企业生产实践

从 OpenAI 的公开实践与 outages 中，我们可以提炼出对生产系统有直接指导意义的经验。

1. 训练：把故障当成常态

• 硬件故障率高：数万台 GPU 中，每天都有节点故障。
• 高频 checkpoint：每数分钟保存一次 checkpoint，确保故障后损失可控。
• 弹性训练框架：自动检测失效节点、重新调度、从 checkpoint 恢复。
• 网络拓扑感知：并行策略与物理拓扑匹配，减少跨机架/跨 pod 通信。
• 混合并行策略：根据模型大小与集群拓扑选择数据/张量/流水线/专家并行的组合。

2. 推理：成本与延迟的平衡

• 输出 token 主导延迟：OpenAI 官方指南指出，减少 50% 输出 token 可降低约 50% 延迟。
• 输入 token 影响较小：缩短 prompt 对延迟提升有限（1–5%），但仍影响成本。
• Streaming 是最有效的感知优化：用户看到 token 逐字出现，主观等待时间显著降低。
• Predicted Outputs：对代码编辑等“已知大部分输出”的场景，可大幅降低延迟。
• 小模型 + 大模型组合：简单任务用小模型，复杂任务路由到大模型。

3. 规模化 API 的平台能力

• 多租户隔离：Organization、Project、API Key 三级隔离。
• 分层限流：按用户 tier、模型、并发、token budget 设置 quota。
• 全球负载均衡：按区域、容量、模型可用性路由请求。
• 版本透明：模型版本明确命名，支持灰度与回滚。
• 可观测三位一体：trace、metrics、logs 覆盖请求全生命周期。

4. 安全与对齐的工程落地

• RLHF 是持续过程：不是一次性训练，而是随着模型能力演进不断迭代。
• Red Teaming 规模化：GPT-4o 动用了 100+ 外部红队成员、29 个国家、45 种语言。
• 自动化 red teaming：使用 GPT-4T 等模型自动生成攻击目标、多步强化学习发现漏洞。
• 部署门槛：Preparedness Framework 将 high/critical 风险模型置于更严格的发布流程。
• System Cards 作为交付物：把安全评估结果与缓解措施公开，建立信任。

5. 与云厂商深度 co-design

• Microsoft 为 OpenAI 建造专用 Azure AI 超级计算机。
• 从网络、存储、调度到故障恢复都针对大模型训练优化。
• Azure OpenAI Service 让企业客户也能使用同一套基础设施。

6. 从 outages 中学到的教训

• 容量规划要留足余量： viral 增长会瞬间打满推理集群。
• 降级策略：在高峰时段限制非付费用户、降低生成长度、引导到更小模型。
• 全局状态一致性：多区域部署下，配额、配置、模型版本需要强一致性。
• 快速回滚：新模型或配置异常时，能在分钟级回滚到稳定版本。

7. 可观测与 SLO

• 关键 SLI：TTFT（Time To First Token）、ITL（Inter-Token Latency）、端到端延迟、可用性、每 token 成本。
• Burn Rate 告警：OpenAI 级别的流量下，短窗口错误预算消耗极快。
• 用户级可观测：按 organization/project 聚合用量、成本、错误率。

8. 多模态与 Agent 的新挑战

• 实时音频/视频：端到端延迟要求从秒级降到百毫秒级。
• 长程 Agent 会话：状态持久化、工具调用审计、沙箱安全。
• 测试时计算（Test-Time Compute）：o1/o3 类 reasoning 模型需要更多推理时间，对调度与成本模型提出新需求。

常见反模式

反模式	风险	OpenAI 的修正思路
一次性发布大模型	风险不可控	Staged release、research preview
忽视推理成本	运营亏损	Continuous batching、KV cache、模型蒸馏
安全作为事后补丁	滥用与合规风险	RLHF、Red Teaming、System Cards
单区域部署	高延迟与单点故障	全球多区域推理集群
模型版本不可控	行为漂移	显式版本命名与灰度

小结

OpenAI 的生产实践表明：大模型基础设施的难点不是让模型跑起来，而是在规模、成本、延迟、安全之间持续做最优 trade-off。下一章把这些经验浓缩为可复用的最佳实践。