标签： AI

这篇记录 Qwen3.6 27B 大模型全本地跑通的完整过程。目标一句话：27B 参数模型，全本地，长上下文，暴露 OpenAI 兼容 API，任何前端（包括 DeepSeek Harness 本身）直接对接。

最终结果：

• Qwen3.6-27B UD-Q5_K_XL（18.95 GB）+ 138K 上下文 + KV 缓存量化 → 32GB 显存刚好装下
• 同一条流水线后来延伸到 Qwen3.8-27B：Q4_K_XL + MTP 投机解码 + 256K 上下文，实测占用 26077 / 32768 MiB

下面就是完整搭建流程。所有参数都来自实际在跑的脚本，不是理论最优值。

一、硬件与驱动

项	实际值
GPU	Tesla V100-PCIE-32GB（TCC 模式）
驱动	573.96（Data Center Tesla 桌面版）
CUDA	12.8（cuda_12.8.0_571.96_windows）
系统	Windows 10/11

两个坑：

1. V100 不能用 GeForce 消费级驱动。 要用数据中心分支，安装包文件名里带 data-center-tesla（我本地留了份：573.96-data-center-tesla-desktop-win10-win11-64bit-dch-international.exe）。

2. TCC 模式没有桌面显示输出。 V100 是纯计算卡，看屏幕靠核显，状态全靠 nvidia-smi。写这篇时的实况（节选）：

| 0  Tesla V100-PCIE-32GB   TCC    75C    51W / 250W
| 26077MiB / 32768MiB
| 进程: llama-server.exe  26066MiB

二、编译 CUDA 版 llama.cpp

我保留两套 llama.cpp：

• F:\AI\llama.cpp-CUDA\ — CUDA 后端（给 V100）
• F:\AI\llama.cpp\ — Vulkan 后端（更早的 AMD RX 590 8G 在用）

CUDA 版用 VS2022（MSVC 19.44）+ CUDA 12.8 工具链编译，当前在产 build：

version: 0.1.0-dev (build 10415, commit 1d2869c6e)
built with MSVC 19.44.35228.0 for x64

CMake 关键参数：

cmake -B build -G "Visual Studio 17 2022" -A x64 ^
  -DGGML_CUDA=ON ^
  -DCMAKE_BUILD_TYPE=Release
cmake --build build --config Release -j

所有启动脚本都会先检查 Release\llama-server.exe 是否存在，缺了就直接提示先编译，避免"启动失败但不知道为什么"。

三、模型选择：27B 为什么"装得下"

手头的模型文件（实测大小）：

模型	大小	备注
Qwen3.6-27B-Q4_K_M.gguf	15.93 GB	常规 K 量化
Qwen3.6-27B-UD-Q5_K_XL.gguf	18.95 GB	Unsloth 动态量化（本文主角）
Qwen3.8-27B-UD-Q4_K_XL.gguf	16.69 GB	当前生产主模型
Qwen3.8-27B-Q5_K_M.gguf	18.47 GB
Qwen3.8-27B-UD-Q6_K_XL.gguf	23.56 GB	高质量档（偏重）
mtp-Qwen3.8-27B-Q4_0.gguf	1.28 GB	MTP 投机解码草稿

3.6 为什么选 UD-Q5_K_XL：UD（Unsloth Dynamic）量化用 imatrix 校准数据动态分配 bit，关键张量多给、不重要的少给，同等名义 5 bit 下质量比固定 Q5_K_M 好。imatrix 校准文件（imatrix_unsloth.gguf）就放在模型目录里。

但 27B 长上下文能上 32G 的关键不是量化，是架构。 我写了个小脚本解析 GGUF v3 元数据（解析器在 novel-project/tools/gguf-meta.py，顺带解决了 v3 格式 KV 区紧跟文件头、字符串长度用 u64 编码的坑），结果有点意外：

general.architecture = qwen35
qwen35.block_count = 65
qwen35.full_attention_interval = 4      # 每 4 层才 1 层全注意力
qwen35.attention.head_count_kv = 4      # GQA，4 个 KV 头
qwen35.attention.key_length = 256       # head 维度
qwen35.context_length = 262144          # 原生 256K
qwen35.nextn_predict_layers = 1         # 内置 MTP 层
qwen35.ssm.state_size = 128             # 线性注意力/SSM 状态

也就是说 Qwen3.x-27B 系列是混合架构：65 个 block 里只有 1/4 是全注意力（约 17 层），其余是线性注意力/SSM，状态大小固定、不随上下文增长。KV 缓存只给那 17 层全注意力层分配——这是 256K 上下文能塞进 32GB 的根本原因。

四、显存预算（全部真实数字）

KV 缓存容量公式（q4_0 量化约 4.5 bit/元素，0.5625 B/元素）：

KV = 2(K+V) × ctx × 4(KV头) × 256(head维) × 0.5625B × 17(全注意力层)

256K 代入：单层 KV ≈ 288 MiB，17 层合计 ≈ 4.8 GB；若不做 KV 量化（fp16），同样 256K 要 17 GB。

项	Q3.8 Q4_K_XL @256K（实测）	Q3.6 Q5_K_XL @138K（估算）
模型权重	16.69 GB	18.95 GB
KV 缓存（q4_0）	≈4.8 GB	≈2.6 GB
SSM 状态 + 激活 + 计算缓冲	≈4.0 GB（实测余量）	≈4.0 GB（参照）
合计	≈25.5 GB → 实测 26077 MiB	≈25.6 GB，还能开 –parallel 2

实测与估算吻合，这套预算方法是可信的。两个结论：

1. --flash-attn on + --cache-type-k q4_0 --cache-type-v q4_0 是长上下文的两个必选项，缺一个 256K 都悬。
2. Q6 + 256K 不成立：光权重就 23.56 GB，我的 Q6 脚本 batch 只能压到 256。要质量降上下文，要上下文降量化，二选一。

五、启动脚本（真实演进过程）

早期是 Vulkan 时代（RX 590 8G），部分层卸载到 GPU：

:: 历史配置：RX 590 8G Vulkan 版
llama-server -m Qwen3.6-27B-Q4_0.gguf -ngl 24 --n-cpu-moe 999 ^
  -c 4096 -b 1024 -ub 512 -t 6 --device Vulkan0 --cache-ram 2048 --mlock

-ngl 24 只把 24 层推 GPU，其余吃 CPU；--n-cpu-moe 999 是 35B-A3B MoE 模型时代抄过来的，对稠密 27B 实际不生效——无害但误导，后来删掉了。

V100 到位后配置重写：99 层全上 GPU，上下文从 4K 拉到 138K：

:: start_Qwen3.6-27b-Q5-MTP_v01.bat（核心部分）
set MODEL_PATH=F:\AI\models\Qwen3.6-27B-UD-Q5_K_XL.gguf
set CTX_LEN=141072

Release\llama-server.exe -m "%MODEL_PATH%" ^
  -ngl 99 -c 141072 -b 512 -t 8 ^
  --host 0.0.0.0 --port 8080 ^
  --flash-attn on --cache-type-k q4_0 --cache-type-v q4_0 ^
  --parallel 2 --mlock --metrics

参数解释：

• -ngl 99：全部层上 GPU（32G 够放，不用抠）
• -c 141072：算过能装下的上下文长度（138K）。Q5 权重比 Q4 重约 2GB，256K 装不下
• --parallel 2：2 个并发请求槽位（KV 缓存翻倍，预算表里已留了余量）
• --mlock：锁定内存防换页
• -t 8：CPU 线程数，服务残留的 CPU 部分

注意 141072 不是整数规格——是"算到刚好装下"的结果，不是官方档位。

当前生产版已升级到 Qwen3.8-27B，并加了 MTP 投机解码：

:: 当前生产配置
Release\llama-server.exe -m "D:\Models\Qwen3.8-27B\Qwen3.8-27B-UD-Q4_K_XL.gguf" ^
  --model-draft "D:\Models\Qwen3.8-27B\mtp-Qwen3.8-27B-Q4_0.gguf" ^
  -ngl 99 -np 1 -c 262144 -b 512 -t 8 ^
  --host 0.0.0.0 --port 8080 ^
  --flash-attn on --cache-type-k q4_0 --cache-type-v q4_0 ^
  --spec-type draft-mtp --spec-draft-n-max 2

元数据里 nextn_predict_layers = 1 说明模型自带 1 层 MTP（Multi-Token Prediction），3.8 配套了独立的 1.28GB Q4_0 草稿文件。--spec-draft-n-max 2 让草稿层一次多预测 2 个 token、主模型一次性验证，中文文本接受率不低，白捡的速度。注意 Q3.6 配置里没有这一项（3.6 没有独立 MTP 草稿文件），别照抄。

六、前端接入

llama-server 原生 OpenAI 兼容：

• API：http://127.0.0.1:8080/v1（chat/completions、models 都通）
• Web：http://127.0.0.1:8080 自带 playground

对 DeepSeek Harness（运行本文的工具），把模型服务指向 8080 即可：

:: D:\Dev\start-harness.bat（简化）
dsh web --port 3080

然后打开 http://127.0.0.1:3080。现在正在服务这段对话的模型，就是本文这台 V100 上跑的——某种意义上是自我验证。

服务监听 0.0.0.0，内网其他机器也能用；如果机器走 VPN 或暴露公网，记得加认证和限流（llama-server 没有内置鉴权，建议套一层反代）。

七、踩坑清单

1. V100 要 Data Center 驱动，GeForce 驱动装不上/不识别。
2. Q6 + 256K 直接别想，光权重 23.56GB。
3. KV 缓存量化是长上下文的必选项：q4_0 把 256K 的 KV 从 17GB 压到约 4.8GB。
4. --n-cpu-moe 对稠密模型无效，MoE 时代的残留，删掉免得误导。
5. MTP 要配套草稿文件：3.6 没有 mtp 文件，--spec-type draft-mtp 加了也白加。
6. 别重复起服务：8080 端口被 llama-server 占着，脚本里有存在性检查，手动启动前先 nvidia-smi 看一眼。

八、速查表

场景	推荐组合
质量优先	Q3.8 UD-Q6_K_XL + ctx 32K~64K
均衡（3.6 主选）	Q3.6 UD-Q5_K_XL + ctx 138K + –parallel 2
长上下文优先	Q3.8 UD-Q4_K_XL + ctx 256K + MTP 投机解码
小模型快速验证	Qwen3.5-9B-Q4_K_M（5.29 GB，8G 显存即可）

脚本、模型都在这台机器上，GGUF 元数据解析器在 novel-project/tools/gguf-meta.py。下一篇想写 imatrix 校准与 UD 量化的制作流程。