标准GPU上的实时LLM推理：每请求3k tokens/秒

# 在标准数据中心 GPU 上实现实时 LLM 推理（单请求 3,000 tokens/s） 来源：https://blog.kog.ai/real-time-llm-inference-on-standard-gpus-3-000-tokens-s-per-request/ 今天，Kog AI 发布了 Kog Inference Engine (KIE) 的技术预览版：在 8× AMD MI300X GPU 上单请求输出 3,000 tokens/s，在 8× NVIDIA H200 上为 2,100 tokens/s（FP16，无投机解码）。该预览版运行一个 2B 模型，随后将以类似速度支持大型第三方 MoE 模型。 在标准数据中心 GPU 上实现实时 LLM 推理（单请求 3,000 tokens/s）（完整基准测试详情见下文）> **TL;DR：** 我们展示了 GPU 上的 AI 推理可以极快，通过架构/引擎/内核协同设计优化整个软件栈，可达到专用推理硬件卡的速度。在我们的实时编程 playground 中测试速度：playground.kog.ai (https://playground.kog.ai/?ref=blog.kog.ai)。 本文解释了为什么针对**单请求 LLM 解码速度**的优化对 AI 智能体至关重要；为什么这主要是一个**内存带宽**最大化问题，而非 FLOPS 问题；为什么**标准数据中心 GPU** 硬件的解码速度上限远高于当前推理栈因**软件瓶颈**所暴露的水平；以及如何通过**协同设计**模型架构、运行时和底层 GPU 代码（作为一个延迟优化的单一流水线）来达到该上限（即使在大型 MoE 模型上）。 我们的公开技术预览旨在证明，在企业已拥有的标准数据中心 GPU（包括 AI 实验室和主权 AI 买家）上，极快的单请求解码是可能的。限制因素在于现有推理软件栈未针对此类工作负载进行优化。开辟 GPU 路径可以在无需受限于专有芯片的情况下提供这种速度。 您现在就可以测试我们的 2B 编码模型的速度 (https://playground.kog.ai/?ref=blog.kog.ai)。它很小，不是前沿模型（我们专注于速度而非规模），但针对特定软件工程任务进行微调后仍然相当强大。 ## 自主智能体带来的变化：单请求解码速度现在是最重要的指标 推理基准测试通常会混用三个量。聚合吞吐量（在所有用户中每秒生成的总 token 数）衡量服务器利用率，有利于大批次。首 token 时间衡量预填充延迟。**单请求解码速度**衡量 token 生成速率，并决定一个用户等待完整响应的时间。最后一个量主导所有长串行交互，而它正是 AI 智能体的瓶颈所在。 智能体软件工程是一个**顺序循环**：检查、规划、编辑、测试、修改。每一步都依赖于前一步。工具时间有时占主导（因为测试需要运行，网页需要加载），但生成密集步骤（规划、代码编写、追踪分析、调试、重构）决定了循环速率。而推理 token 会叠加其上。 这些数字直接影响产品和用户体验。如果一个智能体需要在工作流中生成 50,000 个 token，100 tokens/s 大约需要八分钟；3,000 tokens/s 则不到二十秒。这种差异决定了能够构建的产品。 随着智能体变得更加自主，**生产力的前沿从单纯的智能转向智能 × 迭代速度**。最好的智能体将在相同的墙钟预算内生成更多有用的 token，进行更多推理，执行更多的工具调用、测试和修改。 这就是为什么 Kog 首先优化单请求延迟，以及为什么本预览版以批大小 1 运行。大批次确实重要，我们将在生产环境中支持它们，但它们解决的是不同的问题。 **但 GPU 上的解码速度受到什么限制？** ## 内存带宽是快速 token 生成的主要瓶颈（而 GPU 节点拥有充足的内存带宽） 在批大小 1 时，自回归解码主要由矩阵-向量操作主导。对于每个生成的 token，模型的所有活跃权重必须通过 GPU 内部的内存层次结构从 HBM 移动到计算处理器。因此，一阶界限为： `` tokens/s ≤ effective_memory_bandwidth / (β × active_weight_bytes + KV cache) `` 其中当 tiles 被重新加载或缓存重用不完美时，β 可能大于 1。 关键事实是，低批次解码的算术强度非常低。在 FP16 中，一个模型权重占用两个字节，贡献大约一次乘法-加法（两个 FLOP），即大约**1 FLOP/字节**。FP8 将其提升至约 2 FLOP/字节；FP4 约为 4。然而，现代 AI GPU 每字节 HBM 带宽对应数百个峰值 FLOP。例如，NVIDIA 的 H200 声称的峰值平衡约为 400 FLOP/字节。因此，token 生成速度受限于内存带宽，而非 FLOPS。 这就是为什么**内存带宽利用率 (MBU)** 是单请求速度的核心指标，而不是模型 FLOP 利用率 (MFU)。MFU 可以通过将多个请求一起批处理来改善，但这可能会增加每个用户经历的延迟，因为需要将更多 KV 缓存数据流式传输到 GPU 内部。 对于批大小为 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 tokens/s** - 8× MI300X：33.6 TB/s ÷ 4 GB ≈**8,400 tokens/s** 再考虑几个例子：在批大小 1 时，相同的速度结果适用于 FP8 下 4B 活跃参数的 MoE；而 FP4 下 32B 活跃参数的 MoE 将被限制在约 2,000 tokens/s。 因此，在延迟优先的推理栈中，一个有效的策略是**在完整服务器节点上并行化推理**，提供八个 GPU 的 HBM 带宽。 还应注意，即将于 2026 年下半年推出的下一代 GPU（Rubin 和 MI450）将提供约 4 倍更高的内存带宽，从而允许以相同速度运行 4 倍更大的模型，或使用 4 倍更少的 GPU（可能只需一或两块而非完整节点）。这也有助于以相同速度支持更大的批大小。在本文末尾，我们将更深入地讨论这个话题，以说明对于当前大型最先进 MoE 模型，数据中心 GPU 上应该能达到每秒数千 token 的解码速度。 不过有一个陷阱：这些界限没有考虑非 GEMM 操作停顿、GPU 内部同步、GPU 间通信、指令开销等。关键问题在于系统能够如何不间断地通过 HBM 和缓存流式传输模型活跃参数。事实证明，**让一个 8-GPU 服务器像一台连续的内存流式机器一样运行确实是一个难题。** ## 标准推理栈在哪些地方损失了宝贵的微秒 在 3,000 tokens/s 时，每个 token 的预算约为**333 微秒**，包括所有层、LM head 和采样。对于一个 25 层的模型，每层多花 1 微秒就消耗了 7.5% 的时间预算！ 通常的抽象栈——用高级语言或框架（如 PyTorch 或 Triton）编写的模型图逻辑，降级为许多内核，由 CPU 运行时调度，在内核边界同步，并通过框架级通信库进行中介——灵活、便于维护和集成，并且非常适合通用服务，包括在高批大小时最大化聚合吞吐量。这是通常在 vLLM、SGLang 和 TensorRT-LLM 等推理引擎上运行的模型所采用的方法。**然而，它难以适应 333 微秒的 token 预算。** 简单的启动开销计算说明了问题。如果内核启动和清理大约需要 4.5 μs（根据我们在 AMD MI300X 上的测量），那么每层十个内核，在二十五层上每个 token 在开始任何有用工作之前就会产生 **1,125 μs 的开销**，从而将可达到的速度限制在约 890 tokens/s。即使每层只使用五个激进融合的内核，仍然会产生约 563 μs 的开销，将速度限制在约 1,780 tokens/s。而 **这还没有考虑其他来源的开销，它们会叠加其上。** 因此，将理论 HBM 带宽转化为有用的模型带宽，关键在于系统性地识别并消除微秒级损失的来源： | 标准推理栈 | 微秒损失 | Kog 实现 | |-----------|---------|---------| | **内核边界** | 启动、清理、缓存回写、调度器往返增加开销并中断内存流。 | 持久单内核：一个驻留在 GPU 的程序处理整个解码路径。 | | **CPU 调度与采样** | 主机端逻辑引入昂贵的 GPU-CPU 通信和执行延迟。 | 全 GPU 驻留逻辑，包括 LM head 采样在关键执行路径上。可选的零开销异步 CPU 逻辑用于输出流和 EOS 检测。 | | **网格同步** | 矩阵乘法、注意力、归一化、采样和路由都需要全 GPU 同步和通信，每次操作成本数微秒。 | 优化拓扑感知的 GPU 内网格同步及 AllGather/AllReduce 原语；在 MI300X 上小负载的 barrier 约 600 ns。 | | **GPU 间集合通信** | 张量并行在每层的关键路径中插入两到三次 AllReduce 操作。 | 优化的 KCCL 通信原语，AllReduce 延迟低于 3 μs；Kog Laneformer 模型架构中的延迟张量并行 (DTP) 通信。 | | **统一内存拓扑** | 统一内存实际上并非物理均匀：缓存、HBM、IOD chiplets 和 XCD 位置都会影响延迟。 | 拓扑感知的内存访问，包括 IOD 感知的缓冲区放置、轮询和同步。 | | **权重重新加载** | 不完美的缓存管理和 MatMul 期间的 tile 重用导致 β 升高。 | 缓存和寄存器感知的内核，内存布局针对低批次大小优化。 | | **非 GEMM 工作** | softmax、归一化、路由、采样等计算会暂停内存流。 | 单内核融合预取，跨计算部分重叠。 | 简而言之，**标准推理栈在处处浪费微秒**。这就是可用 HBM 带宽消失的原因。 ## Kog 栈通过协同设计引擎、GPU 代码和模型架构来回收这些微秒 推理系统是分层的：模型位于运行时之上，运行时位于 GPU 内核之上。模型架构约束了通信调度和计算图的结构；运行时控制调度和内存流；GPU 代码决定了同步、缓存管理和拓扑是否以符合预算的方式管理。在现有推理引擎中，这些层大多是孤立调优的。 Kog 充分认识到这三层之间的相互依赖关系，并在 Kog Inference Engine 中协同设计它们以实现最大速度。 这就是为什么我们的关键解码路径不依赖第三方框架、库和抽象（如 PyTorch、Triton、CUTLASS、NCCL、ROCm CK、AITER 或 RCCL）。这些是非常有价值的通用工具，但我们的速度目标更窄：批大小 1（或低批大小）、完整节点、低至中等活跃参数数量，每个 token 预算只有几百微秒。热路径使用低层手工编写的 GPU 代码（NVIDIA 上为 CUDA 和 PTX 内联汇编，AMD 上为 HIP 和 CDNA ISA 内联汇编）实现，并使用我们自己的 KCCL 通信函数进行集合操作。 以下是我们的关键创新总结： - **单内核运行时与优化的 GPU 代码。**我们的 token 生成作为一个持久的 GPU 程序运行，而不是一系列每操作内核。它一次性解码整个序列而不中断。这个单内核消除了所有内核边界，从关键路径中移除了主机端调度和 CPU 端 token 采样，并让我们比传统多内核运行时更严格地控制同步、通信、预取以及执行顺序和调度。这种实现比普通的融合困难得多，因为同一个静态 GPU 程序必须覆盖 MatMul、注意力、归一化、路由、采样和通信，它们各自具有不同的计算形状、缓冲区和寄存器分配需求以及同步。然而，一旦成功实现，有用的内存流不再被内核边界反复打断。有关我们低层 GPU 工程优化的更多详细信息，请深入阅读 Kog 单内核博客文章 (https://blog.kog.ai/building-a-single-kernel-latency-optimized-llm-inference-engine-on-amd-mi300x-gpus)。 - **KCCL 跨 GPU 通信。**只有将模型并行化到多个 GPU 上，才能让单个请求使用完整的 8-GPU 节点。标准张量并行需要在每层进行两次（或对于 MoE 模型是三次）全规约同步；当层数足够多时，避免在每个集合操作上花费过多微秒至关重要。KCCL 是 Kog 针对这种场景的自定义集合通信层。其目标不是峰值聚合带宽，而是可预测的微秒级延迟，能够集成到单内核调度中，使其保持在 3 μs 以下，而供应商库可能需要约 8 μs。代码本身针对每个目标 GPU 架构、通信链路特性和缓冲区大小在汇编级别进行了调优。 - **Laneformer 模型架构。**Kog 的 Laneformer 模型架构是一项围绕多 GPU 节点实际数据移动方式的创新设计。其核心创新是延迟张量并行（DTP，在我们的博客文章 (https://blog.kog.ai/delayed-tensor-parallelism-for-faster-transformer-inference) 中有详细解释），它改变了张量并行解码的依赖结构，使得跨设备通信可以与有用计算重叠，而不是阻塞关键路径。模型架构本身由多 GPU 解码的延迟结构塑造。 值得讨论一下我们在 AMD MI300X GPU 上的 chiplet 拓扑工作，作为我们硬件感知软件设计方法的一个例子： - *问题：*该 GPU 包含 8 个 XCD（计算芯片），放置在 4 个 I/O 芯片 (IOD) 之上，以及 8 个 HBM 堆栈，位于统一内存抽象之后。每个 IOD 连接 2 个 XCD 和 2 个 HBM 堆栈；与不同 IOD 上的模块通信会遭受额外的延迟和带宽瓶颈。统一内存抽象有利于编程简单性，但它隐藏了非均匀访问路径：在我们的测量中，从 XCD 到 HBM 位置的物理路径会改变延迟（可达 150 ns），并在计算单元之间引入偏差。 - *我们的解决方案：*对于网格同步和 GPU 内集合操作，我们测量了每个 XCD 的 barrier 延迟，并将其映射到 chiplet 拓扑，恢复了物理内存地址到 IOD 的映射，并利用这一知识将内存缓冲区复制到受控位置的 HBM 堆栈上，使得每个 XCD 轮询来自其自身 I/O 芯片所连接的 HBM 堆栈的内存。由此产生的 barrier 约为 600 ns，并且在计算单元之间稳定。 同样的工程方法也适用于 NVIDIA Hopper：在这种速度下，每个 GPU 包