超大模型部署到计算集群时，如何按计算图切分并做分布式模型管理？｜快手 C/C++面经解析

60 秒回答模板

我会先把模型抽象成计算图，而不是一整个不可拆的文件。计算图里节点是算子或子图，边是 tensor 依赖；如果单机内存或算力放不下，就按 layer、stage、tensor 或子图把模型分到不同设备和机器。切分策略要看参数体积、激活或中间结果大小、计算量、跨节点通信量和延迟目标：按层切适合顺序很强的深度模型；按矩阵、通道或特征维切适合单层参数或计算太大的情况；也可以把特征提取、主干网络、召回、排序、后处理等子图拆成服务化阶段。部署时需要 runtime 调度请求在各分片间流转，处理 micro-batch、pipeline bubble、超时、重试和背压。模型管理还要维护版本、分片清单、权重存储、节点放置、加载卸载、灰度发布、健康检查和回滚，保证同一次请求走的是兼容版本的分片。

考点 计算图切分

难度 真实面经题

回答目标 把超大模型部署讲成计算图切分、运行时调度和分布式模型生命周期管理的完整系统方案。

深入解析

先建可分析计算图

超大模型部署的第一步是把模型表示成 DAG 或静态/半静态执行图，明确每个节点的输入输出 tensor、参数大小、计算量、激活大小和依赖关系。只有知道串行依赖、可并行部分和跨边界 tensor，才能决定在哪里切分。

图切分平衡内存和通信

如果单层能放下但全模型放不下，可以按 layer 或 stage 做流水线式切分；如果单层权重、通道维或特征维本身超过单设备能力，可以做 tensor、channel 或 feature 维度切分。切分不能只按层数平均，还要看每层参数、中间结果、计算量和跨节点通信，避免某个 stage 成为瓶颈。

运行时负责调度通信

图切完后，请求不再是单进程函数调用，而是在多个设备或服务之间流转。运行时要负责 batch/micro-batch、stage 间通信、tensor 序列化或共享内存传输、超时重试、流控和错误传播，并保证 shape、dtype、版本和顺序一致。

模型管理独立成平面

模型很大时权重和配置会拆成多个 shard，不能只靠普通模型文件上线。管理系统要维护模型版本、分片清单、checksum、存储位置、runtime 版本、输入输出 schema、预处理/后处理配置、每个 shard 的加载状态和放置节点，支持灰度和快速回滚。

服务层满足 SLA

大模型集群部署还要满足吞吐、延迟和稳定性。可以通过动态 batching、请求排队、优先级、限流、热点 stage 扩副本、异步后处理和副本扩缩容提升资源利用率。图切分部署尤其要监控 stage 热点、pipeline 等待、跨节点通信和中间 tensor 传输成本。

验证故障和版本一致性

部署后要验证不同 batch、长短输入、峰值并发、节点重启、分片加载失败、网络抖动和灰度切换。关键指标包括内存峰值、加载时间、P95/P99 延迟、吞吐、跨机流量、stage 空闲率、错误率和恢复时间。

易错点

把题目答成分布式训练，只讲数据并行和梯度同步。
只说拆到多台机器，没有说明按计算图依赖、内存、通信和延迟切分。
忽略分布式模型管理，未覆盖版本、manifest、加载、灰度、回滚和健康检查。
只关注能跑通，不讨论跨节点通信、P95/P99 延迟、故障恢复和观测。

面试官追问

图切分和分布式训练并行有什么区别？

训练关注梯度同步、优化器状态和反向传播；部署关注权重加载、请求调度、版本一致性、延迟、吞吐和在线稳定性。两者可能用相似的切分思想，但目标和故障处理完全不同。

如何判断按层切还是按 tensor 切？

如果单层能放下但整模型放不下，按层或 stage 切更直观；如果单层本身超过单卡能力，则需要 tensor parallel。还要看通信带宽、负载均衡和 SLA。

模型分片灰度发布最怕什么？

最怕同一次请求混用不同版本的权重、预处理配置、后处理配置、输入输出 schema 或算子实现。应使用版本化 manifest 和路由约束，保证请求绑定一组兼容分片。

某个分片节点故障怎么办？

健康检查要及时摘除故障节点，新请求路由到健康副本；执行中请求可失败返回或在可重放边界重试。关键分片要有副本和预热机制。