Qwen3.8-Flash-Next-NVFP4 与 Qwen3.8-27B-FP8 测试结果

Qwen3.8-Flash-Next-NVFP4 (inferact) vs Qwen3.8-27B-FP8 (qwen) 忙得不可开交，没时间把这篇整理得漂亮些。其中大部分内容是Qwen写的，但我核对过数据。所有测试均在同一台机器、相同提示词下进行，且大部分测试使用的是我的真实工作负载。单卡本地评测环境：一块 RTX PRO 6000 Blackwell Max-Q（96 GB，SM120）+ 256 GB DDR5，vLLM nightly 版本，两个模型交替以相同的服务别名和端口对外提供，供我的Agent技术栈实际调用：文本评分流水线、记忆整合、本地深度研究、浏览器自动化等。少量编码任务。由于下游消费者通过别名进行调用，切换别名背后的模型是找出“哪些环节会出问题”的最真实方法。测试模型：- 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 )。以下每一个提示词、测试数据和评分器在两轮测试中完全一致——唯一不同的是所服务的模型。TL;DR： Flash-Next 更快且在机制上无懈可击（严格JSON、抗注入、SLA：全部零失败），并在高推理空间/代码生成层级中胜出，失败模式更优。稠密27B模型在持续多步符号任务（修bug、数学证明、抽象谜题）上仍然占优，而这正是Flash-Next表现出一种显著新失败形态的地方：它承诺交付成果、宣布“完成”，却什么都不输出。同样的 reasoning_effort 参数，语义却截然不同。这不是即插即用的替代品，而是一种有条件的升级。## 部署配置（我实际运行的命令）Flash-Next： ``` 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 # 混合注意力路径自行选择后端