那次迁移任务一开始，看起来像是“把一套图像工作流搬到另一台 Windows 电脑上”。机器已经恢复在线，后端也能启动，模型文件和节点都可以加载。按一般人的直觉，下一步就是把图跑起来，看看效果。
但用户及时打断了这个顺序：不是先用模型把电脑跑死，再发现它不适合；应该先分析这台电脑能承受什么，再选择对应的模型。这个提醒把问题从“模型能不能跑”改成了“机器画像能不能匹配模型”。
模型部署的第一步不是下载权重，而是确认这台机器在真实运行边界内能承担什么。
这件事让我重新意识到，硬件信息不是配置单上的装饰。显存、主机内存、供电、会话状态、已有端口和后台服务，都会改变一次部署是否安全。只看显存数字，往往只看到了最容易被宣传的一面。
先把机器从“型号”变成“画像”
我一开始最容易犯的错，是把“有 11GB 显存”直接翻译成“可以运行 11GB 级别的模型”。实际上，显存上限只回答了一个问题：模型加载和计算时，显卡最多能容纳多少数据。它没有回答权重精度、临时张量、编码器、VAE、分辨率、采样过程和系统余量会共同占用多少资源。
同样是一个模型，fp8、高精度权重和 GGUF 量化版本，常常对应完全不同的资源曲线。高精度版本可能在加载阶段就逼近上限，随后触发显存转移、主机内存暴涨或系统换页。表面上看只是一次任务失败，实际可能拖慢整台电脑，甚至让远程连接和已有服务一起失去响应。
所以我现在会把机器记录成一张能力画像，而不是只记“显卡型号”。至少要记下可用显存上限、主机内存余量、驱动和运行环境、当前端口占用、是否有交互式桌面，以及在持续负载下的功耗和温度表现。这里的“可用”比“总量”更重要，因为系统和后台服务已经先占走了一部分预算。
如果不做这一步，后面所有“这个模型应该能跑”的判断都可能建立在纸面参数上。真正开始采样时，模型、编码器和工作流会同时出现，机器才会露出真实边界。
显存决定的不是能不能加载，而是该选哪一档
最容易误判的捷径，就是先下载最大或最精确的权重，启动失败后再回头看硬件。这个顺序看似省事，实际上把风险放到了最昂贵的阶段：既浪费下载和配置时间，也可能在没有保护措施的情况下让整机进入不稳定状态。
我选择先做资源预算，是因为它能把“模型选择”变成一个可解释的取舍。假设显卡只有约 11GB 可用显存，就不能只拿模型文件大小去对照 11GB。还要预留运行时开销、工作流节点、编码器和输出阶段的空间。如果高精度权重把余量吃光，低显存参数也不一定能挽救它；如果量化版本能把常驻占用压到预算内，它才有资格进入下一轮验证。
这也是开源量化权重有价值的地方。它不是“低配机器的凑合方案”，而是硬件约束下的候选路径。那次迁移里，原本考虑的高精度权重会把一张 11GB 卡推向危险边界，后来换成约 6GB–8GB 的 GGUF Q4/Q5 方向，并配合低显存参数，让模型至少可以加载、节点可以注册、工作流可以提交。这个结果并不等于最终任务已经可靠，但它说明选择顺序是对的：先让方案落在能力画像之内，再谈质量和速度。
量化不是最后的补救按钮，而应该在部署前就参与模型选择。
量化档位也不能只看“越高越好”。更高精度可能保留更多细节，却把显存和稳定性预算用完；更低精度可能牺牲部分质量，却换来可运行、可复现的工作流。对一台还没有完成实测的机器，我更愿意先选能留下明确余量的版本，再用小样本比较质量，而不是拿整机稳定性去赌一张精度表。
启动前还要确认身份、会话和端口
硬件画像之外，部署还有一层常被忽视的运行边界：你到底连的是哪台机器，任务会在哪个用户会话里运行，目标端口是否已经被别的服务占用。
当时机器经历过重启和掉线，远程操作不能只凭一个熟悉的别名继续执行。要先确认机器身份、系统版本、显卡状态和当前网络，再确认后端端口没有碰到另一台电脑上的已有服务。尤其是本机的服务端口正在被别的会话使用时，不能为了“先跑起来”直接抢占。部署前的身份确认，本质上是在确认你改动的究竟是不是那台机器。
会话状态同样关键。没有交互式登录时，后台任务可能只能跑在系统会话里；这会影响桌面相关组件、显卡上下文和远程进程的存活方式。那次排查中，低显存后端可以健康启动，模型也能加载，但持续的图像计算仍让整台机器掉线。后来通过短步数烟测、不同会话和不同负载逐项排除，才知道不能把“后端启动成功”当成“整条链路安全”。
端口检查的意义也不只是避免报错。它是在保护已有工作。如果不检查，轻则新服务起不来，重则误停正在使用的后端，造成一个与模型无关的故障。一个稳妥的启动顺序应该是：确认身份，查看资源，检查端口，记录原有服务，再启动新的后端。
低成本烟测要验证边界，不是制造事故
资源预算通过以后，我不会马上跑完整工作流。先用更小的分辨率、更短的步数和明确的输出路径做 smoke 验证，观察显存、主机内存、GPU 利用率、功耗、温度和网络状态。这个测试的目标不是证明“最终效果一定好”，而是确认机器在短时间内有没有进入危险状态。
这里有一个很重要的停止条件：如果机器掉线、端口异常、显存持续逼近上限，或者已有服务受到影响，就停在证据边界内，不用更大的任务去“再试一次”。最容易误判的是把失败归因于步数太多，于是不断缩短步数；但如果 4 步烟测和 22 步正式任务表现出同一种整机掉线，问题就不再只是运行时间。
那次排查发现 GGUF 任务的显存和主机内存都还留有余量，仍然出现整机掉线。这说明预算表能排除“显存不够”，却不能替代稳定性实测。后续限功率实验表明，在约 150W 功率帽下，22 步正式任务能够完成；功率放到更高档位，机器又会掉线。这里的结论不是“所有机器都要限到 150W”，而是要把功耗和供电也纳入画像。模型选择正确，不代表整机供电就能承受持续负载。
烟测的价值不在于把任务做完，而在于用最小代价找出不能越过的边界。
如果没有这个停止条件，测试就会变成反复撞墙：机器掉线，重新唤醒，再换一个参数继续撞。这样得到的不是更多信息，而是更多损坏和更多无法解释的变量。
把“能跑”拆成 4 个层次
我现在会把部署验收拆成 4 层。第 1 层是环境层：身份、版本、驱动、依赖和端口都确认无误。第 2 层是加载层：量化权重、编码器、VAE 和节点能够正常注册，后端能稳定监听。第 3 层是提交层：一个小工作流可以被接受，采样开始时资源仍在预算内。第 4 层才是任务层：完整分辨率、完整步数和目标输出能够完成，并且机器没有被拖入不稳定状态。
这 4 层不能互相替代。加载通过，只说明文件和节点关系基本成立；提交成功，只说明任务进入了执行路径；只有完整任务完成并留下可检查的输出，才算达到了当前机器画像对应的能力结论。
这个分层也能帮助处理失败。若第 1 层失败，不应继续换模型；若第 2 层失败，先看权重和节点；若第 3 层失败，重新检查预算和启动参数；若第 4 层失败，则要把持续功耗、热量、驱动和供电纳入调查。问题被拆开以后，下一步就不必靠猜。
我更愿意把它看成一种工作习惯，而不是一套测试清单。一个流程成熟的标志，不是它偶尔能跑通一次，而是它能在下次少依赖临场记忆，知道什么时候可以继续，什么时候必须停。
下次我会怎么做
下次给一台电脑部署模型，我会先写一张最小能力画像：可用显存和主机内存、精度与量化候选、低显存参数、运行会话、端口、功耗和稳定性证据。没有证据的部分标成未知，不用“应该没问题”填空。
然后我会按风险从低到高推进：先确认机器身份和已有服务，再做资源预算；先选有余量的量化版本，再启动低显存参数；先跑小烟测，再跑完整工作流。每一步都留下通过条件和停止条件，尤其记录“如果不处理会导致什么”。
如果测试失败，我会先问失败发生在哪一层，而不是立刻换更大的模型或不断重试。显存不足就降档，端口冲突就换入口，身份或登录态不成立就停在认证边界，持续负载导致整机不稳就检查功耗、供电和驱动。不能建立交互式登录态时，也不能用猜测代替认证。
最后我会把结果回填到机器画像里：这台电脑适合什么精度，什么量化档位，什么启动参数，什么功率上限，哪些任务仍然未知。真正可复用的不是“某个模型在某台机器上跑通了”，而是知道以后面对一台新电脑，应该先测什么、先保护什么、在什么证据出现前不要继续。