小睿聊AI 09｜Qwen3.8 Flash 双 Spark 调优实录：13万上下文，怎样把热首字压到0.7秒

封面为双机本地推理概念示意图。

两台 Spark 跑 Qwen3.8 Flash，13.2万 token 的输入，在前缀缓存命中后，0.69秒收到第一个输出token，随后约62 tok/s；同一档输入没有缓存时，首字要等42.9秒。这两个数字放在一起，才接近一个长任务 Agent 的真实体验。

我是小睿。这次想聊的，是一套本地模型服务怎样一点点调顺：哪些参数值得改，哪些看上去先进的优化反而拖后腿，以及一次升级为何会让两台机器反复等待十分钟。

这组记录证明了少量长上下文任务接续使用的可行性，也留下一个很实用的判断：先找出工作真正卡在哪一段，再决定改什么。缓存、MTP和算子优化解决的是不同问题，参数开得更多，服务未必更好用。

这组实践用的是两台技嘉 GIGABYTE AI TOP ATOM，属于 GB10 / DGX Spark 平台，以200GbE RoCE互联。模型为 Qwen3.8-Flash-Next 的 NVIDIA NVFP4 权重，原生上下文262,144 tokens。整轮实践没有换权重，主要调整推理引擎、算子路径和运行参数。

先把最终长请求数据放出来。固定代码题，输出统一为2,048 token；每档一冷两热，下表热请求取第二次。

输入长度	冷首字	热首字	热生成速度	热前缀命中
约3.3万 token	10.3秒	0.58秒	约64 tok/s	约96%
约13.2万 token	42.9秒	0.69秒	约62 tok/s	约99%

这里的 token 是模型处理文本的单位，不直接等于一个汉字或一个英文单词。tok/s 表示每秒生成多少个 token。表里的“首字”沿用日常说法，技术指标是 TTFT，即请求发出到收到第一个输出 token 的时间；它也不一定就是界面上出现最终答案的时刻，思考模型可能先输出推理内容。

这篇所有本机数据都来自这轮部署记录。不同实验分别有自己的对照，下文不把几次百分比相加，凑成一个“累计提速”。

先分清三种等待，调优才有方向

一个本地模型从开机到回答问题，至少有三种容易混淆的等待。

第一种是服务启动：加载权重、初始化两台机器之间的通信、编译或捕获执行路径。这套服务一次完整冷启动约需9—10分钟。它影响维护和故障恢复，但通常不会发生在每一轮聊天里。

第二种是预填充，英文叫 prefill。模型要先处理输入，建立后面生成所需的中间状态。几百 token 的提问和十几万 token 的项目上下文，工作量差别很大。相同前缀已经计算过、相关缓存也还在时，可以复用其中一部分，这就形成了冷请求与热请求的差别。

第三种是生成，通常叫 decode。模型继续输出新的 token；这时看的是生成速度和连续输出的间隔。首字快，长回答仍可能慢；生成很快，也可能先让人等很久。

对 Agent 而言，这三段都重要。一次排查可能先读项目说明和代码，再调用工具、读返回结果、接着分析。前面的大段内容反复出现，后面逐轮增加。如果每轮都重新计算十几万 token，用户感到的就是“每问一句，都要再等一次”。

因此，这轮调优没有只追短题的最高 tok/s。短请求要灵敏，长输入第一次要能接受，接续任务时还得把已有计算利用起来。

两台机器给了空间，也带来了新的账

GB10 的 CPU 和 GPU 共用一池内存。每台128GB，操作系统、模型权重、缓存和临时计算空间，都要从中分配。部署时不能把128GB当成完全独占的显存，再额外给CPU算一份内存。

这套配置采用 TP2，也就是两路张量并行。主要层内张量分片给两个计算进程，两边协同计算同一层，每台承担一部分运算，再交换中间结果，合起来完成同一轮推理。这里的 rank，可以简单理解为参与运算的进程编号。

这样做为长上下文和并发留下了空间，也增加了同步开销。两台机器有两个内存池，并不会变成一块毫无通信成本的“256GB显卡”。至于单机能装下多少，还取决于权重布局、卸载方式、缓存精度和并发预算。这轮的目标很明确：让一个或两个长任务连续工作，先把双机这条路径调稳定。

NVFP4 则是权重使用的低精度表示方式。它用更少的位数储存数值，并配合缩放因子，降低部分权重的存储和读取开销。实际模型依然采用混合精度，不能从名字推断所有层和缓存都变成了4位。

这点与后面的优化直接相关：模型能放下以后，生成阶段仍要反复读取权重。读多少、按什么形状读、调用哪条算子路径，都会影响每秒能吐出多少 token。

长任务接着做，缓存究竟留下了什么

前缀缓存保存的是已经算过的中间结果。它不把上一次答案直接拿来回复，也不按“语义差不多”随便匹配。输入前面一段保持一致，缓存还没有被淘汰，服务才能少算一部分。

Qwen3.8-Flash-Next 的情况比纯注意力模型多一层。它混合使用 Gated DeltaNet，简称 GDN，以及 Qwen Sparse Attention，简称 QSA。可以先作这样的理解：GDN随着输入更新一份紧凑的循环状态，QSA则从历史信息中选择有用部分参与计算。前缀复用要让这些不同类型的状态相互对上。

常见的 KV cache，保存注意力计算所需的键和值。GDN的循环状态不是同一种东西。在引擎配置中，相关循环状态被归入 Mamba / SSM 缓存管理；SSM可以理解为状态空间模型这一类机制的简称。本文中的“BF16 SSM”，说的是循环状态采用BF16精度，不能与模型权重的NVFP4混为一谈。

这套服务最后保留了 align 策略和 retention 832。align要求缓存状态落在引擎可复用的对齐位置；retention在这里表示周期性状态检查点的 token 间隔。832不是总缓存容量，也不是一个会话只能保留832 token。状态检查点像沿途留的恢复位置，完整缓存预算还要看引擎实际分配。

这个间隔不能脱离 scheduler block，也就是调度使用的块大小来设置。一次把多token预测（MTP）的起草深度从3改到4后，有效块变成1616，原来的1600无法整除，服务就启动失败。后来形成的做法是：修改MTP深度或状态精度后，先看日志里的有效块大小，再设与之匹配的检查点间隔。

BF16每个状态元素占的空间比FP32小，但它也改变数值精度和缓存布局。整轮记录没有提供一份可以单独归因的BF16收益表，因而不能给它硬安一个“提速百分比”。最终选择要连同正确性、缓存复用和请求表现一起看。

最后还做了一个贴近连续工作的检查：两个不同的约12万 token 会话交替发送，返回原会话时，仍分别命中98.9%和99.1%，首字保持在0.6—0.7秒。这说明在这次测试中，两段长上下文都能被接续利用。

把这个结果放到常见Agent里，实际启发很直接：稳定的系统说明、工具定义和长期使用的材料放在前面，变化的指令、工具结果逐步追加。无缘无故重排工具列表、改写大段前缀，会让缓存更难复用。设计上下文的组织方式，也是在调服务的性能。

遇到“接着问同一材料，首字仍慢”，应先记录实际命中的前缀长度、缓存是否被挤掉，以及输入有没有被重新排列。先把这些查清，再考虑更快的预填充算子。否则，每轮重算的大段输入还在，仅把生成速度提高一点，连续工作的停顿并不会消失。

预填充先选对路径，再决定每块多大

处理同一段长输入，可以走不同的GPU算子实现。kernel就是这些直接完成计算的内核；FlashInfer和Triton/FLA提供了不同的实现路径。

在约2万 token 的单项对照里，原来使用Triton/FLA进行GDN预填充，冷首字8.87秒、短回答中位39 tok/s。换成FlashInfer后，冷首字8.37秒，短回答44 tok/s，热命中仍是17,600个 token。

随后把chunk从4096加到8192，冷首字反而回到8.67秒。chunk可以理解为分块处理长输入的调度粒度：一块变大，可能减少分块次数，也可能改变内存占用、算子效率，以及与生成请求共同调度的节奏。不能简单推定“每块更大就一定更快”。这轮因此保留FlashInfer和4096。

这组变化也没有解决所有缓存问题。改成稠密检查点保留，仍没让那段未对齐的尾部自动命中。算子路径、处理分块、状态检查点各管一部分工作，应该分别验证。后来的新镜像已经自动选中FlashInfer，旧的手工覆盖文件便不必继续挂载。

MTP多猜一步，为什么反而慢了

MTP是多 token 预测。在这里，它参与推测解码：先由较轻的起草路径提出几个候选 token，再交给完整目标模型验证。猜得合适，一次验证可以推进更多内容；猜得不好，就白做了一部分草稿工作。

所以MTP3与MTP4的差别，不是一个免费开关。多起草一个 token，需要额外计算，也可能增加内存和调度开销。

在同一轮对照里，MTP3的短回答中位速度约44 tok/s，3万 token 输入的冷首字9.3秒，热生成50—53 tok/s。改成MTP4后，短回答约42 tok/s，冷首字11.0秒，热生成43—45 tok/s。多猜一步，整体反而退了。

给MTP4打开 索引共享（index sharing）后，短回答来到45.5 tok/s，比44 tok/s快约3.4%，尚未达到预设的5%门槛。两轮长热生成分别是60和46 tok/s，波动很大。只挑60这个数字，会得到一份很好看的成绩；把两轮都放回去，就没有足够理由替换原配置。

这几组都答对了测试题，缓存也保持正常。正确性过关，让方案有资格继续比较；最终是否保留，还得看它有没有带来稳定的收益。后来在已经使用BF16和64K草稿词表的配置上，又单独测了MTP2，热生成慢约12%。MTP3因此被保留。

可迁移的经验是，起草深度应跟着任务选择。短问答、长代码、工具JSON的候选好猜程度不同；多起草一步节省的验证轮次，得足以抵偿新增工作。对自己的代表请求做同题对照，比照抄别人关闭思考时的最优档位更可靠。

接受率是另一个要一起看的指标：起草出的候选中，有多少被目标模型接受。它受题目、语言、采样方式和候选策略影响。同一服务跑完不同的一批题，历史平均接受率会变；比较时应取同题、同轮的值，不能直接拿两个进程累积了很久的均值作结论。

少读一张大表，草稿路径才真正快起来

这轮很值得展开的优化，是把MTP的草稿输出头缩到64K。

输出头可以理解为“给候选 token 打分的矩阵”。完整词表有248,320行，MTP每起草一个 token，都要在这张大表上计算并找出候选。MTP3一轮还要做三次。在内存带宽有限的机器上，这种重复读取相当可观。

实现保留了目标模型的完整输出头，只给起草路径准备一张较小的表。64K版本共有65,536行，两台机器各32,768行。每个rank在自己的候选里找最大值，然后交换最大分数及其对应的全局 token 编号；主模型继续用完整词表验收。

这些候选来自本机实际输出，补入Kotlin、Java、Gradle、Python、TypeScript、Shell、JSON、工具调用、diff、中文和推理文本。64K集合覆盖了这份语料里的全部 token。这里的100%有明确范围：就是用于构建和检查的这份语料，换业务、换语言，仍要重新看覆盖和接受情况。

为了找出收益来源，同日做了四组对照。

草稿路径	短回答	热生成	接受率
完整词表	39.5 tok/s	60 tok/s	56.2%
完整词表，仅改本地argmax	39.6 tok/s	60 tok/s	56.7%
64K候选词表	44.6 tok/s	70 tok/s	53.7%
32K候选词表	44.1 tok/s	71 tok/s	52.2%

argmax就是找最大分数所处的位置。第二组只改变了取最大值与交换结果的做法，速度几乎没动；缩小读取的候选头后，短回答快约13%，热生成快约17%。这组实验把主要收益指向了减少草稿头的读取与计算，而不是单纯少传几个数。

32K的热生成略高，但接受率比完整词表低约4个百分点，超过了预先设置的3个百分点门槛。它对复制类文本的语料覆盖也只有88%，Kotlin约94%。最后留下64K：本轮接受率下降约2.5个百分点，短回答更快，业务语料覆盖也更稳妥。

这组结果还说明，接受率需要和候选生成的成本一起看。64K猜中的比例略低，但每次起草更省，整题推进反而更快。接受率是解释性能的线索，不能单独作为胜负标准，也不等于最终答案的准确率。同样，候选表也应跟着业务变化检查：今天主要跑代码和工具调用，明天增加另一种语言或大量复制任务，原来的64K集合就需要重新验收。

这个选择还有一笔内存开销：完整输出头没有释放，64K小头每台额外占约160MiB。这里追求的是每次起草少读权重，不能把它写成“又省下一大块模型内存”。

记录中的确定性正文、工具名和参数回归，与完整词表保持一致。完整目标模型验证是这条优化路径成立的关键，自定义实现仍需要检查 token 编号映射、分片边界和采样行为。把“当前测试通过”保留为具体事实，比简单写一句“无损提速”更有参考价值。

上游也在改这处瓶颈。vLLM的#59740使用32K固定候选加16K动态候选，作者在单台GB10上报告，相对完整BF16草稿头，NVFP4候选行方案提升约23%。截至2026年10月7日，这项PR仍未合并，其当前动态候选实现要求TP1，而且对照是完整头。因此，它可以解释这个方向为何值得关注，还不能直接当成当前双机64K配置的下一笔额外收益。

同样写着GB10，调优表未必真的用上

MoE是混合专家结构，模型通过路由选择部分专家参与计算。算子要处理的形状，与专家数量、张量并行方式和实际批量都有关系。

镜像里有一张标着GB10的MoE调优表，不代表它会用于眼前这个模型。当时现成表的中间维度是512、block形状为128×128；本机日志对应512个专家、TP2之后中间维度320、block为64×64。文件名匹配不上，引擎仍会走默认配置。

针对实际形状搜索之后，小批量算子的耗时下降6%—14%。请求级对照进一步确认：两边都做相同启动预热（warmup），只差这张表，短回答中位速度从43到51 tok/s；长输入冷首字和25,600个缓存 token 没变。

这里还区分了小批量生成和大块预填充。M表示算子一次处理的 token 行数，不是整段对话的长度。调优覆盖M从1到64；M达到96及以上，仍保留引擎默认配置，避免为生成阶段选的小计算块（tile）拖累长输入处理。

专家并行EP也试过。它把不同专家放到不同设备，再把 token 路由到相应专家，与TP切分张量的方式不同。这套服务通常只有一个或两个长请求，开启EP后短回答慢约12%；专门为EP再调表，仍慢约10%，因此没有保留。这个结果反映的是当前负载的取舍，不能推广成EP普遍无效。

还有一些收益很小、但判断很清楚的项目。GDN直接从状态池读写，减少外部搬运步骤，本轮热生成提高约3.9%；手工缩小CUDA Graph捕获尺寸没有收益，回到自动。CUDA Graph可以减少反复提交GPU运算的开销，这套配置选择只完整捕获decode路径。

甚至“算子已经快了”也还没结束。给64K草稿头补上32,768×2,560的匹配形状后，新路径确实命中，但整题速度没有分离出清晰改善。局部耗时下降，可能被其它工作、同步或测量波动盖住。对最终使用者来说，能感觉到的是整次请求，而不是某个算子单独跑得多漂亮。

这里可以设两个连续的检查点。先用加载日志，必要时再做性能分析，确认预期的优化路径确实执行了；再看固定请求，证明用户等待真的减少。MoE表从43到51 tok/s走过了这两步，草稿头补形状只走过第一步。尚未显现请求收益的改动，可以继续研究，不必急着增加到长期维护的配置里。

首请求的1.28秒，最后被搬到了启动阶段

一次收紧并发设置后，服务重启，第一条短请求等了1.28秒才出字，后面却只需要0.13秒。日志里能看到，QSA、fused MoE和LayerNorm在首请求中触发了JIT，也就是即时编译。

把几类代表请求放到启动后的warmup预热里，正式接入的第一条短请求就也到了0.13秒。预热约花12秒，相比9—10分钟的完整启动，代价很小，稳态速度也没有下降。

这不是模型突然算快了近十倍，而是把首次编译的等待提前完成了。以后做新旧版本对照，两边都先预热，再发同样的测试请求。这条小规则，避免了把“刚启动的新服务”和“已经跑了几个小时的旧服务”拿来直接比。

升级本身更考验这类本地服务。早先一次nightly试验，同时换镜像、移除8个本地补丁，并打开Engram CPU offload，结果短回答慢约三分之一，冷首字接近翻倍。这个试验否定了当时的整套组合，却无法把退步单独归给新引擎。

一次新镜像继续挂着旧的platforms_interface.py，新代码调用validate_environ，旧文件却没有这个接口。worker立即退出，head还在等另一个rank加入，601秒后才报集合通信超时。

下一次启动又连到残留的旧容器，再等一轮。外层十分钟超时随后触发清理，两边容器被删除，又要从加载权重开始。正常加载本来就接近十分钟，这个超时值把恢复过程也一起打断了。

后来换到新镜像时，先检查哪些兼容改动仍然需要。新版本已经自动选用FlashInfer GDN，旧GDN和FLA覆盖文件便不再挂载；保留必要的配置类导入、QSA层别名以及经过验证的权重映射，关闭这套部署未采用的Engram CPU offload。

同一条256输出token代码题，旧版本中位约42 tok/s，新版本两轮是47和48 tok/s。这个结果只属于这条对照题；它与开头2,048输出的长输入测试分开记录，也没有拿来串成总涨幅。

服务准备好，应该意味着加载、通信和代表性预热都完成，随后还要有一组固定请求确认质量与缓存。仅看进程还活着，或者端口已打开，都不足以说明员工马上能顺畅使用。

因此，一份可复用的部署记录最好同时留下镜像标识、权重版本、覆盖文件清单、实际生效参数和验收请求。升级前知道旧组合怎样恢复，升级后核对新引擎已经包含哪些能力，及时撤掉过时的覆盖文件。如此积累下来的，是可恢复的服务，而不是一串越来越难解释的补丁。

遇到慢请求，先决定该动哪一处

前面的实验，可以整理成一张诊断表。拿到一条“很慢”的反馈，先问它发生在什么时候，再看对应证据。表中没有本机测值的项目，列的是接下来应观测的内容。

慢在哪里	先核对的证据	本例带来的判断与动作
重启后第一条慢，后续快	首次请求日志里是否发生JIT；预热是否覆盖常用路径	1.28秒到0.13秒主要来自提前预热。把准备工作移到服务接入前，再做性能对照
长输入第一轮首字慢	输入长度、冷缓存状态、prefill算子和分块配置	约2万输入换FlashInfer后8.87降到8.37秒；chunk8192反而回8.67秒。按本机实测选路径和粒度
接着问同一材料，首字仍慢	实际命中token数、前缀是否一致、缓存淘汰与状态对齐	最终13.2万输入冷42.9秒、热0.69秒。先检查复用是否成立，再追更高生成速度
首字出来了，后面生成慢	MTP的起草成本与接受情况、实际算子形状、整题耗时	64K接受率略降却生成更快；MTP4反而慢。以质量过关后的请求收益作取舍
单人顺畅，一起用就等	队列等待、同时活动序列、长短请求混合、缓存挤占	seqs=2是调度设置，不是账号数。先测真实混合负载，再决定排队策略或扩容；本轮没有据此给出可支持人数

对本轮这类反复接续长上下文的任务，调优可以按这个顺序推进：先固定真实任务和质量基线，保证每次比较的是同一件事；接着解决反复重算和缓存失效；确认生成仍慢，再看MTP、输出头和MoE等热点。单请求路径已经顺了，才有条件测多人混合使用时的排队和资源分配。每轮打算保留的新组合，都应重新走一次启动与恢复。

这个顺序会随工作改变。以一次性长材料分析为主，冷首字更值得优先改；以多轮代码和工具调用为主，前缀复用通常更有价值；高并发场景更关心总体吞吐和等待分布，不能把这一两个长请求留下的参数原样搬过去。

一个改动怎样才值得留下

“跑得起来”之后，还要过几项实用检查：业务答案和工具参数是否正确，同样请求有没有更快，热缓存有没有退步，重启后能否重现，额外维护是否值得。

本次64K表在代码、中文、工具JSON与复制类样本上检查过，并保留完整目标模型验收；MoE调优同时核对了加载日志和请求收益。整包nightly试验出现退步，就先退回已知组合，不能据此把新引擎单独判为更慢。收益很小、波动很大，或者需要长期维护大量覆盖文件时，暂时不留也是合理的工程选择。

实际执行时，保留一套固定验收请求很实用：双方完成同样预热，再跑短请求；长输入一冷两热，分别记首字、生成速度和命中数量；交替访问两个长会话；最后检查业务输出，并验证一次重启恢复。数字和日志放在一起，下次换引擎时才能知道自己究竟得到了什么、失去了什么。

这轮留下的配置索引

最终服务使用vLLM 0.30.1rc1.dev648，镜像标识15c7ef9050b6，权重revision为fc694b54。下表记录的是本轮选择，本地词表文件、调优表和兼容改动仍是实现的一部分。

配置项	最终选择	主要考虑
并行与调度	TP2，max_num_seqs=2	支持当前少量长任务
长输入分块	chunk 4096	采用本机对照留下的粒度
内存预算	gpu_memory_utilization=0.70	为服务其它开销留空间
推测解码	MTP3，64K balanced draft，本地argmax	兼顾生成速度与接受情况
状态与缓存	BF16 SSM，align，retention 832	与有效block匹配并验证复用
专家计算	匹配本地形状的MoE表，无EP	以低并发请求表现为准
网络	单网卡rocep1s0f1:1	沿用已验证互联路径
执行图	FULL_DECODE_ONLY，自动capture	保留实际有用的捕获方式
Engram	cpu_offload=false	采用当前验证过的组合

这套服务怎样进入实际工作

对常用编码Agent，长上下文里往往有项目约定、代码和多轮工具结果。稳定的热首字能减少接续时的空等，生成速度则决定每轮分析和修改推进得多快。团队共享这类小型服务时，还要把交互请求、长任务和后台任务合理安排，避免所有工作同时抢占有限资源。

在MEASIX的自托管方案里，本地模型可以成为企业自己提供的一项资源：通过枢策 Orchelm 组织模型和工具配置，再提供给员工使用的领航 Pilot。小睿助手借助这些资源理解现场输入，调用相应专业软件处理任务。模型服务负责推理，专业工具执行实际操作，结果回到员工面前查验。

例如员工带着设备资料和零件要求，连续调整一个测量方案。前面稳定的业务说明和工具定义有机会复用，新增的图纸说明、配置变化与测量结果继续进入上下文。此时，缓存的价值是让这个工作过程更连贯；专业结果仍由测量软件及实际验证给出。松子 Tuck 这类持续推进的后台工作伙伴，也适合把不要求立即完成的任务排队执行，减少与现场交互争用推理资源。

这套试验围绕一两个长任务展开，给出了一个具体、可用的起点。继续扩大员工使用范围时，应再测排队等待、任务混合和缓存淘汰，而不是把“seqs=2”直接换算成两个用户，或把单流62 tok/s当成所有人同时能分到的速度。

这轮实践最明确的结论，是双Spark配合这套Qwen3.8 Flash配置，已经验证了少量长上下文任务接续使用的可行性：长输入第一次的等待可以量出来，已有材料再利用时能迅速出首个token，长回答也能保持可用的生成速度。它适合成为个人和小团队持续任务的一种本地推理资源。

真正值得照着做的，是先分清等待发生在哪里，再用同题对照选出有净收益的改动，最后把重启恢复也纳入验收。MTP3、64K、EP关闭只是这次留下的答案；换了负载，答案可以变，这套判断方法仍然有用。

企业继续往前做，则要把推理资源、专业工具和可用的方法一起提供给员工。现场能接着做事，后台任务能合理等待，遇到升级又能恢复服务，本地模型才逐渐成为一项可靠的工作条件。最高的一次tok/s可以吸引注意，决定它能用多久的，还是这些平常但具体的工程选择。

资料与说明

性能数据来自本次双GB10部署与调优记录，各组保留自己的测试对照。技术图依据记录和官方机制独立绘制，封面为概念插画。机制参考：vLLM推测解码、vLLM缓存配置源码、NVIDIA模型卡。上游草稿头方案见vLLM #59740，文中采用核对时的未合并状态。