项目简介
TokenSpeed 是开源 LLM 推理引擎，面向生产级智能体负载，兼具 TensorRT-LLM 级性能与 vLLM 级易用性。其架构将 C++ 有限状态机控制面与 Python 执行面分离，在编译期保障 KV 缓存与请求生命周期安全。内核系统采用可插拔设计，包含 Blackwell GPU 上最快的 MLA 实现之一。
README 预览
\n \n\n\nTokenSpeed is a speed-of-light LLM inference engine designed for **agentic workloads**, with TensorRT-LLM-level performance and vLLM-level usability. The goal is to be the most performant inference engine for production agentic workloads.\n\nCore components:\n\n- **Scheduler**: C++ control plane and Python execution plane. Request\n lifecycle, KV cache ownership, and overlap timing are encoded as a\n finite-state machine, with safe KV resource reuse enforced by the type system at compile time.\n- **Kernels**: pluggable, layered kernel system with a portable public API and\n a centralized registry including one of the fastest **MLA**\n (Multi-head Latent Attention) implementations on Blackwell for agentic workloads.\n- **Entrypoint**: SMG-integrated AsyncLLM for low-overhead CPU-side request\n handling.\n\n## Differentiation\n\nTokenSpeed takes a fundamentally different architectural approach from existing LLM inference engines. The **PyTorch Foundation highlighted these architectural differentiators** when [welcoming TokenSpeed](https://pytorch.org/blog/pytorch-ecosystem-landscape-q3-update/) to the PyTorch Ecosystem Landscape:\n\n> TokenSpeed is an open source LLM inference engine and the first to separate the control plane from the execution plane. The control plane is implemented in C++ as a finite-state machine, using the type system to enforce safe resource management, including request lifecycles and KV cache state, at compile time rather than runtime. The execution plane is implemented in Python, enabling fast iteration and lowering the cognitive load for researchers and engineers. This architecture combines strong correctness guarantees in the core scheduling system with the development velocity of a high-level execution layer.\n>\n> TokenSpeed also treats kernels as a first-class, modular subsystem, separating them from the core engine through a portable public API, centralized registry and selection model, and an extensible plugin mechanism
常见问题 (2)
故障排除为什么在使用 triton 采样后端时，单个请求在 n>1 的情况下会返回相同的补全结果？
已知 bug：parallel_sampling.py 中的 prepare_parallel_sampling_replica 只对 tokenized request 做浅拷贝，且仅替换了 rid，因此所有 n 个副本共享同一个 SamplingParams 和 seed。triton sampler 的噪声来自 tl.randint(seed, offset)（ops/sampling/triton/gumbel.py），所以每个副本在每一步都会抽取出相同的 token——而请求仍返回 HTTP 200 且 usage 统计正确，从而构成一个静默失败。变通方法：(1) 发送 N 个独立请求、每个设置 n: 1，而不是发送一个 n: N 的请求；按请求采样可以产生不同的 completion（已在 temperature 0.7 和 1.2 下确认），代价是失去 prefill 共享和 batching。(2) 在 NVIDIA GPU 上，使用默认的 --sampling-backend flashinfer，其 Philox RNG 包含了 batch 行（curand_init(philox_seed, bx, ...)），因此副本会自然产生差异。另外还需排除一个表象相似的原因：在非 NVIDIA 平台上，backend 默认为 greedy，它会忽略 temperature/top_p/top_k/seed，同时仍返回 200。可用 curl http://<host>:<control-port>/get_server_info | grep sampling_backend 验证当前生效的 backend。这对 GRPO 风格的 RL rollout 尤为重要，因为 n>1 个完全相同的 completion 会产生零方差的 advantage，导致没有任何训练信号。
故障排除为什么在 AMD gfx950 上高并发提供服务时，某些基准测试步骤的运行速度会慢约 36%，并随机出现约 1 秒的停顿？
卡顿是由 JIT kernel 编译发生在服务运行过程中而非启动阶段所导致的。有两个来源：(1) 调度器将 prompt 聚合为最大 8192 个 token 的 prefill 批次，但默认的 prefill 图捕获仅覆盖到 2048 个 token，因此较大的 prefill 批次会走到未被捕获的路径，在服务过程中编译 kernel。(2) Attention kernel 有许多编译期特化，这些特化在 warmup 期间没有被触发执行。修复方法：将服务器端的 prefill 图捕获上限设置为与调度器的最大 prefill 批次大小一致（例如 8192 个 token），使编译发生在捕获阶段而非请求处理期间。此外，运行更具代表性的 warmup 请求，使其覆盖生产环境中实际使用的 attention 特化。诊断提示：其特征是在 TTFT 的尾部（p90/p99）出现固定的约 0.9 秒卡顿，而中位数 TTFT 和 TPOT 保持不变，且所有请求仍能成功完成。