llama.cpp RPC 分布式推理折腾记录
这次主要是在一台 Arch Linux GPU 机器上搭 `ggml-rpc-server`，再让 Windows 主机通过 `llama-cli` 远程调用这个 worker，完成 `llama.cpp` 的 RPC 推理链路验证。
参考文献：
【主要】llama.cpp/tools/rpc/README.md at master · ggml-org/llama.cpp · GitHub
【灵感来源】把旧电脑变成AI算力：llama.cpp RPC 局域网分布式推理验证与实战
极致省流：
archlinux游戏本一台，装载rtx4050M显卡。6G显存。安装cuda13.3
windows台式机一台，装载rtx5060ti显卡。16G显存。安装cuda13.3
-j16基于游戏本为13500H(4P+8E,12核16线程)，请读者酌情考虑散热条件选择。
Arch Linux worker
archlinux在/opt下clone https://github.com/ggml-org/llama.cpp/, 然后执行
mkdir build-rpc-cuda
cd build-rpc-cuda
cmake .. -DGGML_CUDA=ON -DGGML_RPC=ON -DCMAKE_BUILD_TYPE=Release
cmake --build . --config Release -j16
bin/ggml-rpc-server -H 0.0.0.0 -p 50052Windows host下载
.\llama-cli.exe -m "C:\Users\Yumei\Downloads\**.gguf" -ngl 99 --rpc 10.1.29.2:50052测得不连接游戏本
[ Prompt: 19.7 t/s | Generation: 15.4 t/s ]
连接游戏本后
[ Prompt: 4.4 t/s | Generation: 36.5 t/s ]
正片
1. 目标
我的目标是把一台带 NVIDIA GPU 的 Arch Linux 机器配置成 `llama.cpp` 的远程算力节点，然后在 Windows 主机上直接运行 `llama-cli` / `llama-server`，通过 RPC 调用远程 GPU 参与推理。
简单说就是：
- `worker` 机器负责提供 GPU 算力
- `host` 机器负责加载模型、发起推理、调度本地和远程设备
2. worker 端构建
在 Arch Linux 上，需要给 `llama.cpp` 打开 CUDA 和 RPC 后端：
```bash
mkdir build-rpc-cuda
cd build-rpc-cuda
cmake .. -DGGML_CUDA=ON -DGGML_RPC=ON -DCMAKE_BUILD_TYPE=Release
cmake --build . --parallel 8
这里有个坑：我一开始用了错误的构建命令：
cmake -j8 --build . --config Release报错如下：
CMake Warning:
Ignoring extra path from command line:
"Release"
CMake Error: Unknown argument --config原因是 Arch/Linux 下一般是单配置生成器，--config Release 不该放在 cmake --build 里，正确做法是：
- 配置阶段用
-DCMAKE_BUILD_TYPE=Release - 构建阶段用
--parallel 8或-j8开多线程
3. worker 端启动结果
编译完成后，ggml-rpc-server 成功启动，并识别到了 CUDA 设备：
ggml_cuda_init: found 1 CUDA devices (Total VRAM: 5799 MiB):
Device 0: NVIDIA GeForce RTX 4050 Laptop GPU, compute capability 8.9, VMM: yes, VRAM: 5799 MiB
Starting RPC server v4.0.3
endpoint : 127.0.0.1:50052
local cache : n/a
Devices:
CUDA0: NVIDIA GeForce RTX 4050 Laptop GPU (5799 MiB, 5656 MiB free)
transport : TCP (RDMA auto-negotiate enabled)这说明 worker 端本身已经没问题：
- CUDA 正常
- RPC 服务正常
- GPU 被正确枚举
4. host 端理解 RPC 的关键点
官方文档里“主机”和“远程主机”的说法一开始比较绕，实际可以简单理解成：
worker 是什么
worker 就是运行 ggml-rpc-server 的机器，只负责暴露 GPU 算力。
host 是什么
host 就是你真正执行 llama-cli 或 llama-server 的机器。它负责：
- 加载模型
- 调度推理
- 连接远程 worker
- 把一部分计算分发给远程 GPU
也就是说，worker 不跑模型主程序，只跑 RPC 服务；真正的推理入口还是在 host 上。
5. Windows 主机端启动命令
我这边主机模型路径是：
C:\Users\Yumei\Downloads\**.ggufworker IP 是：
10.1.29.2所以主机端命令应该是：
.\llama-cli.exe -m "C:\Users\Yumei\Downloads\**.gguf" -ngl 99 --rpc 10.1.29.2:500526. 遇到的核心问题
Windows 主机连接时报错：
Failed to connect to 10.1.29.2:50052这个错误不是模型问题，也不是 --rpc 参数问题，而是 worker 的监听地址问题。
因为从启动日志里能看到：
endpoint : 127.0.0.1:50052这表示 RPC 服务只监听本机回环地址，也就是只能本机自己连，局域网其他机器根本访问不到。
7. 最关键的修正
在 worker 端不能直接裸跑：
bin/ggml-rpc-server而应该显式绑定局域网地址，或者直接监听所有网卡：
bin/ggml-rpc-server -H 0.0.0.0 -p 50052或者：
bin/ggml-rpc-server -H 10.1.29.2 -p 50052启动后要确认输出类似：
endpoint : 0.0.0.0:50052或者：
endpoint : 10.1.29.2:50052只有这样，Windows 主机上的 llama-cli 才能真正连上这个 worker。
8. 排查思路
如果主机还是连不上，可以继续检查两步。
Windows 端测端口
Test-NetConnection 10.1.29.2 -Port 50052如果 TcpTestSucceeded 是 False，那就是网络或防火墙没有打通。
Arch 端看监听地址
ss -ltnp | grep 50052如果看到的还是：
127.0.0.1:50052说明服务还是只监听本地。
如果看到的是：
0.0.0.0:50052或者：
10.1.29.2:50052说明 worker 监听已经正确。
9. 这次折腾的结论
这次其实已经把最难的一步完成了：worker 成功编译并识别到 CUDA GPU。后面的主要问题不是编译，而是网络绑定和 host/worker 角色理解。
最终结论可以概括成 3 句话：
worker端要用-DGGML_CUDA=ON -DGGML_RPC=ON编译，并运行ggml-rpc-serverhost端运行llama-cli或llama-server，用--rpc IP:PORT连接远程 workerggml-rpc-server必须监听局域网地址，不能只绑127.0.0.1
10. 后续可以继续做什么
接下来如果继续完善，可以做这几件事：
- 验证 Windows host 成功连上 Arch worker
- 测试
llama-server的远程推理服务 - 观察远程 GPU 显存占用和推理吞吐
- 如果有多台 worker，再试
--rpc ip1:50052,ip2:50052 - 根据显存分配情况研究
--tensor-split
如果只总结一句话，这次最大的收获就是：RPC 模式下真正容易卡住的不是编译，而是服务监听地址和 host/worker 的职责理解。
更多推荐
5
0- 0
已为社区贡献1条内容
所有评论(0)