消费级硬件跑大模型：分布式部署与内存预算的博弈

当你在消费级硬件上运行大语言模型时，真正的瓶颈往往不是模型本身，而是内存。本文是《LLMs on Consumer Hardware》系列第五篇，讲述了一个关于内存争夺的现实故事：当协调者模型与工作模型挤在同一台机器上时，系统几乎崩溃；而通过“分布式部署”和“合理缩容”，问题迎刃而解。

从内存争夺到分布式破局

系列第四篇结尾遇到了一堵墙：那个值得运行的77GB协调者模型gpt-oss:120b，无法与其调用的工作模型共享一台机器。每次委派任务都会触发约100GB的模型交换，一个简单的问候都要耗时近五分钟。结论很明确：协调者与工作模型必须同时驻留内存。

第五篇的解决方案直截了当：让它们不再共享。作者将工作模型迁移到第二台机器上——一台配备GTX 1060的5600G主机。这样一来，主机的内存不再被争抢，协调者独享全部内存，交接过程中也不会被本地进程驱逐。

效果立竿见影。同一个120B模型，之前因频繁交换而变得不可用，现在加载一次后，在长达1小时46分钟的长时间运行中持续驻留，完全没有交换。摆脱交换惩罚后，它的编排可靠性甚至超过了Gemma。教训简单得令人泄气：协调者从来不是问题所在，它的位置才是。

这台第二主机实现了双重价值。第二篇中引入它，是因为其独立GPU能解决预填充问题——没有GPU的机器无法在合理时间内摄入大提示词。将工作模型迁移过去，又解决了另一个不相关的问题：为主机释放了协调者所需的内存。一个硬件决策，解决了两个约束。

闲置GPU带来的新租户

这个安排有一个关键副作用：120B模型远超16GB显存，因此主要运行在CPU和系统内存上——速度慢，约每秒9个token，但推理期间GPU几乎完全闲置。主机上的高性能显卡无事可做。

那个闲置的GPU是个邀请。作者在主机的6900XT上添加了本地图像生成（ComfyUI配合Stable Diffusion），让智能体能够生成图像，而不仅仅是文本和代码。单独运行时速度很快——一张SDXL图像大约15到30秒。

问题在于，主机现在有两个重量级租户。协调者占用约80GB内存中的77GB，图像生成需要GPU和几GB内存。GPU是空闲的——协调者没有使用它——但内存再次成为瓶颈。

ComfyUI 的 /free 接口与显存基线

ComfyUI 是基于节点图的 Stable Diffusion 前端，允许通过 API 工作流组合文本编码、采样和解码步骤。它提供 /free 端点，可主动卸载已加载的模型权重、清空显存中的缓存张量并触发 Python 垃圾回收。

默认情况下，生成完一张图后，SDXL 检查点、CLIP 文本编码器和 VAE 仍驻留显存，占用约 8GB。调用 /free 后，模型权重被释放，显存回落到仅剩 CUDA 运行时与少量工作缓冲的约 2.2GB 基线。这一机制使图像生成器能在不使用时对显存几乎零占用，从而与同样依赖系统内存的 CPU 推理协调者共存——前提是系统内存本身有余量。该策略降低了显存峰值，却无法降低系统内存需求：加载图像模型仍需要瞬时分配数 GB 的 RAM。

共存实验：一个看似合理的假设

值得测试而非猜测，因为有一个看似合理的论点支持共存。在委派任务期间，协调者处于空闲状态：它已将任务交给远程工作模型，正在等待。空闲内存页可以廉价换出，只有活跃使用的内存才会导致颠簸。原则上，Linux应该能够将等待中的协调者换出，让图像生成使用释放的内存，然后在协调者恢复时一次性换回。一个空闲的租户应该是好邻居。

测试前设置了两道保障：图像生成器的内存守护，如果空闲内存低于8GB就拒绝启动——干净地失败，而不是让机器陷入交换死机；以及通过ComfyUI的/free在每张图像后自动卸载，真正释放模型并将显存从约8GB降至2.2GB基线。然后禁用守护，加载120B模型，启动多图像运行，同时监控free -h和vmstat。

假设失败了。120B驻留时，只有约3GB内存空闲，这远远不够。

**内存颠簸与空闲页换出**

“颠簸”（thrashing）指系统物理内存不足以同时容纳所有活跃工作集，内核被迫频繁地在内存与交换空间之间换入换出页面。此时 CPU 和 GPU 大量时间耗费在等待 I/O 上，而非执行推理，实际吞吐量急剧下降，表现为响应“优雅但极慢”。

Linux 理论上能廉价换出空闲进程的内存页：协调者在等待远程工作模型返回时处于阻塞状态，其大部分驻留页可被标记为可回收，从而让出内存给图像生成。问题在于，若同时驻留的模型总量已逼近物理内存上限，内核可回收的余地极小——每次 GPU 生成需要数 GB，而释放这些内存意味着必须把协调者的部分页面换出；生成结束后，协调者恢复又需换回。换入换出量远超实际计算量，于是“廉价”变为“持续”，正是实验中第一张图完成后其余全部超时的根本原因。
# 主机，120B协调者驻留（约77GB），多图像运行：
free -h:   ~3 GB free
image 1:   completed
image 2:   timed out at 300s  ->  placeholder
image 3:   timed out at 300s  ->  placeholder
   ...

第一张图像完成了，其余在300秒限制处超时，回退为占位符。关于空闲页面的优雅论点在原则上没有错——只是在实践中被淹没了。在如此大的内存压力下，每次GPU生成都超过五分钟，“廉价换出”变成了“不断换出”。机器优雅降级而非崩溃，但能力实际上被封锁了。

合理缩容：少即是多

解决方案不是更多硬件，而是更少模型。120B一直是边缘的：它独自消耗了几乎全部内存预算，这使得原本的工作模型交换和现在的图像生成冲突都不可避免。将协调者降级到gpt-oss:20b，约14GB，留下约60GB空闲——足以同时进行协调和图像生成，没有交换，也没有守护拒绝。

这笔交易看起来比实际更糟。120B唯一的真正优势是更可靠的编排，而——正如后续文章所示——即使是这一点也没有解决它本应解决的更深层可靠性问题。一个耗费整台机器运行、却仍未解决最难题的协调者，很难证明比一个只有其五分之一大小的模型更合理。

内存预算：本地多模型系统的核心法则

本文的主线是一个单一理念：本地多模型系统受内存预算支配。问题从来不是单个模型是否放得下，而是所有必须同时驻留的东西能否一起放得下——协调者、工作模型，现在还有图像生成器。控制这个预算有两个杠杆，都胜过购买更大的模型：布局（东西在哪台机器上运行）和合理缩容（每个模型完成其工作需要多大）。分布式部署工作模型是布局；缩小协调者是合理缩容。两者结合，定义前两篇的内存争夺就此消失。

下一步

内存问题解决后，一个合理的假设依然成立：更大的协调者，既然终于能运行了，应该更好。下一篇直接测试这个假设——发现更大的模型买来的是更可靠的排序，但不是可靠的循环，而循环需要的根本不是模型。

对于在消费级硬件上折腾本地AI的玩家来说，这个系列的启示很直接：在追求更大参数量的模型之前，先审视你的内存预算和任务布局。有时，换台机器或降级模型，比升级硬件更能解决问题。