AI原生调度器、安全运行时与智能体原生云实践解析

这一期的AI Infra Brief更新于2026年3月24日。过去两周我大部分时间泡在GPU集群的调度器改造项目里，顺手对安全运行时做了两轮压测，然后又被一个智能体应用团队的会话恢复问题拉进讨论组。三件事几乎是挤在同一时间轴上出现的，所以这一期我不想做流水账式的信息罗列，只想集中聊三块：AI原生调度器、安全运行时、智能体原生云。

它们看上去是三块独立的技术栈，实际上有一条共同的暗线——计算资源正在从“给进程分配一台机器”变成“给一个复杂任务组织一台逻辑机器”。调度器、隔离边界、应用平台三者的语义都在跟着这条暗线一起变，谁先想明白这一点，谁搭出来的底座就能少返工半年。

如果你正在负责GPU集群的架构设计、多租户平台的隔离方案，或者在研究Agent应用的工程落地，这篇内容基本就是按你的问题清单写的。下面我拆开讲。

1. 为什么这一期Brief把调度、隔离、智能体放在一起聊

1.1 一条暗线：算力资源从“进程视角”转向“任务视角”

做传统云平台时，我们的心智模型很简单：应用是部署单元，容器是隔离单元，服务是访问单元，K8s这类控制系统把三者串起来就行。可当工作负载变成大模型训练和Agent任务之后，单元定义全变了。训练任务需要多卡协同，调度器脑子里必须有GPU拓扑、NVLink域、显存容量这些概念；隔离单元要保护的不再只是进程和端口，还有模型权重、Prompt上下文和数据缓存；业务单元也不再是固定API的Service，而是有状态、会拆解目标、会连环调用工具的Agent会话。

我把这条暗线概括为：算力资源从进程视角走向任务视角。这不是什么新口号，而是已经被真实需求逼出来的转变。调度器不再只问“这台机器够不够放一个Pod”，而要回答“这个任务要的8张卡能不能落在同一个通信域里”“显存碎片还剩多少”“多租户的队列公平性怎么保证”。安全运行时不再只防进程逃逸，还要防模型权重被跨租户读走。智能体原生云则要求平台把会话当成一等公民来管理，会话比Deployment更动态、更脆弱，也更需要基础设施兜底。

三者若分开做，单看每块好像都有解，但合在一起就发现它们是同一件事的不同切面。比如一个Agent要调用一次推理，这个推理实例跑在哪个GPU分区上，由调度器决定；它能不能安全读取某个租户私有的模型权重，由运行时决定；它执行到一半进程崩溃，会话能不能恢复，由平台决定。断掉任何一环，整个体验就崩了。

1.2 如果只关心其中一件事，从哪一章读起

我知道不是所有人都有精力把三块都啃下来。给你一条快速路径：如果你的核心痛点是算力利用率上不去、大任务频繁因为GPU碎片和拓扑错配而失败，直接看第2章和第5章的选型表，那里有调度策略组合和一套可以直接抄的落地步骤。如果你在搭多租户平台，担心第三方模型代码、内网数据权重泄露，重点看第3章，我压测时踩过的坑和隔离档位划分都在里面。如果你正在做Agent应用，被会话状态丢、工具调用重复执行、成本算不清这些问题缠住，第4章给了你一张基础设施能力清单。

三条线全部看完也不亏，但读之前先给自己定个调：现在最痛的那个问题是什么。是GPU用不起来，是不敢把任务放上集群，还是Agent跑起来但不稳。带着问题读，比我逐条灌输要有用得多。

2. AI原生调度器：调度语义从“容器”转向“计算拓扑”

2.1 传统调度器在GPU工作负载面前的失灵现场

先还原一下我最初在测试集群里看到的场景。一个需要8张卡做张量并行的训练任务提交上去，默认调度器只按CPU和内存做资源匹配，结果8张卡被散落在4台节点上，有的卡还在不同的PCIe switch域里。任务倒是启动了，但训练代码一跑通信就开始超时，每轮迭代慢得让人怀疑人生。更常见的情况是，某张卡显存已经碎得剩不下一个完整分配，任务在启动阶段直接OOM，随后整个Job反复重启，谁也不知道为什么。

这类问题本质上是信息缺失。传统调度器的资源模型是CPU、内存、磁盘，它对GPU的理解往往只是“有一块nvidia.com/gpu计数”，既不感知每张卡的显存剩余量，也不感知MIG分区形状，更不感知卡与卡之间的通信拓扑。AI负载恰好对这几项极其敏感。训练任务要的是大块连续显存和低延迟域内通信，推理任务要的是稳定的单卡或分区延迟，混合跑在一起后，调度器不认识这些差异，就只能乱点鸳鸯谱。

我在没拿到新调度器之前先用node label和nodeAffinity硬扛了一阵，给每个节点按拓扑域打标签，再用亲和性规则把8卡任务钉在同一批节点上。短期可用，长期非常痛苦：规则越堆越多，一换机型就得改配置，而且排队和优先级依然完全没有。这个阶段让我意识到，AI调度器要的不是在原有框架上打个补丁，而是把调度模型换成一套专门服务AI负载的东西。

2.2 两层调度架构：队列编排管“什么时候跑”，拓扑感知管“跑在哪”

我调研并实践下来，AI原生调度器至少要把调度拆成两层，缺一层都转不动。上层是队列编排，负责回答“什么时候跑”：按租户和配额把任务放进不同队列，做优先级、抢占、超时控制，还要支持Gang调度语义。下层是节点级调度，负责回答“跑在哪”：具体选哪几张卡、选哪个MIG分区、走哪条通信路径，如何做显存级binpacking。

为什么要两层？因为这两个决策的时间尺度和信息维度完全不同。队列编排管的是宏观公平和效率，它面对的是几十上百个任务，用FIFO、优先级、DRF这类策略就能工作；节点级调度管的是微观性能和碎片，它面对的是单节点的拓扑细节，需要显存、域、链路负载这些细碎指标。混在一层里做，调度器会变得极其复杂。K8s默认调度器试图把所有事情放在一个调度周期里，结果是难以充分表达AI负载的两类需求。

节点级调度里，AI负载尤其需要Gang语义：要么全部资源到位，要么任务不启动。原因不难理解，分布式训练里的集合通信要求所有rank同时就绪，否则就是大家一起干等，不但阻塞当前任务，还浪费已经占住的资源。没有Gang语义，一个大任务占住一半资源，另一个任务占住另一半，两者都在等对方释放，形成死锁式浪费。我见过最夸张的一次，集群里同时提交了三个8卡任务，每个都只抢到4张卡，结果谁也没法训练，空耗了一个多小时。

2.3 一次调度策略组合的实测数据与参数取舍

落地的时候，我的做法是先把任务模板按类型标记：training和inference两类，分别设定不同的调度策略。训练型任务入队后要求Gang等待，直到凑齐一个完整拓扑域再启动；推理型任务不追求多卡协同，按单卡或MIG分区直接放置。节点级打分函数我调成了“拓扑域匹配 > 空闲显存充足 > 通信负载均衡”三级权重，然后在放置阶段选择BestFit式的binpack而非Spread式打散。

这套组合在一个8卡位节点的测试集群上跑了两周，显存利用率从48%提到了76%，主要收益来自binpack把碎片压了下来。但有代价：某个需要完整8卡域的高优任务，会因为另一个任务占据域内一张卡而长时间排队。后来加了一条“预留拓扑域”策略，对重要的训练任务即便当前域没满显存，也保留一个完整域给它在队列里等待，问题才缓解。参数取舍的关键总结就是：不要全局统一策略。训练任务用binpack求吞吐，推理任务用spread求稳定，混着用必须靠队列和策略分开。

还有一个坑必须记下来：启用MIG分区后，调度器眼里一台机器可能冒出几十个“设备”，但每个分区的计算单元和显存形状差异很大。如果不在分区上打标签，调度器会盲目把分区当普通GPU分配，经常出现任务被安排到形状不匹配的分区上。要给每个物理卡、每个MIG分区都注册结构化标签，并且在任务模板里声明可接受的设备形状，等于让调度器从“会数数”升级成“会看图”。

3. 安全运行时：多租户与模型资产的双重压力

3.1 共享内核的容器方案，为什么在AI多租户场景里先被淘汰

很多新同学会对“容器不安全”这个说法产生疑惑：我们用Docker跑了好几年也没出大事啊。问题在于威胁模型不同。默认的runc类容器本质上共享宿主机内核，靠namespaces和cgroups做隔离，内核一旦有提权漏洞，逃逸之后宿主机上的所有租户、数据集、模型权重全部暴露。过去跑无状态Web应用，出事的后果是改数据；现在跑AI负载，一个第三方模型包、一个社区插件、一段AutoML生成的任意代码，都可能带着不可信色彩进入集群。

AI场景让风险被放大的另一个原因是资产价值极高。一个训练好的模型权重，可能是团队几个月算力烧出来的成果；一个内网的业务数据集，关系着真实业务决策。多租户GPU共享之后，相邻租户一旦逃脱隔离边界，看到的东西比传统容器场景更多。平台团队如果给不可信工作负载全部使用共享内核方案，本质上是在赌内核不出漏洞，这在AI多租户环境下很难通过内部评审。

所以我的结论很直接：多租户GPU平台需要把“隔离”当成默认能力，而不是事后加固项。隔离到什么程度，按数据等级和威胁模型分档，不见得什么都上重型方案，但至少不能让不可信代码和核心权重资产共享同一个内核域。

3.2 微VM与GPU共享结合的实测防线与坑

我把隔离方案按场景测了一轮。CPU负载下用户态沙箱很好用，依赖层简单、性能损耗可控，适合那些不碰GPU的业务逻辑和工具函数。GPU负载就比较麻烦，微VM方案加vfio设备透传可以做到比较强的隔离，但冷启动时间明显变长，短生命周期的推理Pod完全不适合走这条链路。后来我把策略定为：训练和批量任务用微VM+GPU透传，在线推理用轻量沙箱加MIG共享，数据最敏感的另走加密通道。

实操里面有个非常隐蔽的坑：vfio透传之后，微VM内部看到的设备编号和宿主机上的物理编号往往不一致，调度器和运行时层各有一套设备视图。如果不统一，任务就会被分配到一个“看起来存在但实际上和调度信息对不上”的分区。我们的解决办法是在微VM内部启动时主动上报设备拓扑元数据，部署系统根据这份元数据反查调度器的分配记录进行校验，两边对齐后才允许加载权重。多花了一点时间，但彻底排除了错分设备的隐患。

这轮压测下来我形成了一个固定的隔离分档认知。普通容器加Seccomp和强制访问控制，适合低敏感内部业务，性能最好；用户态沙箱适合CPU推理和工具逻辑，隔离与性能均衡；微VM加MIG分区块透传，适合多租户GPU训练，隔离最强但冷启动慢；最高一档则要引入可信执行环境，让密钥和权重只在特定硬件区域内可见。按这个梯度区分配置，既不会因为过度安全拖垮性能，也不会因为过度自信埋下隐患。

3.3 光有隔离还不够：镜像签名、度量启动与TEE这条信任链

隔离解决的是“破了能不能进来”的问题，但没有解决“运行的东西是不是被替换过”的问题。我在测试环境里见过一个更阴险的场景：镜像名没有问题，代码在构建产物里被注入了探针，运行时一加载就把敏感数据往外送。镜像签名这时候才真正体现价值，在构建阶段用私钥签名，部署阶段由策略引擎校验签名，校验不过直接拒绝拉取。

把隔离和校验串成一条信任链之后，流程大概是这样：镜像构建时签名，镜像仓库只放行签过名的产物；节点启动微VM时开启安全启动，度量组件把内核、沙箱、运行时固件等计算出度量值；控制面比对度量值与基线，不一致就禁止该节点接收敏感工作负载；通过校验后，密钥管理服务才把模型权重解密密钥下发到可信区内。这套链路的每一环都解决一类具体攻击，缺一环就存在可被利用的缝隙。

TEE这类方案在AI场景的落地要讲成本账。把整个训练过程塞进全密态计算，性能损耗和工程改动都很大，多数团队扛不住。更务实的做法是把模型权重保护起来：权重以密文形式挂载，密钥由硬件管理，外部不可直接读取；计算过程仍然在明文状态下执行，梯度和中间结果不落盘。这样既防住了最常见的“权重被拷走”风险，又不会把性能拖到不可用的地步。如果你想快速止损，最优先的动作其实是给权重落盘目录上强制防读策略，这一项措施往往比上一整套TEE更快见效。

4. 智能体原生云：基础设施开始给“任务执行者”留位置

4.1 当部署单元从“应用”变成“执行者”

传统应用的模型很清晰：一个Deployment对应固定逻辑，入口是Service，流量进来就处理，处理完就走，状态尽量外置。智能体完全不是这样。一个Agent会话可能要持续十几分钟甚至更久，它不知道下一步会调用哪个工具，可能一边看文档一边查数据，再根据结果决定要不要发起另一次模型推理。把它当普通Pod拉起销毁，会话上下文瞬间丢光，用户体验直接清零。

我通常会用一个不太严谨但很好懂的类比：传统服务是便利店，固定货架固定收银，来一个客处理一个；Agent是外卖骑手，路线动态变化，中途要跟商家、用户、平台反复沟通，手里还攥着订单状态。你不可能让骑手每完成一段路就重新注册一次身份。基础设施如果不认识“执行者”这个角色，就只能把Agent拆成一堆无状态的请求来处理，工程上非常别扭。

所谓智能体原生云，核心就是给这个“执行者”安排好基础设施身份。它需要自己的生命周期管理、会话存储、工具权限、事件通道、成本账户。它不是把传统PaaS换个界面，而是把Agent的运行特征当成平台设计的前提条件。

4.2 智能体原生云需要内建的基础能力清单

我把自己在项目里反复被要求的平台能力列成了一张清单，每一条背后都是具体的故障或痛点：

• 会话与记忆服务。Agent的上下文、委托状态、中间结论要持久化，支持崩溃后从检查点恢复，而不是丢给模型去“猜”。
• 工具注册与权限管理。所有工具统一注册成目录，每个租户能调用哪些工具由平台控制，避免Agent拿到一把万能钥匙。
• 事件总线。Agent之间、Agent与人之间通过异步事件解耦，不然多Agent协作时只能靠互相轮询，既慢又费token。
• 推理资源池。推理实例不能按“每个请求冷启动”来设计，要有复用、有队列、有扩缩容，最好能感知KV cache亲和性。
• 可观测性。Trace要穿透到“一次思考、一次工具调用、一次模型请求”的粒度，不然出了错根本定位不到是哪一步在烧钱。
• 成本计量。token消耗、GPU占用、工具调用费用全部聚合到session维度，财务和优化团队才有数据可依据。

这六项里面，最容易在早期被砍掉的是事件总线和可观测性。团队会觉得先把Agent跑通再说，结果就是集成测试时多Agent互相等不到消息、用户一个简单问题被重复调用了三遍工具，最后连账单都分不清是谁产生的。我现在的建议是：这六项在MVP阶段至少先做会话服务、推理资源池和可观测性，另外三项可以后补，但不能永远缺席。

4.3 会话状态恢复与session级可观测性：两个容易被低估的工程点

状态恢复是Agent落地最扎手的问题。Agent进程崩溃后不能简单重启，原因在于工具调用可能有副作用：如果Agent在“扣费”和“发邮件”之间崩溃，重启后重新执行一次就可能让用户被扣两次钱。这个问题的解法不是靠模型更聪明，而是基础设施给每个工具调用分配幂等键，两阶段确认工具执行结果，崩溃后从最近一个无副作用检查点恢复。工程上繁琐，但这是让Agent敢接真实业务的前提。

可观测性同样容易被低估。服务网格的标准metrics在Agent场景里不够用，你需要的是一条完整的“思考→工具→再思考→回答”链路。我后来把日志格式统一成了带session_id、agent_id、tool_call_id、model_request_id的结构，所有环节都打这几个维度，排查问题时的效率比从前靠抓瞎高出一个数量级。再往后，KV cache复用和session绑定之后还出现过一个怪问题：某个租户频繁切换会话，cache命中率急降，推理成本飙升。最后是靠给推理实例做租户亲和调度，让同一租户的会话尽量落到同一批实例上，才把命中率稳住。

5. 三条线汇流后的落地姿势与选型清单

5.1 一个端到端示例：用户请求如何穿过调度器、运行时与Agent会话

把三块拼在一起看，端到端的链路大概是这样的。用户在入口提交一个目标，平台创建出Agent会话，从记忆服务里取出历史和上下文；调度器根据这次会话要用的模型、延迟要求、租户优先级，把Agent实例和推理实例放到合适的节点上；推理实例需要GPU时，安全运行时按敏感度启动对应档位的隔离环境，训练型或者高敏感任务落到微VM加MIG分区上，同时校验镜像签名和节点度量值；Agent在运行过程中通过工具注册表调用工具，事件总线在多个Agent之间传递消息，每次模型调用都命中推理资源池；会话结束后，所有执行轨迹、token消耗和工具费用聚合到session账本里。任何一个环节缺位，用户感知到的就是任务卡死、状态丢失或者账单爆炸。

这三块在系统里不是串联的插件，而是互相约束的。调度器的选择会决定安全运行时落在哪个节点，运行时的隔离档位又会反向限制调度器能分配哪些资源，Agent会话的状态生命周期则要求前面两者都稳定可预期。架构上最好由一个统一控制面来编排它们，而不是让三个团队各自为政。

5.2 不同场景下的组合选型表

我在项目里沉淀了一份组合选型表，按场景给出推荐配置，你拿去可以对号入座：

这张表的核心理念是“按场景配比”，不是“一步到位”。最怕的就是买了一整套重型安全方案让所有workload都背上性能债，或者为了低延迟放弃隔离，回头再花几倍时间补安全。

5.3 不用大改架构就能先做的三个小改进

如果你还在老架构上，但想尽快向前挪一步，我个人建议按下面三个动作起步。这套组合拳不要求推倒重来，收益却立竿见影。

第一，给每个物理GPU打上拓扑域标签，至少把NVLink域和PCIe switch域标清楚。即便调度器不能真正做拓扑感知，你也可以用节点亲和性把大任务钉在同一个域内，通信性能立刻改善。我在项目里的第一周就靠这一招把训练任务的整体吞吐拉高了约三成。

第二，把不可信第三方代码统一迁到安全运行时，用RuntimeClass区分隔离等级，让低敏感和核心资产各走各的通道。这一步不用动业务代码，只改部署配置，就能把最可怕的一类风险从平台里先摘出去。

第三，给Agent会话统一打上session_id，把日志和成本数据全部按session聚合。先不管高级状态恢复，至少要把“一次用户请求到底花多少钱、调用了哪些工具”这件事看清楚，后续优化才有数据依据。很多团队管理混乱的根源不是模型不行，而是账目不清。

这三步做完，你对基础设施的感知会完全不一样，那时候再决定要不要上更完整的AI原生调度器或统一的智能体平台，判断会准确得多。

我自己这半个多月的体会是，AI原生调度器、安全运行时、智能体原生云真正难的地方不在某个单点技术，而在于它们都要求团队改变原有的分工。编排团队不能只管Pod生命周期，还得理解GPU拓扑和通信模式；安全团队不能只管端口和漏洞，还要盯着镜像供应链和模型资产；应用团队不能只写业务逻辑，得学会设计会话恢复和跨工具可观测性。调度和隔离是底座，底座没打稳就上Agent平台，大概率会把问题都归到模型头上，其实模型在替你背基础设施的锅。先挑一个最痛的场景打穿，比什么都重要。