双卡攒机跑大模型：Qwen3.6-27B-MTP 本地部署全记录

双卡攒机跑大模型Qwen3.6-27B-MTP 本地部署全记录作者一个本地跑大模型的普通开发者设备RTX 3080 20GB RTX 3050 8GB 双卡双路 Xeon时间2026 年 7 月0. 缘起前三篇文章记录了 Qwen3.6-27B 的三轮代码能力评测从基础篇到进阶篇再到高级测评篇。但有个问题一直没展开讲——这个模型到底是怎么跑起来的llama.cpp 部署四个字听起来简单实际折腾下来踩了不少坑。从编译 llama.cpp 到双卡拆分加载从 MTP 架构的理解到参数的反复调优这篇文章把整个过程完整记录下来希望能帮到想本地跑大模型的朋友。1. 机器环境1.1 硬件配置这台机器是几年前的老工作站不是主流的消费级配置但跑 27B 模型完全够用组件配置CPU双路 Intel Xeon E5-2620 v3 2.40GHz12 核 24 线程 × 2 24 核 48 线程内存60GB DDR4GPU 0NVIDIA GeForce RTX 3050 8GB亮机卡GPU 1NVIDIA GeForce RTX 3080 20GB主力计算卡存储NVMe SSD 1TB系统Ubuntu 26.04 LTS内核7.0.0-27-generic这是一台戴尔 Precision Tower 7910 工作站双路 Xeon 的机器。显卡是后来自己加的——3080 是主力3050 是亮机卡。为什么选这个配置27B 模型 Q4 量化后大约 16GB单张 20GB 的 3080 刚好能装下模型权重但留给 KV Cache 的空间就非常紧张了。加上 3050 之后可以把部分层 offload 到 3050 上让 3080 留出更多空间给 KV Cache推理速度会有明显提升。1.2 软件环境组件版本CUDA13.2NVIDIA 驱动595.71.05llama.cppb98512026-06-30最新 master编译后端CUDA CPUGGML_CUDAONPython3.x评测脚本用2. 编译 llama.cpp2.1 克隆与编译gitclone https://github.com/ggml-org/llama.cpp.gitcdllama.cppgitcheckout b9851mkdirbuildcdbuild cmake..-DGGML_CUDAON-DBUILD_SHARED_LIBSONmake-j$(nproc)llama-server几个关键参数-DGGML_CUDAON启用 CUDA 后端这是 GPU 加速的核心。不启用这个就只能用 CPU 推理速度会慢几个数量级。-DBUILD_SHARED_LIBSON编译动态链接库。llama.cpp 的 backend 插件架构依赖这个——CUDA、CPU 等后端以.so文件加载。编译完成后build/bin/目录下会有一堆文件和库llama-server libggml-base.so ← 基础库 libggml-cpu.so ← CPU 后端 libggml-cuda.so ← CUDA 后端 libggml.so ← 主库2.2 编译常见问题问题 1CUDA 版本不匹配llama.cpp 需要 CUDA toolkit 来编译。如果你的系统只有 NVIDIA 驱动但没有安装 CUDA toolkitcmake 会找不到 nvcc。# 检查 CUDA 是否可用nvcc--version# 如果没有安装 CUDA toolkit# Ubuntu 上可以直接用 aptsudoaptinstallnvidia-cuda-toolkit问题 2显存不足导致编译失败make -j$(nproc)会并行编译双路 Xeon 有 48 个线程同时编译会占用大量内存和显存。如果遇到 OOM# 减少并行度make-j16llama-server3. 下载模型3.1 MTP 是什么Qwen3.6-27B 用的是MTPMulti-Token Prediction架构这是 Qwen3 系列的一个特性。简单理解就是模型在预测下一个 token 的同时还会顺便预测后面几个 token。推理时如果预测对了就能跳过中间步骤加快生成速度预测错了就回退到正常路径。MTP 的模型文件和传统 Transformer 模型结构不同需要 llama.cpp 较新的版本b9800才能正确加载。3.2 获取模型文件模型文件Qwen3.6-27B-Q4_K_M-MTP.gguf大约 16GB。# 放到 models 目录mkdir-p~/models# 下载 Qwen3.6-27B-Q4_K_M-MTP.gguf从 HuggingFace 获取关于量化精度的选择Q4_K_M4-bit 量化K 代表 K-quantsllama.cpp 的改进量化方案M 代表中等精度混合。在精度和显存之间取得了较好的平衡。27B 模型 Q4_K_M 大约 16GB。Q8_08-bit 量化精度更高但 27B 模型大约 27GB20GB 显存的卡装不下。Q5_K_M5-bit介于 Q4 和 Q8 之间大约 19GB。对于 20GB 显存的单卡来说Q4_K_M 是能跑 27B 模型的较优选择。后续评测文章中提到过对比不同量化精度的计划这确实值得做。4. Chat TemplateQwen3.6 系列使用特定的 chat template 来格式化对话。llama.cpp 内置的模板可能不完全匹配所以需要指定外部的 jinja 模板文件。模板文件路径llama.cpp路径/models/templates/Qwen3-Coder.jinja这个模板处理了 Qwen3 系列的特殊格式包括 推理标签reasoning model 的思维过程标记工具调用格式tools支持System message 的处理多轮对话的拼接规则用错模板会导致模型输出格式错乱甚至完全无法正常工作。这是最容易忽略的一步。5. 启动命令详解./llama-server\-m~/models/Qwen3.6-27B-Q4_K_M-MTP.gguf\-c131072\-n8192\--fiton\--jinja\--chat-template-filellama.cpp路径/models/templates/Qwen3-Coder.jinja\--reasoningoff\--flash-attn on\--no-mmap\--host0.0.0.0\--port8080\--timeout300\--parallel1\--batch-size1024\--aliasqwen3.65.1 逐个参数解释参数值说明-m模型路径GGUF 模型文件位置-c131072上下文窗口 128K。Qwen3.6 原生支持 128K 上下文-n8192最大生成 token 数--fiton智能上下文裁剪。当输入超过上下文窗口时自动裁剪最旧的 token 而非直接报错--jinja启用 Jinja 模板引擎来处理 chat template--chat-template-file路径外部 chat template 文件。不指定会使用内置模板可能导致格式错误--reasoningoff关闭推理标签处理。这个参数控制是否自动处理 标签。设为 off 是因为评测时我们需要手动处理思维过程见评测文章中clean_code函数 | |–flash-attn| on | **Flash Attention**减少注意力计算的显存占用并加速推理 | |–no-mmap| | 禁用内存映射加载。mmap 在模型文件较大时可能不稳定特别是 NVMe 上的大文件 | |–host| 0.0.0.0 | 监听所有网卡方便从外部访问 | |–port| 8080 | API 端口 | |–timeout| 300 | 请求超时 300 秒5 分钟。27B 模型推理较慢默认超时不够 | |–parallel| 1 | 并行处理 1 个请求。并发会增加 KV Cache 消耗 | |–batch-size| 1024 | 推理 batch 大小。越大首 token 越快但占用更多显存 | |–alias | qwen3.6 | 模型别名API 返回中显示 |5.2 显存分配启动后看显存占用GPU 0 (RTX 3050 8GB): llama-server → 6018 MiB (约 75% 显存) 其他 → ~1800 MiB (桌面环境、浏览器等) GPU 1 (RTX 3080 20GB): llama-server → 18660 MiB (约 91% 显存) 其他 → ~3 MiB双卡拆分情况3080 加载了约 18.2GB 模型权重 KV Cache3050 加载了约 5.9GB 模型权重总计约 24GB 分布在两张卡上模型本身 16GB其余是运行时开销llama.cpp 默认会自动进行多 GPU 的层拆分tensor parallelism。3080 显存大承担更多层3050 分担部分层减轻 3080 的 KV Cache 压力。如果只用单张 3080模型权重占约 16GB20GB 显存只剩 4GB 给 KV Cache。对于 128K 上下文窗口这 4GB 很快就会耗尽导致推理速度骤降KV Cache 溢出到 CPU 内存。双卡的优势就在这里体现。5.3 为什么 --reasoning offQwen3.6 是推理模型输出时会自动包裹 标签。llama.cpp 的–reasoning 参数有三个选项on自动处理客户端看到的是去掉了思维过程的干净输出off原始输出包含思维过程标签hidden输出思维过程但不计入 token 统计评测脚本中clean_code函数需要手动处理思维标签用正则rthink.*$过滤所以这里设为off让原始数据完整传给脚本处理。如果做日常聊天使用建议设为on这样看到的就是干净的回答。6. API 调用llama-server 启动后提供了一个 OpenAI 兼容的 APIcurlhttp://localhost:8080/v1/chat/completions\-HContent-Type: application/json\-d{ messages: [ {role: system, content: 你是一个编程助手。}, {role: user, content: 用 Python 写一个快速排序} ], temperature: 0.1, max_tokens: 2048 }返回格式和 OpenAI API 完全一致{id:cmpl-xxx,model:qwen3.6,choices:[{message:{role:assistant,content:/think...思考过程...\n/think\npython\ndef quick_sort(arr): ...\n},finish_reason:stop}]}6.1 其他有用的 API 端点端点用途GET /v1/models查看已加载的模型列表GET /v1/chat/models查看支持聊天的模型POST /v1/completions补全 API非对话模式GET /health健康检查# 查看模型信息curlhttp://localhost:8080/v1/models# 健康检查curlhttp://localhost:8080/health7. 性能实测7.1 推理速度根据三轮评测的数据统计任务复杂度平均响应时间Token 生成速度估算简单GCD、质数判断25-77s约 15-30 tok/s中等LRU、正则、多线程75-120s约 10-20 tok/s困难LC Hard、完整项目90-280s约 5-15 tok/s响应时间包含首 token 延迟 全部 token 的生成时间。首 token 通常是最慢的因为需要计算整个上下文的注意力。7.2 影响速度的因素上下文长度输入越长首 token 越慢。评测脚本的 prompt 很短所以主要时间花在生成上KV Cache 占用双卡虽然分担了模型权重但 KV Cache 主要在 3080 上。3080 显存占用 91%留给 KV Cache 的空间有限MTP 加速效果MTP 架构理论上能加速 token 生成但在 Q4 量化 双卡拆分的场景下加速效果可能不如全精度单卡明显8. 常见问题问题 1llama-server 启动后立即崩溃检查编译时是否启用了 CUDA。运行llama-server -h看帮助信息中是否有 CUDA 相关选项。如果没有重新编译时加上-DGGML_CUDAON。问题 2显存不足GGML_ERROR: failed to allocate GPU buffer降低上下文窗口-c 32768或减少 batch-size。如果模型本身都装不下考虑更低精度的量化Q4_K_S或更小的模型。问题 3chat template 不匹配模型输出乱码、格式错乱、或反复输出系统提示——大概率是 chat template 不对。确保--chat-template-file指向正确的模板文件并且用--jinja启用。问题 4推理速度极慢检查nvidia-smi看 GPU 利用率如果很低说明没有走 GPU检查--flash-attn on是否启用确认 CUDA 后端.so文件在build/bin/目录下问题 5MTP 模型加载失败error: unsupported model architecturellama.cpp 需要 b9800 之后的版本才支持 MTP 架构。确认git describe --tags显示的版本号足够新。9. 启动脚本日常使用写个简单的启动脚本避免每次都敲长命令#!/bin/bash# start-qwen3.6.shMODEL_PATH~/models/Qwen3.6-27B-Q4_K_M-MTP.ggufTEMPLATE_PATHllama.cpp路径/models/templates/Qwen3-Coder.jinjaLLAMA_SERVERllama.cpp路径/build/bin/llama-server$LLAMA_SERVER\-m$MODEL_PATH\-c131072\-n8192\--fiton\--jinja\--chat-template-file$TEMPLATE_PATH\--reasoningoff\--flash-attn on\--no-mmap\--host0.0.0.0\--port8080\--timeout300\--parallel1\--batch-size1024\--aliasqwen3.610. 总结部署要点回顾llama.cpp 要编译 CUDA 版本——-DGGML_CUDAON是必须的MTP 模型需要新版本——b9800 才支持Chat template 不能省——Qwen3 系列有特定格式要求双卡拆分有实际价值——3080 主力 3050 辅助比单卡 3080 的 KV Cache 空间更充裕参数要按需调整——-c、-n、--batch-size都直接影响显存占用和推理速度这套配置的真实体验双路 Xeon 3080 3050 的组合跑 27B Q4 模型推理速度不算快平均 1-2 分钟/任务但胜在稳定。20GB 显存不是跑大模型的理想配置但加上 8GB 的 3050 分担之后日常使用完全够用。如果预算允许单张 24GB 的卡如 4060Ti 24G、3090 24G会是最简单的方案——不需要折腾双卡拆分KV Cache 也相对充裕。但对于手头已经有双卡的老工作站来说llama.cpp 的多 GPU 支持让这些旧硬件重新发挥了价值。与评测文章的关联前三篇评测文章中的所有测试都是在这个环境下跑的。如果你看到评测结果中的响应时间觉得慢这是 20GB 显存 双卡拆分的正常表现。在显存更充裕的单卡环境下比如 A100 80G同样的模型推理速度会快很多。附录环境检查清单部署前可以快速检查一遍# 1. 检查 NVIDIA 驱动和 CUDAnvidia-smi# 2. 检查 CUDA 编译工具nvcc--version# 3. 检查 llama.cpp 编译产物ls-labuild/bin/llama-serverls-labuild/bin/libggml-cuda.so# 4. 检查模型文件ls-lh~/models/Qwen3.6-27B-Q4_K_M-MTP.gguf# 5. 检查 chat templatecatllama.cpp路径/models/templates/Qwen3-Coder.jinja|head-5# 6. 测试启动加 --help 看是否识别 CUDA./llama-server-h|grep-icuda全部正常就可以放心启动了。附录评测 API 连通性测试# 快速测试 API 是否可用curlhttp://localhost:8080/v1/chat/completions\-HContent-Type: application/json\-d{ messages: [{role: user, content: 你好}], max_tokens: 64 }|python3-mjson.tool返回正常就能开始跑评测了。评测脚本run_benchmark.py的第一步就是做这个连通性检查。系列文章索引第一篇Qwen3.6-27B 本地代码能力评测基础篇15 任务 100% 通过第二篇Qwen3.6-27B 本地代码能力评测 v2进阶篇12 任务 75% 通过第三篇Qwen3.6-27B 本地代码能力评测 v3高级篇16 任务 93.75% 通过第四篇本文部署环境与技术细节