一条 Qwen3.8-27B 速度数据描述的是一套系统，而非一个抽象模型。实际系统包含特定权重、量化产物、推理引擎、缓存状态、上下文形态、推理设置、任务、硬件拓扑和 Token 计量方法。本文把这些变量整理成评测合同，再用两组一手部署说明为什么一个 tok/s 数字无法直接支持采购决策。
阅读时间：7 分钟 · 约 2200 字
TL;DR
- 固定权重产物、量化方式、引擎构建、提示词、输出上限、缓存状态和推理模式。
- 同时报告总吞吐、单流 decode、首 Token 延迟、质量、失败和单次合格任务成本。
- 双 RTX 5090 实测从 1 路 268 tok/s 扩展到 8 路 962 tok/s，单流 decode 同时从 286 降到 141 tok/s。
- 这条曲线只适用于被测 NVFP4 与 SGLang 栈，不能直接变成 Qwen3.8 硬件排行榜。
- 先评测真实工作流，再用生产观测寻找下一处瓶颈。
模型名只确定了一层
官方 Qwen3.8-27B 模型卡显示，这是一款 27B 稠密视觉语言模型，原生上下文长度 262,144。它用 Gated DeltaNet 与 gated attention 组成混合架构，官方部署文档列出 SGLang、vLLM 和 TokenSpeed 等引擎。
硬件开始运行之前，多个行为开关已经改变了负载：
- 默认开启思考模式；
reasoning_effort支持xhigh、medium和low；- 默认开启
preserve_thinking，会在多轮对话中保留推理历史； - 思考与非思考模式的官方推荐采样参数不同；
- 静态 YaRN 可以扩展上下文，但官方提醒它可能影响短文本性能。
模型卡还指出一个关键系统现象：较低推理强度能缩短单轮响应，也可能增加失败、重试、总延迟和 Token 消耗。只测 decode 速度，可能奖励一套更少完成有效任务的配置。
权重产物同样需要唯一身份。BF16、FP8、NVFP4、GGUF、GPTQ 等量化文件可能来自不同发布者，使用不同校准数据、内核和转换版本。应把 Qwen3.8-27B 当作模型家族，并记录仓库、revision 或 digest、量化方法与投机解码草稿模型。
一条有用但边界清楚的并发曲线
一份双 RTX 5090 一手部署报告测试了 NVFP4 Qwen3.8-27B、双卡张量并行、SGLang vendor 构建和 DFlash2 支持。并发实验使用同一道数学题，关闭思考模式，将 max_tokens 固定为 1024，并把并发从 1 路逐步增加到 8 路。
| 并发请求 | 总吞吐 | 单流 decode | 总吞吐扩展倍率 |
|---|---|---|---|
| 1 | 268 tok/s | 286 tok/s | 1.00 倍 |
| 2 | 461 tok/s | 253 tok/s | 1.72 倍 |
| 4 | 692 tok/s | 196 tok/s | 2.58 倍 |
| 8 | 962 tok/s | 141 tok/s | 3.59 倍 |
报告将总吞吐定义为全部生成 Token 除以墙钟时间，其中包含 prefill；单流 decode 则排除 prefill。这解释了单请求下总吞吐略低于纯 decode 的现象。
这条曲线支持一个针对该机器的实用结论：8 路同时运行时，每路仍保持较快交互速度，整机总吞吐继续提升。它也说明快必须绑定工作负载。单用户可能重视 286 tok/s，小型 Agent 池可能更重视 962 tok/s 总吞吐与 141 tok/s 单流速度，批处理则可以继续牺牲交互速度换取总产出。
这组数据无法证明 NVFP4 普遍优于 FP8、SGLang 普遍优于 vLLM，或者双 5090 胜过所有替代方案。这些判断需要匹配权重、引擎、上下文、质量检查和功耗边界。
第二套系统暴露了不同瓶颈
另一份 NVIDIA Developer Forum 一手部署测试了单台与双台 DGX Spark，采用 NVFP4、SGLang、DFlash2，并通过 RoCE 做双机张量并行。
作者报告，代码生成在单机上为 52 至 61 tok/s，双机为 87 tok/s；重复 16k 前缀的首 Token 延迟则从单机约 0.44 秒增加到双机约 0.74 秒。双机提高了 decode，同时为缓存轮次引入了通信延迟。
这份报告还记录了八类兼容性修复，涉及推理强度映射、结构化输出、多轮历史、缓存计量和流式 Token ID。它们都属于性能问题，因为一个会让客户端工作流失败的高速服务，对该请求的有效吞吐是零。
两份报告不能合并成排行榜。它们的硬件、互联、软件构建、任务和计量方法均不同。放在一起能支持一条更有价值的规则：硬件速度、缓存行为、协议兼容和任务质量必须作为同一工作流评测。
使用评测合同，而非轶事表格
正式比较之前，至少冻结以下字段。
| 层级 | 最低记录要求 |
|---|---|
| 权重产物 | 仓库、revision 或 digest、参数规模、量化器、校准细节、草稿模型 |
| 引擎 | 名称、版本或 commit、容器 digest、内核、启动参数、并行方式 |
| 硬件 | 加速器、数量、显存、互联、驱动、功耗限制、主机 CPU 与内存 |
| 负载 | 提示词集、输入输出分布、工具、结构化输出、并发、持续时间 |
| 推理 | 思考开关、推理强度、历史思考保留、采样参数 |
| 缓存 | 冷热状态、前缀复用、KV 精度、容量、重启策略 |
| 性能指标 | TTFT、Token 间延迟、单流 decode、总吞吐、p95/p99、能耗 |
| 质量指标 | 可执行测试、合格任务率、工具成功率、Schema 有效率、重试与失败 |
最少运行四类负载单元：
- 冷启动单轮请求，用于暴露加载、prefill 与编译成本。
- 重复前缀的热缓存轮次，用于测量缓存行为。
- 相互独立的并发请求，用于描绘总吞吐与单用户交互速度。
- 带工具和质量检查的多轮任务，用于测量真实完成结果。
每个单元重复足够次数并报告分布。预热阶段与测量窗口要分开。投机解码可能在一个流事件中返回多个 Token，因此计量应使用真实模型 Token，而非流事件数量。
把质量与重试放到速度旁边
量化和投机解码必须配套质量门槛。测试集应代表真实部署，例如可执行编程题、Schema 有效的数据抽取、工具调用、长上下文检索或领域评测。所有候选配置使用相同输入和解码设置。
核心决策指标应是单次合格任务成本：
单次合格任务成本 =
（算力 + 电力 + 运维人工 + 重试成本）/ 合格任务数
Agent 工作流还要记录完成任务所需轮数、工具失败、重复推理和人工修复时间。较低推理强度即使让每轮更快，只要引入更多重试，最终仍可能更慢。
量化标签也要审计。两个都叫 INT4 的文件，可能使用不同 group size、校准集、异常值处理、内核和累加精度。评测对象是具体产物，而非标签。
从跑分进入生产观测
短期基准用于选择候选配置，生产观测用于判断真实适配。
让入选系统运行一至两周，采集请求形态、缓存命中率、排队深度、TTFT、decode、错误、重试、能耗和合格任务结果，再寻找真实约束。
如果用户已获得 141 tok/s，而 Agent 正在等待工具，继续提升 decode 价值有限。如果长上下文耗尽 KV cache，显存成为优先项。如果 Schema 失败造成重试，协议与解码控制才是瓶颈。如果利用率长期偏低，弹性算力可能优于自建硬件。
模型只是一个可替换组件。更持久的资产是一条评测与可观测闭环，它能在下一版量化、引擎或 GPU 出现后重新测试，同时保持成功定义不变。
下一步：让每条结果都携带评测合同。缺少配置和质量门槛的数字适合讨论，不适合采购。
常见问题
Qwen3.8-27B 达到多少 tok/s 才算好
答案取决于权重、引擎、硬件、上下文、缓存、推理模式、并发和任务。先定义交互速度与合格任务目标，再用同一合同比较配置。
应该开启思考模式做基准吗
按生产环境使用的模式测试。混合负载应分别运行思考和非思考单元。Qwen 模型卡给出的采样建议不同，并提醒较低推理强度可能增加重试。
可以直接比较不同帖子里的 NVFP4、FP8 和 INT4 吗
这些帖子适合发现线索。可靠比较需要匹配任务、质量检查、引擎版本、硬件边界和计量方法。量化标签本身无法建立等价性。
Agent 服务最重要的指标是什么
同时跟踪首 Token 延迟、Token 间延迟、总吞吐、缓存命中、尾延迟、任务成功、重试、工具失败和单次合格任务成本。Agent 用户体验来自完整闭环。
参考资料
- Qwen：Qwen3.8-27B model card。
- Qwen：Qwen3.8 official repository。
- 鸭哥：2×5090 跑 Qwen3.8-27B 一手生产实测，2026 年 8 月 24 日。
- NVIDIA Developer Forums：Qwen3.8-27B NVFP4 on single and dual DGX Spark，2026 年 8 月。
- SGLang：Qwen3.8-27B RTX 5090 cookbook verification issue。