Почему инференс стал узким местом для агентного ИИ
Пока рынок обсуждает новые модели, на практике все чаще упирается в скорость их обслуживания. Для систем вроде Claude Code, Codex и Cursor важен не только «ум» модели, но и то, как быстро и стабильно она отвечает под нагрузкой.
Именно на эту проблему нацелена LightSeek Foundation, выпустившая TokenSpeed — новый open-source движок инференса для LLM под лицензией MIT. Проект пока находится в режиме preview, но уже заявлен как инфраструктурный инструмент для агентных сценариев, где обычные бенчмарки часто не отражают реальную картину.
Чем агентные нагрузки отличаются от обычного чат-бота
В кодинговых агентах сессии длиннее и сложнее: контекст может превышать 50 000 токенов, а диалог тянется десятки шагов. В таких условиях нужно одновременно держать высокий общий поток и быстро отвечать каждому конкретному пользователю.
Проще говоря, важны две метрики: TPM (сколько токенов в минуту обрабатывает один GPU) и TPS (сколько токенов в секунду получает пользователь). TokenSpeed оптимизируют сразу под обе цели: максимальный TPM при гарантированном «пороге отзывчивости» по TPS, обычно около 70 и выше.
Архитектура TokenSpeed: 5 опорных компонентов
1) Моделирование параллелизма через компилятор
В основе — подход SPMD (одна программа, разные части данных). Разработчику не нужно вручную прописывать всю межпроцессную коммуникацию: достаточно указать размещение входов и выходов, а легковесный статический компилятор сам соберет нужные коллективные операции.
2) Планировщик с разделением control plane и execution plane
Управляющая часть сделана на C++ как конечный автомат, где корректность работы с KV-cache проверяется на этапе компиляции, а не уже в проде. Это важно, потому что ошибки в кэше контекста у LLM-сервисов встречаются особенно часто.
Исполняющая часть при этом остается на Python, чтобы командам было проще и быстрее внедрять новые фичи.
3) Модульный слой GPU-ядер
В TokenSpeed вычислительные ядра вынесены в отдельную подключаемую систему с публичным API и реестром выбора. Это дает гибкость для разных ускорителей, а не только одной аппаратной платформы.
4) Оптимизации для MLA
Команда отдельно усилила MLA (Multi-head Latent Attention) для агентных нагрузок на NVIDIA Blackwell. По заявлению разработчиков, их реализация уже принята в vLLM, что косвенно подтверждает практическую ценность подхода.
5) Интеграция SMG
Через SMG (PyTorch-native компонент) снижаются накладные расходы при передаче запроса от CPU-оркестрации к GPU-исполнению. Это помогает убрать лишние миллисекунды на «стыке» систем.
Результаты тестов: сравнение с TensorRT-LLM на NVIDIA B200
Сравнение проводили на трассах SWE-smith, которые близки к реальному трафику кодинговых агентов. В качестве тестовой модели использовали Kimi K2.5, а конкурентом выступал TensorRT-LLM.
- В режиме минимальной задержки TokenSpeed оказался примерно на 9% быстрее.
- По пропускной способности при уровне около 100 TPS на пользователя выигрыш составил примерно 11%.
- В ряде decode-сценариев со speculative decoding и длинным префиксом KV-cache задержка снижалась почти в 2 раза относительно TensorRT-LLM.
Важно: эти цифры относятся к single-deployment конфигурации, без disaggregated-сценариев. Поддержка PD-disaggregation, по словам команды, еще дорабатывается.
Почему это важно для рынка ИИ
Если генеративный ИИ идет в массовую разработку ПО, то победит не только лучшая модель, но и лучшая инфраструктура инференса. TokenSpeed показывает сдвиг в сторону специализированных движков под агентные задачи, где критичны длинный контекст, стабильная задержка и высокая плотность запросов на GPU.
Для индустрии это сигнал: конкуренция смещается на уровень системной инженерии. А для команд, строящих AI-продукты, появление MIT-решения такого класса может снизить зависимость от закрытых стеков и ускорить эксперименты в продакшене.