侧边栏壁纸
博主头像
龍騰博客 博主等级

行动起来,活在当下

  • 累计撰写 187 篇文章
  • 累计创建 31 个标签
  • 累计收到 7 条评论

目 录CONTENT

文章目录

SER8 部署 Qwen3.8-27B 独立测试教程

管理员
2026-08-26 / 0 评论 / 0 点赞 / 3 阅读 / 0 字

适用环境:fnOS-Ser8(Ryzen AI 9 8845HS + Radeon 780M 核显,38GB 内存),目标是在不影响现有 glm47 / qwen36 / qwen3-2507 三端口架构的前提下,单独起一个容器测试 Qwen3.8-27B 是否适合长期整合进去。


0. 背景信息

  • 模型:Qwen3.8-27B,27B 稠密模型,Apache 2.0,262k 原生上下文

  • 架构特点:混合注意力,64 层里 48 层是线性注意力(Gated DeltaNet)、16 层全量注意力,因此长上下文下 KV 缓存开销比传统 27B 模型小很多

  • 量化来源:推荐 bartowski/Qwen3.8-27B-GGUF(imatrix 校准语料覆盖工具调用和推理场景,量化质量口碑可靠)

  • 必要条件:llama.cpp / Ollama 必须是 2026-05 之后的构建版本,否则不认 qwen35 架构,加载不了模型


1. 准备独立测试目录

不要和现有 vol3 模型混在一起,单独建目录:

mkdir -p /vol3/1000/docker/qwen38-test/models
cd /vol3/1000/docker/qwen38-test/models

2. 下载模型

根据你机器的实际可用内存选量化档位:

量化档位

大小

适用场景

Q4_K_M

17.8GB

内存吃紧或首次测试,安全边际最大(推荐第一轮用这个

Q5_K_M

20.8GB

内存确认宽裕后,追求更好质量

Q6_K

23.5GB

内存非常宽裕时才考虑

huggingface-cli download bartowski/Qwen3.8-27B-GGUF \
  --include "Qwen3.8-27B-Q4_K_M.gguf" \
  --local-dir /vol3/1000/docker/qwen38-test/models

下载完成后确认文件:

ls -lh /vol3/1000/docker/qwen38-test/models/

3. 测试前清理内存/swap 状态(可选但推荐)

先看当前 swap 占用情况:

free -h

如果 swap 使用量接近满(比如 8.0Gi/8.0Gi),且 available 内存明显大于 swap 已用量,可以安全清空 swap,让接下来的监控数据更干净:

swapoff -a
swapon -a
free -h   # 确认 swap 已归零

⚠️ 前提:只有当 free -h 里 available 数值大于 swap 已用量时才能这样操作,否则 swapoff -a 会把数据强行塞回物理内存,可能瞬间打满内存导致系统卡死。

清空后可能会看到 used 内存短暂上升(数据从 swap 搬回物理内存),过一会儿会自动回落,属于正常现象。

4. 确认现有模型端口没占用资源

避免和现有三个模型叠加抢内存,测试期间建议先确认它们是停着的:

docker ps -a --filter "name=llama"

看到状态是 Exited 就说明没在跑,可以直接测试。如果是 Up 状态,先停掉:

docker stop llama-qwen3-2507 llama-glm47 llama-qwen36

5. 创建 docker-compose.yml

/vol3/1000/docker/qwen38-test/ 目录下创建 docker-compose.yml

cd /vol3/1000/docker/qwen38-test
cat > docker-compose.yml << 'EOF'
services:
  qwen38-27b-test:
    image: ghcr.io/ggml-org/llama.cpp:server-vulkan
    container_name: qwen38-27b-test
    restart: unless-stopped
    ports:
      - "8085:8080"
    volumes:
      - ./models:/models
    devices:
      - /dev/dri:/dev/dri
    command:
      - -m
      - /models/Qwen3.8-27B-Q4_K_M.gguf
      - -c
      - "32768"
      - -ngl
      - "99"
      - --host
      - "0.0.0.0"
      - --port
      - "8080"
EOF

配置说明:

  • image:必须用 server-vulkan 标签,跟现有三个模型端口保持一致——这台机器的核显(780M)加速依赖 Vulkan 后端,用普通 server 镜像的话 -ngl 参数会被忽略,只能跑纯 CPU

  • devices: /dev/dri:/dev/dri:把核显设备直通进容器,Vulkan 才能识别到 GPU;这一步容易漏掉,漏了的话即使镜像支持 Vulkan 也会退化成纯 CPU 推理

  • ports:现有三个模型占了 8082-8084,这里用 8085 避免冲突

  • -c 32768:先给 32k 上下文测试,够用且省内存,确认没问题再考虑拉长

  • -ngl 99:尝试把所有层卸载到核显。如果启动报错或跑不动,把这个数值调小,做 CPU/iGPU 混合卸载

  • restart: unless-stopped:测试阶段如果不想让它开机自启,可以删掉这一行

6. 启动容器

docker compose up -d

7. 查看启动日志

docker compose logs -f

看到类似 HTTP server listening 的字样就说明启动成功。按 Ctrl+C 退出日志查看(不会停止容器)。

8. 验证接口是否可用

curl http://localhost:8085/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{"messages":[{"role":"user","content":"你好"}]}'

能收到正常回复就说明模型跑起来了。

9. 边测试边监控内存和 swap

watch -n 2 'free -h | grep -E "Mem|Swap"; echo; docker stats --no-stream qwen38-27b-test'

重点盯 available 这一列,只要不跌到临界值(比如低于 2-3Gi),就算 swap 又开始有数字也不用慌——这是长期运行多个后台服务(frigate、compreface、immich 等)后的正常工作模式,不代表这次测试有问题。

10. 排查内存/性能问题

  • 内存报警或 swap 快速上涨:降低量化档位(换成更小的 Q3/Q4 系列),或缩小 -c 上下文长度

  • 启动失败提示架构不认:确认 llama.cpp 镜像是 2026-05 之后构建的,重新 docker pull 最新版

  • 速度太慢:调整 -ngl 数值找到 CPU/核显卸载的平衡点,核显推理本身就会比独显慢,这是硬件限制不是配置问题

11. 测试结束后清理

不管测试结果如何,用完记得清理:

cd /vol3/1000/docker/qwen38-test
docker compose down

如果决定不采用这个模型,模型文件也可以删掉释放硬盘空间:

rm -rf /vol3/1000/docker/qwen38-test

如果之前为了腾内存停了原有三个模型端口,记得测完重新启动:

docker start llama-qwen3-2507 llama-glm47 llama-qwen36

12. 决定是否整合

测试期间重点关注这几点,作为要不要正式整合进三端口架构的判断依据:

  • 生成速度(tokens/s)是否满足日常使用需求

  • 实际内存占用是否有安全余量(结合这台机器长期 swap 偏紧的情况,建议留足 3-5GB 余量)

  • 工具调用(如果 WorkBuddy / Hermes 要接入)是否正常,尤其关注之前 qwen3-2507 端口出现过的 400 报错问题这次是否复现

  • 输出质量是否比现有模型有明显提升,值得为它腾出常驻内存位置

确认没问题后,再考虑怎么并入现有的手动切换架构(模型互斥、按需启停,避免多个大模型同时常驻抢内存)。

13. ⚠️ 重要:严格遵守"同一时刻只跑一个模型"

这台机器曾经因为同时运行两个模型导致 8GB swap 被打满(两个 27B 级别模型的权重+KV缓存叠加,轻松超过系统内存承载上限)。这不是配置问题,是纯粹的资源超载,只要严格遵守单模型运行的纪律就能完全避免

尤其如果后续调大了 UMA VRAM 分区(比如从 8G 调到 16G/20G),系统可见内存会进一步收紧(38GB → 30GB 左右甚至更低),"同一时刻只跑一个模型"这条纪律会变得更重要,不能有例外:

  • 启动新模型容器前,务必先确认旧模型容器已经停止:

    docker ps --filter "name=llama"
    
  • 如果要切换模型,先停旧的再启新的,不要图省事直接叠加启动:

    docker stop llama-<旧模型名>docker compose up -d   # 或 docker start <新模型容器名>
    
  • 建议养成习惯:每次启动模型前先跑一遍 free -h,确认 available 内存和 swap 状态是干净的,再决定要不要启动。

0
AI

评论区