Стоит читать если: вы работаете с LLM-агентами в продакшене, где важна стабильная производительность и низкая задержка под высокой конкурентной нагрузкой. Можно пропустить если: вас интересуют только бенчмарки одного пользователя на пустой системе.
Обычные бенчмарки не показывают реальность
Идеализированные условия далеки от продакшена. Большинство бенчмарков измеряют производительность, когда один пользователь обращается к выделенному эндпоинту. Эти цифры хорошо выглядят, но не отражают поведение системы в реальной среде, где множество одновременных запросов конкурируют за KV-кэш, пропускную способность памяти и циклы GPU. Вместо этого, Together AI фокусируется на том, что происходит с каждым пользователем, когда система находится под нагрузкой.
Нагрузка кодирующих агентов уникальна. Запросы кодирующих агентов характеризуются длинным контекстом (от ~45k до 200k токенов), высокой конкуренцией и необходимостью минимальной задержки. Модель генерирует функцию, а не длинное эссе, поэтому средняя длина вывода составляет около 450 токенов. Это создает специфическое давление на префилл-этап вывода: система испытывает интенсивное, но кратковременное давление на генерацию, а не на длительную декомпрессию. Три ключевых фактора, влияющих на производительность в таких условиях:
- Чувствительность к TTFT. Разработчик не видит ничего, пока не придет первый токен. Эта задержка критична для восприятия скорости инструмента.
- Конкуренция при длинном контексте. Десятки разработчиков одновременно отправляют запросы с контекстом более 80k токенов, что приводит к переполнению KV-кэша и деградации TTFT.
- Форма вывода, ориентированная на префилл. Относительно короткие выходы означают, что движки, оптимизированные для длительной декомпрессии, не обязательно будут выигрывать здесь.
Оптимизация: ThunderMLA и низкоуровневые ядра
Производительность — это проблема всего стека. Together AI достигла значительных улучшений производительности благодаря сквозной оптимизации: от профилирования до переписывания ядер. Вместо изолированных улучшений, компания рассматривает инференс как проблему полного стека, устраняя узкие места по всей цепочке.
ThunderMLA ускоряет обработку. В архитектуре Kimi K2.5, использующей Multi-head Latent Attention (MLA), стандартные реализации запускают два отдельных ядра на каждом шаге декомпрессии. ThunderMLA, часть библиотеки ThunderKittens, объединяет их в один «мегакернел». Это устраняет накладные расходы на запуск и улучшает производительность на 20–35% по сравнению с DeepSeek FlashMLA на аналогичных нагрузках.
Кастомные ядра превосходят стандартные. Кроме ThunderMLA, Together AI профилировала весь стек — поведение драйверов, макет памяти, выполнение ядер — и устранила каждый найденный «бутылочное горлышко». Некоторые изменения касались конфигурации, другие требовали написания ядер с нуля. Эти кастомные ядра на данной рабочей нагрузке превосходят открытые аналоги TensorRT-LLM.
Результаты на Kimi K2.5: 31% больше TPS и 2x TTFT
Сравнение с конкурентами. Together Inference Engine сравнивался с двумя базовыми движками на модели Kimi K2.5 с EAGLE speculative decoding: TensorRT-LLM (4x NVIDIA B200 GPU) и SGLang (8x NVIDIA B200 GPU, поскольку реализация EAGLE в SGLang требовала больше памяти). Together IE и TensorRT-LLM работали на 4 GPU.
При 2.5 миллионах входных токенов в минуту (TPM) на GPU (всего 2.5M TPM), Together Inference Engine обеспечивает 31% больше TPS, чем TensorRT-LLM, и является единственным движком, который поддерживает TTFT ниже 1 секунды.
Кривая деградации показывает преимущество. Когда все движки начинают деградировать под нагрузкой 2.5M TPM, Together IE демонстрирует p50 TTFT в 0.71 секунды. TensorRT-LLM показывает 1.1 секунды, а SGLang — 5.1 секунды. Таким образом, TTFT Together IE вдвое лучше, чем у TensorRT-LLM, и втрое лучше, чем у SGLang, предоставляя больше запаса по производительности.
Качество и стоимость: Kimi K2.6 против Claude Opus 4.6
Kimi K2.6 конкурирует с ведущими моделями. Новая модель Kimi K2.6 теперь доступна на Together AI и на бенчмарках кодирования (SWE-Bench Verified, SWE-Bench Pro, LiveCodeBench v6, Terminal-Bench 2.0) соответствует или превосходит Claude Opus 4.6.
- SWE-Bench Verified: Kimi K2.6 — 80.2, Claude Opus 4.6 — 80.8
- SWE-Bench Pro: Kimi K2.6 — 58.6, Claude Opus 4.6 — 53.4
- LiveCodeBench v6: Kimi K2.6 — 89.6, Claude Opus 4.6 — 88.8
- Terminal-Bench 2.0: Kimi K2.6 — 66.7, Claude Opus 4.6 — 65.4
Значительная экономия затрат. На типичном запросе для кодирующего агента (~80k–100k входных токенов, ~450 выходных токенов), стоимость запроса для Kimi K2.6 на Together AI составляет $0.108, в то время как для Claude Opus 4.6 — $0.451. Это означает, что Kimi K2.6 на 76% дешевле. Для команды из 30 инженеров, использующей кодирующего агента на 1.5M TPM в течение 5 часов в день (250 рабочих дней), годовая экономия на инференсе может достигать ~$440 000 по сравнению с Claude Opus 4.6.
Что это значит
Продакшен-бенчмаркинг меняет правила игры. Подход Together AI к бенчмаркингу подчеркивает важность тестирования LLM-инференса не в идеальных условиях, а в реальных продакшен-сценариях с высокой конкурентной нагрузкой. Это дает инженерам более точное представление о том, чего ожидать от моделей и движков в реальных развертываниях. Выбор движка и модели для кодовых агентов теперь зависит от их способности поддерживать производительность под нагрузкой, а не только от "голых" цифр TPS или TTFT в вакууме.