核心结论

• 当前综合主力仍是 11435 的 Huihui Qwen3.8-27B Q5_K（medium + v22）：同一 20 题测试集质量 97/100，且输出速度约 62 tok/s。
• 11436 已替换为 Huihui Qwen3.8-27B abliterated UD-Q4_K_XL（medium + MTP D3）：同一 20 题严格人工质量 96.5/100，加权 decode 48.12 tok/s。相对旧 Cold-Fusion xhigh，纯吐字速度基本持平，但 reasoning token 减少 52.5%，整组墙钟从约 38.8 分钟降到 12.2 分钟。
• GPT-OSS-120B MXFP4 证明了“12GB RTX 3080 Ti + 110GB 主存”可以运行 120B 模型。最终筛出 FTW + fetch1 + 24 CPU threads + interleave：12K 长上下文档在 4 类代表题平均 14.38、加权 14.30 tok/s；8K 速度档在 ≤4K 输入约 15.2 tok/s。完整质量仍只有 86/100，未超过两套 Qwen3.8 服务。
• 将第七根 DIMM 从远端 NUMA 节点移到 3080 Ti 直连节点，使该节点四通道、局部内存带宽测试提高 11.5%，但 GPT-OSS 稳态 decode 改善落在约 ±3% 波动内。继续购买第八根 DIMM 的价值主要是容量、对称和稳定性，不是显著提速。
• DeepSeek-V4-Flash-0731-120B-REAM-104E-NVFP4 是第三方 104-expert REAM/修复/RTN 量化模型，不是官方 checkpoint；本次虽通过兼容补丁成功运行，但 7 题质量门仅得 21.75/35，使完整测试的理论最高分只剩 86.75/100，且优化后 decode 仅约 8.5–9.2 tok/s。按预设的 90 分门槛提前淘汰，不做 FTW 转换。

统一评测基准与方法

测试集共 20 题、满分 100，覆盖中文指令、英文表达、摘要、结构化抽取、数学与逻辑、编码、代码审查、Agent 规划、长上下文检索、抗提示注入。输入约分为短（40–85 token）、中（约 1K）、长（约 4K）、超长（约 8K）。

质量分与性能分开：质量采用严格人工复核，并实际执行关键代码题；decode tok/s 只统计首 token 后的生成阶段。带 * 的 TTFT 受共享服务排队或缓存状态影响，不用于纯模型对比。

历史模型总表与详细对比

完整 20 题横向对比

* 两套远程 Qwen thinking-on 测试期间存在其他请求，TTFT 含排队。
** 该轮复用了 warm prompt cache；冷态参考约 6.1s。

新 11436 的 96.5 分使用了更严格的代码边界门：code-01 在 mixed naive/aware ISO 时间上抛出 TypeError，乱序输入下 owners 不是按输入首次出现排序；code-02 未排除 Decimal('NaN')。历史 11435 的 code-01 含相同两项缺陷，但旧评分未执行这组扩展用例，因此 97.0 与 96.5 的 0.5 分差不应被解读成稳定的模型能力差距。

11436 新旧版本实测对照（同一 20 题）

新 11436 共 20/20 成功、0 错误、0 截断；66,007 个 prompt token、27,975 个 completion token。TTFT P50/P95 为 5.97/15.14 秒；decode P50/P95 为 48.36/62.69 tok/s。730 个逐秒遥测样本中，目标 RX 7900 XTX 平均利用率 77.1%、P50 79%、P95 100%，显存稳定在 21.55–21.61 GiB；11435/11436 健康检查无非 200 样本。

11436 运行时参数调优与后续建议

当前实参已经明确：单张 RX 7900 XTX、Vulkan0、全层 offload、131,072 context、q4_0 K/V cache、batch/ubatch 2048/512、Flash Attention、medium + 8,192 reasoning budget、MTP D3。26 个完成请求的服务日志累计 MTP accepted/generated 为 22,786/27,987，token 加权接受率 81.4%；单请求约 64.5%–97.1%。这与 Huihui Discussion #4 中另一份 Huihui Q4_K “接受率 0” 的社区复现不同，说明不能把同系列失败直接外推到当前 UD-Q4_K_XL，但仍应以 MTP off/D1/D2/D3 实测决定最佳深度。

公开资料没有给出这个精确文件在相同硬件上的专属配方。Huihui 模型卡确认该 UD 量化来自 Unsloth 且 MTP/视觉部分未修改；Qwen3.8 官方模板只接受 xhigh/medium/low reasoning effort；llama-server 文档说明了 reasoning budget、KV 类型、speculative metrics 与 split 参数。后续建议按以下顺序 A/B，当前不改生产服务：

1. 保持模型、采样与 20 题不变，测试 MTP off → D1 → D2 → D3，同时记录 accepted/generated 与 wall time；接受率高不等于净加速。
2. 只在长上下文质量出现问题时比较 target KV q4_0 → q8_0；q8 会明显增加显存，不应先动。
3. 依次比较 reasoning budget 4096/8192/不限，质量与总完成时间一起评分。
4. 当前生产是单 GPU Vulkan，不要把双 7900 XTX tensor-split 社区数字直接当作本实例预期；若未来做双卡实验，再独立比较 Vulkan layer 与 ROCm tensor split。

加速、局部与稳定性测试

GPT-OSS-120B FreeToken 单变量调优拆解

固定官方 MXFP4、memory_ratio=.82、8K KV、16K max sequence、32 CPU threads、default NUMA，以 extract-02 + code-01 两道代表题筛选 hybrid 每步 PCIe expert fetch 上限。每组均重新加载权重；性能只取真正可推理后的有效请求。

fetch=0 加载时核心进程实际读取超过 60GB，短时顺序推进约 30MiB/s，CPU iowait 约 30%–40%，swap 使用从约 20GiB 升至 27GiB，但实时 swap-in/out 接近 0，11435/11436 全程健康。它说明当前启动瓶颈是 NFS 小 tensor 读取、重排、page residency 与 pinned bank 建立的组合，不是 2.5GbE 的单一线速。因为 0→1 大幅改善而 1→2 反向下降，3/4 不再继续，避免无信息增益的重复冷加载。

启动器原先仅用 /health 判断 READY；FreeToken 在 expert bank 未完成时该端点已可返回成功，导致请求收到 503 model is still loading。现已改为 /health 与真实 1-token chat completion 双门，并记录 startup_wall_s；两条 503 仅保留为 adapter/readiness 证据，不纳入性能样本。

在 fetch=1 下继续比较 CPU MoE 线程数，32→24 线程的两道代表题同时变快：

24 线程相对 32 线程平均 decode +13.5%、加权 decode +13.9%，且 GPU ≥75% 的非零样本占比提高约 10.9 个百分点。16 线程补测为平均 12.43、加权 12.77 tok/s，GPU 非零均值 81.6%，因此线程甜点位明确落在 24，不是“越多越快”或“越少越省同步越快”。

NUMA、special checkpoint 与 FTW

固定 fetch=1、24 CPU threads、8K KV 后进行同题 A/B：

preferred=0 虽让初始进程页更偏向 GPU 直连 node 0，但 expert bank 大于单节点舒适容量，随后仍有跨节点访问，并牺牲 node 1 的本地带宽；真实结果比 default 更慢。interleave=all 把 CPU 侧 expert 数据条带化到两路内存，在本负载中更好利用总带宽。

FTW 转换使用官方 ft checkpoint --dtype bfloat16 --moe-backend offload --shard-gib 8，在本地 raw checkpoint 上耗时 290 秒，生成 60.77 GiB、8 个 4KiB 对齐分片，包含 327 个普通权重张量和 216 个 expert-bank，量化格式仍为 mxfp4_triton；它是布局转换，不是重新量化。输出先写 .partial，索引、配置/tokenizer 哈希和文件清单通过后才原子改名。

启动实测如下：NAS 原始 safetensors 的 t24 组为 1,993 秒；复制后的本地 raw 冷态 t16 为 244 秒，本地 raw 热态 t24/interleave 为 140 秒；FTW 冷态 t24/interleave 为 180 秒。故 FTW 相对 NAS 原始加载缩短约 91%，但没有胜过已热页缓存的 raw 本地副本。FTW 的确定价值是移除 NFS 小 tensor 串行重排灾难、让启动可预测；稳态 decode 只可表述为“持平到小幅提升”。

8K 速度档使用 4096 输出预算时，前三道 ≤4K 输入题平均 decode 15.18 tok/s；但 8K 检索输入占用约 8,144 token，服务因总 KV 只有 8,239 pages，将输出上限从 4,096 自动压到 95，无法形成答案。因此 8K 档只能用于 ≤4K 输入，不能冒充长上下文配置。

12K 通用档把 KV 扩至 12,427 pages，expert cache 从 322 降至 308 slots。4 题均形成 final content，检索题 8 个指定条目的字段全部正确，但全表统计 north_cold/stack_ge_7 输出 1/2，参考为 10/45；这是模型语义缺陷，不是截断。该轮 256 个逐秒遥测样本中，GPU 全时段均值 86.1%、P50 91%、P90/P95 100%；242 个非零样本平均 91.1%，其中 97.5% ≥75%。显存峰值 10,452 MiB，最小可用主存约 42.6 GiB，11435/11436 健康失败为 0。这确认了界面中“GPU 大多稳定在 75% 以上”的观察，不是漏看峰值造成的错觉。

最终推荐启动环境：

GPTOSS_MODEL_DIR=/mnt/enterprise/models/gpt-oss-120b.ftw \
GPTOSS_VARIANT=ftw-fetch1-mr082-kv12k-t24-interleave \
FREETOKEN_MEMORY_RATIO=0.82 \
FREETOKEN_KV_RESERVE_TOKENS=12288 \
FREETOKEN_MOE_CPU_THREADS=24 \
FREETOKEN_MOE_HYBRID_MAX_FETCH=1 \
FREETOKEN_NUMA_POLICY=interleave \
FREETOKEN_SPECIAL_TOKEN_CKPT=0 \
GPTOSS_LOAD_STATE=ftw-cold \
/mnt/enterprise/freetoken/deploy/start-gptoss-experiment.sh

若工作负载保证输入不超过约 4K，可把 FREETOKEN_KV_RESERVE_TOKENS 改为 8192 并把 variant 改成 ...kv8k...，换取约 6% 速度；通用服务不建议这样做。

FreeToken 0.1.2 的 CLI 与 server args 没有 EAGLE3、draft-model 或通用 speculative decoding 接口。外部 EAGLE 仓库虽有非官方 GPT-OSS-120B draft checkpoint，但不能直接接入当前 ft serve，需要另一套 runtime 与独立兼容/质量/显存测试；本轮按 NO-GO 处理，而不是把 llama.cpp 的 Qwen MTP 参数误套到 FreeToken。

DeepSeek 104E 适配与准入评估

改造前

• 241：双 Xeon E5-2682 v4、110GiB 可见内存、RTX 3080 Ti 12GB（PCIe 3.0 x16，直连 NUMA node 0）。
• 11435/11436 使用两张 RX 7900 XTX，作为稳定生产服务；1919 由 FreeToken 承载 GPT-OSS-120B。
• GPT-OSS balanced 完整评测为 86/100、9.77 tok/s；Speed-LC 代表题稳定约 15–16 tok/s。
• 物理调 DIMM 后 node 0 变为 4 通道 64GB，node 1 为 3 通道 48GB。局部内存测试变快，但真实 decode 没有同比提升，说明瓶颈是 CPU、PCIe、NUMA、expert 命中与调度的组合，而非单一内存通道。

DeepSeek 目标模型核查

目标仓库为 Baekpica/DeepSeek-V4-Flash-0731-120B-REAM-104E-NVFP4，固定审计 revision e201071ccb4b13874a17578a9b668c7984842cb4。

模型卡明确把该 NVFP4 构建定位在 Blackwell SM100+，验证平台是 GB10 与 4×B200；其 smoke test 已出现基础算术、重复和代码边界错误，因此即使成功启动，也必须以本地测试集重新评价，不能用“120B”推定质量。

FreeToken 兼容性差异

FreeToken 支持列表中的已知可用 DeepSeek-V4 是官方 checkpoint。当前 DSV4 loader 固定读取原生 ds_fp4：group-32、E8M0 scale、键名 weight/scale。目标仓库则是 compressed-tensors：group-16、E4M3 + global、键名 weight_packed/weight_scale/weight_global_scale，并且缺少 FreeToken 要求的 inference/config.json。

因此不能“改名硬载入”：两种 scale 数学不同，会静默产生错误 logits。本次先创建不修改 NAS 原模型的 sidecar，再做最小兼容补丁：

1. 从官方 DSV4 config 生成 43 层、104E、top-6、无 MTP 的 sidecar inference/config.json。
2. 给 DSV4 resident Linear 接入 FreeToken 已有 W4A16 NVFP4 Triton kernel。
3. 加入 compressed-tensors linear 键映射与 reciprocal global scale。
4. 加入 104E NVFP4 host-bank loader，保持 group-16，不转成错误的 DS FP4。
5. 单独处理 WO_A 的 float32 128×128 block scale；它不同于原生 DSV4 的 E8M0 scale。
6. 原包先备份，补丁可一键恢复；11435/11436 全程不停止。

加载与 A/B 结果

default NUMA 配置最终成功启动，时间线如下：

自动缓存规划原先失败，是因为 DSV4 cost model 强制加入 2 GiB KV slack，并且 prefill overlap 把最小 expert cache 提高到 208 slots。在 12GB 显存上改用可证明能装下的手动几何：--moe-cache-size 104 --num-pages 128 --disable-moe-prefill-overlap --memory-ratio 0.94。服务稳定后通过 /v1/cache/rebuild 增至 176 slots，无需重载权重。

目标仓库还遗漏了官方 DSV4 encoding/encoding_dsv4.py；官方明确说明这一代不提供 Jinja chat template。FreeToken 已支持该 encoder 路径，因此把官方文件补进 sidecar 后即可正确编码；质量门为避免第二次冷加载，直接由外部官方 encoder 调用 /v1/completions。这与模型官方 chat prompt 格式一致。

7 题门控结果：中文短指令、英文四句、订单 JSON、8K 抗注入通过；数学题把正确答案 300 输出为 240，4K 检索输出非法 JSON，代码题有确定性括号语法错误。得分 21.75/35，剩余 65 分即使全取，最高也只有 86.75。因此未继续完整 20 题，也未进行 preferred0 第二次约 16 分钟冷加载。这里不是把局部成绩冒充完整跑分，而是按预先约定的淘汰门计算严格上界。

加载时间诊断与缩短方案

241 到 TrueNAS 的实际链路已经协商为 2,500 Mb/s full duplex；NFS 4.2 使用 TCP，rsize/wsize=1 MiB。2.5GbE 的物理上限是 312.5 MB/s，扣除协议开销后，健康的大块顺序读取目标约为 270–290 MB/s。模型目录在 NAS 上占约 64 GiB，索引记录的 tensor bytes 为 70.10 GB。

当前慢点并非单纯 NFS：兼容 loader 先加载 resident 权重，再把 8 个分片中的数万个 expert tensor 串行读出、解包并拷入 pinned host bank。上一轮 expert 阶段为 575 秒（约 72 秒/分片）；本轮加载中的 10 秒网卡计数只有 73.6 MiB/s（617 Mb/s），而界面看到的 100–170 MB/s 是短时突发。FreeToken 同时明确记录 low free RAM -> serial build；强制并行 reader 会在约 70 GB bank 之外保留整分片匿名临时缓冲，在 110 GiB 且两套 Qwen 同时运行时有现实 OOM 风险。

另一个放大因素是 NUMA：RTX 3080 Ti 与 2.5GbE 网卡都直连 node 0，但 default 启动的核心 loader 当时运行在 node 1；加载中 node 1 可用内存已降至约 9 GB，后续分配会跨 QPI。它会影响 pinned bank 的建立与后续 PCIe fetch，但仅靠绑核不能消除小 tensor 串行重排。

建议按收益与风险排序：

1. GPT-OSS 的 FTW 转换已完成。 最终位于 /mnt/enterprise/models/gpt-oss-120b.ftw，转换 290 秒、冷启动 180 秒；相对 NAS safetensors 的 1,993 秒缩短约 91%。DeepSeek 104E 因质量门失败，没有浪费时间再转换。
2. NUMA A/B 已完成。 interleave=all 胜出；preferred=0 加权 decode 比 default 慢 10.8%。由于 bank 大于单节点舒适容量，纯 membind=0 仍不可行。
3. 不要在当前内存条件下强开 parallel loader。 若未来扩到至少 128–144 GiB，才值得测试 4/8 worker O_DIRECT；现在优先保证 11435/11436 不被换出或触发 OOM。
4. 原始 safetensors 本地副本保留为可回滚基线。 复制耗时 807 秒，26 文件、65,276,859,410 字节与 NAS 源清单完全一致；它的 cold t16 启动 244 秒，热态 raw 可接近 FTW，但仍需每次执行 tensor 重排和 pinned copy。
5. 服务完成后用 iperf3 + 大文件 direct-read 分离测试。 若 iperf3 能到约 2.3 Gb/s、NFS direct-read 仍明显低于 200 MB/s，再检查 TrueNAS vdev、同步读、NIC 中断/队列和 nconnect；若两者都正常，则无需折腾网络配置。

已经准备但因质量门失败而未执行的转换脚本为 deploy/freetoken/convert-deepseek-v4-ream-ftw.sh。它在 1919 活跃时会拒绝运行，并使用 .partial 目录完成后再原子改名，避免把半成品误当模型加载。若未来换成质量合格的同架构 checkpoint，可直接复用此方案。

踩坑与工程经验总结

1. 模型名相似不等于格式兼容。 FreeToken“支持 DeepSeek-V4”和“支持 NVFP4”并不自动推出支持所有 DSV4 NVFP4 衍生仓库；架构、键名、scale 语义、expert 数量和 MTP 都要分别核对。
2. 缺少 inference/config.json。 FreeToken 的 DSV4 参数以该文件为权威来源，HF 顶层 config 并不足够。sidecar 比修改 NAS 原模型更安全、可审计。
3. 第一次失败是明确的 loader KeyError。 原生 loader 查找 layers.0.attn.wq_a.weight，实际只有 weight_packed；这不是分片损坏。
4. 绝不能只重命名权重。 DS FP4 是 group-32 E8M0、无 global；目标 NVFP4 是 group-16 E4M3 + global。错误映射可能“能跑”却输出错误，比显式报错更危险。
5. WO_A 是混合量化例外。 它是 grouped W8A8 FP8，scale 名称和数值语义都与官方 DSV4 路径不同。
6. 该模型没有 MTP。 不能套用官方 DSpark/MTP 参数；所有性能必须按纯 autoregressive 测量。
7. NUMA microbench 不是端到端结论。 preferred=0 可显著改善 GPU 邻近 pinned memory/PCIe overlap，却会让 node 1 线程远程读 node 0，STREAM 反而下降；必须用同一请求 A/B。
8. 首轮冷启动会污染 TTFT。 NAS page-in、host-bank pin、Triton 编译和 CUDA graph capture 必须与 warm repeat 分开报告。
9. 第三方仓库漏了官方 encoder。 DSV4 官方不使用 Jinja，而以 encoding_dsv4.py 为消息协议；缺失时模型能启动但 /v1/chat/completions 会报 tokenizer template 错误。
10. 更大的 expert cache 有收益但救不了模型。 104→176 slots 将 decode 从约 6–7.5 提到 8.5–9.2 tok/s，但跑题后显存最低只剩约 154 MiB，继续追高风险大，也远低于 15 tok/s。
11. 作者自测已经暴露相同退化。 仓库自带结果中的数学题同样代数错误并出现长循环，chat 任务约 5.5–6.1 tok/s；本地错误形态和速度相符，不能简单归咎于 FreeToken 适配。
12. 停止脚本不能假设空闲显存低于 100 MiB。 本机 3080 Ti 空闲基线约 1.17 GiB，旧门会每轮白等 120 秒；现改为确认目标 PID 已退出 compute-app 列表且显存低于 2 GiB，实测释放等待缩到 6 秒。
13. 预检必须认识 FTW index。 原脚本只接受 model.safetensors.index.json，合法 FTW 首次被误判为模型不完整；现同时校验 freetoken_weight.json 的 format/version、shard 与 tensor 列表。

后续建议与 PR 计划

当前部署可做

• 为 104E compressed-tensors loader 增加并行 O_DIRECT 读取；当前串行路径启动慢，但不影响稳态 decode。
• 把当前冠军配置再做至少三次独立进程 warm A/B，记录置信区间；现有两轮 selected2 表明 FTW 稳态增益只有几个百分点，不能凭单轮宣传。
• 增加每层 expert cache hit、CPU route、PCIe fetch bytes、NUMA page residency、GPU stall 的统一 telemetry，避免只看 nvitop 利用率猜瓶颈。
• 分别测试 cache/KV 的 VRAM 配比；短上下文质量测试不必为 16K/12K KV 预留过多显存。
• 对 104E 模型先跑 1-token、短题、数学/重复/代码，再决定是否耗时跑完整 20 题。

FreeToken 可提 issue / PR

1. DeepSeek-V4: detect and clearly reject unsupported compressed-tensors NVFP4 checkpoints：在分配大块内存前给出格式、expert 数与 MTP 的能力矩阵。
2. DeepSeek-V4: add compressed-tensors NVFP4A16 resident linear and expert-bank loader：复用现有 nvfp4_linear / nvfp4_banks，并增加 dequant/logits 对齐测试。
3. DeepSeek-V4: support grouped W8A8 WO_A float scale semantics：兼容 weight_scale / weight_scale_inv，逐层与参考实现比较。
4. DeepSeek-V4: support nonstandard expert counts and SwiGLU clamp：以 104E top-6 router parity 为验收门。
5. Guard DSpark/MTP for MTP-less derivatives：不存在 mtp.* 时禁止启用 speculative decoding，并明确记录 autoregressive-only。
6. NUMA-aware HostBank placement and telemetry：允许 GPU 邻近节点、interleave 与 rank CPU mask，并报告实际 page residency。
7. Parallel compressed-tensors expert loading for DSV4：避免 8 shard 串行读取导致长启动。
8. 关注已有的 TP expert-bank 复制问题；多 GPU 时应分片而非每 rank 复制完整 host bank。
9. Preflight: auto-detect and validate FTW checkpoints：上游预检/GUI 不应把缺少 safetensors index 的 FTW 误报为损坏。
10. GPU release wait should use process/baseline, not <100 MiB：对桌面或持久 CUDA context 主机，以目标 PID 是否退出和启动前基线作为释放门。
11. Expose EAGLE3/speculative capability explicitly：当前内部 kernel 出现 EAGLE tree mask 代码，但 CLI 无 draft-model 接口；应在能力矩阵中明确“未支持”，避免用户误以为可直接启用。

复现与证据

• 测试集与运行器（241）：/mnt/enterprise/freetoken-benchmark/benchmark/suite.py、/mnt/enterprise/freetoken-benchmark/benchmark/run_benchmark.py
• 历史总表：results/all-model-scorecard-20260823.md
• GPT-OSS 完整结果：results/gpt-oss-120b-longctx-medium-min4096-full20-20260823.jsonl
• GPT-OSS Speed-LC：results/gpt-oss-120b-speedlc-evaluation-20260823.md
• NUMA 物理 A/B：results/gpt-oss-120b-numa-ab-20260824.md
• GPT-OSS 优化全量汇总：results/gptoss-optimization-20260824.experiments-summary.json、results/gptoss-optimization-20260824.experiments-summary.md
• GPT-OSS FTW 12K 最终 4 类输出与逐秒遥测：results/gptoss-ftw-fetch1-kv12k-t24-interleave-final4-min4096.jsonl、results/gptoss-ftw-fetch1-kv12k-t24-interleave-final4-min4096.telemetry.csv
• GPT-OSS FTW 转换/启动证据：results/gptoss-ftw-conversion-complete.env、results/gptoss-ftw-control-sha256.txt、results/gptoss-ftw-fetch1-kv12k-t24-interleave.launch.env、results/gptoss-ftw-fetch1-kv12k-t24-interleave.readiness.env
• GPT-OSS FTW 原子转换与推荐启动脚本：deploy/freetoken/convert-gptoss-ftw.sh、deploy/freetoken/start-gptoss-ftw-recommended.sh
• DeepSeek sidecar / 启动：deploy/freetoken/deepseek-v4-ream/、deploy/freetoken/start-deepseek-v4-ream.sh
• DeepSeek 质量门原始记录：results/deepseek-v4-ream-chat-gate5-20260824.jsonl、results/deepseek-v4-ream-chat-gate2b-20260824.jsonl
• DSV4 官方 encoder raw runner：scripts/run_dsv4_raw_suite.py
• Qwen 防掉显存守护：deploy/freetoken/guard-qwen-during-1919.sh
• 新 11436 原始输出与性能：results/remote-11436-huihui-ud-q4kxl-medium-10k-20260824.jsonl、results/remote-11436-huihui-ud-q4kxl-medium-10k-20260824.performance.json
• 新 11436 人工评分与代码验证：results/remote-11436-huihui-ud-q4kxl-medium-10k-20260824.manual-score.json、scripts/validate_qwen11436_code_outputs.py
• FreeToken 官方仓库：FlashML-org/FreeToken

本报告只把同一 20 题、同一评分规则的完整运行放进主排名。局部加速实验、排队状态、warm cache 与兼容性失败均单列，避免把无法比较的数据混为模型质量结论。

附录：统一 20 题测试集明细

所有题目各 5 分，总分 100。测试集使用固定随机种子 20260821 生成无关的“背景档案”，把输入补到约 960、3,900 或 7,900 tokenizer token；背景只用于测试长上下文定位和抗干扰，不改变文末权威任务。下表保留完整任务约束和标准答案要点，省略机械重复的背景档案行。max_tokens 是输出上限，不是要求模型必须用满。

评分时优先检查硬约束（格式、条数、长度、禁止项、精确值），代码题随后执行功能与边界用例。语言流畅但违反硬约束不能获得满分；性能统计将 prompt 阶段与首 token 后的 decode 阶段分开。

补图
官方论文跑分：