DeepSeek多机部署：堆机器还是换显卡

多卡能跑起来，和跑得动，是两码事。deepseek多机部署这件事，第一道坎从来不是显卡够不够多，而是你被显存卡住，还是被卡和卡之间的通信卡住。这两件事长得像，解法完全相反，搞混了钱花出去就是打水漂。我见过不少人上来就追加两台机器，结果模型本来就塞得进一台，多出来的那台机器除了多交电费，什么活也没干。

deepseek多机部署最先撞上的不是显存

模型权重放不下，第一反应是加卡；加卡加不进一台机器，就得跨机；跨机就得走网线。问题就在这——单机内部几张卡之间是那种高带宽的直连通道，一跨到两台机器，通道立刻变成网卡加交换机。张量并行对这种延迟极度敏感，几乎每算一层都要同步一次，链路一慢，所有卡就站在那儿等数据。你去看监控，显存是满的，功耗也不算高，但 token 一个个往外挤，慢得让人想砸键盘。很多人以为是软件参数没调好，其实是硬件拓扑压根不适合这么切。

所以动手之前先问一句：模型能不能塞进一台机器？能塞进去，就别急着上第二台。这个判断比后面所有优化都值钱。

换显卡能解决什么，又不能解决什么

显存更大的卡，最直接的收益是并行度可以降下来。原本要切成四份的层，现在切两份甚至不切，通信量跟着往下掉。这条路的好处是收益直接、操作简单，换完重启就完事。缺点也明显，贵，而且是那种一次性投入很大、后面没多少优化空间的贵。具体价格各渠道差得不少，以官方页面报价为准，别拿一张截图当标准。

但换卡不是万灵药。有些满血版本的模型，单卡显存再怎么加也放不下，你还是得切；切了就有通信，通信就受物理链路限制。花钱能买到显存，买不到延迟。这个账要先算明白，不然换完卡发现问题只解决了一半，那才叫难受。

堆机器的那些隐形成本

多机部署还有个很容易被忽略的成本：故障面变大。一台机器抽风，整个推理服务跟着抖。你得做健康检查，得让请求能重试，前面还得压一层负载均衡，某个节点掉线以后 KV cache 怎么重建也是一堆事。这些活在单机上根本不用想，上了多机就全冒出来了。

还有环境和驱动的一致性。跨机的 CUDA、驱动版本、推理框架版本必须对齐，网卡固件也别差太远。我用 Debian 的时候被这个坑过一回，两台机器内核小版本不一样，RDMA 就是起不来，日志报得含糊其辞，用 ip 和 ethtool 一点点对着查，耗掉大半天。这类问题没有万能答案，以服务商或官方页面的说明为准，自己一项项核对。

别忘了供电和散热。几张高功耗卡塞满一个机柜，普通机柜的电源余量和风道真的顶不住，这个在算预算的时候十有八九会被漏掉，等到机器频繁降频才想起来。

先去试试量化，别急着买卡

很多场景其实是被“必须上满血”这个执念拖住的。INT8、FP8 的量化版本，显存能砍下来一大块，精度损失在绝大多数业务里用户根本感知不到。再退一步，选参数量小一点的蒸馏版本，一台机器就能跑，首 token 延迟还更好看。

我的习惯是先拿量化版本压一轮，把并发、首 token 延迟、每 token 延迟三个数跑出来，再决定要不要上多机。如果业务量根本撑不满一张卡，多机就是给电费做慈善。长上下文的应用还得另算，上下文越长 KV cache 越占地方，这部分显存和权重是分开吃的，压测的时候拿真实长度的请求去打，别用一句“你好”测完就下结论。

框架参数填错，硬件白买

vLLM、SGLang 这些现在对多机的支持都还行，但配置差别不小。张量并行的切分数要和卡数对得上，流水线并行会带来额外的空转，这些文档里都写着，别跳过去。启动参数里那几个 –tensor-parallel-size 之类的东西填错了不会报错，只会慢，慢到你以为硬件有问题。

还有 KV cache 的显存预留比例，调太满跑一阵就 OOM，调太小并发上不去，中间那个平衡点只能靠压测找。有人问我有没有标准值，真没有，每个模型的层数、每张卡的大小、请求长度分布都不一样。

云上租多机，和自建是两种账

自己买卡是一次性大投入，机器到手就开始折旧，闲置的时候照样烧电。租的话是按量算，多机只在压测和高峰期开，平时缩回单机，这在小团队里往往更划算。代价是跨机的网络质量得看服务商给什么规格，普通实例之间未必有高带宽互联，下单前把网络规格问清楚，别默认多台机器之间就是快的。

照着这个顺序判断就行

先估权重加 KV cache 要占多少显存，看能不能压进一台机器；能，就单机，挑显存够的那张卡，别管几台。不能，再考虑多机，优先选同型号同批次、带高带宽互联的机器，别新旧混插。上多机之前先做量化，量化压不下来再谈加机器。最后把压测数据存档，并发、首 token 延迟、每 token 延迟这三个数比任何参数截图都实在。

技术选型最怕的是先买硬件再想场景，钱花完了才发现瓶颈卡在网线上。先把瓶颈量出来，再决定是加机器还是换卡，顺序反过来，学费基本就得交一遍。