Представьте себе сценарий, где автономный ИИ-агент пишет, тестирует и отлаживает код в реальном времени. Пользователь нажимает кнопку, и через мгновение получает готовое решение. Но что, если вместо мгновенной реакции агент начинает «думать» несколько минут, генерируя ответ по одному токену за раз? В мире автономных систем такая задержка не просто неудобна — она делает продукт непригодным для использования. Именно эту проблему решает компания Kog AI, демонстрируя, что инференс больших языковых моделей (LLM) на стандартных датацентровых GPU может достигать скоростей, ранее доступных только на специализированном оборудовании. Их технология позволяет генерировать до 3 000 токенов в секунду на один запрос, используя обычные видеокарты NVIDIA H200 или AMD MI300X.
В этой статье мы подробно разберем, почему оптимизация скорости декодирования для одного запроса стала критически важной метрикой, как память, а не вычислительная мощность, ограничивает скорость современных моделей, и какой подход к совместному проектированию (co-design) архитектуры модели, рантайма и низкоуровневого кода позволяет обойти традиционные программные узкие места. Мы углубимся в технические детали, которые превращают теоретическую пропускную способность памяти в реальную скорость генерации.
01Почему скорость декодирования стала главным KPI для ИИ-агентов
Традиционные бенчмарки для больших языковых моделей часто смешивают три разные метрики: агрегатную пропускную способность (общее количество токенов, сгенерированных в секунду для всех пользователей), время до первого токена (latency prefill) и скорость декодирования на один запрос. Для классического чат-бота, где пользователи ждут ответа, важны первые две метрики. Однако для автономных агентов, таких как программисты-роботы, решающие сложные задачи, ключевой становится именно скорость декодирования токенов.
Агентская работа — это последовательный цикл: осмотр, планирование, редактирование, тестирование и исправление. Каждый шаг зависит от предыдущего. Хотя время выполнения внешних инструментов (запуск тестов, загрузка веб-страниц) может доминировать, шаги, требующие генерации текста (планирование, написание кода, анализ трассировок, отладка), определяют темп всей работы. Кроме того, токены рассуждения (reasoning tokens) накапливаются, увеличивая общее время ответа.
Давайте переведем это в цифры. Если агенту нужно сгенерировать 50 000 токенов в рамках рабочего процесса, то при скорости 100 токенов в секунду это займет около восьми минут. При скорости 3 000 токенов в секунду тот же процесс завершится менее чем за двадцать секунд. Эта разница кардинально меняет возможности продукта. По мере того как агенты становятся более автономными, граница производительности смещается от чистой «интеллектуальности» к произведению «интеллекта на скорость итераций». Лучшие агенты будут не только генерировать больше полезных токенов, но и выполнять больше вызовов инструментов, тестов и правок в тот же временной бюджет.
02Главный враг скорости: пропускная способность памяти, а не FLOPS
Что ограничивает скорость генерации токенов на GPU? Многие ошибочно полагают, что это вычислительная мощность (FLOPS — floating-point operations per second). Однако при размере батча 1, когда модель генерирует токены по одному (autoregressive decoding), основная нагрузка ложится на работу с памятью. Для каждого сгенерированного токена все активные веса модели должны быть перемещены через иерархию памяти GPU, от высокоскоростной памяти HBM (High Bandwidth Memory) к вычислительным процессорам.
Первопричина ограничения проста: скорость токенов в секунду прямо пропорциональна эффективной пропускной способности памяти и обратно пропорциональна объему активных весов модели. Ключевой факт заключается в том, что при низком батче арифметическая интенсивность (arithmetic intensity) очень мала. В формате FP16 вес модели занимает 2 байта и вносит примерно одно умножение-сложение (2 FLOP), что дает соотношение около 1 FLOP на байт. Даже переход на FP8 повышает это значение лишь до ~2 FLOP/байт, а FP4 — до ~4. Однако современные ИИ-видеокарты предлагают сотни пиковых FLOP на каждый байт пропускной способности HBM. Например, NVIDIA H200 имеет пиковый баланс около 400 FLOP/байт. Это означает, что скорость генерации токенов упирается в пропускную способность памяти задолго до того, как вычислительные блоки GPU будут загружены полностью.
Именно поэтому центральной метрикой для скорости декодирования является Memory Bandwidth Utilization (MBU — использование пропускной способности памяти), а не Model FLOP Utilization (MFU). MFU можно улучшить, увеличив размер батча, но это увеличит задержку для каждого пользователя, так как потребуется передавать больше данных кэша KV (Key-Value cache) внутри GPU.
Хорошая новость заключается в том, что пропускная способность памяти GPU уже очень высока. Сервер с 8 видеокартами NVIDIA H200 обеспечивает около 30,7 ТБ/с эффективной агрегатной пропускной способности памяти (с учетом реалистичного потолка в 80% от теоретических 4,8 ТБ/с на карту). Сервер с 8 AMD MI300X достигает примерно 33,6 ТБ/с. Возьмем для примера плотную модель на 2 миллиарда параметров в формате FP16. У нее около 4 ГБ активных весов. Если бы веса могли передаваться идеально (игнорируя трафик кэша KV и возможные перезагрузки тайлов), теоретический предел скорости составил бы:
- 8x H200: 30,7 ТБ/с / 4 ГБ ≈ 7 700 токенов/с
- 8x MI300X: 33,6 ТБ/с / 4 ГБ ≈ 8 400 токенов/с
Эти же скорости применимы к модели MoE (Mixture of Experts) с 4 активными параметрами в FP8. Модель MoE с 32 активными параметрами в FP4 была бы ограничена ~2 000 токенов/с. Таким образом, стратегия для систем с упором на задержку — распараллеливание инференса на полном серверном узле, обеспечивающем восемь GPU-эквивалентов пропускной способности HBM.
03Почему стандартные стеки инференса теряют драгоценные микросекунды
При целевой скорости 3 000 токенов в секунду бюджет на один токен составляет примерно 333 микросекунды, включая все слои, голову языковой модели (LM head) и выборку (sampling). В модели из 25 слоев потеря всего 1 микросекунды на слой потребляет 7,5% от всего временного бюджета!
Обычный стек абстракций — логика графа модели, написанная на высоком уровне (PyTorch, Triton), пониженная до множества ядер (kernels), запланированная процессором (CPU), синхронизированная на границах ядер и опосредованная библиотеками коммуникаций — гибка и удобна для обслуживания. Это подход, используемый в таких движках, как vLLM, SGLang и TensorRT-LLM. Он отлично подходит для максимизации агрегатной пропускной способности при высоких батчах. Однако он плохо подходит для бюджета в 333 микросекунды.
Простой расчет накладных расходов показывает проблему. Если запуск ядра и очистка занимают около 4,5 мкс (по измерениям на AMD MI300X), то десять ядер на слой трансформера в 25 слоев создают 1 125 мкс накладных расходов на токен до начала любой полезной работы. Это ограничивает достижимую скорость ~890 токенами/с. Даже если агрессивно объединить пять ядер на слой, накладные расходы составят ~563 мкс, ограничивая скорость ~1 780 токенами/с. И это еще до учета других источников накладных расходов.
Превращение теоретической пропускной способности HBM в полезную пропускную способность модели — это вопрос систематического выявления и устранения источников потери микросекунд. Стандартные стеки теряют время на границах ядер, планировании CPU, синхронизации сетки, меж-GPU коммуникациях и неэффективном управлении кэшем.
04Подход Kog: совместное проектирование (Co-design) стека
Kog AI признает взаимозависимость трех слоев: архитектуры модели, рантайма и GPU-кода. В существующих движках эти слои настраиваются изолированно. Kog же проектирует их совместно для максимальной скорости в Kog Inference Engine. Критический путь декодирования не полагается на сторонние фреймворки, такие как PyTorch, Triton, CUTLASS, NCCL или ROCm CK. Вместо этого горячий путь реализован в низкоуровневом, вручную написанном GPU-коде (CUDA с PTX-вставками для NVIDIA, HIP с CDNA ISA-вставками для AMD) и использует собственные функции коммуникации KCCL.
Моноядро (Monokernel) и оптимизированный GPU-код
Генерация токенов в Kog выполняется как одна постоянная программа GPU, а не как последовательность ядер для каждой операции. Она декодирует всю последовательность за один проход без прерываний. Это моноядро устраняет все границы ядер, исключает планирование на стороне хоста и выборку токенов на CPU из критического пути. Оно позволяет гораздо теснее контролировать синхронизацию, коммуникацию, предварительную выборку (prefetch) и порядок выполнения. Реализовать такой подход сложнее, чем обычное слияние (fusion), так как одна статическая программа GPU должна охватывать MatMul, внимание, нормализацию, маршрутизацию, выборку и коммуникацию, каждая из которых имеет разные вычислительные формы и потребности в распределении регистров. Однако, когда это реализовано, полезная потоковая передача данных больше не прерывается границами ядер.
Коммуникации KCCL между GPU
Один запрос может использовать весь узел из 8 GPU только если модель распараллелена по GPU. Стандартное тензорное параллелизм требует двух (или трех для модели MoE) операций all-reduce в каждом слое. KCCL — это собственный слой коллективных коммуникаций Kog. Его цель — не пиковая агрегатная пропускная способность, а предсказуемая задержка в микросекундах, которую можно интегрировать в расписание моноядра, удерживая ее ниже 3 мкс, тогда как библиотеки вендоров тратят ~8 мкс. Код оптимизирован на уровне ассемблера для каждой целевой архитектуры GPU.
Архитектура Laneformer и отложенное тензорное параллелизм (DTP)
Архитектура модели Kog, Laneformer, инновационно спроектирована вокруг того, как узлы с несколькими GPU фактически перемещают данные. Ее ключевое нововведение — отложенное тензорное параллелизм (Delayed Tensor Parallelism, DTP). Это изменяет структуру зависимостей тензорного параллелизма так, что межустройственная коммуникация может быть перекрыта с полезными вычислениями, а не блокировать критический путь. Архитектура модели сама формируется структурой задержки много-GPU декодирования.
05Глубокое погружение: работа с топологией чиплетов AMD MI300X
Работа Kog с топологией чиплетов на GPU AMD MI300X является ярким примером их подхода к аппаратно-зависимому программному дизайну. Проблема заключается в том, что этот GPU содержит 8 вычислительных dies (XCD), расположенных поверх 4 I/O dies (IOD), и 8 стеков HBM за абстракцией унифицированной памяти. 2 XCD и 2 стека HBM подключены к каждому IOD. Коммуникация с модулями, подключенными к другому IOD, подвержена дополнительной задержке и узкому месту пропускной способности. Абстракция унифицированной памяти упрощает программирование, но скрывает неоднородные пути доступа: физический маршрут от XCD к месту в HBM меняет задержку достаточно сильно (до 150 нс) и вносит дисбаланс между вычислительными единицами.
Решение Kog: для синхронизации сетки и внутри-GPU коллективных операций они измерили задержку барьера на каждый XCD, сопоставили ее с топологией чиплетов, восстановили отображение физического адреса памяти на IOD и использовали эти знания для репликации буферов памяти в стеках HBM в контролируемых местах, так что каждый XCD опрашивает память из стека HBM, подключенного к своему I/O die. В результате барьер составляет около 600 нс и стабилен для всех вычислительных единиц. Тот же подход применяется на NVIDIA Hopper: на такой скорости каждый пакет GPU — это конкретная физическая система, а не абстрактный ускоритель.
06Что это значит на практике
Демонстрация Kog AI доказывает, что экстремально быстрое одиночное декодирование возможно на стандартных датацентровых GPU, которые уже есть у предприятий, включая ИИ-лаборатории и покупателей суверенного ИИ. Ограничивающим фактором всегда было то, что существующие программные стеки инференса не были оптимизированы для этого типа нагрузки. Открытие пути к GPU может обеспечить эту скорость без блокировки проприетарным кремнием.
Для разработчиков и компаний это означает, что можно достичь производительности, сопоставимой со специализированными картами для инференса, используя знакомое оборудование. Это снижает барьер входа для развертывания высокоскоростных ИИ-агентов. Хотя текущий технологический превью фокусируется на небольшой модели (2B параметров), оптимизированной для скорости, а не масштаба, принципы совместного проектирования применимы и к более крупным моделям. По мере появления новых GPU с увеличенной пропускной способностью памяти, эта архитектура позволит запускать еще более мощные модели с той же высокой скоростью генерации токенов, делая автономный ИИ по-настоящему интерактивным и полезным в реальном времени.
Источник: Hacker News ↗