Potluck：用多台闲置设备组网跑本地AI推理的实战指南

1. 为什么要在自己的设备上跑本地 AI1.1 从“租算力”到“用闲算力”的转变过去两年大模型推理几乎被云端 GPU 服务器垄断。一张消费级显卡动辄上万租用云端算力按小时计费长期跑推理任务成本高得离谱。但实际情况是大多数个人开发者、小团队手里并不缺算力——你可能有一台带 RTX 4060 Laptop GPU 的游戏本、一台老旧的台式机、一台 Mac Mini甚至几台淘汰下来的办公电脑。这些设备平时 CPU 和 GPU 利用率长期低于 20%大部分时间在“摸鱼”。Potluck 这个项目瞄准的就是这个场景把你自己拥有的多台电脑组织起来共同跑本地 AI 推理。它不依赖云端不需要把数据传到别人的服务器上所有计算都在你手边的设备上完成。核心思路是“聚合闲散算力”而不是“购买更多算力”。这个方向之所以值得关注是因为它解决了一个真实痛点单台设备跑不动大模型但多台设备联合起来显存和算力就能拼凑出可用的推理能力。比如一台 8GB 显存的笔记本跑 7B 模型勉强够用但如果能把另一台 6GB 显存的台式机也拉进来就能尝试 13B 级别的模型或者用更高的量化精度跑 7B。1.2 适合谁来折腾这套方案Potluck 不是给“点一下就能用”的小白用户准备的。它适合以下几类人手里有多台电脑、对本地推理有需求、愿意花时间配置环境、能接受一定调试成本的开发者或技术爱好者。如果你只有一台设备或者对命令行操作完全陌生那这套方案可能不是最优解——直接装个 Ollama 或 LM Studio 更省事。但如果你符合以下任意一条Potluck 的思路就值得你花时间研究你有一台带独显的笔记本和一台核显台式机你在家里组了个小机柜有几台退役的迷你主机你需要处理敏感数据不能把内容发到云端你想学习分布式推理的底层原理而不只是调 API。注意本地推理的“本地”指的是计算发生在你拥有的设备上不经过第三方服务器。但这不意味着绝对安全——如果你的设备本身被入侵或者局域网内有恶意节点数据仍然可能泄露。安全边界取决于你的网络环境和设备管理能力。1.3 核心关键词拆解local AI、local inference、CPU、GPU这几个词看起来简单但组合在一起就构成了 Potluck 的技术底座。local AI指的是模型权重、推理引擎、输入输出数据全部在你自己的硬件上闭环不依赖外部 API。local inference强调的是推理过程本身在本地执行而不是训练——训练通常需要更大的显存和更长的周期推理则更关注延迟和吞吐。CPU和GPU在这里的角色分工很明确GPU 负责矩阵乘法、注意力机制等并行计算密集的部分CPU 负责调度、内存管理、数据预处理和后处理。Potluck 的巧妙之处在于它不要求所有设备都有 GPU——CPU 设备也能参与只是承担的任务类型不同。一台纯 CPU 的机器可以负责 tokenization、结果聚合、轻量级模型层而 GPU 设备负责重计算层。这种异构组网的能力是 Potluck 区别于传统单机推理方案的关键。它把“CPU 和 GPU 的连接”这个问题从主板内部扩展到了局域网层面本质上是在做分布式计算资源调度。2. Potluck 的整体设计与思路拆解2.1 为什么不做“单机多卡”而做“多机联合”单机多卡方案比如一张主板插两张 4090当然性能更好NVLink 或 PCIe 带宽远高于局域网。但它的门槛太高需要大功率电源、足够的 PCIe 插槽、良好的散热机箱成本直接翻倍。而且很多人的设备是笔记本根本没有扩展卡槽。Potluck 选择“多机联合”路线本质上是牺牲带宽换灵活性。局域网千兆以太网的带宽大约 125MB/s万兆能到 1.25GB/s而 PCIe 4.0 x16 的带宽是 32GB/s。差距是几十倍。但模型推理有一个特点层与层之间的数据传输量并不均匀。嵌入层和输出层的参数量相对小中间某些层的激活值也不大。如果切分策略得当跨机传输的数据量可以控制在可接受范围内。另一个考量是容错性。单机多卡一旦一张卡出问题整个推理任务就挂了。多机联合时如果某台设备掉线可以重新调度任务到其他节点或者降级运行。这对于“用闲散设备”的场景很重要——你的老台式机可能随时因为过热降频但整个系统不应该因此崩溃。2.2 推理任务的切分逻辑按层切还是按张量切分布式推理有两种主流切分方式流水线并行和张量并行。流水线并行是把模型的不同层分配到不同设备上比如设备 A 跑第 1-10 层设备 B 跑第 11-20 层数据像流水线一样依次流过。张量并行是把同一层的计算拆开比如一个矩阵乘法拆成四块四台设备各算一块再汇总。Potluck 更倾向于流水线并行原因很实际张量并行对通信带宽要求极高每次矩阵乘法都要同步中间结果千兆网络根本扛不住。流水线并行只在层与层之间传输激活值通信频率低得多。而且流水线并行更容易实现异构支持——GPU 设备跑计算密集的层CPU 设备跑轻量层各取所长。但流水线并行有个经典问题气泡。如果设备 A 算得快、设备 B 算得慢A 算完自己的层后要等 B这段时间 A 就闲置了。Potluck 的解法是动态调度把模型层切得更细让快设备多承担几层慢设备少承担几层尽量让各设备的完成时间接近。这需要运行时 profiling先跑一遍基准测试测出每台设备跑一层的时间再据此分配。2.3 内存与显存的管理策略本地推理最大的瓶颈往往不是算力而是内存。一个 7B 参数的模型FP16 精度下需要约 14GB 显存INT8 量化后约 7GBINT4 量化后约 3.5GB。如果你的设备显存不够就得把部分层放在 CPU 内存里用的时候再加载——这就是所谓的“offloading”。Potluck 在内存管理上做了几件事第一支持分层加载不需要一次性把整个模型读进显存第二支持量化格式的自动转换根据设备能力选择 FP16、INT8 或 INT4第三维护一个全局的内存视图知道每台设备还剩多少可用内存避免调度时把任务分配给已经满载的设备。这里有个容易踩的坑显存碎片。如果你频繁加载和卸载不同大小的层显存里会出现很多不连续的小块最终导致明明总剩余显存够用但就是分配不出一块连续空间。Potluck 的做法是预分配显存池把显存切成固定大小的块层加载时从池里取块卸载时归还。这牺牲了一点灵活性但换来了稳定性。2.4 网络通信层的设计取舍局域网通信有两个选择TCP 和 RDMA。RDMA 延迟低、CPU 占用少但需要专门的网卡和交换机支持普通家用环境根本没有。TCP 通用性强但协议栈开销大每次传输都要经过内核拷贝。Potluck 默认走 TCP但做了几个优化第一用零拷贝技术减少数据在用户态和内核态之间的搬运第二对激活值做压缩比如用 FP16 代替 FP32 传输或者用简单的行程编码压缩稀疏激活第三支持批量传输把多个小包合并成一个大包减少协议头开销。实测下来在千兆局域网里这些优化能把有效带宽利用率从 60% 提升到 85% 左右。虽然绝对带宽还是比不上 PCIe但对于流水线并行来说够用了。如果你家里有万兆网络那体验会好很多跨机传输几乎不会成为瓶颈。提示网络质量对多机推理的影响非常大。如果设备之间走 Wi-Fi延迟波动可能达到几十毫秒导致流水线气泡严重。强烈建议用有线连接哪怕只是千兆。3. 核心细节解析与实操要点3.1 设备发现与组网配置Potluck 启动后第一件事是发现局域网内的其他节点。它用的是 mDNS多播 DNS协议类似打印机和投屏设备的发现机制。每台运行 Potluck 的机器会广播自己的存在包括 IP 地址、可用内存、GPU 型号、当前负载等信息。其他节点收到广播后自动加入节点列表。这个过程不需要手动配置 IP但有几个前提条件所有设备必须在同一子网内防火墙要允许 mDNS 的 5353 端口和 Potluck 自己的通信端口如果有多网卡要指定用哪个网卡广播。我遇到过一台机器同时插了有线和无线网卡结果 mDNS 广播从无线网卡出去了导致有线设备发现不了它。解决办法是在配置文件里显式指定network_interface参数。节点发现之后Potluck 会做一次能力协商。每台设备上报自己的硬件信息CPU 核心数、内存大小、GPU 型号和显存、支持的指令集比如 AVX2、AVX-512。协调节点根据这些信息生成一个设备能力表后续调度都基于这张表。# potluck_config.yaml 示例 node: name: desktop-01 network_interface: eth0 listen_port: 7946 discovery: enabled: true interval_seconds: 10 resources: max_memory_gb: 32 max_vram_gb: 8 allow_cpu_fallback: true这个配置文件里allow_cpu_fallback是个关键开关。如果设为 true当 GPU 显存不够时Potluck 会把部分层放到 CPU 上跑。这会降低速度但能避免任务直接失败。对于“能跑就行”的场景建议打开。3.2 模型加载与量化选择Potluck 支持 GGUF、ONNX 和 PyTorch 三种模型格式。GGUF 是 llama.cpp 生态的格式量化选项丰富从 Q2_K 到 Q8_0 都有适合 CPU 和低显存 GPU。ONNX 跨平台性好但量化支持不如 GGUF 灵活。PyTorch 格式最灵活但需要自己处理量化和设备映射。选择量化级别时要平衡精度和资源占用。以 7B 模型为例量化级别每权重比特数7B 模型大小困惑度增幅适用场景FP1616~14GB基准显存充足追求最高质量Q8_08~7GB0.1%显存中等质量敏感Q5_K_M5.5~4.8GB0.5%平衡选择Q4_K_M4.5~4GB1.2%显存紧张可接受轻微降质Q3_K_M3.5~3GB3%显存严重不足Q2_K2.5~2.3GB8%仅应急质量明显下降我的经验是Q4_K_M 是甜点。它在 7B 模型上只增加约 1% 的困惑度但模型大小只有 FP16 的 28%。对于多机场景这意味着你可以把更多层放在 GPU 上减少跨机传输。加载模型时Potluck 会先读模型的元数据知道有多少层、每层多大、哪些层是注意力层、哪些是前馈层。然后根据设备能力表决定每层放在哪台设备上。这个分配过程是贪心算法先满足 GPU 设备把计算量大的层优先分配过去剩余层再分给 CPU 设备。3.3 推理流水线的搭建与调试流水线搭建的核心是层分配表。假设模型有 32 层你有三台设备设备 A 有 RTX 40608GB 显存设备 B 有 Intel UHD 核显共享内存设备 C 纯 CPU。一个可能的分配是设备 A第 1-16 层注意力层为主计算密集设备 B第 17-24 层前馈层计算量中等设备 C第 25-32 层 输出层轻量层 采样这个分配不是拍脑袋决定的。Potluck 会先跑一个微基准测试让每台设备单独跑几层测出每层的平均耗时。然后根据耗时比例分配层数目标是让每台设备的总耗时接近。如果设备 A 跑一层要 10ms设备 B 要 30ms那设备 A 应该分到大约三倍于设备 B 的层数。调试流水线时最常遇到的问题是某台设备成为瓶颈。表现是其他设备都在等它GPU 利用率上不去。排查方法是看 Potluck 的日志它会打印每层的执行时间和等待时间。如果某台设备的等待时间远大于执行时间说明它分到的层太多或者太重需要重新分配。另一个常见问题是首次推理特别慢。这是因为模型层需要从磁盘加载到内存再传到显存。Potluck 支持预热功能启动后先跑一次空推理把所有层加载到位后续推理就快了。预热需要额外时间但值得。3.4 跨设备数据传输的优化技巧跨设备传输的数据主要是激活值也就是上一层输出的张量。以 7B 模型为例隐藏层维度通常是 4096序列长度 512 时一个激活张量是 512×4096×2 字节FP16 4MB。如果每层都传 4MB32 层就是 128MB。千兆网络下传输 128MB 需要约 1 秒这还没算协议开销。优化手段有几个第一压缩激活值。很多激活值经过 ReLU 或 GELU 后是稀疏的可以用稀疏格式传输只传非零元素和索引。第二量化传输。把 FP16 激活值量化成 INT8 再传接收端反量化能减少一半带宽。第三重叠计算和传输。设备 A 算完第 1 层后立刻开始算第 2 层同时把第 1 层的输出传给设备 B。这样传输时间和计算时间重叠隐藏了部分延迟。Potluck 默认开启重叠传输但压缩和量化需要手动配置。我的建议是如果网络是千兆开启 INT8 传输量化如果是万兆可以关掉量化用 FP16 保证精度。注意激活值量化会引入额外误差可能影响生成质量。对于数学推理、代码生成等对精度敏感的任务建议关闭量化传输宁可慢一点。4. 实操过程与核心环节实现4.1 环境准备从零搭建多机推理集群假设你有两台设备一台是带 RTX 4060 Laptop GPU 的笔记本Windows 11一台是带 Intel UHD 核显的台式机Ubuntu 20.04。目标是让两台机器联合跑一个 7B 的 GGUF 模型。第一步在两台机器上安装 Potluck。Windows 端有预编译的二进制包Ubuntu 端需要从源码编译。编译依赖包括 CMake 3.20、GCC 11、CUDA Toolkit如果要用 GPU。Ubuntu 上还要装libmdns用于节点发现。# Ubuntu 端编译示例 git clone https://github.com/potluck-project/potluck.git cd potluck mkdir build cd build cmake .. -DCMAKE_BUILD_TYPERelease -DPOTLUCK_USE_CUDAON make -j$(nproc) sudo make installWindows 端直接下载 zip 包解压后把potluck.exe所在目录加入 PATH。然后创建配置文件指定模型路径、监听端口、网络接口。第二步下载模型。推荐从 Hugging Face 下载 GGUF 格式的模型比如TheBloke/Llama-2-7B-Chat-GGUF的 Q4_K_M 版本。下载后放到两台机器都能访问的共享目录或者各自放一份。如果模型文件太大可以用 NFS 或 SMB 共享避免重复下载。第三步启动节点。先启动台式机CPU 节点再启动笔记本GPU 节点。启动命令potluck serve --config potluck_config.yaml --model /path/to/model.gguf启动后Potluck 会打印节点发现日志。如果看到Discovered node: desktop-01和Discovered node: laptop-01说明组网成功。4.2 模型切分与分配的实际操作节点发现完成后Potluck 会自动做能力协商和层分配。你可以在日志里看到分配结果[INFO] Device capability table: laptop-01: GPURTX 4060 Laptop (8GB), CPU16 cores, RAM32GB desktop-01: GPUIntel UHD (shared), CPU8 cores, RAM16GB [INFO] Layer assignment: laptop-01: layers 0-19 (20 layers) desktop-01: layers 20-31 (12 layers) [INFO] Estimated pipeline latency: 45ms/token这个分配结果是基于基准测试的。笔记本的 GPU 算力强分到更多层台式机核显弱分到较少层。如果对分配结果不满意可以手动覆盖。在配置文件里加一个layer_assignment段layer_assignment: laptop-01: [0, 19] desktop-01: [20, 31]手动分配适合你已经知道设备性能差异的情况。比如你发现台式机虽然核显弱但 CPU 有 AVX-512 指令集跑某些层反而比笔记本的 CPU 快那就可以多分几层给它。4.3 推理测试与性能基准分配完成后跑一个简单的推理测试potluck infer --prompt Explain the difference between CPU and GPU in one paragraph. --max-tokens 100Potluck 会打印每个 token 的生成时间和流水线各阶段的耗时。一个典型的输出Token 1: 120ms (pipeline fill) Token 2: 48ms Token 3: 45ms ... Token 100: 44ms Average: 46ms/token Throughput: 21.7 tokens/sec第一个 token 特别慢是正常的因为流水线需要填充。后续 token 稳定在 45ms 左右说明流水线运转正常。如果后续 token 时间波动很大可能是网络不稳定或者某台设备在跑其他任务。对比单机性能如果只用笔记本跑这个模型可能只有 15 tokens/sec。多机联合后提升到 21.7 tokens/sec提升约 45%。这个提升幅度取决于模型切分是否均衡以及网络延迟。4.4 长时间运行的稳定性调优跑短测试没问题不代表长时间运行稳定。我遇到过连续跑几小时后某台设备因为内存泄漏导致 OOM整个流水线崩溃。Potluck 有健康检查机制每 30 秒 ping 一次各节点如果某节点连续三次不响应就把它标记为不可用重新分配层到其他节点。但重新分配需要时间期间推理会中断。为了减少中断可以配置热备节点多准备一台设备平时不参与推理但保持模型加载状态。主节点故障时热备节点立刻接管。这需要额外硬件但对于生产环境值得。另一个稳定性问题是显存碎片。长时间运行后显存里会出现很多小块。Potluck 的显存池机制能缓解这个问题但如果你的模型层大小差异很大还是可能碎片化。解决办法是定期重启 Potluck 进程比如每天凌晨重启一次。虽然粗暴但有效。# 每天凌晨3点重启的 cron 示例 0 3 * * * systemctl restart potluck提示如果你的设备中有笔记本注意散热。长时间满载推理会让笔记本降频性能下降 20%-30%。把笔记本垫高、用散热底座或者限制 GPU 功耗到 80%能保持更稳定的性能。5. 常见问题与排查技巧实录5.1 节点发现失败怎么办节点发现失败是最常见的问题表现是 Potluck 启动后只看到自己看不到其他节点。排查步骤第一检查网络连通性。在台式机上 ping 笔记本的 IP看是否通。如果不通检查防火墙设置。Windows 防火墙默认会阻止入站连接需要手动放行 Potluck 的端口。第二检查 mDNS 是否工作。在 Linux 上可以用avahi-browse -a查看 mDNS 广播。如果看不到 Potluck 的服务说明 mDNS 没启动或者被阻止。有些企业网络会禁用多播这种情况下需要手动指定节点 IP。第三检查网卡选择。如果设备有多张网卡Potluck 可能选错了网卡。在配置文件里显式指定network_interface比如eth0或wlan0。第四检查子网掩码。如果两台设备在不同子网比如一台 192.168.1.x另一台 192.168.2.xmDNS 广播无法跨子网。需要配置 mDNS 反射器或者手动指定节点。5.2 推理速度远低于预期的排查思路如果多机推理速度比单机还慢说明流水线有问题。按以下顺序排查先看网络延迟。用ping测两台设备的往返延迟。如果延迟超过 5ms说明网络质量差。Wi-Fi 环境下延迟可能到 20ms 以上这会严重拖慢流水线。换成有线连接。再看层分配是否均衡。Potluck 日志会打印每台设备的执行时间和等待时间。如果某台设备等待时间占比超过 50%说明它分到的层太少其他设备在等它。手动调整层分配给慢设备减少层数。然后看是否有设备在跑其他任务。如果笔记本同时在看视频、下载文件GPU 和网络带宽会被占用。关掉不必要的后台任务。最后看模型量化是否合适。如果用了 Q2_K 这种极低量化虽然模型小了但推理时反量化开销大可能反而更慢。试试 Q4_K_M 或 Q5_K_M。5.3 显存不足与内存溢出的处理显存不足的表现是推理时报CUDA out of memory或failed to allocate。处理方法第一降低量化级别。从 Q5_K_M 降到 Q4_K_M模型大小减少约 20%。第二减少分给 GPU 的层数。把一些层移到 CPU 上跑虽然慢但不会 OOM。第三开启显存池。在配置文件里设置vram_pool_size预分配显存块避免碎片。第四关闭其他占用显存的程序。浏览器、视频播放器、游戏都会占显存。跑推理时尽量关掉。内存溢出OOM通常发生在 CPU 节点上。如果 CPU 内存不够Potluck 会尝试把层换出到磁盘但这会极慢。解决办法是减少 CPU 节点的层数或者增加物理内存。5.4 常见问题速查表问题现象可能原因排查方法解决方案节点发现失败防火墙阻止检查入站规则放行 Potluck 端口节点发现失败mDNS 被禁用avahi-browse -a手动指定节点 IP推理速度慢网络延迟高ping测试改用有线连接推理速度慢层分配不均查看等待时间手动调整层分配显存不足量化级别高查看模型大小降低量化级别显存不足显存碎片查看分配日志开启显存池推理中断节点掉线查看健康检查日志配置热备节点首次推理慢模型未预热查看加载日志开启预热功能生成质量差量化过度对比困惑度提高量化级别生成质量差激活值量化检查传输配置关闭激活值量化5.5 独家避坑经验分享第一个坑不要用 Wi-Fi 组网。我一开始图省事笔记本走 Wi-Fi台式机走有线。结果推理速度波动极大有时 20 tokens/sec有时掉到 5 tokens/sec。后来把笔记本也插上网线速度稳定在 22 tokens/sec。Wi-Fi 的延迟抖动对流水线并行是致命的。第二个坑模型文件不要放在网络共享盘上。我试过把模型放在 NAS 上两台机器都从 NAS 加载。结果首次加载花了 10 分钟因为 NAS 的读取速度只有 100MB/s而模型有 4GB。后来把模型复制到每台机器的本地 SSD加载时间降到 30 秒。第三个坑注意 CPU 的指令集。老 CPU 可能不支持 AVX2跑量化模型时速度极慢。在 Linux 上用lscpu查看支持的指令集。如果只有 SSE4.2建议只让它跑最轻量的层或者干脆不参与推理。第四个坑Windows 的电源管理会降频。笔记本在电池模式下GPU 功耗被限制性能下降一半。跑推理时一定要插电源并在电源选项里设置为“高性能”。第五个坑不要混用不同版本的 Potluck。我有一次笔记本用 0.3.0台式机用 0.2.5结果协议不兼容节点发现成功但推理时报序列化错误。所有节点必须用同一版本。6. 进阶玩法与扩展思路6.1 把手机也拉进推理集群Potluck 理论上支持任何能跑 Python 的设备包括手机。Android 手机可以通过 Termux 安装 Python 和 Potluck参与推理。但手机的算力和内存有限只能跑最轻量的层比如 embedding 层或输出层。而且手机的网络延迟通常比有线设备高可能成为瓶颈。实际测试下来把一台骁龙 8 Gen 2 的手机加入集群推理速度只提升了 3%但功耗增加了不少。除非你实在缺设备否则不建议把手机作为主力节点。不过如果你有一台闲置的旧手机让它跑 embedding 层把 GPU 设备解放出来跑注意力层还是有点意义的。6.2 结合 Kubernetes 做动态调度如果你有多台设备而且经常变化比如今天笔记本在明天台式机在可以用 Kubernetes 做动态调度。每台设备跑一个 Potluck 的容器Kubernetes 负责节点发现和健康检查。当某台设备离线时Kubernetes 自动把 Pod 调度到其他节点。但这套方案复杂度高适合已经有 K8s 集群的人。对于家庭环境Potluck 自带的节点发现和健康检查已经够用了。K8s 的优势在于可以结合 GPU 配额管理比如限制每个 Pod 使用的显存量避免一个任务占满所有资源。6.3 用 Potluck 跑微调任务Potluck 主要针对推理但也可以用来跑轻量级微调。比如 LoRA 微调只需要训练少量参数显存需求比全量微调小得多。你可以把 LoRA 适配器放在 GPU 设备上训练基础模型层分布在多台设备上。但微调的通信模式跟推理不同。推理是单向流水线微调需要反向传播梯度要在设备间同步。这对网络带宽要求更高。千兆网络下微调速度可能只有单机的 30%。万兆网络会好很多但依然不如单机多卡。我的建议是Potluck 适合推理微调还是用单机多卡或者云端算力。除非你的微调任务非常轻量比如只训练最后一层。6.4 监控与日志分析Potluck 提供了 Prometheus 格式的监控指标可以接入 Grafana 做可视化。关键指标包括每台设备的 GPU 利用率、显存占用、网络吞吐、推理延迟、队列长度。通过这些指标你能快速定位瓶颈。比如如果 GPU 利用率只有 30%但推理延迟很高说明瓶颈在网络或 CPU。如果 GPU 利用率 90% 以上但延迟还是高说明 GPU 算力不够需要换更强的卡或者降低量化级别。日志方面Potluck 默认输出 INFO 级别日志。调试时可以用--log-level debug输出更详细的信息包括每层的执行时间和数据传输量。但 debug 日志量很大长时间跑会占满磁盘记得配置日志轮转。# 日志轮转配置示例 logging: level: info file: /var/log/potluck.log max_size_mb: 100 max_files: 5这个配置会让 Potluck 最多保留 5 个 100MB 的日志文件超过就自动删除最旧的。对于长期运行的集群这是必须的。6.5 安全加固建议本地推理虽然不经过云端但局域网内的通信仍然需要保护。Potluck 支持 TLS 加密节点间通信但默认关闭。如果你的局域网内有不可信设备建议开启 TLS。开启方法是在配置文件里指定证书路径security: tls_enabled: true cert_file: /path/to/cert.pem key_file: /path/to/key.pem ca_file: /path/to/ca.pem证书可以用自签名的只要所有节点都信任同一个 CA 就行。开启 TLS 后节点发现和推理通信都会加密防止中间人攻击。另外Potluck 的 API 默认监听所有网卡。如果不想让局域网外访问可以绑定到127.0.0.1或者特定的内网 IP。在配置文件里设置listen_address: 192.168.1.10只接受来自该网卡的连接。我个人在实际操作中的体会是本地多机推理的乐趣在于“折腾”本身。你不需要一次成功可以慢慢调优看着推理速度从 10 tokens/sec 提升到 25 tokens/sec那种成就感比直接租云端 GPU 强得多。而且一旦搭好这套环境可以反复使用跑各种模型试各种量化级别学习成本摊薄后非常划算。最后再分享一个小技巧如果你有两台配置相同的设备可以试试对称分配层让每台设备跑一半的层。这样流水线最均衡气泡最小。如果配置不同就按算力比例分配算力强的多跑几层。记住流水线的瓶颈永远是最慢的那台设备所以要么提升它要么减少它的负担。