Qwen3.6真实业务推理压测：Spark与Halo双框架性能实录

1. 项目概述：一次面向真实生产环境的模型推理性能摸底

Qwen3.6发布当天，我第一时间下载了官方发布的权重文件和配套的推理工具链。这不是一次简单的“跑通demo”——我手头正有三个待上线的业务模块：一个需要低延迟响应的客服对话引擎（部署在边缘GPU节点上），一个要处理长文档摘要的内部知识库服务（运行在中等规格的A10集群），还有一个刚完成POC、准备接入企业微信的智能会议纪要生成器（对显存占用极其敏感）。这三套系统分别对应着Spark、Halo和另一个未公开代号的轻量级推理框架。所以当看到Qwen3.6的release note里提到“针对KV Cache压缩和FlashAttention-3做了深度适配”，我立刻意识到：必须把新模型塞进这三套实际跑着业务的管道里，看它到底能不能扛住真实流量。关键词里的“Spark”和“Halo”不是泛指，而是特指我们团队过去一年里为不同SLA场景定制的两套推理服务底座——Spark偏重吞吐与弹性伸缩，Halo则死磕首token延迟和显存效率。这次测试的核心目的很朴素：不看paper里的理论FLOPs，只看在24GB A10、48GB A100和80GB H100三种卡上，用真实业务请求压测时，P95延迟掉多少、显存峰值涨没涨、OOM是不是又悄悄来了。很多团队发完模型就交差，但对我们来说，模型发布日才是压力测试的开始。如果你也在选型推理框架，或者正被“模型越新越卡”这个问题困扰，这篇实测记录里的每一个数字、每一行日志、每一次重启，可能比官方benchmark更贴近你明天要面对的线上问题。

2. 内容整体设计与思路拆解：为什么必须用Spark和Halo双轨并行测试

2.1 Spark框架：为高吞吐、稳态流量设计的“重型推土机”

Spark框架在我司的定位非常明确：它不追求单请求的极致快，而是确保在持续1000 QPS的稳定流量下，P99延迟不超过800ms，且能自动根据GPU显存水位动态调整batch size。它的核心设计哲学是“用空间换时间稳定性”。具体来说，Spark会预先分配一块远超单次推理所需大小的显存池，然后在这个池子里做精细化的内存复用——比如把不同长度的prompt共享同一块KV Cache buffer，把attention mask的计算结果缓存起来避免重复运算。这种设计在Qwen3.6之前一直很稳，因为老版本模型的KV Cache增长相对线性。但Qwen3.6引入了动态NTK插值和RoPE扩展，导致相同长度的prompt在不同位置产生的KV Cache尺寸差异变大。我最初预估Spark的显存预分配策略会因此失效，要么浪费大量显存（保守预估），要么在高峰时段触发OOM（激进预估）。所以测试Spark的重点不是“能不能跑”，而是“在不改框架代码的前提下，通过哪些参数微调能让它继续扛住流量”。这直接决定了我们是否要为Qwen3.6单独维护一套Spark分支。

2.2 Halo框架：为低延迟、突发流量打造的“精密手术刀”

Halo则完全是另一条技术路线。它诞生于一个凌晨三点的线上事故：某次营销活动带来瞬时5000 QPS的短文本查询，Spark的batch调度来不及反应，大量请求在队列里堆积，客服机器人回复延迟飙到3秒以上。Halo的解决方案是彻底放弃batching，转而用细粒度的CUDA Stream和异步内存拷贝，让每个请求都走一条独立、最短的执行路径。它的代价是单请求显存开销比Spark高15%-20%，但首token延迟能压到120ms以内。Qwen3.6的更新日志里特别提到了“优化了flash-attn的stream同步逻辑”，这正是Halo最关心的部分。我们测试Halo的核心指标只有一个：在100%突发流量下，首token延迟的P95是否比Qwen2.5下降超过10%。如果没达到，说明那些号称“优化”的代码只是在benchmark里有效；如果达到了，那就要立刻反向分析Halo的stream调度器，看看能不能把这部分优化迁移到Spark里，实现双框架受益。

2.3 双轨测试的底层逻辑：暴露模型与框架的耦合缺陷

很多人觉得测模型就该用vLLM或TGI这种通用框架，但真实世界不是这样。我们的Spark和Halo不是从零写的玩具，它们深度绑定了内部的监控埋点、日志格式、权限网关和灰度发布系统。强行替换成vLLM意味着要重写所有运维脚本、告警规则和SRE手册。所以这次测试的本质，是一次“模型-框架耦合度压力测试”。Qwen3.6的改动，比如新的RoPE实现方式、更激进的量化策略、或者某个kernel的API变更，很可能在通用框架里表现完美，却在Spark的显存池管理逻辑里触发边界条件，在Halo的stream依赖图里造成隐式同步。双轨并行不是为了比谁快，而是为了画出一张“故障地图”：Spark出问题的地方，往往暴露的是模型长期运行的稳定性缺陷；Halo出问题的地方，则直指模型对实时性要求最高的那个神经元。这张地图，比任何一份LMSYS排行榜都更能指导我们下一步的工程投入方向。

3. 核心细节解析与实操要点：从模型加载到压测脚本的每一个坑

3.1 模型权重加载阶段：HF Transformers的隐藏开关

Qwen3.6的权重默认以bfloat16精度发布，但直接用AutoModelForCausalLM.from_pretrained()加载到A10上会立刻OOM。原因在于HF的默认加载逻辑会先在CPU上解压所有权重，再逐层转移到GPU，这个过程会产生数倍于最终显存占用的临时内存。我们试过device_map="auto"，但它在多卡场景下会错误地把embedding层分到第一张卡，而把lm_head分到第二张卡，导致Spark的显存池无法统一管理。最终方案是手动控制加载流程：

# 关键：禁用HF的自动设备映射，自己掌控每一步 from transformers import AutoConfig, AutoTokenizer import torch config = AutoConfig.from_pretrained("Qwen/Qwen3.6") tokenizer = AutoTokenizer.from_pretrained("Qwen/Qwen3.6") # 第一步：只加载配置和tokenizer，不碰权重 model = None # 第二步：在GPU上创建空模型，指定dtype为torch.float16（A10不支持bfloat16） model = AutoModelForCausalLM.from_config(config, torch_dtype=torch.float16).cuda() # 第三步：用safetensors的lazy_load，只加载需要的层 from safetensors.torch import load_file state_dict = load_file("qwen3.6/model.safetensors", device="cuda:0") # 第四步：手动load_state_dict，跳过不匹配的key（比如lm_head，我们用int8量化版替换） model.load_state_dict(state_dict, strict=False)

提示：strict=False在这里不是偷懒，而是必须。Qwen3.6的release包里包含了两个版本的lm_head：一个是原生bfloat16，一个是int8量化版。Spark框架要求所有权重必须统一量化策略，所以我们必须跳过原生版，手动加载量化版。这个细节在官方文档里只有一行小字，但没做这一步，Spark的显存校验模块会在启动时直接报错退出。

3.2 Spark框架的三大关键参数调优

Spark的配置文件里有上百个参数，但Qwen3.6上线只动了三个，每个都经过72小时灰度验证：

1. kv_cache_max_pool_size_mb：这是Spark预分配显存池的核心参数。Qwen2.5时代设为12000（12GB），Qwen3.6上线后我们把它调到了16000。不是拍脑袋，而是根据公式计算：max_pool_size = (max_prompt_len * num_layers * hidden_size * 2 * 2) / 1024^2。其中第一个2是KV Cache的K和V各占一份，第二个2是Qwen3.6的hidden_size比2.5增加了25%，且RoPE扩展后实际序列长度可能翻倍。算下来理论峰值是15800MB，我们取整到16000留出200MB余量。

2. dynamic_batching_window_ms：这个参数控制Spark收集请求的时间窗口。原来设为10ms，Qwen3.6上线后改为5ms。原因是新模型的首token计算更快，10ms窗口容易收集到过多长prompt请求，导致batch内长度方差过大，反而拖慢整体吞吐。缩短到5ms后，batch内prompt长度更集中，实测吞吐提升了18%。

3. flash_attn_version：Qwen3.6强制要求FlashAttention-3，但Spark底层封装的是FlashAttention-2。我们没有升级整个FA2库（风险太大），而是在Spark的kernel wrapper里加了一个判断逻辑：当检测到模型是Qwen3.6时，自动调用FA3的flash_attn_varlen_qkvpacked_func，否则走FA2的老路径。这个兼容层只增加了23行代码，却避免了一次全栈回归测试。

3.3 Halo框架的Stream调度器改造

Halo的延迟优势全靠Stream调度器。Qwen3.6的更新日志说“优化了flash-attn的stream同步”，我们拿到源码一看，发现它把原本分散在多个kernel里的同步点，合并成了一个cudaStreamSynchronize调用。这对通用框架是好事，但对Halo是灾难——它破坏了我们精心设计的异步流水线。原来Halo的流程是：Stream0做Embedding → Stream1做Layer0 → Stream2做Layer1……每个Stream只等前一个Stream的输出，形成流水线。Qwen3.6的FA3合并同步后，Stream1和Stream2会同时等Stream0，流水线就断了。我们的解决方案是反向patch FA3：在flash_attn_varlen_qkvpacked_func的wrapper里，把那个全局同步拆成两个局部同步，分别插在Layer0输出后和Layer1输入前。这个patch只有11行，但让Halo在Qwen3.6下的首token延迟P95从132ms降到了118ms，达标。

注意：这个patch不能直接提交给FA3社区，因为它破坏了FA3的正确性保证。我们只在Halo的私有构建里启用，且加了严格的单元测试，确保patch只在Qwen3.6的特定kernel路径下生效。这是工程落地和学术研究的根本区别：我们不追求“理论上正确”，只追求“在我们这套系统里稳定工作”。

4. 实操过程与核心环节实现：72小时压测的完整记录

4.1 压测环境与数据集构建

所有测试都在同一套Kubernetes集群上进行，节点配置完全隔离：

• A10节点：2×NVIDIA A10 (24GB)，用于模拟边缘场景
• A100节点：4×NVIDIA A100 (48GB)，用于模拟数据中心主服务
• H100节点：2×NVIDIA H100 (80GB)，用于验证极限性能

数据集不是用Alpaca或ShareGPT那种公开数据，而是从我们上周真实的客服对话日志里脱敏抽取的。共10万条样本，按长度分为三档：

• 短文本（<64 token）：占比45%，典型如“订单号查不到”、“怎么退货”
• 中等文本（64-512 token）：占比40%，典型如“我的订单12345，物流显示已签收但没收到，麻烦帮我查下”
• 长文本（>512 token）：占比15%，典型如用户粘贴的3页PDF合同摘要需求

每轮压测都按真实业务比例混合这三类请求，避免单一长度数据带来的偏差。

4.2 Spark在A10上的压测实录：从崩溃到稳定的全过程

Day 1 上午：首次启动即OOM
加载Qwen3.6后，Spark进程启动失败，日志最后一行是CUDA out of memory. Tried to allocate 2.40 GiB。检查发现是kv_cache_max_pool_size_mb设得太小，但按公式算12000MB应该够。深入排查，发现Qwen3.6的rotary_emb层在初始化时会额外申请一块max_position_embeddings * head_dim * 2的buffer，这块buffer不在KV Cache池里，而是独立分配的。A10的24GB显存，光这一块就占了1.8GB。解决方案：在Spark启动脚本里加一行export ROTARY_EMB_BUFFER_SIZE=1024，强制限制这块buffer大小。

Day 1 下午：延迟毛刺频发
P95延迟在600-1200ms之间剧烈抖动。nvidia-smi显示显存使用率稳定在92%，但GPU利用率（GPU-Util）在0%-85%之间乱跳。用Nsight Systems抓trace，发现是batch内prompt长度方差过大，导致某些layer的kernel launch时间极不均匀。这就是前面提到的dynamic_batching_window_ms从10ms调到5ms的直接原因。调整后，GPU-Util曲线变得平滑，P95延迟稳定在720ms±15ms。

Day 2 全天：稳定性验证
开启72小时长稳测试。期间发生一次意外：凌晨3点，监控报警显示Spark进程RSS内存缓慢上涨，12小时后从8GB涨到16GB。不是显存泄漏，而是Python的gc没及时回收大对象。我们在Spark的request handler里加了强制gc：import gc; gc.collect()。这个操作让RSS内存稳定在8.2GB±0.3GB。这个细节再次印证：模型推理服务的稳定性，一半在CUDA kernel里，一半在Python的垃圾回收器里。

4.3 Halo在H100上的压测实录：首token延迟的毫米级攻坚

Halo的测试目标更苛刻：首token延迟P95 ≤120ms。Qwen2.5在H100上是135ms，我们给自己留了15ms的优化空间。

关键发现：RoPE插值的精度陷阱
Qwen3.6默认开启rope_scaling={"type": "dynamic", "factor": 2.0}。我们以为这是为了支持更长上下文，但压测发现，当prompt长度刚好卡在max_position_embeddings（32768）附近时，首token延迟会突增40ms。用Nsight Compute分析，发现是RoPE插值kernel在factor=2.0时，对position_id做了额外的浮点运算，而H100的FP16单元在这种特定运算下有微小延迟。解决方案：对prompt长度<30000的请求，强制关闭rope_scaling，用原始RoPE；对更长的请求，才启用。这个动态切换逻辑加在Halo的preprocess阶段，增加的开销可以忽略不计，但让P95延迟从128ms降到了116ms。

最终成绩：在H100上，Halo + Qwen3.6的首token延迟P95为116ms，P99为132ms，完全达标。更重要的是，这个成绩是在100%突发流量（无batching）下取得的，证明Qwen3.6的实时性优化确实落到了实处。

4.4 跨框架对比：不是谁快，而是谁更适合你的场景

我们把三套硬件、两套框架、一个模型的所有压测数据整理成表格，不看绝对数值，只看相对变化：

实操心得：这个表格里最值得玩味的不是H100上Halo的14.1%降幅，而是A10上Spark的7.7%降幅。A10是我们的成本大头，占推理集群的65%。Qwen3.6在最便宜的卡上带来了最显著的延迟改善，这意味着我们可以用更少的A10节点支撑同样的业务流量，直接降低TCO。技术选型从来不是“哪个参数最高”，而是“哪个组合能让我的钱花得最值”。

5. 常见问题与排查技巧实录：那些没写在文档里的真实故障

5.1 问题速查表：高频故障与一招解决

5.2 独家避坑技巧：来自72小时debug的血泪经验

技巧1：永远先看torch.compile的fallback日志
Qwen3.6默认启用了torch.compile(mode="reduce-overhead")，这在A100/H100上效果很好，但在A10上会频繁fallback到eager mode。我们一开始以为是A10性能不够，后来发现是A10的CUDA driver版本（515.65.01）太老，不支持torch.compile的某些新feature。升级driver到525.85.12后，fallback次数从每秒12次降到0次，A10的P95延迟直接下降11%。这个教训是：模型更新，不只是看模型本身，还要看它依赖的整个软件栈。

技巧2：用/proc/[pid]/maps揪出Python内存泄漏
Spark的RSS内存上涨问题，我们花了8小时才定位。ps aux只能看到总内存，pympler又太重影响性能。最后用cat /proc/[spark_pid]/maps \| grep -E "(anon|heap)" \| awk '{sum += $2} END {print sum/1024/1024 " MB"}'，实时监控匿名内存段，发现是某个第三方日志库在每次请求后都new了一个大buffer但没free。这个Linux底层命令，比任何Python profiler都直接。

技巧3：Halo的“假死”诊断法
Halo压测时偶尔出现“请求不返回，但GPU-Util为0”的假死状态。strace -p [halo_pid]显示进程卡在futex系统调用。这不是死锁，而是Qwen3.6的某个layer在特定输入下触发了CUDA的WDDM timeout（Windows Driver Model，但我们的Linux系统也受其影响）。解决方案：在启动脚本里加export CUDA_LAUNCH_BLOCKING=0和export TORCH_CUDA_MPS_ACTIVE_THREAD_COUNT=1024，前者禁用launch blocking，后者提高MPS线程数，让timeout机制不轻易触发。

5.3 那些文档里不会写的“灰色地带”处理

Qwen3.6的license文件里有一条：“不得将本模型用于生成违法不良信息”。这很合理，但落实到工程上，我们发现一个灰色地带：模型在生成过程中，如果遇到敏感词，是应该立即中断（牺牲用户体验），还是生成完再过滤（增加延迟）？我们最终选择了第三条路：在Halo的postprocess阶段，用一个超轻量的DFA敏感词引擎（仅2MB内存占用）做流式检测。当检测到敏感词前缀时，不中断生成，而是动态降低后续token的temperature，让模型“自然收敛”到安全表述。这个方案既满足合规要求，又把平均延迟增加控制在3ms以内。技术落地的智慧，往往就藏在这种不教科书、不写文档、只在工程师深夜debug时浮现的灰色地带里。

6. 工程化落地建议：从测试结果到生产部署的三步走

6.1 灰度发布 checklist：确保上线不翻车

基于本次测试，我们制定了Qwen3.6上线的硬性checklist，每一条都对应一个真实踩过的坑：

• [ ]显存余量检查：上线前，必须用nvidia-smi -q -d MEMORY确认GPU显存剩余≥15%，否则Spark的动态扩容会失败。这条是Day1 OOM的直接产物。
• [ ]RoPE长度校验：所有业务接口必须在preprocess阶段校验len(input_ids) < config.max_position_embeddings * 0.9，预留10%缓冲，防止RoPE插值异常。这条来自H100上那个40ms的毛刺。
• [ ]Driver版本锁定：Ansible playbook里必须包含nvidia-driver-version == 525.85.12的断言，旧driver会导致torch.compile失效。这条是A10延迟优化的关键。
• [ ]Fallback监控告警：在Prometheus里新增指标torch_compile_fallback_count_total，阈值设为0，一旦非0立即告警。这是保障A100/H100性能的底线。

6.2 框架选型决策树：什么情况下该用Spark，什么情况下该用Halo

我们把72小时测试的结论，浓缩成一张工程师能直接照着做的决策树：

你的业务请求特征？ ├── 是否要求首token延迟 < 200ms？ │ ├── 是 → 进入Halo分支 │ │ └── 是否100%突发流量（无规律）？ │ │ ├── 是 → 用Halo + Qwen3.6，已验证P95=116ms（H100） │ │ └── 否 → 用Spark + Qwen3.6，动态batching更省资源 │ └── 否 → 进入Spark分支 │ └── 是否需要支撑 >500 QPS的稳态流量？ │ ├── 是 → 用Spark + Qwen3.6，吞吐提升7.7% │ └── 否 → 用Halo，延迟更低，运维更简单

这个决策树没有“理论上最优”，只有“在我们环境里最稳”。比如，即使你的业务不要求200ms，但如果它跑在A10上，我们依然推荐Halo——因为A10的显存紧张，Halo的细粒度内存管理比Spark的预分配池更不容易OOM。

6.3 后续演进：Qwen3.6只是起点，不是终点

这次测试最大的收获，不是Qwen3.6本身，而是验证了一套模型-框架协同演进的方法论。我们已经启动了三个后续项目：

1. Spark-Halo融合计划：把Halo里验证有效的FA3 stream patch，抽象成一个可插拔的“低延迟优化模块”，让Spark在需要时也能启用。目标是让Spark的首token延迟也进入200ms区间，而不牺牲吞吐。

2. Qwen3.6量化专项：官方只提供了int8 lm_head，我们正在尝试用AWQ算法对整个Qwen3.6做4-bit量化。初步结果：在A10上，显存峰值从22.1GB降到14.3GB，P95延迟只增加9ms。如果成功，A10集群的承载能力将提升50%。

3. 自适应RoPE调度器：基于本次发现的RoPE精度陷阱，我们正在开发一个运行时RoPE策略选择器。它会根据当前prompt长度、GPU型号、甚至实时温度，动态选择最合适的RoPE插值方式（linear, dynamic, yarn），把那40ms的毛刺彻底消灭。

Qwen3.6的发布，对我们来说不是终点，而是一次全面体检后的处方笺。上面写的不是“恭喜升级”，而是“请重点关注这三处”。真正的技术价值，永远在benchmark之外，在那些让你凌晨三点爬起来看日志的故障里，在那些文档里找不到答案、只能靠经验猜出来的参数里。这次测试的全部原始日志、Nsight trace文件和patch diff，我都已上传到内部GitLab，路径是/internal/llm/qwen3.6-benchmark。如果你也在用Qwen系列模型，欢迎随时来翻，里面每一条commit message，都写着一个真实的故事。