那次音乐生成任务开始时，看起来只是一次普通的本地试跑。模型准备加载，生成流程也已经写好，唯一需要做的似乎是把参数调到合适的位置。结果任务一启动，电脑先变得迟钝，接着出现内核崩溃，系统里还留下了杀进程的记录。
我一开始很容易把这类事故归结为“模型太大”或者“参数太激进”。但再往回看，真正危险的并不是某个孤立参数，而是模型加载和生成入口没有把系统余量当成前置条件。只要两个重任务同时进入，原本勉强可以运行的方案，就可能一起把机器推过临界点。
这件事让我重新意识到，本地生成系统的稳定性，不是靠提醒使用者“别同时运行”得来的。只要危险请求还能走到模型加载的位置，系统就不能把安全寄托在人的记忆上。
死机之后，先看系统留下了什么
事故发生后，最容易做的动作是马上换一个更小的模型，或者重新运行一次，看看是不是偶发故障。我没有先这么做，而是先复盘系统级证据：当时有没有内核崩溃，系统是否主动杀过进程，任务结束后资源有没有真正回收。
这一步很慢，却很重要。因为“程序报错”和“系统已经没有余量”不是一回事。前者通常可以在应用层处理，后者却可能发生在应用来得及写出错误之前。如果已经出现内核崩溃和系统杀进程记录，再把问题当成普通参数错误，就会错过真正的边界。
我也同时盘点了现有能力。运行环境已经有进程级资源监测库，生成框架也提供了内存上限能力。这意味着问题不在于缺少某个神奇工具，而在于这些能力没有被接到任务入口上。能力躺在环境里，不会自动变成保护；只有在危险动作发生前被调用，它才有意义。
如果不处理这一层，后面会出现一个很糟的循环：任务失败，使用者重试；重试又启动新的模型加载，旧进程可能还没有退出，最后失败不再是单个任务失败，而是整台电脑失去响应。
表面是模型太重，实际是没有资源门
模型大小当然会影响风险，但“换小模型”并不等于完成修复。一个小模型也可能在多个任务同时加载时超过余量；一个大模型在系统空闲、单任务运行且有上限约束时，反而可能是可控的。真正需要回答的问题不是“这个模型大不大”，而是“当前机器现在能不能安全接纳它”。
于是我把生成请求拆成了几个时间点：请求进入、准备加载、模型加载、开始生成、生成结束、释放资源。原来的流程把这些动作连成了一条顺滑的路径，只要函数被调用就继续向下执行。缺少的，恰恰是加载前的停顿：先检查，再决定是否允许进入。
这个停顿就是内存门。它不必精确预测每一步的峰值，但至少要定义一个可测的最低余量：当前可用内存低于阈值时，直接拒绝加载；任务数量已经达到上限时，直接拒绝并发；监测数据无法取得时，也不能假装资源充足。
资源门的价值，不是让每一次请求都成功，而是在失败还可控的时候拒绝请求。
我选择把检查放在模型加载之前，是因为加载往往是最昂贵、最难回收的一步。如果等模型已经进内存，甚至等生成开始后才发现余量不足，系统可能已经进入无法优雅退出的状态。闸门越靠前，拒绝越便宜，留下的清理工作也越少。
只加内存门还不够，还要挡住并发
内存门解决的是“当前余量够不够”，互斥锁解决的是“有没有另一个任务正准备消耗这份余量”。两者不是同一件事。一个请求检查时看到内存还够，另一个请求随后也看到同样的数字，如果它们在检查后一起加载，两个判断都可能在单独看时正确，合在一起却把系统拖垮。
所以修复时，我把模型加载与生成统一包进资源保护逻辑：先取得单任务锁，再做内存检查，确认通过后才加载模型并开始生成；任务结束或中途失败，都要释放锁并执行资源清理。锁不是为了让系统变慢，而是把“同时抢资源”改成“排队进入”。对于本地机器，少一点并发，通常比多一次崩溃更划算。
这里最容易误判的是把锁只加在某一个命令行入口。只要还有另一个入口可以绕过它，系统就仍然存在并发缺口。我更愿意把保护放在共享的加载和生成层，让不同调用方式最终都经过同一道门。这样改动的范围小一些，保护的覆盖面却更完整。
错误捷径是只把模型换小，或者在使用说明里写一句“请不要同时运行”。这两种做法都把责任留给了人：前者没有证明峰值已经安全，后者没有阻止错误请求。凡是会消耗共享资源的危险动作，都应该在代码入口被拒绝，而不是在说明文字里被提醒。
监测要看进程，也要看结束之后
加锁和内存阈值之后，我没有把问题当成已经结束。因为生成任务还有另一类隐蔽失败：主流程看似结束了，子进程却继续空转；或者生成报错了，模型和缓存没有释放，下一次任务接着踩在残留资源上。
因此，监测不能只记录“任务开始”和“任务成功”。还要能看到进程是否仍然存在、资源占用有没有回落、失败路径是否完成清理。后续排查同类问题时，确实又追到了进程空转和资源回收，说明第一次修复挡住了最明显的危险，并不代表整个生命周期已经可靠。
我把这看成一个很实际的边界：任务的终点不是函数返回，而是资源回到可用状态。若不检查这一点，系统可能表面上只运行了一个任务，实际上后台还挂着前一次生成。下一次内存门看到的是被污染的现场，使用者却只会以为“这次怎么突然不行”。
失败清理也要和成功路径一样明确。模型加载到一半失败、生成过程中被中断、监测发现资源异常，都应该进入同一套释放逻辑。否则，越是需要保护的异常场景，越容易留下下一次任务无法解释的状态。
用离线测试证明闸门真的会关
这类问题不能靠再制造一次死机来验收。真实死机的代价太高，而且每次发生时的系统状态不同，很难形成稳定的回归证据。修复后，我补了可重复的离线测试，用模拟的内存读数、锁占用和生成失败来检查几个关键判断。
测试至少要证明：余量低于阈值时，模型不会被加载；已有任务持锁时，新的重任务会被拒绝或等待；资源足够时，正常流程可以通过；生成中途失败时，锁和监测状态最终会释放。这里测试的是门槛行为，不是某一次真实生成的结果。
同时，技能层的执行规则也补上了硬门槛。原因很简单：如果代码有保护，调用方却能通过另一条路径绕开；或者调用方知道有保护，却在加载前没有触发它，系统仍然不稳。规则、共享入口和测试需要互相咬合，少一层都可能留下旁路。
一个本地生成系统是否可靠，不看它顺利时能跑多快，而看资源不足、并发进入和中途失败时能不能有序拒绝并清理。
下次我会怎么做
下次遇到本地生成任务把电脑拖慢，我会先把问题分成4层处理：先看系统级证据，确认是应用错误还是资源耗尽；再盘点已有的监测和上限能力，避免重复造工具；然后在共享加载入口加单任务锁和内存门，把拒绝动作放在模型进入内存之前；最后用离线测试覆盖低余量、并发占用、正常通过和失败清理。
我不会把“换小模型”当成默认答案，也不会把“提醒用户不要并发”当成安全机制。模型选择仍然重要，但它应该是预算之后的决策，而不是替代预算。真正值得沉淀的，是一条能反复执行的流程：先证据，后门槛；先阻断，后加载；先测失败，再测成功。
表面上我是在修一次死机，其实我是在重新定义“能运行”。能运行只是某次机器状态刚好允许，安全运行则意味着系统知道什么时候不该开始。一个流程成熟的标志，不是它永远不失败，而是它能在失败变大之前停下来，并把现场收拾干净。