卡片召唤师
精华
|
战斗力 鹅
|
回帖 0
注册时间 2016-11-16
|
感觉不是很理想：
两块都挖到底了。结论有点反直觉：**能调的都已在最优点**，剩下的空间被三处**上游实现限制**挡住了。下面是数据。
## 一、MTP：所有可调项都已在峰值
每个配置一次引擎重载，同一组中文+代码提示，2 轮取中位数：
| 旋钮 | 取值 → decode tok/s | 结论 |
|---|---|---|
| `--spec`（校验窗口） | 2→77.1 · 3→81.4 · **4→83.6** · 6→79.9 | **当前的 4 就是峰值** |
| `--spec-min-p` | 0.80→80.2 · 0.85→80.5 · **0.90→80.2** · 0.95→80.2 · **1.00→66.8** | 0.80~0.95 是平台期，0.90 正落在里面，没有提升空间 |
| `--mtp-max-t 3` | 80.7 | 更差 |
| `--spec 6 + --mtp-max-t 4` | 82.0 | 不如 spec 4 |
| `--suffix-draft 0` | 80.9 | prompt lookup 值约 **3%**，确认别关 |
草稿接受率：spec2=81.5%、spec3=77.3%、**spec4=75.5%**、spec6=72.0%。窗口越短接受率越高，但总吞吐仍以 4 最优——说明瓶颈已经不在"草稿准不准"，而在"每次校验窗口的固定开销"。
**唯一没走通的方向：提高草稿头本身的分辨率。** 项目文档把 `mtp_pack.py --experts q4_0` 明确标成 "acceptance comparison arm"，所以我构建了 1.597 GB 的 q4_0 草稿头（现在是 0.889 GB 的 q2_0）。结果：
```
mtp_rt.py: assert gu.shape == (NE, 2*FF, 720) → 实际 (512,1280,1440)
```
`mtp_rt.py` 把运行时 blob 布局**写死成 Q2_0**（`BLOB = 3*(H*FF*18//64)`），而引擎源码里**根本没有读取 `strata.mtp.expert_format`**。q4_0/q8_0 只能打包、无法加载。这是引擎侧要改的，不是配置问题。
## 二、专家画像：真正起作用的是「自适应」，而它已经在工作
| 配置 | decode tok/s | 缓存命中率 |
|---|---:|---:|
| auto 缓存（当前） | **83.6** | 82.6% |
| `--expert-cache 3000` | 64.4 | 64.5% |
| **关掉自适应**（`--adapt-every 100000`） | **58.2** | **53.3%** |
| `--adapt-every 1` | 80.4 | 83.2% |
**这是本轮最重要的发现：自适应机制值 +30%。** 关掉它，命中率从 82.6% 掉到 53.3%。也就是说**出厂画像单独只有 53% 的命中率，是自适应在线上把它拉到 82%** —— 「按你的真实流量定制画像」这件事，引擎已经自动在做，而且每 4 轮做一次。所以想"定制画像"的直觉是对的，但不必手动做。
顺带否掉两个假设：
- **画像跨层偏斜？不成立。** 我直接解析了 `expert-profile.bin`：前 5,870 项覆盖全部 48 层，每层 93~155 槽（均值 122，σ=14），前 200 项就覆盖了 44 层。出厂画像是均衡的，做均匀画像不会有收益。
- **那 2.5 GB 空闲显存能抢？不能。** `--expert-cache 7000` 确实拿到 7,844 槽（+34%），但引擎自己报警 `0 MiB of VRAM free ... requests may stall` —— 那是留给图像编码器的。**auto 的保守是对的。**
## 三、更正：识图对文本速度的代价是 ~12%，不是我之前说的 ≈0
之前那次比较用了**两套不同的调优参数**，是无效对比。这次同一探针对照：
| | 专家缓存 | 4K decode（热态 3 次均值） |
|---|---:|---:|
| 开识图 | 5,870 槽 | **86.6** tok/s |
| 关识图 | 7,647 槽 | **98.8** tok/s |
图像编码器启动时占掉约 3.35 GiB（本来可以当专家缓存）。**这是个真实取舍**：
- `--vision gpu`（当前）：每图 0.1–0.5 s，文本 **-12%**
- `--vision cpu`：文本全速，但每图 **10–30 s**
你的日常里图片是偶发的还是高频的？如果一周才几张，切 CPU 模式等于白捡 12%；如果经常发图，现在这样是对的。
## 四、三个值得提给上游的问题
1. **`--dump-routing` 对原生 IQ 包输出空文件** —— 只有单 token 路径 `drive_pool()`（`generate.cpp:462`）会写记录，原生包"runs verify windows only"（`:1845`）走 `drive_pool_multi()`（`:492`），它只 `++t->calls`。→ `tools/make_profile.py` 对 IQ3_S 这类模型**完全不可用**。
2. **`--expert-cache-per-layer` 与 `--expert-profile` 不兼容** —— 加上就启动失败：`ExpertCache::verify_slot: slot 0 differs from the arena at byte 0`。好消息是硬失败而不是算错。
3. **MTP 草稿头精度无法调整** —— 见上文，`mtp_rt.py` 写死 Q2_0，引擎不读格式元数据。
## 现状
模型已恢复到原配置（`spec 4 / spec-min-p 0.90 / pcie 0.05 / workers 16 / auto cache / 识图开`），健康检查通过，Pi 端到端正常。原始数据在 [sweep2.json](/mnt/e/model/tune/sweep2.json)、[sweep3.json](/mnt/e/model/tune/sweep3.json)、[sweep4.json](/mnt/e/model/tune/sweep4.json)，完整分析在 [REPORT.md](/mnt/e/model/tune/REPORT.md) 第四轮。
坦白说，这轮**没有找到可落地的配置级提升**——但把"为什么没有"和"卡在哪"问清楚了，而且第 1、3 两个问题都是能提 issue、修完就有收益的（尤其草稿头精度，接受率从 75% 往上走空间不小）。
|
|
楼主: qwased
沪公网安备 31010702007642号 )
发表于 2026-9-28 15:42
）
毛病和qoder里面也差不多，莫名其妙的幻觉