Together Inference Engine показал 31% больше TPS и в 2× лучше p50 TTFT в бенчмарке coding‑агентов

В сравнительном бенчмарке на реальной нагрузке coding‑агентов Together Inference Engine дал при одинаковом железе на 31% больше TPS по сравнению с ближайшим OSS‑решением и сохранил в 2× лучшее p50 TTFT при насыщении;

Together Inference Engine в бенчмарке для coding‑агентов продемонстрировал на 31% большую пропускную способность (TPS) и в два раза лучшее p50 TTFT при насыщении, что указывает на более высокую отзывчивость и пропускную способность при одинаковом аппаратном парке. Отчёт с результатами опубликован 19 мая 2026 года; авторами указаны Alex Angus, Will Van Eaton и Dan Fu.

Тестирование моделировало реальные сессии coding‑агента с промптами от примерно 45 000 до 200 000 токенов и средней длиной генерации около 450 токенов (p50 = 293, p99 = 2 230). В качестве ключевых метрик использовались TPM (input tokens per minute), TPS (tokens per second) на пользователя и p50 TTFT. Аппаратная конфигурация испытаний — 4× NVIDIA B200 для основного движка; в примечании упомянут вариант SGLang на 8× B200. Авторы называют это релизом «версия 1» и планируют дальнейшие обновления.

Авторы подчёркивают, что стандартные одно‑пользовательские бенчмарки плохо отражают поведение в продакшене: при десятках одновременных запросов взаимно влияют общая ёмкость KV‑кеша, пропускная способность памяти и GPU‑циклы. Для coding‑агентов выделены три критических фактора: высокая чувствительность пользовательского опыта к времени до первого токена (TTFT), одновременный длительный контекст, который нагружает KV‑кеш и планировщик, и форма вывода — короткие, частые «всплески» декода, где доминирует стадия prefill.

Технические улучшения, которые, по авторам, дают преимущество в этой нагрузке, — это комплексная оптимизация стека: использование ThunderMLA, переписывание «горячих» ядер (custom kernel rewrites) и сквозное профилирование на реальном трафике. В отчёте приводится сравнение с ближайшим открытым движком по пропускной способности и экономике: в их условиях измерений стоимость работы оказалась примерно на 76% ниже по сравнению с Claude Opus 4.6. По мнению авторов, для развёртывания coding‑агентов важнее оптимизировать prefill и поведение scheduler при заполнении кешей, чем фокусироваться на декод‑сквозной пропускной способности; на практике ключевые точки мониторинга — p50 TTFT, заполнение KV‑кеша и TPM/TPS при росте QPS.

Отчёт отмечает ограничения исследования: это версия 1, сценарий специально ориентирован на coding‑агентов и моделирует рост сессий и реальный churn, поэтому не все выводы автоматически переносятся на задачи с длительным непрерывным декодом (например, суммаризация очень длинных документов). Авторы заявляют о намерении обновлять бенчмарк по мере развития оптимизаций и расширения набора моделей.