Пользователь нажимает «Отправить». Появляется пульсирующий лоадер. Проходит секунда. Две. Три. На четвертой секунде палец тянется закрыть вкладку. В мире классического веба мы десятилетиями боролись за First Contentful Paint (FCP) и Time to Interactive (TTI). Мы минифицировали JavaScript, настраивали CDN, сжимали картинки в WebP. Но в эпоху генеративного ИИ старые метрики потеряли смысл. Метрика выживания изменилась. Теперь миром правит Time To First Token (TTFT) — время от отправки запроса до появления первого осмысленного символа ответа на экране. И эта метрика безжалостно убивает конверсию AI-продуктов.
Исследования человеческого восприятия непреклонны: реакция системы быстрее 100 миллисекунд кажется нашему мозгу мгновенной, физическим продолжением нашего собственного действия. До 400 миллисекунд мы способны удерживать контекст диалога, воспринимая задержку как естественную паузу перед ответом собеседника. Все, что длится дольше одной секунды, прерывает поток мыслей (flow). Когда нейросеть «думает» 5 секунд перед тем, как выдать первое слово, пользователь испытывает когнитивный диссонанс.
Лоадеры, скелетные экраны и забавные анимации больше не спасают. Они работали как отвлекающий маневр, когда мы ждали загрузки статической страницы или ответа от базы данных. Но ожидание ответа от ИИ-помощника воспринимается иначе. Мы подсознательно антропоморфизируем чат-ботов. Долгое молчание собеседника вызывает не просто скуку — оно вызывает раздражение и недоверие к компетенции системы. Если бот техподдержки думает 10 секунд над простым вопросом, клиент уходит к живому оператору или закрывает приложение.
Анатомия ожидания: Физика сетей против математики инференса
Давайте препарируем эти секунды ожидания. Почему TTFT получается таким огромным? Проблема складывается из двух фундаментальных слоев: физики сетей и математики LLM-инференса.
Сетевая задержка в РФ имеет свою жесткую специфику. Большинство мощных GPU-кластеров (серверы OpenAI, Anthropic, крупные хабы Azure и AWS) физически расположены в США или Западной Европе. Пакет данных из Москвы во Франкфурт летит около 40-50 миллисекунд (Round Trip Time, RTT). Кажется, это ничтожно мало? Но сетевые протоколы работают иначе — мы не отправляем один пакет.
Установка защищенного соединения с нуля требует времени и множества сетевых обменов. Сначала DNS-резолвинг (20-50 мс). Затем TCP Handshake (SYN, SYN-ACK, ACK) — это один полный RTT (50 мс). Следом идет TLS Handshake для установки шифрования. Даже с современным TLS 1.3 это требует еще одного RTT (50 мс), а на старых версиях — двух. Итого, только на то, чтобы сказать серверу «привет» и договориться о шифровании, мы тратим 150-200 миллисекунд.
Если трафик маршрутизируется до Восточного побережья США (например, дата-центры в Ashburn, Virginia), RTT возрастает до 110-130 мс. Установка соединения съедает уже 300-400 миллисекунд. А ведь мы еще даже не начали передавать сам промпт. Если промпт большой (сотни килобайт контекста), в дело вступает TCP Slow Start — алгоритм начинает передачу с небольшого окна (initcwnd, обычно 10 пакетов) и постепенно его увеличивает, требуя дополнительных RTT для подтверждения доставки. Сетевой налог растет экспоненциально.
Фаза Prefill: Тяжелая артиллерия инференса
Как только промпт наконец достигает серверов провайдера, начинается математика. Генерация текста в LLM делится на две фазы: Prefill (обработка контекста) и Decode (генерация новых токенов).
Прежде чем выдать первый токен, модель должна «прочитать» весь входящий промпт и вычислить для него матрицы внимания (attention Key-Value cache). Это фаза prefill. Она требует колоссальной вычислительной мощности и пропускной способности памяти GPU. Если пользователь загрузил документ на 100 страниц (около 50 000 токенов), вычисление KV-кэша займет время. У современных топовых моделей prefill rate составляет от 1000 до 5000 токенов в секунду на один GPU. Значит, только на «осмысление» большого промпта уйдет от 10 до 50 секунд.
И вот здесь возникает критический разрыв. Сеть сожрала полсекунды. Провайдер потратил еще несколько секунд на prefill. Пользователь видит крутящийся спиннер, его терпение лопается, и он уходит.
Узкое горлышко шлюзов: Как мы стреляем себе в ногу
Многие команды разработчиков пытаются решить проблему исключительно на клиенте, рисуя красивые анимации "ИИ анализирует данные..". Это пластырь на открытый перелом. Реальное решение лежит на уровне инфраструктуры.
Когда вы строите production-ready AI-приложение, вы редко ходите к провайдерам напрямую с фронтенда. Это небезопасно и неконтролируемо. Вы используете собственный бэкенд-шлюз (gateway) для управления API-ключами, биллинга, проверки лимитов, логирования и модерации промптов.
Именно здесь прячется скрытый враг TTFT. Если ваш шлюз написан неоптимально, он становится главным бутылочным горлышком. Синхронный код, блокирующие вызовы к базе данных для проверки баланса пользователя перед отправкой запроса, отсутствие пулирования соединений (connection pooling) с апстримами — все это добавляет сотни миллисекунд.
Представьте типичный плохой сценарий: запрос приходит на ваш сервер. Сервер делает блокирующий SELECT в базу данных. Затем открывает новое TLS-соединение до OpenAI. Ждет ответа. Буферизирует его в памяти. И только потом начинает отдавать клиенту. Вы только что умножили сетевую задержку на два, убили стриминг и добавили задержку базы данных.
Инженерия минимального TTFT: Подход RouterAPI
Как мы решаем эту задачу в RouterAPI? Мы рассматриваем каждую миллисекунду как критический ресурс. Наша архитектура спроектирована так, чтобы свести накладные расходы шлюза к абсолютному минимуму.
Во-первых, мы уничтожаем сетевой налог на установку соединений. Наш высокопроизводительный шлюз, RouterAPI, поддерживает постоянные пулы прогретых соединений (keep-alive) со всеми мажорными провайдерами (OpenAI, Anthropic, Google и другими провайдерами). Когда приходит запрос от пользователя, TCP и TLS handshake уже выполнены заранее. Промпт улетает в уже открытый, прогретый сокет. Это мгновенно срезает 200-400 миллисекунд.
Во-вторых, мы жестко разделяем бизнес-логику и проксирование трафика. Сложная логика (синхронизация моделей, расчет стоимости, администрирование) живет в Laravel-приложении. Но сам стриминг токенов обрабатывается легковесным Go-сервисом. Стриминг от апстрима до клиента реализован абсолютно прозрачно и неблокирующе. Как только первый байт первого токена падает в сетевой буфер от провайдера, он мгновенно отправляется (flushed) в SSE-соединение (Server-Sent Events) клиента. Никакой промежуточной буферизации ради логов.
В-третьих, проверки баланса и учет токенов вынесены из критического пути. Мы используем Redis для сверхбыстрой проверки лимитов (rate limiting и базовый баланс) за доли миллисекунды до отправки запроса. А детальный биллинг, подсчет токенов и запись логов происходят асинхронно (out-of-band), уже после того, как соединение закрыто. Пользователь не ждет, пока мы запишем транзакцию в MySQL.
Суровая реальность AI UX
Снижение TTFT с 3 секунд до 0.8 секунды фундаментально меняет восприятие продукта. Приложение перестает казаться тяжелым скриптом, который делает запрос к стороннему API, и начинает ощущаться как живой, отзывчивый интеллект.
Вы не можете заставить LLM быстрее вычислять матричные умножения на чужих серверах. Вы не можете изменить скорость света в оптоволоконных кабелях, проложенных по дну Атлантического океана. Но вы обязаны выстроить свою сетевую инфраструктуру так, чтобы между готовностью первого токена на GPU провайдера и его рендерингом в DOM-дереве браузера пользователя не было никаких искусственных препятствий.
Выбор правильного шлюза и оптимизация маршрутизации — это не просто вопрос красивых графиков в Grafana. Это вопрос выживания продукта на рынке. Пользователи больше не готовы ждать. Миллисекунды действительно решают всё.