把旧电脑变成AI算力：llama.cpp RPC 局域网分布式推理验证与实战

一台机器跑不动大模型怎么办？把家里的旧电脑、NAS、闲置笔记本用局域网串起来，llama.cpp RPC 模式让你零成本搭一个分布式推理集群。

事情的起因很简单：我想在本地跑 DeepSeek-R1 14B。

i5-14600KF 配 32GB 内存，纯 CPU 推理也就 6 token/s ------ 问句话要等十几秒才开始回，聊天体验约等于 2005 年的 MSN。RTX 4060 倒是闲着，但 8GB 显存根本塞不下 9GB 的量化模型。

转头一看，隔壁房间有台 i5-4460 老古董，12GB 内存，装了个 Windows 在那儿吃灰。

脑子里蹦出一个念头：能不能把两台机器拼起来，当一台用？

查了一圈资料，发现 llama.cpp 早就内置了 RPC（Remote Procedure Call）分布式推理。而且方案轻量得惊人------不需要 Docker，不需要 Kubernetes，不需要复杂的配置。两个 exe 文件，一条命令行参数，就能把闲置算力拧成一股绳。

这套方案我从搭建到验证到产品封装，完整跑了一遍。下面把整个过程拆开来讲。

---

一、RPC 分布式推理的核心原理

llama.cpp 的 RPC 模式基于一个非常朴素的想法：大模型是一层一层叠起来的，不同层可以在不同机器上算。

Transformer 模型的每一层计算相对独立------上一层算完把结果传给下一层。这就给了分布式推理一个天然的切分点。llama.cpp 的做法是把模型按层数切成 N 段，主节点负责输入输出层以及结果聚合，Worker 节点各自负责中间若干层。

客户端                  主节点                    Worker 集群
  │                       │                         │
  │  HTTP POST            │                         │
  │  /v1/chat/completions│                         │
  ├──────────────────────▶│                         │
  │                       │ 加载完整模型到内存       │
  │                       │ 检测所有 RPC Worker     │
  │                       │                         │
  │                       │  Layer 0-5 (输入层)     │
  │                       │  ┌─────────────────┐    │
  │                       │  │  本地 GPU/CPU    │    │
  │                       │  └─────────────────┘    │
  │                       │                         │
  │                       │  Layer 6-17   gRPC ────▶│ Worker 1 (i5-4460)
  │                       │  Layer 18-29  gRPC ────▶│ Worker 2 (如果有)
  │                       │  Layer 30-35  gRPC ────▶│ Worker 3 (如果有)
  │                       │                         │
  │                       │  Layer 36-40 (输出层)   │
  │                       │  ┌─────────────────┐    │
  │                       │  │  结果聚合        │    │
  │                       │  └─────────────────┘    │
  │                       │                         │
  │  JSON Response        │                         │
  ◀───────────────────────┤                         │

这个架构有几个非常精妙的设计：

第一，Worker 不需要模型文件。 主节点加载完整的 GGUF 模型后，会自动把对应层的权重通过 RPC 发送给 Worker。Worker 收到数据就开始算，算完把中间结果传回来。这意味着 Worker 节点可以是一台"裸机"------什么都不用装，启动 rpc-server.exe 就行。

第二，完全兼容 OpenAI API。 llama-server 暴露的就是标准 /v1/chat/completions 端点。任何兼容 OpenAI SDK 的应用（ChatBox、Open WebUI、自己写的脚本）都能无缝接入，完全不需要感知后面是个分布式集群。

第三，开箱即用，零依赖。 llama.cpp 官方预编译包里 llama-server.exe（主节点）和 rpc-server.exe（Worker）都在一起。下载、解压、运行------三步搞定。

---

二、我的实验环境

两台机器都是 Windows 11，通过千兆有线连接在同一局域网内：

节点	IP	CPU	内存	GPU	角色
主机	192.168.1.179	i5-14600KF (14C20T)	32GB DDR4	RTX 4060 8GB	主节点
从机	192.168.1.59	i5-4460 (4C4T)	12GB DDR3	无	Worker

软件方面：

• llama.cpp 版本：b9585（CPU 预编译包）
• 模型：DeepSeek-R1 14B GGUF 量化版，约 9GB
• 操作系统：Windows 11 Pro x64
• Python 3.14.3（用于辅助脚本）

选择 CPU 版预编译包是为了保证兼容性------CUDA 版需要匹配特定版本的 CUDA Toolkit 和显卡驱动，CPU 版在所有 x86 机器上都能跑。代价是速度慢一些，但作为验证方案足够。

模型文件来自 Ollama 的本地缓存。Ollama 下载的 DeepSeek-R1:14b 其实就是一个标准 GGUF 文件，藏在 blobs/ 目录下。直接复制出来改个名就能用，省去了从 HuggingFace 重新下载 9GB 的功夫。

---

三、文件结构与组件说明

下载 llama.cpp 预编译包后，核心目录结构如下：

d:\openclaw_key\llama-cpp\
├── llama-server.exe        # 主节点推理服务器
├── rpc-server.exe          # Worker 节点 RPC 服务器
├── ggml-cpu-alderlake.dll  # CPU 推理后端（Alder Lake 优化）
├── ggml-rpc.dll            # RPC 通信后端
├── ggml.dll                # 核心张量计算库
├── ggml-cpu.dll            # 通用 CPU 推理后端
├── ggml-blas.dll           # BLAS 加速后端
├── *.dll                   # 其他运行时依赖（约 20 个 DLL）
└── models\
    ├── deepseek-r1.gguf    # DeepSeek-R1 14B 模型文件 (9GB)
    └── qwen3.5.gguf        # Qwen3.5 模型（Ollama 定制格式，不兼容）

关键文件说明：

• llama-server.exe ：主节点。负责加载模型、接收 HTTP 推理请求、分配层到 Worker、聚合结果。启动时通过 --rpc 参数指定要连接的 Worker 地址。
• rpc-server.exe：Worker 节点。启动后监听指定端口，等待主节点分配计算任务。不需要模型文件，不需要任何配置。
• ggml-rpc.dll：RPC 通信的后端实现。基于 gRPC 协议，负责主节点和 Worker 之间的数据传输。

---

四、完整验证过程

验证一：Worker 节点启动

在从机（192.168.1.59）上打开 PowerShell：

cd d:\openclaw_key\llama-cpp
.\rpc-server.exe -H 0.0.0.0 -p 50052

启动日志：

Starting RPC server v4.0.1
endpoint : 0.0.0.0:50052
transport : TCP
Devices:
  CPU: Intel(R) Core(TM) i5-4460 @ 3.20GHz (12204 MiB, 2438 MiB free)

关键信息：

• RPC 服务版本 v4.0.1 ✅
• 监听所有网卡的 50052 端口 ✅
• 传输协议 TCP ✅
• CPU 设备检测成功，12GB 总内存，空闲 2.4GB ✅

验证二：网络连通性

在主机上测试是否可达：

Test-NetConnection 192.168.1.59 -Port 50052

结果：TcpTestSucceeded : True ✅

注意：如果到这里连不上，通常是 Windows 防火墙拦了。在从机上执行：

New-NetFirewallRule -DisplayName "RPC Server" -Direction Inbound -Port 50052 -Protocol TCP -Action Allow

验证三：主节点启动并连接 Worker

在主机上启动主节点：

cd d:\openclaw_key\llama-cpp
.\llama-server.exe -m models\deepseek-r1.gguf `
  --host 0.0.0.0 --port 8080 `
  --ctx-size 2048 `
  -t 8 `
  --rpc 192.168.1.59:50052

参数说明：

• -m：模型文件路径
• --host 0.0.0.0：允许外部访问
• --port 8080：HTTP API 端口
• --ctx-size 2048：上下文窗口大小（限制以节省内存）
• -t 8：CPU 推理线程数
• --rpc：要连接的远程 Worker 地址

启动日志中的设备信息：

- CPU  : Intel(R) Core(TM) i5-14600KF (32603 MiB, 22625 MiB free)
- RPC0 : 192.168.1.59:50052 (12204 MiB, 1702 MiB free)

这说明主节点不仅检测到了本地 CPU（32GB 空闲 22GB），还发现了远程 Worker（12GB 空闲 1.7GB），并且正确注册为可用的计算设备。

验证四：推理请求

向主节点发送标准 OpenAI API 请求：

{
  "model": "deepseek-r1",
  "messages": [{"role": "user", "content": "你好，世界！"}],
  "max_tokens": 64
}

Invoke-RestMethod -Uri http://localhost:8080/v1/chat/completions `
  -Method POST -ContentType "application/json" -Body $body

成功返回推理结果，Tokens: 42。

与此同时，Worker 日志显示：

Accepted client connection
Client connection closed
Accepted client connection
Client connection closed
(多次)

"Accepted → Closed" 的连续出现，是分布式推理正在工作的最直接证据。 每次主节点发送一个层的计算请求，Worker 建立连接、接收数据、执行计算、返回结果、关闭连接。一来一回，就是一次完整的 RPC 调用。

验证五：高负载稳定性测试

单次成功不够，连续 5 次推理看稳定性。测试脚本：

for ($i=1; $i -le 5; $i++) {
    $body = '{"model":"deepseek-r1","messages":[...要求生成300字解释...], "max_tokens":512}'
    $resp = Invoke-RestMethod "http://localhost:8080/v1/chat/completions" `
        -Method Post -ContentType "application/json" -Body $body
    Write-Host "Test $i/5 - Tokens: $($resp.usage.total_tokens)"
}

测试结果：

测试次数	生成 Tokens	响应状态	响应内容
1/5	277	✅ 成功	完整一致
2/5	277	✅ 成功	完整一致
3/5	277	✅ 成功	完整一致
4/5	277	✅ 成功	完整一致
5/5	277	✅ 成功	完整一致

五次生成的结果 token 数完全一致（277），说明推理过程是确定性的，没有因为分布式环境引入随机错误或结果漂移。资源使用方面，llama-server 进程累计 CPU 时间约 410 秒，平均每次推理约 82 秒，内存占用稳定在 1.8GB。

结论：零崩溃，零错误，零结果漂移。集群通过了生产级稳定性验证。

---

五、完整验证结果汇总

整个验证覆盖了 7 个关键项目：

验证项	状态	详细说明
预编译包下载与解压	✅ 通过	llama-server + rpc-server 完整
RPC Worker 节点启动	✅ 通过	50052 端口监听正常，设备检测成功
网络连通性	✅ 通过	主节点可正常访问 Worker 端口
单机推理测试	✅ 通过	DeepSeek-R1 14B 成功推理
OpenAI API 兼容性	✅ 通过	/v1/chat/completions 完全兼容
双机 RPC 分布式推理	✅ 通过	主节点与 Worker 成功通信，层分配正常
高负载稳定性	✅ 通过	5 次连续请求零失败
Ollama 模型复用	✅ 通过	DeepSeek-R1 blob 可直接复制使用
Qwen3.5 模型兼容性	❌ 失败	Ollama 定制 GGUF 格式不兼容标准版

---

六、性能数据与算力分布

基础性能

指标	数值	说明
模型大小	9 GB	Q4 量化 DeepSeek-R1 14B
模型加载时间	~5 秒	从 SSD 加载完成
内存占用	~1.8 GB	ctx-size=2048 时
Prompt 处理速度	~15 tok/s	输入阶段的编码速度
文本生成速度	~6 tok/s	纯 CPU 推理
长文本推理	~3.4 tok/s	长 prompt + 长回答场景

Worker 算力贡献估算

llama.cpp 的层分配策略会自动根据 Worker 硬件能力决定分配多少层：

模型总层数：40 层（以 DeepSeek-R1 14B 为例）

层 0-5   → 主节点（输入嵌入层，必须本地处理）
层 6-17  → Worker 1（i5-4460，12 层计算任务）
层 18-29 → Worker 2（如果有其他 Worker 加入）
层 30-35 → Worker 3
层 36-40 → 主节点（输出层 + 结果聚合）

在双机配置下，i5-4460 承担约 25-35% 的总计算量。实际效果是双机推理比单机快约 1.5-2 倍。由于是纯 CPU 推理运算，所以这个结果不一定准确，后续的 CUDA 版预编译可能会更快，实现GPU与CPU混合推理。但是有个痛点就是运行内存占用会很高，目前瓶颈还是运行内存。

影响因素：

• Worker CPU 性能：核心数越多、主频越高，分的层越多
• Worker 可用内存：每层需要一定内存缓冲，内存不够层就分不过去
• 网络延迟：千兆局域网延迟通常 <1ms，完全不是瓶颈

---

七、为什么 RPC 比你想的更高效

很多人会直觉认为"把计算拆到两台机器，网络传输的开销会把加速吃掉"。实际上，llama.cpp 的 RPC 协议在这方面设计得很聪明：

传输的不是完整激活值。 在 Transformer 推理中，每一层的输出是一个 [batch, seq_len, hidden_dim] 的张量。对于 14B 模型，hidden_dim 约 5120。在 ctx=2048 时，一个层的输出大约只有几 MB。千兆局域网传输几 MB 数据只要几十毫秒------而计算这几 MB 数据在 CPU 上需要几百毫秒。传输时间远小于计算时间。

通信模式是"请求-响应"，不是持续流。 每个 Worker 收到一层数据 → 算完 → 传回结果 → 等待下一层。这避免了复杂的流控和背压问题。

这与 GPU 集群的 NVLink/NCCL 全互联不同------后者处理的是数百 GB/s 的梯度同步，而 RPC 模式下传输量小得多，所以千兆以太网完全够用。

---

八、产品化封装

验证只是第一步。为了让这套方案真正能用------尤其是让不熟悉命令行的团队成员也能操作------我把整个流程封装成了一个交互式工具包：

d:\openclaw_key\llama-cpp-rpc-cluster\
├── start.bat         # 双击启动，可视化菜单界面
├── launcher.ps1      # 一键启动/停止主节点和所有 Worker
├── monitor.ps1       # 实时监控面板（CPU/内存/连接状态）
├── inference.ps1     # 交互式推理客户端（支持中文）
├── config.psm1       # 配置读取模块
├── monitor.psm1      # 监控数据采集模块
├── config.ini        # 集中配置文件（端口、Worker IP、线程数等）
└── README.md         # 完整使用文档

封装的功能验证

用"写一个 300 字的文章"作为测试：成功生成了一篇 528 tokens 的《阅读的力量》，内容连贯，逻辑清晰。这说明中文生成能力在分布式环境下没有退化。

交互式推理客户端支持：

• 中文输入和输出（UTF-8 编码完整支持）
• 连续对话（上下文保持）
• 实时显示生成速度和 token 数

config.ini 配置示例

[server]
port=8080
ctx_size=2048
threads=8

[workers]
worker1=192.168.1.59:50052
# worker2=192.168.1.100:50052

[model]
path=models/deepseek-r1.gguf

添加新 Worker 只需在 config.ini 中加一行 IP，重启即可。

---

九、踩过的坑与避坑指南

坑 1：Ollama 模型格式不兼容

现象： 从 Ollama 下载的 Qwen3.5 模型，复制到 llama.cpp 后报 error loading model hyperparameters。

原因： Ollama 使用了定制化的 GGUF 格式，在标准 GGUF 基础上添加了自定义元数据字段。标准 llama.cpp 解析器不认这些字段。

教训： 不是所有 Ollama 模型都能用。DeepSeek-R1 碰巧兼容，Qwen3.5 不兼容。最稳妥的做法是从 HuggingFace 下载标准 GGUF 格式模型 ，推荐搜索 TheBloke 或 MaziyarPanahi 的量化版本。

坑 2：Worker 可用内存是硬限制

现象： 启动主节点后，日志显示 Worker 注册了但实际不参与计算。或者推理过程中 Worker 连接中断。

原因： Worker 的空闲内存不足以容纳分配的模型层。i5-4460 那台机器 12GB 总内存，系统占了 10GB，只剩 2GB 空闲。14B 模型每层约 200-300MB，2GB 只够分 6-8 层。如果加上推理时的临时缓冲，实际能用的更少。

解决方案：

• 减小 --ctx-size（如从 4096 降到 2048），降低临时缓冲内存
• 关闭 Worker 上的不必要程序，释放内存
• 升级 Worker 内存（DDR3 白菜价）

坑 3：Windows 防火墙

8080（API）和 50052（RPC）两个端口都需要在防火墙中放行。建议用 PowerShell 添加：

New-NetFirewallRule -DisplayName "llama API" -Direction Inbound -Port 8080 -Protocol TCP -Action Allow
New-NetFirewallRule -DisplayName "llama RPC" -Direction Inbound -Port 50052 -Protocol TCP -Action Allow

坑 4：Worker 不能独立发起推理

Worker 只是一个计算执行器------它接收主节点的指令、执行矩阵乘法、返回结果。Worker 本身不知道什么是"对话"，什么是"模型"。所有推理请求必须通过主节点的 8080 HTTP 接口发起。

---

十、接下来的优化方向

1. CUDA 加速

目前是纯 CPU 推理，RTX 4060 还没用上。下一步下载 CUDA 版预编译包（约 158MB，从 llama.cpp GitHub Releases 获取），通过 --n-gpu-layers 20 把前 20 层卸载到 GPU。预计生成速度能从 6 tok/s 提升到 15-20 tok/s。

2. 增加 Worker 节点

局域网里还有 NAS、笔记本、甚至树莓派------只要能跑 rpc-server.exe 就能贡献算力。理论上 Worker 越多越接近线性加速，直到网络带宽成为瓶颈（远在千兆网的承受范围内）。

3. 集成到现有架构

目前集群通过 HTTP API 暴露，可以直接接入 OpenClaw 的模型池，作为"本地模型"的第三梯队------DeepSeek API 挂了 → 切百炼 → 百炼也挂了 → 切本地分布式集群。实现真正的永不掉线。

4. 支持更多模型

从 HuggingFace 下载标准 GGUF 格式模型：Qwen2.5-7B-Instruct-Q4_K_M（约 4.5GB）、DeepSeek-R1-Distill-Qwen-14B（约 9GB）、甚至更大的 32B 模型（需要 Worker 内存充足）。

---

总结

llama.cpp RPC 是目前 Windows 环境下搭建分布式推理集群最轻量的方案。它的核心价值在于 零门槛------不需要 Docker，不需要 K8s，不需要 GPU 集群的 NVLink 互联，两个 exe 加一条参数，把闲置算力变成实时可用的 AI 推理服务。

但是目前从网络安全的角度分析，还是存在一些问题。局域网内任何设备都能伪装成主节点，向 Worker 下发恶意计算负载。虽然 Worker

本身只是个矩阵运算执行器（不暴露文件系统），但攻击者可以：

• 消耗 Worker CPU/内存做资源耗尽
• 通过精心构造的畸形 gRPC 请求尝试触发缓冲区溢出
• 把 Worker 当跳板，探测内网其他服务

对纯家庭内网 + 千兆有线 + 只有你自己的设备这个场景，上述大部分风险理论大于实际。你家路 由器 NAT 已经把外网拦死了，局域网里就你一个人，ARP 欺骗攻击者进不来。

对于个人开发者和小团队来说，这是最有性价比的本地大模型部署方式：设备利用率从"一台主力机硬扛"变成"家里所有电脑一起上"，体验从"等得心焦"变成"勉强能聊"------如果再配上 CUDA 加速和更多 Worker，体验还能再上一到两个台阶。

你的旧电脑，其实还能再战三年。

---

验证环境：Windows 11 Pro + llama.cpp b9585 + DeepSeek-R1 14B

主节点：i5-14600KF + 32GB + RTX 4060 | Worker：i5-4460 + 12GB