AI写代码越来越快，但一个复杂任务真正耗时的地方，往往不只是生成代码。
让AI自己处理一个项目，它可能要先分析需求、生成计划，再调用工具、阅读报错、修改代码。一轮做完，还要接着判断下一步。这样的过程循环很多次，即使每次只少等一点，累计下来也可能影响整个任务的耗时。
10月13日，开源推理引擎TokenSpeed的开发团队公布了一组测试结果：使用4张NVIDIA GB300运行千问Qwen3.8-Flash-Next，在单路并发条件下，平均每用户输出速度达到685.9 Token/s。
685 Token/s，到底是在测什么？
这次主要测试之一，使用的是SWE-Smith代码任务的既有多轮对话记录。每段对话有10至15轮，第一轮输入约50,000 Token，此后每轮新增800 Token，每轮最多输出500 Token。
采用既有记录回放，是为了更稳定地观察推理服务的性能，而不是让Agent现场解决一批新问题。所以，测试能说明这套服务的输出表现，但不能直接证明代码任务的完成率或最终质量。
另一个容易忽略的细节，是685.9 Token/s的计算方式。
团队统计每轮请求在第一个Token出现之后、继续输出其余Token所花费的平均时间，再换算为输出速度。首Token出现之前的排队、输入处理等时间，不计入这个数字；首Token之后的调度停顿和流式传输开销则包含在统计中。
而且，685.9 Token/s对应的是并发数为1的结果。用户一多，情况就不一样了。
同一测试中，并发从1提高到32，单用户输出速度从685.9 Token/s降至95.7 Token/s；与此同时，平均每张GPU的输出吞吐量，从每分钟7,321.5 Token增加到29,005.5 Token。
换句话说，一个人用得快，和一群人一起用时总共能处理多少工作，是两回事。前者决定交互时的等待感受，后者关系到服务器的服务能力。两项指标的统计范围也不同，不能直接用并发数相乘来换算。
这组数据说明了优化后系统在不同并发下的表现，但原文没有给出足够的同条件跨引擎对照，因此不能据此断言TokenSpeed比其他主流推理引擎快了多少倍。
模型没有更新，这些速度从哪里挤出来？
先看模型本身。
Qwen3.8-Flash-Next在8月就已有公开介绍。它采用混合专家（MoE）架构，主模型约1,250亿参数，另有约510亿参数的N-gram嵌入部分，但每生成一个Token，并不需要激活全部参数，主模型的激活参数量约为60亿。
它还结合了两种处理上下文的方式：Gated DeltaNet（GDN）把部分历史信息压缩成递归状态，Qwen Sparse Attention（QSA）则负责从较长的上下文中选出相关内容。模型在设计时，已经尝试减少不必要的计算。
问题是，模型理论上少算了，并不等于软件运行起来就没有额外开销。
GPU执行模型时，不仅要做矩阵计算，还得查找缓存位置、准备计算数据、读写中间结果、启动一段段计算程序。模型计算越精简，这些辅助步骤所占的时间比例，有时反而越明显。
这正是TokenSpeed此次优化的重点。
第一处，是让稀疏注意力“找内容”更省事。
可以把QSA理解成先从长篇记录里找出值得回看的几页，再仔细阅读，而不是每次都把整本记录重读一遍。
但“找哪几页”本身也要计算：给历史内容评分、筛选相关片段，再找到它们在缓存中的位置。如果连续几个候选Token都要查相近的历史内容，每次从头准备就会产生重复工作。
TokenSpeed针对这个过程做了复用，让同一请求中多个待验证的Token共享部分历史索引数据，并减少无效位置的筛选。在一项只针对评分环节的GB300微基准测试中，单请求对应的耗时从6.61微秒降到2.69微秒。
这个对比只针对局部计算环节，不能理解为整个模型快了2倍多。但它说明，除了真正执行注意力计算，“先把该看的内容找出来”也值得优化。
第二处，是把原来分开的零碎计算合在一起。
千问这套架构有四路残差分支。每一层都要做归一化、投影、门控混合和状态更新，如果每个小步骤都单独启动GPU计算程序，就会反复产生启动和数据搬运成本。
TokenSpeed为其中一部分操作设计了融合算子，把多个步骤放到同一次执行中。在团队公布的局部测试里，32行Token输入时，某个残差混合算子的耗时从30.61微秒降至8.38微秒。
第三处，是让一次预测多个Token的过程少做重复工作。
一般的自回归生成，是得到一个Token之后再预测下一个。多Token预测（MTP）则尝试一次准备多个候选，再由模型验证哪些可以保留。
听起来像是一次多走几步，但多预测也会带来新成本：草稿模型要计算，候选要验证，最后还要把接受的结果更新到缓存中。
TokenSpeed的处理方式包括：让后续草稿步骤复用先前选出的注意力位置，把验证状态直接写入指定缓冲区，并批量更新已接受Token对应的状态。这样减少重复筛选和中间数据复制。
在这次SWE-Smith测试中，团队报告单路并发时每轮平均接受长度为3.231 Token，其余并发设置下的平均值也接近这一水平。但它只是解释多Token预测机制在该测试中的运行情况，不能脱离草稿与验证的成本，单独推算整体速度。
第四处，是把显存和GPU等待时间也算进优化。
Qwen3.8-Flash-Next有一块很大的N-gram嵌入表，但每次生成时只会访问其中少量数据。TokenSpeed把这部分表存放在锁页主机内存中，按需读取对应数据，并尽可能让读取与其他计算重叠进行。
按照团队公开的配置，使用FP8格式存储该表，并在4路张量并行之间分片，每个GPU分片可释放约12.22 GiB的常驻显存分配。腾出的显存可以用于更大的KV缓存，为服务更多并发请求提供空间。
当然，把数据从显存移到主机内存并不是免费操作。数据仍需要传输，所以关键在于按需读取、提前准备，尽量避免让GPU停下来等。
同样的思路还被用于GPU计算程序之间的重叠执行：后一个步骤如果有不依赖前一步结果的准备工作，可以先开始准备；真正用到前一步输出时，仍要等待数据就绪。
这次优化的共同点，不是让GPU凭空增加算力，而是少做重复工作、少搬数据，并尽量缩短本可避免的等待。
速度、显存和任务质量，不能只看一个指标
这次测试还有一个关键条件：使用了NVIDIA提供的Qwen3.8-Flash-Next-NVFP4量化检查点。
量化可以理解为用更紧凑的数值表示来存放和计算部分模型数据，减轻存储与带宽压力。NVIDIA模型卡显示，这一版本并不是让全部数据都变成4bit：部分专家层使用NVFP4，其他模块仍使用BF16或FP8等精度。
因此，不能看到“NVFP4”就认为整个模型只需原来的四分之一存储空间，也不能只看输出速度，就认定量化前后所有任务的效果完全一致。
NVIDIA公开过FP8与NVFP4版本在多项基准上的对照，成绩有高有低。例如Terminal-Bench 2.1的结果分别为83.3和82.9。它们可以作为观察量化影响的参考，但不是TokenSpeed这次速度测试中重新测出的任务质量。
再加上模型文件、缓存精度、并行方式、MTP步数和运行环境都会影响表现，单独知道“4张GB300”和“685.9 Token/s”，还不足以复现同样的速度。
对于真正准备部署的团队，还需要在自己的业务负载下，同时测试首Token等待时间、持续输出速度、并发吞吐、任务质量和成本。
输出更快，Agent最终能少等多久？
回到最初的问题：假设一个Agent要连续生成计划、写代码、分析结果，一共输出6,000 Token，模型输出速度从100 Token/s提高到685 Token/s，最终任务能快多少？
只看输出阶段，时间大约会从60秒缩短到8.8秒，确实非常明显。
但如果这个任务还需要90秒来等待排队、处理输入、调用工具和执行代码，那么完整任务的耗时，就只是从150秒降到约98.8秒，减少约34%。
这是为了说明关系而做的假设计算，不是TokenSpeed公布的一项真实Agent任务成绩。
在不同任务中，结果可能差很多。不断访问网页、运行测试或者等待外部服务的Agent，瓶颈可能主要在工具上；需要持续生成大量内容的任务，模型输出速度的影响通常会更大。
成本也一样。自建部署要考虑GPU采购或租赁、设备利用率、请求并发和任务完成率；托管API是否降价，则由服务商决定。推理效率改善可能为降低成本创造条件，但这次公布的685.9 Token/s，并不等于阿里云已经调整了API价格。
所以，这次测试最值得关注的，并不只是一个看起来很快的数字。
它说明，即使模型本身已经专门设计了高效的计算架构，开放权重之后，推理引擎仍然可以继续优化：从注意力筛选、算子融合，到缓存复用、内存安排和GPU执行调度，很多细节都会影响最终的服务表现。
对于Agent来说，输出更快是好事，但这只是第一步。在相同任务、可接受的质量和实际并发条件下，用户究竟少等了多久、完成同样工作花了多少钱，才是下一步真正需要回答的问题。
参考资料
-
TokenSpeed Team｜685 tokens/s per user: serving Qwen3.8-Flash-Next on NVIDIA GB300 with TokenSpeed -
NVIDIA｜Experiment with Qwen3.8-Flash-Next on NVIDIA GB300 NVL72 for Agentic Coding -
NVIDIA｜Qwen3.8-Flash-Next-NVFP4模型卡 -
TokenSpeed开源仓库 -
NVIDIA CUDA｜Programmatic Dependent Launch