生产级 AI 平台架构：K8s + GitOps + IaC + 安全 + 可观测性

感谢你抽空阅读。如果你有 AI 平台、云基础设施或平台工程方面的工作经验，欢迎在评论区分享你的架构思路。

在《云工程师的 AI 基础设施》第 4 部分中，我们探讨了 AI 的 FinOps，以及 GPU 利用率、Token 消耗量、模型选择和推理量如何影响成本。

阅读第 4 部分：FinOps for AI: Understanding GPU, Token, and Inference Costs

目前，我们已经介绍了 AI 基础设施的各个组成部分：

Kubernetes
GPU
调度
模型服务
可观测性
FinOps

但生产系统很少作为独立组件运行。

真正的挑战在于将它们整合为一个平台——开发者可以在上面部署应用，运维人员能够理解其运作逻辑，安全团队可以实施治理，企业能够负担得起运行成本。

这正是这篇终章要讨论的内容。

生产级 AI 平台长什么样？

一个简化的架构大致如下：

Developer
    ↓
Git Repository
    ↓
CI Pipeline
    ↓
Container Registry
    ↓
GitOps Repository
    ↓
Kubernetes
    │
    ├── AI Applications
    ├── Model Servers
    ├── GPU Workloads
    ├── Vector Services
    └── AI Agents
    │
    ↓
Observability + Security + FinOps

模型只是其中一个组件。

生产级 AI 平台还需要：

• 可重现的基础设施
• 受控的部署流程
• 安全的身份与密钥
• 回滚与恢复能力

目标不是简单地让一个 AI 应用跑起来。

目标是让它可重复、安全、可观测、可扩展，并且可恢复。

1. 从基础设施即代码开始

手动创建基础设施或许能应付实验阶段。

生产环境需要的是可重现的方案。

与其让工程师手动创建：

Kubernetes Cluster
GPU Node Pool
Network
Storage
Identity
Secrets Integration
Monitoring

不如把基础设施定义为代码。

Infrastructure Code
       ↓
Review
       ↓
Plan
       ↓
Apply
       ↓
Cloud Infrastructure

这样基础设施就变成了：

一个典型仓库的结构如下：

infrastructure/
├── network/
├── kubernetes/
├── gpu-nodes/
├── identity/
├── monitoring/
└── environments/
    ├── dev/
    ├── staging/
    └── production/

重要的原则不是具体用哪个 IaC 工具。

而是基础设施的变更要遵循与应用代码变更相同的工程规范。

2. 用 Kubernetes 作为运行时层

Kubernetes 成为 AI 平台运行的运行时环境。

AI API
Model Server
Embedding Service
Vector Search
AI Agents
Background Workers
GPU Workloads

                    Kubernetes
                        │
        ┌───────────────┼───────────────┐
        ↓               ↓               ↓
   AI Services      Model Servers    AI Agents
        │               │               │
        └───────────────┼───────────────┘
                        ↓
                    GPU Pool

这让平台获得了一种统一方式来管理：

Scheduling
Scaling
Networking
Health checks
Rollouts
Configuration
Resource allocation

Kubernetes 在 AI 领域的采用已经朝着这个方向发展。CNCF 2025 年调查显示，66% 托管生成式 AI 模型的组织至少在部分推理工作负载上使用了 Kubernetes。

有趣的地方在于，AI 基础设施开始越来越不像一堆独立服务器，而更像一个共享平台。

3. 将 CI 与部署分离

一个有用的模式是把构建软件和部署软件分开。

CI 流水线可以处理：

Code
 ↓
Tests
 ↓
Security Scan
 ↓
Container Build
 ↓
Container Registry

然后部署可以独立通过 GitOps 来处理。

Container Registry
       ↓
Deployment Configuration
       ↓
Git Repository
       ↓
GitOps Controller
       ↓
Kubernetes

因为 CI 系统不需要持有广泛凭证来直接修改生产集群。

取而代之的是，生产配置存在于 Git 中。

一次变更的流程大致是：

Pull Request
     ↓
Review
     ↓
Merge
     ↓
GitOps Reconciliation
     ↓
Deployment

Kubernetes 本身也推荐对生产工作负载采用声明式、版本控制的配置，这也天然契合 GitOps 工作流。

4. Git 成为期望状态

假设生产环境当前运行的是：

model-version: v12
replicas: 4

新版本需要：

model-version: v13
replicas: 6

团队不需要手动修改集群，只需更新 Git 中的配置。

model:
  version: v13

replicas: 6

GitOps 控制器会比较：

Desired State in Git
        ↓
Actual State in Cluster

然后调和差异。

这样做的好处包括：

Change history
Code review
Rollback
Auditability
Environment consistency

如果出了问题，回滚 Git 变更就可以恢复之前的期望配置。

对于 AI 系统来说，这尤其有用，因为变更可能涉及：

Model version
Prompt configuration
Resource limits
GPU requirements
Inference replicas
Routing policies

5. 把安全作为平台能力来对待

安全不应该在部署之后才添加。

它应该贯穿整个平台。

一个请求的路径可能长这样：

User
 ↓
Authentication
 ↓
API Gateway
 ↓
AI Application
 ↓
Authorized Tool / Model
 ↓
Protected Resource

重要的控制措施包括：

模型永远不应该成为安全边界。

如果一个 AI Agent 请求访问数据库、API 或生产工具，基础设施仍然需要验证该操作是否被允许。

一个有用的原则是：

AI 决定它想做什么。平台决定它被允许做什么。

随着 AI Agent 开始直接与运营基础设施交互，这一点变得越来越重要。

6. 把密钥放在应用外部

AI 应用可能需要以下凭据：

Model providers
Databases
Vector stores
External APIs
Cloud services
MCP servers

这些不应该出现在：

Source code
Container images
Git repositories
Application logs

Secrets Manager
      ↓
Workload Identity
      ↓
Application

在可行的情况下，工作负载身份比长期静态凭据更可取。

如果确实需要凭据，它们应该具备：

同一原则适用于开发、预发布和生产环境。

每个环境都应该有自己独立的信任边界。

7. 让可观测性成为平台的一部分

在第 3 部分中，我们详细探讨了 AI 可观测性。

在平台层面，我们希望有一条统一的遥测路径。

Applications
GPU Nodes
Model Servers
AI Agents
     │
     ├── Metrics
     ├── Logs
     └── Traces
     │
     ↓
OpenTelemetry / Exporters
     ↓
Observability Platform

OpenTelemetry 为 Kubernetes 提供了 Collector、Operator 和工作负载 instrumentation 工具，作为通用遥测层非常有用。

生产级 AI 平台应该让工程师能够从：

User says AI is slow

追踪到：

Request ID
    ↓
API trace
    ↓
Model inference latency
    ↓
GPU saturation
    ↓
Growing queue depth

而不需要去搜索五个互不相关的系统。

平台应该默认让诊断变得更容易。

8. 把可靠性与 AI 指标连接起来

传统的 SRE 指标仍然重要：

Availability
Latency
Errors
Traffic

AI 添加了另一层：

Time to first token
Tokens per second
Queue depth
GPU utilization
Model errors
Tool-call failures
Provider latency

一个服务在 Kubernetes 层面可能看起来健康：

Pods:      Healthy
CPU:       Normal
Memory:    Normal

但用户却经历着：

Queue:     Growing
TTFT:      Increasing
GPU:       Saturated

生产就绪意味着要把两个视角连接起来。

9. 把 FinOps 加入架构

成本不应该存在于一个完全独立的仪表盘里，只归财务部门所有。

平台本身已经知道：

GPU utilization
GPU hours
Requests
Tokens
Models
Tenants
Workloads

这些指标可以与成本关联起来。

AI Workload
     ↓
Resource Usage
     ↓
Cost Allocation
     ↓
Team / Tenant / Product

例如：

Workload: document-summary
Model: model-a
GPU Hours: 420
Requests: 180,000
Cost / Request: $0.018

现在工程团队可以就以下方面做出更好的决策：

Scaling
Model choice
Prompt size
Caching
GPU capacity

FinOps 成为平台工程的一部分，而不是只有在收到云账单时才去查看的东西。

10. 构建安全的部署路径

生产级 AI 发布应该通过受控的阶段推进。

Developer
    ↓
Pull Request
    ↓
Tests
    ↓
Security Checks
    ↓
Build Image
    ↓
Deploy to Staging
    ↓
Validation
    ↓
Production Approval
    ↓
GitOps Deployment

验证可能包括：

Unit tests
Integration tests
Model evaluations
Security tests
Smoke tests
Performance tests

AI 增加了一个重要的区别。

服务可能部署成功，但模型表现却更差了。

因此发布验证应该同时考虑：

Infrastructure Health
        +
AI Quality

一次技术上健康的部署不一定是成功的 AI 发布。

11. 在需要之前先设计好回滚

想象模型版本 v13 导致延迟增加或效果变差。

生产环境不应该依赖于有人记得一长串命令。

如果配置是版本控制的：

v12
 ↓
v13
 ↓
Problem detected
 ↓
Revert
 ↓
v12

回滚就成为部署设计的一部分。

需要纳入版本控制的内容：

Container versions
Prompt configurations
Routing policies
Resource limits
Model versions

恢复能力应该在故障发生之前就测试过。

把所有内容整合起来

现在完整的架构看起来是这样的：

                    Developer
                        ↓
                  Git Repository
                        ↓
                  CI / Validation
                        ↓
                 Container Registry
                        ↓
               GitOps Configuration
                        ↓
                GitOps Controller
                        ↓
                    Kubernetes
          ┌─────────────┼─────────────┐
          ↓             ↓             ↓
     AI Services   Model Servers   AI Agents
          │             │             │
          └─────────────┼─────────────┘
                        ↓
                  GPU Infrastructure
                        ↓
        ┌───────────────┼───────────────┐
        ↓               ↓               ↓
   Observability     Security        FinOps

支撑这一切的有：

Infrastructure as Code
Identity
Secrets
Policies
Networking
Storage
Testing

这并不是要选择某一个完美工具。

而是关于创建清晰的运维边界。

平台应该降低开发者复杂度

开发者在构建 AI 功能时，不应该需要理解以下每个细节：

GPU scheduling
Network policy
Secret rotation
Prometheus configuration
GitOps controllers
Cloud billing

理想情况下，平台应该提供一条受支持的路径。

Developer 定义：

Model
GPU requirement
Scaling policy
Environment

平台处理：

Infrastructure
Deployment
Security
Observability
Cost allocation

这正是 AI 基础设施开始与平台工程重叠的地方。

现代内部开发者平台越来越多地将 Kubernetes、GitOps、可观测性、治理、安全和自助服务整合到标准化工作流中。AI Agent 现在开始与人类开发者一起成为这些平台的消费者。

生产级 AI 平台实用检查清单

在将 AI 平台称为生产级就绪之前，我希望能对以下问题有明确的答案：

• 基础设施是否可以从代码重现？
• 部署是否采用声明式且版本控制的？
• 每次生产变更都可以被审计吗？
• 发布可以快速回滚吗？
• 密钥是否存储在应用代码之外？
• 每个工作负载是否遵循最小权限原则？
• GPU 和推理健康状况可以监控吗？
• 请求可以跨服务追踪吗？
• 成本可以归因到工作负载或团队吗？
• 发布前是否验证了模型质量和基础设施健康？

如果其中多项依赖于手动知识，平台仍然存在运维风险。

结语

这篇文章是《云工程师的 AI 基础设施》系列的大结局。

Why Kubernetes?

GPU Scheduling
      ↓
Model Serving
      ↓
Observability
      ↓
FinOps
      ↓
Production Platform

对我来说最大的教训是：生产级 AI 不只是一个机器学习问题。

Cloud problem
Distributed systems problem
Platform engineering problem
Security problem
SRE problem
FinOps problem

而这正是云工程师在 AI 生态系统中扮演重要角色的原因。

一个模型在 Jupyter Notebook 里可以令人惊艳。

但生产级 AI 系统需要的多得多。

Repeatable infrastructure
Controlled delivery
Secure access
Reliable compute
Observability
Cost visibility
Recovery

Kubernetes 提供了运行时基础。

基础设施即代码使环境可重现。

GitOps 使部署可控且可审计。

安全定义了工作负载被允许访问什么。

可观测性告诉我们系统在做什么。

FinOps 告诉我们是否高效地使用了这些资源。

这些组件合在一起，把一个 AI 应用变成了一个可运维的生产级平台。

而对于云、DevOps、SRE 和平台工程师来说，这可能是当前 AI 转型中最有趣的部分之一。

系列文章索引

本文完结了我的《云工程师的 AI 基础设施》系列：

• Why Kubernetes Is Becoming the Operating System for AI Infrastructure
• Running AI Workloads on Kubernetes: GPUs, Scheduling, Scaling, and Model Serving
• Observability for AI Infrastructure: What to Monitor Beyond CPU and Memory
• FinOps for AI: Understanding GPU, Token, and Inference Costs
• Building a Production AI Platform: Kubernetes, GitOps, IaC, Security, and Observability

感谢在整个系列中阅读、评论或分享经验的每一位读者。

我定期分享我在云基础设施、Kubernetes、DevOps、SRE、平台工程以及生产级 AI 系统背后基础设施方面的学习心得。

LinkedIn: Connect with me on LinkedIn

---

如果你从零开始设计一个 AI 平台，你会先标准化哪一部分：基础设施、部署、安全、可观测性，还是成本管理？