一家企业准备把参数规模更大的模型接入在线问答。算法团队认为增加GPU数量即可，平台团队却发现现有模型在单卡上勉强能加载，真正瓶颈可能是长上下文与并发请求；采购则希望一次买足。多卡推理方案若没有先区分容量和吞吐问题，很容易把硬件投入变成长期通信和故障负担。

决策口径：先判断单个请求是否必须跨卡切分，再决定是使用模型并行、增加独立副本，还是保持单卡并调整模型与请求边界。

先证明瓶颈属于容量，而不是调度或请求形态

多卡方案的第一个输入不是GPU数量，而是一份可复核的显存账本。账本至少要记录模型权重、运行精度、KV缓存、运行时预留、并发请求和上下文长度。模型能加载但长请求频繁失败，与模型本身完全放不下，是两类不同问题；前者可能顺利获得请求分层、批处理或并发控制改善，后者才可能要求切分单个模型。

POC应固定模型版本、镜像、启动参数和请求集，分别观察空载、单请求、目标并发和长上下文场景。显存数值只有在这些条件不变时才可比较。若团队无法解释增量显存来自权重、缓存还是运行时，采购更多卡也无法形成可靠容量计划。

三种扩展方式解决的不是同一个问题

以下对比用于识别方案方向，不代表任何框架或硬件的默认表现。

从表中可以看出，副本扩展面向“更多请求”，模型并行面向“单个请求跨卡”。如果单卡可承载且并发是主要矛盾，优先比较独立副本通常更容易隔离故障；若单模型确实无法承载，再进入跨卡切分验证。

把通信路径写进POC，而不是只看卡数

多卡通信的真实代价取决于物理拓扑、并行方式、消息规模、软件栈和请求形态。团队应画出卡与卡、进程与进程之间的路径，并在相同请求集下记录端到端延迟、吞吐、排队和资源变化。只记录GPU利用率，会看不到通信等待和某一阶段成为热点。

同一台服务器内不同连接关系也可能带来差异，跨节点则会引入更多网络依赖。草稿阶段不设固定带宽或延迟门槛；正式POC应由基础设施团队给予实际拓扑，由推理团队说明通信模式，SRE负责关联事件与请求结果。

故障边界决定方案能否进入生产

多卡组中任一卡失败都可能影响整个服务实例，不能用“还有其他卡”推导服务仍可用。 验收至少要覆盖进程退出、单卡不可用、模型加载失败和实例重启。每次故障都记录探测来源、请求表现、摘流动作、重建时间、未完成请求以及旧版本是否可接管。

如果重建多卡实例需要较长准备过程，容量计划还要保留健康副本和流量保护，不能把全部资源都压到峰值利用。恢复后要再次验证模型版本和路由状态，防止实例表面就绪但仍使用错误配置。

用选择矩阵收敛采购和回退条件

下面的矩阵把单请求模型需求放在纵轴、通信与恢复代价放在横轴。它的任务不是自动给出答案，而是提醒评审会同时看容量收益和故障影响。

最终结论应分为采用、补测和暂缓。采用需要明确并行方式、卡组大小、容量余量、故障恢复和回退对象；补测要写出缺失的拓扑、请求或故障证据；暂缓则保留单节点优化、模型压缩或较小模型等替代路线。如果没有可执行的回退方案，多卡扩展就不应被视为完成选型。

在形成多卡基线前，可先参考 AI推理服务POC验收框架 的模型、伸缩、访问与监控证据划分。需要补充平台层资源治理视角时，再进入 AI基础设施分类 查看相关内容。

采购评审要核对卡组扩容和退出的实际工作量

多卡方案进入采购前，应让算法、平台、基础设施、SRE和采购角色分别签认对象。算法团队给出模型、精度、上下文和并行方式，基础设施团队给予卡间拓扑与可分配资源，平台团队说明调度和镜像，SRE负责告警、摘流与重建，采购核对这些前提是否写入交付范围。只写“支持多卡”，无法确认实施由谁完成。

容量证据要回答卡组怎样形成，而不是只记录总卡数。同一服务需要陆续在占用哪些卡、调度失败时是否继续等待、卡组中一张卡被占用后能否安排其他任务、扩容是否要求重建实例，都影响资源池碎片和交付窗口。若卡组必须长期独占，还要把空闲时段与备用容量列入预算说明，避免按理论峰值采购后才发现可用资源被切碎。

合同附件可以要求交付显存账本、拓扑清单、启动参数、基准请求集、故障演练和回退手册，但不应预写未经测试的性能数字。验收时由同一请求集复跑单卡、目标卡组和健康副本接管场景；模型版本、卡组或软件栈变化后，原结论标记为待复验。供应方负责的调优与企业自担的资源、请求治理也要分开。

退出路线需要真正可操作：是否能够回到单卡、独立副本、较小模型或旧并行配置，模型制品与启动配置能否导出，卡组释放后如何确认没有残留路由和占用。一次受控回退会暴露专有参数、人工脚本和少数专家依赖。若退出只能依赖原实施人员现场处理，应把交接和演练工时计入采购风险。

变更窗口还应覆盖模型或运行时升级后的重新分片。升级前保留当前制品、参数和路由版本，升级后先以代表性请求验证显存、通信和错误，再决定扩大流量。这样卡组变化不会越过既有验收边界。

下一步建议

先选择一个代表性模型和三组请求：短交互、长上下文、目标并发。完成单卡基线后，只对确实无法满足边界的场景增加卡数，并把每次变化与通信、请求和故障证据绑定。采购评审时提交显存账本、拓扑图、故障记录和回退步骤，而不是提交一张峰值性能截图。

常见问题

模型能在单卡运行，还需要多卡推理吗？

不一定。模型能够加载只说明权重和运行时在当前条件下可以进入显存，还要观察目标上下文、并发、KV缓存和延迟是否满足业务边界。如果主要问题是请求数量，增加独立副本可能比切分单个模型更简单，也更容易隔离故障。

判断时应保持模型、镜像、请求集和观察窗口一致，比较单卡优化、并发控制、多副本与跨卡切分。只有单请求容量或计算路径确实要求跨卡，并且通信与恢复代价可接受，才值得把多卡作为生产候选。

评审记录应同时列出单卡基线、目标卡组、请求画像和剩余显存，并注明模型或上下文变化后的复测条件。采购团队据此判断增加卡数是在解决单请求容量，还是在掩盖并发和调度问题。

多卡推理POC最先验证哪种故障？

先验证一个多卡服务组内的单进程或单卡异常，因为它最能暴露故障是否被放大到整个实例。测试应在授权的隔离环境进行，观察健康检查何时发现异常、入口何时停止送流、在途请求如何结束、实例如何重建以及健康副本是否有足够容量接管。

随后再测试模型加载失败、配置不一致和节点重启。报告中不要只写恢复成功，还要记录未完成请求、人工操作、恢复后的模型版本和流量状态，以判断方案是否真的可复核。

故障报告还应保留卡组拓扑、异常位置、摘流时间、健康副本余量和重建步骤。若恢复依赖手工登录或专有脚本，应在POC阶段暴露并安排交接，不能用最终服务恢复掩盖过程风险。

怎样区分模型并行和增加副本？

模型并行把一个模型或一次请求的计算拆到多张卡上，主要解决单卡容量或单请求计算边界；增加副本则让多个完整服务实例承接更多请求，主要解决并发、隔离和可用容量。两者可以组合，但组合后会同时增加资源和运维复杂度。

企业应先用同一请求集验证单卡是否能够承载单请求，再看目标并发下队列与延迟。若单请求可运行而并发不足，优先评估副本；若单请求本身无法承载，才进入模型并行。最终还要比较故障范围与回退难度。

选择矩阵应由算法团队确认单请求需求，平台团队确认副本与调度，SRE确认故障范围，采购确认实施和退出成本。若组合方案同时使用模型并行与多副本，还要分别验切分组故障和副本接管。