附录 C · 练习题
附录 C · 练习题
用法：八题覆盖全书，每题给提示与参考答案（普通段落，先自己做完再翻答案）。数值题的单价与流量均为（示意）；编程题基于第 6.1 节的 mini_obs.py。第 1.2 节的 21 问自评可作为第 0 题：让团队三类角色各答一遍，对答案本身就是练习。
练习一 · 三本账计算（第 3.1 节）
某次调用 usage：未命中输入 1,200 token，输出 800 token，缓存读 9,000 token，缓存写 0。单价（示意）：输入 3 美元/百万、输出 15 美元/百万、缓存读 0.3 美元/百万。（1）求本次费用；（2）求缓存节省额；（3）若账本只记总数（11,000 token 全按输入价），算出的数与真实费用差多少，说明什么？
提示：三项分别乘单价再除以一百万；节省额用（输入价 − 缓存价）× 缓存读 token。
参考答案：（1）(1,200×3 + 800×15 + 9,000×0.3) ÷ 1,000,000 = 0.0183 美元；（2）9,000×(3−0.3) ÷ 1,000,000 = 0.0243 美元——本次调用缓存省下的钱甚至超过了它花的钱；（3）只记总数会得 11,000×3 ÷ 1,000,000 = 0.033 美元，高估约 80%（示意）。说明只记总数既算错金额，也销毁了"缓存帮你省了多少"的证据——这正是第 3.1 节"只存总额等于销毁证据"的数值版。
练习二 · 三张桌子合一（第 2.2 节）
你们团队现状：日志在 ELK、计费在财务的表格、质量抽检在人工表格，三者对不上请求。请给出改造方案，让一次用户投诉能在 5 分钟内还原现场（第 1.2 节第 1 问）。
提示：从"一个 ID 贯穿三处"想起；再想每张桌子各自缺什么字段。
参考答案：要点五条——入口为每个请求生成 trace_id；用 contextvars 加日志 Filter，让日志自动携带 trace_id；token 账本行带 trace_id 与分摊键（团队/功能/用户）；用户反馈与抽检评分事件也带 trace_id；跨服务出站请求带 traceparent 头与版本标签（模型/prompt/检索库）。验收方式：随机抽一条点踩记录，5 分钟内拼出该次会话的 span 树、耗时、花费与评分——能做到，第 1 问转"能"。
练习三 · 抽样设计（第 4.1 节）
日调用量 50 万次，功能 A 占 98%、功能 B 占 2%（示意）。若统一按 2% 抽样，B 每天只有多少样本？请设计一个分层抽样方案，使 B 的日样本量提高到 2,000 左右，同时总裁判成本不升反降。
提示：算一下统一抽样的总样本量，再想大头功能的比例能不能降。
参考答案：统一 2% 时总样本 1 万条，B 只有约 200 条（1 万次 × 2%），日级波动基本被噪声淹没。分层方案：A 抽 1%（49 万 × 1% ≈ 4,900 条），B 抽 20%（1 万 × 20% = 2,000 条），总量约 6,900 条，低于原来的 1 万条——裁判成本下降而小功能的灵敏度提高一个数量级。两条纪律：抽样率随评分行记录（估算全局值时除以各自的 rate）；错误与点踩样本强制全采、不占抽样额度。
练习四 · 漂移阈值判断（第 4.2 节）
某功能 P95 延迟：7 天同时段基线 3.0 秒，昨日 3.0 秒，今日 4.4 秒；配置为基线带 ±30%、日环比 ±40%、静态底线 4.0 秒（均示意）。（1）判断今日状态；（2）若今日是 3.5 秒、昨日 2.9 秒呢？（3）第 1 问若又知当天上午有 prompt 变更，下一步做什么？
提示：三个阈值逐个算；带子是基线乘（1±30%）。
参考答案：（1）基线带 [2.1, 3.9]，4.4 越上带；环比 +46.7% 超过 40%，突变；4.4 也越过静态底线 4.0——三层全越，按第 4.2 节规则直接进提醒线以上。（2）3.5 在带内、环比 +20.7% 未越、未触静态底线——正常波动，不告警（这正是三层阈值法避免误报的例子）。（3）结合"当天有变更"，走第 5.2 节排障树坏/慢交叉路径：先拉探针分与输出长度信号确认质量是否同步恶化，用版本标签圈出 v 新版本的 trace 对比 v 旧版本；若仅新版本流量变慢，进入回滚评估——"当天有变更吗"永远是最高杠杆的问题。
练习五 · 给 mini_obs 装会话熔断（第 6.1 节，编程）
把第 3.3 节的 SessionCap 并入第 6.1 节的 MiniObs：给 ask() 加预检，超限会话返回用户可读话术，且不再产生任何 token 消耗。写出演示验收方式。
提示：预扣口径用"预计输入 + max_tokens"；SessionCap 类可直接从第 3.3 节拷贝。
参考答案（示意）：
# exercise_cap.py —— 给 mini_obs.ask() 并入会话熔断（参考答案，示意） class MiniObs: def __init__(self, day_budget: float = 0.02, cap_tokens: int = 30_000): # ……原有初始化不变…… self.cap = SessionCap(cap_tokens) # 第 3.3 节原样拷贝 def ask(self, question, user, session, turn=0): planned = 4_000 + 800 * turn # 预扣：预计输入 + max_tokens if not self.cap.allow(session, planned): return "[已熔断] 会话超出 token 上限，请重开会话" # ……原有 ask() 其余不变……
验收：用 turn=40 的长会话请求（planned = 36,000，超过 30,000 上限），应返回熔断话术；对比成本日结确认该请求 token 零消耗；再请求一次确认熔断保持、需人工复位。要点三条：宁可误杀的预扣口径、熔断状态进面板可见（它本身是第 4.2 节漂移信号）、复位走 runbook 不自动放行。
练习六 · 故障分类与排障（第 5.1、5.2 节）
周一 14:00 起，P95 从 3.2 秒涨到 7.5 秒，TTFT 从 1.0 秒涨到 5.8 秒；错误率、三本账结构均无变化；当天 10:00 有过检索库更新。（1）归类四类故障中的哪类？（2）沿排障树说出前两步看什么、两种可能分支各自的结论；（3）第一止损动作是什么？
提示：TTFT 恶化说明慢发生在哪一段？检索库变慢会体现在哪个 span？
参考答案：（1）超时与慢（延迟类），且无错误、无成本异动。（2）第一步看段占比（第 2.1 节"问题有固定住址"）：若 llm.call 段占比高且 TTFT 恶化，指向上游容量或排队——周一午高峰叠加，结论走"切轻量模型、限流排队"（第 7.2 节）；若 retrieve 段占比高，则嫌疑回到 10:00 的检索库更新（新索引慢查询），结论走"临时降检索篇数、评估回滚索引"。注意 TTFT 恶化本身更偏向前者——检索慢不拦首 token。（3）先止损后根因：下调检索篇数与 max_tokens、必要时切轻量模型保体验，同时按第 5.2 节留痕记时间线。
练习七 · 预算三线设计（第 3.3 节）
某功能月预算 6,000 美元（示意）。设计：日预算、三线触发条件、会话级上限的推导、以及"从不能到能"的验收方式。
提示：日预算按 30 天折算；会话上限从单轮成本 P95 × 预计轮数 × 安全系数推。
参考答案：日预算 200 美元。三线（参数示意）：提醒线——今日消耗速率达日预算 1.5 倍（相当于全天将烧 300 美元以上节奏），值班群查 TopN；暂停线——速率达 3 倍或单会话超上限，自动降级/熔断并通知负责人；升级线——月预算剩余不足 10%（600 美元），进决策会。会话上限：若单轮成本 P95 约 0.012 美元、预期 20 轮、安全系数 2，则单会话成本上界约 0.48 美元，按账本均价折算成 token 上限写入 SessionCap（预扣口径）。验收（第 1.2 节第三步）：把测试功能日预算故意调低，确认 10 分钟内收到提醒线、自动降级链路生效、熔断可在面板看到——三条都过，第 15、16 问转"能"。
练习八 · 容量测算与限速（第 7.2 节）
日调用量 12 万次，单次输入加输出 1,800 token，流量集中在 10 小时，峰值系数 2.5，平均时延 4 秒（均示意）。（1）求平均 QPS、峰值 QPS、峰值 token/分钟、稳态并发；（2）若供应商当前档位限 50 万 token/分钟（示意），给出两种处置；（3）三层令牌桶各自防什么？
提示：有效时长用 10 小时；并发用利特尔法则。
参考答案：（1）平均 QPS = 120,000 ÷ 36,000 ≈ 3.3；峰值 QPS ≈ 3.3 × 2.5 ≈ 8.3；峰值 token/分钟 = 8.3 × 60 × 1,800 = 90 万；稳态并发 ≈ 8.3 × 4 ≈ 33 路。（2）缺口 40 万 token/分钟：其一升档（花钱买容量，简单直接）；其二多密钥分池，按功能哈希把流量分到 2~3 个池（注意每池的突发缓冲被稀释，容量留余），大促前配合专项提额报备。（3）用户桶防刷量与失控会话突发、功能桶防单功能热点侵占（租户隔离）、全局桶防上游 429 与重试风暴；限速值与预算折算的峰值分钟预算取严者执行。