13 线首发 · 推荐主力换届 v2026.09.11

DSv4 线号已改为三位（01→101、02→102）。本版的 dsv4-kit-01/02 文件名
在新编号下会被读成 Qwen 的 01/02 线，请勿再用——
到 v2026.09.12 取 dsv4-kit-101/102。
本版七个 q38-kit-* 资产照常有效，Qwen 侧编号未动，下方结论不变。

本次重点：13 线（bf16 · TP8 全 P2P + custom AR）首次发布，并成为推荐主力

13 线 vs 01 线 · 同口径实测

各约 2 小时，负载按编程助手实际口径（输入 40K–350K 字符、均值约 150K、缓存命中 9294%）。
比较前先验明两线负载可比：S3 段命中率十次测量全落在 91.793.7%，均值 92.7% vs 92.5%。

	01 线 TP4	13 线 TP8 全 P2P	增益
单流 decode P50	35.0 tok/s	62.1 tok/s	+77%
冷启 prefill 80–150K 字符	1,757 tok/s	2,665 tok/s	+52%
冷启 prefill ≥350K 字符	936 tok/s	1,601 tok/s	+71%
≥350K 字符 TTFT	112.10 s	65.70 s	−41%
聚合消化 4/8/16 路	2,830 / 10,927 / 12,294	4,536 / 15,197 / 16,036	+60/+39/+30%
服务错误	1（510 请求）	0（729 请求）	—

两条规律：输入越长 TP8 优势越大（+26%→+71%，长上下文正是编程助手主场）；
并发越高相对优势越小（+60%→+30%，两线都接近各自 prefill 上限）。

⚠ 「聚合消化 tok/s」不是 prefill 算力——分子含命中缓存、未被重算的 token，
只能读作「整机每秒消化多少输入 token」。真实算力只看「冷启 prefill」行。

包级验收

两线均走完整现场流程（解包 → up.sh → S1-S8 → 真实请求 → stop）：

• 13 线：就绪 7 分 33 秒，KV 池 3,050,496 token，S8 四项自证全过
• 01 线：就绪 4 分 48 秒，KV 池 2,449,536 token，S8 四项自证全过

13 线的硬前提：驱动需打 v4 补丁

跨 socket 的 dmabuf 会触发驱逐活锁，根因是内核 drivers/pci/p2pdma.c 的
host_bridge_whitelist[] 只列 Intel 根桥 ⇒ pci_p2pdma_distance_many() 返回 −1
⇒ gpu_dma_buf_attach 清零 attach->peer2peer ⇒ dmabuf map 只给 GTT ⇒ 活锁。

1 字节补丁（patches/patch_v4.sh，随包分发）修掉该问题。serve.sh 启动前做字节自检、
未打拒启；stages.sh 另做「来源 + 运行时」双重检查。打完补丁必须重启机器
（驱动 rmmod/insmod 重载会永久破坏 KFD 驱逐机制）。

这不是上游缺陷，而是通用版 Ubuntu 内核环境下的适配手段——
厂商定制内核上可能不存在此问题。

01 线更新

补 @attest custom all-reduce启用 自证项；撤回此前「custom AR 从未启用」的结论——
那是 0811 树时期的观察，0828 树已修，实测 custom_AR_ranks=4，A/B 证明值 2.15×。

⛔ INT8 全系（09/10/11/12）暂不可投产

VMFault 两次复现（存活 19 分 26 秒 / 37 分钟），均在低负载、显存充裕时发作，
无一致前兆。v4 补丁不是解法（dmabuf 与 INT8 内核是两个子系统）。
各线 README 首部已加警示。14 线（INT8 TP8）因此不纳入本次发布。

其它

• dlhook2-sg.so agent 过滤件退役（v4 之后留着反而损失 76% 吞吐）
• 修掉一批公开包内的失效链接与错误路径提示

---

用法：tar xzf q38-kit-<NN>-*.tar.gz && cd q38-kit-<NN> && bash up.sh
（除镜像与模型权重外自包含；bash up.sh status 只看不拉、bash up.sh stop 清场）