从按需扩容到共享 GPU 池：UiPath 如何支撑企业级 Agentic AI

当自动化系统从执行固定步骤，升级为能够理解文档、识别界面、调用模型并自主决策的 Agentic AI，基础设施面对的已经不只是“多部署几张 GPU”。训练任务需要大量高性能算力，在线推理要求稳定低延迟，全球化服务还要兼顾区域容量与成本。

UiPath 为智能文档处理和自主智能体重新设计了 GPU 平台：不再为每个产品维护独立集群，而是通过机器学习服务平台统一管理共享 GPU 池，在 Google Kubernetes Engine 上组合 A3 与 G4 VM，并使用 Dynamic Workload Scheduler 提前安排稀缺训练容量。

这次改造最值得关注的，不是某一种 GPU 的性能，而是容量管理方式从“工作负载来了再扩容”转向“在平台层统一规划、调度和复用”。

为什么逐个产品扩容开始失效

早期 AI 项目的常见做法是：某个团队需要训练模型时创建 GPU 节点，任务结束后缩容；推理流量增长时，再临时增加实例。只要 GPU 容量充足、供应稳定，这种模型简单而直接。

规模扩大后，三个问题会同时出现。

峰值容量长期闲置

在线推理流量通常有明显的昼夜周期。为了应对峰值，团队必须准备额外容量，但这些昂贵 GPU 在低谷时段可能没有任务。单个产品看似拥有充足余量，整个公司却可能同时存在一批利用率很低的独立集群。

高端 GPU 不是无限供应

大规模训练和微调需要高带宽互联与高性能 GPU。UiPath 使用搭载 NVIDIA H100 的 A3 VM 承担此类任务，但市场需求使高端容量无法像普通虚拟机一样随时获取。继续依赖即时扩容，会让训练计划受制于当时是否有可用节点。

训练和推理的目标不同

训练关注吞吐量、并行效率和任务完成时间，可以接受排队和预定窗口；在线推理关注尾延迟、可用性与稳定容量，通常不能等待资源释放。把两类任务混在同一套简单自动扩缩容规则中，容易出现两种结果：训练挤占生产推理，或者为保护推理而让高端 GPU 长期空闲。

共享 GPU 池改变了什么

UiPath 将 GPU 视为平台级战略资源，由机器学习服务平台 MLS 在团队、任务和时间窗口之间统一分配。白天优先运行实时推理与延迟敏感任务，夜间或低峰时段则将空闲容量切换给批量训练和长时间作业。

其核心不是让每个 Pod 更快启动，而是让调度器理解不同工作负载的业务优先级：

这种设计能够平滑不同产品的流量峰值。例如，一个团队的推理请求进入低谷后，释放出的容量可以被另一个团队的批处理任务利用，而不是继续绑定在原产品名下。

共享并不意味着所有任务可以无条件争抢资源。平台必须同时提供配额、优先级、抢占规则和容量预订，否则独立集群的问题只会变成共享集群中的资源争用。

用不同 GPU 承担不同工作

UiPath 没有把所有任务都放到最高规格硬件上，而是按工作负载选择 GPU：

• A3 VM 与 NVIDIA H100 用于大规模训练和微调，重点是训练吞吐量与多 GPU 扩展效率。
• G4 VM 与 NVIDIA RTX PRO 6000 用于较轻的推理任务，在性能和价格之间取得更合适的平衡。
• Dynamic Workload Scheduler 用于提前安排短期训练容量，使工程团队能够围绕已确认的计算窗口制定计划。

这里有一个容易被忽略的成本原则：推理服务需要的是满足延迟目标的最便宜配置，而不是单卡性能最强的配置。若一个模型在较经济的 GPU 上已经能够达到吞吐量和 P95 延迟要求，把它放到 H100 上通常只是在占用本可用于训练的稀缺资源。

硬件选型应通过基准测试决定。至少记录以下指标：

• 单请求和批处理场景下的 P50、P95、P99 延迟
• 每张 GPU 每秒处理的文档页数或 token 数
• 峰值显存与稳定运行时的显存余量
• 不同批大小下的吞吐量变化
• 单位文档、单位 token 或单位任务的实际成本

可以这样实践：在 Kubernetes 中表达调度意图

下面是一个可改造的 GKE/Kubernetes 示例。它不代表 UiPath 的内部配置，而是演示如何把“在线推理优先、批量训练可排队”的原则写进集群资源对象。

运行前需要把节点标签 accelerator 的值改成集群实际使用的标签，并确认 NVIDIA device plugin 已经能够暴露 nvidia.com/gpu 资源。

先为在线推理和批处理定义不同优先级：

apiVersion: scheduling.k8s.io/v1
kind: PriorityClass
metadata:
  name: online-inference
value: 100000
preemptionPolicy: PreemptLowerPriority
globalDefault: false
description: "Latency-sensitive production inference"
---
apiVersion: scheduling.k8s.io/v1
kind: PriorityClass
metadata:
  name: batch-training
value: 1000
preemptionPolicy: Never
globalDefault: false
description: "Queueable training and evaluation jobs"

在线推理 Deployment 可以绑定推理节点池，并保留明确的 GPU、CPU 与内存资源：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: document-inference
spec:
  replicas: 2
  selector:
    matchLabels:
      app: document-inference
  template:
    metadata:
      labels:
        app: document-inference
    spec:
      priorityClassName: online-inference
      nodeSelector:
        accelerator: rtx-pro-6000
      containers:
        - name: server
          image: us-docker.pkg.dev/PROJECT_ID/ai/document-server:VERSION
          ports:
            - containerPort: 8080
          resources:
            requests:
              cpu: "4"
              memory: 16Gi
              nvidia.com/gpu: "1"
            limits:
              cpu: "8"
              memory: 24Gi
              nvidia.com/gpu: "1"
          readinessProbe:
            httpGet:
              path: /ready
              port: 8080
            initialDelaySeconds: 20
            periodSeconds: 5

夜间批量训练则以 Job 提交到 H100 节点，并使用较低优先级：

apiVersion: batch/v1
kind: Job
metadata:
  name: document-model-finetune
spec:
  backoffLimit: 1
  template:
    spec:
      restartPolicy: Never
      priorityClassName: batch-training
      nodeSelector:
        accelerator: nvidia-h100-80gb
      containers:
        - name: trainer
          image: us-docker.pkg.dev/PROJECT_ID/ai/document-trainer:VERSION
          args:
            - "--config=/configs/finetune.yaml"
            - "--output=/checkpoints/run-001"
          resources:
            requests:
              cpu: "48"
              memory: 256Gi
              nvidia.com/gpu: "8"
            limits:
              cpu: "48"
              memory: 256Gi
              nvidia.com/gpu: "8"

应用资源前可以先做服务端校验：

kubectl apply --dry-run=server -f priority-classes.yaml
kubectl apply --dry-run=server -f inference.yaml
kubectl apply --dry-run=server -f training-job.yaml

kubectl apply -f priority-classes.yaml
kubectl apply -f inference.yaml
kubectl apply -f training-job.yaml

kubectl get pods -o wide
kubectl describe job document-model-finetune

生产平台还应在这套基础上增加命名空间配额、PodDisruptionBudget、拓扑分布约束、任务队列、公平共享策略以及 GPU 利用率监控。仅设置 PriorityClass 并不能构成完整的共享 GPU 平台。

调度系统真正需要哪些控制面

从独立集群走向共享池后，机器学习平台需要承担比 Kubernetes 默认调度更多的职责。

准入控制决定任务是否可以进入队列。训练任务应声明 GPU 数量、预计时长、最晚完成时间和是否允许中断。缺少这些信息，平台很难进行容量规划。

公平共享避免某个团队持续占满资源。可以给每个业务单元设置基础配额，同时允许其在其他团队空闲时借用剩余容量。

时间窗口调度把可延迟任务移动到夜间或已预订的容量窗口。UiPath 借助 DWS 从被动寻找 GPU 转为提前锁定训练容量，这提高了供应和成本的可预测性。

硬件匹配根据模型显存、延迟目标和并行策略选择节点池。调度器不应默认把所有 GPU 任务发送到最高端节点。

可观测性与计费归属需要回答：哪支团队使用了多少 GPU 小时、利用率是多少、排队多久、每次训练或每千次推理的成本是多少。没有这些数据，共享池很快会失去治理依据。

从试点走向生产的检查清单

UiPath 的实践可以归纳为三个决策：解耦产品与硬件、提前调度稀缺容量、按任务选择合适芯片。团队落地时可以按以下顺序推进：

1. 盘点训练、在线推理和批处理任务的峰谷周期，不要只统计平均 GPU 利用率。
2. 将 GPU 所有权从产品集群上移到平台层，先选择少量可排队任务进入共享池。
3. 为生产推理定义不可妥协的延迟和可用性目标，并预留基线容量。
4. 为训练任务增加预计时长、GPU 数量、截止时间和可中断性等调度元数据。
5. 分别在高端训练 GPU 和经济型推理 GPU 上进行基准测试，以单位业务成本而非卡型决定部署位置。
6. 引入预约容量或动态工作负载调度机制，避免关键训练在最后一刻寻找供应。
7. 上线团队配额、公平共享、成本归属和队列等待时间监控，再逐步迁移更多工作负载。

共享 GPU 池并不会自动降低成本。只有当平台能够识别任务优先级、利用时间差复用容量，并阻止高端 GPU 被轻量任务占用时，它才会产生真正的效率收益。对企业级 Agentic AI 而言，这套调度与治理能力，往往比单纯增加 GPU 数量更能决定系统能否稳定扩展。