本地跑双 Qwen3.8-27B 实践实录：官方原版 + 去拒答版，200K 上下文全量部署与实测数据

[清风明月]

本地跑双 Qwen3.8-27B 实践实录：官方原版 + 去拒答版，200K 上下文全量部署与实测数据

平台：Linux（Ubuntu 26.04 LTS）/ llama.cpp 源码编译 / systemd 用户服务
用途：本地多模态 LLM（文字 + 视觉），日常 Hermes Agent 主模型
日期：2026-08-18（模型 8-14 发布后 4 天内的完整实践）

一、先说结论

• 一台 32GB 显存卡可以同时把 Qwen3.8-27B 官方原版和社区去拒答版都部署起来跑 200K 上下文，全 GPU 加载，KV cache 4bit，每个服务实测占用约 25 GB 显存，32GB 卡还有 6GB 余量。
• 实测吐词：API 端到端 58-60 t/s（含思考 token 计数）；长续写工作负载 46-51 t/s；短输出配合 MTP 投机解码能冲到 83 t/s（draft 接受率 0.995）。
• 视觉可用：一张真实截图发进去，4.5 秒内带思考返回，描述基本准确。
• 最大坑在官方 chat template 会把空的 thinking 块嵌进多轮对话，禁 multi-turn agent——必须 --jinja 覆盖；另一个坑是 3.8 系过思考，用 reasoning_effort=medium 压住。

二、硬件 / 软件环境

项	配置
显卡	NVIDIA RTX PRO 4500 Blackwell，32 GB（实测 32623 MiB），驱动 595.84
CPU	AMD Ryzen 7 3700X（8C/16T）
内存	60 GB
系统	Ubuntu 26.04 LTS
推理框架	llama.cpp 源码编译（0.1.0-dev，build 1，commit 6509138，GCC 13.4.0）
服务方式	systemd 用户服务（systemctl --user），8000 端口互斥

三、模型来源（两个 27B 分别来自哪）

Qwen 官方只发布 BF16 / FP8 权重，没有官方 GGUF，本地 GGUF 一律第三方转换。我实测字节级比对（本地文件 size 与 HF 仓库完全一致）确认了两份来源：

1. 官方原版 Qwen3.8-27B（默认主力，llama.cpp Q5_K_M）

• 仓库：https://huggingface.co/unsloth/Qwen3.8-27B-GGUF
• 底模：https://huggingface.co/Qwen/Qwen3.8-27B（官方，8-14 发布，27.78B dense 混合注意力 VLM，262144 原生上下文，Apache 2.0）
• 文件：Qwen3.8-27B-Q5_K_M.gguf（19,834,055,648 B）+ mmproj-F16.gguf（927,607,488 B）

2. 去拒答版 Qwen3.8-27B-Uncensored（低拒版，专职"有问必答"）

• 仓库：https://huggingface.co/JonathanColetti/Qwen3.8-27B-Uncensored-GGUF
• 加工：JonathanColetti 做 abliteration（正交化消解除拒答方向），拒答率 98/100 → 12/100，四种基准均值仅掉 0.5 分（噪声级），保留 MTP 投机解码头
• 文件：Qwen3.8-27B-Uncensored-Q5_K_M.gguf（19,535,701,408 B）+ Qwen3.8-27B-Uncensored-vision-f16.gguf（927,606,912 B）
• ️ 注意别下错：Reddit 上推的 vcruz305/Qwen3.8-27B-AEON-ULTIMATE-UNCENSORED-GGUF（AEON 系）是 --no-mtp，不带 MTP 头，同类 Q5_K_M 只有 19,231,099,968 B，明显小一截。要 MTP 提数选 JonathanColetti 版。

四、部署步骤（llama.cpp 源码 + systemd 服务）

1. 编译 llama.cpp

llama.cpp 需要足够新的版本才认识 qwen35 架构，建议直接源码编最新：

git clone https://github.com/ggml-org/llama.cpp && cd llama.cpp
cmake -B build -DGGML_CUDA=ON -DCMAKE_BUILD_TYPE=Release
cmake --build build --config Release -j$(nproc)

2. 下载模型（HF 直连，直接落到最终目录）

hf download unsloth/Qwen3.8-27B-GGUF --local-dir ~/models/Qwen3.8-27B \
  --include "Qwen3.8-27B-Q5_K_M.gguf" "mmproj-F16.gguf"
hf download JonathanColetti/Qwen3.8-27B-Uncensored-GGUF \
  --local-dir ~/models/Qwen3.8-27B-Uncensored \
  --include "Qwen3.8-27B-Uncensored-Q5_K_M.gguf" "Qwen3.8-27B-Uncensored-vision-f16.gguf"

3. systemd 用户服务（两个服务参数完全一致，仅模型路径不同）

~/.config/systemd/user/llama-qwen-27B.service：

[Unit]
Description=llama.cpp Qwen3.8-27B Q5_K_M Service (200K, effort=medium)

[Service]
ExecStart=%h/llama.cpp/build/bin/llama-server \
  -m %h/models/Qwen3.8-27B/Qwen3.8-27B-Q5_K_M.gguf \
  --mmproj %h/models/Qwen3.8-27B/mmproj-F16.gguf \
  --alias Qwen3.8-27B \
  --host 127.0.0.1 \
  --port 8000 \
  --ctx-size 200000 \
  --n-gpu-layers 99 \
  --flash-attn on \
  --parallel 1 \
  --jinja \
  --no-mmap \
  --ubatch-size 512 \
  --cache-type-k q4_0 \
  --cache-type-v q4_0 \
  --cache-ram 32768 \
  --chat-template-kwargs '{"reasoning_effort": "medium", "preserve_thinking": true}' \
  --reasoning-preserve \
  --temp 1.0 \
  --top-k 20 \
  --top-p 0.95 \
  --min-p 0.0 \
  --spec-type draft-mtp \
  --spec-draft-n-max 2
Environment=CUDA_VISIBLE_DEVICES=0
Restart=on-failure
RestartSec=10
StandardOutput=journal
StandardError=journal

[Install]
WantedBy=default.target

启用高开一体，服务管理：

systemctl --user daemon-reload
systemctl --user enable --now llama-qwen-27B.service     # 官方版
systemctl --user enable --now llama-qwen-27B-uc.service  # 去拒答版（同参数改模型路径）
# 端口 8000 互斥：开一个前先停另一个
systemctl --user start/stop/restart llama-qwen-27B.service

五、实测结果（均为本机真实跑出的数字）

吐词速度（llama-server 日志 + API 客户端实测）

场景	数据	说明
API 端到端（纯解码 300 token 全吐出）	60.1 t/s，TTFT 0.28s	httpx 客户端计时，含网络开销
API 端到端（带思考问答）	58.8 t/s，TTFT 0.16s	思考 279 token + 正文 189 token
长续写工作负载（n_gen 418→1861 持续生成）	tg 46-51 t/s	真实 agent 会话下的稳速
短输出 + MTP 高命中	83.4 t/s	draft acceptance 0.995，mean len 2.99

MTP 投机解码统计（journal draft acceptance）

• 长上下文会话：acceptance 0.615，mean len 2.23
• 一般任务：acceptance 0.65 ~ 0.995，mean len 2.3 ~ 2.99
• 结论：MTP 在长输出/低重复性文本收益浮动，短输出命中很高，白捡速度，显存代价可忽略，建议一直开着。

视觉（多模态）实测

• 输入真实截图（PNG, ~718 prompt token）+ 提问"描述这张截图"
• 返回：4.5 秒，其中思考 107 token，正文准确描述了页面是各模型 API 请求配额表格（Grok/GPT/GLM/Kimi/Qwen/DeepSeek 各周期次数）
• 结论：vision 走 --mmproj/vision-f16 正常，识别准确度够用

显存占用（32GB 卡）

项	占用
llama-server（Q5_K_M 19.5GB 权重 + mmproj + 200K ctx q4 KV）	25,318 MiB ≈ 24.7 GB
全卡总占用	26.0 / 32 GB（其余为桌面等）
剩余余量	~6 GB

200K 上下文能塞进 32GB 的三个关键：KV cache 全 4bit（--cache-type-k/v q4_0）、全 GPU offload（-ngl 99）、--no-mmap 避免大文件映射把内存和随机 IO 拉爆。KV 换成 fp16 的话 200K 直接放不下。

与 A3B（MoE）的参照对比

同机还部署了 Qwen3.6-35B-A3B（vLLM NVFP4，MoE 3B 激活）作对照：

指标	Qwen3.8-27B (dense)	Qwen3.6-35B-A3B (MoE)
纯解码	46-60 t/s	144 t/s
往返延迟（纯文本问答）	TTFT ~0.2s	1.2s
定位	dense 全参，编码/深度推理/长文写作更强	速度翻倍余，工具调用/Hermes agent 首选

一句话：dense 质量换速度，MoE 速度换质量，同机器双方案按场景切。

六、踩坑与经验（给后面的人）

1. 必须 --jinja：3.8 官方 jinja 模板会把空的 thinking 块包进输出，直接破坏多轮 agent 会话（llama.cpp 下实测）。GGUF 包里若烤了固定模板也要用 --jinja。
2. 过思考是 3.8 的祖传毛病：简单 prompt 都能吐几千 token 思考（Reddit 上戏称"史上最 overthinking"）。用 --chat-template-kwargs '{"reasoning_effort": "medium"}' + --reasoning-preserve 可控档，medium 下实际思考量很小。
3. 官方 benchmark 别全信：SWE-bench Pro 61.7 之类是 Qwen 自报（且对比项直接复用别家成绩），发布当天没有独立复现。release 当天 Reddit 实测反馈一致好评（双 5080 Q6 能到 100 t/s、2080Ti 22GB Q8 也能 40 t/s），本机体验同样"明显强于 3.6-27B"——但"强"是有依据的主观体验，不是官方数字背书。
4. 量化选 Q5_K_M 是甜点：Q4 能用、Q5 几乎无损、Q6/Q8 32GB 全 offload 放不下（Q8 是 26.63 GB + KV 直接爆卡）。14 层 hybrid attention 的 KV 天然小，配合 4bit KV 是 32GB 卡跑 200K 的唯一正解。
5. 下载后务必字节级核验：HF 仓库 ?blobs=true 拿每个文件 size，与本地 stat 对比。不同仓库同名量化可能差几百万字节（带不带 MTP、带不带 vision），网上吹的"best one"未必是你要下的那个。
6. 切模型 = 切服务：8000 端口互斥，切换脚本负责停旧起新，不要把服务常驻两个。

七、接入 agent 的方式（OpenAI 兼容）

llama.cpp 自带 /v1/chat/completions，标准 OpenAI 协议，视觉直接 image_url base64。接入任何 agent 框架只需把 base URL 指到 http://127.0.0.1:8000/v1：

# 视觉测试（base64 内联）
curl http://127.0.0.1:8000/v1/chat/completions \
  -H 'Content-Type: application/json' \
  -d '{"model":"Qwen3.8-27B","max_tokens":500,
       "messages":[{"role":"user","content":[{"type":"image_url","image_url":{"url":"data:image/png;base64,..."}},
       {"type":"text","text":"描述这张图"}]}]}'

---

帖子里的所有速度、显存、延迟、MTP 统计均为本机（8-18）实测；模型来源均做过字节级比对。硬要说缺点：dense 27B 的算力开销比同机 MoE 大，长 agent 会话的思考 token 消耗要心里有数——这也是很多人对 3.8 的真实槽点。

以上部署实测均由hermes调用opencodego套餐模型deepseek-v4-flash负责，本人只负责在旁边喝茶，静静地看着就行了。所以有问题也别问我，问你机器上的hermes或deepseek harness！

[清风明月]

实测可以全量262K上下文无压力，但看了锤哥的视频及其它帖子，太高的上下文意义不大，还占显存，200K够用了。

[terry]

确实不用追求太高上下文，deepseek harness对上下文处理很克制，不滥用。128k上下文就能解决大多数需求，实在搞不定换在线，那消耗就小多了。说实话，我测试了下，就是用来干脏活，修修补补也不如在线的体验舒服，但是不要钱。

[清风明月]

确实，都是涨价惹的祸，没办法，本地还是要有一个能处理简单任务的免费模型，哎，要是不涨价，deepseek-v4-flash用得多舒服！还是设为128K了。

[清风明月]

现在感觉量大管饱的在opencode go套餐里只有mimo-v2.5这一个选择了，虽然多模态不错，但驱动hermes和harness感觉效果比deepseek-v4-flash差多了。

[terry]

@清风明月 是的，v4flash还是不贵啊，还是能玩的。

[清风明月]

@terry 说:

是的，v4flash还是不贵啊，还是能玩的。

是的，不用也没比它更好的选择，即使涨价，也是性价比最高的，只是我们习惯了之前的定价而已！

[rock shi]

@terry 看来锤子哥还是赚钱，其实DeepSeek这个价格对一般还没怎么变现的用户来说成本算是比较高，如果单靠DeepSeek去试错的话，现在成本要一天四五十块钱，要是已经有变现能力了当然这个确实不算高

[kos or]

@rock-shi said:

如果单靠DeepSeek去试错的话，现在成本要一天四五十块钱

差不多 我之前使用平均都在一天兩美元以內 漲價第一天就增加到US$7.7, 這都是在不含coding狀況下的使用金額

目前是本地模型 + GPT Luna 混用, 暫時不用Deepseek-V4-Flash了

[stxpnet]

@kos-or 还好吧，我目前只有配置27B新模型和框架的时候才开一下deepseek。 其它时候就用本地最好的27B模型跑任务。大大解放了。 就是月底电费还不知道怎样。

[kos or]

@stxpnet

主要是我Deepseek這個月額度沒了, GPT額度夠,
跑本地 电费應該還行 不太可能像ComfyUI產圖一樣GPU核心高瓦數下一直跑;
有人使用地端模型家中電費飆升的嗎？

一台機器 600W 每天持續運作8小時, 連續30天 一個月的電費約在20美元以內