一、两种形态各自的定位

容器形态把计算资源切成灵活的小份。每个任务拿到自己需要的卡数和显存，用完归还，资源利用率高，任务之间隔离也比较干净。它的开销小、启动快，适合数量多、单任务规模不大的场景，比如在线推理、数据处理、小规模试验。裸金属形态则是整台机器的完整交付，使用者直接面对真实的硬件，没有中间层带来的性能损失，机器内卡与卡之间的高速互联也能发挥到极致。大规模训练对通信质量极其敏感，独占整机、独占互联的裸金属因此成为首选。两种形态并非替代关系，而是分工关系，混部的意义就在于让对的形态去干对的事。

还有一类介于两者之间的用法：把整台机器切成几个固定的大块，每块包含若干张卡，按块分配给中型任务。它牺牲了一些灵活，换来比细粒度容器更稳定的互联性能，适合中等规模的训练和压测场景。从成本视角看，两种形态互补着用，整体利用率比单一形态高出不少，这正是混部被普遍采用的经济动因。

二、混部的可行性从哪来

混部的关键在于调度系统建立统一的资源视图。所有节点，无论最终以容器方式还是裸金属方式使用，都先注册到同一个集群里，把自己的卡数、显存、网络能力、位置信息上报。调度器看到的是一张完整的资源地图，分配时只是决定把某个节点整机划出去，还是把它切成容器配额。对上层使用者而言，提交任务时声明想要的形态即可，剩下的交给调度器匹配。这背后要求容器管理组件和裸金属管理组件遵循统一的接口规范，资源账本合在一起记账，才不会出现两边各自为政、资源对不上的情况。

统一视图还有个副产品：资源报表变得诚实。过去容器一套账、整机一套账，月底对账要人工拼合，现在天然一份账本，谁用了多少、闲了多少，随时可查。对需要向上汇报资源利用情况的管理者，这份账本省去了不少整理功夫。统一视图一旦建立，混部就具备了扎实的工程基础。

三、同一集群怎么统一纳管

统一纳管体现在几个层面。资源层面，所有节点的卡都进同一个池子，用标签区分节点适合的形态，比如带高速互联的机器标记为适合整机分配。调度层面，一套调度器处理所有请求，按任务声明的形态偏好挑选节点：要整机的任务匹配空闲的整机节点，要容器配额的任务落在容器节点上。账号层面，使用者和项目在两边的权限体系是打通的，同一个团队既能拿到裸金属也能用容器，配额统一计算。有了这三层的统一，混部才名副其实，否则只是两套系统摆在同一个机房里各干各的，管理负担反而更重。

纳管的颗粒度也值得设计。账号和项目组作为基本单位，配额跟着项目走，成员变动只影响权限不影响资源。项目结束后资源自动回收，防止出现人走了资源还挂在名下的情况。这套机制让混部集群的账目长期保持清爽，扩容缩容也都有账可查。

四、资源切分与隔离怎么做

混部环境里要防住两种互相伤害。一种是容器任务之间抢资源，这靠容器层面的配额和隔离机制解决，每个任务限定卡数、显存上限和带宽份额。另一种是容器任务与裸金属任务撞车，调度器必须保证：一旦某台机器被整机分配出去，这台机器就不再接受任何容器任务，直到整机释放回池子；反过来，整机任务也只能落在完整空闲的机器上。实现上通常按节点粒度做互斥，或者把一部分机器固定为容器专区、另一部分固定为整机专区，物理分区加逻辑互斥双管齐下，边界最清晰，出了问题责任也最好界定。

隔离不只是防抢，也是为了可预测。任务提交时就知道自己能拿到多少资源、和谁同机，运行表现才稳定可复现。对需要做性能对比的实验，这一点尤其重要，资源边界模糊的环境里测出的数字，换个时间就复现不了。配额调整也应留缓冲，改完之后观察一两天再继续动，频繁改动会让使用者无所适从。

五、调度怎么识别形态需求

任务对形态的需求可以写进提交描述里。大模型训练任务可以声明需要整机独占、需要机器内高速互联，调度器据此优先给裸金属；推理服务和批处理任务声明卡数即可，落在容器区。更讲究的做法是拓扑感知调度：训练任务的多台机器尽量挑网络距离近的节点，机器内部按卡间互联关系分配。形态偏好也允许弹性处理，比如任务声明优先裸金属、接受容器兜底，资源紧张时也能先跑起来。调度策略保持可配置，不同课题组、不同任务类型的偏好都可以单独设定，用得越久，这些配置越贴近真实业务。

对于既不极致追求互联、又想省心的任务，系统还可以自动选择：哪边资源就绪就先去哪边，任务描述里勾选接受自动分配即可。这类任务往往是兜底的大多数，让它们流动起来，整机区和容器区的利用率都能被填得比较满。

六、网络与存储怎么打通

混部集群里，两种形态最好共享同一套网络架构和存储体系。网络方面，容器任务和裸金属任务都在同一个高速网络里，跨形态的数据传输不用绕路，训练任务读写共享数据集的体验保持一致。存储方面，统一接入同一套共享文件系统，无论任务跑在容器里还是裸金属上，看到的数据路径都相同，代码和数据不用为形态差异做两套准备。打通之后还有一个好处：任务可以在两种形态之间迁移，前期试验用容器，正式训练转裸金属，环境不换，迁移成本低。数据集集中存放还省去了来回复制的等待，对大体量的训练数据尤其友好。统一存储也让权限管理更简单，数据权限跟着目录走，两种形态的任务执行同一套规则。

安全边界同样要考虑。两种形态的任务对网络的访问范围应当一致管理，谁的权限到哪里，不因形态不同而出现口径差异。统一的安全策略配合统一的网络体系，混部环境才不至于在安全上留下缝隙。

七、运维视角怎么统一

混部给运维提出了统一化的要求。监控上，所有节点的卡温度、显存占用、故障计数进同一套看板，不因形态不同分成两拨。日志上，容器任务和整机任务的操作记录统一归档，审计追溯一套流程走完。故障处理上，坏的卡或坏节点从资源池摘除，两种形态的任务都会自动绕开。镜像与环境方面，尽量让同一份软件环境既能装进容器也能部署到整机，减少两套维护。运维统一做得好，使用者感知不到形态差异带来的额外负担，混部的价值才能真正落地，而不是省了硬件却赔上人力。

日常巡检建议固定节奏：每周看一遍整机区占用与排队，每月盘点一次容器配额与实际用量的差距，每季度复盘分区比例。节奏固定下来，混部就不会失控；拖到问题爆发再查，代价要大得多。故障演练也可以顺带做一次，摘掉一张卡看调度是否绕行、告警是否及时，验证过才算真正准备好。

八、实践建议与常见问题

落地混部有几条经验。先做容量盘点，弄清楚多少机器固定给整机、多少给容器、多少机动，分区比例依据业务构成来定，宁可先紧后松。给关键任务留余量，不要把池子排满，整机释放和容器归还都有时间差，满负荷运转容易出现互相等待。定期复盘利用率：整机区长期空闲说明分区过宽，容器区排队严重说明该扩。常见问题包括整机长期被个别团队占用不释放，需要配回收策略和定期沟通；容器任务显存超用挤占同机任务，要靠配额硬约束。混部是手段不是目的，最终衡量标准是整个集群的利用效率和使用体验。

新起步的团队有个简单的开局办法：先划出小部分机器试混部，跑两三个月积累数据，再决定要不要扩大范围。试点期的记录越细，后续推广的底气越足，这比一开始就全面铺开、边跑边改要稳当得多。