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的引擎將不會是贏得吞吐量基準的引擎。