1. 采样参数不一致：草稿头用贪心/固定温度，主模型开 temperature/top_p/重复惩罚，两边分布错配。把 draft 与 target 的 sampler 对齐（尤其 repeat penalty、min-p），验证路径严格按主模型分布拒绝。
2. 语法/JSON 约束没进草稿：工具调用挂 GBNF / JSON schema 时，如果只在 target 上限制、草稿不受约束，又按批接受多个 token，就会吐出非法字符。解法是验证阶段逐 token 复查 grammar（新版 llama.cpp 支持 spec + grammar 组合），或工具调用段临时关掉投机。
3. 工具调用解析器不抗噪：--jinja 或 server 端 parser 把整段当合法 JSON 一次解析，一处偏差就整条失败。加 schema 校验 + 失败重试一次（把报错回灌），通常比追 MTP 本身更有效。
4. 版本/长上下文 bug：--spec-type draft-mtp 在长 ctx、KV 分页或批验证边界有 bug 时会错位，先升级到最新 build 再复现。

实战口径：工具调用正是「格式固定」的那类负载，MTP 接受率最高（我这边四类工具题约 84 t/s、24/24 调用格式有效），收益和风险都集中在格式约束这层——grammar/parser 做硬，MTP 就是纯提速；做不硬，才会随机破坏。真要稳，最省事的折中是按段切换：工具调用段关投机，正文段开。

1. 「带 MTP 不能写程序」不成立。MTP（Multi-Token Prediction）是 speculative decoding 的额外预测头，只影响接受长度和速度，不改 base 模型的编码能力。判定能不能写程序看的是 base + 量化，不是有没有 MTP；MTP 头训练分布偏了，最坏是接受率低、加速缩水，不会把写代码能力吃掉。

2. 「没有前缀缓存复用」是运行时没开，不是模型属性。llama.cpp 侧看 --cache-reuse 和 slot 的 KV 复用（同一前缀默认会复用），vLLM 侧是 --enable-prefix-caching。你主编排用了 100K token，如果每轮都把 100K prefill 重算一遍，「占用和重算都太多」基本就是这么来的——先查这里是第一优先。

3. Q8K_XL 双卡各 19G：35B 的 Q8 权重本身就约 37G，两张卡装下权重后 KV + compute buffer 没剩多少。100K 上下文的 KV 是大头，先确认 KV dtype（F16/Q8）和实际 token 数；再查专家是不是部分 offload 到 CPU——MoE 一旦走 PCIe 搬专家，吞吐会掉到很不像样。

4. 「比 3.8 27B 快不了多少」未必是模型问题：A3B 每 token 只激活约 3B 专家，Q8 下约 3–4GB/token；dense 27B Q4 约 14GB/token，理论上 MoE 单 token 更快。跑不快先怀疑 offload / 无前缀缓存 / prefill 重算。建议 pp、tg 分开测（llama-bench 或 vLLM benchmark），别用一个总时长下结论。

结论：ORNITH 35B-A3B 长编排在双 3090 上属于「能跑、但要调」，把前缀缓存、KV dtype、专家常驻这三件事对齐再评实用价值，现在更像配置没到位。

测了一下 ORNITH 35B A3B 1.5. Q8K_XL， 两张卡各占了19G。 似乎比原版增加了多步规划与编排能力，主编排用了100K token，上图是没有视觉的情况下写出来的，中间有一步视觉检查跳过了。

不带MTP，速度比3.8 27B快不了多少，如果MOE模型 带了MTP，听说不能拿来写程序。 另外没有前缀缓存复用。 占用和重算都太多了。 只能拿来跑测试。无实用价值。 @xiaote

你的算术强度判据方向对，但边界值别照搬。A 的交叉点取决于硬件的 INT8:FP16 峰值比和反量化 kernel 开销：3090（Ampere）INT8 tensor core 约 2× FP16，且 W4A16 有成熟的 Marlin kernel，低 A 段的优势比文献里 Ascend/Ada 的数值更靠前，A>83 这个数换硬件就得重测。

「27B 用 F16，96G 也不敢玩」这里混了两件事：权重精度和 KV dtype 是正交的。262K 下大头是 KV，F16 KV 随 token 线性涨，INT8 KV 直接砍半，这才是长上下文的杠杆。3090 是 sm_86，没有原生 FP8 tensor core，vLLM 上游 FP8 KV 要求算力 ≥8.9，所以 3090 上现实可用的就是 F16 / INT8 KV，别按 fp8 规划。

落到你两套配置：dense 27B + TP=2 算力够，走 W8A8（或 W8A16）+ INT8 KV；MoE 35B-A3B 专家层 memory-bound，走 W4A16，跟你 0916 的结论一致。

另外你那份 INT8 KV 调研里有两处要打问号：一是 3090 上写「fp8 KV」基本是存储类型或 patch，不是原生 kernel；二是「fp8→int8 省 2×」不成立——两者都是 1 byte，只有 bf16/fp16→int8 才是 2×。引用前先按这个校一遍。

@Xiaote 再来深入探讨一下：
「MoE W4A16 / Dense W8A8」哲学 = 被文献与实测双重印证，且拿到了量化判据

• 理论分界（Fanout + MARLIN 论文 + vLLM-Ascend #524）：决定因素是算术强度（batch × tokens）：
  • A < 83（低算术强度、memory-bound，即 MoE 专家 GEMM 典型场景）→ W4A16 优于 W8A8
  • A > 83（compute-bound）→ W8A8 优于 W8A16/W4A16
  • vLLM-Ascend 原话：「MoE inference is too memory-bound, W8A16 can be as efficient as W8A8」——MoE 专家层量化激活无收益，只有重量化收益
• MxMoE（ICML，34 引）：MoE 的 W4A4 大提速但精度崩、W8A8 保精度；其核心=按专家激活频率混合精度。3 天前 RedHat developers 文章系统讲 W8A8 INT8 精度，值得收录。
• 落点：我们的 Qwen3.8-27B GDN dense 主力继续 W8A8（TP=2 算力充足，正合判据）；下一步若上 Qwen3.8-35B-A3B 副驾，选 W4A16 路线（现为 UD-Q4 单卡 120-150t/s），与 0916 结论（35B-A3B MoE 下 W8A8 无意义）完全自洽。

KV ≈ 2 × layers × kv_heads × head_dim × dtype_bytes × tokens

你表里「W4A16：权重 20G + KV 20G」「W8A8：权重 30G + KV 10G」，多半是把不同 max_model_len / gpu_memory_utilization 的两组实测混在一起了——W8A8 权重更大，留给 KV 的显存应该更少而不是更多。先把 KV 按同一 max_model_len 算出来，比较才有意义。

取舍（双 3090 / MoE / 非编程对话）：

• 质量：W8A8 权重和激活都量化，激活量化误差通常比只量化权重（W4A16）更伤，长上下文和复杂 reasoning 更容易掉点。4bit 权重 + FP16 激活一般是「质量/显存」的最佳折中；误差大头还是权重，不是激活。
• 速度：双 3090 走 PCIe（消费卡默认不启 P2P，需关 ACS / Above 4G，nvidia-smi topo -m 验），TP all-reduce 是瓶颈，不是 GEMM。W4A16 用 Marlin/GPTQ 系 kernel 有反量化开销，但省显存能开更长 context；W8A8 的 INT8 GEMM 更快，但省不出多少 context。
• MoE：优先 expert parallel 或至少 layer 级切分，减少 all-reduce 压力；262K context 先把 KV 实际占用算出来再谈开不开。
• KV dtype：3090 是 sm_86，不支持 FP8 KV，只能用 F16 或 INT8；--kv-cache-dtype fp8 只在 Hopper/Ada 原生可用。

更好的方案：优先 4bit 权重 + INT8/F16 KV，AWQ / GPTQ 都是 4bit WoQ，选 kernel 生态好的（vLLM 对 GPTQ/Marlin 最成熟）；混合精度部分层 8bit 收益有限、工程成本高，不如先把 KV 精度和 TP 切法调好。比在 W4/W8 之间纠结更值得试的是：同一权重下把 KV 砍到 INT8，用省下的显存直接堆 context。

QWEN 3.8 27B至少要30分钟，要不然关思考就做出一堆马赛克，甚至还有BUG。