Kog 推理引擎：不砍精度，单请求冲到 3000 tokens/s

推理引擎的 benchmark 长期被一个数字统治——聚合吞吐量。每秒多少 token，多少并发请求，成本摊到每个 token 多少美元。这些指标对批量处理场景确实重要，但它们掩盖了一个越来越尖锐的问题：当用户坐在聊天窗口前等回复，聚合吞吐量救不了体验延迟。

Kog AI 刚发布的 KIE（Kog Inference Engine）技术预览版，把矛头直接指向了单请求速度——8× AMD MI300X 上跑出 3000 tokens/s，8× NVIDIA H200 上达到 2100 tokens/s。更值得注意的前提：没有量化，没有投机解码，没有剪枝，没有 KV Cache 压缩。模型精度和完整度原封不动，速度靠架构层面的优化拿到。

单请求速度为什么突然成了硬指标

过去两年，推理优化几乎都走同一条路：用精度换速度。INT8、INT4 量化，投机解码用小模型猜大模型的输出，KV Cache 压缩扔掉"不重要"的注意力记录。这些手段在聚合吞吐量 benchmark 上效果显著，但代价是单请求的首 token 延迟（TTFT）和生成节奏被拖慢或打乱——因为并发调度本身就需要排队和资源分片。

现实场景正在倒逼思路转变：

• 交互式 AI 助手：用户对 200ms 以上的卡顿有明确感知，流畅的生成节奏比"总吞吐量高但偶尔卡一下"更影响体验。
• Agent 链式调用：一个 agent 工作流可能连续发起几十次推理调用，每次都是单请求、低并发。聚合吞吐量在这里几乎不发挥作用，单次调用的端到端延迟才是瓶颈。
• 实时语音/视频对话：多模态场景对 token 生成速度的要求直接对应到音频帧率，低于某个阈值就无法维持自然对话节奏。

KIE 的思路是：不牺牲模型完整性，在计算调度和内存访问层面把单请求的 GPU 利用率拉到接近理论上限。

8× MI300X 3000 tokens/s 背后做了什么

摘要中明确提到"未使用量化、投机解码、剪枝或 KV Cache 压缩"，这意味着速度提升来自更底层的优化。结合公开信息和技术预览版的方向，核心手段大致落在以下几类：

计算与通信的重叠调度。8 卡推理的最大瓶颈不是单卡算力，而是卡间通信。传统做法是先完成一轮 AllReduce 再继续计算，通信时间完全是空等。KIE 的调度策略让计算和通信重叠执行——当前层的通信进行时，下一层的部分计算已经启动。这种"流水线式"重叠在数学上接近于把通信开销压到零。

连续批处理（Continuous Batching）的单请求特化。Continuous Batching 本身是提升并发吞吐的常见手段，但 KIE 把它反过来用：在单请求场景下，通过更细粒度的 micro-batching 把一个请求的多个 step 拆成更小的调度单元，让 GPU 的 SM（流多处理器）在每个周期都有足够的工作量，减少空闲气泡。

内存访问模式优化。大模型推理是典型的内存带宽瓶颈（memory-bound），而非计算瓶颈。权重从 HBM 加载到 SRAM 的速度决定了实际吞吐。KIE 对权重加载做了预取和重排，让同一批权重在 SRAM 中被尽可能多次复用后才换出，减少 HBM 读取次数。

这些优化叠加起来，在 MI300X 的 5.3 TB/s HBM 带宽上把利用率推到了一个远超常规推理引擎的水平。H200 的 4.8 TB/s 带宽略低，对应 2100 tokens/s 的成绩也符合带宽比例关系——侧面印证了优化确实是在内存带宽层面吃满了硬件能力。

AMD vs NVIDIA：两个数字的读法

3000 和 2100 的差距，很容易被读成"AMD 完胜"。但更准确的读法是：MI300X 的 HBM 带宽（5.3 TB/s）高于 H200（4.8 TB/s），而 KIE 的优化恰好把瓶颈压到了内存带宽上，所以带宽差异直接反映到了速度差异。这不是"AMD 的 GPU 计算更强"，而是"这个特定优化路径下，带宽成了决定性因素，MI300X 的带宽更大"。

对选型的影响：如果你的推理场景确实是单请求、memory-bound，MI300X 在 KIE 这套优化下有明确优势。但如果你的场景是高并发、计算密集（比如长 context 的 prefill 阶段），H200 的 FP8 计算能力和更成熟的软件生态可能仍然是更稳妥的选择。

实践：用开源工具测量你的单请求速度

KIE 目前是技术预览版，尚未完全开源。但你可以用现有工具复现单请求速度的测量方法，建立自己的基准线，等 KIE 开放后直接对比。

以下脚本使用 vLLM（当前最主流的开源推理引擎）在单请求场景下测量 tokens/s，同时监控 GPU 带宽利用率：

# 1. 启动 vLLM 单卡推理服务（以 Llama-3.1-8B 为例）
#    --max-model-len 控制最大序列长度
#    --gpu-memory-utilization 控制显存占用比例
python -m vllm.entrypoints.openai.api_server \
  --model meta-llama/Llama-3.1-8B-Instruct \
  --max-model-len 4096 \
  --gpu-memory-utilization 0.9 \
  --port 8000

# 2. 单请求速度测量脚本 measure_single_req.py
#    依赖: pip install openai pydantic
#    运行: python measure_single_req.py

import time, json, statistics
from openai import OpenAI

client = OpenAI(base_url="http://localhost:8000/v1", api_key="dummy")

PROMPT = "请用中文详细解释 transformer 架构中多头注意力的计算流程，从输入矩阵到输出矩阵，逐步说明每个矩阵运算的含义和维度变化。"
NUM_RUNS = 5  # 多次运行取均值，减少波动

speeds = []
ttfts = []  # 首 token 延迟

for i in range(NUM_RUNS):
    start = time.perf_counter()
    first_token_time = None
    token_count = 0

    stream = client.chat.completions.create(
        model="meta-llama/Llama-3.1-8B-Instruct",
        messages=[{"role": "user", "content": PROMPT}],
        max_tokens=512,
        stream=True,
    )

    for chunk in stream:
        if chunk.choices[0].delta.content:
            token_count += 1
            if first_token_time is None:
                first_token_time = time.perf_counter()

    end = time.perf_counter()

    if first_token_time:
        ttft_ms = (first_token_time - start) * 1000
        generation_time = end - first_token_time
        tokens_per_sec = token_count / generation_time if generation_time > 0 else 0
        ttfts.append(ttft_ms)
        speeds.append(tokens_per_sec)
        print(f"Run {i+1}: {tokens_per_sec:.1f} tokens/s, TTFT {ttft_ms:.0f}ms, {token_count} tokens")

print(f"\n--- 结果汇总 ---")
print(f"平均速度: {statistics.mean(speeds):.1f} tokens/s")
print(f"平均 TTFT: {statistics.mean(ttfts):.0f} ms")
print(f"速度标准差: {statistics.stdev(speeds):.1f} tokens/s")

# 3. 同时监控 GPU 带宽利用率（需要 dcgm-exporter 或 nvidia-smi）
#    每 1 秒采样一次，推理期间运行
nvidia-smi dmon -s u -d 1 -c 60
#    输出中的 "gpu" 列即 GPU 计算利用率
#    如需带宽利用率，安装 DCGM:
#    docker run --gpus all --rm nvcr.io/nvidia/k8s/dcgm-exporter:3.1.7 \
#      -d f:100,f:101,f:102  # 带宽利用率指标

运行后你会得到一组数据：单请求 tokens/s、TTFT、GPU 利用率。在 8B 模型单卡场景下，vLLM 通常在 80-120 tokens/s 左右（具体取决于 GPU 型号和显存带宽）。这个数字和 KIE 的 3000 tokens/s 之间的差距，就是调度优化和 8 卡协同的空间。

如果你想进一步逼近 KIE 的测量方式，把脚本改成 8 卡部署：

# 8 卡 vLLM 启动（需要 8 卡同一节点）
python -m vllm.entrypoints.openai.api_server \
  --model meta-llama/Llama-3.1-70B-Instruct \
  --tensor-parallel-size 8 \
  --max-model-len 4096 \
  --gpu-memory-utilization 0.9 \
  --port 8000

70B 模型在 8× H200 上用 vLLM 单请求大约在 150-250 tokens/s 区间。对比 KIE 的 2100 tokens/s，差距接近 10 倍——这基本就是"传统调度"和"计算通信重叠+micro-batching 特化"之间的工程差距。

采纳前需要想清楚的几件事

技术预览版 ≠ 生产可用。KIE 目前是预览，没有 SLA，没有长期稳定性数据，API 和配置格式可能变动。适合做基准测试和技术验证，不适合直接上生产。

单请求速度不是唯一指标。如果你的业务是高并发批量处理（翻译、摘要、批量 embedding），聚合吞吐量和成本/token 仍然更重要。KIE 的优化方向对这类场景的提升有限——它吃的是单请求下 GPU 的空闲气泡，高并发场景下气泡本来就不大。

硬件绑定度高。3000 tokens/s 的成绩是在 8× MI300X 这种顶级带宽硬件上拿到的。如果你用的是 A100（2 TB/s 带宽）或 L40（0.72 TB/s），速度会按带宽比例下降，优化效果被硬件天花板限制。

生态成熟度。MI300X 的软件栈（ROCm）在稳定性和工具链丰富度上仍然落后于 NVIDIA 的 CUDA 生态。KIE 在 MI300X 上跑得快，但部署、调试、监控的整体体验可能不如 H200 上顺畅。

一个简单的决策检查清单：

KIE 的意义不只是一个新引擎的发布，而是把"单请求速度"这个被长期忽视的指标推到了台前。当 agent 工作流和实时对话成为主流场景，推理优化的重心从"每秒多少 token 总量"转向"每个用户等多久"，这个转变本身比具体数字更值得关注。