大家中秋快乐！

在 "没苦硬吃！！3090带着小弟跑Qwen3.8-Flash-Next双卡实测"( https://lcz.me/topic/1397/6 )这个帖子里， 当时我还是 3090 24G + 3070 8G , 但是当时非常想知道跑起来什么样子，于是硬上llama.cpp跑，测出来是15-25tok/s 左右。 后来3070换成了 3080 20G， 没有优化调参，直接重复跑了一次， 变成了 30-36tok/s 左右。 前一阵入手了第二快 3090 ， 于是一直想着再复测一次。

但是，说到但是，必须吐嘈一下。新的3090是在一家维修显卡的店铺买的，店铺信誉还是不错的，超过15年实体店，老板人也不错，承诺店保1年。但3090到手后，发现满载有较明显的啸叫声，老板说这个很正常，让我随便造，大不了他给我保。于是用了一两个星期，感觉叫声越来越大了，我真的怕哪天爆一个元器件什么的，于是还是给退回去了。

老板也挺痛快，说给我换一个，但是他自己测了一下手头的卡，基本都同样的状况，挑不出来完全没有啸叫的， 在我的要求下， 他说帮我去找好货，但是时间要长点。 也吐嘈说， 现在的3090、4080、4090这些卡，基本没有非常好品相的了，能找到工厂里新出来的基本没有，大多是翻修卡。前期品相好的基本被挑的差不多，现在市场上流通的品质不太好说， 尤其是 4080 32G、 4090 48G 这种魔改卡， 出问题的概率比之前要大不少，之前可能20张4090有一个出问题，现在恨不得10张里面有2-3个出问题，他自己都不想卖了。

言归正传，正好休息，实在没事做，还是借着以前的3090+3080把这个测试做一下,我相信只要这个跑通了，2x3090只会更好。

结论先放

把 Qwen3.8-Flash-Next EXL3 3.05bpw turboderp 量化（90 GB，7 shards + 31 GB n-gram table）丢到 RTX 3080 20G + RTX 3090 24G（非对称 PCIe4.0，无 P2P），用 TabbyAPI cpu_moe_split_experts=192 + ctx=65536 + cache_mode=Q4 + draft_mode=mtp + dynamic_draft=true，实测：

• MTP off (baseline)： coding 出码平均 ~39.4 t/s decode，~0.5–1 s TTFT

• MTP on (dynamic_draft, ceiling=4)： **4 语言 coding 出码 8 轮 median 63.27 t/s ~ 69.69 t/s

• 多场景测速平均：~49.4 t/s（7 场景 21 个 chat 的中位）

• MTP off → on 加速：+50–65% decode throughput

• 短 ctx vs baseline：ctx=8K/16K prefill 143-152 t/s，decode 52-53 t/s；ctx=65K prefill 143-152 t/s，decode 57 t/s。

• ctx 上限：

  • 装得下的最大 ctx = 196K
  • ctx ≤ 65 536 时decode ≥ 60 t/s code；ctx ≥ 98 304 即跌破 55 t/s
  • 这台 3090+3080 + exl3 1.5.1 的最优甜蜜点 = ctx 65 536

1. 测试环境

1.1 硬件一览

1.2 软件

装了 exllamav3 之后还必须手动装 uvloop、aiohttp、async_lru、loguru、sse-starlette、huggingface-hub（PyPI 上 exllamav3 不带这些）。TabbyAPI 会以 from uvloop import install 第一次调用。

1.3 模型

2. 实测结果

2.1 配置 A：MTP off（baseline）

VRAM 占用：cuda:0 = 16.0 GB，cuda:1 = 21.3 GB，总 37.3 GB。

冷启动约 30 s（model loaded 完）。

主表： 3 rounds

每轮由 TabbyAPI 服务端 inst 日志报告 tokens generated at X T/s，取 4 轮平均值填 median。

表格里的 token 数都从 usage.completion_tokens 读（不是估算）。如果某轮撞到 1024-token 上限（常见在 C、Rust，因为 prompt 后机器仍倾向验证细节），单轮 t/s 偏低属于 prompt 收尾时机估算不能拆——保留是合理的稳态参考。

2.2 配置 B：MTP on (dynamic_draft, ceiling=4)

VRAM 占用：cuda:0 = 17.3 GB，cuda:1 = 22.3 GB，总 39.6 GB（多 2.3 GB 给 MTP 头 + draft cache）。

冷启动约 34.5 s。

2.3 多场景扩展测试（MTP on, ctx=65536, split=192）

在配置 B 的基础上扩到 7 个场景各 3 轮——code 4 语 + 英文 narrative / summarize + 中文 narrative。专门看 prose 类任务的吞吐下降。

观察：

1. code 任务平均 60+ t/s
2. prose 任务降至 ~29 t/s——因为输出 token 数小（136–290），MTP dynamic_draft 的 ceiling=4 在短生成中接受率较低这是 MTP 的天然特性：长输出才有戴 draft 的价值。
3. 中文 narrative 输出 character 数远低于英文（136 vs 283），但单字符内容更密；t/s 数字看上去差但实际 prose 信息量是接近的。

2.4 MTP on vs off 对照

3. 踩坑问题（这是个梗合集）

3.1 draft_mode 只能取有限枚举值

写 "draft_mode: enabled" 之类的 都会报：

pydantic_core._pydantic_core.ValidationError: 1 validation error for TabbyConfigModel
draft_model.draft_mode
  Input should be 'model', 'disabled', 'mtp' or 'ngram'

正确值只 4 个：disabled / model / mtp / ngram。用 mtp 才能让 exl3 内建 MTP head 接管。model 是再装一份独立 drafter GGUF，我们这台没那个文件。

3.2 VRAM 临界 40 GB 是 exl3 1.5.1 的 autosplit 死线

我反复试了 6 组 split/cache 组合：

教训是：exl3 1.5.1 autosplit 有 ~40 GB 死死线（host 44 GB = (20+24)）。超过这线硬崩，连 cache_mode=Q4 都救不了。想用满 VRAM 必须在 192-split/cx=65K 这条缝里做，不能再压 context。

3.3 用 enable_thinking: false ≠ /no_think 标语

TabbyAPI 的 OAI extra_body 走 chat_template_kwargs={"enable_thinking": False}，yml template（minja-numeric-index patched jinja）会把这个变量传给 jinja 模板让模型静默思考。单独写 /no_think 不行——模型仍思考，max_tokens=1024 时思考段会先填满，content 一段不写。

3.4 非流式响应走得快很多，但 server-log 才是真数据

curl -X POST /v1/chat/completions ... stream=false → OAI API 立即返回完整 JSON，但 usage.completion_tokens 是 end-of-stream 时累计的真实 token 数。手写的 streaming parser 在 Qwen3.8 + tabby 上能拿到 chunk 但 OpenAI protocol 把每个 token 拆成独立 data: {...}，所以 delta chunk 数 ≠ 真实 token 数（tabular.py 在合并多 token chunk）。别自己写 client parser 跟 server inst 数字对账——服务器 inst 每条 chat 都报 X tokens generated at Y T/s，那才是真实吞吐。

4. ctx 上限扫描：推到装不下 + 看每个 ctx 的 throughput

沿着 ctx → Q4 cache + MTP on，把 ctx 从 65K 一路拉到 20 万。每档重起 server 测 3 轮 Python code 取 median。

代码任务（Python prompt + max_tokens=1024）：

观测：

1. ctx 拉到 100K+ 时 t/s 即跌破 60：98K 是 51.9 t/s。
2. ctx=196K split=384（59% on CPU），VMRAM 只用了 24.7 GB 还有大量剩余——但 throughput 进一步跌到 31 t/s。同上：CPU-MoE 太多反而更慢。

4.1 短 ctx 测速：8K / 16K vs 65K 的 prefill + decode 对比

为了回答"短 ctx prefill/decode 会更快么"，专门测了 ctx=8K / 16K / 65K 三档，每档 3 轮 Python code prompt，MTP on，stream_options.include_usage=true 让 TabbyAPI 服务端直接报 prompt_tokens_per_sec 和 completion_tokens_per_sec。

观测：

1. prefill 反而短 ctx 更慢。
2. 短 ctx vs 长 ctx MTP draft 接受率相当。
3. 最低可行 ctx = 8K：cache_size=4096 撞 AssertionError: Cache too small for batch shape（chunk_size=4096），exl3 1.5.1 需要 cache ≥ chunk_size。

5. 感想

1. 不对称双卡确实能用 exl3 跑 176B MoE 模型。前提是：cache_size 砍、split 激进、MTP on。底线是每卡 20GB + 一张 24GB，足跑 3.05bpw + 60 t/s。

2. CPU-MoE 越少越好（前提 RAM 装得下）。本机 RAM 125 GB 装下 96 GB host_ram_gb 减去 8 GB OS、Python、cache buffer 后余 ~80 GB；32 GB n-gram + 25-30 GB offload experts 都能放下。

3. 不该 tabbyAPI 默认装。这个 cli 工具是个 helper，但它强依赖 --disable-auth、--override-preset safe_defaults，还得手动 pip 装一堆 deps。

4. code vs prose 任务吞吐差。MTP dynamic_draft 对长输出/重复模板类任务（code）收益大，因为它可以并行看出 4 个 token 并预测。对短输出（prose 130–290 char）MTP 接受率只剩 50% 左右，效益降至 +30% 上下。所以这次叙事类 t/s ~29，跟 code ~60 是 2:1 关系。

5. 要把 ctx 推到 100K+ 还想 ≥ 60 t/s：必须升级到双 3090 NVLink 或 H100 PCIe 5.0以上。这台 3090+3080 = 44 GB VRAM 在 exl3 1.5.1 死线下，最优 = 65K ctx / MTP on / split=192 / 39.7 GB VRAM。

6. 简单指令给急着复现的人

# 1. 装 venv
python3.12 -m venv /qwen38flash-exl3-venv
/qwen38flash-exl3-venv/bin/pip install exllamav3 fastapi-slim \
   "pydantic>=2.11,<3" ruamel.yaml uvicorn jinja2 loguru "sse-starlette>=2.2.0" \
   aiofiles aiohttp async_lru "huggingface_hub" psutil "httptools>=0.5.0" \
   pillow requests uvloop

# 2. 改 config（基于本帖 1.3 节 + 这次 3.3 的实测 OOM 边界）
# 主要变量：
#   max_seq_len: 65536, cache_size: 65536, cache_mode: Q4
#   cpu_moe_split_experts: 192
#   draft_mode: mtp, draft_num_tokens: 4, draft_dynamic: true
#   reasoning: false, template_vars_force: {enable_thinking: false}

# 3. 启动
THREADS=28 /qwen38flash-exl3-venv/bin/python -u \
   /qwen38flash/EXL3/tabbyAPI/main.py \
   --host 0.0.0.0 --port 5000

# 4. 跑 bench
python3 /bench-codingspeed/bench_qwen38.py