Ограниченный памятью, но не пропускной способностью: физический разрыв вывода ИИ при декодировании LLM с размером пакета 1

Аннотация

Системы физического ИИ, включая роботов, автономные транспортные средства, воплощённые агенты и периферийные копилоты, часто выполняют вывод, отличающийся от облачного LLM-сервинга: однопоточная декодировка с размером пакета 1 (batch-1 autoregressive decode), где один робот, видеопоток или сессия пользователя ожидают следующего токена. Этот тип нагрузки обычно описывается как ограниченный пропускной способностью памяти. На каждом шаге декодирования потоково передаются веса модели и активный KV-кэш, поэтому задержка должна масштабироваться в соответствии с пиковой пропускной способностью HBM. Мы показываем, что это объяснение верно, но неполно. Мы измеряем декодирование с batch-1 для трёх GQA-трансформеров класса 7–8B на четырёх GPU NVIDIA: H100 SXM5, A100-80GB SXM4, L40S и L4. Мы оцениваем длины контекста от 2048 до 16384, получая 44 валидных ячейки в контролируемой конфигурации bf16 SDPA. Достигнутая доля пиковой пропускной способности HBM снижается по мере роста пиковой пропускной способности. Для базового случая Qwen-2.5-7B с ctx=2048 L4 достигает примерно 81% от аналитического минимального уровня использования памяти, в то время как H100 — лишь 27%. Декодирование в физическом ИИ является память-доминированным, но более быстрая память не приводит к пропорциональному снижению задержки. Мы проверяем недостающий фактор с помощью эксперимента A/B с CUDA Graphs. На H100 при ctx=2048 CUDA Graphs улучшает задержку декодирования в 1.259 раза по N=10 свежим сессиям с 95% бутстреп-доверительным интервалом от 1.253 до 1.267. На L4 то же вмешательство даёт лишь 1.028x. Это изолирует накладные расходы на стороне запуска, которые становятся заметны на быстрых GPU, но в основном остаются скрытыми на более медленных, ограниченных пропускной способностью памяти GPU. Практический вывод для развёртывания в том, что экономия памяти имеет значение только тогда, когда среда выполнения её реализует. На L4 декодирование в bf16 находится близко к минимальному уровню использования памяти, но распространённые квантованные подходы не дают ожидаемого четырёхкратного снижения трафика весов: bnb-nf4 достигает 59.36 мс/шаг, а AutoAWQ+Marlin — 45.24 мс/шаг при базалайне bf16 в 62.32 мс. GPTQ+ExLlamaV2 с Ada-оптимизированными int4-ядрами достигает 17.36 мс/шаг.

English

Physical AI systems, including robots, autonomous vehicles, embodied agents and edge copilots, often run a different inference workload from cloud LLM serving: single-stream, batch-1 autoregressive decode, where one robot, camera feed or user session waits on the next token. This workload is usually described as memory-bandwidth-bound. Each decode step streams model weights and the active KV cache, so latency should scale with peak HBM bandwidth. We show that this account is true but incomplete. We measure batch-1 decode for three 7 to 8B-class GQA transformers across four NVIDIA GPUs: H100 SXM5, A100-80GB SXM4, L40S and L4. We evaluate context lengths from 2048 to 16384, producing 44 valid cells under a controlled bf16 SDPA setup. The achieved fraction of peak HBM bandwidth falls as peak bandwidth rises. On the headline Qwen-2.5-7B ctx=2048 cell, an L4 reaches roughly 81 percent of its analytic memory floor, while an H100 reaches only 27 percent. Physical-AI decode is memory-dominated, but faster memory does not translate into proportional latency gains. We test the missing term with a CUDA Graphs A/B experiment. On H100 at ctx=2048, CUDA Graphs improves decode latency by 1.259x across N=10 fresh sessions, with a 95 percent bootstrap confidence interval of 1.253 to 1.267. On L4, the same intervention gives only 1.028x. This isolates a launch-side overhead that becomes visible on fast GPUs but remains mostly hidden on slower, bandwidth-bound GPUs. The deployment implication is that memory savings matter only when the runtime realises them. On L4, bf16 decode sits close to the memory floor, but common quantised paths do not recover the expected 4x weight-traffic reduction: bnb-nf4 reaches 59.36 ms/step and AutoAWQ+Marlin reaches 45.24 ms/step from a 62.32 ms bf16 baseline. GPTQ+ExLlamaV2, with Ada-tuned int4 kernels, reaches 17.36 ms/step.