企业 AI 项目有一个普遍痛点:试点阶段效果惊艳,一旦要上生产、要长期跑、要合规审计,就卡住了。红帽与 NVIDIA 联合推出的 AI 工厂(Red Hat AI Factory with NVIDIA)最新进展,瞄准的就是这个断层——不是再造一个模型框架,而是在基础设施层补上安全、合规、生命周期管理这些"无聊但致命"的环节。
自主智能体的生产级挑战
自主智能体和传统微服务不一样。它需要持续运行、自主决策、调用外部工具、维护上下文状态。试点环境里你可以忽略这些问题,生产环境不行:
- 状态持久化:智能体的对话历史、任务进度不能因为 Pod 重启就丢了。
- 权限边界:智能体调用数据库、API、文件系统时,谁授权?审计日志在哪?
- 模型版本切换:业务模型从 v1 升到 v2,智能体的行为可能完全不同,怎么灰度?
- 合规留痕:金融、医疗场景要求每一步决策可追溯,这不是加个
print就能解决的。
AI 工厂这次更新的核心,就是把这些问题下沉到平台层解决,而不是让每个应用团队自己造轮子。
基础设施级的安全与合规
红帽的优势在基础设施治理(OpenShift、RHEL 的安全基线、SELinux 策略),NVIDIA 的优势在 GPU 加速和 AI 软件栈(NVIDIA NIM、NeMo、TensorRT)。AI 工厂把两者拧在一起:
- 模型服务通过 NVIDIA NIM 容器化部署,每个 NIM 容器自带安全签名和版本标签,OpenShift 管它的生命周期——从部署、滚动升级到回滚。
- 智能体的每次外部调用(工具调用、API 请求)经过平台级策略网关审计,日志写入不可篡改的审计存储。
- GPU 资源调度由 OpenShift 的 GPU Operator 统一管理,MIG 分片让小模型推理和大模型训练可以在同一集群混跑,互不干扰。
这不是"建议你这么做",而是平台默认就这么做。应用团队拿到的是一个已经内置合规护栏的运行环境。
生命周期管理:从部署到退役
模型和智能体都有生命周期。一个金融风控智能体,模型可能每季度更新一次,策略规则可能每周调整,而智能体本身可能要跑三年。AI 工厂这次强化了几个关键环节:
- 模型注册与版本追踪:NVIDIA NIM 微服务注册到 OpenShift Service Mesh,版本、签名、性能基准全部可查。
- 灰度发布:新版本智能体先对 5% 流量服务,指标达标后自动扩比例;异常则自动回滚,不需要人工半夜爬起来操作。
- 退役与归档:模型下线后,推理日志和决策记录按合规要求保留指定周期,到期自动清理。
下面是一个在 OpenShift 上部署 NVIDIA NIM 模型服务并挂载智能体策略的 YAML 示例,可以直接改造使用:
# nim-model-deployment.yaml
# 在 OpenShift 上部署一个 NVIDIA NIM 模型服务,供自主智能体调用
apiVersion: apps/v1
kind: Deployment
metadata:
name: nim-llama3-8b-instruct
namespace: ai-factory
labels:
app: nim-model
model: llama3-8b-instruct
version: v1.0.0
spec:
replicas: 2
selector:
matchLabels:
app: nim-model
model: llama3-8b-instruct
strategy:
type: RollingUpdate
rollingUpdate:
maxSurge: 1
maxUnavailable: 0 # 零中断滚动更新
template:
metadata:
labels:
app: nim-model
model: llama3-8b-instruct
version: v1.0.0
annotations:
audit.redhat.com/enabled: "true" # 开启平台级审计
spec:
serviceAccountName: nim-model-sa # 限制权限的专用 SA
containers:
- name: nim
image: nvcr.io/nim/meta/llama3-8b-instruct:1.0.0
ports:
- containerPort: 8000
resources:
limits:
nvidia.com/gpu: 1 # 每实例独占一块 GPU
requests:
nvidia.com/gpu: 1
env:
- name: NIM_MODEL_NAME
value: "meta/llama3-8b-instruct"
- name: NIM_MAX_BATCH_SIZE
value: "32"
volumeMounts:
- name: model-cache
mountPath: /model-cache
- name: audit-log
mountPath: /audit-log
volumes:
- name: model-cache
persistentVolumeClaim:
claimName: nim-model-cache-pvc
- name: audit-log
persistentVolumeClaim:
claimName: audit-log-pvc # 审计日志持久存储
---
apiVersion: v1
kind: Service
metadata:
name: nim-llama3-8b-instruct
namespace: ai-factory
spec:
selector:
app: nim-model
model: llama3-8b-instruct
ports:
- port: 8000
targetPort: 8000
---
# 智能体策略 ConfigMap——可独立更新,不影响模型服务
apiVersion: v1
kind: ConfigMap
metadata:
name: agent-policy-finance-risk
namespace: ai-factory
data:
policy.yaml: |
tools:
- name: query_risk_db
allowed: true
audit: true
max_calls_per_minute: 60
- name: send_alert
allowed: true
audit: true
requires_approval: false
guardrails:
max_context_tokens: 4096
refuse_topics: ["personal_advice", "political"]
output_format: "structured_json"
compliance:
log_retention_days: 365
decision_trace: true
部署命令:
# 创建命名空间和 GPU Operator 已就绪的前提下
oc apply -f nim-model-deployment.yaml
# 查看模型服务状态
oc get pods -n ai-factory -l app=nim-model
# 查看审计日志输出
oc logs -n ai-factory deployment/nim-llama3-8b-instruct | grep audit
# 灰度发布新版本:先改 version 标签,用 canary 路由切 5% 流量
oc patch deployment nim-llama3-8b-instruct -n ai-factory \
-p '{"spec":{"template":{"metadata":{"labels":{"version":"v1.1.0"}}}}}'
这个示例的关键点不是 YAML 本身,而是它体现的思路:模型服务、智能体策略、审计存储是三个独立管理的对象,各自有生命周期,互不耦合。改策略不需要重建模型 Pod,升级模型不需要改策略 ConfigMap。
持续运行:智能体不是一次性脚本
自主智能体的"自主"意味着它要长时间运行、持续响应事件、维护自身状态。AI 工厂在运行层面提供了几项支撑:
- 状态外置:智能体的上下文和任务状态存储在 Redis 或 PostgreSQL 中,Pod 重启后自动恢复,不依赖本地内存。
- 健康探针:OpenShift 监控智能体的推理延迟、工具调用成功率、上下文溢出率,异常时自动重启或降级。
- 事件驱动:智能体通过 Kafka 或 AMQP 接收业务事件,而不是靠人工触发,实现真正的持续运行。
一个最小化的智能体状态持久化模式(Python 示例):
# agent_state_manager.py
# 智能体状态外置到 Redis,Pod 重启后可恢复
import redis
import json
from datetime import datetime
r = redis.Redis(host="redis.ai-factory", port=6379, decode_responses=True)
class AgentStateManager:
def __init__(self, agent_id: str):
self.key = f"agent:{agent_id}:state"
def save_context(self, conversation_id: str, messages: list):
"""保存对话上下文,设置 24 小时过期"""
payload = {
"conversation_id": conversation_id,
"messages": messages,
"updated_at": datetime.utcnow().isoformat(),
}
r.hset(self.key, conversation_id, json.dumps(payload))
r.expire(self.key, 86400) # 24h TTL,自动清理过期对话
def load_context(self, conversation_id: str) -> dict:
"""Pod 重启后恢复上下文"""
raw = r.hget(self.key, conversation_id)
if raw:
return json.loads(raw)
return {"conversation_id": conversation_id, "messages": [], "updated_at": None}
def save_task_progress(self, task_id: str, step: int, result: dict):
"""记录任务执行进度"""
r.hset(
f"agent:{self.key}:tasks",
task_id,
json.dumps({"step": step, "result": result, "ts": datetime.utcnow().isoformat()})
)
# 使用示例
state = AgentStateManager("finance-risk-agent-001")
state.save_context("conv-789", [{"role": "user", "content": "检查账户 A 风险"}])
# Pod 崩溃重启后
recovered = state.load_context("conv-789")
print(recovered["messages"]) # 上下文完整恢复
上生产前的检查清单
AI 工厂解决的是平台层问题,但应用团队仍然需要做好自己的部分。以下是一个从试点走向生产的关键检查项:
| 检查项 | 试点阶段通常 | 生产要求 |
|---|---|---|
| 模型版本管理 | 手动下载权重文件 | NIM 注册 + Service Mesh 版本路由 |
| 智能体状态 | 内存里存 | Redis/PG 外置,Pod 无状态 |
| 工具调用权限 | 全开 | 策略网关 + 每工具限频 + 审计 |
| 合规日志 | print() |
平台审计存储,不可篡改 |
| GPU 资源 | 独占整卡 | MIG 分片或时间片共享 |
| 灰度发布 | 直接替换 | RollingUpdate + canary 路由 |
| 故障恢复 | 人工重启 | 健康探针 + 自动重启 + 状态恢复 |
如果你的团队还在试点阶段,建议先从状态外置和策略 ConfigMap 这两项入手——它们改动最小、收益最直接,也是最容易在试点中被忽略的。
红帽与 NVIDIA 的这次更新,本质上是把"AI 上生产"从每个团队自己摸索的苦活,变成平台默认提供的能力。技术栈本身并不神秘,难的是把这些治理细节做到默认开启、不可绕过。这才是智能体从 demo 走向长期可信运行的关键。