AI 应用正在从单轮生成式调用走向能够规划、调用工具并持续执行任务的 Agent。工作负载随之发生变化：推理请求持续时间更长，GPU 等加速资源更紧张，模型服务需要弹性伸缩，任务还可能跨越多个服务和集群。CNCF 日本社区成立 AI Infra SIG，并通过首次 meetup 和讲者招募启动交流，正是为了把这些问题放到 Kubernetes 与 Cloud Native 的工程语境中讨论。
为什么 Agent 会放大基础设施压力
传统 Web 服务的容量规划通常围绕 QPS、CPU 和请求延迟展开。AI Agent 则引入了更多变量：一次用户请求可能触发多轮模型推理、向量检索、外部 API 调用和代码执行，整体耗时及资源消耗很难仅由入口流量推算。
这会让平台团队面对几类具体问题：
- 异构资源调度：不同模型可能依赖不同规格的 GPU、显存和运行时。
- 弹性与冷启动：模型副本扩容速度受镜像体积、权重加载和设备初始化影响。
- 长任务可靠性：Agent 工作流可能持续数分钟，需要处理超时、重试、幂等和中断恢复。
- 可观测性：仅查看 Pod CPU 使用率无法解释推理延迟，还需要关联模型、Token、队列和工具调用。
- 成本治理：GPU 利用率、模型选择和请求批处理方式都会直接改变运行成本。
Kubernetes 提供了声明式部署、调度、隔离和控制器机制，但它不会自动解决所有 AI 工作负载问题。真正值得社区讨论的是：哪些能力应由 Kubernetes 承担，哪些应交给模型服务框架、工作流引擎或专门的推理平台。
SIG 的价值在于形成可复用的工程语言
AI Infra 横跨模型开发、平台工程、SRE、安全和成本管理。不同团队即使遇到同一个问题，也可能使用完全不同的指标和术语。SIG 可以通过 meetup、案例分享和开源协作，让这些经验逐步变成可比较、可验证的工程方案。
适合进入讨论的议题包括 GPU 调度与共享、模型服务伸缩、推理网关、分布式训练、Agent 沙箱、供应链安全，以及 AI 工作负载的可观测性。讲者也不必只展示成熟平台。一次失败的扩容实验、一组 GPU 空闲率数据，或者对某个控制器的取舍分析，同样具有实践价值。
由于来源摘要没有给出 SIG 的具体技术路线和项目清单，不能据此断言它会采用某个模型服务框架或 CNCF 项目。更合理的理解是：SIG 提供协作场所，具体技术结论仍需由后续分享、实验和社区共识形成。
可以这样实践：在 Kubernetes 上建立最小 AI 推理工作负载
下面是一个可改造的最小示例。它使用通用 HTTP 推理容器占位，重点展示 GPU 请求、健康检查、资源限制和 Service 暴露方式。运行前需要把 YOUR_REGISTRY/ai-inference:latest 替换为实际镜像；如果集群没有 GPU，也需要删除 nvidia.com/gpu 资源声明。
apiVersion: apps/v1
kind: Deployment
metadata:
name: ai-inference
labels:
app: ai-inference
spec:
replicas: 1
selector:
matchLabels:
app: ai-inference
template:
metadata:
labels:
app: ai-inference
spec:
containers:
- name: server
image: YOUR_REGISTRY/ai-inference:latest
ports:
- name: http
containerPort: 8080
env:
- name: MODEL_NAME
value: example-model
resources:
requests:
cpu: "2"
memory: 8Gi
nvidia.com/gpu: "1"
limits:
cpu: "4"
memory: 16Gi
nvidia.com/gpu: "1"
readinessProbe:
httpGet:
path: /ready
port: http
initialDelaySeconds: 10
periodSeconds: 5
livenessProbe:
httpGet:
path: /health
port: http
initialDelaySeconds: 30
periodSeconds: 10
---
apiVersion: v1
kind: Service
metadata:
name: ai-inference
spec:
selector:
app: ai-inference
ports:
- name: http
port: 80
targetPort: http
应用并检查资源：
kubectl apply -f ai-inference.yaml
kubectl rollout status deployment/ai-inference
kubectl get pods -l app=ai-inference -o wide
kubectl describe pod -l app=ai-inference
kubectl port-forward service/ai-inference 8080:80
另开终端验证接口。下面假设容器提供 /health；真实路径需要按所选推理服务器调整：
curl --fail http://127.0.0.1:8080/health
这个清单只是讨论起点。生产环境还应补充模型权重的加载策略、PodDisruptionBudget、网络策略、身份认证、指标采集和按队列长度或并发数扩缩容。对于 GPU 推理，直接使用 CPU 指标驱动 HPA 往往会产生误导，更适合评估请求队列、活跃序列数、首 Token 延迟和 GPU 利用率等指标。
从一次 meetup 走向持续协作
团队参与 AI Infra SIG 时，可以带着一份可复现材料，而不只是架构图。一个有效的分享通常应说明工作负载规模、集群和设备条件、观测指标、失败现象、采取的方案以及仍未解决的问题。
采用相关方案前，建议检查以下事项：
- 能否在不绑定单一模型或云厂商的前提下描述问题。
- 扩缩容指标是否真正反映推理压力，而不是沿用 Web 服务指标。
- Agent 的外部工具调用是否具备权限隔离、审计和超时控制。
- GPU 成本、利用率和服务等级目标是否能放到同一张报表中评估。
- 分享内容是否包含可复现配置、数据边界和失败条件。
AI Infra SIG 的意义，不是为快速变化的技术栈提前指定唯一答案，而是让日本的云原生与 AI 工程人员能持续交换证据、验证设计，并把有效做法沉淀为社区知识。首次 meetup 和讲者招募只是入口，长期价值取决于社区能否把真实运行数据、失败经验和可复用配置带到桌面上。