Qwen3.8-27B 带视觉（mmproj）在 16GB 卡上的第三轮补充调研
======================================================
日期：2026-08-27
对象：对方明确声称「模型带视觉能力」；硬件仍是 RTX 4090 Laptop 16GB（576 GB/s）
与提问者本机 RTX 5060 Ti 16GB（448 GB/s）
前提：前两轮已认定「Q4 + 128K/256K + MTP」装不下。本轮只补视觉这一项。
对照文件：
/home/zyw/Downloads/grok-16g-256k-调研.txt （第一轮：16GB + 256K 声称）
/home/zyw/Downloads/grok-4090laptop-补充调研.txt （第二轮：4090 Laptop 硬件）
本报告不改 KV 公式、不改 16GB 可用显存上限。变的是：mmproj 常驻 + 图像 encode 峰值 + MTP 能否与 --mmproj 共存。
一、结论（先看这个）
----------------
对方把「官方是原生多模态」说成「我这张 16GB 卡上 Q4+视觉+128K+MTP3=44 t/s」，这两件事不是同一条配置。
1. Q4 权重 + mmproj（F16 0.93GB 或 q8_0 0.63GB）+ 128K Q4 KV + MTP3
合计约 18.3–19.1 GB。16GB 卡装不下。换 q8_0 mmproj 只省 0.3GB，补不回 2.25 GiB 的 128K KV。
4090 Laptop 和 5060 Ti 显存同为 16GB，这条线两边一起死。
2. 带视觉后，真正的 Q4 权重在 16GB 上最大可行上下文大约是：
无 MTP、mmproj q8_0：约 32K–48K（贴边到 64K 看机器）
开 MTP n-max=1、mmproj F16：约 8K–32K
开 MTP n-max=3：Q4 档几乎没有余量，多数会 OOM
要同时站住「视觉 + 128K + MTP」，权重必须掉到 IQ3_XXS / Q2 档（约 9.8–10.9GB），那就不是 Q4。
3. 「带视觉跑 44 t/s」作为 decode 数字，短上下文下并不比纯文本更不可能——图像 encode 结束后，
mmproj 闲置，decode 仍只扫语言模型权重。但 44 t/s 仍然是 8K–32K + MTP 的短上下文数字，
不是 128K 填满后的数字，也不是「看图那一下」的端到端速度。
带视觉让「Q4+128K+MTP+44 t/s」作为一条同时成立的配置，比前两轮更不可能。
4. llama.cpp 里 --mmproj 与 --spec-type draft-mtp 能共存。依据是已合入的 PR #22673，
不是被关掉的 PR #23286。图像 embedding 批次不走草稿；助手生成阶段 MTP 仍加速。
视觉 prefill 本身不会被 MTP 加速。
5. 公开检索没有「4090 Laptop 16GB + Qwen3.8-27B + 视觉」带收据的 tok/s。
16GB 卡上带视觉的公开实测，权重都是 Q3 / IQ3，上下文 32K–64K，速度 20–40 t/s 量级。
没有一份把 Q4 + 视觉 + 128K + MTP3 + 44 t/s 跑通。
一句话：官方原生多模态是真的；16GB 卡上「Q4 + 视觉 + 128K + MTP + 44 t/s」仍然是把短上下文 MTP 速度贴到装不下的配置上。视觉让显存账单再加 0.63–0.93GB，上下文上限更紧，不是更松。
二、官方视觉能力 vs GGUF 的 mmproj：两套东西
------------------------------------------
官方权重（Hugging Face Qwen/Qwen3.8-27B，任务标签 Image-Text-to-Text）：
类型：Causal Language Model with Vision Encoder（原生 VLM，不是后挂 adapter）
语言模型：27B；含视觉塔后总参数约 27.78B（社区常写 28B）
视觉塔：27 层，hidden 1,152，patch 16，spatial_merge 2，
intermediate 4,304，heads 16，投影到语言模型 5,120 维
社区把这份塔叫 CLIP 风格，约 458–461M 参数
输入：文本 + 图像 + 视频；输出：文本
官方 safetensors / FP8 把视觉编码器打进主权重，不需要单独文件
GGUF 路线把视觉塔拆出来：
主 GGUF = 语言模型（含 MTP/nextn 张量）
mmproj = 视觉编码器 + 投影层，必须 --mmproj 另载
不加 --mmproj：文本正常，贴图被静默忽略（看起来像「视觉坏了」）
文件体积（Hugging Face 指针，字节级）：
文件 字节 十进制 GiB
unsloth mmproj-F16.gguf 927,607,488 0.928 GB 0.864 GiB
unsloth mmproj-BF16.gguf 931,146,432 0.931 GB 0.867 GiB
prithivMLmods / Blackfrost
mmproj-q8_0 约 629 MB 0.63 GB 0.59 GiB
前两轮写的「F16 0.91GB / q8_0 0.63GB」对得上。F16 与 BF16 几乎同大，质量无实质差别。
q8_0 省约 300MB。Blackfrost 注明：宽 4,304 的中间层张量量化失败会自动留 F16，
所以 q8_0 不是「整份塔都压到 8-bit」，实际更接近 0.63GB 这个数。
ggml-org 的 27B 仓主要出拆开的 MTP 草稿文件（Q4_0 1.68GB），q8_0 mmproj 要去
prithivMLmods / Blackfrost 等第三方仓。Unsloth 主仓给 F16 / BF16。
默认行为（llama.cpp docs/multimodal.md）：
--mmproj-offload 默认开：mmproj 整份上 GPU
--no-mmproj-offload mmproj 留在主机内存，图像 encode 走 CPU，极慢
--no-mmproj 彻底不要视觉，给文本腾显存
16GB 上「带视觉」= 默认把 0.63–0.93GB 常驻 GPU。这是启动时就要付的，不是「看图才占」。
三、问题 1：Q4 + mmproj + 128K Q4 KV + MTP 到底多少 GB？装得下吗？
--------------------------------------------------------------
沿用前两轮公式（与模型卡一致）：
F16 KV = 64 KiB / token
Q4_0 KV ≈ 18 KiB / token（Q4_0 是 4.5 bit/值，约 F16 的 28%）
上下文 Q4_0 KV
8,192 0.14 GiB
32,768 0.56 GiB
65,536 1.13 GiB
98,304 1.69 GiB
131,072 2.25 GiB ← 声称的 128K
262,144 4.50 GiB
MTP 额外（qwen38-mtp 在 5060 Ti、15.06GB Q4、32K 上的实测差）：
MTP off → n-max 2：+890 MiB
MTP off → n-max 3：+1,040 MiB ← 「MTP 3」
MTP off → n-max 4：+1,190 MiB（再深加载 OOM）
运行开销（CUDA / 图 / DeltaNet 固定状态）按 0.6 GB。
4090 Laptop 再扣内屏 / WDDM 0.2–0.8 GB，可用按 15.0–15.5 GiB。
5060 Ti 桌面可用按 15.5–15.8 GiB。下面用 15.5 做公共上限。
把加法写死。权重用「16GB 上最大还能全卡驻留的 4-bit」UD-IQ4_XS = 14.3 GB（十进制）。
配置 合计 16GB 命运
IQ4_XS + F16 mmproj + 128K + MTP3
14.3 + 0.93 + 2.25 + 1.04 + 0.6 ≈ 19.1 GB OOM，差约 3.5GB
IQ4_XS + q8_0 mmproj + 128K + MTP3
14.3 + 0.63 + 2.25 + 1.04 + 0.6 ≈ 18.8 GB 仍 OOM
IQ4_XS + F16 mmproj + 128K，关 MTP
14.3 + 0.93 + 2.25 + 0.6 ≈ 18.1 GB 仍 OOM
IQ4_XS + q8_0 mmproj + 64K + MTP1
14.3 + 0.63 + 1.13 + 0.40 + 0.6 ≈ 17.1 GB 仍 OOM
第一轮引用的 Reddit 天花板
IQ4_XS + F16 mmproj + MTP-1 + 64K 15,680 MiB 短上下文 45.4 t/s；
这是 16GB 带视觉的实测顶，不是 128K
换 Q3 也救不了「Q4 声称 + 128K」：
UD-Q3_K_XL 13.1 + F16 0.93 + 128K 2.25 + MTP3 1.04 + 0.6 ≈ 17.9 GB → OOM
UD-Q3_K_XL 13.1 + q8_0 0.63 + 128K 2.25 + 无 MTP + 0.6 ≈ 16.6 GB → 贴边到 OOM
（笔记本更先爆）
所以问题 1 的直接答案：
Q4 + 视觉 + 128K Q4 KV + MTP：装不下，约 18.3–19.1 GB。
4090 Laptop 没有多出来的第 17 个 GB。带宽 576 vs 448 改速度，不改容积。
四、带视觉后最大可行上下文（16GB，全卡驻留）
------------------------------------------
工作预算 15.5 GiB。文件的「GB」按 Hugging Face 十进制，KV 用 GiB。
换算时 UD-IQ4_XS 14.3 GB ≈ 13.3 GiB，UD-Q3_K_XL 13.1 GB ≈ 12.2 GiB，
UD-IQ3_XXS 10.9 GB ≈ 10.15 GiB，UD-Q2_K_XL 9.83 GB ≈ 9.15 GiB。
mmproj F16 = 0.86 GiB，q8_0 = 0.59 GiB。开销 0.5–0.6 GiB。
权重 mmproj MTP 留给 Q4 KV 大约上下文
UD-IQ4_XS 13.3G F16 0.86 关 ~0.7–0.9 GiB 32K–48K
UD-IQ4_XS q8 0.59 关 ~1.0–1.2 GiB 48K–64K 贴边
UD-IQ4_XS F16 n-max 1 ~0.3–0.5 GiB 8K–32K
UD-IQ4_XS 任一 n-max 3 几乎没有 空载或 OOM
UD-Q3_K_XL 12.2G F16 关 ~1.8–2.0 GiB ~100K；128K 差一截
UD-Q3_K_XL q8 关 ~2.1 GiB 128K 纸面贴边，笔记本易 OOM
UD-Q3_K_XL F16 n-max 2 ~1.0–1.2 GiB ~55K–70K
UD-Q3_K_XL F16 n-max 3 ~0.8–1.0 GiB ~45K–55K
UD-IQ3_XXS 10.2G F16 n-max 2 ~3.2 GiB 128K + MTP 纸面能进
UD-Q2_K_XL 9.2G F16 n-max 3 ~4.3 GiB 128K + MTP 宽松
读表规则：
- 「Q4 + 视觉」在 16GB 上的现实上限是 32K 左右能开 MTP，64K 要关 MTP 或换 q8 mmproj，
到不了 128K。
- 「视觉 + 128K + MTP」纸面能进的，是 IQ3_XXS / Q2，不是 Q4。
- 4090 Laptop 若在 Windows + 内屏，把上表每档再砍 8K–16K。
图像 token 对 KV 的增量很小，不是瓶颈：
llama.cpp 对本家族要求 --image-min-tokens 1024（低于此位置编码不稳）
视觉 token ≈ ceil(H/28)×ceil(W/28)（patch 16 × merge 2）
日常截图大约 256–2048 token；Groq 托管按每图 2048 计费
2048 × 18 KiB ≈ 36 MiB Q4 KV —— 相对 mmproj 常驻的 0.9GB 可以忽略
真正吃显存的是 mmproj 权重常驻，加上图像 encode 时 CLIP 计算缓冲的峰值
（llama.cpp issue #23422：缓冲 reserve 失败会在第一张图 SIGSEGV）。
16GB 贴顶时，即使「加载成功」，第一张图仍可能爆。这是带视觉比纯文本更险的地方。
五、问题 2：带视觉跑 44 t/s，更不可能还是更可能？
----------------------------------------------
先把「44 t/s」拆成三件事，不要混。
A. 加载后、纯文本短上下文、MTP n-max=2~3 的 decode
B. 看完一张图之后，生成回复的 decode
C. 从点发送到第一个字的端到端（含视觉 encode + 图像 token prefill）
A 和 B 几乎是同一档速度。mmproj 在 decode 阶段闲置，不被每步扫一遍。
decode 带宽公式仍是「带宽 / 语言模型权重」，不是「带宽 / (权重+mmproj)」。
所以：如果 Q4 权重仍然全卡驻留、上下文仍是 8K–32K、MTP 仍开着，
带视觉的 decode 44 t/s 并不比纯文本更难。
4090 Laptop（576 GB/s）短上下文 MTP n-max 3 的估计仍是 52–62 t/s（第二轮），
视觉不改这条外推。
C 才是视觉多出来的成本。它不表现在「生成 t/s」上，表现在 TTFT：
阶段 显存 时间（16GB 消费卡，量级）
mmproj 常驻 +0.63–0.93 GB 启动时付清
ViT encode 峰值缓冲 再加数百 MB～约 1GB 瞬时 GPU：约 0.5–3 s / 图
CPU（--no-mmproj-offload）：10–40 s
图像 token 写入 KV 约 18–36 MiB @ Q4 随 LLM prefill
图像 token LLM prefill 1024–2048 token 5060 Ti 短 prefill 约 0.5–2 s
4090 Laptop 算力更高，应更快
之后的 decode 与同等填充的纯文本相同 MTP 从这里开始加速
公开参照：
Agnify 托管硬件：单图并发 1 的 TTFT 约 0.16 s（那不是 16GB 消费卡）
llama.cpp issue #23422 对照：GPU encode 约 2.1 s / 图（Qwen3.5-9B，更小的塔）
社区对 461M F16 塔的经验：消费卡 GPU 零点几秒到数秒；CPU 十几到四十秒
所以：
「带视觉 44 t/s」若指生成阶段：短上下文下和纯文本一样可信，不是更可能，也不是因为视觉变快。
「带视觉 44 t/s」若指端到端、含看图：更不可能。encode 那几秒不进 t/s 分子，
有人会把「加载了 mmproj 的纯文本测速」当成视觉成绩。
「Q4+视觉+128K+MTP3=44 t/s」作为一条配置：比前两轮更不可能，因为 0.9GB mmproj
把本来就装不下的 128K 再往外推了约 50K token 的空间。
视觉不会让 decode 变快。MTP 的 1.7–2.3× 加速发生在图像处理完之后的文本生成。
4090 Laptop 相对 5060 Ti：视觉 encode（算力瓶颈）优势比 decode（带宽瓶颈）更大，
所以「看图等第一字」笔记本可能明显快，但生成 t/s 仍按 576/448 ≈ 1.29 外推。
六、问题 3：--mmproj 与 --spec-type draft-mtp 能否共存？MTP 还能加速吗？
--------------------------------------------------------------------
能共存。MTP 在看图之后的文本生成阶段仍加速。图像 encode / embedding 批次不走草稿。
时间线（必须把 PR 号说对，前两轮有一处过时）：
PR #22673（2026-05-16 合入）
llama.cpp 正式 MTP。作者原文：
「MTP is compatible with Vision input and Tensor/Pipeline Parallelism」
--no-mmproj 被写成省显存的可选项，不是开 MTP 的前提。
PR #23286（2026-05-18 提出，当天关闭，未合入）
本意是给 MTP+mmproj 加安全门：图像 embedding 批次 skip draft，
只在 SLOT_STATE_GENERATING 时允许草稿。
作者自己在当时的 main 上复现不了崩溃（单图、图后文本、双图、长 prompt+图都过了），
于是关 PR。第一轮写「PR #23286 之后主线可以共存」不准确——
共存的法律依据是 #22673，#23286 只是一份没合进去的加固补丁。
Unsloth Studio PR #5560（2026-05-18 合入）
去掉「视觉模型就别开 draft-mtp」的错误门闩。
B200、Qwen3.6-35B-A3B + mmproj-F16：无 MTP 179.7 → 有 MTP 253.8 t/s（1.41×，接受率 0.57）。
日志同时出现：
creating MTP draft context
loaded multimodal model '...mmproj-F16.gguf'
adding speculative implementation 'draft-mtp'
行为矩阵（#23286 描述的、与 #22673 实际运行一致）：
MTP process/sync 草稿
纯文本 prefill 安全批次 否
图像 embedding 批次 跳过 否
多模态文本 prefill 安全批次 否
助手生成阶段 安全批次 允许
含义：
- 可以同时写 --mmproj xxx.gguf --spec-type draft-mtp。主线不会因为两个 flag 在一起而拒绝启动。
- 看图那一下（ViT + 把 embedding 写进 LLM）享受不到 MTP。
- 从图后第一个生成 token 起，MTP 按接受率 0.5–0.85 加速，和纯文本同一套数字。
- llama-mtmd-cli 不暴露 --spec-type；要视觉+MTP 用 llama-server，不要用 mtmd-cli 测速。
- 老构建（#22673 之前）或某些 fork 仍会在视觉+MTP 上崩。16GB 实测请用 b10472+。
- 部分早期 Gemma 4 笔记写「加载 mmproj 后服务端会为求稳关掉所有草稿」。那是 2026-05 的旧行为，
不代表当前 Qwen3.8 主线。Qwen3.8 请以 #22673 + Unsloth #5560 的共存日志为准。
16GB 上的实际限制不是「flag 互斥」，是显存：开了 mmproj 再开 MTP n-max=3，Q4 权重没有地方放草稿 KV。
能共存 ≠ 能在 16GB 上把两个都开到声称的深度。
七、问题 4：有没有 16GB 卡带视觉的公开实测？视觉版 44 t/s 可信度？
----------------------------------------------------------
检索范围：GitHub qwen38-mtp 表及 sweeps、r/LocalLLaMA、r/LocalLLM、Hugging Face 讨论、
Unsloth / bartowski / ggml-org 模型卡、The Autodidacts、Hardware Corner、中文社区。
时间截至 2026-08-27。
没有找到：
- RTX 4090 Laptop 16GB + Qwen3.8-27B + mmproj 的带量化档 / 上下文 / t/s 收据
- RTX 5060 Ti 16GB + Q4 + mmproj + 128K + MTP 的收据
- 任何单卡 16GB 上「Q4 + 视觉 + 128K + 44 t/s」的收据
找到的、带视觉、且是 16GB 级的：
来源 硬件 配置 速度
The Autodidacts RTX 3080 16GB UD-IQ3_XXS + mmproj-BF16 + MTP n-max 2
（Ampere，慢于 5060 Ti） + ngram + q4 KV + 32K 20–30 t/s
r/LocalLLaMA 评论 RX 6800 16GB Vulkan bartowski IQ4_XS + MTP + mmproj
+ 64K q5/q5 KV 创作 25–30，
代码 35–40 t/s
第一轮引用的 Reddit 顶 未写清卡型、16GB UD-IQ4_XS + MTP-1 + F16 mmproj + 64K
占用 15,680 MiB 短上下文 45.4 t/s
r/LocalLLM 16GB 指南 16GB + 统一内存 UD-Q4_K_M + mmproj-F16 + --no-mmproj-offload
+ 140K + MTP n-max 2
+ CUDA Unified Memory + 多层 FFN 放 CPU 自称 ~20 t/s
不是全卡驻留，
不能当 44 t/s 证据
smtek Ollama 标签 按 VRAM 分档 16GB 标签（Q2_K_XL-16gb、Q3_K_M）
明确关掉视觉或关掉 MTP 官方包装自己
都不在 16GB 上
同时开 Q4+视觉+长窗
对照：qwen38-mtp 扫参表里 5060 Ti 的 44–50 t/s 全部是无 mmproj、32K、定制 Q4、MTP n-max 2~3。
PCGH 的 47.6 t/s 同样是 IQ4_XS、32K、无视觉、MTP-2。
可信度：
声称「Q4+视觉+128K+MTP3=44 t/s」 作为同时成立的配置 不可信
声称「加载了 mmproj，短上下文 MTP 到 44 t/s」
在 150W 档 4090 Laptop 上 可信（和纯文本短上下文同一档）
在 5060 Ti 上 勉强可信（公开 47–50 是无视觉 32K）
声称「看图过程也是 44 t/s」 不可信（encode 不进这个数字）
声称「填满 128K 后带视觉仍 44 t/s」 不可信（先装不下，再掉速）
八、问题 5：如果对方真的「带视觉 + 128K + MTP 且 16GB」，可能是什么？
----------------------------------------------------------------
按可能性从高到低。没有一条能让「Q4 + 128K + MTP3 + 44 t/s」同时成立。
1. 权重其实是 IQ3_XXS / Q3，口称 Q4
UD-IQ3_XXS（10.9GB）+ mmproj-F16 + 128K Q4 KV + MTP n-max 2：纸面约 15GB，能起来。
Autodidacts 在 3080 16GB 上跑过这个组合（他们开的是 32K，不是 128K）。
质量是 3-bit。短上下文 MTP 到 40+ t/s 在 4090 Laptop 上说得通；填满 128K 后到不了 44。
2. -c 131072 只是开了窗口，实际只填了 8K–32K
llama.cpp 的 -c 会按窗口预分配 KV。Q4 KV 的 2.25 GiB 在启动时就要付。
所以「分配 128K、实际短对话、速度 44 t/s」仍然要求权重小到能同时放下 2.25 GiB 空 KV。
Q4 + mmproj 做不到。IQ3_XXS 做得到。对方如果展示的是「设置里写着 128K、测速 44」，
最干净的解释是：小量化 + 短填充 + MTP，窗口数字被当成了填充数字。
3. mmproj 在 CPU（--no-mmproj-offload）
省 0.63–0.93GB GPU。图像 encode 掉到 10–40 秒。
即便如此，IQ4_XS + 128K + MTP 仍约 16.6GB，还是 OOM。
只能再换 Q3，或把 128K 降到 64K–96K。
Unsloth Studio 现在的策略也是：装不下时先把 projector 丢 CPU，再丢 drafter，最后才卸语言模型层——
因为 projector 每张图跑一次，语言模型每 token 跑一次。
4. 统一内存 / --fit / 部分层 CPU
r/LocalLLM 那份 Q4_K_M + mmproj + 140K + MTP，靠 GGML_CUDA_ENABLE_UNIFIED_MEMORY
和十几层 FFN 放 CPU，换来 ~20 t/s。这是「看起来 16GB 跑起了 Q4+视觉+长窗」，
速度对不上 44。第二轮已经测过：IQ4_NL --fit 基线 16.8 t/s，再 MTP 把 4 层放 CPU 掉到 20.3，
是净亏损。
5. mmproj q8_0 + 更短 KV + MTP n-max 1
这是 16GB 上「真的带视觉、还想留一点 Q4 质量」的老实配方：
UD-IQ4_XS 或 quimmedes Q4-XYZ-v2 + mmproj-q8_0 + 8K–32K + MTP n-max 1
短上下文可以摸到 40–50 t/s。128K 不在菜单里。
6. 独立 MTP GGUF 又加载了一份
对方若用 ggml-org 的拆分文件，MTP Q4_0 再加 1.68GB，视觉版更先爆。
正确做法仍是：Unsloth 主 GGUF 已含 nextn，只加 --spec-type draft-mtp。
问对方要这五样，比继续猜有用：
- 主 GGUF 文件名和体积（是 UD-IQ4_XS 14.3GB，还是 UD-IQ3_XXS 10.9GB）
- mmproj 文件名（F16 / BF16 / q8_0）以及有没有 --no-mmproj-offload
- 完整启动命令（特别是 -c、-ctk、-spec-draft-n-max、-ngl / --fit）
- nvidia-smi 的 Memory-Usage，以及 llama.cpp 日志里的 kv size
- 44 t/s 是 llama-server timings 的 predicted_per_second，还是墙钟 / (生成 token)；
那次请求实际 prompt 多长、有没有图、thinking 开没开
九、16GB 上带视觉的可复现命令（能起来的，和不要这样开的）
----------------------------------------------------
前置与前两轮相同：llama.cpp b10472+，含 CUDA FA 对 q4 KV 的 prefill 修复；
4090 Laptop 编译 sm_89，5060 Ti 编译 sm_120；测速 -np 1。
----- 配方 V0：16GB 上「真的带视觉」的老实上限（Q3，32K–48K，MTP-2）-----
# 权重：Qwen3.8-27B-UD-Q3_K_XL.gguf（13.1GB）
# mmproj：同仓 mmproj-F16.gguf（0.93GB）；更紧就换 mmproj-q8_0（0.63GB）
# 预期：全卡驻留；短生成在 4090 Laptop 上约 40–55 t/s，5060 Ti 约 35–46 t/s
# 这不是 128K，也不是 Q4。
llama-server \
-m Qwen3.8-27B-UD-Q3_K_XL.gguf \
--mmproj mmproj-F16.gguf \
--image-min-tokens 1024 \
-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
----- 配方 V1：还想留 Q4 质量（必须短上下文，MTP 只能 1）-----
# 权重：Qwen3.8-27B-UD-IQ4_XS.gguf（14.3GB）
# mmproj 建议 q8_0。F16 会把 MTP 余量吃光。
# 预期：8K–32K 能起来；n-max 2 起对 IQ4_XS 很容易 OOM（前两轮：n-max 4 差 240 MiB，还没算 mmproj）
llama-server \
-m Qwen3.8-27B-UD-IQ4_XS.gguf \
--mmproj mmproj-q8_0.gguf \
--image-min-tokens 1024 \
-ngl 999 -fa on -np 1 \
--fit off \
-c 16384 \
-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
----- 配方 V2：硬要视觉 + 128K + MTP（那就不能叫 Q4）-----
# 权重：Qwen3.8-27B-UD-IQ3_XXS.gguf（10.9GB）
# Autodidacts 在 3080 16GB 上用过同款权重+mmproj+MTP，他们开的是 32K。
# 128K 纸面能进；填满后不要期待 44 t/s。
llama-server \
-m Qwen3.8-27B-UD-IQ3_XXS.gguf \
--mmproj mmproj-F16.gguf \
--image-min-tokens 1024 \
-ngl 999 -fa on -np 1 \
--fit off \
-c 131072 \
-ctk q4_0 -ctv q4_0 \
--spec-type draft-mtp \
--spec-draft-n-max 2 \
--jinja --reasoning-preserve \
--host 127.0.0.1 --port 8080
----- 配方 V3：不要这样开（这就是声称的配置，16GB 会 OOM）-----
# llama-server \
# -m Qwen3.8-27B-UD-IQ4_XS.gguf \
# --mmproj mmproj-F16.gguf \
# -c 131072 -ctk q4_0 -ctv q4_0 \
# --spec-type draft-mtp --spec-draft-n-max 3 \
# -ngl 999
# 合计 ≥ 18GB。
# 更糟：主文件已含 nextn，再 -md / -hfd 加载 ggml-org MTP Q4_0（+1.68GB）
# 视觉版比纯文本更先爆。
十、和前两轮的衔接（改了什么、没改什么）
------------------------------------
没改：
- KV 公式、Q4 KV 128K = 2.25 GiB、256K = 4.50 GiB
- 16GB 可用约 15.0–15.8 GiB
- 5060 Ti 无 MTP 26 t/s、MTP n-max 2~3 在 32K 约 50–54 t/s
- 4090 Laptop 带宽 576 GB/s，短上下文按 1.29× 外推；上下文上限不因换卡而变
改了 / 补了：
- 官方确实是原生 image-text-to-text；GGUF 必须另载 mmproj，F16 0.93GB / q8_0 0.63GB
- 带视觉后 Q4+128K+MTP 从「约 18GB+」变成「约 18.3–19.1GB」，更装不下
- 带视觉后 Q4 最大可行上下文从「32K–96K」收到「约 32K，开 MTP 更短」
- MTP 与 mmproj 共存：依据 PR #22673（已合入），不是未合入的 #23286
- 视觉 decode 44 t/s 在短上下文下并不额外离谱；作为「128K 填满」数字仍然离谱，而且更离谱
- 16GB + 视觉的公开收据全是 Q3/IQ3 或短窗，没有 Q4+128K+44 t/s
如果只留一句给对质：官方带视觉是真的；你这张 16GB 卡要把视觉、Q4、128K、MTP3 和 44 t/s 叠在一起，物理上差大约 3GB，公开实测也没有人做到。
)