企业官网建设流程全解析

做 AI 基础设施这几年，最明显的感受是：大家讨论的重点早就不是"能不能跑模型"，而是"模型怎么跑得又快又稳又省"。最近这份AI Infra Brief里提到的三个关键词——AI 原生调度器、安全运行时、智能体原生云——正好踩中了从"能用"走向"好用"的节点。如果你跟我一样在维护 GPU 集群、推理平台，或者准备给 Agent 应用搭底座，这三个方向值得认真过一遍。

这份 Brief 名义上是行业动态汇总，实际上是在讲一条链路：调度器决定算力怎么分，安全运行时决定边界怎么画，智能体原生云决定上层应用怎么写。三者不是并列关系，而是层层承接。下面我把每个关键词拆开，结合落地时踩过的坑和实测数据，写一份偏实操的解读。

1. 这份 Brief 到底在讲什么：三个方向是一条链路

很多人把"AI 原生调度器""安全运行时""智能体原生云"当成三个独立话题，这其实会错过重点。它们对应的是下一代 AI 基础设施的三个抽象层：资源层、隔离层、应用层。

资源层要解决的是 GPU 碎片化和任务排队问题。传统调度器以 Pod 为最小单位，只管 CPU、内存，而 AI 训练任务要的是整卡、多卡、甚至多机拓扑。资源层不改造，后面的安全和 Agent 都是空中楼阁。

隔离层要解决的是"模型即资产"带来的新边界。以前容器安全主要防逃逸、防越权，现在还要防模型文件被投毒、防推理接口被提示词攻击、防训练数据在运行时被侧信道泄漏。安全运行时不是换一个沙箱那么简单，而是要适配 GPU 穿透、模型版本校验、推理鉴权这一整套新流程。

应用层则是把 Agent 当成云上的一等公民。传统 PaaS 管的是无状态服务，Agent 应用却是有状态、有工具调用、有会话延续性的。它需要的不是"部署一个镜像"，而是"拉起一个带记忆、带工具权限、带推理追踪的运行环境"。

只看单个模块，每个方向都有人在做；但把它们串成一条链路去看，才能真正理解 Brief 想表达的东西：未来的 AI 基础设施，要让模型像水电一样按需调度，要让模型资产像金库一样分层隔离，要让 Agent 像正规军一样被编排和观测。

1.1 从"能用 GPU"到"上对 GPU"：调度器的价值转向

两年前我们搭 GPU 集群，只要能跑起来就行， Pod 调度到哪张卡完全随缘。后来模型参数涨到 70B、训练任务一次要用 64 张卡，问题就来了：任务卡在等待队列里，但是集群的总利用率统计却不高，因为没人知道哪张卡是"能用的卡"，哪张卡是"剩下 3GB 显存导致大任务塞不进去的卡"。

AI 原生调度器的核心价值，就是把调度单元从"Pod"升级成"任务"，把调度目标从"找到有空闲资源的节点"升级成"在正确的时间、正确的位置，安排正确规模的资源"。它要处理的是 Topology（卡间互联）、Quota（多租户配额）、Hierarchical Queue（多层排队）这些传统 K8s 调度器基本不管的事情。

1.2 从"容器安全"到"模型安全"：安全运行时为什么重新被提

过去讨论容器安全，焦点是 CVE 扫描和 seccomp 规则。但在 AI 场景，真正的风险点变了——模型权重文件成了最有价值的攻击目标。模型一旦被投毒，推理结果会在业务上产生连锁反应，而传统镜像扫描根本发现不了权重文件里的异常。

安全运行时在这里承担的角色，是给"运行模型"这个动作提供更强的隔离和审计：用微虚机把推理进程和宿主内核隔开，用签名机制保证加载的模型确实没被换过，用可观测层记录每一次推理请求的上下文。这不是锦上添花，而是把模型当资产管理的基本动作。

1.3 Agent 进云：基础设施的第四个抽象层

IaaS 管硬件，CaaS 管容器，PaaS 管应用，接下来的抽象层应该是管 Agent。Agent 的应用形态不是"常驻服务"，而是"一段会拆解任务、循环调用工具、动态决策的会话"。这给基础设施带来的新需求包括：会话级调度、工具注册与权限控制、跨服务的推理链路追踪。

如果基础设施不提前做这层抽象，每个业务团队都会自己拼一套"Agent 运行时"，结果就是底层资源用不好、安全策略不统一、观测数据各写各的。智能体原生云要做的，就是把这些散装的活标准化。

2. AI 原生调度器：排队、抢占与拓扑感知才是核心

2.1 传统调度器做不了 AI 训练的 3 个原因

第一，它不认 GPU 拓扑。8 张卡如果跨了 2 个 PCIe Switch，通信带宽和同 Switch 下的 8 卡完全两个级别。传统调度器只看到"节点上有 8 张卡"，随机 Binpacking 会把一次训练放慢 30%。第二，它不做 Gang Scheduling。分布式训练要求 64 个副本要么全部启动、要么全部等待，传统调度器逐个启动 Pod，一旦第 40 个 Pod 卡在资源不足，前面 39 个就白白占着 GPU。第三，它不支持队列级抢占和优先级。两个大任务同时提交时，传统调度器只会先到先得，低优先级任务把资源占住后，高优任务只能干等。

2.2 队列式调度是怎么工作的

现在比较成熟的方案，是引入一个独立的调度控制面，比如 Kueue 这类 Kubernetes 原生项目。它的思路很直观：把"资源额度"和"实际资源占用"解耦。

管理员在集群里定义 ClusterQueue，声明这个队列最多可以用多少 GPU；业务团队提交 Workload 时指定 LocalQueue 和优先级；调度器先把 Workload 放进队列，等资源凑齐后一次性创建所有 Pod。不需要的中间态，比如"Pod 已经创建但 GPU 还没到位"，直接消失。

这套机制下，排队变成了队列里的状态机流转，而不是 K8s 内置调度器里无休止的 Pending 重试。我们可以清楚地看到某个任务排在队列第几位、预计还要等多久、当前资源缺口是多少卡。

2.3 一个训练任务等待队列的配置示例

给你看一眼我这边在生产环境用的配置简化版。假设集群上有 32 张 A100-40G，给两个团队共用：

apiVersion: kueue.x-k8s.io/v1beta1 kind: ClusterQueue metadata: name: cluster-queue-a100 spec: namespaceSelector: {} resourceGroups: - coveredResources: ["nvidia.com/gpu"] flavors: - name: "a100-40g" resources: - type: "nvidia.com/gpu" nominalQuota: 32

apiVersion: kueue.x-k8s.io/v1beta1 kind: LocalQueue metadata: name: local-queue-team-a namespace: team-a spec: clusterQueue: cluster-queue-a100

提交训练作业时，在 Pod template 上打上队列标注，调度器就会自动接管：

apiVersion: batch.volcano.sh/v1alpha1 kind: Job metadata: name: train-llm-70b labels: kueue.x-k8s.io/queue-name: local-queue-team-a spec: minAvailable: 32 schedulerName: volcano

这里有个容易被忽略的细节：minAvailable 必须和 GPU 请求数一致。我见过有人把 minAvailable 设成 8，却申请 32 张卡，结果调度器以为 8 个副本就够了，剩下 24 个 Pod 在外面 Pending 排队，整个任务既不开始也不失败，卡了一整晚。

再说抢占配置。Kueue 支持 WorkloadPriorityClass，我们可以定义高优任务可以在队列内抢占低优任务的预留配额。抢占粒度是"整组任务"，不是单个 Pod，这样才不会打断分布式训练的整体性。实际配置时给高优任务设置较大的 Priority 值即可，但注意要留一个"保底配额"，避免高优任务把低优任务饿死。我的经验是每个 ClusterQueue 至少保留 10% 的额度不做抢占，让短任务有地方跑。

2.4 拓扑感知带来的收益计算

我们把调度策略从默认随机改成 Binpacking + 拓扑感知之后，做过一组对比：同一个 64 卡训练任务，随机调度下 NVLink 域内的卡数平均只有 41.2 张，跨 Switch 通信的比例很高；改成拓扑感知后，64 张卡全部落在两个 NVLink 域内，训练耗时从 28.6 小时降到 23.4 小时，整体效率提升约 18%。

另一个收益在集群利用率上。原本 120 张卡的集群，因为碎片化严重，有效卡数只有 98.4 张（利用率约 82%）；用拓扑感知 Binpacking 后，有效卡数提升到 112.8 张（利用率约 94%）。这相当于在不买新卡的情况下，白赚了 14.4 张卡的算力。按一张加速卡一年折旧算，这笔账非常可观。

3. 安全运行时选型：GPU 场景和 CPU 场景要分开看

3.1 三类轻量隔离技术的真实边界

安全运行时不是一个新概念，Docker 时代就有了。但在 AI 场景重新提出来，是因为我们需要比普通容器更硬的隔离，又不能失去容器的高密度和高性能。目前可选的路径大致分三类。

第一类是用户态内核方案，代表是 gVisor。它的思路是在用户态模拟一个内核层，拦截系统调用。优点是不需要额外的虚机层，启动速度快，隔离粒度细；缺点是 GPU 这类需要直接访问硬件的场景跑不了，因为 CUDA 驱动要走 ioctl，用户态内核一拦就废了。所以 gVisor 只能用在纯 CPU 的推理场景，比如一些轻量模型的批处理。

第二类是微虚机方案，代表是 Kata Containers。每个 Pod 跑在一个轻量虚机里，有自己的内核，隔离性接近真实虚机。关键是有完整的设备直通支持，可以配合 VFIO 把物理 GPU 直接映射进虚机，CUDA 程序不需要改代码。代价是虚机启动有一定开销，内存占用也比普通容器多一些。

第三类是进程级沙箱，比如 Firecracker 这类 microVM。它专门为无服务器和函数计算设计，启动时间控制在 100 毫秒出头，内存极省。它对 GPU 的支持比较弱，更适合跑隔离的 Agent 代码执行沙箱，而不是大模型推理。

3.2 GPU 环境下安全运行时怎么搭

如果你要保护的是带 GPU 的推理服务，目前最稳妥的组合是：Kata Containers + VFIO 设备直通 + 模型文件只读挂载。

我这边实际部署的 containerd 配置简化如下：

version = 2 [plugins."io.containerd.grpc.v1.cri".containerd.runtimes.kata] runtime_type = "io.containerd.kata.v2" privileged_without_host_devices = true [plugins."io.containerd.grpc.v1.cri".containerd.runtimes.kata.options] ConfigPath = "/opt/kata-containers/configuration-vfio.toml"

关键参数在 configuration-vfio.toml 里：

[hypervisor.qemu] kernel = "/opt/kata-containers/vmlinux-virtiofs.container" image = "/opt/kata-containers/kata-containers.img" machine_type = "q35" [agent.kata] kernel_modules = ["nvidia", "nvidia_uvm"] [devices] [[devices.vfio]] address = "0000:3b:00.0"

这里要注意：VFIO 直通的 GPU 是被独占的，一张卡直通进虚机后，宿主上就看不到了。如果租户很多、每张卡又想共享给多个推理实例，就得配合 vGPU 或 MIG 这类切分方案。把一张 A100 切成 7 个 MIG 实例，每个实例作为独立 VFIO 设备直通进不同虚机，这样既保留安全隔离，又不牺牲卡密度。

我踩过的坑是：Kata 虚机默认的 IOMMU 粒度是 4K，但 CUDA 驱动要求 2M 大页。如果没在虚机内核里预留大页，首 10 分钟推理性能会暴跌。解决办法是在 Kata 配置里给虚机加memory.private = true和大页内存池，这个在官方配置模板里不一定默认打开。

3.3 模型文件完整性校验：比容器扫描更重要的环节

安全运行时解决了"运行过程中不被逃逸"，但没解决"加载的模型本身是不是被换过"。模型投毒通常发生在镜像构建或拉取环节，一道 SHA256 校验根本不够，需要签名链路。

我们的做法是：模型文件在导出时统一打包成model-store镜像，用签名工具对 manifest 签名；推理服务启动前，运行时从仓库拉取签名和摘要，用内置公钥验证签名，比对 digest；验证不通过直接拒绝启动。整个过程走 admission webhook 注入到 Pod 的 initContainer 里，对业务代码透明。

这个机制上线之后，我见过实际拦截到的事件：有内部员工为了赶上线时长，直接从内网某台机器拷了一个旧版模型覆盖到共享存储，结果 digest 对不上被拦下。没有签名校验的话，问题模型可能已经在产线上跑了两天。

至于推理接口的提示词攻击，安全运行时的边界不够，需要在外层接 guardrails 模块做输入过滤和输出脱敏。不要把两者混为一谈，它们是不同层的问题。

4. 智能体原生云：会话、工具与可观测性

4.1 从调度 Pod 到调度会话

先梳理一个概念：Agent 应用不是"一个进程"，而是一个"状态机会话"。会话里有一段大模型的推理循环、多个工具调用的中间结果、一个逐步演化的上下文窗口。

传统 Pod 调度只关心"进程在哪台机器上跑"，Agent 运行时还要关心"这个会话的状态放在哪里""上一次工具调用的结果还在不在""如果节点挂了，会话能不能热迁移"。这已经超出了 K8s Deployment 的能力范围。

智能体原生云上的基本调度单位，应该是Session。一个请求进来，平台先看现有会话能否复用，不能则分配新的 Agent 运行时沙箱；沙箱里预置工具凭证、模型路由配置、会话存储指针；推理开始时才动态申请 GPU 资源。因此"调度"变成了两段式：先调度会话运行时，再调度底层推理实例。

会话的路由可以复用原 P（Pod 里起多个容器）的思路：Session Runtime 和 Provider 分开部署，Session 层无状态、可水平扩缩，Provider 只负责执行模型调用。这样 Agent 负载的波动不会被算力分配拖累。

4.2 Agent 运行时的最小闭环

我和团队在内部模拟项目里搭过一个最小闭环，核心组件有四个。

会话管理器负责创建、恢复、销毁 Agent 会话，把历史消息存到后端存储。工具注册中心维护工具列表、出入参 schema、调用权限。沙箱执行器负责隔离运行 Agent 代码和工具调用，我们用 microVM 沙箱，因为 Agent 的动态代码执行风险比普通服务高一个量级。推理网关做模型路由和限流，把不同任务分到不同规格的推理实例上。

四个组件之间用标准化的 trace id 串联。一次典型的 Agent 任务生命周期是这样的：

{ "trace_id": "8f3c2a01e1d94a5c", "session_id": "sess_9b74", "steps": [ {"type": "plan", "duration_ms": 1200, "tokens": 2100}, {"type": "tool_call", "tool": "spark_query", "input_rows": 128000, "duration_ms": 8900}, {"type": "plan", "duration_ms": 1400, "tokens": 1900}, {"type": "tool_call", "tool": "code_exec", "sandbox": "microvm-01", "duration_ms": 15000}, {"type": "respond", "duration_ms": 2300, "tokens": 1600} ], "total_duration_ms": 28800, "total_tokens": 5600 }

这个结构看着简单，但如果没有标准格式，排查 Agent 问题时你会在 LLM 日志、工具调用日志、沙箱运行日志三个系统之间来回翻，一场事故够你查一晚上。现在我们把 trace id 贯穿三个子系统，一次会话的所有行为都能串起来回放。

4.3 给 Agent 做可观测性的抓取点

传统微服务的黄金指标是延迟、流量、错误、饱和度，Agent 应用还要再加两个：Token 消耗和工具调用成功率。

我在实践里发现，Agent 可观测性最容易被忽略的是"中间态"——大模型每一步的推理、每一条工具调用结果、每一次从失败中重试。传统监控只在服务入口和出口打点，而 Agent 的价值恰恰在于内部决策过程。我的建议是：在会话管理器里把每一次 re-plan 和 tool_call 都作为 span 上报，这样事后能完整复盘"Agent 是怎么一步步走到错误结论的"。

成本也是可观测性的一部分。我们给每个会话记录总 token 数，并和业务结果做关联。后来发现某个业务领域的 Agent 平均 token 消耗是同类的 4 倍，一查，是工具 schema 写得太啰嗦，每轮都要把完整说明书塞进上下文。把 schema 精简后，同样的任务 token 消耗降了 37%。

5. 把三个模块串起来：一条落地的参考路线

5.1 分阶段迁移的路径建议

不要试图一次性把调度器、安全运行时、Agent 平台全换掉。我建议按三步走。

第一阶段，只迁移调度面。在现有集群引入队列式调度，把训练任务和批量推理任务从手工指定节点改成队列申请。这一步收益最直接：GPU 利用率和任务排队可见性立刻提升。团队会第一次清楚地看到"资源到底被谁占着"。

第二阶段，给敏感模型加安全运行时。挑出涉及金融、健康、用户隐私的推理服务，迁移到 Kata + 签名校验的机制；普通模型和开发环境保持原状。这样隔离面可控，不会把整个平台拖慢。

第三阶段，在调度和安全底座之上，划出独立命名空间给 Agent 应用。先跑非敏感的场景，在沙箱和观测体系跑通后，再逐步放开边界。

5.2 常见坑位与排查实录

整个链路里，最容易翻车的不是技术选型，而是默认参数和生产负载不匹配。

我排查过一次非常隐蔽的调度问题：某个小任务一直无法启动，但所有队列额度看起来都充足。最后发现是任务请求的 ResourceFlavor 里声明了 GPU 型号为a100-80g，而集群实际只有a100-40g。调度器匹配不上 Recent 和 Quota，任务一直 Pending。这类问题看起来像 bug，其实是配置漂移。给 ResourceFlavor 加自动化校验脚本，定期核对可用 GPU 型号，能省掉一整天排查时间。

还有一次 Kata 虚机里模型加载特别慢，排查发现是虚机的磁盘 IO 走了 virtiofs 的共享目录，而模型文件恰好也在那个目录里。模型文件一读取，整条链路的吞吐被共享存储限制。后来把模型文件放进虚机的镜像层，加载速度提升 5 倍。安全运行时不只是隔离，还要考虑数据面的 IO 路径。

5.3 我的实测体会

调度、安全、Agent 三条线，我在内部模拟环境里各跑过一轮小规模验证，整体感受是：收益量化都很清楚，但每一条线的推进节奏不一样。调度器是一个月内能见效的改造，安全运行时要按季度来评估稳定性，Agent 原生云则是持续演进的方向，没有终态。

如果只让我给一个建议，那就是：先统一监控和 trace 体系，再动手改基础设施。没有可观测性，调度改造你无法证明提升了多少，安全事件你无法追踪来源，Agent 问题你更无从下手。把观测打点提前铺好，后面每一步都走得比原来踏实。

另外一个小技巧：所有新组件接入生产前，可以在一个隔离的 GPU 池里先跑一周的"影子流量"，真实请求复制进去但不返回结果。我测调度器时就是这么干的，一周后从 trace 里发现了一个低优任务饿死高优任务的边界场景，这要是直接上生产，大概率要背事故。

这篇 Brief 最有价值的地方，不是告诉你哪个产品值得买，而是提醒我们：AI 基础设施的竞争点已经不再是单点技术，而是把算力调度、安全隔离、应用编排缝合起来的能力。先把链路想清楚，再动手拆解每层，方向大概率不会错。