# 1. 输入、输出、缓存读写、reasoning thinking 与工具附带费用随 Provider 定价变化时，版本化价格字典与请求级归集链路应如何设计，才能保证历史账单在调价后仍可复算 A 价格与用量应分离并各自版本化，归集时按请求时点取当时生效的价格版本复算，保证历史可复算 ✓ 正确答案 B 价格应直接硬编码在代码里，调价时改代码即可 C 调价后应一律用最新价格重算所有历史账单 D 历史账单只记录最终金额，不需要保留用量快照与价格版本
# 2. 预算护栏的软告警、限流与硬熔断三级应如何划分职责，既避免单租户超额拖垮整体，又防止小额异常累积成大账单 A 软告警、限流、硬熔断三者只在达到预算上限时才触发 B 软告警用于预警、限流用于降速防止异常滚动放大、硬熔断用于阻断超额，且护栏按租户隔离并设全局兜底 ✓ 正确答案 C 单租户一旦熔断应拖垮全部租户以强制止损 D 小额异常无需检测，等月末账单统一处理即可
# 3. 单个 Agent 任务超预算被熔断后，已产生的部分结果、已执行的付费工具调用和未出账的在途请求应如何处置，才能最小化损失且与 Provider 账单对得上 A 已执行工具调用如实记账、部分结果保留为降级完成、在途请求终止并只结算实际返回的 usage，从而与 Provider 账单对齐 ✓ 正确答案 B 已产生的部分结果应完全丢弃，避免污染数据 C 已执行的付费工具调用可以回滚，不记账 D 在途请求无论是否返回都应全额计费
# 4. 为什么成本归集不能只在月末做，近实时（分钟/小时）归集应如何落地并与 Provider 的计费周期窗口对齐 A 实时归集用估算值驱动运营决策，月末用 Provider 实际账单校准，并设置容忍带吸收偏差 ✓ 正确答案 B 月末归集完全够用，实时归集没有价值 C 实时归集与 Provider 账单必须完全一致，否则无法使用 D 归集时点应以请求发送时间为准，与完成时间无关
# 5. 上下文裁剪、模型路由、缓存、Batch 和输出限制如何进入质量—成本联合评估 A 每种降本手段只关注成本下降，无需考虑质量 B 用带标注的自有评估集统一度量各手段的成本下降与质量损失，并以单位业务成本为指标比较 ROI ✓ 正确答案 C 质量无法量化，只能靠主观判断 D 上下文裁剪与缓存不会影响任何质量
# 6. 输入、输出、缓存读写、推理 thinking、Web Search、文件存储等费用应如何归集到单个业务请求 A 归集主键应为单次 LLM 调用，而非业务请求 B 一笔请求只可能产生一种计费项 C Web Search 与文件存储费用无法归集，只能忽略 D 以业务请求 ID 为主键，把 token、缓存、thinking、搜索、存储等所有计费项关联到其下，非 token 费用由工具层显式上报 ✓ 正确答案
# 7. 成本异常检测（单租户成本突增）应如何结合业务事件（活动、爬虫） A 维护事件日历，对照判断突增是否与已知业务活动吻合，并结合动态基线区分合理波动与真实异常 ✓ 正确答案 B 用固定阈值告警即可，不用管业务事件 C 成本突增一律视为爬虫刷量，无需判断 D 动态基线会掩盖所有真实异常，应禁用
# 8. 怎样建立每次成功任务成本，而不被“单 Token 更便宜但重试更多”的模型误导 A 单 token 更便宜就代表任务更便宜，无需考虑重试 B 失败任务成本应混入成功任务一并计算 C 应把任务内所有尝试（含重试）成本累加，除以成功任务数得到"每次成功任务成本"，避免被单 token 低价误导 ✓ 正确答案 D 重试成本不应计入任务成本
# 9. Provider 定价与折扣为何不应写死，成本配置怎样按官方资料核查和更新 A 价格应写死在代码里，调价时改代码 B 折扣只要混入单一单价即可，无需单独建模 C 价格与折扣应集中化、版本化配置，以官方定价资料为唯一可信源，定期核查并更新 ✓ 正确答案 D 价格无需追溯，历史账单用当前价重算即可
# 10. 限制最大输出后质量下降时，如何通过结构化回答、分阶段生成或按需展开补偿 A 限制输出长度不影响质量，无需补偿 B 可通过结构化回答提高信息密度、分阶段生成分解长任务、按需展开把深度内容延后到需要时来补偿 ✓ 正确答案 C 唯一的补偿办法是提高 max_tokens D 被截断的回答应直接丢弃，不返回给用户
# 11. 成本归集应包含哪些“自建成本”，GPU、电费、运维人力、备份网络，如何与 Provider API 成本统一核算 A 自建成本只需算 GPU 采购价，无需考虑电费与人力和闲置 B 自建成本应折算为包含折旧、电费、人力、闲置的每百万 token 成本，再与 API 单价在同一口径下比较 ✓ 正确答案 C 自建成本无需摊销，一次性都算当年 D 只要自建就一定比 API 便宜
# 12. 模型路由（任务复杂度 → 不同模型）应如何避免“降级到便宜模型导致质量崩塌” A 只要模型便宜就一律降级，无需管质量 B 降级后无需验证，直接返回结果 C 路由只需要看 Prompt 长度判断复杂度 D 用可靠判据 + 置信度/校验 + 失败回退升级，并对高价值任务设硬性护栏，用误路由率监控 ✓ 正确答案
# 13. 月度账单超出预算时，应按租户、模型、功能分级告警并自动降级（限流、固定模板） A 超预算就应直接停机所有服务 B 所有功能应同等待遇，不分优先级 C 降级无需告知用户，静默执行即可 D 按租户/模型/功能分级告警，并按限流→降级模型→固定模板逐步降级，优先保护高价值功能且对用户透明告知 ✓ 正确答案
# 14. Provider 定价变化（如 GPT-4o 价格调整）应如何通过配置中心快速反映到应用 A 价格变化应每次改代码发版 B 配置中心推送后立即全量生效，无需灰度 C 通过配置中心热更新价格表，带版本与生效时间，走灰度发布并支持回滚，保证历史计费可复算 ✓ 正确答案 D 价格版本无需管理，直接用最新价
# 15. 长上下文请求的成本优化（上下文压缩、检索替代）应如何与质量损失做联合评估 A 用带关键信息标注的评估集度量压缩/检索后的 token 下降与质量下降，用边际权衡选压缩率，并可级联回退全量上下文 ✓ 正确答案 B 长上下文优化只需压缩到最短，不管质量 C 检索替代一定不会丢信息 D 长上下文成本与长度无关
# 16. 推理 thinking tokens 在账单中不可见时，应如何结合 Prompt Caching 与上下文裁剪做总成本优化 A thinking tokens 不可见就完全无法优化 B 只需优化可见的 input/output token C 通过 Prompt Caching 稳定前缀与上下文裁剪降低输入复杂度，以"总 token 成本 + 缓存命中率"为监控口径间接优化 thinking 成本 ✓ 正确答案 D 缓存不会影响 thinking 成本
# 17. 多租户共用同一模型实例时，应如何按 token、缓存命中与工具调用综合分摊以避免小租户贴大租户 A 共享实例应把所有成本按租户数平均分摊 B 按各租户真实 token 用量、缓存命中量与工具调用量综合分摊，缓存命中按实际命中 token 归因，避免小租户贴大租户 ✓ 正确答案 C 缓存成本无法分摊，只能忽略 D 大租户应承担少量，小租户应承担大部分
# 18. 上下文压缩、检索替代与 Batch 路由三类优化应如何按质量与成本联合评估，挑选 ROI 最高的组合 A 三类优化收益可直接相加，无需实测 B 只要做了其中一种就无需组合 C 用统一评估集分别/组合测算各手段的成本下降与质量影响，按帕累托前沿与单位业务成本挑 ROI 最高的组合，并实测叠加冲突 ✓ 正确答案 D 压缩与 Batch 一定互不冲突
# 19. 跨云、跨 Provider 混合部署时，成本报表应如何做汇率、计费单位（token、字符、秒） A 直接按当前实时汇率折算即可，无需记录 B 用汇率快照统一币种、明确各计费单位（token/字符/秒）且折算方式透明，保留原始数据供对账、归一化数据供决策 ✓ 正确答案 C 所有计费单位都能折算成 token，无需标注 D 报表只需展示原始计费数据
# 20. 推理 thinking tokens 与可见输入输出 tokens 在租户账单中为何要分别核算，避免看不见的扣费 A 在租户账单中分别列示可见输入/输出/thinking/缓存 tokens，计费规则透明，避免看不见的扣费 ✓ 正确答案 B thinking tokens 应并入可见输出，不单独列示 C thinking tokens 对租户不可见，因此无需计费 D 分开核算会让账单更复杂，应尽量合并
# 21. 多业务线共用模型网关时，公共成本（网关、缓存、评估、闲置配额）应如何分摊，才能减少团队间争议 A 公共成本按各业务线人数平均分摊 B 事前约定透明规则，固定成本按比例、可变成本按真实用量分摊，提供可复查明细减少争议 ✓ 正确答案 C 公共成本无需分摊，由公司统一承担 D 按业务线收入占比分摊最公平
# 22. 预算熔断在业务高峰期触发时，排队、降级小模型与固定模板回答应如何取舍，并向用户诚实告知能力受限 A 高峰期应直接拒绝所有请求，不做任何告知 B 按业务价值与时效性取舍排队/降级小模型/固定模板，并对用户诚实告知能力受限与恢复预期 ✓ 正确答案 C 固定模板适合所有高价值实时任务 D 降级无需告知用户
# 23. 失败请求（重试、超时、被审核拒绝后重写）产生的成本应如何归集与归因，区分必要成本与缺陷成本 A 失败成本应全部并入成功任务成本 B 重试成本无需归集，因为不影响总量 C 给请求打结果标签与归因标签，区分必要成本与缺陷成本，缺陷成本单列并驱动改进 ✓ 正确答案 D 所有失败都是模型问题，无法区分
# 24. 预算护栏规则本身应如何版本化与变更审计，防止配置错误导致误熔断或护栏被静默关闭 A 护栏阈值可随意修改，无需审批 B 护栏被关闭会主动告警，无需自检 C 护栏一旦设置就无需再检查 D 护栏规则版本化、变更审批 + 灰度 + 审计 + 自检，防止误熔断与护栏被静默关闭 ✓ 正确答案
# 25. 多币种、多计费主体场景下，成本归集的口径（汇率快照、含税与否）应如何统一，避免财务与工程各有一套数字 A 财务与工程各自用自己的口径即可，无需统一 B 汇率用实时汇率即可，无需快照 C 统一基准币种、汇率快照、含税口径与成本归属，建立口径契约，估算口径与实际口径通过换算模板和差异报告对齐 ✓ 正确答案 D 含税与否不影响对账
# 26. Batch API 与在线请求混合部署时，结果领取协议与计费归属为何不能冲突 A Batch 与在线分通道领取、分计费口径（Batch 按任务提交、在线按请求），用任务 ID 关联，避免结果丢失与计费错位 ✓ 正确答案 B Batch 与在线请求可用同一套领取与计费逻辑 C Batch 结果必须轮询，否则无法计费 D 在线请求也可用异步回调领取
# 27. 成本归集应如何与租户配额、API 网关限流协同，在配额耗尽前自动降级而非 429 后才告警 A 成本归集与配额无关，各自独立 B 只有 429 才能触发降级 C 成本归集与网关限流联动，推演剩余配额与耗尽时间，在配额耗尽前主动降级而非被动 429 ✓ 正确答案 D 配额状态无需实时反馈给网关
# 28. 面向租户的 AI 用量计量（metering）记录应包含哪些字段，才能同时支撑计费、审计与争议处理，高并发计量写入如何可靠落地 A 计费记录只需租户 ID 和金额 B 高并发计量直接同步落库即可 C 计量字段覆盖身份/用量/计价/审计四类，写入用异步事件流 + 幂等去重 + 批量聚合，保证高并发下不丢不重 ✓ 正确答案 D 计量记录无需 trace ID，因为用不到
# 29. 订阅套餐 + 超量按量的混合计费下，Token 余额与配额扣减如何保证并发一致性（超卖、重复扣减、负余额） A 余额扣减可以先读后写，无需原子性 B 重复请求重复扣减是正常现象 C 负余额无需任何控制 D 用原子条件更新（balance >= cost 才扣）+ 按请求 ID 幂等，衔接套餐余额与超量按量，防止超卖、重复扣减与负余额 ✓ 正确答案
# 30. 账单争议场景下，如何用请求级 trace、usage 记录与缓存命中明细向租户举证，证据链应做到什么粒度 A 提供账单总额即可，无需明细 B 证据链粒度到请求级并可下钻到计费项，含 trace、usage、价格版本与缓存命中明细，保证可追溯、可复算、可核验 ✓ 正确答案 C 缓存命中明细无需展示 D 证据链只需租户 ID 和总金额
# 31. 免费额度、试用额度与付费配额并存时，扣减顺序与过期策略如何设计，防刷（多账号注册、脚本刷量）如何做 A 先扣付费额度，再扣免费额度 B 先扣临期免费/试用额度再扣付费配额，免费额度设有效期，并用风控、速率限制、行为校验防多账号与脚本刷量 ✓ 正确答案 C 免费额度无需防刷 D 所有账号免费额度应相同且无限
# 32. 计量口径如何与 Provider 账单对齐，差额（重试成本、失败请求）由平台承担还是转嫁，规则如何向租户说明 A 所有差额都应转嫁给租户 B 平台内部损耗应计入租户账单 C 差额无需向租户说明 D 平台自身原因（重试、故障）差额由平台承担，租户实际用量差额按真实计费，规则透明说明并设容忍带 ✓ 正确答案
# 33. 配额告警（临近耗尽、耗尽、宽限期）应如何在产品文案与 API 限流响应中设计，引导升级而非只返回 429 A 配额用尽只返回 429 即可 B 宽限期应直接全停服务 C 分临近耗尽/耗尽/宽限期设计产品文案，API 返回结构化错误码 + 恢复时间 + 升级指引，把限制转化为升级机会 ✓ 正确答案 D 配额耗尽无需给用户任何提示
# 34. 租户中途升降级套餐时，计费如何处理按比例折算、配额迁移与未用额度结转 A 按剩余天数比例折算差价、配额迁移衔接已用额度、明确未用额度结转规则，并在下单前给折算预览 ✓ 正确答案 B 升降级只按整月计算，不折算中途 C 降级时未用额度直接作废 D 升级时已用配额从新套餐外的额度扣
# 35. 计量数据的保留期与查询性能应如何规划，既支撑实时配额校验又支撑长周期对账 A 所有计量数据放一个存储，统一保留期即可 B 明细数据无需保留，只留汇总即可 C 热冷分层，热数据支撑实时校验、冷数据归档支撑长周期对账，保留期差异化并做预聚合提升性能 ✓ 正确答案 D 实时校验可以直接扫全量历史数据
# 36. 预算、硬配额、软告警和异常用量检测如何配合，防止单个 Agent 循环耗尽账户 A 只看账户级预算即可，无需 Agent 级控制 B Agent 循环无法检测，只能任其运行 C 在 Agent 级设硬配额（次数/时长）与异常检测识别循环并快速终止，账户级预算做兜底，分层设防 ✓ 正确答案 D 软告警即可解决问题，无需终止 Agent
# 37. 成本报表应同时展示“绝对成本”、“成本/请求”、“成本/用户”、“成本/功能”，单一指标为何不可信 A 只用一个总成本指标就足够 B 成本/请求越高越好 C 同时展示绝对成本、成本/请求、成本/用户、成本/功能并支持下钻，多指标联动才能区分增长与浪费、高价值与低价值 ✓ 正确答案 D 绝对成本低就代表成本控制好
# 38. 如何用 FinOps 思维让工程团队主动关心成本（按团队、按产品线分摊） A 成本只由财务负责，工程无需关心 B 工程团队只需要关注功能开发，成本与其无关 C 成本看板只给管理层看即可 D 按团队/产品线分摊成本并透明化，纳入团队 KPI 与复盘机制，让成本成为团队主动优化的运行指标 ✓ 正确答案
# 39. 多模型混用的成本归集，按会话、租户、功能模块如何分摊 token 成本？ A 所有模型统一用相同价格计算即可 B 请求带租户/功能/会话/模型维度标签，按每次调用的模型单价分别计价，支持任意维度聚合与下钻 ✓ 正确答案 C 只按租户维度归集即可 D 多模型混用无法归集成本
# 40. 预算护栏触发后的自动处置（降级模型/限制并发/通知）如何设计？ A 护栏触发就直接停机所有服务 B 所有功能处置应一视同仁 C 处置动作无需可恢复 D 按告警严重度分级匹配处置（通知→降级模型+限并发→熔断），优先保护核心功能，可恢复、可回滚、透明并审计 ✓ 正确答案
# 41. 内部试验、灰度流量与红队测试的成本应如何与生产账单隔离，避免扭曲单位业务成本指标 A 试验与红队成本应混入生产成本 B 给请求打流量类型标签，单位业务成本只统计生产流量，非生产成本单列，避免扭曲指标 ✓ 正确答案 C 灰度流量无需区分 D 红队测试成本应计入业务成本
# 42. Provider 账单对账出现差额时（延迟出账、估算偏差），应如何设置容忍带与告警，并在何时触发人工核查 A 基于历史差额设容忍带，带内不告警，超限/持续超限/集中在可疑项时触发人工核查定位根因 ✓ 正确答案 B 任何差额都必须人工核查 C 差额超过 0.01% 就停机 D 对账差额无需处理，直接采用 Provider 账单
# 43. 大模型、向量库、GPU 与工具调用全链路成本应如何按请求级归集，而不是按月粗粒度分摊 A 以请求 ID 为主键，把 LLM token、向量库检索、GPU 推理、工具调用按请求级计量并汇总，支撑下钻与优化 ✓ 正确答案 B 全链路成本按月粗粒度分摊即可 C 向量库与 GPU 成本无法按请求归集 D 粗粒度分摊能定位到单个请求
# 44. FinOps 在 AI 场景下应如何打通 OpenTelemetry GenAI span 与云账单，实现请求级成本归因 A span 与云账单完全独立，无法关联 B span 只记录耗时，不记录 token C 用 trace-id/request-id 把 GenAI span 的模型与 token 用量关联到云账单金额，按模型×token×价格对 span 计价，实现请求级归因 ✓ 正确答案 D 云账单无法回填到 span
# 45. 多模态（图像、音频、视频）请求成本应如何按分辨率、时长与压缩比例归集以避免单一指标误导 A 多模态成本按请求数统计即可 B 一张图无论分辨率都同等成本 C 按模态类型、分辨率/时长、压缩比例折算成成本当量归集，报表按承载量而非请求数展示，支持下钻定位高成本源头 ✓ 正确答案 D 压缩比例不影响成本
# 46. 如何以'模型 × 区域 × 工作负载'维度做成本归集，并与 FinOps 团队协作做月度优化复盘 A 按模型/区域/工作负载三维归集定位成本结构，与 FinOps 月度复盘评估优化效果、定下月优化项，工程与财务分工协作 ✓ 正确答案 B 成本只需按模型一个维度归集 C 月度复盘只做报表，不做优化 D 区域维度不影响成本归集
# 47. 如何建立"单位业务成本"指标（如单次客服解决成本）驱动模型选型？ A 模型选型只看 token 单价即可 B 用"每成功业务结果的总成本"（如单次客服解决成本）综合价格与解决率，选单位业务成本最低的模型 ✓ 正确答案 C 小模型永远最便宜，应无脑选 D 业务解决率与成本无关
