Зачем агентам особый инференс и как TokenSpeed разгоняет LLM

Когда запускаешь стандартную нейросеть для генерации текста или кода, возможностей движков вроде vLLM обычно хватает с запасом. Но как только дело доходит до автономных AI-агентов, картина меняется. Постоянные вызовы инструментов, ветвление диалога, многократные повторы контекста и растущий KV-кэш быстро ставят обычный инференс на колени.

В мае этого года команда LightSeek выложила на GitHub проект TokenSpeed. Разработчики задались целью сделать специализированный движок для агентских нагрузок, который сочетает скорость TensorRT-LLM с понятным и простым Python-интерфейсом.

Что ломается в обычных движках при работе с агентами

Агентские сценарии сильно отличаются от диалога с чат-ботом. Бот получает запрос, формирует один ответ и освобождает ресурсы. Агент же работает циклично:

• Формирует мысли и выбирает инструмент
• Ждет ответа от внешнего API или базы данных
• Анализирует полученный результат и делает следующий шаг

Из-за этого контекст постоянно разрастается, а сервер вынужден заново пересчитывать длинные цепочки токенов или удерживать гигантские объемы памяти под KV-кэш. Если одновременно запустить десятки таких агентов, даже мощные ускорители начинают простаивать в ожидании передачи данных.

Архитектура TokenSpeed и решение проблемы

Авторы TokenSpeed не стали делать очередную тонкую обертку над PyTorch. Они переписали критические узлы системы, чтобы выжать максимум из железа.

Во-первых, они разделили управляющий контур и исполнение. Планировщик запросов написан на C++, а верхнеуровневое исполнение оставили на Python. Состояние каждого запроса, передача владения KV-кэшем и тайминги завязаны на строгий конечный автомат. Система типов C++ еще во время компиляции проверяет безопасность повторного использования ресурсов кэша, что полностью исключает утечки памяти.

Во-вторых, в движок встроен статический компилятор для распределенных вычислений. Разработчику не нужно вручную прописывать логику параллелизма через torch.distributed. Достаточно разместить аннотации на границах модулей, и компилятор сам сформирует команды для межпроцессорного взаимодействия.

В-третьих, здесь переработали низкоуровневые кернелы. Авторы реализовали собственную версию алгоритма Multi-head Latent Attention (MLA), оптимизированную под архитектуры NVIDIA Hopper и Blackwell. Она минимизирует задержки при активной работе с длинным контекстом.

Цифры и реальные тесты

Разработчики приводят конкретные бенчмарки на актуальных моделях. В мае проект продемонстрировал скорость в 580 токенов в секунду на модели Qwen3.5-397B-A17B в агентских задачах.

Если взглянуть на графики сравнения с TensorRT-LLM на чипах NVIDIA B200 при запуске модели Kimi K2.5, TokenSpeed выигрывает по пропускной способности при том же уровне задержки.

Интересно наблюдать за тем, как быстро проект адаптирует свежие релизы. Например, поддержку моделей Kimi K3 и FP4-инференса для видеокарт NVIDIA и AMD добавили буквально в день их официального выхода.

Интеграция в существующий код

С точки зрения точки входа TokenSpeed использует AsyncLLM. Архитектура минимизирует накладные расходы процессора на обработку входящих HTTP-запросов, поэтому сервер не захлебывается при высоком RPS.

Пример запуска сервера выглядит знакомо для всех, кто работал с vLLM:

python3 -m tokenspeed.entrypoints.openai.api_server \
    --model Qwen/Qwen2.5-7B-Instruct \
    --port 8000

После этого к серверу можно обращаться через стандартный клиент OpenAI, что упрощает встраивание в готовые агентские фреймворки вроде AutoGen, CrewAI или LangChain.

Стоит ли ставить в продакшен

На данный момент у репозитория около 1700 звезд и почти 50 открытых issue. Это молодой, динамичный проект, который пока рано назвать консервативным стандартом отрасли.

Попробовать TokenSpeed точно имеет смысл, если у вас уже развернута инфраструктура для AI-агентов и вы уперлись в потолок производительности vLLM на длинных контекстах. Если же вам нужен простой сервер для обслуживания базового чат-бота, стандартных инструментов пока хватит с запасом.