使用 llama.cpp 运行 Qwen3.8-27B
我已经用 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 编码的结论。