Published on

在 AMD 笔记本上本地跑 Qwen3-4B：一套不依赖 CUDA 的轻量部署方案

Authors
  • Name
    Twitter

在 AMD 笔记本上本地跑 Qwen3-4B

很多人一提到本地大模型，第一反应还是 CUDA、显卡显存、推理框架和一堆系统依赖。问题是，现实里不少机器根本不满足这个前提。

我这次做的事情很简单：在一台普通 AMD 笔记本上，不装 CUDA，不折腾系统级服务，直接用用户目录里的自包含方案，把 Qwen3-4B-Q4_K_M.gguf 跑起来。

这篇文章不是“最强性能攻略”，也不是一键脚本展示。它更像一份工程记录：如果你手上只有一台没有 NVIDIA GPU 的 Linux 机器，想先建立一个稳定、可维护、可复现的本地 LLM 基线，这条路是能走通的。

这次部署的目标

先把目标讲清楚，不然后面很容易跑偏。

这次并不追求更大的参数规模，也不追求复杂的服务编排。目标只有四个：

  • 在没有 CUDA 的前提下完成本地推理
  • 模型、运行器和脚本都放在用户目录，方便迁移和清理
  • 下载结果可校验，避免大文件损坏后很难排查
  • 终端交互和本地 HTTP 服务都能直接用

最终落地方案如下：

  • 模型：Qwen3-4B-Q4_K_M.gguf
  • 推理后端：llama.cpp
  • 加速方式：纯 CPU
  • 部署目录：/home/an/Projects/interesting/local-llm

如果只看一句话总结，那就是：

用一个 4B 的 GGUF 量化模型，加一套本地目录里的 llama.cpp 运行器，先把“能稳定用”的闭环做出来。

运行环境

机器配置如下：

CPU:    AMD Ryzen 5 5600H, 6C / 12T
Memory: 30 GiB
GPU:    AMD Radeon Vega integrated graphics
OS:     Ubuntu 24.04.4 LTS
Disk:   NVMe SSD

真正决定选型的，不是 CPU 型号本身，而是这两个约束：

  • 没有 NVIDIA GPU，也就没有 CUDA 路线
  • 虽然有 30GiB 内存，但如果直接上 8B、14B，纯 CPU 交互体验会明显变差

所以这次的判断很克制：

  1. 先走 CPU 推理
  2. 模型规模控制在 4B 左右
  3. 优先 GGUF 量化格式
  4. 不做系统级安装

这比一开始就挑战更大的模型更现实。先把基线做稳，再谈升级。

为什么选 Qwen3-4B

本机内存并不算特别紧张，但“能加载”和“适合长期使用”是两回事。

这次选的是：

Qwen3-4B-Q4_K_M.gguf

原因比较直接：

  • Qwen 对中文场景更友好
  • 4B 规模在纯 CPU 环境里还算能接受
  • Q4_K_M 是体积和效果之间比较常见的折中点
  • GGUF 可以直接被 llama.cpp 加载，路径简单

模型文件大约 2.4GB。这个体积不算小，但仍然处在可下载、可校验、可管理的范围里。

为什么这次没继续用 Ollama

最开始我考虑过直接走 Ollama：

ollama run qwen3:4b

它的优点很明显。安装后体验会更顺，模型管理、服务进程、命令行交互都已经封装好了。对多数人来说，Ollama 仍然是本地 LLM 的最快入口。

但放到这次环境里，有两个很现实的问题：

  1. 系统级安装需要 sudo，而当前环境并不适合走这条路
  2. Linux amd64 安装包本身体积不小，下载成本并不低

换成 llama.cpp 预编译运行器以后，事情就简单很多了：

  • 下载体积小很多
  • 不需要改系统路径
  • 不需要注册 systemd 服务
  • 直接放在用户目录即可运行

所以这次不是说 Ollama 不好，而是 llama.cpp 更符合“轻量、自包含、少依赖”的目标。

最终目录结构

部署目录整理成下面这样：

/home/an/Projects/interesting/local-llm
├── bin/llama-b8946
├── models/Qwen3-4B-Q4_K_M.gguf
├── chat-qwen3-4b.sh
├── serve-qwen3-4b.sh
├── download-qwen3-4b.sh
└── README.md

这套结构的好处很朴素：

  • 运行器、模型、脚本集中在一起
  • 迁移时只需要拷贝一个目录
  • 清理时也不会留下系统级残留

对于本地实验环境，这种“笨但清楚”的组织方式通常比复杂安装流程更省事。

模型下载里真正麻烦的地方

这次最麻烦的其实不是推理，而是下载。

Hugging Face 仓库可以访问，但大文件经过 Xet 链路时出现了 TLS 握手中断，报错类似：

tls handshake eof

后来切到 ModelScope，虽然文件能下，但单连接速度不太稳定。最后采用的办法是 HTTP Range 分片下载：把 2.5GB 左右的 GGUF 文件切成 16 个分片并行拉取，再按顺序合并。

这个处理没有什么“高级技巧”，只是承认一件事：大文件下载的首要问题往往是链路稳定性，不是你会不会用 wget。

模型校验信息

模型元信息如下：

File:   Qwen3-4B-Q4_K_M.gguf
Size:   2497280256 bytes
SHA256: 7485fe6f11af29433bc51cab58009521f205840f5b4ae3a32fa7f92e8534fdf5

校验命令：

sha256sum /home/an/Projects/interesting/local-llm/models/Qwen3-4B-Q4_K_M.gguf

正确输出应包含：

7485fe6f11af29433bc51cab58009521f205840f5b4ae3a32fa7f92e8534fdf5

这一步不要省。

GGUF 文件体积大，一旦分片合并出错或者下载中途损坏，后面看到的往往只是“加载失败”或者莫名其妙的异常。那时候再回头排查，成本反而更高。

两种运行方式

这次保留了两个入口：终端交互和本地 HTTP 服务。

终端聊天

直接运行：

/home/an/Projects/interesting/local-llm/chat-qwen3-4b.sh

终端中运行 Qwen3-4B 的交互截图

退出命令：

/exit

脚本里的核心参数包括：

--threads 8
--ctx-size 4096
--conversation
--reasoning off

这里把线程设为 8，主要是为了在 6C / 12T 的 CPU 上兼顾吞吐和可用性，不把整台机器彻底打满。ctx-size 设为 4096，已经够覆盖一般问答、解释命令、短文本改写这类轻任务。

本地 HTTP 服务

启动命令：

/home/an/Projects/interesting/local-llm/serve-qwen3-4b.sh

Qwen3-4B 的本地 HTTP 服务启动截图

访问地址：

http://127.0.0.1:8080

这个入口更适合接本地页面、脚本工具，或者后续自己套一层简单前端。

实测速度怎么样

我用中文短 Prompt 做了基本加载和生成测试，模型可以正常输出。观测值大致如下：

Prompt processing: ~30 tok/s
Generation:        ~10.9 tok/s

这个速度放在纯 CPU 环境里，我觉得是可接受的。

它当然不适合高并发服务，也不适合长上下文批处理，但如果你的需求是下面这些，它已经够用了：

  • 本地问答
  • 命令解释
  • 短文本改写
  • 轻量代码辅助

首次加载模型会有比较明显的等待，这也正常。后续交互主要还是受生成速度影响。对于一个 4B 的 Q4 模型来说，这个表现基本符合预期。

这次部署里最值得保留的经验

做完以后，我反而更确认一件事：没有 CUDA，不代表本地 LLM 就没有实践价值；真正重要的是别一开始就把目标定得太虚。

这次能跑通，不是因为环境多强，而是因为路线足够收敛：

  • 模型别太大
  • 格式尽量通用
  • 运行器尽量轻
  • 文件必须可校验
  • 启动方式脚本化

Qwen3-4B-Q4_K_M + llama.cpp 正好符合这个思路。它不是性能最强的组合，但它干净、透明，也比较容易维护。

如果后面继续往上走，我会优先考虑两个方向：

  1. 保持这套 llama.cpp 结构不变，继续试 Qwen3 8B 的 GGUF 量化版本
  2. 另开一条 Ollama 路线，换取更完整的模型管理体验

至少在当前这台机器上，4B 这一档已经足够作为本地离线 LLM 的起点。

Discuss on Twitter • View on GitHub