推理性能突破：消费级 GPU 达成 3k tokens/sec

简而言之：我们证明了，通过对整个软件栈进行架构、引擎与内核的协同设计和优化，GPU 上的 AI 推理可以快到惊人，达到专用推理硬件卡的速度级别。你可以在我们的在线编程体验环境中测试这一速度：playground.kog.ai。

本文将解释：为什么优化单请求的 LLM 解码速度对 AI 智能体至关重要；为什么这主要是一个最大化内存带宽的问题，而非 FLOPS 问题；为什么受软件瓶颈影响，标准数据中心 GPU 硬件的解码速度上限远高于当前推理栈所能呈现的水平；以及如何通过将模型架构、运行时和底层 GPU 代码协同设计为一条针对延迟优化的完整流水线，达到这一上限——即使是在大型 MoE 模型上。

我们的公开技术预览旨在证明：企业已经拥有的标准数据中心 GPU——包括 AI 实验室和主权 AI 采购方所使用的 GPU——完全可以实现极快的单请求解码。一直以来，限制这一能力的因素在于，现有推理软件栈并未针对这类工作负载进行优化。打通 GPU 这条路径，有望在不被专有芯片锁定的情况下实现这种速度。

现在，你可以测试我们的 2B 编程模型。它规模较小，也不是前沿模型——我们一直专注于速度而非规模——但经过针对特定软件工程任务的微调后，它仍然具备相当不错的能力。

自主智能体带来的变化：单请求解码速度成为如今真正重要的指标

推理基准测试通常混合了三个不同的指标。聚合吞吐量，即所有用户每秒生成的 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)

当计算块被重复加载或缓存复用不理想时，β 可能大于 1。

关键在于，低批量解码的算术强度非常低。在 FP16 中，一个模型权重占用两个字节，并贡献大约一次乘加运算（两个 FLOP），即约 1 FLOP/byte。FP8 将其提高到约 2 FLOPs/byte，FP4 则提高到约 4 FLOPs/byte。然而，现代 AI GPU 的峰值计算能力相对于 HBM 带宽可达到每字节数百个 FLOP。例如，NVIDIA H200 声称其峰值平衡点约为 400 FLOPs/byte。因此，在受到 FLOPS 限制之前，token 生成速度就已经先受到内存带宽的约束。

这就是为什么内存带宽利用率（Memory Bandwidth Utilization，MBU）才是单请求速度的核心指标，而不是模型 FLOP 利用率（Model FLOP Utilization，MFU）。通过将多个请求组成批次，仍然可以提高 MFU，但由于 GPU 内部需要传输更多 KV cache 数据，这也可能增加每个用户感受到的延迟。

对于批大小为 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 cache 流量和潜在的 β 重载——其理论极限上界为：

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——可能只需一两块 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 时间预算。

一个简单的启动开销计算就能说明问题。根据我们在 AMD MI300X 上的测量，如果一次内核启动和清理大约耗时 4.5 µs，那么每个 Transformer 层使用十个内核、总计二十五层，就会在任何有效计算开始之前，为每个 token 带来 1,125 µs 的开销，从而将可达到的速度限制在约 890 tokens/s。即便经过激进融合，将每层减少到五个内核，仍会产生约 563 µs 的开销，把速度限制在约 1,780 tokens/s。而这还没有考虑其他会进一步叠加的开销来源。

因此，要把理论 HBM 带宽转化为有效的模型带宽，就必须系统性地识别并消除所有造成微秒级损失的来源：

简而言之，标准推理栈在各个环节都会浪费微秒。可用的 HBM 带宽正是在这些地方消失的。

Kog 通过协同设计引擎、GPU 代码和模型架构，夺回这些微秒

推理系统采用分层结构：模型位于运行时之上，运行时又位于 GPU 内核之上。模型架构约束着通信调度和计算图的结构；运行时控制调度和内存流式传输；GPU 代码则决定同步、缓存管理和拓扑结构能否以符合时间预算的方式进行管理。在现有推理引擎中，这些层通常主要是彼此独立地进行调优。

Kog 充分认识到这三个层次之间的相互依赖关系，并在 Kog Inference Engine 中对它们进行协同设计，以实现最高速度。

这就是为什么我们的关键解码路径不依赖第三方框架、库和抽象层（如 PyTorch、Triton、CUTLASS、NCCL、ROCm CK、AITER 或 RCCL）。它们都是非常有价值的通用工具，但我们的速度目标更加聚焦：批大小为 1（或较小的批大小）、使用完整节点、较低和中等的激活参数量，并且每个 token 只有几百微秒的时间预算。热路径使用手工编写的底层 GPU 代码实现（NVIDIA 平台使用带 PTX 内联汇编的 CUDA，AMD 平台使用带 CDNA ISA 内联汇编的 HIP），并使用我们自己的 KCCL 通信函数执行集合通信。

以下是我们部分关键创新的概要：

Monokernel 运行时与优化的 GPU 代码。 我们的 token 生成过程作为一个持久化 GPU 程序运行，而不是由一系列逐操作内核组成。它不间断地一次完成整个序列的解码。这个 monokernel 消除了所有内核边界，将主机端调度和 CPU 端 token 采样移出关键路径，并使我们能够比传统的多内核运行时更严格地控制同步、通信、预取，以及执行顺序与调度。与普通的算子融合相比，这种方法的实现难度要高得多，因为同一个静态 GPU 程序必须涵盖 MatMul、注意力、归一化、路由、采样和通信，而它们各自具有不同的计算形态、缓冲区与寄存器分配需求，以及同步方式。然而，一旦成功实现，有效的内存流式传输便不会再被内核边界反复中断。有关我们的底层 GPU 工程优化，请参阅 Kog monokernel 博客文章中的深入解析。

KCCL GPU 间通信。 只有将模型并行分布到多个 GPU 上，单个请求才能使用完整的 8 GPU 节点。标准张量并行要求每一层执行两次 all-reduce 同步（对于 MoE 模型则是三次）；当层数足够多时，避免每次集合通信耗费过多微秒至关重要。KCCL 是 Kog 针对此类场景定制的集合通信层。它追求的不是峰值聚合带宽，而是可预测的微秒级延迟，使其能够集成到 monokernel 调度中：将延迟控制在 3 µs 以内，而供应商库大约需要 8 µs。代码本身针对每一种目标 GPU 架构、通信链路特性和缓冲区大小进行了汇编级调优。

Laneformer 模型架构。 Kog 的 Laneformer 模型架构是一项围绕多 GPU 节点实际数据传输方式构建的创新设计。它的核心创新是延迟张量并行（Delayed Tensor Parallelism，DTP；我们的博客文章对此进行了详细说明），这种方法改变了张量并行解码的依赖结构，使跨设备通信能够与有效计算重叠，而不是阻塞关键路径。模型架构本身就是根据多 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 的屏障延迟，并将其映射到 chiplet 拓扑；随后还原了物理内存地址到 IOD 的映射关系，并利用这些信息，在位置可控的 HBM 堆栈上复制内存缓冲区，使每个 XCD 都能轮询连接到其自身 I/O 裸片的 HBM 堆栈中的内存。最终得到的屏障延迟约为 600 ns，并且在不同计算单元之间保持稳定。

同样的工程方法也适用于 NVIDIA Hopper：在这样的速度下，每个 GPU 封装都是一个具体的物理系统，而不是抽象的加速器。

通过深入研究底层硬件机制，并据此调整我们的推理引擎，我们可以挖掘出使用更高级语言、库和框架时不可能获得的额外微秒级优化空间。

我们今天发布的内容

我们开放 Kog Inference Engine 达到每请求 3,000 tokens/s 速度的技术预览。用户可以在实时体验环境中运行上述基准测试所使用的 Laneformer 2B 模型，配置也完全相同：单个 8× MI300X 节点，批大小为 1。

请注意，此预览旨在让大家直观感受速度，而不是提供一个前沿的编程助手。我们的模型在 HumanEval 编程基准测试中得分为 50%，考虑到它的规模，这实际上相当不错（Qwen2.5-Coder 的 1.5B 版本为 43.9%，3B 版本为 52.4%）；在针对特定软件工程任务进行微调后，它的表现尤其出色。它采用普通的自回归解码，序列长度为 4096（长上下文扩展正在进行中，目标是将其扩展至 128k）。我们使用 NVIDIA Nemotron v1 和 v2 数据集，在由 256 个 H100 GPU 组成的集群上，使用 6T tokens 对其进行了预训练。

需要特别强调的是，除了上面介绍的方法外，我们没有使用其他优化技巧：没有量化、没有推测解码、没有剪枝、没有提前退出、没有 KV 缓存压缩，等等。在未来的路线图中，我们计划实现这类唾手可得的优化以及其他技术，以便支持更大的模型，并在相近速度下实现批处理（或者只是进一步提升速度）。

在单个 8× NVIDIA H200 节点上，我们的引擎目前可以达到每请求 2,100 tokens/s。我们预计在不久的将来追平 AMD GPU 的速度。

接下来，让我们看看如何扩展这项技术预览，以加速最新的前沿 AI 模型。

扩展至大型第三方 MoE 模型

下一个工程步骤，是将同一套技术栈应用于更大的第三方开放权重模型（稠密模型和 MoE 模型），并在适用时采用 FP8/FP4 量化和多 token 预测技术（如推测解码）。

我们的扩展依据是每次前向传播所移动的激活参数字节数，而不是总参数量。对于稠密模型，激活参数基本上就是完整模型。对于 MoE，关键在于每个生成 token 所对应的激活参数量，它可以远小于总参数量（以下数据均基于批大小为 1）：

• Qwen3-Coder-Next：总参数量 80B，激活参数量 3B。

• GPT-OSS-120B：总参数量 117B，激活参数量 5.1B。

• DeepSeek-V4-Flash：总参数量 284B，激活参数量 13B。

• Kimi-K2.6：总参数量 1.04T，激活参数量 32B。

• Qwen3-Coder-480B-A35B：总参数量 480B，激活参数量 35B。

• DeepSeek-V4-Pro：总参数量 1.6T，激活参数量 49B。

在单个 8 GPU 节点上，按理论聚合带宽的 80% 计算，仅考虑带宽的一阶速度上限如下（数值单位为每秒输出 token 数）：

这些是上限值，并不代表必然能够达到的实际生产速度。如前文所述，实际速度还需要考虑每层由内核启动、KV 缓存流量、β、非 GEMM 工作、路由、同步和 GPU 间集合通信等因素造成的减速。与传统推理技术栈相比，这正是 Kog 推理引擎的优势所在。

不过，这里还有一个显而易见的问题：对于第三方模型，由于模型架构已经固定，我们无法使用延迟张量并行。我们必须使用标准张量并行，因此每一层都要为 GPU 间的 all-reduce 通信承担三次延迟开销。幸运的是，凭借 KCCL 集合通信的速度和我们的 monokernel 设计，我们可以在 GPU 通信期间，继续将模型权重流式传输至计算单元和内存缓存。这并不能完全消除通信的影响，但可以显著降低影响（请记住，我们受限于内存而非计算：因此，即使计算短暂停顿，我们也能很轻松地追赶上来——真正的限制因素是用于提取模型权重的共享内存缓冲区、寄存器文件和缓存的大小）。

现在，为了预测实际数据，我们可以依据这样一个事实：我们的技术预览实现了约 36% 的 MBU。保守地假设我们无法进一步提高这一数值（尽管我们坚信能够做到），并且不考虑潜在的量化或多 token 预测技巧，那么上表中的数值应除以约 2.8，从而得到使用现有技术时，在前沿 MoE 模型上可以合理预期的实际输出速度估算值（单位为 tokens/s）：

当然，这些只是粗略估算，实际数据会有所不同。但核心思路依然成立。

随着 GPU HBM 带宽增长，以及 Kog 技术栈——包括运行时、内核和集合通信等——不断成熟，我们预计大型前沿 MoE 模型在标准数据中心 GPU 上的速度将进入每请求 1,000–5,000 tokens/s 的区间。

专用推理硬件建立了单请求生成速度作为一个独立的基础设施类别，随着自主 AI 智能体的兴起，这个类别将变得越来越重要。

直到现在，标准数据中心 GPU 还无法在这个类别中竞争；不是因为硬件限制，而是因为在它们之上构建的软件推理栈的架构方式。

我们的公开预览版展示了一个标准的 8-GPU 节点可以在 2B 编码模型上以批大小 1 每秒生成 3,000 个输出 token，无需量化或推测解码。我们通过将持久化运行时、低级 GPU 代码和模型架构视为一个统一系统来实现这一点。

更广泛的收获是，这不仅限于小型定制模型。随着可用 HBM 带宽的增长以及 Kog 栈的逐步完善，我们期望相同的性能能够扩展到当今 AI 智能体前沿的大型开源混合专家模型。

深入探索

• 在 Kog Playground 中测试我们的速度

• 来自我们 LLM 架构研究团队关于延迟张量并行性的博客文章

• 来自我们 GPU 工程团队关于单内核运行时的技术深潜，包括针对 AMD MI300X GPU 的低级 GPU 优化

• 设计合作伙伴计划：适用于正在构建编码智能体、应用生成系统或其他智能体工作流的团队，在这些场景下迭代速度已经成为竞争瓶颈。我们很乐意讨论，欢迎通过我们的网站与我们联系。

Kog 是一家总部位于巴黎的 AI 基础设施初创公司，致力于为 AI 智能体构建实时推理引擎，具备创新的低级 GPU 工程和 LLM 架构研究能力。公司由 Gaël Delalleau 于 2023 年创立——他是 École Polytechnique 工程师，职业生涯横跨网络安全研究和高性能 GPU 工作——Kog 在巴黎运营，拥有 11 人团队，包括 10 名工程师和研究人员（其中 5 位博士）。

Kog 从 Varsity VC 和法国 BPI 深科技计划融资 500 万美元，并在 2025 年 10 月获得 French Tech 2030 标签，这是法国政府授予为战略部门做出贡献的特定国家深科技公司的认证。