Qwen3.8-Flash-Next-oQ4e-mtp 评测方案（M5 Max + oMLX）

在 上张贴 由 yuanxujia发表回复

1. 评测对象与对照

角色模型说明
主角Qwen3.8-Flash-Next-oQ4e-mtpJundot oQ4e imatrix，99GB / 21 shards，125B MoE / 6B 激活，qwen4_exp 架构，256K 上下文，内置 MTP（默认开），VLM
对照Qwen3.8-27B-DFlash2 系资产已确认：z-lab 官方 draft、incoai、cfontes、ProCreations MLXFast-Q4 融合版；执行前从 oMLX 面板确认实际可加载配置
可选Swift-1.5-Qwen3.8-27b-oQ6e-bf16-mtp-MLX微调版，变量多，默认不加

架构事实（文章背景素材）：45/48 层 linear_attention（DeltaNet 系）+ 每 4 层 1 层 full_attention（12 层 full-attn，2 KV heads / head_dim 256）→ KV cache 极小；1 层 MTP head；PLE SSD offload 已启用；vision tower 保留在量化中（333 tensors）。

对照公平性约定：

  • 质量对比：同采样参数（temp 0.6）、同 thinking 状态、同 max_tokens
  • 速度对比：分两栏——「统一口径」（都关 thinking、temp 0）与「各自加速技术」（125B MTP / 27B DFlash2），文中说明两者加速原理不同
  • 加速技术对决是叙事亮点：模型内置 MTP vs 外挂 draft DFlash2

2. 环境与冻结项

环境快照（已采集，执行时复核写入报告头部）：

  • 硬件：Apple M5 Max，18 核，128GB；macOS 26.6.2 (25G83)
  • 服务：oMLX 0.7.1.dev1 @ localhost:8050；模型 wired 内存 ~88GB；SSD cache 已占用 132GB（磁盘空闲 914GB，充足）
  • 模型量化：4-bit affine g64 + 选择性 5-bit override（hyper-connection 模块）；qwen4_ple_ssd_offload: true
  • 内存 guard：aggressive，ceiling 120GB

固定条件：

  • 插电、关闭低电量、禁用屏保/休眠打扰
  • 每档预热 1 次，正式 3 次取中位数 + 并列原始值
  • 冷却 60s；首尾热漂移对照（第 1 档与最后 1 档同条件各补 1 次，验证热降频影响）
  • 采样参数定稿：速度测试 temp=0 / top_k=20 / top_p=0.95（可重复优先）；质量与任务测试 temp=0.6 / top_k=20 / top_p=0.95（= oMLX 实际配置，用户日常体验口径）
  • thinking 策略：速度测试统一 enable_thinking=false；质量/任务测试默认开（xhigh），关键题双跑（开/关）
  • 防缓存污染：每次速度请求 prompt 加唯一 nonce（[run-{uuid4}]），记录 cached_tokens，必须为 0 才算干净样本
  • 并发检查：每次测速前后 grep server.log 确认无其他请求在跑（生产服务有 Hy-MT2 翻译任务共用）；有并发则该次样本作废
  • 测试时段：与用户约定静默窗口（测试期间避免使用 8050 的翻译/agent 任务）
  • 改配置前备份：cp ~/.omlx/model_settings.json ~/.omlx/model_settings.json.bak-{date}（MTP 对照需改配置）

2.5 实测基线（2026-10-16 冒烟，全部已验证）

项目实测结果
usage 指标TTFT / prefill tok/s / decode tok/s / cached_tokens 全可用
Tools APItool_calls 正常返回（1.2s，格式标准）
thinking 控制chat_template_kwargs.enable_thinking=false 生效；reasoning_effort 三档 xhigh/medium/low
思考关键发现9.11 vs 9.8：关 thinking 答错（”9.11 大”），开 thinking 答对（9.8）
长上下文（10.8K）TTFT 8.85s，prefill 1226 tok/s，中段 needle 检索命中，gen 75 tok/s，cached=0
长输出（581 tok）65.3 tok/s sustained，8.9s
VLM图像理解正常（中文图表描述准确，3.3s）
MTP默认启用；日志统计：接受率 87.5–93.8%，2.95–3.27 tok/cycle，overhead 27ms vs backbone 637ms
短请求速度失真6-token 请求仅 ~20 tok/s（MTP 起步/cycle 少）→ 测速档位用 ≥512 输出
预填速度外推128K ≈ 105s、256K ≈ 210s（按 1226 tok/s 线性外推，实测确认）

MTP 日志数据源（比专门 on/off 实验更丰富）：~/.omlx/logs/server.log 中 MTP[uid] ... accept=xx/yy depth[d1=..,d2=..,d3=..] timing[backbone=..ms mtp=..ms] 行——执行期内持续采集，文章用”运行中真实统计”而非”实验室对照”。

3. 数据块设计

块 1：速度矩阵

profilepromptcompletion目的
short32–128512日常短回复（注明 MTP 低 cycle 失真机制）
coding512–1,0241,024主可比档
long-context4,0961,024prefill 成本
sustained1,0244,096+长输出、热降频、吞吐衰减
  • MTP on 状态下跑完整矩阵（默认状态）
  • MTP off 对照（可选单轮）：改 model_settings.json 的 mtp_enabled=false → 重载 → 跑 short+coding 两档 → 改回 → 重载。成本：2 次模型重载（99GB，每次约 3-5min，实测记录）。若执行时发现重载代价高于 10min/次则跳过此实验，改用日志数据 + 27B DFlash 对照支撑叙事
  • 每档 3 次 + nonce + cached_tokens 校验 + 并发检查
  • 记录：TTFT、prefill tok/s、decode tok/s、总时长、wired 内存（vm_stat 采样）
  • 预估：125B ~45min（含冷却）；27B ~25min

块 2：长上下文阶梯

  • 阶梯：4K → 16K → 64K → 128K → 256K 挑战（每个长度独立素材，避免跨级缓存命中）
  • 素材：本地真实中文长文拼接（Strata 报告 + 评测指南 + 补足用素材），每级在随机位置埋 2 个标记（开头区 + 中段），末尾问检
  • 记录：TTFT、prefill 速度衰减曲线、decode 衰减、cached_tokens、内存
  • 10.8K 基线已有（8.85s / 1226 tok/s）；本阶梯验证衰减曲线上翘点
  • 256K 挑战：素材需 ~500K 字符中文；prefill 预估 3.5min+；如内存 guard 拒绝则如实记录为边界
  • 预估：~50min

块 3：质量体检（升级版 + 思考维度）

新维度（v2 核心变更）：思考模式对照——关键题目标题（陷阱/数学/逻辑）双跑：thinking on（xhigh）vs off。

维度题目说明
逻辑L1 昨天明天陷阱、L2 身高题、L3 三开关、H-hard 多步数学、9.11 陷阱题（保留原文）9.11 已确认区分度
指令I1 鲁迅体、I2 给 5 岁小孩讲 AI、严格格式题原题 +1
幻觉H1 鲁迅的孙子、新幻觉题 1 道避开 27B 旧题
长文大素材（50K+ token）细节问答 1 道与块 2 联动
  • 执行：全部题 thinking on 默认跑；逻辑/数学类加跑 thinking off（对照）；彩蛋：reasoning_effort xhigh vs low 各跑 2 题（思考预算话题）
  • 评分：关键词自动评分初筛 + 人工复核；思考模式对比单独出一张小表（题目 × {thinking on 正确性, off 正确性}）
  • 预估：125B ~50min；27B ~25min

块 4：真实任务 ×4（每个 3 次、不重试、全文存档）

#任务设计备注
a代码分析真实文件 200–400 行（候选：oMLX 相关源码 / 用户项目文件），找问题 + 给方案校准集是代码向
b中文写作基于真实素材写 300–500 字公众号段落用户真实工作流
c严格格式指令2–3 题：行数 + 前缀 + 字数 + 禁用词，全机器可检区分度最高
dAgent 工具调用升级设计：多工具选择（3 个工具选对的）+ 错误恢复（工具返回错误后能否自愈）+ 多轮基础能力已验证可用（1.2s tool_calls），测难度上限
  • 任务 d 的预期管理修正：基础工具调用是可用的（不是预期翻车）；测的是边界——工具选择歧义、错误处理、多轮依赖
  • 记录：完整输出、耗时、格式合规性（自动）、内容质量（人工 3 档 + 备注）
  • 预估：125B ~50min + 27B ~25min

块 4.5：VLM 彩蛋（v2 新增）

  • 3 张图：① 中文信息图（描述题）② 图表数据提取（”这张柱状图最大值是多少”）③ 截图 OCR（界面文字识别）
  • 每张 1 次 + 记录 TTFT / tokens
  • 目的：文章差异化卖点（”它不只会写代码，还能看图”），成本 ~10min

块 5：对照汇总

  • 速度对比表（统一口径 + 各自加速）、质量对比表、思考模式对比表、内存对比
  • “多花 ~85GB 内存换到什么”决策表素材（99GB vs 27B Q4 ~15GB，差值执行时按实际文件精算）

4. 评分与纪律

  • 不重试、不纠错、原样保留（失败输出也是证据）
  • scope 声明：非长时间稳定性测试；非全工具集；256K 挑战可能受内存 guard 限制
  • 条件注明：预热、cache 状态（cached_tokens=0 才算干净）、热状态、采样参数、thinking 状态
  • 数字规范：中位数 + 原始值并列；标注样本量与局限；不做因果夸大
  • MTP 接受率口径注明：temp=0 确定性解码下接受率可能高于真实使用场景；真实场景接受率从质量/任务测试（temp=0.6）的日志中采集对照
  • 自动评分只做初筛，人工复核兜底；全部原始响应进 raw/

5. 执行计划（v2 修订）

Phase 0 冒烟（已完成 ~80%）
  ✅ 已验证：usage / tools / thinking / 长上下文 10.8K / 长输出 / VLM / MTP 日志
  □ 剩余：
     - 256K 边界单测（一次，~4min）
     - 27B 对照实际加载配置确认（oMLX 面板）
     - MTP off 重载路径演练 + 重载耗时实测
     - 用户约定静默窗口
Phase 1 125B 全套（顺序：速度矩阵 → 长上下文阶梯 → 质量体检 → 真实任务 → VLM 彩蛋）
  预估 3.5–4.5h（含冷却与思考等待）
Phase 2 切换 27B（重载）→ 27B 全套（速度 → 质量 → 任务；长上下文阶梯可精简为 4K/64K 两点）
  预估 1.5–2h
Phase 3（可选）MTP off 单轮对照 → 恢复 MTP
  预估 +30min（含 2 次重载）
Phase 4 数据整理 + 图表 + 文章映射  预估 2h

排序原则：125B 全部测完再切 27B（LRU 换出代价大：99GB 重载）；MTP off 对照放最后（避免中间态污染主数据）。

脚本：新写 runner.py（复用 local-model-benchmarking 的评分模块）：

  • 支持 profile 档位 / nonce 注入 / cached_tokens 校验 / 并发检查 / JSON 断点续跑（每个 block 独立可跑）
  • MTP 日志解析器（parse_mtp_logs.py）：从 server.log 提取 accept 率、tok/cycle 时间序列

6. 风险表（v2 更新）

风险实测/评估应对
prefix cache 污染 TTFT已确认缓存系统存在（hot 10GB + SSD 132GB）nonce + cached_tokens==0 校验
生产服务并发干扰已确认（日志见 Hy-MT2 并发）静默窗口 + 测前测后日志核对，异常样本作废
热降频M5 Max 跑 125B 负载高冷却 60s + 首尾热漂移对照
LRU 换出 125B99GB+27B 超 128GB 门槛顺序策略：125B 全完再切 27B
MTP 对照重载代价2 次 99GB 重载限 short+coding 两档；超 10min/次则跳过转日志方案
temp=0 下 MTP 接受率虚高机制已知报告注明 + temp=0.6 真实场景日志对照
256K 内存边界guard ceiling 120GB如实记录为边界数据（本身就是文章素材）
磁盘 cache 增长已占 132GB，剩 914GB充足；开测前记录基线
短输出测速失真实测 6-token 仅 20 tok/s档位用 ≥512 输出 + 机制说明
oMLX dev 版本行为差异0.7.1.dev1版本号写进报告；非常规现象记录复现步骤

发表回复