Qwen3.8-27B 在 16GB 显存上跑 128K–256K + 44–50 t/s 的可行性调研
================================================================
日期：2026-08-27
对象：RTX 5060 Ti 16GB / RTX 5080 16GB 级别消费卡 + llama.cpp
模型：Qwen3.8-27B（架构标签 qwen35；64 层 = 48 层 Gated DeltaNet 线性注意力 + 16 层全注意力）
提问者实测对照：同款 5060 Ti 16G，IQ4_XS + KV Q4_0，96K 占满 15.76G，26 t/s；开 MTP 再要约 1.88G 缓冲后 OOM
一、结论（先看这个）
----------------
总评：原声称「16GB 卡上 Q4 + 210K–256K 上下文 + 44–50 t/s」作为一条同时成立的配置，不可信。
把三条声称拆开看：
声称 1 Q4 + mmproj + KV 压缩 4 + 128K + MTP 3 + 44 t/s
判定：物理上装不下。速度数字单独看合理，但是短上下文 + MTP 的数字，不是 128K 填满后的数字。
声称 2 不加视觉、关 MTP：256K 上下文，35 t/s
判定：用真正的 Q4 权重（约 14–17GB）不可能。只有把权重压到约 2.7–3.0 bpw（约 8.7–11GB）才可能「分配」256K；即便如此，填满后的 decode 也远低于 35 t/s，除非把「分配了 256K 窗口、实际只填了几十 K」和「填满 256K」混为一谈。
声称 3 开 MTP：210K 上下文，50 t/s
判定：16GB + Q4 权重装不下 210K；50 t/s 是 5060 Ti 在 32K 左右、MTP n-max=2~3 的短上下文实测，不是 210K 填满后的速度。
提问者自己的 96K / 15.76G / 26 t/s 数字，和公开的独立测量高度吻合，应视为 16GB 卡上 IQ4_XS 的真实基线。差距来自：
(1) 把短上下文 MTP 速度当成了长上下文速度；
(2) 把「-c 262144 分配了窗口」当成「跑满 256K」；
(3) 把 Q4 权重和 2–3 bit 定制量化混称；
(4) 把单独加载的 MTP 草稿 GGUF（约 1.4–1.7GB）当成了必要开销——Unsloth 主 GGUF 里已经带了 nextn 张量；
(5) 把 5060 Ti（448 GB/s）和 5080（960 GB/s）当成同一性能档。
「甜品版 / oQ4e」：公开检索没有名为 oQ4e 的 GGUF 量化格式。中文圈「甜品版」通常指 Q4_K_M / UD-Q4_K_XL（约 16.5–17.9GB），而这恰恰是 16GB 卡装不下的那一档。16GB 卡的真实甜点是 UD-Q3_K_XL（13.1GB）或 UD-IQ4_XS（14.3GB），上下文 32K–73K，不是 210K–256K。
二、模型架构：为什么 27B 的 KV 比「普通 27B」便宜 4 倍，但还是装不满 16GB
------------------------------------------------------------------------
官方布局（Hugging Face 模型卡 / config.json）：
64 层 = 16 × [ 3×(Gated DeltaNet → FFN) + 1×(Gated Attention → FFN) ]
Gated Attention：Q 头 24，KV 头 4，head_dim 256
Gated DeltaNet：V 头 48 / QK 头 16，head_dim 128；状态大小与序列长度无关
词表 248,320；隐藏维 5120；FFN 中间维 17,408
原生上下文 262,144；MTP（nextn）随权重量化一起进 GGUF
只有 16 层全注意力按 token 增长 KV；48 层 DeltaNet 只持有固定循环状态（约 72–154 MiB，不随上下文涨）。
每 token 的 BF16/F16 KV：
16 层 × 4 KV 头 × 256 维 × 2（K+V）× 2 字节
= 65,536 字节 = 64 KiB / token
这就是社区反复引用的公式，和提问者给的「8K≈0.5GB / 32K≈2GB / 262K≈16GB」一致。提问者写的 16.4GB 是把 262,144×64KiB 按十进制 GB 换算的结果（约 17.2×10^9 字节），按 GiB 计是整 16.00 GiB。后文统一用 GiB。
Q4_0 并不是精确的 1/4。llama.cpp 的 Q4_0 是 32 个值 + 1 个 FP16 scale = 4.5 bit/值，相对 F16 的 16 bit 约为 28%。社区实测表（同一张 24GB 卡、同一份 Q4_K_M）给出：
F16/F16 ≈ 64 KiB/token
Q8_0/Q8_0 ≈ 34 KiB/token
Q8_0/Q4_0 ≈ 26 KiB/token
Q4_0/Q4_0 ≈ 18 KiB/token
按这个表把 KV 算死：
上下文 F16 KV Q8 KV Q4_0 KV
8,192 0.50 GiB 0.27 GiB 0.14 GiB
32,768 2.00 GiB 1.06 GiB 0.56 GiB
65,536 4.00 GiB 2.13 GiB 1.13 GiB
98,304 6.00 GiB 3.19 GiB 1.69 GiB ← 提问者 96K 实测所在档
131,072 8.00 GiB 4.25 GiB 2.25 GiB
210,000 13.13 GiB 6.97 GiB 3.69 GiB
262,144 16.00 GiB 8.50 GiB 4.50 GiB
16GB 卡还要扣：
CUDA 运行时 / 计算缓冲 / 图 约 0.4–0.8 GiB
DeltaNet 固定状态 约 0.07–0.15 GiB
mmproj F16（视觉） 约 0.91 GiB（931 MB）
单独 MTP 草稿 GGUF（如果加载） 1.37–1.68 GiB（Unsloth Q4_0 / ggml-org Q4_0）
MTP 自己的 KV + 草稿缓冲 再加几百 MiB；提问者看到的「还要 1.88G」几乎就是「又加载了一份 MTP GGUF」
Hardware Corner 用 Q4_K Small（16.68 GiB）在默认（接近 F16）KV 下测到：4K=18GB，64K=22GB，128K=26GB，256K=34GB。这正好是「权重 17GB + F16 KV」，和公式对得上，也证明默认 KV 下 256K 根本不是 16GB 卡的事。
三、「甜品版 / oQ4e」是什么
--------------------------
公开检索（Hugging Face、ModelScope、llama.cpp、ik_llama.cpp、Unsloth、bartowski、ubergarm、中文社区）没有找到名为「oQ4e」的量化格式或仓库。
中文本地部署圈里「甜品版」几乎总是指质量/体积比最好的那一档，对应：
文件 大小 16GB 卡命运
Unsloth UD-Q4_K_XL 17.6–17.9 GB 装不下（权重就已经超过 16GB）
Unsloth UD-Q4_K_M 16.5 GB 装不下或只能空载、几乎无 KV
Unsloth Q4_0 16.1 GB 同上
Unsloth UD-Q4_K_S 15.4 GB 贴边，几乎没有上下文
Unsloth UD-IQ4_XS 14.3 GB 16GB 上最大还能全卡驻留的 4-bit 档
第三方 IQ4_XS（非 UD） 15.7 GB 贴边；MTP 再开就 OOM
quimmedes Q4-XYZ-v2 15.06 GB 目前公开能在单卡 16GB 上开 MTP 的最大 Q4 档
Unsloth UD-Q3_K_XL 13.1–13.4 GB 16GB 卡真正的「能用甜点」：73K 上下文 + MTP
Unsloth UD-Q2_K_XL 9.83 GB 才开始有机会冲击 200K+ Q4 KV
定制 pareto 2.72 bpw 8.66 GiB 目前唯一有收据的「16GB 分配 256K」方案（见第七节）
最接近「oQ4e」字面的候选：
- IQ4_XS / UD-IQ4_XS（常被叫「4bit 压缩版」）
- bartowski 系 Q4_K_L（embed/output 升到 Q8，有人叫 Q4 extra）
- ubergarm / ik_llama.cpp 的 IQ4_KS（仅该 fork 能跑）
- Unsloth UD-Q4_K_XL（社区口中的 4-bit 甜点，但是给 24GB 卡的）
无论「oQ4e」具体指向哪一个 4-bit 文件，只要它还是 4-bit 量级（约 14–18GB），KV 公式就把它钉死在 16GB 卡上：全卡驻留下，Q4 KV 只剩大约 0.5–2.5 GiB，对应大约 30K–140K，到不了 210K–256K。
四、llama.cpp 的 KV 压缩：4-bit 之外还有什么
------------------------------------------
主线 llama.cpp（b10400+ / 当前 master）允许的 KV 类型：
-ctk / --cache-type-k
-ctv / --cache-type-v
允许值：f32, f16, bf16, q8_0, q4_0, q4_1, iq4_nl, q5_0, q5_1
默认：f16
草稿模型另有一套：
-ctkd / --cache-type-k-draft
-ctvd / --cache-type-v-draft
取值相同。
这就是「比 Q4 更强」和「比 Q4 更弱」的完整主线菜单：
更省（相对 Q4_0）：没有。主线最低就是 q4_0 / q4_1 / iq4_nl，都在 4–4.5 bit。
更保质量：q5_0、q5_1、q8_0、bf16、f16。
K/V 可以独立设，例如 -ctk q8_0 -ctv q4_0。社区评测：q8/q4 相对 F16 大约 40% 体积、质量损失约 1–2%；q5_1/q4_1 体积约 34%、质量略好。
非对称组合在 CUDA 上 historically 会让 prompt processing 掉回 CPU（pps 崩）。需要编译时打开 GGML_CUDA_FA_ALL_QUANTS，或坚持对称组合（q4_0/q4_0、q8_0/q8_0）。2026-08 有 PR #27140 修了小量化 KV 的 prefill 崩塌（修前 q4_0 prefill 约 74 t/s，修后约 1182 t/s）。请用 b10500 以后、含该修复的构建。
量化 V 缓存必须开 Flash Attention。-fa off 时 V 会停在 fp16，压缩等于没开。
主线没有、只存在于 fork / 未合入 PR 的更狠手段：
ik_llama.cpp：KV 可用 q6_0、部分 IQ 类型；--k-cache-hadamard / --v-cache-hadamard
OpenAlchemy / TheTom turboquant fork：turbo2（约 2 bit）、turbo3（约 3 bit），约 5–7× 相对 F16
TQ4_0 PR #20995：旋转后再 Q4_0，同等体积质量损失约为朴素 Q4_0 的 30%，未进主线
vLLM + KVarN：k4v2（K 4-bit / V 2-bit），是另一套引擎，不是 llama.cpp
原声称里的「KV 压缩 4」应对齐为：
-ctk q4_0 -ctv q4_0 -fa on
这已经是主线能给出的最强压缩。没有「再压一档就能在 Q4 权重上塞进 256K」的主线开关。
五、MTP / nextn 在 llama.cpp 里怎么开
-----------------------------------
机制：Qwen3.5/3.6/3.8 训练了 Multi-Token Prediction 头（nextn）。量化后的 GGUF 里是 blk.*.nextn.* 张量。不加 flag 时 llama.cpp 加载但不使用。PR #22673（2026-05，当时 flag 叫 --spec-type mtp）之后改名为：
--spec-type draft-mtp
旧写法 --spec-type mtp 会被静默忽略，速度直接腰斩。这是 2026-05 社区大规模「我的 t/s 突然少一半」事件的原因。
最小可工作命令（主 GGUF 已含 nextn 时，不要再加载第二份 MTP 文件）：
llama-server \
-m Qwen3.8-27B-UD-Q3_K_XL.gguf \
-ngl 999 -fa on -np 1 \
--spec-type draft-mtp \
--spec-draft-n-max 2
关键参数：
--spec-type draft-mtp
启用模型自带 MTP 头做投机解码。可逗号混用：
--spec-type ngram-mod,draft-mtp
--spec-draft-n-max N
每步草稿深度。默认 3。Qwen 官方 SGLang 示例是 nextn=3（--speculative-num-steps 3）。
16GB 5060 Ti 实测：n=2 → 50 t/s，n=3 → 54 t/s，n=4 → 59 t/s，n=6 加载 OOM。
24GB 卡在 n=2 就饱和；16GB 卡因为 DeltaNet 让 verify 便宜，加深草稿仍划算。
--spec-draft-p-min P
草稿置信度下限，默认 0。提到 0.6–0.8 会提高接受率、减少无效草稿。
带宽差的设备（APU/Mac）常净赚；5060 Ti 上 p-min=0.65 + n-max=4 反而比裸 n-max=4 慢 11%。
--spec-default
打开默认投机配置（会启用 ngram-mod）。Georgi 的官方示例带了它。
--parallel 1 / -np 1
MTP 是单流优化。-np 2 起优势迅速消失，-np 4 基本没了。测速必须 -np 1。
--spec-draft-type-k / --spec-draft-type-v（-ctkd / -ctvd）
草稿 KV 类型。16GB 上建议和主 KV 一样用 q4_0，或草稿用 q5_1。
两种加载 MTP 的方式，不要混用：
A. Unsloth / 多数现代 GGUF：nextn 已经在主文件里。
只需 --spec-type draft-mtp。
Reddit 16GB 实测：再加载一份独立 MTP GGUF 会额外吃约 768 MiB，完全没必要。
B. ggml-org 仓库把 MTP 头拆成单独文件（MTP Q4_0 = 1.68GB，MTP Q8_0 = 3.16GB）：
llama-server -hf ggml-org/Qwen3.8-27B-GGUF:Q4_K_M \
-hfd ggml-org/Qwen3.8-27B-GGUF:Q4_0 \
--spec-default --spec-type draft-mtp --reasoning-preserve
这就是提问者「开 MTP 还要 1.88G」的来源。16GB 卡上这份额外文件几乎必然 OOM。
限制：
- 历史版本 MTP 与 mmproj 不能同时用；PR #23286 之后主线可以共存，但图像 embedding 批次不会走草稿。
- llama.cpp issue #27282：原生 MTP 会另开一块 CUDA arena，满上下文时可能 OOM。
- MTP 破坏逐 bit 确定性（#25618）。要可复现输出用 --spec-draft-n-max 1。
- Unsloth 对 Qwen3.6 MTP 的旧警告（-np>1 和 --mmproj 不支持）对 3.8 已部分过时，但 16GB 上仍建议 --no-mmproj 换上下文。
加速幅度（不是「Blackwell 魔法」，是投机解码）：
5060 Ti 16GB、能装下的 Q4 文件、32K、q4_0 KV（qwen38-mtp 仓库 @jaisusx 扫参，b10472）：
MTP off 26.3 t/s VRAM 14,514 MiB
n-max 2 50.0 t/s 15,404 MiB
n-max 3 53.6 t/s 15,554 MiB
n-max 4 59.5 t/s 15,704 MiB（99.1% 占用，再深就 OOM）
PCGH / Reddit 另一组 IQ4_XS 14.60 GiB、32K、MTP-2：无 MTP 25.7 → MTP-1 40.0 → MTP-2 47.4–47.6 t/s。
接受率大约 0.5–0.85，有效加速 1.7–2.3×。这正好解释「44–50 t/s」从哪来——短上下文、MTP 打开、权重全卡驻留。
六、44–50 t/s 合不合理？5060 Ti 和 5080 不是同一档
------------------------------------------------
稠密 27B 的 decode 基本是显存带宽瓶颈。
卡 显存 带宽 理论天花板（14GB 权重常驻）
RTX 5060 Ti 16GB 448 GB/s 约 448e9 / 14e9 ≈ 32 步/秒 → 无 MTP 约 25–32 t/s
RTX 5080 16GB 960 GB/s 约 69 步/秒 → 无 MTP 约 50–70 t/s
RTX 4090 24GB 1008 GB/s 社区 Q4 约 39–48 t/s，MTP 后 60–80
RTX 5090 32GB 1792 GB/s 社区短上下文 MTP 可到 100+ t/s
所以：
- 5060 Ti 无 MTP 26 t/s：完全正常，提问者测到的就是这个。
- 5060 Ti 有 MTP 44–50 t/s：短上下文（4K–32K）完全正常，多个独立来源重复。
- 5060 Ti 在 96K 填满后仍 26 t/s：也正常。KV 变大后每步要多读 1.7GiB 量级的 Q4 cache，MTP 的加速会被带宽吃掉一部分。Reddit 在约 55K 填充后测到 31.3 t/s（MTP-1）。
- 5080 无 MTP 到 50 t/s 不难；把它和 5060 Ti 写成「同一级别」是原声称的第一处不严谨。两张卡显存相同，所以上下文上限相同；速度差大约一倍。
Blackwell 相关的真实优化：
1. 编译时必须 -DCMAKE_CUDA_ARCHITECTURES=120，否则跑在兼容内核上，浪费 SM120。
2. NVFP4 权重在 50 系上大约 1.5× 于 BF16，但 NVFP4 文件约 16–23GB，16GB 卡不是它的目标。
3. 没有「Blackwell 让 KV 凭空再小 4 倍」的主线特性。
4. CUDA Graphs + Flash Attention 是标配，不是秘密开关。
七、16GB 上 210K–256K 是否物理可行
--------------------------------
把「权重 + KV + 开销 ≤ 15.5 GiB 可用」当成硬约束（5060 Ti 可用显存大约 15.5–15.8 GiB）。
情形 A：Q4 权重（14.3–16.5GB）+ Q4 KV + 无视觉 + 无独立 MTP 文件
UD-IQ4_XS 14.3GB + 96K Q4 KV 1.69GiB + 开销 ≈ 15.7GB。这就是提问者测到的 15.76G / 96K。
线性外推：
128K：14.3 + 2.25 + 0.6 ≈ 17.2GB → OOM
210K：14.3 + 3.69 + 0.6 ≈ 18.6GB → OOM
256K：14.3 + 4.50 + 0.6 ≈ 19.4GB → OOM
第三方 IQ4_XS 15.7GB 更糟：32K 基线刚好，n-max 4 直接 OOM（差 240 MiB）。
情形 B：Q3 权重（UD-Q3_K_XL 13.1GB）+ Q4 KV + 无视觉
73K：13.1 + 1.26 + 0.6 ≈ 15.0GB，这是目前社区票数最高的 16GB 配方，MTP 后约 46 t/s。
128K：13.1 + 2.25 + 0.6 ≈ 16.0GB，贴边，部分机器能起来、部分 OOM。
210K：13.1 + 3.69 + 0.6 ≈ 17.4GB → OOM
256K：13.1 + 4.50 + 0.6 ≈ 18.2GB → OOM
情形 C：Q2 权重（UD-Q2_K_XL 9.83GB 或定制 8.66 GiB）+ Q4 KV + 无视觉
9.83 + 4.50 + 0.6 ≈ 14.9GB → 256K 分配在纸面上能进 16GB。
质量是 2-bit 档，不是「Q4」。原声称如果实际用的是这种文件，就不该叫 Q4。
情形 D：分配 256K、只填充几十 K
llama.cpp 的 -c 262144 会按窗口预分配 KV。Q4 KV 的 4.5 GiB 在启动时就要付掉，并不会因为「现在只聊了 4K」而少占。
所以「-c 256K 但实际短对话、速度 35 t/s」仍然要求权重小到能同时放下 4.5 GiB 的空 KV。Q4 权重做不到。
唯一公开、带收据的「16GB 分配 256K」是 github.com/7269827-rgb/qwen38-256k-on-16gb：
硬件是 RX 9070 XT 16GB（AMD，不是 5060 Ti）
权重是定制 pareto 量化 8.66 GiB / 2.72 bpw（FFN gate/up 走 q2_K）
256K 分配、40K 填充时 56 t/s；200K 填满 + 自制 selective-skip 补丁 42–46 t/s；
主线 llama.cpp、无补丁、200K 填满约 33 t/s；
作者自己写：新鲜启动可能落到 24–29 t/s 的慢状态。
这不能给原声称背书：量化不是 Q4，卡不是 5060 Ti，200K 的高速依赖非主线补丁。
情形 E：双卡 2×5060 Ti（32GB）
Hardware Corner：128K 生成 15.55 t/s（无 MTP 的他们那套）。AboveSpec：Q6_K + MTP，150K 驻留 19.4 t/s。
这是 32GB 方案，不是单卡 16GB。
情形 F：--fit on 把部分层赶到 CPU
IQ4_NL + --fit 能加载，但基线掉到 16.8 t/s；再开 MTP 把 4 层放 CPU 反而从 25.2 降到 20.3 t/s。
用 CPU 换上下文会把「50 t/s」直接打穿。
情形 G：-nkvo 把 KV 放系统内存
权重可以全在 GPU，256K Q4 KV 放在 DRAM。注意力每步都要过 PCIe，长上下文速度会远低于 26 t/s，更到不了 35–50。
结论：单卡 16GB + 真正的 Q4 权重 + 主线 llama.cpp，物理上限大约是：
无视觉、无独立 MTP 文件、Q4 KV、IQ4_XS 级权重 ~32K–96K（提问者 96K 已是上限附近）
无视觉、MTP 开在主 GGUF 内、Q3 权重 ~64K–73K，46 t/s 量级
带 mmproj F16 再减约 0.9GB，上下文再砍一截
210K–256K 必须 Q2 档权重，或双卡，或 KV 下放到内存（速度报废）
八、三条声称的逐条拆解
--------------------
声称 1
「Q4 + 视觉 mmproj + KV 压缩 4 + 128K + MTP 3 + 44 t/s」
拆：
Q4 权重 14–17GB
mmproj F16 ≈ 0.91GB
MTP n-max=3 的草稿 KV/缓冲，16GB 卡上约 0.4–0.8GB（若再加载独立 MTP 文件则 +1.4–1.7GB）
128K Q4 KV ≈ 2.25 GiB
合计 18GB+，超过 16GB。
44 t/s 本身：5060 Ti、32K、MTP n-max=2 的公开数字就是 47–50 t/s。所以速度是短上下文数字，被贴到了 128K + 视觉的配置上。
可信度：配置不可行；速度数字是别的配置的。
声称 2
「不加视觉、关 MTP：256K，35 t/s」
拆：
Q4 权重 + 256K Q4 KV（4.5 GiB）≥ 19GB。不可行。
若权重是 8.7–10GB 的 2-bit/混合量化，分配 256K 可行。主线、无补丁、填满 200K 的公开数字约 28–33 t/s（AMD 16GB Vulkan）或更低。
「35 t/s @ 256K」最像是：-c 262144 分配成功（用了小量化），实际生成时上下文只有几十 K。llama-bench 在 4K 上 Q3/Q4、无 MTP，5060 Ti 大约就是 25–32 t/s；AMD 16GB 无 MTP 4K 约 45 t/s。数字对得上「短上下文」，对不上「填满 256K」。
可信度：字面配置不可行；若改成「Q2/定制量化、分配了 256K、实际短填充」，速度可以接近。
声称 3
「开 MTP：210K，50 t/s」
拆：
210K Q4 KV ≈ 3.69 GiB。Q4 权重装不下。Q3 也装不下。需要 ≤11GB 权重。
50 t/s 精确对应 5060 Ti、32K、MTP n-max=2 的中位数（qwen38-mtp 扫参表：50.0 t/s）。
长上下文会同时打低接受率、打高 KV 带宽。AboveSpec 双卡 32GB、Q6、MTP，150K 填满是 19.4 t/s（浅处 37 t/s）。单卡 16GB 填满 210K 还要 50 t/s，和带宽模型相反。
可信度：不可行。50 t/s 是短上下文 MTP 数字被搬家。
九、和提问者实测差距的解释
------------------------
提问者：IQ4_XS + KV Q4_0 + 96K = 15.76G，26 t/s；开 MTP 再要 1.88G → OOM。
这组数字不仅不「落后」，而且就是 16GB 卡的正确物理图像。
1. 26 t/s 就是 5060 Ti 全卡驻留、无 MTP 的基线。独立来源：26.3（Q4-XYZ-v2 / 32K）、25.7（IQ4_XS / 32K）、25.2（Unsloth IQ4_XS / 32K）、27.4（UD-IQ4_XS / 32K 无 MTP）。96K 比 32K 再慢一点完全正常。
2. 15.76G @ 96K 符合 KV 公式。UD-IQ4_XS 14.3GB + 1.69GiB Q4 KV + ~0.6GB 开销 ≈ 15.6–16.0GB。再往上加 32K 就会顶满。
3. 「开 MTP 要 1.88G」强烈暗示加载了 ggml-org / Unsloth 的独立 MTP Q4_0（1.37–1.68GB）再加上 MTP 自己的 KV。正确做法：用已经含 nextn 的主 GGUF，只加 --spec-type draft-mtp，额外显存大约 0.4–0.9GB（扫参表：14,514 → 15,404 MiB @ n-max=2）。IQ4_XS 15.7GB 那一档就是「基线能上、MTP n-max=4 差 240 MiB」——提问者 OOM 和这份公开表格是同一件事。
4. 原声称能「多出」100K+ 上下文和近一倍速度，不是因为你少开了某个神秘开关，而是因为对照实验不是同一件事：更小的权重、更短的实际填充、MTP 打开、可能还有双卡或定制补丁。
十、可复现的 llama.cpp 启动命令
------------------------------
前置：
- llama.cpp b10472 或更新，务必包含 CUDA FA 对 q4 KV 的 prefill 修复（#27140 一类，建议 b10520+）。
- 编译：cmake -B build -DGGML_CUDA=ON -DCMAKE_CUDA_ARCHITECTURES=120 && cmake --build build -j --target llama-server
- 驱动能看见 SM120。Windows 用户注意：部分构建要自己指定 120，否则会走兼容内核。
- 测速一律 -np 1，thinking 先关或 reasoning_effort=medium，否则 xhigh 会先想几万 token，t/s 被「思考长度」扭曲。
- nvidia-smi 看的是 MiB；llama.cpp 日志里的 kv size 才是 KV 真实占用。
----- 配方 0：复现提问者自己的基线（IQ4_XS，96K，无 MTP）-----
# 权重：unsloth/Qwen3.8-27B-GGUF 的 Qwen3.8-27B-UD-IQ4_XS.gguf（14.3GB）
# 预期：VRAM ~15.5–15.8G，短生成 ~25–27 t/s，96K 填满后略降
llama-server \
-m Qwen3.8-27B-UD-IQ4_XS.gguf \
-ngl 999 -fa on -np 1 \
-c 98304 \
-ctk q4_0 -ctv q4_0 \
--jinja --reasoning-preserve \
--host 127.0.0.1 --port 8080
# 不要加 -md / -hfd。不要加 --mmproj。这就是 15.76G 那条线。
----- 配方 1：16GB 上最推荐的日用（质量 / 速度 / 上下文的真实甜点）-----
# 权重：Qwen3.8-27B-UD-Q3_K_XL.gguf（13.1–13.4GB）
# 社区最高票 16GB 配方：73,728 上下文，MTP + ngram，约 46 t/s（JS 生成）
# KV 用 q4_1（比 q4_0 稍大一点、质量略好）；草稿 KV 用 q5_1
llama-server \
-m Qwen3.8-27B-UD-Q3_K_XL.gguf \
-ngl 999 -fa on -np 1 \
--fit off \
--ctx-checkpoints 0 \
-c 73728 \
-ctk q4_1 -ctv q4_1 \
-ctkd q5_1 -ctvd q5_1 \
--spec-type ngram-mod,draft-mtp \
--spec-draft-n-max 2 \
--temp 0.4 --top-p 0.90 --top-k 15 --min-p 0.02 \
--chat-template-kwargs '{"preserve_thinking": true, "reasoning_effort": "medium"}' \
--reasoning-budget 5000 \
--jinja --reasoning-preserve \
--host 127.0.0.1 --port 8080
----- 配方 2：16GB 上冲击最大 Q4 质量 + MTP（上下文必须短）-----
# 权重优先：能装下的定制 Q4（例如 quimmedes/Qwen3.8-27B-XYZ Q4-XYZ-v2，15.06GB）
# 次选：Unsloth UD-IQ4_XS 14.3GB（MTP n-max 建议 1–2，n-max 4 会 OOM）
# 预期：32K，MTP off ≈ 26 t/s，n-max 2 ≈ 47–50 t/s，n-max 3 ≈ 53 t/s
llama-server \
-m Qwen3.8-27B-UD-IQ4_XS.gguf \
-ngl 999 -fa on -np 1 \
--fit off \
-c 32768 \
-ctk q4_0 -ctv q4_0 \
-ctkd q4_0 -ctvd q4_0 \
--spec-type draft-mtp \
--spec-draft-n-max 2 \
--jinja --reasoning-preserve \
--host 127.0.0.1 --port 8080
# 若 VRAM 仍有 >400 MiB 余量，再试 --spec-draft-n-max 3。
# 不要同时加独立 MTP 文件。
----- 配方 3：16GB 上要视觉（mmproj）时必须让出的东西 -----
# mmproj F16 ≈ 0.91GB。Q3 权重 + 32K + MTP-1 是目前公开能同时站住的组合。
# Reddit：UD-IQ4_XS + MTP-1 + F16 mmproj + 64K = 15,680 MiB，45.4 t/s（短上下文）。
# 这已经是 16GB 的天花板，128K 不要想。
llama-server \
-m Qwen3.8-27B-UD-IQ4_XS.gguf \
--mmproj mmproj-Qwen3.8-27B-F16.gguf \
-ngl 999 -fa on -np 1 \
--fit off \
-c 32768 \
-ctk q4_0 -ctv q4_0 \
--spec-type draft-mtp \
--spec-draft-n-max 1 \
--jinja --reasoning-preserve \
--host 127.0.0.1 --port 8080
# mmproj 来源：ggml-org/Qwen3.8-27B-GGUF 或 prithivMLmods 的 mmproj-bf16 / mmproj-f16。
# 更省：mmproj-q8_0（约 629MB），视觉质量略降。
----- 配方 4：Georgi 官方 MTP 示例（这是 24GB 卡的，16GB 会 OOM）-----
# 仅作对照。Q4_K_M ≈ 17–19GB，主文件就已经超过 16GB。
# llama-server -hf ggml-org/Qwen3.8-27B-GGUF:Q4_K_M \
# -hfd ggml-org/Qwen3.8-27B-GGUF:Q4_0 \
# --spec-default --spec-type draft-mtp --reasoning-preserve
----- 配方 5：想尽量逼近 128K（无视觉、Q3、无 MTP，贴边）-----
llama-server \
-m Qwen3.8-27B-UD-Q3_K_XL.gguf \
-ngl 999 -fa on -np 1 \
--fit off \
-c 131072 \
-ctk q4_0 -ctv q4_0 \
--jinja \
--host 127.0.0.1 --port 8080
# 预期：部分 16GB 卡能起来，部分在创建 KV 时 OOM。
# 起来了也不要期待 35–50 t/s：无 MTP 的 128K 填满后，带宽模型给出的是十几 t/s。
----- 配方 6：不要这样开（这就是提问者 OOM 的路径）-----
# 错误：主文件已经含 nextn，又用 -md / -hfd 加载第二份 MTP。
# llama-server -m IQ4_XS.gguf -md Qwen3.8-27B-MTP-Q4_0.gguf \
# --spec-type draft-mtp -c 98304 -ctk q4_0 -ctv q4_0 -ngl 999
# 额外 1.4–1.9GB，16GB 卡直接爆。
----- 测速建议 -----
# 短上下文（和 44–50 t/s 声称对齐）：
curl 127.0.0.1:8080/v1/chat/completions \
-H 'Content-Type: application/json' \
-d '{"model":"x","messages":[{"role":"user","content":"Write a Python merge sort."}],"max_tokens":256,"temperature":0}'
# 看 llama-server 日志里的 prompt eval time / eval time，以及 draft acceptance。
# 不要用「模型原生 256K」当「我正在跑 256K」。真正填满后，eval time 会明显变慢。
# 看 KV 是否按你想的量化：
# 启动日志应出现 type_k = q4_0, type_v = q4_0，且 flash_attn = enabled。
十一、16GB 卡应该怎么选（可执行建议）
----------------------------------
目标 量化 上下文 MTP 预期速度（5060 Ti）
日常对话 / 编程，要速度 UD-Q3_K_XL 13.1GB 32K–73K n-max 2 40–50 t/s
尽量保 4-bit 质量 UD-IQ4_XS 14.3GB 或定制 Q4 32K n-max 2 45–50 t/s
尽量长上下文（无视觉） UD-Q3_K_XL 64K–96K 关或 n-max 1 25–35 t/s
要视觉 UD-IQ4_XS + mmproj q8/F16 32K n-max 1 ~45 t/s 短上下文
冲击 200K+ 不要用 Q4；用 UD-Q2_K_XL 能分到 256K 视余量 填满后 15–30 t/s，质量明显差
24GB 卡的「甜点」 UD-Q4_K_XL / Q4_K_M 128K–262K n-max 2 这才是原声称该去的硬件
原声称把「24GB 卡 + Q4 + 量化 KV + MTP 短上下文」的体验，口述成了「16GB 卡 + Q4 + 210K–256K」。数字分别都能在别的配置上找到出处，拼到同一张 16GB 卡上则违反显存加法。
十二、主要来源
------------
架构与 KV 公式
Hugging Face Qwen/Qwen3.8-27B 模型卡（64 层、16×(3 GDN + 1 GA)、4 KV 头、head_dim 256）
r/Qwen_AI「64 KiB/token，262K = 16 GiB KV」（发布当天按模型卡算出来的，后续实测吻合）
SGLang cookbook：bf16 65.5 KB/token，fp8 32.8 KB/token；DeltaNet 状态 78–154 MB 固定
量化文件大小
unsloth/Qwen3.8-27B-GGUF（UD-IQ4_XS 14.3GB，UD-Q3_K_XL 13.1GB，UD-Q4_K_XL 17.6GB，MTP Q4_0 1.37GB）
ggml-org/Qwen3.8-27B-GGUF（Q4_K_M 19GB，MTP Q4_0 1.68GB）
16GB / 5060 Ti 实测
github.com/sudoingX/qwen38-mtp/sweeps/rtx-5060-ti.md（26.3 → 50/54/59 t/s 扫参，n-max 6 OOM）
PCGH 2026-08-17：IQ4_XS 14.60 GiB、32K、MTP-2 = 47.6 t/s
r/LocalLLaMA 2026-08-21：5060 Ti、IQ4、64K、MTP-1 = 45–47 t/s；55K 填充后 31.3 t/s
Hardware Corner：Q4 权重默认 KV 下 128K=26GB、256K=34GB；双 5060 Ti 128K 生成 15.55 t/s
codersera 16GB 配方：UD-Q3_K_XL、73728、MTP+ngram ≈ 46 t/s
256K-on-16GB（不是 Q4，不是 5060 Ti）
github.com/7269827-rgb/qwen38-256k-on-16gb（8.66 GiB / 2.72 bpw，RX 9070 XT）
llama.cpp 接口
tools/server/README.md：-ctk/-ctv 允许值；-ctkd/-ctvd
docs/speculative.md：--spec-type draft-mtp，--spec-draft-n-max 默认 3，--spec-default
PR #22673 MTP；2026-05 重命名 mtp → draft-mtp
PR #23286 MTP+mmproj 共存
PR #27140 q4 KV prefill 修复
MTP 额外开销
独立 MTP GGUF 1.37–1.68GB；主 GGUF 已含 nextn 时再加载纯属浪费（Reddit：+768 MiB）
llama.cpp #27282 MTP 另开 CUDA arena 导致满上下文 OOM
十三、一句话
------------
16GB 卡跑 Qwen3.8-27B 是真的，44–50 t/s 也是真的，256K 原生窗口也是真的；但这三件事不能在同一份 Q4 权重、同一张单卡、同一个填满的上下文里同时为真。提问者 96K / 15.76G / 26 t/s 的测量是对的。要对齐原声称的速度，开主 GGUF 内的 MTP、把上下文降到 32K–73K、必要时换 UD-Q3_K_XL；要对齐原声称的 210K–256K，只能换 2-bit 级权重或换 24GB 以上的卡。