标准GPU上实现实时LLM推理：单请求每秒3000个token

标准数据中心GPU上的实时LLM推理（单请求每秒3000个token）今天，Kog AI发布了Kog推理引擎（KIE）的技术预览版：在8× AMD MI300X GPU上，单请求每秒输出3000个token；

在8× NVIDIA H200（FP16，无推测解码）上，每秒输出2100个token。该预览版运行一个2B模型，接下来将以类似速度支持大型第三方MoE模型。

简而言之：我们证明，通过架构/引擎/内核协同设计来优化整个软件栈，GPU上的AI推理可以超快，达到专用推理硬件卡的速度水平。你可以在我们的实时编码游乐场中测试速度：playground.kog.ai。

这篇文章解释了为什么优化单请求LLM解码速度对AI智能体很重要；为什么这主要是一个内存带宽最大化问题，而非FLOPS问题；为什么标准数据中心GPU硬件的解码速度上限远高于当前推理栈因软件瓶颈所暴露的水平；

以及如何通过将模型架构、运行时和底层GPU代码协同设计为单个延迟优化的流水线来达到这一上限（即使在大型MoE模型上）。我们的公开技术预览旨在证明，在企业已经拥有的标准数据中心GPU（包括AI实验室和主权AI买家）上，可以实现极快的单请求解码。

限制因素在于现有推理软件栈未针对此类工作负载进行优化。

开辟GPU路径可以在不锁定专有芯片的情况下提供这种速度。你今天就可以测试我们的2B编码模型的速度。它很小，不是前沿模型（我们一直专注于速度而非规模），但在针对特定软件工程任务进行微调后仍然相当有能力。

自主智能体改变了什么：单请求解码速度现在成了关键指标推理基准通常将三个量混为一谈。总吞吐量（所有用户每秒生成的总token数）衡量服务器利用率，并奖励大批量。首token时间衡量预填充延迟。每请求解码速度衡量token生成速度，并定义用户在收到完整响应前等待的时间。

最后一个指标支配着每一次长串连续交互，而这正是AI智能体的瓶颈所在。智能体软件工程是一个顺序循环：检查、规划、编辑、测试、修改。每一步都依赖前一步。

工具调用时间有时占主导（因为测试必须运行，网页必须加载），但生成密集型步骤（规划、代码编写、跟踪分析、调试、重构）决定了循环速率。推理token在此基础上叠加。这些数字直接转化为产品和用户体验。

如果一个智能体需要在一个工作流中生成50,000个token，100 token/s大约需要八分钟；而3,000 token/s则不到二十秒。这种差异改变了可以构建的产品。

随着智能体变得更加自主，生产力前沿从单纯的智能转向智能乘以迭代速度。最好的智能体将在相同的挂钟时间内生成更多有用的token、进行更多推理、执行更多工具调用、测试和修改。这就是为什么Kog首先优化单请求延迟，也是为什么这个预览版以批大小1运行。

大批量确实重要，我们将在生产环境中支持它们，但它们回答的是不同的问题。那么，是什么限制了GPU上的解码速度？内存带宽是快速token生成的主要瓶颈（而GPU节点拥有充足的内存带宽）在批大小为1时，自回归解码主要由矩阵-向量运算主导。

对于每个生成的token，模型的所有活跃权重都必须通过GPU内部的内存层次结构，从HBM传输到计算处理器。因此，一阶界限为：token/s ≤ 有效内存带宽 / (β × 活跃权重字节数 + KV缓存)其中，当tile被重新加载或缓存重用不完美时，β可能大于1。

关键事实是，低批大小解码的算术强度非常低。在FP16下，一个模型权重占用两个字节，大约贡献一个乘加运算（两个FLOP），即约1 FLOP/字节。FP8将其提高到约2 FLOP/字节；FP4提高到约4。

然而，现代AI GPU每字节HBM带宽对应数百个峰值FLOP。例如，NVIDIA H200声称峰值平衡约为400 FLOP/字节。

因此，token生成速度在受FLOPS限制之前，先受内存带宽限制。这就是为什么内存带宽利用率（MBU）是单请求速度的核心指标，而非模型FLOP利用率（MFU）。

MFU可以通过将多个请求批处理在一起来改进，但这可能会增加每个用户经历的延迟，因为需要在GPU内传输更多KV缓存数据。对于批大小为1的解码，更多内存带宽等于每秒生成更多token。好消息是，GPU的内存带宽已经非常高。

一个8× NVIDIA H200节点提供约30.7 TB/s的有效聚合内存带宽（以每GPU理论4.8 TB/s的80%作为现实上限）。一个8× AMD MI300X节点在实践中达到约33.6 TB/s（假设每GPU可实现4.2 TB/s）。

以FP16下的2B参数稠密模型为例。

它大约有4 GB的活跃权重，因此如果仅权重就能完美流式传输（忽略KV缓存流量和潜在的β重载），光速上限将是：- 8× H200:30.7 TB/s ÷ 4 GB ≈ 7,700 token/s- 8× MI300X:33.6 TB/s ÷ 4 GB ≈ 8,

400 token/s我们再考虑几个例子：在批大小为1时，相同的速度结果适用于FP8下具有4B活跃参数的MoE；而FP4下32B活跃参数的MoE将被限制在约2,000 token/s。

因此，在延迟优先的推理栈中，一个有效的策略是在提供八个GPU HBM带宽的完整服务器节点上并行推理。

还应注意，即将在2026年下半年推出的下一代GPU（Rubin和MI450）将提供约4倍更高的内存带宽，从而允许以相同速度运行4倍更大的模型，或使用4倍更少的GPU（可能一到两个而非完整节点）。

这也有助于以相同速度支持更大的批大小。在本文末尾，我们将进一步探讨这一主题，以表明对于当前大型最先进的MoE模型，在数据中心GPU上应该可以实现每秒数千token的解码速度。不过，有一个问题。

这些界限没有考虑非GEMM操作停顿、GPU内同步、GPU间通信、指令开销等。关键问题是系统如何能够连续地通过HBM和缓存流式传输活跃模型参数而不中断。事实证明，让一个8-GPU服务器像一台连续内存流式机器一样运行确实是一个难题。

标准推理栈会损失宝贵的微秒在3,000 token/s时，每个token的预算大约为333微秒，包括所有层、LM头和采样。在一个25层模型上，每层仅多花1微秒就会消耗7.5%的时间预算！

通常的抽象栈——用高级语言或框架（如PyTorch或Triton）编写的模型图逻辑，降级为许多内核，由CPU运行时调度，在内核边界同步，并由框架级通信库协调——灵活、便于维护和集成，非常适合通用服务，包括最大化高批大小下的聚合吞吐量。

这是vLLM、SGLang和TensorRT-LLM等推理引擎上运行的模型通常采用的方法。然而，它与333微秒的token预算匹配度很差。一个简单的启动开销计算就能说明问题。

如果一次内核启动和清理成本约为4.5微秒（根据我们在AMD MI300X上的测量），每个Transformer层有十个内核，二十五层则每token产生1,125微秒的开销，这还不包括任何有用的计算。