一个内存互斥故障教会我的事：一台机器只干一件事
我的算力集群里有一台节点（就是跑 DeepSeek 推理的那台 139），原本同时跑着两个服务：大模型推理，和一个 bge-m3 的向量嵌入服务。
某天推理服务升级大上下文配置，内存需求猛涨。
embedding 服务开始反复被挤崩。
我做了个决定：停用 embedding，把这台节点完整让给推理。
恢复方式也留好了：哪天要 embedding，一条 docker start 命令拉起来——但在那之前，它与 DeepSeek 内存互斥，不能共存。
这个小决定背后，是我花了不少学费才想明白的"一机一事"原则。
资源互斥的服务，不共机
什么叫资源互斥？两个服务不是"分享"同一块资源，而是各自都要在峰值时独占它。
推理服务加载大模型后，显存与系统内存是刚性占用——它不峰值时省下的资源也不给别人用，因为它随时要峰值。
这种服务之间没有"共享"，只有"互斥"。
硬把互斥服务塞进同一台机器，你以为省了一台机器的钱，实际付出的是三重隐性成本：
稳定性耦合：一个服务升级、重启、内存波动，另一个跟着遭殃。
排障复杂度翻倍：出问题时你要在两个服务之间做归因——是它还是它？
容量规划失效：两条资源曲线叠加，峰值预算没法算。
如果必须共机：显式声明预算与启停顺序
现实不总允许一机一事——成本、空间、功耗都有限制。
必须共机时，我的两条铁律：
显式声明资源预算：每个服务允许占用多少内存/显存，写成配置并设置硬限制，容器层面用限额兜底——超限即杀，保护邻居。"它应该不会用太多"不是预算，是赌博。
显式声明启停顺序与互斥开关：哪个先起、冲突时谁让路、让路的那个怎么恢复——写成脚本存进运维手册。我给互斥对写了"恢复命令"，谁停的谁知道怎么拉起来，不依赖任何人的记忆。
专门化的代价，要诚实面对
139 节点专门化之后，我清掉了上面所有"顺手再跑点什么"的想法。
Ollama 应用移除，无关服务卸载，embedding 停用。
代价是这台机器的利用率下降了——它有大块时间只干一件事，甚至闲着。
这笔账怎么算？用利用率的损失，买稳定性的确定性。
推理服务的可用性直接决定我的工作流能不能转，它停一小时的真实成本，远高于那块闲置内存理论上能创造的价值。
当然，如果是一个"挂了也无所谓"的服务，就不配享受这种待遇——专门化是给关键服务的特权。
这个原则的普适版
"一机一事"其实是软件工程老原则在硬件上的投影：单一职责、故障域隔离、资源配额——微服务、进程隔离、容器化，说的都是同一件事。
判别式一句话：当两个东西的峰值需求互斥、失效代价耦合时，把它们分开；分开的成本，用显式的预算与顺序管理来兜底。
下次你在规划算力、规划服务器、甚至规划自己的时间时，都可以问一句：这两个东西，是互补，还是互斥？
互斥的东西放在一起，省下的是明面成本，埋下的是隐性故障。
集群的全景见 算力集群演进记；显存记账的细节见 OOM 四张面孔。