TokenSpeed：专为编程智能体打造的LLM推理引擎

自托管大语言模型的团队通常面临一个两难选择：vLLM 和 SGLang 部署简单但硬件利用率不够极致，TensorRT-LLM 能压榨出 NVIDIA 硬件的最大性能，代价是复杂的编译和配置流程。LightSeek Foundation 推出的开源推理引擎 TokenSpeed 试图终结这个取舍——用 vLLM 级别的易用性，实现 TensorRT-LLM 级别的性能，并且专门针对编程智能体（Coding Agent）场景做了深度调优。

TokenSpeed 推理引擎

为什么"智能体"改变了推理问题

大多数推理基准测试模拟的是聊天场景：一段短提示，一段短回答，结束。但编程智能体的工作模式完全不同。

一次典型的智能体会话有三个显著特征。第一，上下文极长——把代码文件、工具调用输出和历史对话加在一起，提示词很容易超过 50K token。第二，轮次密集——同一个对话会反复回来，每次都比上次更长。第三，存在硬性速度底线——如果 token 流式输出太慢，智能体给人的感觉就像坏了一样。TokenSpeed 团队将每用户约 70 token/秒设为目标下限，部分场景追求 200+ token/秒。

这意味着优化目标不是单纯的"最大吞吐量"，而是"每 GPU 最大吞吐量，同时保证每个用户都能获得快速生成"。这个定位直接决定了 TokenSpeed 的多数设计取向。

TTFT 与 TPOT：智能体场景下的两个核心指标

文中提到的"每用户 token/秒"对应的是 TPOT（Time Per Output Token，每输出 token 耗时）的倒数，衡量的是模型产出单个 token 的速度；而智能体场景中同样关键的另一个指标是 TTFT（Time To First Token，首 token 延迟），它由预填充（prefill）阶段决定，即模型处理整个输入提示词、建立 KV 缓存所需的时间。当上下文超过 50K token 时，预填充的计算量随序列长度近似平方增长，TTFT 往往成为用户感知卡顿的主因。因此 TokenSpeed 的优化必须同时兼顾两个维度：通过高效的注意力内核压低长上下文的预填充耗时，通过 KV 缓存复用与调度策略提升解码阶段的吞吐。这也是为什么单纯的"最大吞吐量"指标在智能体场景下失真——它可能以牺牲单用户延迟为代价堆高整体 QPS。

架构解析：四个关键设计

建模层：用编译器替代手写并行代码

传统做法是为每个模型手写张量并行通信代码，工作量大且容易出错。TokenSpeed 的思路是让开发者在模块边界标注数据应该在哪里，然后由一个轻量静态编译器自动生成集合通信操作。自定义并行代码减少，意味着添加新模型时引入的 bug 也更少。

调度器：C++ 控制面 + Python 执行面

调度器的控制面用 C++ 写成有限状态机。请求生命周期和 KV 缓存归属被显式建模，类型系统能在编译期捕获不安全的 KV 缓存复用，而不是等到凌晨三点在生产环境爆炸。执行侧保留在 Python 中，方便开发者快速修改和实验。

内核：可插拔注册机制

内核放在独立的可插拔包中，通过注册表管理，NVIDIA 和 AMD 后端可以并存。说个细节，他们为 Blackwell 架构优化的 MLA（多头潜在注意力）内核速度足够快，以至于 vLLM 已经采纳了这个实现——这本身就是一种来自竞品的技术背书。

MLA 与 Blackwell 架构

MLA（Multi-head Latent Attention，多头潜在注意力）是 DeepSeek^广告系列模型引入的注意力变体，它把 Key/Value 投影到低维潜在空间再缓存，相比传统 MHA/GQA 能大幅压缩 KV 缓存占用，因而对长上下文场景尤为有利。但其计算模式与标准注意力差异较大，需要专门编写的高效内核才能在 GPU 上跑出速度。Blackwell 是 NVIDIA 继 Hopper 之后的架构代号（对应 B100/B200 等芯片），引入了新一代 Tensor Core、更大的共享内存与更快的显存带宽，同时第五代 NVLink 提升了多卡互联带宽——这些特性对张量并行通信密集的 MoE 推理尤为关键。TokenSpeed 针对 Blackwell 优化的 MLA 内核被 vLLM 反向采纳，说明其在底层实现上确实达到了可被主流社区认可的工程质量。

入口：OpenAI 兼容 API

请求通过基于 SMG 项目构建的 OpenAI 兼容服务器进入，CPU 侧开销保持在较低水平。这意味着现有使用 OpenAI API 的客户端代码只需要修改 base_url 就能对接。

快速上手：几分钟跑通推理服务

环境要求

需要 NVIDIA GPU 主机（nightly wheel 需要 CUDA 13）或搭载 ROCm 7.2 的 AMD 主机；Python 3.11 到 3.13；如果选择 Docker 路线则需要支持 GPU 的 Docker。

方式一：Docker（推荐）

项目提供了预装好所有依赖的 runner 镜像：

docker pull lightseekorg/tokenspeed-runner:latest

docker run -itd \
  --shm-size 32g \
  --gpus all \
  --ipc=host \
  --network=host \
  -v ~/.cache:/home/runner/.cache \
  --name tokenspeed \
  lightseekorg/tokenspeed-runner:latest \
  /bin/bash

挂载缓存目录后，模型权重在容器重启后依然保留，不需要重新下载。

方式二：pip 安装 nightly 版本

在 CUDA 13 机器上：

python -m pip install --upgrade tokenspeed \
  --extra-index-url https://lightseek.org/whl/nightly

Nightly 版本按日期编号，可以固定版本以保证可复现性。AMD 用户需要先安装 ROCm 版 PyTorch 并使用单独的 wheel 源。

启动第一个模型

GPT-OSS 20B 可以单卡运行，适合做冒烟测试：

tokenspeed serve openai/gpt-oss-20b \
  --served-model-name gpt-oss-20b \
  --host 0.0.0.0 \
  --port 8000 \
  --tensor-parallel-size 1

因为服务器使用 OpenAI API 协议，调用方式与 OpenAI 完全一致：

from openai import OpenAI

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

response = client.chat.completions.create(
    model="gpt-oss-20b",
    messages=[{"role": "user", "content": "Explain KV caching in two sentences."}],
    max_tokens=200,
)
print(response.choices[0].message.content)

任何已经对接 OpenAI 的智能体框架，都可以直接指向这个服务器。

大模型部署

对于大型 MoE 模型，启动参数与 vLLM 高度相似。官方模型配方页面提供了 DeepSeek V4、Qwen3 系列、GLM 5.x、MiniMax M3、Kimi K3、Nemotron-3 Super 等模型的经过测试的启动命令，建议从配方出发而非从零调参。

性能表现：官方数据与验证方式

TokenSpeed 团队公布的性能数据全部为自报，需要谨慎对待：

在 NVIDIA B200 上运行 Kimi K2.5，使用真实编程智能体轨迹（SWE-smith，EvalScope 评估），TokenSpeed 在整个延迟/吞吐量曲线上优于 TensorRT-LLM。batch size 1 时约快 9%，在每用户约 100 token/秒时吞吐量高约 11%。
他们的 MLA 解码内核在典型投机解码工作负载下，延迟约为 TensorRT-LLM 的一半。
在 Qwen3.5-397B-A17B 上，智能体工作负载报告了最高 580 token/秒的速度。

这些是厂商基准测试，应该将其视为"值得测试的理由"而非"性能保证"。好消息是基准测试工具包含在仓库的 test/agentic_benchmark 目录中，可以在自己的流量上复现。

投机解码与 MoE 模型

投机解码（speculative decoding）是一种加速解码的通用技术：用一个轻量"草稿模型"或模型内部的草稿头一次生成多个候选 token，再由主模型并行验证，从而把多次串行解码压缩为一次前向。它能在不改变输出分布的前提下提升单用户生成速度，但代价是验证阶段对 KV 缓存和注意力内核的压力更大，因此对内核效率敏感——这正是文中强调"典型投机解码工作负载下延迟约为 TensorRT-LLM 一半"的背景。MoE（Mixture of Experts，混合专家）则是当前前沿开源大模型的主流架构，如 DeepSeek、Qwen、Kimi 等，其特点是大参数量但每 token 只激活部分专家，从而在推理时降低实际计算量。MoE 的推理瓶颈往往不在算力而在显存带宽与通信（专家分散在不同 GPU 上需要 all-to-all 通信），这也是 TokenSpeed 强调建模层通信自动生成、以及面向多卡张量并行的价值所在。

适合哪些团队

TokenSpeed 目前最适合以下场景：

为编程智能体或长上下文、多轮对话工作负载部署大型 MoE 模型（DeepSeek、Kimi、Qwen、GLM、MiniMax 等）。
运行在较新的 NVIDIA 硬件（Hopper，尤其是 Blackwell）或 AMD MI350 级别 GPU 上，并且关注每 token 成本。
曾考虑 TensorRT-LLM 的速度优势，但不想承担其构建和配置的复杂度。
需要对新前沿开源模型的零日支持。TokenSpeed 在 Kimi K3 和 Thinking Machines 的 Inkling 发布当天就提供了支持。

从定位来看，TokenSpeed 填补的是推理引擎市场中一个真实存在的空白：既不想牺牲性能，也不想承受 TensorRT-LLM 的工程负担。它能否兑现承诺，取决于真实工作负载下的表现——而基准测试工具的开放，至少让验证变得可行。