封面

机箱、主板、CPU、电源加起来不到 1000 块。两张 RTX 5060 Ti，一个周末。跑的是刚开源半个月的 Qwen3.8-27B。22.7 → 70 tok/s，3.08 倍，每一步都是实测。

先摊结果，免得你读到最后才发现货不对板。

22.7 tok/s → 70 tok/s，3.08 倍。

跑的不是 7B 小模型，是 Qwen3.8-27B——今年 8 月阿里千问刚开源的那颗 27B 视觉大模型。

机器是这样：

  • GPU：2× RTX 5060 Ti 16GB
  • 主板：MSI X470 GAMING PLUS
  • CPU：AMD R5 3600X
  • 内存：16 GB DDR4（另挂 16 GB swap）
  • 硬盘：512 GB SSD
  • 系统：Ubuntu 26.04

除了显卡、固态和内存，剩下那堆——机箱、主板、CPU、电源——加一起不到 1000 块。

机器照片

配置发到群里，第一个人问”这也能跑？“，第二个人问”X470 只有 PCIe 3.0，你不嫌慢？”。

慢不慢，数字说了算。

下面是我这两天走过的路，以及我认为比 MTP、比量化都更值得先想清楚的那个判断。

一、这条路是怎么一步步爬上去的

四个台阶，每一级都对应一个具体决策：

22.7 → 31.5 → 44 → 70

  • 22.7：Q4_K_M 量化，128K 上下文，没开投机解码。基线。
  • 31.5：开了 MTP=2，+45%。
  • 44：换成 IQ4_XS 量化，+40%。
  • 70：双卡拆分从 layer 模式换成 tensor 模式，+59%。

你没看错，最后那一步——只加了一个参数，速度提升 59%，双卡利用率从 50% 直接跳到 90%。

这是全文最值钱的一段，我放在第六章细讲。

四个台阶

二、主角登场：Qwen3.8-27B 是什么来头

先交代清楚，我折腾的到底是个什么模型。

Qwen3.8-27B，阿里千问今年 8 月 14 日开源的视觉大模型，Apache 2.0 协议，个人和企业都能免费商用。

海外开发者给它起了个外号，叫”装在本地的 Opus”。发布三天 Hugging Face 下载量破 300 万，上线首日登上 Hacker News 榜首——这是它现在有多火的直接证据。

它的分量，一句话就能讲明白：

用一张消费级显卡扛得住的体量，跑出了接近全球顶级闭源模型的水平。

以前这种级别的能力，只有云端 API 给得起——按 token 付钱，数据还得先传到别人的服务器上。现在它开源了，你把它下载进自己的机器，断网也能跑，数据一步不出门。

有多接近？看两场最能说明问题的考试：

  • SWE-bench Pro 61.7 分——考的是”给真实开源项目修 bug”，这个分数超过了 Claude Opus 4.6 Max 的 53.4。
  • LiveCodeBench v6 90.3 分——考的是竞赛级编程题，同样压在闭源旗舰之上。

除了会写代码，它还有两个本事：

  • 看得懂。图片、视频、PDF 版式、论文图表，它是真能读懂并动手干活，不是”看图说话”。
  • 记得住。一次能处理 26 万 token，差不多是一本厚书的量。

Qwen3.8-27B 插图

顺带给个参照系，方便你判断 70 tok/s 是什么水平。

AMD 在它发布当天就做了适配，官方实测数据是：单张 Radeon AI PRO R9700（32GB 专业卡），开启投机解码后约 51.8 tok/s。

我这边是两张 RTX 5060 Ti（合计 32GB）、Linux + CUDA、同样开了投机解码，70 tok/s。

平台不同、后端不同，不能简单划等号。但量级摆在那儿：两张消费级卡，跑到了单张 32GB 专业卡官方成绩之上。

那这台机器跑它为什么这么费劲？因为它天生带视觉编码器（显存要多分一块）、长上下文又吃 KV cache——这两点，就是我后面所有优化的出发点。

下面开始讲机器。

三、先说硬件：低预算，但每一块都是挑过的

最容易挨骂的是那块 X470。两代前的老主板，没有 PCIe 4.0，更别提 5.0。

但这是我专门挑的。

理由只有一条：它的两条 PCIe x16 插槽都直连 CPU。

大部分消费级主板不是这样。第二条 x16 插槽往往走南桥——你可以理解成，两张卡之间说话得先过一个中转站，延迟全堆在那儿。而 X470 上，两条 PCIe 3.0×8 各自对应一张卡，显卡之间直接通过 CPU 通信，不绕路。

那 PCIe 3.0×8 的带宽，够不够跑 27B？

够。

因为真正的瓶颈从来不是物理带宽，而是”两张卡到底有没有在同时干活”。

先记住这句话。它是后面那 59% 提速的题眼，第六章会回来收。

另一处妥协是内存：只有 16 GB。理论算下来，32 GB 显存装 14 GB 权重绰绰有余，实际跑起来却反复 OOM（内存溢出）。这个坑我在最后会讲清楚。

四、走错的那条路：vLLM 跑得动，但跑不动了

最开始我选的是 vLLM，理由很正当——想试试英伟达官方的 NVFP4 量化在 50 系卡上的硬件加速。

vLLM OOM 截图

模型一下就是 22 GB，加上视觉编码器和 KV cache，32 GB 显存很快见底：

  • 100K 上下文就快顶到极限
  • 想开 MTP=1，直接 OOM
  • 关掉桌面环境，只腾出 850 MiB 显存
  • 关了 GUI 之后，MTP=2 才勉强跑通，速度 30 → 60

看起来问题解决了。但我心里清楚，这已经是硬挤出来的状态。

真正的转折点是我想把视觉能力加回来的时候——显存不够了。想加长上下文？不够。想开多并发？更不够。

vLLM 在这个硬件上没有扩展空间了。

“能跑起来”和”能用起来”是两回事。这句话值一台显卡的钱。

所以我换成了 llama.cpp。

五、两次提速：MTP 的甜点位，和那个差点骗过我的 2 tok/s

换成 llama.cpp 之后，先上了 Qwen3.8-27B-UD-Q4_K_M.gguf，15.33 GB，比 NVFP4 省了好几个 G。

第一次提速：MTP=2，+45%

MTP（Multi-Token Prediction，多 token 投机解码）的原理不复杂：让一个轻量级的 draft 模型先猜几个 token，主模型一次性验证。猜对了就赚了时间，猜错了退回重来。

  • 无 MTP：22.7 tok/s（基线）
  • MTP=2：31.5 tok/s（+45%）
  • MTP=3：31.4 tok/s，接受率掉到 53.8%，反而倒退

MTP=3 不是失败，是实测之后下的判断：这个模型的甜点位就在 2，别在 3 上浪费时间。

从那一刻起，后面所有实验我都锁死 MTP=2，不再回头。

MTP 测试结果

第二次提速：那个差点骗过我的 2 tok/s

这一段是整个周末最有意思的部分。

我换上了 IQ4_XS 量化——之前我在 5060 Ti 上部署过 Qwen3.6 35B A3B + IQ4，证明 IQ4 在这块卡上能吃到 GPU 加速，所以我对它有底。

结果第一次跑出来，AI 跟我说：

“2 tok/s。建议换回 Q4_K_M。”

我看了一眼，直接质疑：不可能。

我在这块卡上跑过 IQ4，知道它是能 GPU 加速的。2 tok/s 这种数字，只像是”根本没用上 GPU”。

我让 AI 继续往下查。最后定位到问题：SNAP_COMPONENTS 为空，导致 snap 包没有启用 CUDA 后端——模型实际是跑在 CPU 上的。

修一行环境变量：

SNAP_COMPONENTS= cuda-compat-12-4

再跑：

  • 比 Q4_K_M 快 30%（PP 1124 tok/s，TG 44 tok/s）
  • 还省了 1.9 GB 显存

从 2 tok/s 到 44 tok/s，中间只隔着一行环境变量。

这次经历让我确认一件事：AI 给的是高概率结论，但你的领域经验是推翻它的关键信号。 如果你手上有过一手实测，就别急着接受它的”建议回退”。

六、真正的大招：一个参数，双卡从 50% 到 90%

44 tok/s 跑顺了，但我盯着显卡占用率看，总觉得不对——两张卡都只有 50% 左右。

问题出在 llama.cpp 默认的 layer 拆分模式。

Layer 模式：两个人轮流搬砖

llama.cpp 默认按”层”切分模型：第 1 层放 GPU0，第 2 层放 GPU1，第 3 层又回到 GPU0……

听起来很公平。但推理的时候，模型是一层一层往前跑的——跑第 1 层时 GPU1 在等，跑第 2 层时 GPU0 在等。

更糟的是，连续几层刚好落在同一张卡上是常有的事。一旦发生，另一张卡就彻底闲着。

所以 layer 模式下，双卡利用率稳定在 50% 上下。两张卡永远没法火力全开。

Tensor 模式：每层都劈成两半

换成这个参数：

--split-mode tensor

规则变了：每一层内部的权重张量都被切到两张卡上——前半在 GPU0，后半在 GPU1。

这意味着模型跑到任何一层，这一层的前向计算都必然需要两张卡各算一半，再把结果合起来。没有谁等谁，每一层都是双人同时出力。

对比一下：

模式显卡利用率TG 速度
IQ4_XS + layer 模式~50%44 tok/s
IQ4_XS + tensor 模式~90%70 tok/s

+59%，比 MTP 那 45% 还狠。

这就是 layer 和 tensor 的本质区别——不只是”切法不同”，而是决定了你的双卡利用率到底停在 50% 还是 90%。

这件事比 MTP、比量化格式，都更值得在选框架之初就想清楚。

七、顺手捡的一刀：KV cache 减半

tensor 模式解锁之后还有空间，我去翻了别人的参数清单，发现不少人用这一组：

-ctk q8_0 -ctv q8_0

作用是把 KV cache 从 FP16 量化到 8-bit。我之前没用过，第一反应也是”会不会掉精度”。

查了一圈，结论是：Q8 比 FP16 少一半 bit，理论精度损失 <5%，而在 95% 以上的场景里几乎感知不到。

再想一层就通了：LLM 的 KV cache 本来就容忍少量噪声。多 5% 噪声换 50% 显存，这笔账太划算。

直接采纳。

结果：每 token 的 KV 从 144 KB 降到 72 KB，砍半。 省下来的空间，正好喂给长上下文和 tensor 切分。

KV cache 减半

八、完整配置，拿去就能跑

环境前置三件套：

  • llama.cpp 最新版（支持 --split-mode tensor）
  • CUDA Toolkit 12.4（snap 包需要）
  • Qwen3.8-27B 的 GGUF 量化模型（建议 IQ4_XS）

核心启动命令（白话注解版）：

#!/bin/bash
# 终极配置：IQ4_XS + 双卡 tensor-split + q8_0 KV + MTP=2
# 验证：200K 上下文，KV 复用时 TG ≈ 70 tok/s

export LLAMA_CPP_BACKEND=cuda   # 必须，否则 snap 跑 CPU

exec /snap/bin/llama-cpp server \
  --model /home/springcore/models/Qwen3.8-27B-UD-IQ4_XS.gguf \
  --mmproj /home/springcore/models/mmproj-BF16.gguf \
  --host 0.0.0.0 --port 8000 \
  --gpu-layers 99 \
  -c 200000 \
  --parallel 1 \
  --tensor-split 1,1 \
  -ctk q8_0 -ctv q8_0 \
  --kv-unified \
  -b 1024 -ub 1024 \
  --split-mode tensor \
  --spec-type draft-mtp --spec-draft-n-max 2 \
  --flash-attn on \
  --reasoning-preserve \
  --chat-template-kwargs '{"reasoning_effort": "medium"}' \
  > /tmp/llama_snap.log 2>&1

环境前置命令（首次部署时跑一次）：

echo 1 > /proc/sys/vm/overcommit_memory
sudo systemctl mask gdm3
snap install llama-cpp --channel=latest/cuda

几个关键参数的白话解释：

  • --split-mode tensor：70 tok/s 的核心。双卡按张量切，每层都一起算。
  • --spec-type draft-mtp --spec-draft-n-max 2：MTP=2 投机解码，这个模型的唯一甜点位。
  • -ctk q8_0 -ctv q8_0：KV cache 量化到 8-bit，显存减半，精度几乎无感。
  • --tensor-split 1,1：双卡各承担 50% 权重。
  • --kv-unified：KV 用统一连续池，减少碎片。
  • -b 1024 -ub 1024：大 batch，提升 prompt 处理吞吐。
  • --mmproj：视觉投影器（multimodal projector），挂上才能用 Qwen3.8-27B 的视觉能力。
  • --flash-attn on：开启 Flash Attention，长上下文下显存与速度都受益。
  • --reasoning-preserve + --chat-template-kwargs '{"reasoning_effort": "medium"}'：保留模型推理内容，并把思考强度钉在中等档。
  • export LLAMA_CPP_BACKEND=cuda：snap 包安装后的关键开关。没这一行，模型会回退到 CPU —— 前面第五章那个”2 tok/s”的坑就来自这里。

实测显存占用：GPU0 13.73 GB，GPU1 12.58 GB，还剩约 5.7 GB 余量。不开定时重启，连跑数天没问题。

九、五条能复用的判断

按对我帮助的大小排序：

1. 选主板先问”双卡是不是都直连 CPU”，别盯着 PCIe 几代。 PCIe 3.0×8 跑 27B 完全够用。一张直连、另一张走南桥，才是最亏的布线。

2. 选框架之前，先想清楚 layer 还是 tensor。 layer 模式利用率封顶 50%，tensor 能到 90%。这 59% 的差距，比 MTP、比换量化格式都大。

3. MTP 要实测找甜点位，别迷信”越大越好”。 Qwen3.8-27B 的甜点位是 2。MTP=3 接受率掉到 53.8%，速度不升反降。

4. KV cache 量化是性价比最高的一刀。 精度损失 <5%，95% 场景无感，显存直接减半。tensor 模式 + 长上下文场景下尤其值。

5. “突然变慢”先查硬件加速有没有真的启用。 2 tok/s 不是模型慢，是 CUDA 后端没加载。一行环境变量，比改十个 flag 有效得多。

另外一条不那么”攻略”但很实在的：

系统内存是隐藏的坑。 理论算够，实际跑起来 KV cache 元数据、累积的 pinned buffer、CudaGraph 状态都在吃内存。下次装机我直接上 32 GB。

十、3 倍不是终点

局限我认。

16 GB 内存是这台机器当下的天花板，2×16 GB 显存也就摸到 200K 上下文的极限附近，再往上必须换硬件。

但方法论会留下来：

主板选双卡直连 → 选框架时先定 layer 还是 tensor → MTP 实测找甜点位 → KV cache 量化 → 试探量化格式的硬件适配

这不是一套参数，是一串判断。下次硬件换代，步骤还是这些步骤。

完整方法论

最后，聊点正事

我这两年一直在做一件事：帮企业和个人把 AI 真正跑起来——不是跑个 demo 截图发朋友圈，是跑在自己的机器上、自己的数据上，跑得够快、够稳、够便宜。

如果你正卡在这些地方：

  • 想做本地或私有化部署，但不知道硬件怎么选、模型怎么选、框架怎么选
  • 显卡买了，跑起来发现利用率只有一半，速度上不去
  • 想把大模型接进自己的业务流程，搭 AI 工作流或自动化系统

欢迎来找我聊。我是搞机的春天，专做 AI 工作流与自动化系统搭建。

也欢迎在评论区说说：你现在的本地部署方案跑到多少 tok/s？卡在哪一步了？看到都会回。