1. 为什么要在自己设备上跑本地 AI1.1 从 Potluck 这个项目说起第一次看到 Potluck 这个标题的时候我的直觉是终于有人把我手头这几台破电脑能不能凑一起跑个大模型这件事做成一个正经项目了。它的核心主张很朴素——把你拥有的电脑台式机、笔记本、甚至闲置的迷你主机通过网络连起来让它们协同完成一次本地 AI 推理。不是租云 GPU不是买一张 4090而是把已有的算力榨干。这件事为什么值得聊因为过去两年本地 AI 的门槛被两件事卡住了。第一是显存一个 7B 模型 FP16 要 14GB 左右显存量化到 4bit 也要 4-5GB很多轻薄本根本装不下。第二是单机算力即便模型塞得进去token 生成速度也慢到没法用。Potluck 这类项目的思路是既然单机不够那就横向扩展把多台机器的 CPU、GPU、内存拼成一个逻辑上的算力池。它适合谁我梳理了三类人。一类是手里有两三台旧电脑、想折腾点东西的爱好者一类是预算有限但想跑私有模型的学生和独立开发者还有一类是对数据隐私敏感、不希望推理请求离开自己局域网的人。这三类人的共同点是不追求极致性能但要求能跑起来、数据不出门、成本可控。1.2 本地推理和云端推理的真实差距很多人一上来就问本地跑和调 API 到底差多少我实测下来的结论是差距不在能不能用而在什么场景下值得。云端 API 的优势是开箱即用、按量付费、模型随便换本地推理的优势是零边际成本、数据不出本地、断网可用、可以随便折腾量化版本。举个具体数字。一台带 RTX 4060 Laptop GPU8GB 显存的笔记本跑 Qwen2.5-7B 的 4bit 量化版本大概能到 30-40 tokens/s这个速度日常对话完全够用。但如果换成 14B 模型显存直接爆掉只能靠 CPU 卸载offload速度掉到 3-5 tokens/s体验就很差了。这时候 Potluck 的价值就出来了如果我有两台这样的笔记本把 14B 模型按层切分到两台机器上每台只负责一部分层理论上就能把速度拉回到可用区间。注意分布式推理不是简单的112。网络传输、同步开销、负载均衡都会吃掉一部分收益。跨机器跑推理实际加速比通常在 1.3-1.8 倍之间而不是 2 倍。这一点后面会详细拆。1.3 这篇文章会讲什么我不打算只复述 Potluck 的 README。我会从它背后的技术栈讲起——local inference 的几种主流切分策略、CPU 和 GPU 在其中的角色分工、网络层怎么设计、量化怎么选。然后给出一套我自己验证过的多机部署流程包括环境准备、模型切分、参数配置、性能调优。最后是踩坑记录这部分是我觉得最有价值的地方因为分布式推理的坑官方文档基本不会写。如果你手头正好有两台以上的电脑或者你对 local AI 的横向扩展感兴趣这篇内容应该能帮你省下不少试错时间。2. 分布式本地推理的核心技术拆解2.1 模型并行 vs 流水线并行两种切法怎么选要把一个大模型拆到多台机器上绕不开两个概念模型并行tensor parallelism和流水线并行pipeline parallelism。这两个词听起来很学术但用生活化的方式解释就很好懂。模型并行好比一道菜需要切菜、炒菜、装盘三个步骤但每个步骤都由不同的人同时做——切菜的人切好一批就传给炒菜的人炒菜的人炒好就传给装盘的人。对应到模型上就是把一个矩阵乘法拆成几块每台机器算一块然后汇总结果。这种方式的优点是负载均衡好缺点是通信极其频繁每一层都要同步对网络带宽要求很高。千兆局域网基本扛不住万兆或者 Thunderbolt 直连才比较现实。流水线并行好比一条流水线第一台机器负责模型的前几层算完把中间结果activation传给第二台第二台算中间几层再传给第三台。这种方式通信量小得多因为只在层与层之间传一次数据而不是每个算子都同步。缺点是会有气泡——第一台机器算的时候后面的机器在等等第一台算完第二台开始算第一台又闲下来了。所以流水线并行需要靠 micro-batch 来填满气泡。Potluck 这类面向消费级设备的项目通常会优先选择流水线并行原因很直接家用网络环境Wi-Fi、千兆网线的带宽和延迟撑不起模型并行那种高频通信。我实测过在千兆局域网下做 tensor parallelism通信开销能占到总时间的 40% 以上得不偿失。对比维度模型并行流水线并行通信频率每层多次每层一次带宽要求极高万兆以上中等千兆可接受负载均衡好需要 micro-batch 调优实现复杂度高中适合场景同机多卡多机异构2.2 CPU 和 GPU 在推理中的分工热词里反复出现 CPU 天梯图、GPU 计算、kernel 算子这些词说明大家对硬件分工很关心。在本地推理里CPU 和 GPU 的角色其实很清晰。GPU 负责的是矩阵乘法和注意力计算这类高度并行的算子。一个 transformer 层里绝大部分 FLOPs 都集中在这些地方。GPU 的几千个 CUDA 核心可以同时处理大量乘加运算这是它快的原因。但 GPU 的短板是显存有限而且显存和计算单元之间的带宽是瓶颈——这就是所谓的memory wall。CPU 负责的是调度、tokenization、采样、以及当显存不够时的卸载计算。所谓 offload就是把一部分层或者一部分权重放在内存里需要的时候再搬到 GPU 算。这个搬运过程走 PCIe 总线速度远低于显存内部带宽所以 offload 一多速度就断崖式下跌。在 Potluck 这种多机场景下分工会更复杂一层。每台机器内部有自己的 CPU-GPU 分工机器之间还要通过网络传 activation。所以一个合理的配置策略是让每台机器尽量把能塞进显存的层都塞进去塞不下的才 offload 到 CPU同时尽量让各台机器的负载均衡避免某台机器成为瓶颈。实操心得判断一台机器适不适合加入算力池先看它的显存。8GB 显存大概能扛 7B 模型的 4bit 量化12GB 能扛 13B 的 4bit24GB 能扛 32B 的 4bit。如果显存低于 6GB这台机器基本只能做 CPU 推理加进来反而拖慢整体速度。2.3 量化让模型塞进消费级硬件的关键不聊量化本地推理就是空谈。量化的本质是用更少的比特来表示权重牺牲一点精度换显存和速度。主流的量化方案有几种我按实际使用体验排个序。GGUF 格式llama.cpp 生态是目前消费级设备上最实用的。它支持 2bit 到 8bit 的多种量化等级而且 CPU 和 GPU 混合推理做得很好。Q4_K_M 是我最推荐的档位4bit 量化精度损失很小显存占用只有 FP16 的四分之一左右。Q5_K_M 精度更好但显存多占 25%Q3_K_M 更省显存但精度开始明显下降。GPTQ 和 AWQ 是 GPU 专用的量化方案需要显卡支持。它们的优势是推理速度快因为可以直接用 GPU 的 int4 计算指令。但缺点是灵活性差模型必须完整加载到显存不能像 GGUF 那样灵活 offload。在 Potluck 的多机场景下我倾向于推荐 GGUF因为它对异构硬件的容忍度最高。你可能有台机器是 N 卡有台是 A 卡有台只有核显GGUF 都能跑只是速度不同。而 GPTQ/AWQ 对硬件一致性要求高混搭容易出问题。2.4 网络层设计机器之间怎么对话多机推理的网络层核心要解决三个问题发现、传输、容错。发现是指机器之间怎么找到彼此。最简单的方案是手动配置 IP 列表每台机器启动时读取配置文件知道其他节点的地址。进阶方案是用 mDNS 或者自定义的发现协议自动扫描局域网内的节点。Potluck 这类项目通常会提供手动配置作为保底自动发现作为可选。传输是指 activation 怎么传。这里有个关键选择用 TCP 还是 RDMA。TCP 通用性好任何网络都能跑但延迟高、CPU 占用大。RDMA 需要专用网卡延迟低、CPU 占用小但硬件门槛高。家用场景基本只能用 TCP所以优化重点在于减少传输数据量和压缩。容错是指某台机器掉线了怎么办。分布式系统里节点故障是常态。一个健壮的实现应该有超时检测和降级策略——比如某台机器 5 秒没响应就把它标记为不可用重新分配层到其他机器。如果做不到动态重分配至少要让整个推理任务优雅失败而不是卡死。3. 多机部署实操从零搭一个算力池3.1 环境准备与依赖安装假设你手头有两台机器我以最常见的组合为例一台带 RTX 4060 Laptop8GB 显存的笔记本一台带核显的台式机。目标是跑一个 14B 的 4bit 量化模型。第一步是统一环境。两台机器都要装 Python 3.10 或 3.11不要用 3.12因为部分推理库还没适配。然后装 PyTorch这里要注意版本匹配。带 N 卡的那台装 CUDA 版本核显那台装 CPU 版本。# 带 N 卡的机器 pip install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/cu121 # 只有 CPU 的机器 pip install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/cpu装完之后验证一下。N 卡机器上跑python -c import torch; print(torch.cuda.is_available())应该输出 True。CPU 机器上同样命令输出 False 是正常的。然后是推理框架。如果用 llama.cpp 生态直接编译或者下载预编译版本。如果用 Python 生态的分布式方案需要装对应的库。这里我建议先用 llama.cpp 的 RPC 模式做验证因为它对多机的支持相对成熟配置也简单。网络方面确保两台机器在同一局域网能互相 ping 通。如果走 Wi-Fi尽量用 5GHz 频段2.4GHz 的带宽和延迟都很糟糕。有条件的话拉一根网线稳定性提升非常明显。3.2 模型切分策略与参数计算模型切分是整个过程里最需要动脑子的部分。核心问题是14B 模型4bit 量化后大概 8-9GB怎么分到两台机器上先算显存。带 4060 的笔记本有 8GB 显存但系统和其他程序会占用 1-1.5GB实际可用 6.5GB 左右。核显台式机没有独立显存只能用系统内存假设有 16GB 内存可用 12GB 左右。如果按层平均分每台机器承担 7B 左右的权重。笔记本的 6.5GB 显存装不下 7B 的 4bit约 4GB 权重加 KV cache 和中间激活勉强能塞但会很紧张。台式机用内存跑 7B 的 4bit速度会很慢。更合理的策略是让笔记本承担大部分层比如 60%因为它有 GPU 加速台式机承担剩余 40%纯 CPU 跑。这样笔记本的显存压力大一些但整体速度更快。具体切分点需要根据实测调整一般从 50/50 开始然后往 GPU 强的机器倾斜。KV cache 也要算进去。14B 模型如果上下文长度设 4096KV cache 大概占 1-2GB。这部分也要分摊到各机器上。如果显存实在紧张可以把上下文长度降到 2048KV cache 减半。注意切分点不是随便定的最好切在 transformer 层的边界上。有些实现要求切分点对齐到 attention 层或 FFN 层的边界切在中间会导致计算错误。配置前先看框架文档对切分粒度的要求。3.3 启动流程与配置示例假设用 llama.cpp 的 RPC 模式流程大概是这样的。先在台式机作为 server 节点上启动 RPC 服务./rpc-server -H 0.0.0.0 -p 50052然后在笔记本上启动主程序指定模型路径和 RPC 节点./llama-cli -m models/qwen2.5-14b-q4_k_m.gguf \ --rpc 192.168.1.100:50052 \ -ngl 99 \ -c 4096 \ -n 512这里的参数含义-ngl 99表示尽可能多的层放到 GPU-c 4096是上下文长度-n 512是最大生成 token 数。--rpc指定远程节点地址。启动后观察日志看层是怎么分配的。如果发现所有层都堆在本地远程节点没被用上说明配置有问题。正常情况下应该能看到类似 assigned layers 0-20 to local, 21-40 to remote 的日志。第一次跑建议先用小模型验证流程比如 3B 的模型确认多机通信正常后再换大模型。这样出问题容易定位。3.4 性能调优让速度再快一点跑通之后接下来就是调优。我总结了几个有效的方向。第一是调整切分比例。用--tensor-split参数可以指定各节点的权重比例。比如--tensor-split 6,4表示本地 60%、远程 40%。多试几组找到速度最快的组合。我实测下来让 GPU 强的机器多承担一些通常能提升 15-20% 的速度。第二是开批处理。如果框架支持 continuous batching把-b参数调大比如 512 或 1024。这样多个请求可以并行处理吞吐量提升明显。但要注意显存占用也会增加。第三是优化网络。如果两台机器都有 Thunderbolt 接口用 Thunderbolt 网桥直连延迟能降到 1ms 以下比千兆网线快很多。没有的话至少确保走有线而不是 Wi-Fi。第四是调整线程数。CPU 推理时线程数设成物理核心数不要设成逻辑核心数。比如 8 核 16 线程的 CPU设 8 而不是 16。超线程在推理场景下反而会拖慢速度因为缓存竞争。调优项默认值推荐值预期收益tensor-split平均GPU 侧倾斜15-20%batch size512102420-30% 吞吐网络Wi-Fi有线/Thunderbolt30-50% 延迟降低CPU 线程逻辑核心物理核心10-15%4. 踩坑记录与问题排查4.1 常见报错与解决思路分布式推理的报错信息往往很晦涩我整理了几个高频问题。问题一连接超时。启动时提示 failed to connect to RPC server。先检查防火墙Linux 上用ufw status看规则Windows 上检查入站规则。然后确认 IP 和端口没写错用telnet 192.168.1.100 50052测试连通性。如果 telnet 不通就是网络层的问题跟推理框架无关。问题二显存溢出。提示 CUDA out of memory。这时候要降低-ngl的值让更多层 offload 到 CPU。或者减小上下文长度或者换更激进的量化等级。我遇到过一种情况是 KV cache 没算进去模型权重塞得下但一推理就爆后来把-c从 8192 降到 4096 就好了。问题三输出乱码或重复。这通常是切分点不对导致的。检查切分是否对齐到层边界或者尝试换一个切分比例。还有一种可能是量化版本和框架版本不匹配比如用新版 llama.cpp 加载旧版量化的模型会出现解析错误。问题四速度异常慢。如果比单机还慢说明网络开销吃掉了并行收益。用iftop或nload看网络流量如果持续跑满带宽说明传输量太大需要减少跨机传输的数据。另一个可能是某台机器成了瓶颈用htop看各机器的 CPU 和 GPU 利用率找出拖后腿的那台。4.2 那些文档不会告诉你的细节第一个细节机器性能差异太大会拖慢整体。我试过把一台老笔记本4 代 i5和一台新台式机12 代 i7组池结果老笔记本成了瓶颈整体速度比单用台式机还慢。后来把老笔记本踢出去速度立刻上来了。所以组池的机器性能差距不要超过两代。第二个细节内存频率对 CPU 推理影响很大。DDR4 2400 和 DDR5 6000在 CPU 推理场景下速度能差 40% 以上。因为 CPU 推理是内存带宽瓶颈不是计算瓶颈。如果你的机器支持内存超频开 XMP 能白捡不少性能。第三个细节模型加载时间。多机加载大模型如果每台机器都从磁盘读一遍启动会很慢。可以把模型放在共享存储上或者用内存映射mmap方式加载减少重复 IO。llama.cpp 默认用 mmap这个要确保开启。第四个细节温度墙和功耗墙。笔记本跑推理GPU 很快就会撞到温度墙降频。我实测 4060 Laptop 持续跑 10 分钟后频率从 2.1GHz 降到 1.5GHz速度掉了 30%。解决办法是垫高笔记本改善散热或者用nvidia-smi -pl限制功耗让频率稳定在一个较低但可持续的水平。4.3 什么情况下不值得折腾多机说了这么多多机的好处我也得泼盆冷水。有些情况下多机方案并不划算。如果你只有一台机器那没什么好说的老老实实单机跑。如果两台机器性能差距悬殊弱的那个基本是累赘。如果你的网络环境是 Wi-Fi 且信号不好多机通信的延迟会让你怀疑人生。如果你只是想偶尔跑一下模型配置多机的时间成本可能比直接用云服务还高。我的判断标准是当你单机跑某个模型速度低于 5 tokens/s且你手头有至少两台性能相近的机器且它们能走有线网络连接这时候多机方案才值得投入时间。否则要么换更小的模型要么接受慢速要么用云服务。实操心得先用单机把模型跑通记录 baseline 速度。然后加第二台机器对比速度变化。如果提升低于 20%说明多机方案在当前环境下不划算果断放弃。不要为了分布式而分布式。5. 本地 AI 算力池的更多可能性5.1 除了推理还能做什么算力池搭起来之后能做的事情不止推理。我试过几个有意思的方向。一个是批量任务处理。比如你有一批文档要做摘要单机跑要几个小时多机并行能缩短到几十分钟。这种场景下不需要模型并行而是数据并行——每台机器跑一个完整的模型处理不同的数据分片。实现起来比模型并行简单得多效果也更直接。另一个是模型微调。LoRA 微调对显存的要求比推理高单机可能跑不动。多机可以做数据并行微调每台机器处理不同的 batch然后同步梯度。不过这个对网络要求更高因为梯度同步的通信量比推理大得多。还有一个是作为本地服务。把算力池包装成一个 OpenAI 兼容的 API局域网内的其他设备手机、平板都能调用。这样你的旧电脑就变成了一个私有 AI 服务器数据完全不出本地。5.2 硬件选型的几点建议如果你打算认真搞一套本地算力池硬件选型有几个原则。GPU 优先看显存其次看算力。8GB 显存是入门线12GB 是舒适线24GB 是爽线。RTX 3060 12GB 是性价比很高的选择二手价格不贵显存够大。4060 Ti 16GB 也不错但价格高一些。CPU 优先看内存带宽和核心数。推理场景下内存带宽比核心数更重要。支持四通道内存的平台比如 HEDT 或者服务器平台会比双通道的快很多。核心数 8 核起步16 核更好。内存至少 32GB最好 64GB。因为 CPU offload 的层都放在内存里内存不够会直接 OOM。而且内存频率越高越好DDR5 6000 比 DDR4 3200 快不少。网络方面如果预算允许上 2.5G 或万兆网卡。千兆网卡在传输大 activation 时会成为瓶颈。Thunderbolt 直连是另一个好选择延迟低但需要两台机器都有接口。5.3 这个方向的未来走向本地 AI 算力池这个概念我觉得会越来越实用。原因是模型在变小变强量化技术在进步消费级硬件的算力也在涨。一年前 7B 模型是主流现在 14B、32B 的量化版本在消费级设备上也能跑了。另一个趋势是软件层的成熟。现在配置多机推理还很折腾要手动配 IP、调参数、处理各种报错。未来应该会有更傻瓜化的工具自动发现节点、自动切分模型、自动调优。Potluck 这类项目就是在往这个方向走。对于普通用户来说最实际的建议是先把单机跑顺理解量化和 offload 的基本原理然后再考虑多机。多机不是目的只是手段。真正的目标是让本地 AI 变得可用、好用而不是为了技术而技术。我在实际使用中的体会是本地 AI 最大的价值不是性能而是掌控感。你知道模型在哪、数据去哪、什么时候能用。这种掌控感是云服务给不了的。多机算力池只是把这种掌控感扩展到了更多设备上而已。