LightSeek Foundation发布了TokenSpeed,一个MIT许可的开源推理引擎,在NVIDIA B200上8路tensor-parallel运行Qwen3.5-397B-A17B(NVFP4量化),单用户吞吐量报告为580 tok/s。他们基准测试的agentic工作负载形状正确:首轮50K上下文、10-15轮每轮800个token、>90% KV缓存命中率。定位是"TensorRT-LLM性能加vLLM可用性"——从零开始用SPMD架构和静态编译构建。
三类优化承载速度。内存拷贝消除使用跨KV pages和Mamba状态slots的混合前缀缓存(Qwen3.5的线性注意力层维持递归状态,TokenSpeed将其与KV一起checkpoint),通过current_input_indices进行索引间接而非在推测解码期间复制tensor,以及copy-on-write语义使缓存的checkpoint在不变异的情况下被重用。Kernel融合压缩多阶段ops:GemmaRMSNorm AllReduce从3个kernel到1个,QK-RMSNorm + Partial RoPE + Gate Split从5个到1个Triton kernel,中间结果保留在寄存器中,MoE Gate-Sigmoid-Mul-Add从5个到1个。重叠的CPU-GPU执行使用CUDA graph捕获、pinned内存的异步H2D、基于事件的layer barrier、和GPU侧sentinel来消灭D2H往返。长上下文曲线是要标记的头条数字:128K时~530 tok/s、256K时~495 tok/s、1M时~445 tok/s——8倍上下文扩展跨度仅降级16%。
构建者的生态系统解读是双重的。首先,agentic-工作负载形状的推理正成为一个独立于通用prompt completion的类别。TokenSpeed交付的优化——prefix-cache-aware设计、多轮KV重用、Mamba/GDN状态缓存——为同一上下文跨轮增长的场景调优,这正是LLM agent所处的场景。单batch数字是这个工作负载最干净的信号,因为真实agent traces通常是每用户串行的。第二,方法论差距是真实的:没有在相同Qwen3.5 NVFP4设置上对vLLM、SGLang或TensorRT-LLM的头对头数字发布,这意味着"580 tps记录"的framing需要独立runner的复现。MIT许可和位于lightseekorg/tokenspeed的公开GitHub使该复现成为可能,无论头条数字是否成立,这都是方法论上的胜利。
如果你周一早上在混合架构模型上运行agentic推理:TokenSpeed值得在你的具体工作负载上做一次复现,特别是如果你有B200集群和NVFP4-aware工具。如果你构建推理SaaS:agentic-工作负载优化类别——在多轮状态churn中存活的前缀缓存——现在与batch-prompt吞吐量明显分离。赢得agent serving的引擎将不会是赢得吞吐量基准的引擎。