15 августа 2026 в русскоязычных лентах разошёлся репозиторий patchy631/time-to-first-token. Название читается как слоган про скорость. На 21 августа 2026 это не демо и не подборка трюков. Это план на десять недель: один OpenAI-совместимый сервис, живые метрики, нагрузка выше 1000 одновременных запросов и бенчмарк, который можно показать. Запрос «как запустить инференс LLM» чаще заканчивается стопкой ноутбуков. Здесь наоборот: один артефакт растёт, а не плодится.

Слово в названии не случайное. Time to first token это первая пауза, которую человек чувствует в чате, в агенте и в голосовом боте. Пока первый токен не пришёл, экран пустой. Ниже сверка репозитория и практический разбор: что такое TTFT, почему метрика решает для продукта, с чего начать инференс и какие ошибки ломают и сервис, и чужой замер.

Что такое time to first token

Time to first token (TTFT) это время от отправки запроса до первого выходного токена модели. Так метрику описывают карточка IBM, гайды по бенчмаркам NVIDIA и документация serving-стеков. Это не «сколько модель думает вообще». Это момент, когда поток ответа стартовал и пользователь впервые видит текст.

Пока первый токен не появился, внутри стека обычно успевают четыре вещи:

  1. сеть до GPU или до API;
  2. очередь, если слоты заняты;
  3. prefill: полный проход по промпту и сбор KV-кэша;
  4. первый шаг decode, уже после прогретого кэша.

Prefill упирается в вычислительную мощность и растёт вместе с длиной входа. Decode после этого упирается в пропускную способность памяти: каждый новый токен читает кэш. Поэтому TTFT и «токены в секунду» это разные оси. Система может сыпать токены быстро и всё равно казаться мёртвой, если до первого символа прошло две секунды.

Рядом с TTFT держат ещё три числа. Их нельзя склеивать в одно «у нас быстро».

Для чата и голосового агента сначала смотрят TTFT и ITL. Для пакетной генерации важнее throughput. Для IDE, которая ждёт готовый патч целиком, часто решает E2E. Чужой маркетинговый «300 мс TTFT» без длины промпта ничего не значит. На 100 токенах входа это обычный результат. На 10 000 токенах это уже сильный стек.

Почему TTFT важна продукту

Пользователь не видит GPU utilization. Он видит пустое окно. Ориентиры для интерактива, не догма: на коротком и среднем промпте (порядка 1k токенов) TTFT ниже 300 мс ощущается как мгновенный ответ, 300-600 мс ещё приемлемы, больше секунды выглядят как зависание. Полный ответ потом может прийти быстрее, чем у конкурента. Человеку это уже не поможет: он успел решить, что сервис «не отвечает».

На продукт это ложится по-разному.

Для продукта метрика ещё и про деньги. Пока запрос стоит в очереди, вы платите за карту и теряете слот. Живой p50 при плохом p99 значит, что в пике очередь душит хвост пользователей. Среднее это прячет. В репозитории time-to-first-token дашборд с самого начала показывает TTFT, ITL, throughput, глубину очереди и стоимость запроса. Это перевод фразы «модель отвечает» в SLA и юнит-экономику.

Если вы уже считаете цену токена у облачных API, та же логика нужна и своему endpoint: не «сколько стоит миллион», а сколько стоит один пользовательский ход при вашем TTFT и вашей утилизации. Как сравнивать цену токена у чужих моделей, мы разбирали отдельно: сколько стоят токены Claude и GPT.

Как запустить инференс LLM: один сервис

Ответ на «как запустить инференс LLM» зависит от того, что вы хотите увидеть через месяц. Если нужен скрин «it works», хватит Ollama на ноутбуке. Если нужен продукт, репозиторий отвечает иначе: 50 сессий по 30 минут, 10 недель, около 25 часов чистого времени. Python, понимание transformer на уровне архитектуры и терминал достаточно. Kubernetes и CUDA с нуля не требуют. Цель одна: OpenAI-совместимый endpoint на арендованной GPU, который вы сами подняли, измерили и прогнали под нагрузкой.

Порядок в README нарочный и отличается от типичного «сразу квантуем».

  1. Сначала ментальная модель. Prefill упирается в compute, decode в память. Без этой картинки квантование, continuous batching и speculative decoding выглядят набором трюков.
  2. Поднять vLLM с моделью 7-8B и сохранить команду запуска. Её будут переиспользовать все следующие недели.
  3. Метрики. Prometheus и Grafana до любой оптимизации.
  4. Второй движок, SGLang, на той же модели и том же железе. Так сравнивают повтор общих префиксов, а не «какой движок моднее».
  5. Нагрузка: фиксированные длины, затем метка 1000+ concurrent, и только потом кванты, speculative decoding и вытеснение KV.

Альтернатива из того же README честная: семнадцать несвязанных экспериментов почти всё время тратят на установку. Один сервис, который обрастает панелями и вариантами, покрывает тот же материал и оставляет что показать.

Что ставить в первую неделю

Для старта хватает одной карты примерно на 24 ГБ. В репозитории аренду считают получасами и гасят инстанс между сессиями: RunPod, Modal, Lambda, vast.ai. Colab оставляют на чистый Python без serving. H100 нужен точечно: сессия с 1000 одновременными и, если будете гонять по-настоящему, разделение prefill и decode.

Практический минимум на своей или арендованной карте:

Если карта уже дома и вы смотрите в сторону локальной 27B, это другой контур: качество кода и VRAM, не serving на тысячу одновременных. Его мы разбирали в статье про Qwen 3.8 на RTX 3090. Для дороги time-to-first-token берите 7-8B. Иначе первая неделя уйдёт на нехватку памяти, а не на метрики.

Неделя 1 в репозитории GPU почти не требует: roofline, арифметическая интенсивность, почему добавленные FLOPS не лечат memory-bound decode. Имеет смысл прочитать это до аренды. Иначе вы купите час H100, чтобы заново открыть, что decode ждёт память.

Метрики, без которых оптимизация слепая

Неделя 3 в roadmap посвящена линзе, не ускорению. Пока нет живых панелей, любая «оптимизация» это вкус. Документация метрик vLLM как раз про гистограммы задержек и счётчики очереди, не про среднее «у нас 40 ток/с».

Что должно быть на дашборде до нагрузочного прогона:

Скрейп Prometheus чинят на слабом трафике. Чинить его в момент 1000 одновременных уже поздно: вы не отличите падение панели от падения сервиса. Панель без определения метрики в репозитории предлагают удалять. Это хорошее правило и для продукта: если вы не можете сказать, что именно рисует график, по нему нельзя принимать решение о железе.

Отдельно про длину входа. TTFT почти линейно страдает от длинного промпта, потому что prefill обязан пройти весь контекст, прежде чем появится первый новый токен. Системный промпт на две страницы, история чата и приложенный репозиторий сидят в той же паузе, что и «модель медленная». Иногда быстрее режет контекст, чем покупать более крупную карту. Та же дисциплина, что в работе с квотами агента: не тащить в запрос всё, что модель когда-либо видела. Про соседний контур экономии токенов: лимиты Claude Code.

Нагрузка: 1000 одновременных и честный бенчмарк

Неделя 5 в roadmap собирает воспроизводимый harness. GuideLLM гоняет развёртку от синхронного базиса до насыщения, не одну произвольную точку. vllm bench serve ставят рядом как независимую проверку: если два инструмента разошлись, это информация, не повод выбрать красивую цифру. genai-perf снимает concurrency 1, 2, 4 и дальше до 128 и ищет колено: throughput ещё растёт, хвост латентности уже ломается. Именно колено публикуют, не обвал.

Прогон «больше 1000 одновременных» в README делают на арендованном H100 и смотрят KV-кэш плюс очередь. Если TTFT взлетает и num_requests_waiting растёт раньше цели, сервер уже вытесняет запросы. Такой прогон не публикуют. Сначала крутят --max-num-seqs, --gpu-memory-utilization и chunked prefill. Цифра «держали тысячу» ценой преемпшена ничего не стоит продукту: в этом режиме живые пользователи видят секундные паузы.

Чеклист перед тем, как назвать файл бенчмарком, в репозитории короткий и жёсткий:

Без этого «мы держим 1000 concurrent» это анекдот. С этим это артефакт, к которому можно вернуться через квартал и понять, что именно вы тогда мерили.

Частые ошибки

Большая часть поломок на старте инференса не про CUDA. Про привычку оптимизировать раньше, чем появилась линза.

  1. Стопка демо вместо сервиса. Каждая техника в новом контейнере. Через месяц нечего сравнивать: разные модели, разные длины, разные даты драйверов.
  2. Оптимизация до метрик. Квантование и speculative decoding без дашборда дают красивый темп на одном запросе и сюрприз в очереди.
  3. Одна цифра TTFT без длины промпта, без перцентилей и без оговорки, стрим это или полный ответ.
  4. Замер в насыщении. Когда GPU вытесняет запросы, вы публикуете аварию и называете её нагрузкой.
  5. Speculative decoding «потому что ускоряет». В материалах vLLM выигрыш до 2.8× на низком QPS и замедление 1.4-1.8× на высоком. Кроссовер полезнее слогана. Если на вашем реальном request rate спекуляция тормозит, это ожидаемый результат, не провал настройки.
  6. Автоскейл по CPU на GPU-сервисе. В roadmap неделя 8 учит смотреть на глубину очереди, не на загрузку процессора. Процессор на serving-узле часто скучает, пока карта уже стоит в преемпшене.
  7. INT4 как дефолт ради скорости. Если качество на вашем прокси падает сильнее, чем на 1-2%, в README советуют оставить FP16 или FP8. INT4 это рычаг против нехватки памяти, не универсальный ускоритель.
  8. Путать локальный чат и serving. Ollama на ноутбуке закрывает «как запустить» для себя. На вопрос продукта про сотню одновременных сессий саппорта это другой класс задач: очередь, KV-кэш, хвост p99.

Коротко

Time to first token это пауза до первого выходного токена: сеть, очередь, prefill и первый decode. Для продукта это ощущение «жив ли чат», не строка в таблице токенов в секунду. Инференс LLM имеет смысл запускать как один OpenAI-совместимый сервис: модель 7-8B, vLLM, сразу Grafana, потом нагрузка и только потом кванты и спекулятивное декодирование.

Репозиторий patchy631/time-to-first-token на 21 августа 2026 как раз про эту последовательность: 10 недель, метрики, прогон за 1000 concurrent и бенчмарк с закреплёнными версиями. Если публикуете цифры, держите TTFT и ITL раздельно и не мерите в точке, где сервер уже вытесняет очередь. Первичный источник по метрике: Time to First Token у IBM. Первичный источник по плану запуска: README того же репозитория.