Qwen3.8-Flash-Next-NVFP4 对比 Qwen3.8-27B-FP 测试结果

## Qwen3.8-Flash-Next-NVFP4 (inferact) 与 Qwen3.8-27B-FP8 (qwen) 的对决 最近实在太忙，没时间美化格式。这份报告大部分由Qwen撰写，但我亲自验证了所有数据。所有测试在同一台设备上进行，使用相同的提示词，且多数测试基于我实际的工作负载。 **本地单卡评测配置：** 一块 RTX PRO 6000 Blackwell Max-Q (96 GB, SM120) + 256 GB DDR5 内存，使用 vLLM nightly 版本。两个模型通过同一服务别名和端口交替部署——这正是我的智能体技术栈实际调用的接口，涵盖文本评分流水线、记忆整合、本地深度研究、浏览器自动化等任务。尽量减少代码改动，因为下游服务依赖该别名，所以替换背后的模型是检验兼容性的诚实方法。 **测试模型：** - Qwen3.8-Flash-Next-NVFP4 (https://huggingface.co/Inferact/Qwen3.8-Flash-Next-NVFP4) - Qwen3.8-27B-FP8 (https://huggingface.co/Qwen/Qwen3.8-27B-FP8) 以下所有提示词、测试用例和评分标准在两次测试中完全一致——唯一变量是部署的模型。 **简言之：** Flash-Next **更快且机械层面完美无缺**（严格JSON输出、抗注入攻击、SLA：零违规），并在高推理要求的空间/代码生成任务中凭借更优的失败模式胜出。而稠密的27B模型仍在持续多步符号推理任务（如修复bug、数学证明、抽象谜题）中占优。Flash-Next在此类任务中暴露出一种新的故障模式：承诺交付成果、宣布“完成”，却输出空结果。相同的 `reasoning_effort` 参数，却产生截然不同的行为语义。因此，它不能直接替换，仅可条件性升级。 ## 实际部署配置（我实际运行的参数） **Flash-Next：** ```bash docker run vllm/vllm-openai:qwen38-flash-next \ -e VLLM_PLE_CPU_OFFLOAD=1 \ # 将约100GB n-gram嵌入表暂存至主机内存 -e VLLM_API_KEY=*** \ --entrypoint vllm serve Inferact/Qwen3.8-Flash-Next-NVFP4 \ --max-model-len 200704 \ # ~200K（原生支持262K） --gpu-memory-utilization 0.91 \ --max-num-seqs 16 \ # 延迟优先，单工作站设置 --no-enable-flashinfer-autotune \ # 混合注意力路径自动选择后端 --structured-outputs-config '{"backend":"xgrammar","disable_any_whitespace":true}' \ --enable-prefix-caching --enable-chunked-prefill \ --reasoning-parser qwen3 --enable-auto-tool-choice --tool-call-parser qwen3_coder \ --speculative-config '{"method":"mtp","num_speculative_tokens":3}' \ --served-model-name llm-large ``` **实战经验：** PyPI预编译包不支持此架构，仅限专用镜像。配置中的 `xgrammar` 参数继承自我的27B配置，后来发现它至关重要（移除后出现无声卡顿）。实测：生成速度约177 tok/s，MTP草稿接受长度约2.1。 **3.8-27B：** ```bash python3 -m vllm.entrypoints.openai.api_server \ --model Qwen3.8-27B-FP8 --max-model-len 262144 --kv-cache-dtype fp8 \ --gpu-memory-utilization 0.52 --max-num-seqs 16 --attention-backend FLASHINFER \ --structured-outputs-config '{"backend":"xgrammar","disable_any_whitespace":true}' \ --reasoning-parser qwen3 --enable-auto-tool-choice --tool-call-parser qwen3_coder \ --speculative-config '{"method":"mtp","num_speculative_tokens":2}' \ --served-model-name llm-large ``` **变量控制：** 采样器默认参数（`enable_thinking`、MTP、xgrammar）在两模型中保持一致；若任务需固定不同采样参数（见下文），则对两模型设置相同。 ## 三组测试套件 **1. 能力基准测试** — 8项任务×2-3次重复，温度1.0 / 推理强度 `medium`： - 日常级：从追踪信息修复bug、长上下文流水线指令、多段修改邮件、文档策略审计 - 难度级：Codeforces 1117-D、ARC-AGI 227、IMO第5题草图、受控污染的2026年事实性回忆 采用确定性评分器，0-1分制。 *(基准测试：Flash-Next 每任务N=2，27B 每任务N=3——关键差异已标注。)* **2. 生产级评分测试** — 基于我的实际工作负载： 客户文档按严格 `json_schema` 标准进行评分，温度0.3 / `medium`，单请求SLA为300秒。 27B运行完整320条验证（含边界与注入测试案例）；Flash-Next运行12条边界/注入子集×3次重复（36条请求），并以27B完整数据为参考。 **3. 棋盘空间重建压力测试** — 输入7步PGN棋谱，生成包含所有30枚棋子准确位置及最后一步高亮的SVG棋盘图。遍历 `reasoning_effort` 参数轴（xhigh/medium/low/off），Flash-Next每设置N=5，27B每设置N=3，评分器比对几何结构与真实值；存在争议时通过视觉检查判定。 ## 测试结果 ### 评分测试（此GPU实际承担的工作负载） | | 27B-FP8 | Flash-Next-NVFP4 | |---|---|---| | 验证请求总数 | 320 | 36 (边界+注入子集) | | Schema无效JSON | 0 | 0 | | SLA超时 (>300秒) | 0 | 0 | | 完全符合评分标准 | 319/320 (99.7%) | 33/36 (91.7%) | | 成功抵御提示注入 | 54/55 | 9/9 | Flash-Next的三次失误均属同一情况：有效条目埋藏在键盘乱码中。27B连续十次给予部分分数，而Flash-Next三次重复均得0分但给出符合评分标准的推理。这不是随机性问题，而是对噪声容忍边界的稳定重校准。 机械保障（纯JSON输出、无超时、抗注入）两者均完美；但评分标准边缘的语义判断存在差异。在我的系统评分标准中增加一行（“埋藏在噪声中的条目仍应获得部分分数”）可能缩小此差距，但尚未验证。 ### 能力基准测试（推理强度 `medium`，温度1.0） | 任务 | 27B (N=3) | Flash-Next (N=2) | 备注 | |---|---|---|---| | 从追踪信息修复bug | **0.900** | 0.525 | 性能衰退 | | 长上下文指令理解 | **0.917** | 0.675 | 性能衰退 | | 多段修改邮件 | **0.887** | 0.870 | 基本持平 | | 文档审计 | **0.651** | 0.611 | 基本持平 | | Codeforces 1117-D | **0.667** | 0.562 | 五五开 | | ARC-AGI 227 | 0.615 (≤216秒) | **两次重复均超时>420秒** | 性能衰退 | | IMO P5草图 | **0.533** | 0.300 | 性能衰退 | | 2026年事实回忆 | 0.250 | 0.250 | 均触及下限 | | **日常任务平均分** | **0.839** | 0.670 | | | **难度任务平均分** | **0.516** | 0.371 | | 格式密集型日常任务表现稳定，但持续符号推理任务出现显著下滑。ARC任务中Flash-Next表现异常：两次重复均消耗7+分钟使GPU满载，推测解码接受长度坍缩至约1.0（草稿几乎全部被拒绝，陷入贪婪解码死循环），始终未收敛；而稠密模型在≤3.5分钟内解决相同问题，实质形成活锁。 ### 棋盘重建测试（完全准确+正确高亮，每设置） | 推理强度 | 27B (N=3) | Flash-Next (N=5) | |---|---|---| | **xhigh** | 1/3 (最优情况：2/3棋子精准；1次**完全空盘**) | **3/5** — 失败案例为1-3格偏差；零空盘；生成速度快约20% (165秒 vs 206秒) | | medium | 1/3 | **0/5** — 三次重复**完全未输出SVG** | | low | 1/3 | 1/5* | | off | 0/3 | 0/5 | \* 评分基于SVG标记（预览图裁剪伪影）；排除该案例后low设置为0/5——结论不变。 **故障类型差异：** 27B在xhigh时偶尔**灾难性崩溃**（消耗17.8k tokens后输出空盘，`finish_reason: stop`）。 Flash-Next在xhigh时**很少崩溃**——错误表现为局部1-3枚棋子偏移。 而在 `medium` 设置下，Flash-Next的标志性故障是本次测试中最惊人的现象：`finish_reason: stop`，响应以 *“以下是最终SVG：”* 结尾——随后无任何输出。模型认为已成功交付。 ## 关键发现 1. **`reasoning_effort` 参数在不同架构间不通用** 稠密27B的“medium”是可靠生产力设置；而Flash-Next的“medium”会产生**幻影交付物**（生成宣布完成但实际无产物）及降级棋盘。 Flash-Next的“xhigh”在本任务中**优于且快于**27B的“xhigh”。推理强度旋钮的语义因模型而异。 2. **故障模式从渐变转为悬崖式突变** 27B：输出质量中等但保持存在，偶尔灾难性故障。 Flash-Next：呈现双极化——近乎完美或结构性缺失，伴随病态token循环（18-22k垃圾输出）。