两台 T5000 跑 DeepSeek，我踩遍了分布式部署所有的坑
8 月 28 号晚上，我在懒猫算力仓的两台 Jetson Thor T5000 上，用官方 CLI 3.0.8 部署了 DeepSeek V4 Flash，双机分布式，vLLM 后端。
跑起来那一刻挺爽的。
然后我花了三天，把部署过程中踩的坑一个个填上。
这篇把坑全部摆出来。
坑一：启动顺序的竞态，连锁崩的根源
双机组网的两个节点不对等：139 这台是 rank0（对外提供 API 的主节点），179 那台是 rank1（纯算力的从节点）。
主节点要等从节点先就绪，才能完成组网握手。
我第一次部署时随手先启动了主节点——从节点还在拉起中，主节点等待超时直接失败。
更糟的是第二次尝试：旧进程没停干净，master 的通信端口 29679 被残留进程占着，从节点连上来直接报 Gloo read error，然后像多米诺一样把整个组网拖崩。
排查痛苦在于：报错指向"通信失败"，真根因是启动顺序与端口清理——隔着一层，日志不会告诉你。
纪律：先 rank1 后 rank0；重启前必须查端口占用（不是看容器状态）；顺序写成脚本，人不再手点。
坑二：worker 被静默击杀，连遗言都没有
配 1M 上下文时，我把 KV 缓存配得非常激进：20GiB 的 KV 池几乎吃满内存预算。
跑起来一切正常。
直到某天，从节点上的 worker 进程消失了，主节点报错退出。
没有异常日志，没有报错栈。
后来确认：内存紧张时，操作系统把进程静默终止了。这种终止不会在应用日志留任何痕迹，必须看内核层日志才知道死因。
解法：1M 上下文必须把 KV 池从 20G 砍到 10G，给宿主机留 17-18G 健康余量。
把资源压到 100% 的配置，就是定时炸弹。
坑三：推理预算太小，模型"想了想"返回空
诡异反馈：API 返回成功，content 是空的。
根因：DeepSeek V4 默认开启深度思考，回答之前先生成内部推理。max_tokens 设小了，思考过程烧光预算，轮到正文时额度已尽。
解法：max_tokens 给到 256 以上，或者直接关思考。
关掉之后还有意外收获——同题 46.8 秒变 1.75 秒，27 倍。详见慢的三层真相。
坑四：容器不自启，重启后是一地碎片
推理容器出于安全考虑没配自启动。节点一次断电重启后，整个推理组躺平了，直到我发现业务报错。
分布式系统的启动比单体复杂：顺序、等待、健康确认一个都不能少。
最终形态是编排脚本：清理残留 → 起从节点 → 健康探针确认 → 起主节点 → API 探活 → 失败自动回滚重试。
还有个细节：139 节点上原本跑的 Ollama 和 bge-m3 embedding 服务，因为内存互斥被停用和移除了——这台机器现在专门干推理这一件事。
最终沉淀：操作手册结构
六条红线：先 rank1 后 rank0 / 重启前查端口 / KV 留宿主余量 / 思考类任务 token 上限给足 / 节点重启跑编排脚本 / 配置变更留快照。
两个脚本：编排启动脚本（顺序+探针+回滚）、1M 上下文切换脚本（139 先 rank1、179 后 rank0，约 8 分钟就绪）。
一张端口清单：通信端口、API 端口、探针端口及占用检查命令。
分布式系统的运维，聪明不如勤奋，勤奋不如手册。
每个坑的价值，只有在它变成手册里一行"必须/禁止"时才真正兑现。