Задержка Kimi K3

Время до первого токена

Пять стриминговых прогонов, тривиальный промпт («Count to three»), потолок 128 токенов:

Медиана TTFT — 2,82 с. Но взгляните на средний столбец: три прогона из пяти вообще не выдали ни одного токена контента. Это не результат по задержке — это ловушка бюджета рассуждений, пойманная в естественной среде. Потолок в 128 токенов целиком ушёл на размышления, и стрим завершился, выдав только рассуждения. Если вы стримите K3 пользователю, тихий сбой выглядит именно так.

Для ощущаемой скорости важен именно разрыв между первым токеном и первым токеном контента: в прогоне 1 рассуждения начались на 2,74 с, а ответ — только на 4,62 с. Если вы показываете reasoning_content, пользователь видит движение уже через ~2,8 с. Если нет — смотрит на спиннер ~4,6 с.

Длинный контекст

Без стриминга, с тривиальным выходом — то есть по сути «сколько времени нужно K3, чтобы прочитать ваш промпт и подумать над ним»:

Реальное время растёт вместе с промптом

Секунды на вызов, тривиальный выход · замерено 2026-07-16

Полмиллиона токенов — это 52 секунды и $1.49 за один запрос, ещё до того, как K3 начнёт что-либо писать. Окно в миллион токенов реально, но оно не быстрое и не бесплатное: при ~5-кратном росте токенов мы увидели ~5-кратный рост реального времени, так что потолок в ~1 млн правдоподобно выходит на отметку около двух минут. Мы это не проверяли — это был бы вывод, а не замер.

Скорость даёт архитектура, а не кэширование

Разумная надежда: прогреть префикс, пропустить работу, вернуть себе задержку. Мы это проверили. Не подтверждается. При сравнении холодных и тёплых вызовов на одинаковых префиксах реальное время стабильно не улучшалось — 3,56 с→3,80 с, 3,02 с→4,29 с, 3,99 с→3,54 с, 4,38 с→4,27 с, 5,22 с→3,78 с. Разброс от прогона к прогону перекрывал любой эффект кэша.

Причина структурная: K3 тратит секунды на рассуждения при каждом вызове, независимо от того, был ли промпт в кэше, — и именно это доминирует в таймлайне. Кэширование — оптимизация счёта, а не задержки.

Что с этим делать

• Стримьте всегда. Без стриминга длинный контекст — это минута тишины. stream: true плюс stream_options: {"include_usage": true}.
• Ставьте клиентские таймауты в минутах. Таймауты SDK по умолчанию убьют вполне легитимные вызовы с длинным контекстом. Мы замерили 52 с на одном успешно завершившемся запросе.
• Решите, что делать с паузой на рассуждения. ~2,8 с до первого токена рассуждений, ~4,6 с до первого токена контента. Либо показывайте размышления, либо показывайте спиннер, рассчитанный на несколько секунд работы.
• Не ставьте K3 в синхронный путь запроса, которого человек ждёт с коротким лимитом времени. Модель думает. В этом и есть продукт.
• Урезайте контекст. Задержка растёт с размером промпта, и, в отличие от стоимости, кэш-скидки, которая бы её смягчила, здесь нет.

Чем эти цифры не являются

Это не бенчмарк. Один клиент, один сетевой маршрут, один день, выборки от одного до пяти прогонов. В них зашиты наш маршрут до серверов Moonshot и та нагрузка, под которой Moonshot был в день запуска, — а свежий флагман в такой день предположительно занят.

В каждом числе здесь доминируют размышления K3, измеряемые секундами. Сетевая маршрутизация — включая хоп через транзитный шлюз — на этом фоне миллисекунды, поэтому мы считаем эти цифры таймингами K3, а не какого-то конкретного эндпоинта. Где мы их снимали.

Читайте их как порядки величин, а не замеры модели: секунды, а не миллисекунды до первого токена; десятки секунд, а не секунды на 100 тыс.; минута, а не десять секунд на 500 тыс. Такова форма явления, и её достаточно, чтобы проектировать с оглядкой на неё. Когда нагрузка дня запуска уляжется, мы прогоним замеры заново и обновим даты.