MTP 配对验证计划与结果

2026-09-18，延续 06bcbcf 基线。目标是评估 MTP 2 是否值得替换默认配置。不会把一次短输出计时等同于稳定性验收。

预设测试范围

无 MTP：128K、FP8 KV、Graph、GPU budget 0.96。
MTP 2：同样的镜像、权重、上下文、视觉编码器与单活动请求，GPU budget 0.985；Graph 包含 3-token 验证形状。
两组使用同一脚本和生成资产、相同 seed 和采样参数；不会把精确逐字一致作为浮点路径变化后的唯一正确性标准。
12 道可精确验算的算术、精确 JSON、多轮记忆、OCR 发票与加总、4 张图片、120 秒 720p 视频顺序识别。
代码、中文需求、算法推理三类提示：每类一次预热、三次 2048-token 固定输出计时，xhigh 思考档；另有一次 16384-token 连续输出。
接近 128K 的两个位置检索，重复三次；长文本与图片混合检索；4 个客户端同时提交，验证单活动序列下的排队，不声称 GPU 并行处理。
两组各连续 600 秒混合负载，交替长输入、图像、视频、2048-token 解码，累计时间不包括前述功能与性能用例。
同时采集主机/GPU 资源、OOM、服务错误；功能失败和 HTTP 错误均保留，不能过滤失败后只汇报成功数据。

判定原则

默认启用必须满足：全部预设功能检查通过、无 OOM 或服务退出、长输出无中断、排队请求成功，并在多类长输出任务上有持续收益。单一 synthetic 测试不代表综合模型质量；真实业务长期运行和更大视频仍超出这次验证范围。

固定 token 计时使用 ignore_eos，可能得到截断或后续重复文本，只评估持续解码而非答案质量。精确答案用例正常使用 EOS。视频资产为六个颜色区间，每区间 20 秒，2fps、总计 240 帧；服务内部可能进一步采样。多模态能力是模型/处理器的实际输入路径测试，不代表任意时长、分辨率或帧数都可接受。

补充正常 EOS 任务：发票提取、订单去重、依赖调度、中文审批规则、合并区间和二分查找代码、工具调用参数。代码先做 AST 限制，再在独立进程中以 CPU/内存/时间上限执行固定测试用例，不执行任何外部工具操作。

预检曾使用不支持的 reasoning_effort=high，服务返回 400。查明支持 low/medium/xhigh 后改为 xhigh，两组统一使用修正脚本；原始预检错误单独保留，不混入正式统计。

状态：完整配对验证完成，MTP 2 已启用；原始记录保存在 audit/qualification/。

暂停后恢复与基线诊断

按用户要求暂停后，服务器恢复了无 MTP 配置。原基线正式套件 92 个请求全部通过，其中持续混合负载 54 个请求、623.7 秒；补充 xhigh 正常 EOS 任务有一道 merge-intervals 未返回正文。

原脚本在 JSON 解析失败时没有保存完整响应，已修正记录并保留原始失败。相同基线单项复测确认：finish_reason=length，8192 个输出 token 全部为 reasoning_tokens，content=null。没有证据将其归因于 MTP，因为该请求在无 MTP 下运行。相同任务在 medium 下生成代码并通过固定测试。

两种配置都补充相同的 medium 全套质量任务。高思考档的预算耗尽按实际失败记录；最终评价同时区分基础模型/输出预算限制和 MTP 相对基线的新回归，不用切换思考档的成功掩盖 xhigh 失败。

最终结果

检查	无 MTP	MTP 2
功能、计时、长输入及持续负载请求	92/92 通过	98/98 通过
其中连续混合负载	54 请求 / 623.7 秒	60 请求 / 614.0 秒
xhigh 正常 EOS 任务	6/7	7/7
medium 正常 EOS 任务	7/7	7/7
2048-token 代码提示，中位数	77.10 token/s	123.42 token/s
2048-token 中文提示，中位数	77.12 token/s	128.78 token/s
2048-token 推理提示，中位数	77.14 token/s	122.15 token/s
16384-token 单次持续输出	76.62 token/s，213.9 秒	142.32 token/s，115.2 秒

三类 2048-token 测试提升 58%–67%。16384-token 计时约提升 86%，但基线含 12136 个思考 token、MTP 为 16384 个思考 token，生成内容明显不同；只证明长时间解码速度和不中断，不能声称答案质量等价或完成业务更快。中文计时中两组思考/正文占比也不同。每类计时为预热后 3 次，不能外推到所有输入。

两组都通过：2048×1536 合成发票图片 OCR/加总、4 图输入、120 秒 720p 视频顺序识别、125995 token 双位置检索、111670 token 长文本加图片检索、4 客户端排队。两道生成代码在独立受限进程中通过固定用例；没有执行实际外部工具动作。

合计 1305 次资源采样：主机可用内存最低 171.95 GiB，OOM kill 最大值 0，未触发内存保护；GPU 峰值 84797 MiB / 85651 MiB，剩余约 854 MiB，温度峰值 64°C。当前容器 healthy、OOMKilled=false、restart=unless-stopped。这些为本次快照，不代表未来实时状态。

延迟与缓存取舍

MTP 减少可用 KV 容量，不能把解码收益直接换算成整体业务收益。本次持续负载中：

请求类别总耗时中位数	无 MTP	MTP 2
重复长输入检索	1.74 秒	15.17 秒
视频	2.08 秒	2.37 秒
图片	2.03 秒	1.31 秒
2048-token 解码	26.62 秒	16.70 秒

交替负载中的缓存状态不同。这是当前两套配置的实际混合负载表现，不能把长输入差异解读为纯计算预填充性能差异，也没有通过内核剖析证明具体缓存淘汰原因。初始基线重跑还可能复用之前预检的缓存，因此首次检索 TTFT 不作为冷启动预填充对照。独立的连续前缀复用检查两组均通过。

10 分钟内 MTP 处理 60 个混合请求、基线 54 个，说明本组混合任务的整体改善远小于解码提升。若主要业务是大段上下文反复提问、只生成很短的答案，原配置可能更合适。

当前采用与运行边界

按用户希望利用 MTP 提升生成速度的方向，服务器已采用 MTP 2 + 128K + FP8 KV + 单活动请求 + 0.985 GPU 预算，保留文字、图片、视频能力。启用自动重启；未提高并发或进一步挤占显存。没有声称通过全天运行或任意媒体大小测试。

完整测试未发现 MTP 新增的服务错误或所选任务正确性回归，因此本轮不再仅因显存余量较小就拒绝启用。仍需尊重实测边界：视觉检查为合成图/视频，代码为固定用例，10 分钟持续负载不是 24 小时压力测试，也不是通用模型质量认证。

日常代码和结构化任务建议显式指定 reasoning_effort: medium，并为最终正文预留输出预算；需要 xhigh 时检查 finish_reason，不能把 reasoning-only 的 length 响应当成完整答案。128K 是输入、思考和正文合计上限。

原无 MTP 配置保存在根目录 compose.baseline.yaml。服务器项目目录中执行以下命令可切换（会重启模型）：

# 回退到无 MTP
 docker compose -f compose.baseline.yaml up -d
# 恢复经本轮验证的 MTP 默认配置
 docker compose -f compose.yaml up -d

复测方法

先用镜像内已有 Pillow/OpenCV/numpy 生成合成资产：

docker cp scripts/make_qualification_assets.py qwen38-flash-6000d:/tmp/make_qualification_assets.py
docker exec qwen38-flash-6000d python3 /tmp/make_qualification_assets.py --output /root/.cache/qualification
python3 scripts/qualification.py --output /data/flash-next/audit/new-qualification.jsonl --soak-seconds 600
python3 scripts/quality_tasks.py --output /data/flash-next/audit/new-quality-xhigh.jsonl
python3 scripts/quality_tasks.py --effort medium --output /data/flash-next/audit/new-quality-medium.jsonl

输出路径必须不存在，避免覆盖原始记录。使用相同输入和设置配对比较，分别保留失败与成功结果。汇总工具 scripts/summarize_qualification.py 可读取与本次相同命名的回执目录。

8.0 KiB Raw Permalink Blame History Unescape Escape