Platform Engineering 1.0 已经证明了自己的价值：Golden Path 让部署更快，内部开发者平台降低了认知负担，自助式基础设施把开发者从工单队列里解放出来，标准流水线也让交付变得可复制。现在变化来了：AI 原生工作负载把平台从“帮应用上线”推向“帮模型、数据、推理和实验稳定运行”。
1.0 的成功经验仍然有用，但对象变了
过去的平台工程主要围绕服务交付：创建仓库、申请环境、配置 CI/CD、发布到 Kubernetes、接入日志和监控。它的核心是把重复路径产品化，让团队少做低价值决策。
AI 原生工作负载并没有推翻这个逻辑，但它扩大了平台要管理的对象：
- 不只是应用镜像，还有模型权重、向量索引、提示词模板和评测数据集。
- 不只是 CPU 和常规内存，还有 GPU、显存、批处理队列和推理并发。
- 不只是部署成功，还要关注模型质量、延迟、成本、漂移和安全边界。
- 不只是开发者体验，还要覆盖数据科学家、ML 工程师、应用工程师和平台团队之间的协作。
换句话说，Golden Path 仍然重要，但路径上的“路标”要换一批。
AI 原生平台需要把实验和生产连起来
传统 IDP 常常围绕“服务模板”展开：选语言、选数据库、生成流水线、部署环境。AI 工作负载还需要处理一个更难的问题：实验不是生产的反面，而是生产能力的一部分。
一个现实的平台能力可以这样拆：
- 实验入口：允许团队提交训练任务、评测任务或离线推理任务。
- 模型登记：记录模型版本、指标、数据来源和审批状态。
- 推理部署：把已批准模型部署成稳定服务，带资源限制和回滚策略。
- 可观测性：同时看系统指标和模型指标，例如延迟、错误率、token 成本、评测分数。
- 治理边界：明确哪些模型可以访问哪些数据，哪些环境允许外部 API 调用。
这里的关键不是堆更多工具，而是把这些能力做成开发者能理解的自助路径。平台团队需要把复杂性收进平台，把选择权留在合适的位置。
可以这样实践：给推理服务做一条最小 Golden Path
下面是一个可改造的 Kubernetes 示例。它不声称来自原文，而是展示 AI 原生平台可以如何把资源、部署和服务暴露为一条标准路径。
把镜像、模型路径、资源大小替换成你自己的值后即可改造使用。
apiVersion: apps/v1
kind: Deployment
metadata:
name: ai-inference-demo
labels:
app: ai-inference-demo
workload-type: ai-native
spec:
replicas: 2
selector:
matchLabels:
app: ai-inference-demo
template:
metadata:
labels:
app: ai-inference-demo
spec:
containers:
- name: inference
image: ghcr.io/example/ai-inference:0.1.0
ports:
- containerPort: 8080
env:
- name: MODEL_NAME
value: "recommendation-ranker"
- name: MODEL_VERSION
value: "v2024-09-15"
- name: MODEL_PATH
value: "/models/recommendation-ranker"
resources:
requests:
cpu: "1"
memory: "2Gi"
limits:
cpu: "2"
memory: "4Gi"
readinessProbe:
httpGet:
path: /ready
port: 8080
initialDelaySeconds: 10
periodSeconds: 5
livenessProbe:
httpGet:
path: /healthz
port: 8080
initialDelaySeconds: 30
periodSeconds: 10
---
apiVersion: v1
kind: Service
metadata:
name: ai-inference-demo
spec:
selector:
app: ai-inference-demo
ports:
- port: 80
targetPort: 8080
应用部署：
kubectl apply -f ai-inference-demo.yaml
kubectl rollout status deployment/ai-inference-demo
kubectl get pods -l app=ai-inference-demo
如果你的集群需要 GPU，可以把资源段改成类似下面这样。具体资源名取决于集群设备插件配置，例如 NVIDIA device plugin 通常使用 nvidia.com/gpu。
resources:
requests:
cpu: "2"
memory: "8Gi"
nvidia.com/gpu: "1"
limits:
cpu: "4"
memory: "16Gi"
nvidia.com/gpu: "1"
这类模板的价值不在 YAML 本身，而在平台把默认决策固化下来：健康检查、资源边界、版本标签、环境变量命名、发布方式和观测接入都应当一致。
平台团队要新增哪些产品能力
AI 原生平台不是把现有 IDP 改个名字。它至少需要补齐几类能力。
资源编排要更精细。 GPU 和高内存节点通常成本高、供给少，不能像普通 Deployment 一样随便扩。平台需要配额、队列、优先级、空闲回收和成本可视化。
流水线要覆盖模型生命周期。 传统流水线关注构建、测试、发布。AI 工作负载还要把数据校验、模型评测、模型登记和发布审批放进标准路径。
可观测性要跨越应用和模型。 请求延迟、错误率仍然重要，但还不够。平台还应支持记录模型版本、输入输出摘要、评测指标和成本指标。这里要注意隐私和合规，不应把敏感输入原样写入日志。
治理要前移。 对 AI 应用来说，权限、数据边界、外部模型调用策略和审计记录不能等上线后再补。平台应把它们做成模板、策略和默认配置。
落地建议：从一条窄路径开始
不要一上来建设“大而全 AI 平台”。更稳的做法是选一个高频场景，例如在线推理、批量评测或向量索引刷新，然后做成一条端到端 Golden Path。
可以用这份检查表评估起步范围：
- 是否有清晰的目标用户：应用工程师、ML 工程师，还是数据科学家？
- 是否定义了输入和输出：模型、数据、镜像、评测结果、服务地址？
- 是否有默认资源规格和成本边界？
- 是否能从模板创建、部署、观测到回滚？
- 是否能记录模型版本和发布责任人？
- 是否明确哪些数据可以进入日志、评测和外部调用？
Platform Engineering 1.0 的经验仍然成立：把重复路径产品化，把复杂工具藏在清晰接口后面。AI 原生工作负载只是把平台工程的题目变难了，也让平台团队更接近业务交付的核心。