Задержка Kimi K3

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

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

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

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

Повторный замер 2026-07-18: реальные промпты — другой режим

Два дня спустя мы прогнали серию побольше: десять стриминговых прогонов на каждый эндпоинт, каждый со своим реалистичным промптом (задача «объясни в двух предложениях» — над такой K3 действительно думает), без кэш-попаданий, через оба эндпоинта EvoLink:

• Сложность промпта сдвигает TTFT в 3–4 раза. В тот же день тривиальный промпт по-прежнему отдавал первый токен за ~3,35 с; попросите модель действительно подумать — и медиана первого токена уходит к 11,3 с. Закладывайте бюджет под промпт, который реально отправите.
• Разброс огромен. Отдельные прогоны — от 2,9 до 40 с до первого контента. p95 около 36 с означает: один вызов из двадцати заставит пользователя ждать полминуты до первого видимого символа — если не стримить рассуждения или прогресс.
• Основной эндпоинт оправдывает имя. direct.evolink.ai обошёл резервный api.evolink.ai по всем медианам, примерно на 4 с в середине распределения. В проде используйте direct.

Пропускная способность при этом стабильна: 15–18 токенов/с после начала контента, оба эндпоинта, оба дня. Ожидание сосредоточено в начале; сам стрим в порядке. Сравниваете шлюзы? Тот же протокол прогнали и через OpenRouter, парными раундами в двух окнах — стабильного победителя нет (страница на английском). Собственная медиана EvoLink сдвинулась с 21,4 с в первом окне до 31,1 с часом позже — дрейф по времени суток того же масштаба, что и разрыв между шлюзами.

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

Без стриминга, с тривиальным выходом — то есть по сути «сколько времени нужно 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 с на одном успешно завершившемся запросе.
• Решите, что делать с паузой на рассуждения. ~3 с до первого токена рассуждений на тривиальных промптах, медиана 11 с на реальных, а первый токен контента приходит ещё на секунды или десятки секунд позже. Либо показывайте размышления, либо делайте индикатор прогресса, рассчитанный на десятки секунд на p95.
• Не ставьте K3 в синхронный путь запроса, которого человек ждёт с коротким лимитом времени. Модель думает. В этом и есть продукт.
• Урезайте контекст. Задержка растёт с размером промпта, и, в отличие от стоимости, кэш-скидки, которая бы её смягчила, здесь нет.

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

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

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

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

FAQ по задержке Kimi K3

Насколько быстро отвечает API Kimi K3?

Зависит от промпта. На тривиальном промпте медиана до первого токена ~3 секунды (2,8 с 2026-07-16, 3,35 с при повторе 07-18). На реалистичных промптах замер 2026-07-18 дал медиану 11,3 с до первого токена рассуждений и 21,4 с до первого токена контента (n=10, p95 35,7 с), пропускная способность — 18,4 токена/с (медиана) после начала контента. Первый токен всегда — рассуждение, а не ответ. Это замеры с одного клиента, а не бенчмарк.

Сколько времени Kimi K3 обрабатывает длинный контекст?

Мы замерили 10,5 секунды на промпте в 98 625 токенов и 52,0 секунды на промпте в 497 718 токенов, оба раза с тривиальным выходом. Масштабирование выглядело примерно линейным, так что полное окно в 1 048 576 токенов правдоподобно приближается к двум минутам, хотя мы этого не проверяли.

Ускоряет ли кэширование промптов Kimi K3?

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