使用 llama.cpp 运行 Qwen3.8-27B

太阳作者太阳
原创内容采用 CC-4.0 协议发布,转载请注明出处

我已经用 ModelScope 下载了 Qwen3.8-27B,并在 RTX 4090 24GB 上启动了 llama-server。目前只做了启动和两次对话请求,日志没有出现加载失败、显存不足或上下文溢出。回复质量、长上下文、视觉输入、Agent 工具调用和持续运行仍未测试,因此这篇文章先保留为草稿。

下载模型

先按固定 ModelScope 缓存根目录设置 MODELSCOPE_CACHE。然后只下载 UD-Q4_K_M 权重和 F16 视觉投影文件:

modelscope download unsloth/Qwen3.8-27B-GGUF \
  --include "*Q4_K_M*" "*mmproj-F16*"

本次得到两个文件:

Qwen3.8-27B-UD-Q4_K_M.gguf  16464440224 bytes
mmproj-F16.gguf                927607488 bytes

模型文件位于新版 ModelScope 缓存目录:

$MODELSCOPE_CACHE/models/unsloth--Qwen3.8-27B-GGUF/snapshots/master/

启动前可以核对文件名和大小:

find "$MODELSCOPE_CACHE/models/unsloth--Qwen3.8-27B-GGUF/snapshots/master" \
  -maxdepth 1 -type f -printf '%f %s bytes\n'

Qwen3.8 的权重文件名带有 UD,启动时应使用实际文件名 Qwen3.8-27B-UD-Q4_K_M.gguf

启动纯文本服务

./build/bin/llama-server 是从 llama.cpp 源码编译得到的可执行文件。源码获取、CUDA 构建参数和版本检查见使用 llama.cpp、Claude Code 和 Codex 搭建本地 Agent 编码环境中的“编译 llama.cpp”一节。完成构建并进入 llama.cpp 仓库目录后,再运行下面的命令。

这次只测试文本输入,因此没有加载已经下载的 mmproj-F16.gguf

export LLAMA_API_KEY='在这里填入你的实际 key'

./build/bin/llama-server --metrics --alias Qwen3.8-27B \
  --model "$MODELSCOPE_CACHE/models/unsloth--Qwen3.8-27B-GGUF/snapshots/master/Qwen3.8-27B-UD-Q4_K_M.gguf" \
  --no-mmproj --reasoning-preserve --jinja \
  --host 0.0.0.0 --port 30104 --ctx-size 262144 -ngl 100 --fit off \
  --cache-type-k q4_0 --cache-type-v q4_0 --parallel 1 \
  --batch-size 4096 --ubatch-size 1024 --flash-attn on \
  --load-mode mlock --threads $(nproc)

这组参数沿用了Qwen3.6-27B 的启动配置,目的是先在同一台机器上建立可比较的起点。它目前只能算一次成功启动记录,还不能据此判断 262K 上下文、KV Cache 量化和批次参数是否适合长时间使用。

--no-mmproj 会关闭视觉输入。以后测试图片时,需要移除这个参数,并增加:

--mmproj "$MODELSCOPE_CACHE/models/unsloth--Qwen3.8-27B-GGUF/snapshots/master/mmproj-F16.gguf"

当前运行结果

llama-server 在约 11 秒后完成加载:

init: llama threadpool init, n_threads = 32
load_model: initializing, n_slots = 1, n_ctx_slot = 262144, kv_unified = 'false'
llama_server: model loaded
llama_server: listening on http://0.0.0.0:30104

随后发起了两次对话请求。第一次处理 371 个输入 token,生成 85 个 token:

prompt eval time = 322.84 ms / 371 tokens (1149.19 tokens per second)
eval time = 1704.65 ms / 85 tokens (49.28 tokens per second)
total time = 2027.49 ms / 456 tokens
truncated = 0

第二次请求与已有上下文的前缀相似度是 0.958,服务复用了同一 slot 的缓存。这次只重新计算 20 个输入 token,生成 804 个 token,生成速度仍为约 49.38 tokens/s:

selected slot by LCP similarity, f_sim_best = 0.958
prompt eval time = 277.24 ms / 20 tokens (72.14 tokens per second)
eval time = 16262.84 ms / 804 tokens (49.38 tokens per second)
total time = 16540.09 ms / 824 tokens
truncated = 0

这些数字说明模型能够加载、处理请求并复用前缀缓存。日志不能说明回复内容是否准确,也不能替代 Claude Code 或 Codex 的真实工具调用测试。

关于 unused tensor 警告

加载时出现了多条 blk.64 警告,其中既有普通 attention、FFN 权重,也有 nextn 权重:

model has unused tensor blk.64.attn_q.weight -- ignoring
model has unused tensor blk.64.ffn_gate.weight -- ignoring
model has unused tensor blk.64.nextn.eh_proj.weight -- ignoring
model has unused tensor blk.64.nextn.shared_head_norm.weight -- ignoring

这组现象与 llama.cpp 已记录的 Qwen3.x MTP 块加载问题一致。当前服务仍然完成了普通生成,因此它不是本次启动失败。不过,额外的 MTP/NextN 预测块没有在这次常规推理中发挥作用,本文也没有测试 draft-mtp 推测解码。

在 llama.cpp 修复或明确该问题前,不能把这些警告简单删掉,也不应宣称模型的全部权重都已参与推理。

后续测试

当前还需要补充以下结果:

  • 普通问答和编码任务的输出质量。
  • Claude Code 与 Codex 的真实终端工具调用。
  • 多轮对话中的聊天模板和角色顺序。
  • 262K 长上下文的显存占用、缓存命中和稳定性。
  • 加载 mmproj-F16.gguf 后的图片输入。
  • 服务持续运行时的内存、显存和生成速度变化。
  • MTP/NextN 警告在后续 llama.cpp 版本中的处理情况。

这些项目完成前,本文只记录当前环境下的初步运行结果,不作为 Qwen3.8-27B 已适合日常 Agent 编码的结论。

参考资料