为什么 Agent 需要专用推理以及 TokenSpeed 如何加速 LLM

当运行标准的文本或代码生成神经网络时，vLLM 等引擎通常游刃有余。但一旦涉及自主 AI Agent，情况就大不相同了。频繁的工具调用、对话分支、重复的上下文传递以及不断增长的 KV-cache 很快就会让标准推理引擎不堪重负。

今年 5 月，LightSeek 团队在 GitHub 上发布了 TokenSpeed。开发者旨在打造一款专用的 Agent 工作负载引擎，将 TensorRT-LLM 的速度与简洁的 Python 接口相结合。

标准引擎在处理 Agent 时会出现什么问题

Agent 场景与聊天机器人对话有显著不同。机器人接收请求，生成单个响应，然后释放资源。而 Agent 则以循环方式运行：

• 形成思路并选择工具
• 等待外部 API 或数据库的响应
• 分析接收到的结果并采取下一步行动

这导致上下文不断增长，迫使服务器重新计算长 token 链或为 KV-cache 维护大量内存。如果同时运行数十个这样的 Agent，即使是最强大的加速器也会在等待数据传输时陷入空闲状态。

TokenSpeed 架构与解决方案

TokenSpeed 的作者没有在 PyTorch 之上创建另一个薄包装层。他们重写了关键的系统组件，以从硬件中提取最大性能。

首先，他们将控制循环与执行分离。请求调度器使用 C++ 编写，而更高级别的执行逻辑保留在 Python 中。每个请求的状态、KV-cache 所有权转移和时间都与严格的有限状态机绑定。C++ 类型系统在编译时检查缓存资源重用的安全性，完全消除了内存泄漏。

其次，该引擎包含一个用于分布式计算的静态编译器。开发者无需通过 torch.distributed 手动编写并行逻辑。只需在模块边界处放置注解，编译器就会自动生成处理器间通信命令。

第三，他们重新设计了底层内核。作者实现了自己的 Multi-head Latent Attention (MLA) 算法版本，针对 NVIDIA Hopper 和 Blackwell 架构进行了优化。它在处理长上下文时最大限度地减少了延迟。

数据与实际测试

开发者提供了当前模型的具体基准测试。今年 5 月，该项目在 Qwen3.5-397B-A17B 模型的 Agent 任务中展示了 580 tokens/秒的速度。

查看在 NVIDIA B200 芯片上运行 Kimi K2.5 模型时与 TensorRT-LLM 的对比图表，TokenSpeed 在相同延迟水平下吞吐量更高。

有趣的是，该项目对新版本的适配速度非常快。例如，对 Kimi K3 模型和 NVIDIA 及 AMD GPU 的 FP4 推理支持在正式发布当天就添加了。

集成到现有代码

从入口点来看，TokenSpeed 使用 AsyncLLM。该架构最大限度地减少了处理传入 HTTP 请求的 CPU 开销，因此服务器在高 RPS 下不会不堪重负。

服务器启动示例对任何使用过 vLLM 的人来说都很熟悉：

python3 -m tokenspeed.entrypoints.openai.api_server \
    --model Qwen/Qwen2.5-7B-Instruct \
    --port 8000

之后，您可以使用标准的 OpenAI 客户端连接到服务器，这简化了与 AutoGen、CrewAI 或 LangChain 等现有 Agent 框架的集成。

是否值得部署到生产环境

目前，该仓库约有 17,000 颗星和近 50 个 open issues。这是一个年轻、充满活力的项目，现在称之为保守的行业标准还为时过早。

如果您已经部署了 AI Agent 基础设施，并且在长上下文场景下遇到了 vLLM 的性能瓶颈，那么绝对值得尝试 TokenSpeed。如果您需要一个简单的服务器来提供基本的聊天机器人，标准工具目前就足够了。