用途
LLMOps Platform Engineering 用于设计和运营一个内部 LLM 平台，使团队能够快速进行实验，同时不牺牲可靠性、成本或合规性。
适用场景包括：
- 为团队构建用于部署和管理 LLM 驱动功能的内部平台
- 设计包含模型评估门禁的 CI/CD 流水线
- 为模型版本搭建 A/B 测试基础设施
- 创建基于 Kubernetes 的模型服务基础设施
- 建立模型晋升的治理工作流
主要能力
参考架构
- 控制面：模型注册表、提示/版本目录、策略检查、评估流水线。
- 数据面：推理网关、向量数据库、缓存、特征存储。
- 运维面：遥测、告警、SLO 仪表盘、成本分析。
- 安全面：IAM 边界、密钥轮换、内容过滤、审计日志。
模型晋升流水线
提供 GitHub Actions 工作流示例（.github/workflows/model-promotion.yaml），包含以下作业：
- evaluate：运行质量评估套件、安全评估套件、延迟基准测试，执行质量/安全/延迟门禁检查，上传评估证据。
- approve：在目标环境中记录审批信息（审批人、模型、目标、时间）。
- deploy：部署金丝雀版本，等待金丝雀验证（15 分钟，含质量阈值 0.85、错误率阈值 0.02），然后晋升为全量发布并检查滚动状态。
评估门禁阈值
提供质量与延迟阈值配置示例：
- 质量门禁（thresholds/quality.yaml）：groundedness 最低 0.85、task_success 最低 0.90、hallucination 最高 0.08、regression 相对基线不低于 -0.02（即回退不超过 2%）。
- 延迟门禁（thresholds/latency.yaml）：p50 最高 800ms、p95 最高 2000ms、p99 最高 5000ms、吞吐量最低 50 请求/秒。
A/B 测试配置
提供 ABTest 自定义资源示例（ab-test-config.yaml），包含：
- 持续时间（如 7d）与流量分配（control/treatment 权重）
- 主要指标（task_success_rate、user_satisfaction_score）与次要指标（latency_p95、cost_per_request、hallucination_rate）
- 护栏自动回滚条件（如 task_success_rate 低于 0.80 持续 1h、hallucination_rate 高于 0.15 持续 30m）
- 分配策略（sticky_user，基于 user_id 哈希）
Kubernetes 模型服务部署
提供 Deployment、Service、HorizontalPodAutoscaler 清单示例，包含：
- 滚动更新策略（maxSurge 1、maxUnavailable 0）
- 拓扑分布约束、Prometheus 抓取注解
- 容器参数（模型路径、张量并行、最大模型长度、GPU 显存利用率）
- 资源请求与限制（CPU、内存、GPU）
- 就绪与存活探针、模型权重与配置卷挂载、GPU 容忍与节点选择
- HPA 基于 llm_queue_depth 与 gpu_utilization_percent 的扩缩容行为
CI/CD 设计要点
- 构建不可变容器，固定依赖与模型哈希。
- 使用环境晋升：dev -> stage -> prod。
- 在以下情况使部署失败：回归评估低于基线、安全测试超过风险阈值、p95 延迟超过 SLO 预算。
- 存储部署证据以供审计（提交 SHA、评估报告、审批人）。
运维 SLO
- 可用性：99.9%，30 天滚动窗口
- p95 延迟：< 1200ms，5 分钟分桶
- 每请求成本：< $0.05，1 小时平均
- 任务成功率：> 90%，24 小时滚动
- 有据性（Groundedness）：> 85%，24 小时滚动
平台护栏
- 强制租户配额与模型允许列表。
- 自动化路径要求结构化输出契约。
- 关键工作流默认使用低风险模型设置。
- 生产环境禁用不受约束的工具执行。
工具栈（示例）
- 编排：Argo Workflows、GitHub Actions、Airflow
- 模型注册表：MLflow、自定义元数据数据库
- 网关：LiteLLM、Bifrost、基于 Envoy 的 API 网关
- 可观测性：OpenTelemetry + Prometheus + Grafana + Langfuse
- 策略：OPA/Rego 用于部署与运行时检查
- 评估：RAGAS、自定义评估框架、Promptfoo
- 服务：vLLM、TGI、Triton Inference Server
故障排查
- 金丝雀未通过质量门禁：对比评估结果与基线，调整模型配置或回退版本。
- 部署卡在滚动更新：检查 Pod 事件与资源配额，修复资源限制或节点可用性。
- A/B 测试无显著差异：验证流量分配与样本量，延长测试时长或增加处理组权重。
- 模型冷启动过慢：模型权重下载过大，使用预缓存 PVC 或 init 容器。
- 评估流水线不稳定：模型输出非确定性，评估时设置 temperature=0，增加样本量。
使用方式
该技能以文档形式提供指导，包含参考架构、配置示例与操作流程。使用前需确认目标环境、影响范围与回滚计划。示例命令包括：
git status && git diff --stat kubectl diff -f manifest.yaml
前置条件
- 带 GPU 节点池的 Kubernetes 集群（或云推理 API 访问权限）
- 容器注册表（Harbor、ECR、GCR 或 ACR）
- CI/CD 系统（GitHub Actions、GitLab CI 或 Argo Workflows）
- 可观测性栈（Prometheus + Grafana + OpenTelemetry）
- 模型注册表（MLflow 或自定义元数据存储）
预期成果
- 从实验到生产的标准化路径
- 带质量与安全门禁的安全模型发布
- 可复用的推理、向量数据库与可观测性基础设施模块
- 平台、应用与安全团队之间清晰的归属模型
限制
- 指导内容针对真实环境执行：应用任何内容前需确认目标、影响范围与回滚计划。
- 未经明确批准，切勿部署到生产环境。
- 本文档为纯文档导入：上游脚本与模板未随附。
- 相关技能：ai-pipeline-orchestration、agent-evals、llm-gateway、model-registry-governance、ai-sre-incident-response。