你的 AI SRE 并不只需要一个模型——它需要为每项工作选择合适的模型
I’m happy to translate the article for you, but I’ll need the actual text of the post. Could you please paste the content you’d like translated (excluding any code blocks or URLs you want to keep unchanged)? Once I have the text, I’ll provide a Simplified Chinese version while preserving the original formatting and markdown.
介绍
我们使用单一模型构建了首个 AI SRE 集成：Opus for everything —— 事故分流、Kubernetes 调试、IAM 策略审查、成本异常检测。我们的想法是使用最佳可用模型，而不去过度思考。
三个月后，成本变得真实。说实话，大多数任务并不需要 Opus 级别的推理。检查 pod 是否处于 CrashLoopBackOff 并不需要像解析复杂的跨账户 IAM 策略信任关系那样的认知负荷。
Rootly 本周发布了基准测试结果，用实际数字验证了我们大多数人一直的直觉。如果你正在构建 AI SRE 工具——或即将开始——这些发现值得细细品味。
什么是基准测试发现的
Rootly 对 Claude Sonnet 4.6 和 Opus 在四种基础设施任务类型上进行测试：
| 任务类型 | 测试模型 |
|---|---|
| Kubernetes 调试 | Sonnet 4.6, Opus |
| 计算异常检测 | Sonnet 4.6, Opus |
| IAM / S3 策略审查 | Sonnet 4.6, Opus |
| 通用基础设施工作 | Sonnet 4.6, Opus |
关键要点： Sonnet 4.6 在 Kubernetes 和计算任务上的表现与 Opus 相当。差距在复杂的 IAM 和策略推理上扩大——这正是 Opus 明显领先的地方。
为什么这样合理
- K8s 调试 主要是模式匹配加日志解释（例如
OOMKilled、CrashLoopBackOff）。模型只需识别已知模式并给出已知修复——较小、更快的模型足以胜任。 - IAM 则不同。跨账户信任策略、条件键、与权限边界交互的 SCP、以及 AssumeRole 链需要深度依赖推理。一次错误推断就可能改变整个账户的安全姿态，因此更高的推理能力很重要。
实际模型路由示例
您不需要复杂的框架即可开始。最简化的实现是一个在入口处将 任务类型 → 模型 进行映射的路由函数：
# Mapping of task types to the model that should handle them
TASK_MODEL_MAP = {
"k8s_debug": "claude-sonnet-4-6",
"compute_anomaly": "claude-sonnet-4-6",
"cost_analysis": "claude-sonnet-4-6",
"iam_policy_review": "claude-opus-4-6",
"security_audit": "claude-opus-4-6",
"incident_triage": "claude-sonnet-4-6", # fast first pass
"incident_rca": "claude-opus-4-6", # deep analysis on escalation
}
def route_task(task_type: str, payload: dict) -> str:
"""
Choose the appropriate model based on task_type and invoke the LLM.
"""
model = TASK_MODEL_MAP.get(task_type, "claude-sonnet-4-6")
return call_llm(model, payload)您在入口处对任务类型进行分类——可以依据告警元数据、PagerDuty 服务名称，或一次轻量级的预路由调用——随后进行相应的路由。
事故的两阶段路由
- 快速首轮分流（Sonnet）：“这是 P1 吗？可能的原因是什么？”
- 深入根因分析（Opus）：当事故持续超过 15 分钟或首次评估不明确时触发。
大多数事故不需要第二阶段，从而在提供所需深度的同时节省成本。
成本计算
在 Anthropic 当前的定价下，Opus 的每个输出 token 成本大约是 Sonnet 的 3–5 倍。
- 场景： 每天处理 200 条警报，全部使用 Opus。
- 将其中 70 % 路由到 Sonnet（可预测的 K8s 与计算任务），即可在 不牺牲关键质量 的前提下，节省 60–70 % 的月度 LLM 开支。
在大规模情况下——一个平台团队每天处理 500+ 条警报，涉及 20 项服务——这将带来显著的降本。其原则类似于经典的 FinOps：让资源规模与工作负载相匹配。
团队在开始这样做时常犯的错误
| 陷阱 | 重要性 | 快速解决方案 |
|---|---|---|
| 路由置信度 | 错误分类与安全相关的任务可能代价高昂。 | 当分类器不确定时默认使用 Opus。 |
| 跳过缓存 | 即使使用更便宜的模型，重复的上下文也会导致 token 使用量激增。 | 缓存系统提示和稳定的用户消息部分 → 节省 40–60 % 的 token。 |
| 缺乏可观测性 | 没有每个模型和任务的指标，你无法判断费用激增的原因。 | 添加一个 Prometheus 计数器： llm_requests_total{model="claude-sonnet-4-6", task_type="k8s_debug"} llm_requests_total{model="claude-opus-4-6", task_type="iam_policy_review"} |
几分钟的仪表化可以在账单到来时省去数小时的困惑。
我会不同的做法
- 从第 0 天起记录任务类型和模型 — 即使在构建路由逻辑之前。
- 让单一模型运行一个月，为每个请求标记其任务类型。
- 到月末，你将拥有关于任务分布的真实数据（例如，% K8s 调试 vs. IAM 工作）。
- 你会知道长尾推理任务到底出现在何处。
- 用数据而不是直觉来构建路由器。
我们仍在随着新警报类型的出现迭代分类，并且我们并不声称我们的路由是完美的。但从一开始就具备可观测性，使得后续细化要容易得多。
随意将代码片段和想法适配到你自己的技术栈。关键很简单：把合适的模型匹配到合适的工作，你就能在不牺牲可靠性的前提下省钱。
本文的去向
这是 LLMOps 作为一门真正学科的开端。目前大多数团队仍处于“挑选模型并在所有场景中使用”的阶段——这对于实验来说还算可以，甚至对小规模使用也没问题。但随着 AI SRE 从试点走向生产，运营层面的顾虑开始显现：成本、可靠性、延迟、以及按任务类型划分的质量。
那些像对待计算基础设施一样对待 LLM 基础设施的团队——具备成本可视化、合理规模化以及可观测性——将相较于仍然为分类 pod 重启而支付高额 Opus 费用的团队拥有显著优势。
Rootly 的基准测试只是一个数据点。你的生产数据才是更好的参考。开始收集它吧。
如果你正在构建 AI SRE 工具，并在模型路由或任务分类中遇到有趣的边缘案例，欢迎联系我——我真的很想了解其他团队发现了哪些模式。