Kog AI 这次给出的数字很直接：标准 8 卡 GPU 节点，单请求解码最高约 3000 tokens/s。
具体一点，是 8×AMD MI300X 约 3000 tokens/s，8×NVIDIA H200 约 2100 tokens/s。条件也要同时写清：FP16，batch size 1，没有 speculative decoding，公开演示模型是 2B coding model，不是 frontier model。
所以，这不是“大模型推理已经便宜到飞起”。也不该被轻飘飘归为一次跑分秀。
它真正戳中的问题是：标准 GPU 在低 batch 解码里，到底还有多少性能被软件栈、通信、调度和抽象层吃掉了。
3000 tokens/s 说的是单个请求，不是整机吞吐
推理圈里很多数字都叫 tokens/s，但指的不是一回事。Kog 这次强调的是单请求 decode speed，也就是一个请求连续生成时，每秒吐多少 token。
这和常见的服务器总吞吐不是同一个指标。
| 指标 | 关心的问题 | 容易误读的点 |
|---|---|---|
| Aggregate throughput | 一台服务器总共每秒生成多少 token | 大 batch 可以很好看，但单个用户未必快 |
| Time to first token | 第一个 token 多久出来 | 决定“有反应”的速度，不等于后续生成速度 |
| Decode speed per request | 单个请求持续生成有多快 | 直接影响 agent 一轮任务要等多久 |
这件事对 AI agent 比对普通聊天更重要。
聊天产品里，用户可以容忍模型慢慢打字。代码代理、企业自动化代理不一样。它们经常要 inspect、plan、edit、test、revise，一步卡住，后面都停。
Kog 给过一个直观换算：一个工作流如果要生成 5 万 token，100 tokens/s 大约 8 分钟；3000 tokens/s 不到 20 秒。这个例子不能代表所有任务，但能说明一件事：低延迟会改变 agent 的可用边界。
受影响最直接的是两类人。
| 对象 | 现在该怎么看 |
|---|---|
| 做代码代理、自动化 agent 的团队 | 不该只看模型分数，也要把单请求解码速度列进评估表 |
| 企业和主权 AI 买家 | 采购专用推理芯片前，可以延后一点判断，要求 GPU 方案给出低 batch 延迟数据 |
这里的动作不是立刻迁移。恰恰相反，是别急着被单个数字带走。
如果你买的是 agent 能力，就要问三个数：首 token 时间、单请求 decode speed、生产流量下的稳定吞吐。少一个，账都不完整。
低 batch 解码卡在 HBM，也卡在微秒级软件税
Kog 这篇技术预览最有价值的地方，不是“3000”本身，而是它把瓶颈说清了。
batch size 1 的自回归解码，很多时候不像 FLOPS 问题，更像内存带宽问题。
每生成一个 token，模型权重都要从 HBM 搬到计算单元。FP16 权重约 2 字节。算术强度低，GPU 峰值算力再高，也要先过 HBM 带宽这一关。
Kog 的说法是，8×H200 节点按可用带宽估算约 30.7 TB/s，8×MI300X 约 33.6 TB/s。对一个 2B FP16 dense model，权重大约 4GB，理论上确实存在数千 tokens/s 的空间。
现实跑不到理论上限，问题就落到软件栈。
| 损耗来源 | Kog 的做法 |
|---|---|
| 多 kernel launch、频繁同步 | persistent monokernel，把 decode 热路径做成 GPU 常驻程序 |
| CPU 调度和采样开销 | 把 sampling 等关键逻辑放到 GPU 上 |
| 跨 GPU 通信延迟 | 自研 KCCL，压低 collectives 开销 |
| Tensor parallel 等待 | Laneformer / DTP，尽量重叠通信和计算 |
| 拓扑、缓存、buffer 损耗 | 针对 GPU 结构做同步和内存访问优化 |
这不是给现有框架拧几个参数。它更像把模型结构、runtime、kernel、通信库压成一台低延迟机器。
代价也在这里。
通用推理框架要照顾多模型、多租户、高吞吐、可维护性。Kog 这种路线追求的是极限低延迟。它可能更快，也必然更挑模型、更挑部署条件、更难维护。
古话说“天下熙熙，皆为利来”。放到推理系统里，就是每一层抽象都要收费。收的不是钱，是微秒。
当每个 token 的预算只有几百微秒，抽象层就不再只是工程便利，也可能变成延迟税。
我的判断：方向是真的，结论还不能拔太高
我更在意的不是 Kog 赢没赢某个 benchmark，而是它把行业里一个不太好听的事实摊开了：标准 GPU 并不天然慢，很多慢来自软件栈没把低延迟当第一目标。
这对专用推理芯片叙事是一次提醒，但不是判决书。
Kog 目前只能说明一件事：在 2B FP16、batch size 1、无 speculative decoding 的公开演示条件下，标准 GPU 还有被系统工程挖出来的余量。它不能证明大模型、MoE、复杂生产流量都能同速复现。
限制要摆在桌面上。
| 现在能确认的 | 现在还看不清的 |
|---|---|
| 2B coding model 上的技术预览成绩 | frontier model 上是否仍然接近这个速度 |
| 8×MI300X、8×H200 的厂商自测结果 | 第三方可复现结果和更多模型基线 |
| batch size 1、FP16、无 speculative decoding | 生产批处理、多租户、长上下文下的稳定性 |
| Kog 声称后续支持大 MoE | 大 MoE 的真实速度、成本和部署复杂度 |
这也是我不太买账某些过度解读的原因。
不能把 2B 模型跑分快速外推成“大模型推理格局改写”。不能把技术预览当成熟商用部署。更不能据此宣布专用推理芯片路线失败。
专用芯片要回答的是另一组问题：成本、功耗、供货、编译器、模型适配、集群规模、运维复杂度。Kog 这次打到的是低延迟软件栈，不是把所有硬件路线一刀砍掉。
更现实的动作是：
- agent 团队评测推理服务时，把单请求 decode speed 单独列出来，不要只看总吞吐。
- 企业买 GPU 或专用推理卡时，要求供应商给出相同模型、相同精度、相同 batch 下的延迟数据。
- 已经在用 vLLM、SGLang、TensorRT-LLM 的团队，不必马上迁移，但要开始区分“高吞吐优化”和“低延迟优化”是不是同一个目标。
这件事接下来只看三项。
一是能不能跑更大的 dense model 和真实 MoE。二是能不能在生产流量下稳定跑，而不是只跑演示路径。三是能不能拿出第三方复现结果，和主流推理栈放到同一条件下对比。
如果这三项站住，低延迟推理会重新变成软件工程的主战场。
模型能力当然重要。但 agent 不是论文榜单。它要一轮一轮跑任务。每个微秒都算数，每个同步点都可能拖垮体验。
Kog 这次最有价值的提醒就在这里：GPU 还有余量，但余量不在宣传页上，在系统栈最脏、最细、最难维护的地方。