AI 扩展计划 / Playbooks

AI FinOps / Unit Economics / Capacity Playbook

AI 平台进入生产后，成本问题会从“模型 API 账单偏高”变成一组更难的产品和架构问题：

992 行AI_FINOPS_UNIT_ECONOMICS_CAPACITY_PLAYBOOK.md

AI FinOps / Unit Economics / Capacity Playbook

目标：训练把 AI 平台从“能调用模型”升级为“成本、容量、质量、SLO、碳效率和业务价值可共同治理”的能力。适用对象：AI Platform PM、FinOps Lead、Product Architect、CTO Staff、AI Operations。核心判断：AI FinOps 不是月底解释 token 账单，而是在设计、发布和扩容前就能回答“每一个 AI 成果单位花多少钱、为什么值得、容量怎么保、质量是否被牺牲、谁负责预算”。

1. 定位：AI 价值控制面

AI 平台进入生产后，成本问题会从“模型 API 账单偏高”变成一组更难的产品和架构问题：

同一个 request 可能触发模型、检索、rerank、工具、judge、human review、trace 存储和下游 API。
同一个业务成果可能经过多次重试、多模型路由、缓存命中或绕过、人工复核和返工。
同一个 GPU 池可能服务客服 Copilot、AML Copilot、KYC 抽取、代码 Agent、客户-facing AI 和实时风控模型。
同一个成本优化动作可能降低延迟，也可能损害 citation correctness、AML evidence quality 或支付风险召回。
同一个预算池如果缺少多租户归因，会变成“先用先赢、后用排队、财务补洞”的平台反模式。

一句话定位：

AI FinOps 是 AI 平台的价值控制面。它把 token、GPU、API call、case outcome、SLO、quality、risk、capacity 和 business value 放进同一个决策系统。

这份 playbook 衔接仓库已有资产：

已有资产	本手册补上的能力
`docs/AI_PLATFORM_PM_PLAYBOOK.md`	把 model gateway、cost dashboard、quota 和多租户从平台能力扩展为 unit economics 和容量治理。
`docs/AI_OBSERVABILITY_COST_SLO_PLAYBOOK.md`	把 trace、cost ledger、SLO 和 incident 指标转成预算、容量、chargeback、showback、funding gate。
`docs/AI_ARCHITECTURE_REVIEW_GATE_CHECKLISTS.md`	在 architecture gate、release gate、scale gate 增加成本质量边界、容量承诺、预算护栏和碳效率证据。
`docs/AI_EVALOPS_PLATFORM_ARCHITECTURE_PLAYBOOK.md`	把 eval/judge/human review 成本纳入完整 unit economics，而不是只算推理成本。
`docs/AI_TRANSFORMATION_VALUE_OFFICE_PLAYBOOK.md`	把 AI 投资组合管理落到单 use case、单租户、单成果单位的成本和价值证据。

2. Source Anchors

这些来源作为方法锚点，不构成财务、合规或采购建议。

Anchor	Link	本手册使用方式
FinOps Foundation Framework	https://www.finops.org/framework/	使用 FinOps 的协作、问责、数据驱动和价值最大化原则组织 AI 成本治理。
FinOps for AI	https://www.finops.org/framework/technology-categories/ai/	将 AI spend 的复杂性、不可预测性、政策治理和业务价值对齐作为 AI FinOps 的专门问题。
FinOps for AI Overview	https://www.finops.org/wg/finops-for-ai-overview/	参考 AI workload 的 training cost efficiency、resource utilization efficiency、cost per API call、ROI 和合规成本视角。
Cost Estimation of AI Workloads	https://www.finops.org/wg/cost-estimation-of-ai-workloads/	用于 AI 服务从 pilot 到 production 的预测、估算和成本驱动因素分析。
OpenCost Docs	https://opencost.io/docs/	作为 Kubernetes 成本测量、showback 和 chargeback 的开源参考。
OpenCost Specification	https://opencost.io/docs/specification	作为容器和基础设施成本分配口径的参考。
Kubernetes Resource Management	https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/	用 requests、limits、CPU、memory 和资源约束设计 AI workload 的基础容量口径。
Kubernetes Resource Quotas	https://kubernetes.io/docs/concepts/policy/resource-quotas/	用 namespace 级资源配额设计多租户预算和容量护栏。
Kubernetes Device Plugins	https://kubernetes.io/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/	用 device plugin 思路理解 GPU、TPU、NIC 等专用资源在集群中的暴露和调度。
Kubernetes GPU Scheduling	https://kubernetes.io/docs/tasks/manage-gpus/scheduling-gpus/	用于 GPU workload 的调度、限制和容量规划。
Kubernetes Horizontal Pod Autoscaling	https://kubernetes.io/docs/concepts/workloads/autoscaling/horizontal-pod-autoscale/	用于交互式 AI 服务的副本扩缩容设计。
Kubernetes Node Autoscaling	https://kubernetes.io/docs/concepts/cluster-administration/node-autoscaling/	用于峰值容量、pending pod 和节点池扩缩容设计。
NIST AI RMF	https://www.nist.gov/itl/ai-risk-management-framework	用 Govern / Map / Measure / Manage 把成本优化放入风险治理，而不是单纯降本。
Green Software Foundation SCI	https://greensoftware.foundation/standards/sci/	用 Software Carbon Intensity 思路把 AI 成本、能耗和碳效率纳入同一优化视角。
Learn Green Software	https://learn.greensoftware.foundation/introduction/	用 energy efficiency、carbon awareness、hardware efficiency 作为 AI workload 效率原则。
AWS Well-Architected Sustainability Pillar	https://docs.aws.amazon.com/wellarchitected/latest/sustainability-pillar/sustainability-pillar.html	参考云工作负载可持续性、资源效率和运营改进原则。
Google Cloud Carbon Footprint	https://cloud.google.com/carbon-footprint	参考云碳排放度量、项目/产品/区域维度分析和报告思路。

3. 为什么 AI FinOps 不等于普通 Cloud FinOps

普通 cloud FinOps 常见优化对象是 compute、storage、network、数据库、Kubernetes 资源和许可证。AI FinOps 仍然继承这些对象，但成本驱动因素发生了结构性变化。

维度	Cloud FinOps 常见口径	AI FinOps 需要新增的口径
最小成本单位	VM hour、vCPU、GB、request	input token、output token、reasoning token、GPU second、model call、tool call、eval case、accepted answer、resolved case
需求形态	可通过服务流量近似预测	prompt 长度、上下文、模型路线、重试、agent 步数和 judge 强度共同决定成本
容量瓶颈	CPU、memory、IO、network	GPU/TPU、KV cache、prefill、decode throughput、provider rate limit、queue wait
成本风险	资源闲置、过度预留、未关停	长上下文膨胀、强模型滥用、低缓存命中、agent loop、eval 过重、峰值专线容量闲置
归因难点	标签缺失、共享集群	多模型、多工具、多租户、多 workflow step、多业务 outcome
优化边界	性能、可用性、安全	quality、groundedness、citation、risk tier、human oversight、SLO、regulatory evidence
价值证明	单位交易成本、基础设施效率	cost per successful answer、cost per resolved case、cost per prevented loss、cost per accepted code change

关键转变：

从 usage 管理转向 outcome 管理。token 多不等于价值大，token 少也不等于效率高。
从单模型成本转向全链路成本。RAG、tool、judge、human review 和 observability 都是 AI 成果的一部分。
从平均成本转向风险分层成本。AML、支付风控、客户-facing 场景不能用低风险 FAQ 的成本标准裁剪质量。
从容量采购转向容量组合。reserved、on-demand、spot、batch window、degradation route 和 spillover 都要进入产品决策。
从平台共享转向多租户经济。共享平台必须回答谁用了、谁受益、谁付费、谁被限流。

4. Unit Economics：AI 成本单位阶梯

AI unit economics 要从最底层的 token/GPU 走到业务结果。只停在 token 层，会奖励“消耗”；只停在业务 ROI，又无法定位成本失控。

Token / GPU / API call
-> Request
-> Successful AI output
-> Accepted workflow action
-> Resolved business case
-> Portfolio value and risk-adjusted ROI

4.1 Token 成本模型

Token 成本不是一个字段，而是一组可优化的构成。

成本项	公式口径	典型失控信号	优化杠杆
Input token cost	input_tokens * input_price_per_token	prompt 模板膨胀、历史对话无限携带、RAG top_k 过高	prompt compression、context pruning、retrieval filtering、semantic cache
Output token cost	output_tokens * output_price_per_token	回答冗长、格式不受控、代码生成超长	max output、structured output、concise style policy、stream cutoff
Reasoning token cost	reasoning_tokens * reasoning_price_per_token	低复杂度任务走强推理模型	task classification、risk-tiered routing、reasoning budget
Cached input token cost	cached_tokens * cached_price_per_token	cache key 过细导致命中低	prompt prefix 稳定化、system prompt registry、tenant-aware cache
Embedding cost	embedded_tokens * embedding_price	重复索引、无效文档、增量更新缺失	document dedupe、delta ingestion、source registry
Rerank cost	rerank_items * rerank_price	top_k 过大、所有请求都 rerank	two-stage retrieval、risk-based rerank、rerank only when needed

核心指标：

Metric	定义	解释
Cost per 1K input tokens	输入 token 单位成本	判断上下文治理和 prompt 架构效率。
Cost per 1K output tokens	输出 token 单位成本	判断输出长度治理和模型路线效率。
Evidence token ratio	evidence tokens / input tokens	判断输入预算是否花在可信证据，而不是模板噪音。
Cache-adjusted token cost	total token cost - cache savings	判断缓存带来的真实经济收益。
Token per successful answer	total tokens / successful answers	比单纯 token 总量更接近价值效率。

4.2 GPU 成本模型

GPU 成本的关键不是“买贵了”，而是吞吐、队列、显存、SLO 和利用率之间的组合。

成本项	公式口径	典型失控信号	优化杠杆
GPU reserved cost	reserved_gpu_hours * reserved_rate	低谷闲置、高峰仍排队	基线 workload 放 reserved，峰值走 spillover
GPU on-demand cost	ondemand_gpu_hours * ondemand_rate	突发长期化、预算不可预测	预测峰值、预热容量、route policy
GPU idle cost	idle_gpu_hours * blended_rate	平均利用率低、batch window 空置	batch packing、multi-tenant pooling、autoscaling
GPU queue cost	queued_requests * business_wait_cost	SLO 违规、客户-facing 延迟升高	priority queue、pre-warm、capacity floor
KV cache memory cost	kv_cache_gb_seconds * memory_rate	长上下文请求挤占交互任务	context cap、separate pools、long-context approval
Failed generation cost	failed_or_retried_tokens * price	agent loop、tool failure、timeout retry	retry budget、tool health routing、loop guard

核心指标：

Metric	定义	解释
GPU utilization efficiency	useful busy time / provisioned GPU time	判断 reserved 和 on-demand 是否被有效使用。
Tokens per GPU second	generated tokens / GPU seconds	判断模型部署、batching 和 serving stack 效率。
Cost per million generated tokens	GPU total cost / generated million tokens	对自托管模型和 API 模型做可比分析。
Queue wait p95	p95 等待容量时间	直接影响客户-facing 和 analyst copilot 体验。
Idle capacity burn	idle_gpu_hours * blended_rate	解释过度预留和低复用。

4.3 Call 成本模型

AI request 常常不是一次模型调用。

Call 类型	成本口径	归因维度
Model call	token cost 或部署服务成本	use case、model route、prompt version、risk tier、tenant
Retrieval call	vector DB、hybrid search、metadata filter、rerank	knowledge base、index version、tenant、source owner
Tool call	内部系统 API、第三方 API、支付/风控/CRM 查询	tool owner、workflow step、side effect risk
Judge call	deterministic check、LLM judge、expert sampling	requirement id、rubric version、release gate
Human review	reviewer time * loaded labor rate	risk tier、review type、business owner
Observability call	trace、metric、log、span storage 和查询	retention policy、sampling rate、risk tier

关键原则：

低风险高频请求可以优化 call count。
高风险请求要保留必要 judge、human review 和 audit 成本。
tool call 成本要和 side effect 风险绑定，不能只看 API 单价。
observability 成本要按风险和保留周期分层，不能全量无限留存。

4.4 Case 成本模型

Case 成本把 AI 消耗转成业务结果。

成本单位	公式	适用场景
Cost per successful answer	total_ai_cost / quality_passed_answers	客服 Copilot、政策助手、内部知识问答。
Cost per accepted recommendation	total_ai_cost / user_accepted_recommendations	AML Copilot、代码 Agent、运营建议。
Cost per resolved case	total_ai_cost / resolved_cases	客服工单、支付争议、KYC remediation。
Cost per document processed	total_ai_cost / processed_documents	KYC 文档抽取、合同审查、监管材料抽取。
Cost per prevented loss	total_ai_cost / estimated_prevented_loss	支付风险、欺诈检测、AML investigation prioritization。
Cost per release-quality code change	total_ai_cost / accepted_changes_passing_ci	代码 Agent、测试生成、迁移辅助。

AI FinOps 最重要的句子：

成本下降只有在 quality、risk、SLO 和 adoption 不恶化时才算优化；否则只是把成本转移到返工、事件和用户不信任里。

5. Reference Architecture：AI FinOps 控制面

flowchart LR
  U[Users and Workflows] --> GW[AI Gateway]
  GW --> RT[Risk and Task Classifier]
  RT --> ROUTE[Model Routing Policy]
  ROUTE --> CACHE[Semantic / Prompt / Retrieval Cache]
  CACHE --> ORCH[AI Orchestrator]
  ORCH --> RET[Retrieval and Rerank]
  ORCH --> MODEL[Model Serving / API]
  ORCH --> TOOL[Tool Gateway]
  ORCH --> JUDGE[Eval and Judge]
  MODEL --> OBS[Trace and Metrics]
  RET --> OBS
  TOOL --> OBS
  JUDGE --> OBS
  OBS --> LEDGER[AI Cost Ledger]
  OBS --> SLO[SLO and Quality Dashboard]
  LEDGER --> ALLOC[Cost Allocation / Showback / Chargeback]
  SLO --> BUDGET[Budget Guardrails]
  ALLOC --> PORT[Portfolio Funding Gate]
  BUDGET --> CAP[Capacity Planner]
  CAP --> GPU[Reserved / On-demand / Spot GPU Pools]
  CAP --> PROVIDER[Provider Rate Limits and Spillover]
  PORT --> EXE[Executive Review]

架构原则：

AI Gateway 是成本和风险控制入口，不只是 API proxy。
每次 request 必须携带 tenant_id、use_case_id、workflow_step、risk_tier、cost_center、environment 和 business_outcome_id。
Routing policy 必须同时看 task、risk、quality、latency、budget、cache eligibility 和 data boundary。
Cost ledger 必须记录成功、失败、重试、绕过缓存、人工复核和最终业务结果。
Capacity planner 必须读取 SLO、峰值预测、reserved commitment、on-demand spillover、batch window 和 carbon signal。
Showback 面向透明和行为改变；chargeback 面向预算问责；两者都需要统一 schema。

6. 架构模式

6.1 Model Gateway as Cost Control Plane

设计点	决策口径
Model allowlist	按 data classification、risk tier、region、供应商合约和模型能力定义。
Route policy	每条路线声明目标：quality-first、latency-first、cost-first、privacy-first、fallback-only。
Cost metering	每次调用记录 token、latency、cache、model version、cost、route reason。
Quota	按 tenant、use case、environment、risk tier 设置 request/token/cost 额度。
Fallback	主路线失败时按 risk tier 降级；高风险不允许降级到未批准模型。
Kill switch	能按 model、prompt、tenant、use case、tool、route policy 快速禁用。

6.2 Risk-Tiered Model Routing

Risk tier	示例	默认路线	成本策略	不可牺牲项
Low	内部 FAQ、开发者帮助	small / fast model + cache	高缓存、高 batch、低 judge	基础正确性、权限过滤
Medium	客服 Copilot 草稿、KYC 字段解释	medium model + RAG + selective judge	路由按复杂度分层	citation、升级人工、语气边界
High	AML Copilot、支付争议建议	strong model + expert sample + audit	成本接受由风险 owner 签署	evidence、no final decision、HITL
Critical	自动拒贷、自动冻结账户、自动报送	LLM-only no-go	AI 只做辅助证据整理	人类最终决策、完整审计

6.3 Semantic Cache with Governance

Semantic cache 的目标不是“缓存所有答案”，而是缓存低风险、可复用、权限一致、版本稳定的计算结果。

Cache 类型	命中对象	适合场景	必须进入 cache key 的字段
Prompt prefix cache	system prompt、policy instruction、固定上下文	多团队共享 prompt 模板	prompt_version、model_alias、environment
Retrieval cache	query rewrite、doc ids、rerank result	政策 FAQ、产品条款查询	tenant、role、KB version、jurisdiction、permission scope
Semantic answer cache	低风险等价问题答案	内部操作指南、非个性化产品知识	risk_tier、policy_version、locale、product、source freshness
Tool result cache	只读、短 TTL 查询结果	商品目录、公开汇率、系统状态	tool_version、data_region、TTL、customer_scope

绕过缓存规则：

涉及客户个人账户、交易、KYC、AML case、支付风险实时判断时默认绕过 answer cache。
知识库版本、政策有效期、权限范围、地区或产品线变化时必须失效。
高风险 case 可以缓存检索结果的 metadata，但不缓存最终判断。
任何 cache hit 都要记录 cache_status、cache_key_policy_version 和估算节省。

6.4 Batching and Async Lanes

Workload	推荐模式	理由
KYC 文档抽取	async batch + priority queue	可在 SLA 窗口内集中处理，降低 GPU idle 和 API call overhead。
客服实时草稿	micro-batch only when TTFT SLO safe	不能为了吞吐牺牲坐席等待体验。
AML 历史 case 回填	offline batch + spot/preemptible capacity	可重试、可切片、对延迟不敏感。
代码 Agent 批量评审	scheduled batch + repo priority	避免白天高峰挤占客户-facing 容量。
支付风险实时模型	no batch for synchronous decision path	毫秒级延迟和高可用优先。

6.5 SLO Budget as Cost Boundary

SLO budget 把“可接受质量和延迟”转成成本边界。

SLO 类型	示例	成本含义
Latency SLO	客服 Copilot p95 total latency <= 8s	决定是否需要预热、缓存、小模型路线和峰值 on-demand。
Quality SLO	citation correctness >= 95%	决定是否允许降低 top_k、移除 rerank 或切小模型。
Safety SLO	high-risk escalation miss = 0	决定高风险请求不能走 cost-first route。
Availability SLO	客户-facing AI 99.9% 可用	决定 reserved capacity、multi-region 和 provider fallback。
Cost SLO	cost per resolved case <= approved target	决定是否需要优化 prompt、cache、route 或停止 scale。

6.6 Multi-Tenant Capacity Pool

AI 平台多租户不是“所有人共用一套 GPU”。成熟设计要分配容量、优先级、预算和降级规则。

Tenant 类型	容量策略	预算策略	降级策略
Customer-facing production	dedicated floor + shared burst	chargeback 到业务 owner	cache、shorter answer、approved fallback，不关闭核心功能
Regulated analyst copilot	reserved quality lane	risk accepted budget	queue with explanation、manual workflow fallback
Internal productivity	shared best-effort pool	showback + monthly cap	lower model tier、batch、rate limit
Experiment / sandbox	strict quota, no reserved GPU	prepaid innovation budget	hard stop at quota, no production spillover
Batch extraction	off-peak pool + spot capacity	cost per document gate	delay window、checkpoint resume

7. Capacity Planning：从需求到容量组合

AI 容量规划要同时回答四个问题：

需要多少实时吞吐和并发。
需要多少峰值保底和溢出能力。
哪些 workload 可以排队、批处理或降级。
reserved、on-demand、spot 和供应商 rate limit 怎么组合。

7.1 容量输入

输入	示例	决策影响
Request arrival rate	客服高峰 120 RPM，低谷 25 RPM	决定 gateway、queue、model serving 基线。
Token profile	p50 input 2K、p95 input 8K、p95 output 700	决定 prefill、decode、KV cache 和成本。
SLO	p95 TTFT <= 2s，p95 total <= 8s	决定是否能 batch、是否需要预热。
Risk mix	低风险 55%，中风险 40%，高风险 5%	决定强模型容量和 judge/human review 成本。
Cache eligibility	低风险 70% 可缓存，中风险 25% 可缓存	决定所需模型吞吐。
Business calendar	发薪日、节假日、促销、监管报送窗口	决定峰值预留和临时容量。
Data boundary	restricted data 只能私有端点	决定不能全部依赖公共 API spillover。

7.2 核心估算公式

这些公式用于 sizing 和对话，不替代真实压测。

effective_requests = total_requests * (1 - semantic_cache_hit_rate)

input_tokens_per_min =
  effective_requests_per_min * avg_input_tokens

output_tokens_per_min =
  effective_requests_per_min * avg_output_tokens

model_capacity_needed =
  peak_output_tokens_per_second / measured_tokens_per_second_per_replica

concurrency_needed =
  arrival_rate_per_second * avg_total_latency_seconds

reserved_baseline =
  p50_or_p60_steady_demand * commitment_confidence_factor

ondemand_spillover =
  p95_peak_demand - reserved_baseline - safe_degradation_capacity

idle_burn =
  reserved_capacity_cost - useful_work_cost_at_actual_utilization

7.3 Reserved / On-Demand / Spot Tradeoff

选项	适合	优势	风险	控制方法
Reserved capacity	稳定高基线、客户-facing、restricted data	单位成本可控、容量有保障	需求低估仍排队，需求高估产生闲置	每月校准 p50/p75 负载，设置共享池和 off-peak batch
On-demand	短期峰值、试点扩容、不可预测活动	弹性强、启动快	单价高、预算波动大、供应商限速	budget guardrail、峰值事件审批、rate-limit fallback
Spot / preemptible	可中断 batch、离线 eval、历史回填	单位成本低	中断、不可用于实时 SLO	checkpoint、idempotent job、retry budget
Dedicated private endpoint	restricted data、高风险生产	数据边界清晰、治理强	成本高、容量弹性差	只承载高风险或合规必要 workload
Third-party API spillover	公共低中风险峰值	减少自建峰值容量	数据出境、供应商依赖、质量差异	route allowlist、redaction、quality monitoring

7.4 容量降级层级

Level	触发条件	动作	禁止动作
L0 normal	SLO 和预算正常	按默认 route 执行	无
L1 cost pressure	单日预算使用 >= 70%，质量正常	低风险走 cache-first 和小模型，关闭冗长输出	不影响高风险路线
L2 capacity pressure	p95 queue wait 超阈值 30 分钟	开启 on-demand spillover，batch workload 延后	不把客户-facing 请求降到未批准模型
L3 incident pressure	provider failure、GPU 池异常	切换 approved fallback，暂停 sandbox 和 batch	不绕过 audit 和 policy
L4 risk protection	高风险质量 SLO 违反	停止 scale，强制人工流程	不用降本理由继续放量

8. 产品决策框架

8.1 选择优化目标

Use case	首要优化目标	次要目标	不应作为首要目标
客服 Copilot	cost per resolved case + citation correctness	AHT、FCR、坐席采纳率	token 总量最低
AML Copilot	evidence quality + analyst productivity	cost per accepted narrative	单次回答成本最低
KYC 文档抽取	cost per document processed + field accuracy	batch throughput、cycle time	实时延迟
代码 Agent	cost per accepted change passing CI	developer cycle time、defect leakage	生成代码行数
客户-facing AI	p95 latency + safety + availability	cost per completed journey	平均成本
支付风险实时模型	prevented loss / false positive tradeoff	p99 latency、feature freshness	模型推理单价

8.2 Cost-Quality Frontier

Cost-quality frontier 用于避免两种错误：为了质量无限加钱，或为了降本破坏业务结果。

Route	单次成本	质量	延迟	适合
small model + cache	低	中	低	内部 FAQ、低风险分类、格式转换。
medium model + RAG	中	中高	中	客服草稿、KYC 解释、运营助手。
strong model + rerank + judge	高	高	中高	AML narrative、复杂投诉、监管影响分析。
strong model + HITL	最高	最高可控	高	高风险决策支持、客户影响动作前置审查。

决策规则：

如果质量提升没有带来 acceptance、resolution、risk reduction 或 reviewer efficiency 改善，停止上移模型路线。
如果降本带来 reject、edit distance、fallback、human review 或 incident 上升，降本无效。
每个 use case 要维护一条 frontier 曲线：成本、质量、延迟、风险四维同时看。

8.3 Funding Gate

Gate	进入条件	成本证据	退出条件
Discovery	有明确业务 owner 和 workflow pain	粗略 T-shirt sizing，说明成本驱动项	确认数据、风险、容量和价值假设
Pilot	有 eval contract 和小流量用户	unit economics worksheet v1，预算上限	达成质量、采纳、SLO 和成本阈值
Release	有 production owner 和 incident runbook	cost allocation schema、alert rules、capacity plan	通过 release gate 和预算审批
Scale	有多租户和 chargeback/showback 机制	cost per business outcome 连续稳定	通过 scale gate，明确 reserved/on-demand 策略
Optimize	有足够 trace 和 outcome data	frontier 分析、route/cache 实验结果	成本下降且质量/SLO/风险不恶化

9. 治理模型

9.1 RACI

活动	Platform PM	FinOps Lead	Product Architect	AI Ops	Risk/Compliance	Business Owner	Finance
Unit economics 口径	A	R	C	C	C	C	A
Cost allocation schema	C	A/R	R	R	C	C	A
Routing/cache policy	A	C	R	R	C	C	I
Capacity plan	C	C	A/R	R	C	C	I
Budget guardrails	C	A/R	C	R	C	A	A
Funding gate	R	R	C	C	C	A	A
Chargeback/showback	C	A/R	C	R	I	A	A
Cost-quality review	A	R	R	R	A for high risk	A	C
Carbon/efficiency review	C	R	R	R	I	C	C

9.2 Budget Guardrails

预算护栏要分三层：

层级	控制对象	示例规则
Preventive	请求进入前	sandbox tenant 每日成本上限 300 美元；高风险路线必须有 approved budget id。
Detective	运行中发现异常	单小时 cost per successful answer 较 7 日均值上升 40% 触发告警。
Corrective	触发后自动或人工动作	低风险 route 降级为 cache-first；batch workload 延后；业务 owner 审批后再恢复峰值路线。

9.3 Chargeback vs Showback

模式	适合阶段	行为目标	风险
Showback	discovery、pilot、平台早期	让团队看见用量和成本，建立归因习惯	没有预算问责，容易继续扩张
Soft chargeback	release 初期	把成本分配到业务线，但允许平台补贴共性能力	需要明确补贴规则
Hard chargeback	scale 和成熟运营	业务 owner 对使用和价值负责	可能抑制有价值探索
Portfolio funding	跨业务平台能力	对 gateway、eval、observability、security 等共性能力统一投资	容易被误认为“平台免费”

10. 金融零售案例

10.1 客服 Copilot

维度	决策
核心单位	cost per resolved case、cost per accepted draft、cost per FCR improvement
成本驱动	RAG top_k、citation judge、输出长度、峰值坐席并发、重复政策问题
容量策略	客服高峰保留 reserved floor；低风险 FAQ 走 semantic cache；复杂投诉走 stronger route
质量边界	citation correctness >= 95%，unsupported fee/policy claim = 0
成本优化	稳定 policy prompt prefix、按产品/地区缓存检索结果、长答案默认摘要化
不能做	为降本关闭升级人工、移除政策引用、把客户个人账户问题缓存为通用答案

10.2 AML Copilot

维度	决策
核心单位	cost per accepted case narrative、analyst hours saved per case、quality pass per expert review
成本驱动	证据检索、长 case history、strong model、expert review、audit retention
容量策略	analyst 工作时段保留质量 lane；历史回填和模型对比放入 batch lane
质量边界	unsupported suspicious claim = 0；AI final SAR decision = 0
成本优化	case evidence pre-index、timeline extraction 缓存、重复 typology 模板化
不能做	用小模型替代专家复核、为了节省成本减少关键证据引用

10.3 KYC 文档抽取

维度	决策
核心单位	cost per document processed、cost per verified field、remediation cycle time reduction
成本驱动	OCR、page count、image quality retry、字段校验、人工复核
容量策略	大批量任务走 off-peak batch 和 spot；高优先级客户 onboarding 走 priority lane
质量边界	critical identity field accuracy 达到批准阈值；missing required field recall 达标
成本优化	文档类型先分类、小模型抽取标准字段、复杂异常升级强模型或人工
不能做	因 batch 便宜而拖延高价值客户开户 SLA

10.4 代码 Agent

维度	决策
核心单位	cost per accepted change passing CI、developer cycle time saved、defect escape avoided
成本驱动	repo context、test run、sandbox compute、multi-turn debugging、review retry
容量策略	内部 productivity 走 shared best-effort；发布前修复窗口提高优先级
质量边界	CI pass、security scan、code owner approval、no secret leakage
成本优化	repo map cache、test selection、diff-scoped context、失败后限制重试轮次
不能做	用生成代码行数证明价值、让代码 Agent 挤占客户-facing 容量

10.5 客户-facing AI 峰值容量

维度	决策
核心单位	cost per completed journey、conversion or containment value、p95 latency under peak
成本驱动	活动流量、峰值并发、低缓存命中、供应商 rate limit、多地区部署
容量策略	campaign 前预热容量；reserved baseline + on-demand burst + approved fallback
质量边界	safety block、customer complaint、handoff success、availability SLO
成本优化	低风险问题 cache-first，客户特定问题 route-first，输出长度按渠道控制
不能做	峰值时关闭安全 guardrail 或客户升级人工路径

10.6 支付风险实时模型

维度	决策
核心单位	cost per prevented loss、cost per false positive avoided、p99 decision latency
成本驱动	实时特征、模型推理、低延迟 serving、冗余部署、回溯评估
容量策略	专用实时 lane；离线训练和回测不得占用实时推理资源
质量边界	p99 latency、fraud recall、false positive rate、decision auditability
成本优化	feature cache、模型蒸馏、分层筛选、只对可疑交易走重模型
不能做	为了降低推理成本让高风险交易绕过模型或延迟授权链路

11. 模板 1：AI Unit Economics Worksheet

下面用客服 Copilot 示例给出一张可直接复制的 worksheet。复制后保留字段口径，并用目标 use case 的实际数据替换示例值。

Section	Field	Example value	Formula or rule
Scope	Use case	customer_service_copilot	与 trace 的 `use_case_id` 一致
Scope	Business owner	Contact Center VP	对业务结果和预算负责
Scope	Risk tier	Medium	决定 eval、cache、route 和 audit 强度
Volume	Monthly requests	1,200,000	来自 gateway trace
Volume	Cache hit rate	38%	semantic + retrieval + prompt cache
Volume	Effective model requests	744,000	requests * (1 - cache_hit_rate)
Token	Avg input tokens	2,200	p50/p95 分开维护，worksheet 用月度加权均值
Token	Avg output tokens	420	受输出策略影响
Cost	Model cost	41,500	token cost 或 self-hosted allocation
Cost	Retrieval cost	7,800	vector DB、search、rerank
Cost	Judge cost	5,600	selective judge + QA sample
Cost	Tool/API cost	3,900	CRM、case lookup、policy service
Cost	Human review cost	18,000	QA 和升级人工
Cost	Observability cost	2,200	trace、metric、retention
Cost	Total AI cost	79,000	sum(cost items)
Quality	Quality-passed answers	930,000	通过质量阈值的回答
Adoption	Accepted drafts	690,000	坐席采纳或轻微编辑
Outcome	Resolved cases	510,000	与 ticketing system 回链
Unit	Cost per request	0.066	total_ai_cost / monthly_requests
Unit	Cost per quality-passed answer	0.085	total_ai_cost / quality_passed_answers
Unit	Cost per accepted draft	0.114	total_ai_cost / accepted_drafts
Unit	Cost per resolved case	0.155	total_ai_cost / resolved_cases
Value	Estimated labor value	210,000	AHT reduction * loaded labor rate
Value	Net value	131,000	estimated_labor_value - total_ai_cost
Guardrail	Citation correctness	96.4%	必须高于 release gate
Guardrail	Safety incidents	0	S0/S1 按风险等级处理
Decision	Scale decision	Scale with cache expansion	当成本、质量、SLO 和 adoption 同时达标

Review questions：

cost per resolved case 的变化来自成本下降，还是 resolved case 增加。
cache savings 是否建立在正确权限、版本和地区控制上。
human review cost 上升是质量问题，还是高风险流量占比增加。
哪个路线位于 cost-quality frontier 之外。
是否存在低成本但低采纳、低质量的“伪优化”。

12. 模板 2：Cost Allocation Schema

12.1 Request-Level Schema

Field	Type	Example	Required	用途
`trace_id`	string	`trc_cs_20260629_001`	Yes	全链路回溯
`tenant_id`	string	`retail_banking_us`	Yes	多租户归因
`business_unit`	string	`contact_center`	Yes	showback / chargeback
`cost_center`	string	`cc_4102`	Yes	财务归集
`use_case_id`	string	`customer_service_copilot`	Yes	AI portfolio 归因
`workflow_step`	string	`draft_answer`	Yes	定位成本发生点
`risk_tier`	enum	`medium`	Yes	决定 route 和保留策略
`environment`	enum	`prod`	Yes	sandbox 成本隔离
`user_role`	string	`contact_center_agent`	Yes	adoption 和权限分析
`route_policy_version`	string	`route_v18`	Yes	成本变化解释
`cache_status`	enum	`retrieval_hit_answer_miss`	Yes	计算节省和失效问题
`business_outcome_id`	string	`case_849201_resolved`	Conditional	连接业务结果

12.2 Cost Event Schema

Field	Type	Example	Required	用途
`cost_event_id`	string	`ce_model_000341`	Yes	成本事件唯一标识
`trace_id`	string	`trc_cs_20260629_001`	Yes	关联 request
`component`	enum	`model_call`	Yes	model/retrieval/tool/judge/human/observability
`provider`	string	`approved_model_provider_a`	Yes	供应商或内部平台
`model_or_service`	string	`medium_rag_model`	Conditional	模型或服务名
`input_tokens`	number	`2410`	Conditional	模型事件
`output_tokens`	number	`380`	Conditional	模型事件
`gpu_seconds`	number	`0.42`	Conditional	自托管推理
`api_calls`	number	`2`	Conditional	工具或检索
`unit_price`	number	`0.000002`	Yes	当期价格表
`allocated_cost_usd`	number	`0.0084`	Yes	分摊后成本
`allocation_method`	enum	`direct_metered`	Yes	direct_metered / proportional / shared_pool
`pricing_version`	string	`pricebook_2026_06`	Yes	审计和重算
`retention_class`	string	`prod_90d_trace_1y_aggregate`	Yes	观测数据成本

12.3 Allocation Rules

成本类型	分配规则	示例
Direct model API	按实际 token 和价格表直接分配	客服 Copilot 2,410 input tokens 直接归属 contact_center。
Shared GPU pool	按 GPU seconds、priority weight 和 reserved floor 分摊	AML 质量 lane 的 reserved floor 归属 compliance budget。
Vector DB	按 query count、index size 和 tenant 权重分摊	KYC 文档索引按 document owner 和查询量共同分摊。
Observability	按 trace volume、retention class 和 risk tier 分摊	高风险 AML trace 保留更久，成本归属 AML owner。
Platform baseline	作为 portfolio shared service 单独列示	gateway、policy engine、eval runner 基线成本走平台基金。
Idle reserved capacity	按 reserved owner 分摊，未指定 owner 时进入 platform optimization backlog	客服峰值预留低谷闲置由 contact_center 和 batch jobs offset。

13. 模板 3：SLO / Cost Matrix

Use case	Risk	SLO	Cost SLO	Optimization allowed	Optimization blocked	Owner
Customer Service Copilot	Medium	p95 TTFT <= 2s；citation correctness >= 95%	cost per resolved case <= 0.18 USD	cache policy answers、reduce output length、route simple questions to small model	remove citation、disable escalation、cache customer-specific answer	Contact Center PM + AI Platform
AML Copilot	High	unsupported suspicious claim = 0；expert pass >= 98%	cost per accepted narrative <= approved case budget	pre-index evidence、batch historical summaries、template narrative structure	remove expert sampling、allow AI final SAR decision	AML Owner + Compliance
KYC Document Extraction	Medium/High	required field recall >= approved threshold；batch SLA <= 4h	cost per document <= 0.42 USD	off-peak batch、doc type routing、spot for retryable jobs	delay priority onboarding、skip critical field validation	KYC Ops + Platform
Code Agent	Medium	CI pass；security scan pass；no secret leakage	cost per accepted change <= 12 USD	repo map cache、test selection、retry cap	bypass code owner review、share restricted repo context	Engineering Productivity
Customer-Facing AI	High	p95 total <= 5s；safety incident = 0；availability >= 99.9%	cost per completed journey <= campaign target	cache generic content、pre-warm capacity、approved fallback	disable guardrail、remove handoff、route restricted data to public endpoint	Digital Product + Risk
Payment Risk Model	High	p99 decision latency <= 80ms；fraud recall and false positive targets met	cost per prevented loss within model risk budget	feature cache、two-stage model、distillation	skip high-risk scoring、defer synchronous decision	Fraud Risk + Payments Architect

Review cadence：

Pilot：每周评审 cost、quality、latency、adoption。
Release：每两周评审异常和趋势。
Scale：月度 FinOps review + 季度 portfolio funding review。
High-risk：任何 S0/S1 事件立即进入 incident review。

14. 模板 4：Capacity Plan

14.1 Capacity Plan Summary

Field	Example
Use case	Customer Service Copilot
Business calendar	发薪日和信用卡账单日流量增加 2.4 倍
Monthly request forecast	1,200,000
Peak request forecast	120 RPM for 3 hours
Token profile	p50 input 2K；p95 input 8K；p95 output 700
Cache assumption	semantic/retrieval combined hit rate 38%，campaign week 降至 24%
SLO	p95 TTFT <= 2s；p95 total <= 8s
Capacity floor	70 RPM through reserved provider capacity
Spillover	80 RPM approved on-demand route for 4 peak days/month
Batch lane	QA sampling、policy regression、offline summaries after 21:00 local time
Degradation	low-risk route answers capped at 350 tokens；complex/high-risk stays quality-first
Hard stop	citation SLO breach or high-risk escalation miss triggers freeze scale

14.2 Capacity Calculation Example

Metric	Example value	Explanation
Peak RPM	120	customer service forecast
Cache hit under peak	24%	peak questions more personalized
Effective model RPM	91.2	120 * (1 - 0.24)
Avg total latency	6.5s	measured in load test
Concurrency needed	9.9	91.2 / 60 * 6.5
Headroom factor	1.4	provider variance and traffic burst
Planned concurrency	14	concurrency_needed * headroom
Reserved coverage	70 RPM	steady affordable floor
On-demand burst	50 RPM	peak spillover
Batch deferral	100% of non-customer batch during peak	protect interactive SLO

14.3 Capacity Review Questions

预测基于 request count 还是 effective model requests。
峰值 token profile 是否不同于平均 token profile。
SLO 违规时先降级哪类 workload。
restricted data 是否有足够私有容量。
on-demand spillover 是否有预算和供应商 rate limit 确认。
reserved idle 是否能被 batch workload 填谷。
capacity plan 是否记录碳效率和区域选择约束。

15. 模板 5：Routing / Cache Policy

policy_id: route_cache_customer_service_v18
owner: ai_platform_pm
approved_by:
  - contact_center_product_owner
  - ai_risk_lead
  - finops_lead
effective_date: 2026-06-29
default_route:
  model_alias: medium_rag_model
  max_output_tokens: 700
  judge_profile: selective_medium_risk
rules:
  - name: low_risk_policy_faq
    when:
      risk_tier: low
      data_classification: internal_or_public
      customer_specific: false
    route:
      model_alias: small_fast_model
      cache_mode: semantic_answer_cache_allowed
      max_output_tokens: 350
      judge_profile: sampled
    cost_guardrail:
      max_cost_per_answer_usd: 0.025
  - name: customer_account_question
    when:
      customer_specific: true
      data_classification: confidential
    route:
      model_alias: medium_rag_model
      cache_mode: retrieval_cache_only
      max_output_tokens: 650
      judge_profile: citation_required
    safety:
      require_handoff_for_complaint: true
  - name: high_risk_complaint_or_regulatory
    when:
      risk_tier: high
    route:
      model_alias: strong_approved_model
      cache_mode: no_answer_cache
      max_output_tokens: 900
      judge_profile: strict
    safety:
      require_human_review: true
      final_customer_message_by_ai: false
  - name: budget_pressure_low_risk
    when:
      daily_budget_consumed_percent_gte: 70
      risk_tier: low
    route:
      model_alias: small_fast_model
      cache_mode: cache_first
      max_output_tokens: 250
    blocked_changes:
      - do_not_change_medium_or_high_risk_routes
cache_key:
  required_fields:
    - tenant_id
    - user_role
    - permission_scope
    - product
    - jurisdiction
    - policy_version
    - knowledge_base_version
    - prompt_version
    - risk_tier
invalidation:
  - policy_version_change
  - permission_scope_change
  - knowledge_base_refresh
  - product_terms_change
  - incident_kill_switch

Policy review：

任何新模型路线必须有 eval result、cost estimate、data boundary 和 rollback rule。
任何 answer cache 必须证明不会跨权限、跨地区、跨客户状态复用。
任何 budget pressure rule 必须声明不会影响高风险路线。

16. 模板 6：Budget Alert Rules

Alert	Trigger	Severity	Action	Owner
Daily budget burn	use case daily spend >= 70% before 14:00 local time	Medium	low-risk cache-first；notify business owner	FinOps Lead
Cost per resolved case anomaly	7-day rolling cost per resolved case +30% and quality unchanged	Medium	inspect token profile、route mix、cache miss	Platform PM
Quality-cost regression	cost down >= 15% and human rejection up >= 10%	High	rollback route/cache change	Product Architect
GPU idle burn	reserved GPU utilization < 35% for 5 business days	Medium	move batch workload to idle window or reduce commitment next cycle	AI Ops
Queue SLO breach	p95 queue wait > 1s for 30 minutes in customer-facing route	High	activate on-demand spillover；pause batch and sandbox	AI Ops
Agent loop cost spike	retry or tool loop cost > 2x 7-day baseline	High	enable loop guard；disable affected tool route	Platform Architect
Sandbox runaway	sandbox tenant reaches 90% monthly quota	Low	hard cap at quota；require funding request for extension	Platform PM
High-risk budget overrun	high-risk use case exceeds approved monthly budget by 15%	High	business/risk/finance review; no automatic downgrade	Business Owner
Carbon efficiency drift	off-peak batch runs in high-carbon window while lower-carbon window available	Low	reschedule eligible batch workload	AI Ops

Alert design principles：

每条 alert 必须能 drill down 到 traces 和 cost events。
预算 alert 不应自动牺牲 high-risk safety route。
anomaly 要看 unit cost，不只看总 spend。
alert 要区分 growth-driven spend 和 inefficiency-driven spend。

17. 模板 7：Portfolio Funding Gate

Gate question	Evidence required	Customer Service Copilot example
业务成果是否可量化	baseline、target、business owner signoff	AHT baseline 420s，目标下降 12%，FCR 不下降
成本单位是否正确	unit economics worksheet	cost per resolved case 0.155 USD
质量和风险是否可接受	eval report、SLO/cost matrix、incident plan	citation correctness 96.4%，S0/S1 0
容量是否可保障	capacity plan、reserved/on-demand strategy	70 RPM reserved + 50 RPM spillover
多租户归因是否完整	allocation schema、tenant tags、showback report	contact_center cost_center cc_4102
降本空间是否清楚	cost-quality frontier、routing/cache experiments	low-risk FAQ cache hit 从 38% 提升到 52%
碳和效率是否纳入	batch window、idle GPU reuse、region constraints	QA batch 移到 off-peak，填充 reserved idle
扩容是否有退出条件	stop rules、budget guardrails	cost per resolved case 连续 2 周 > 0.22 且无价值提升则冻结扩容

Funding decision wording：

Decision: approve scale from 20% to 60% contact-center traffic.
Reason: quality SLO, safety SLO and cost per resolved case are within approved range; capacity plan covers billing-day peak.
Conditions: keep high-risk complaint route unchanged; improve cache hit for low-risk FAQ; review unit economics weekly during scale-up.
Budget owner: Contact Center VP.
Platform co-owner: AI Platform PM.
Next review: 2026-07-29.

18. 模板 8：Executive Memo

# Executive Memo: AI FinOps and Capacity Gate for Customer Service Copilot

## Decision Needed
Approve scaling Customer Service Copilot from 20% to 60% of contact-center traffic for the next 30 days.

## Business Outcome
The pilot reduced average handle time by 11.8% while keeping first-contact resolution stable. Agent accepted drafts in 74% of quality-passed answers.

## Unit Economics
Monthly pilot run-rate cost is 79,000 USD. Cost per resolved case is 0.155 USD. Estimated monthly labor capacity value is 210,000 USD, producing 131,000 USD net value before platform shared-service allocation.

## Quality and Risk
Citation correctness is 96.4% against a 95% gate. S0/S1 incidents are 0. High-risk complaint flows still require human review and are not included in cost-first routing.

## Capacity
Billing-day peak forecast is 120 RPM. Plan covers 70 RPM reserved baseline and 50 RPM approved on-demand spillover. Non-customer batch jobs are paused during peak windows.

## Cost Controls
Low-risk policy FAQ will move to cache-first route. Daily budget alert triggers at 70% burn before 14:00 local time. Cost per resolved case above 0.22 USD for two consecutive weeks freezes further scale.

## Carbon and Efficiency
Offline QA and regression jobs will run after 21:00 local time and use reserved idle capacity before buying additional batch capacity.

## Recommendation
Approve conditional scale with weekly FinOps review and no relaxation of citation, escalation or human-review gates.

19. 30 天训练计划

Day	训练主题	产出
1	选择一个 AI use case，定义业务 outcome 和 risk tier	Use Case Brief
2	梳理 request trace 和 workflow step	Trace-to-Cost Map
3	建 token、GPU、call、case 四层成本模型	Cost Driver Inventory
4	填第一版 AI unit economics worksheet	Unit Economics v1
5	定义 successful answer、accepted action、resolved case	Outcome Definition
6	设计 cost allocation schema	Allocation Schema
7	做一次 showback report 样例	Showback Report
8	定义 SLO/cost matrix	SLO/Cost Matrix
9	建 cost-quality frontier 假设	Frontier Hypothesis
10	设计 risk-tiered routing policy	Routing Policy v1
11	设计 semantic/retrieval/prompt cache policy	Cache Policy v1
12	建 budget guardrails 和 alert rules	Budget Alert Rules
13	梳理 capacity inputs：流量、token、SLO、峰值	Demand Model
14	计算 reserved baseline 和 on-demand spillover	Capacity Calculation
15	设计 batch lane 和优先级队列	Batch and Priority Plan
16	设计多租户 quota、priority、chargeback/showback	Multi-Tenant Policy
17	把 OpenCost/Kubernetes 资源口径映射到 AI workload	Infra Cost Mapping
18	加入 GPU/device/plugin/resource quota 视角	GPU Capacity Notes
19	把 eval、judge、human review 纳入完整成本	Eval Cost Model
20	做客服 Copilot 案例	Customer Service FinOps Pack
21	做 AML Copilot 案例	AML FinOps Pack
22	做 KYC 文档抽取案例	KYC Extraction FinOps Pack
23	做代码 Agent 案例	Code Agent Economics Pack
24	做客户-facing 峰值容量案例	Peak Capacity Plan
25	做支付风险实时模型案例	Real-Time Risk Capacity Plan
26	设计 carbon/efficiency review	Efficiency Review Sheet
27	写 portfolio funding gate	Funding Gate Memo
28	写 executive memo	Executive Memo
29	准备 CTO/CFO/SRE 面试回答	Interview Answer Set
30	汇总作品集叙事：从 token bill 到 AI value control plane	Portfolio Narrative

最终作品集包：

AI FinOps Capacity Pack
  01-use-case-brief.md
  02-unit-economics-worksheet.xlsx
  03-cost-allocation-schema.md
  04-slo-cost-matrix.md
  05-capacity-plan.md
  06-routing-cache-policy.yaml
  07-budget-alert-rules.md
  08-portfolio-funding-gate.md
  09-executive-memo.md
  10-interview-answer-set.md

20. 面试回答

20.1 30 秒版本

AI FinOps 的核心不是压低 token 账单，而是把 AI 成本和业务结果绑定。我要能按 use case、tenant、workflow step、risk tier 追踪 token、GPU、模型调用、检索、工具、judge、human review 和 observability 成本，再算 cost per successful answer、cost per resolved case 或 cost per prevented loss。优化必须在 quality、SLO 和风险边界内发生，否则只是把成本转移到返工和事故里。

20.2 2 分钟版本

我会把 AI FinOps 设计成平台控制面。入口是 AI gateway，所有请求带上 tenant、use case、risk tier、workflow step 和 cost center。每次模型、检索、工具、judge 和人工复核都产生成本事件，进入 cost ledger。然后按业务结果计算 unit economics，比如客服是 cost per resolved case，AML 是 cost per accepted narrative，KYC 是 cost per document processed，支付风控是 cost per prevented loss。

容量上我不会只买 GPU。我会先看流量、token profile、cache hit、SLO 和风险 mix，再决定 reserved baseline、on-demand spillover、spot batch 和降级策略。低风险高频请求可以用小模型和 semantic cache；中风险客服草稿要保留 RAG 和 citation judge；高风险 AML 和支付风控不能因为降本牺牲 human review、审计和安全门禁。治理上要有 showback/chargeback、budget guardrails、SLO/cost matrix 和 portfolio funding gate。这样才能向 CTO 解释架构，向 CFO 解释 ROI，向 AI Ops 解释容量和告警。

20.3 CTO 追问

Q: Model routing 怎么避免只按成本选最便宜模型？

A: Routing policy 必须同时看 task type、risk tier、data boundary、quality threshold、latency SLO、budget 和 cache eligibility。低风险 FAQ 可以 cost-first，高风险 AML narrative 必须 quality-first，restricted data 必须 privacy-first。每次 route 都记录 route reason，并用 cost-quality frontier 审查。如果成本下降伴随 human rejection、unsupported claim 或 incident 上升，就回滚路线。

Q: 自托管 GPU 和外部模型 API 怎么比较？

A: 先把两者转成相同成果单位。API 看 token 和 call 成本，自托管看 GPU seconds、idle burn、serving stack、运维、可用性和容量风险。最终比较 cost per successful answer 或 cost per resolved case，并叠加数据边界、SLO、供应商依赖和模型质量。GPU 便宜但利用率低、排队高或质量差，未必比 API 划算。

Q: 多租户 AI 平台怎么防止一个团队耗尽资源？

A: 请求层强制 tenant/use_case/cost_center 标记，资源层用 quota、priority queue 和 namespace/resource quota，平台层设置 monthly budget、daily burn alert 和 sandbox hard cap。customer-facing 和 regulated workloads 有 capacity floor，sandbox 和 batch 是可抢占。showback 先让团队看见成本，scale 后做 chargeback 或 portfolio funding。

20.4 CFO 追问

Q: 你怎么证明 AI 投资值得继续？

A: 我不会用 token 使用量证明价值。我会展示单位经济：总成本拆成模型、检索、工具、judge、人工复核、观测和容量闲置；收益按 resolved case、AHT 降低、误报减少、损失避免或开发周期缩短计算。只有通过质量和风险阈值且被业务采纳的结果才进入分母。然后用趋势说明 scale 后单位成本是否下降、业务 outcome 是否改善。

Q: 成本超预算时先砍哪里？

A: 先归因，不直接砍模型。看是流量增长、token 膨胀、cache miss、强模型路线过多、agent loop、judge 过重、human review 增加、GPU idle 还是 on-demand 峰值。低风险场景可以降级模型、限制输出、提高 cache；batch 可以延后或用 spot；高风险场景要业务和风险 owner 接受成本，不能自动降级安全和审计。

20.5 AI Ops / SRE 追问

Q: AI 容量告警和普通服务告警有什么不同？

A: 除了 CPU、memory、5xx，还要看 queue wait、TTFT、total latency、provider rate limit、GPU utilization、KV cache pressure、cache hit、route mix、token p95、cost per request 和 SLO 违规。AI 服务可能 HTTP 200 但质量失败，也可能技术正常但预算失控。告警必须能 drill down 到 trace 和 cost events。

Q: 峰值容量不足时如何降级？

A: 按预定义层级。先暂停 sandbox 和 batch，再开启 on-demand spillover，然后对低风险请求启用 cache-first、小模型和短输出。中高风险请求保持质量路线，只允许排队、人工 fallback 或受控流量限制。客户-facing 场景不能关闭安全 guardrail 和人工转接。

21. 自检清单

是否为每个 use case 定义了正确的成果单位，而不是只看 token。
是否把模型、检索、工具、judge、human review、observability、idle capacity 都纳入成本。
是否按 tenant、business unit、cost center、workflow step、risk tier 做归因。
是否能解释 cost per successful answer 和 cost per resolved case 的变化。
是否有 SLO/cost matrix，明确哪些成本优化被允许、哪些被禁止。
是否有 routing/cache policy，并记录 route reason、cache status 和版本。
是否把 reserved、on-demand、spot、batch、spillover 和降级策略写进 capacity plan。
是否有 budget alert rules，并能 drill down 到 trace 和 cost event。
是否区分 showback、soft chargeback、hard chargeback 和 portfolio funding。
是否把 carbon awareness、idle capacity、off-peak batch 和区域选择纳入效率讨论。
是否为多租户平台定义 quota、priority、capacity floor 和 sandbox hard cap。
是否能向 CTO 讲清架构，向 CFO 讲清 ROI，向 AI Ops 讲清容量和告警。

22. Final Principle

AI 成本治理的成熟标志不是“账单下降”，而是“每一美元花在什么智能能力、服务哪个业务结果、消耗哪类容量、承担什么风险、是否值得继续扩容”都能被解释。

在金融零售 AI 里，真正的 FinOps 能力不是让模型少回答，而是让高价值回答得到保障、低价值消耗被约束、峰值容量可预测、多租户成本可归因、质量和安全不被降本吞掉。

参考来源链接

FinOps Foundation Framework: https://www.finops.org/framework/
FinOps for AI: https://www.finops.org/framework/technology-categories/ai/
FinOps for AI Overview: https://www.finops.org/wg/finops-for-ai-overview/
Cost Estimation of AI Workloads: https://www.finops.org/wg/cost-estimation-of-ai-workloads/
OpenCost Documentation: https://opencost.io/docs/
OpenCost Specification: https://opencost.io/docs/specification
Kubernetes Resource Management for Pods and Containers: https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/
Kubernetes Resource Quotas: https://kubernetes.io/docs/concepts/policy/resource-quotas/
Kubernetes Device Plugins: https://kubernetes.io/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/
Kubernetes GPU Scheduling: https://kubernetes.io/docs/tasks/manage-gpus/scheduling-gpus/
Kubernetes Horizontal Pod Autoscaling: https://kubernetes.io/docs/concepts/workloads/autoscaling/horizontal-pod-autoscale/
Kubernetes Node Autoscaling: https://kubernetes.io/docs/concepts/cluster-administration/node-autoscaling/
NIST AI Risk Management Framework: https://www.nist.gov/itl/ai-risk-management-framework
Green Software Foundation Software Carbon Intensity: https://greensoftware.foundation/standards/sci/
Learn Green Software: https://learn.greensoftware.foundation/introduction/
AWS Well-Architected Sustainability Pillar: https://docs.aws.amazon.com/wellarchitected/latest/sustainability-pillar/sustainability-pillar.html
Google Cloud Carbon Footprint: https://cloud.google.com/carbon-footprint