企业官网建设流程全解析

1. 为什么要在自己的设备上跑本地 AI

1.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 量化后约 7GB，INT4 量化后约 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 模型为例：

我的经验是：Q4_K_M 是甜点。它在 7B 模型上只增加约 1% 的困惑度，但模型大小只有 FP16 的 28%。对于多机场景，这意味着你可以把更多层放在 GPU 上，减少跨机传输。

加载模型时，Potluck 会先读模型的元数据，知道有多少层、每层多大、哪些层是注意力层、哪些是前馈层。然后根据设备能力表，决定每层放在哪台设备上。这个分配过程是贪心算法：先满足 GPU 设备，把计算量大的层优先分配过去；剩余层再分给 CPU 设备。

3.3 推理流水线的搭建与调试

流水线搭建的核心是层分配表。假设模型有 32 层，你有三台设备：设备 A 有 RTX 4060（8GB 显存），设备 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。如果每层都传 4MB，32 层就是 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_TYPE=Release -DPOTLUCK_USE_CUDA=ON make -j$(nproc) sudo make install

Windows 端直接下载 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: GPU=RTX 4060 Laptop (8GB), CPU=16 cores, RAM=32GB desktop-01: GPU=Intel UHD (shared), CPU=8 cores, RAM=16GB [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 100

Potluck 会打印每个 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.x），mDNS 广播无法跨子网。需要配置 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 常见问题速查表

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 强得多。而且一旦搭好，这套环境可以反复使用，跑各种模型，试各种量化级别，学习成本摊薄后非常划算。

最后再分享一个小技巧：如果你有两台配置相同的设备，可以试试对称分配层，让每台设备跑一半的层。这样流水线最均衡，气泡最小。如果配置不同，就按算力比例分配，算力强的多跑几层。记住，流水线的瓶颈永远是最慢的那台设备，所以要么提升它，要么减少它的负担。