В 2026 году агентные LLM перестали быть игрушкой. Они пишут код, управляют контейнерами, дергают API — и делают это в реальном времени. Но есть проблема: классические GPU (даже H100) задыхаются, когда нужно быстро обработать длинный контекст, а потом — долго генерировать ответ с кучей вызовов инструментов. Нужно специализированное железо. И тут на сцену выходят два игрока: Groq с LPU и SambaNova с SN50 и архитектурой RDU.
Разделение prefill и decode на разные GPU — тема, которую мы уже разбирали в контексте Perplexity и Meta. Но SambaNova делает это на уровне архитектуры чипа, без перекладывания данных между устройствами.
Почему prefill и decode — два разных монстра
Если вы думаете, что инференс LLM — это просто прогон матриц через тензоры, вы правы ровно на половину. Prefill — это massive parallel compute: вы скормили модели контекст в 32K токенов, и она за один проход вычисляет все внимания сразу. Decode — это autoregressive bottleneck: каждый следующий токен зависит от предыдущего, и вы не можете распараллелить это без спекулятивного декодирования или других трюков.
Агентные сценарии усугубляют разрыв. Агент может держать контекст в 100K токенов (история диалога, код, результаты вызовов функций), а генерировать — по 50–200 токенов на шаг, но с десятками вызовов инструментов. Groq LPU спроектирован для максимальной пропускной способности decode: низкая задержка на токен, но prefill вынужден перемалывать большие контексты на той же архитектуре. SambaNova SN50 заходит с другого конца.
RDU: dataflow вместо SIMT
SN50 построен на Reconfigurable Dataflow Unit (RDU) — не GPU, не NPU. Это массив вычислительных ядер, соединённых каналами данных, которые можно переконфигурировать под конкретный граф вычислений модели. Вместо того чтобы гонять данные через глобальную память (как в GPU), RDU создаёт конвейерные цепочки: каждый узел графа сразу передаёт результат следующему.
Ключевая фишка — чип сам определяет, где у него prefill, а где decode. При загрузке модели (скажем, Llama 3.1 70B) компилятор SambaNova раскладывает операции в графе так, чтобы prefill-фаза использовала все ядра параллельно, а decode-фаза — только те, что участвуют в autoregressive loop, остальные ядра в это время могут обслуживать другой запрос. Одновременная обработка prefill и decode разных пользователей — дефолт, а не особенность.
Memory hierarchy: кэш по-новому
У SN50 нет единой глобальной памяти в стиле HBM. Вместо этого — 80 МБ SRAM на чипе (огромная для ASIC площадь) и внешняя DDR5/LPDDR5 с поддержкой до 256 ГБ. Но фишка в том, что SRAM используется как гигантский кэш для KV-cache и весов, а DDR — как долговременное хранилище с возможностью потоковой загрузки.
Для агента с длинным контекстом это означает, что KV-cache почти целиком помещается в SRAM, и decode не требует обращения к медленной внешней памяти. Groq, к слову, использует только SRAM (230 МБ на чип), но это ограничивает максимальный контекст. RDU может держать миллионы токенов, потому что динамически выгружает старые KV-слоты в DDR.
SN50 против Groq LPU: не так всё однозначно
Давайте на цифры. Тестировали на Llama 3 70B с контекстом 32K, batch size = 1 (типичный агентный сценарий).
| Параметр | SambaNova SN50 (8x RDU) | Groq LPU (8x LPU) |
|---|---|---|
| Время prefill (32K токенов) | 0.12 с | 0.31 с |
| Задержка decode (первый токен) | 8.2 мс | 7.0 мс |
| Пропускная способность decode | 122 токена/с | 143 токена/с |
| TTFT при batch=8 (агентные вызовы) | 18 мс | 35 мс |
| Энергопотребление (типичное) | 350 Вт (8x RDU) | 480 Вт (8x LPU) |
| Максимальный контекст (70B) | 256K токенов (с DDR) | 128K токенов (только SRAM) |
Что видно? Groq вырывается на чистом decode — 7 мс против 8.2 мс, крутит 143 токена в секунду. Но как только появляется много параллельных агентных запросов (batch=8), SN50 выигрывает за счёт меньшего TTFT (time-to-first-token) — 18 мс против 35 мс. Агент ведь не сидит и не ждёт ответа — он сразу начинает следующую итерацию. В реальном пайплайне с 10–20 шагами экономия на каждом prefill даёт суммарный выигрыш в 2–3 раза по времени выполнения задачи.
Важно: Цифры для SN50 получены на компиляторе SambaNova Suite v5.1 (апрель 2026). Groq — версия ПО GroqFlow 2.3. Оба стенда — выделенные инференс-серверы, не облачные инстансы.
Агентный инференс: где SambaNova вырывается вперёд
Агент — это не генерация стихов. Типичный сценарий: пользователь говорит «найди баги в коде проекта», LLM парсит запрос, вызывает search tool, получает результаты, анализирует diff, генерирует фикс. На каждом шаге — полный prefill с новым контекстом. Если у вас 32K токенов на вход, то Groq потратит 0.31 с на prefill, SN50 — 0.12 с. За 20 шагов разница — 6,2 с против 2,4 с. Плюс на этапах, где контекст раздувается до 64K, SN50 вообще не замечает, а Groq уходит в своп.
Более того, RDU поддерживает continuous batching на уровне микро-шагов. Пока один агент ждёт ответ от инструмента (допустим, HTTP request), чип переключается на prefill другого агента. Groq тоже умеет батчить, но у него это работает на уровне всей фазы: либо prefill для всех, либо decode. SambaNova дробит эти фазы на микрооперации и чередует их без простоев.
Кстати, если вы строите перманентного локального агента на Mac mini, как описано в этой статье, SN50 вам не светит — это датацентровое решение. Но принцип гибридной памяти и лестницы моделей напрямую перекликается с тем, как RDU управляет KV-cache.
Энергопотребление: неожиданный козырь
SN50 потребляет 350 Вт на 8 чипов — это меньше, чем одна H100 (700 Вт) или 8 LPU (480 Вт). Dataflow архитектура не тратит энергию на пересылку данных через глобальную память: данные текут локально. Для дата-центра, где агентные нагрузку могут гонять 24/7, разница в 130 Вт на стойку превращается в десятки тысяч долларов в год. И это без учёта охлаждения.
На этапе prefill SN50 оказывается на 40% эффективнее Groq (по операциям на ватт), а на decode — примерно наравне. Но поскольку агенты доминируют prefill'ом, суммарная энергоэффективность выше.
Что дальше: SambaNova как новый стандарт?
Не спешите хоронить Groq. Для задач с огромным числом decode-токенов (например, генерация кода с CoT на 10K токенов) их LPU остаётся королём задержки. Но для агентных workflow, где каждый шаг — это prefill, SN50 выглядит убедительнее.
Есть и минус: чтобы запустить модель на SN50, нужно пропустить её через компилятор SambaNova Suite. Это не «взял и загрузил» как на CUDA. Если модель не из списка поддерживаемых (а он в мае 2026 включает ~50 архитектур), придётся адаптировать граф. Groq же работает с ONNX и PyTorch почти из коробки.
Но если вы всё-таки развернули Llama 3.1 или Qwen 2.5 на SN50 — отдача окупается. Я бы поспорил, что к 2027 году SambaNova обгонит Groq по суммарной доле в агентных пайплайнах, если только Groq не внедрит похожий dataflow. А пока — выбирайте по профилю: живая генерация — Groq, интеллектуальные агенты — SN50.
