深夜十二点，你家的电表突然开始疯狂转圈，可屋里明明只开着一盏台灯。你怀疑是哪台空调偷偷运转，又担心是邻居偷接了电线，但翻遍整个房子也找不到原因。等月底拿到电费单，数字大得吓人——更可怕的是，你根本说不清这笔钱烧在了哪天、哪台电器上。 大模型的 Token 消耗，就像家里的用电量：每次调用都烧掉一定数量的“电”，并在账单上变成真金白银。输入 Token 是白天较便宜的电，输出 Token 是更贵的峰电；不同用户、不同场景则像不同的家电，耗电天差地别。这篇文章要教你给 AI 服务装一块“智能电表”：实时看到 Token 用量、按用户和场景拆分明细、在异常突增时自动跳闸告警、月底自动生成成本报表。从此，AI 服务花的每一分钱花在哪，都清清楚楚。

岗位关联

掌握 Token 实时追踪与告警，等于握住了 AI 服务的“成本方向盘”：既能第一时间揪出恶意刷量与重复死循环，也能在账单爆炸前主动踩刹车。这是从“会调 API”走向“能运维 AI 服务”的必备技能。

目录
  1. 可视化演示
  2. 核心指标
  3. 接入方式
  4. 链路追踪
  5. 告警阈值
  6. 成本报表
  7. 优化手段
  8. 落地实践
  9. AI 应用场景
  10. Python 演示
  11. 常见误区
  12. 面试题

可视化演示

展示系统处理流水线、实时性能指标曲线及多方案对比分析，包含数据流转、吞吐延迟监控与方案评估。

本节配有交互动效（进入视口后自动加载，约 3KB）。

系统可视化 处理流程：输入→处理→模型→输出 性能监控：实时指标 P=L×T

核心指标

装电表的第一步，是看懂电表上那几个数字：这个月用了多少度、白天用了多少、夜间用了多少、功率有没有超标。对大模型应用来说，第一步同样是明确要盯哪些“读数”——也就是核心指标。别急着接工具，先想清楚你要测量什么。

Token 就是大模型世界的“度”。一次 API 调用消耗的 Token 分成两部分：输入 Token（你发给模型的提示词）和输出 Token（模型生成的回答）。主流 API 都按两部分分别计价，而且输出单价通常是输入的 2～3 倍——就像峰电比谷电贵。所以“只看总度数”远远不够，必须拆开看。

单次调用的成本可以这样算：输入数量乘输入单价，加上输出数量乘输出单价，再除以 1000（单价按每千 Token 计价）。另外还要关注速率指标：每秒请求数（QPS）和每秒 Token 吞吐量。速率指标相当于用电功率，功率持续超标往往预示着异常调用或扩容需求。

总之，这几个指标构成了“电表读数”的全部。有了清晰的读数，下一步才是把这块电表真正装进系统——也就是接入方式。

cost=nin×pin+nout×pout1000\displaystyle \text{cost} = \frac{n_{\text{in}} \times p_{\text{in}} + n_{\text{out}} \times p_{\text{out}}}{1000}
一句话记忆：先把“输入、输出、单价、速率”这四个读数装进仪表盘，成本才是透明的。
  1. 输入成本先算输入部分的钱，输入 Token 数量乘以输入单价。
    Cin=nin×pinC_{\text{in}} = n_{\text{in}} \times p_{\text{in}}
  2. 输出成本同理，输出 Token 数量乘以输出单价，注意输出单价通常更高。
    Cout=nout×poutC_{\text{out}} = n_{\text{out}} \times p_{\text{out}}
  3. 合并并换算单位两笔费用相加，再除以 1000，把“每千 Token 价格”换算成实际金额。
    cost=Cin+Cout1000\displaystyle \text{cost} = \frac{C_{\text{in}} + C_{\text{out}}}{1000}

接入方式

想给家里装上电表，有三种常见做法：买个插座式电表插在电器前、请电力公司装智能电表自动回传、或者在总闸处装一块总表。对应到系统里，分别是手动埋点、SDK 接入和网关代理；实在不行，还有抄表员式的日志采集兜底。

手动埋点最直接：每次调用大模型后，从返回结果里取出 usage 字段（input_tokens / output_tokens），随手记进监控系统。它灵活、可控，但要求改动每一处调用代码，就像每个电器前都要插一个插座电表，工程量大。

SDK 接入则省心得多：通过 OpenTelemetry 这类可观测性库，在模型调用的请求管道上自动采集 Token 用量，再导给 Prometheus 或云监控。网关代理最“霸道”——在请求必经的代理层（如 LiteLLM）统一拦截计量，业务代码零侵入，还能顺手限流。如果以上都动不了，就靠日志采集：把每次调用的用量写进日志，离线再聚合。日志若按采样率 s 抽样，估算全量的公式如下。

四种接入方式没有绝对优劣：小团队手动埋点足够，存量系统优先网关代理，追求规范就上 SDK，日志永远是最兜底的那条路——就像租房用电表插座、整栋楼用总闸，各得其所。

N^=Nobss\displaystyle \hat{N} = \frac{N_{\text{obs}}}{s}
采样率越低，估算误差越大；关键计费场景建议全量采集，日志兜底时也要保证抽样比例稳定。
  1. 记录观测样本N_obs 是采样后实际记录到的 Token 总量，它只是全量中的一部分。
    Nobs=∑i∈SniN_{\text{obs}} = \sum_{i \in S} n_i
  2. 确定采样率s 是采样的比例，比如每 10 条请求抽 1 条时 s = 0.1。
    s=∣S∣∣T∣s = \frac{|S|}{|T|}
  3. 还原全量用量用观测值除以采样率，得到对全部请求 Token 量的估算。
    N^=Nobss\displaystyle \hat{N} = \frac{N_{\text{obs}}}{s}

链路追踪

只看整栋楼的用电量毫无意义——你必须知道是哪个房间、哪台电器在烧钱。链路追踪做的事情，就是给每次大模型调用发一张“身份证”：请求 ID。这张 ID 从业务入口一路跟着请求走到模型返回，把整条调用路径串成一条可查的链。

有了请求 ID，每一笔 Token 消耗都能贴上多维标签：user_id（谁在调用）、scene（哪个业务场景，比如客服、搜索、摘要）、model（用了哪个模型）。这相当于在每个房间装分户电表，再给每台电器装分电器表。谁在用、用什么、花多少，数据表里一目了然。

最常见的分析是按用户聚合：把某个用户所有请求的成本加起来，就能回答“这个账号一共烧了多少钱”。公式如下，其中 R_u 是该用户的全部请求集合，c_r 是第 r 条请求的成本。

链路追踪让“成本追凶”成为可能。当一个账号深夜狂刷客服机器人，你顺着用户维度下钻，几秒就能找到凶手——这正是肉眼盯总量永远做不到的事。

Cu=∑r∈Rucr\displaystyle C_u = \sum_{r \in R_u} c_r
维度标签是后续一切报表和告警的地基：没有拆分，只有“整栋楼很费电”；有了拆分，才有“302 室空调一夜没关”。
  1. 定义用户请求集合R_u 是用户 u 在统计周期内的全部请求集合。
    Ru={r∣user(r)=u}R_u = \{ r \mid \text{user}(r) = u \}
  2. 单次请求成本c_r 来自追踪数据里每条请求的 cost 字段，即该请求消耗的金额。
    cr=nin,r×pin+nout,r×pout1000c_r = \frac{n_{\text{in},r} \times p_{\text{in}} + n_{\text{out},r} \times p_{\text{out}}}{1000}
  3. 累加求和把集合里所有请求的成本加起来，就是该用户的累计成本。
    Cu=∑r∈Rucr\displaystyle C_u = \sum_{r \in R_u} c_r

告警阈值

电表最值钱的配件是保险丝和漏电保护：电流一异常就跳闸，防止烧坏整屋线路。Token 告警阈值就是大模型应用的“保险丝”，负责在成本失控前切断风险。没有它，账单爆炸往往发生在睡梦之中。

最简单的做法是静态阈值：比如“任意一小时内总 Token 超过 50 万就告警”。但业务有昼夜节律和周末效应，白天高峰本来就用得多，固定阈值要么白天天天误报，要么深夜漏掉真正的异常——就像保险丝粗细恒定，却要适配一年四季不同的负荷。

更聪明的做法是动态基线：用历史同时段数据算出“这个时间点正常该用多少”，再看当前值偏离常态几个标准差。标准差越大越异常，公式如下。突增检测还可以再叠一层：比昨天同一时刻高出 5 倍，直接判定异常。防误报靠两条体感规则：异常要持续多个采样点（比如连续 3 分钟）；数据先做平滑窗口，避免单个毛刺误触保险丝。

保险丝不是越粗越好，也不是越细越好，它必须容忍正常波动，却对真正的漏电一触即发。动态基线加持续判定，就是让告警既有弹性又有准头。

zt=xt−μtσt\displaystyle z_t = \frac{x_t - \mu_t}{\sigma_t}
z 值读到 3 以上，基本可以断定“这不是正常波动，是漏电”。
  1. 当前观测值x_t 是当前时刻的 Token 用量，比如最近 5 分钟的总消耗。
    xt=usage(t)x_t = \text{usage}(t)
  2. 历史参照系μ_t 与 σ_t 是从历史同时段数据算出的均值与标准差，描述“正常该是多少”。
    μt=mean(Xt),σt=std(Xt)\mu_t = \text{mean}(X_t), \quad \sigma_t = \text{std}(X_t)
  3. 偏离多少个标准差当前值减均值再除以标准差，z 越大异常越明确，超过 3 基本可判异常。
    zt=xt−μtσt\displaystyle z_t = \frac{x_t - \mu_t}{\sigma_t}

成本报表

月底的电费单会告诉我三件事：总电费、各房间分摊、跟上月相比涨了多少。成本报表就是把 Token 花费变成一张张这样的“电费单”，让每一分钱都有账可查。它是优化和追责的依据，也是财务和业务之间沟通的语言。

报表的常见维度有四个：按用户聚合，找出“用电大户”账号；按场景聚合，看哪条业务线在烧钱；按模型聚合，对比不同模型的单位成本；按天/周/月周期汇总，观察时间曲线。聚合之后必须支持下钻：先把用户排序，再点开某个用户看他的请求明细。

报表里最常用的一个数字是环比增长率：本期成本减上期成本，除以上期成本，再乘 100%。它回答的是“这个月是不是花得越来越快”。运维每天打开报表的第一句话通常是：“今天为什么比昨天贵？”答案就藏在这张表的下钻路径里。

报表最大的价值，是把“感觉上个月电费变多了”变成“客服场景环比涨了 40%，主要来自用户 mallory”。有了这本账，谈预算、做分摊、抓坏人，才都有据可依。

g=Ct−Ct−1Ct−1×100%\displaystyle g = \frac{C_t - C_{t-1}}{C_{t-1}} \times 100\%
增长率持续为正且加速，说明成本在滚雪球，必须马上翻到优化那一章动手。
  1. 本期成本C_t 是本期（比如本周）全部请求的成本总和。
    Ct=∑i∈this periodciC_t = \sum_{i \in \text{this period}} c_i
  2. 上期成本C_{t-1} 是上一个周期的成本，作为对比基准。
    Ct−1=∑j∈last periodcjC_{t-1} = \sum_{j \in \text{last period}} c_j
  3. 求变化率差值除以上期值再乘 100%，正数代表成本上涨，负数代表下降。
    g=Ct−Ct−1Ct−1×100%\displaystyle g = \frac{C_t - C_{t-1}}{C_{t-1}} \times 100\%

优化手段

电费太贵怎么办？换节能灯、错峰用电、少开大功率电器。Token 成本同理，也有四大“省电妙招”，而且都建立在前面几章的追踪能力之上——没有指标和报表，优化就是闭着眼省钱。

第一招缓存复用：把相同或相近的问答结果缓存起来，命中一次就省下整次模型调用，相当于随手关灯。第二招模型降级：非核心场景从旗舰大模型换到便宜的小模型，就像客厅大灯换成台灯，亮度够用就行。第三招限制速率：按用户或 API Key 设置 QPS 和日配额，从源头挡住刷量，类似稳压器防止浪涌。第四招压缩提示：精简 prompt、裁剪长期记忆，减少输入 Token 的浪费，好比顺手拔掉待机电器的插头。

缓存能省多少钱可以估算：每月总成本乘以命中率就是节省金额，公式如下。一个 30% 命中率的系统，月成本直接打七折；降级策略要按场景价值分级，别把客服这种高价值场景也一刀切。

省电不等于降低生活质量，降本也不等于牺牲体验。四大妙招的目标是一致的：用更少的 Token，换来同样好的用户体验——这才是优化的本质。

S=C×hS = C \times h
命中率 h 是优化效果的第一 KPI，报表里应该单独一列盯着它。
  1. 无缓存总成本C 是不做缓存时每月调用大模型的总花费。
    C=∑all requestscrC = \sum_{\text{all requests}} c_r
  2. 缓存命中率h 是命中缓存的请求数占全部请求的比例，取值在 0 到 1 之间。
    h=NhitNtotalh = \frac{N_{\text{hit}}}{N_{\text{total}}}
  3. 节省金额命中的请求本会重复计费，节省额就是总成本乘以命中率。
    S=C×h\displaystyle S = C \times h

落地实践

指标、接入、追踪、告警、报表、优化，六块拼图都画好了，最后要把它们组装成一套真正能跑的体系，就像小区要配配电房、请电工、写应急预案。落地实践这章讲的就是“整套体系怎么转起来”。

第一步是大屏看板：把 Token 用量、成本趋势、告警事件、预算余量集中到一块实时更新的屏幕上，让值班的人一眼看清全局。第二步是应急响应：告警触发后按处置手册走——先看是不是单用户刷量，再查有没有重试死循环，最后决定限流、降级还是断掉某个 API Key。处理完还要复盘，把处置结论沉淀成新规则。

第三步是预算护栏：设好月预算，当消耗达到 80% 自动降级非核心功能，相当于电卡余额不足自动断电。判断“还能撑几天”用下面的公式：剩余预算除以日均消耗速率。第四步是责任到人：每个场景指定成本负责人，每周 review 报表，把“谁用电谁负责”落到考核里。

一块电表的价值从来不在读数，而在于让人能及时关灯。Token 追踪也一样：指标是眼睛，告警是神经，报表是账本，优化与响应才是真正省下钱的那只手。

Dleft=Bremainingrdaily\displaystyle D_{\text{left}} = \frac{B_{\text{remaining}}}{r_{\text{daily}}}
当剩余天数跌破 7 天，系统自动预警并启动降级流程，而不是等月底傻眼。
  1. 剩余预算B_remaining 是当月尚未花费的预算余额。
    Bremaining=Bmonthly−CspentB_{\text{remaining}} = B_{\text{monthly}} - C_{\text{spent}}
  2. 每日消耗速率r_daily 是最近 7 天平均每天的 Token 成本。
    rdaily=Clast 7 days7r_{\text{daily}} = \frac{C_{\text{last 7 days}}}{7}
  3. 还能撑几天两者相除，估算当前速度下预算还能维持的天数。
    Dleft=Bremainingrdaily\displaystyle D_{\text{left}} = \frac{B_{\text{remaining}}}{r_{\text{daily}}}

AI 应用场景

场景 1：客服机器人“薅羊毛”识别

阶段：监控与告警（LLM 运维）

解决的问题：电商客服机器人按会话消耗 Token，恶意用户用脚本高频刷问答，单条请求看起来完全正常，只有 Token 总量在悄悄放大。传统只盯 QPS 发现不了异常。

具体案例：某团队接入实时追踪后，发现深夜 3 点“客服问答”场景 Token 突增 8 倍，按用户维度下钻定位到 mallory 账号单小时调用 2000 次，触发防刷策略限流，当月省下约 30% 成本。这正是“电表跳闸查漏电”的翻版。

场景 2：多业务线成本分摊

阶段：成本核算与报表

解决的问题：公司同时跑搜索、推荐、客服三条 AI 业务线，一张总账单无法分账，财务和业务各执一词。按请求标签（scene=搜索/推荐/客服）聚合，就能生成各业务线独立“电费单”。

具体案例：每月 5 号自动生成《各业务线 Token 成本报表》，按用户、场景、模型三张透视表呈现。推荐线环比增长 45% 被单独点名，业务方据此把推荐模型从旗舰大模型降级为蒸馏小模型，成本当月回落。

场景 3：预算护栏自动降级

阶段：成本治理与自动化

解决的问题：月底预算吃紧但业务不能停，靠人工盯盘既不及时也不可靠，需要系统自动化兜底。

具体案例：设定月预算 10 万元，实时追踪器每秒计算 D_left = 剩余预算 / 日均消耗。当预测剩余天数少于 7 天时，自动把非核心场景切换到便宜模型、开启缓存强命中，并把预警消息推送到值班群，全程无需人工干预。

Python 演示

python56 行
#!/usr/bin/env python3# -*- coding: utf-8 -*-"""极简 Token 用量追踪器: 记录请求, 按用户/场景聚合, 触发告警.""" from collections import defaultdict  class TokenUsageTracker:    def __init__(self, input_price=0.02, output_price=0.06, alert_limit=8000):        # 单价按每 1000 token 计算, 单位为美元        self.input_price = input_price        self.output_price = output_price        self.alert_limit = alert_limit        self.records = []        self.user_cost = defaultdict(float)        self.scene_cost = defaultdict(float)        self.alert_count = 0     def record(self, user, scene, input_tokens, output_tokens):        cost = (input_tokens * self.input_price + output_tokens * self.output_price) / 1000.0        self.records.append({            "user": user,            "scene": scene,            "input_tokens": input_tokens,            "output_tokens": output_tokens,            "cost": round(cost, 4),        })        self.user_cost[user] += cost        self.scene_cost[scene] += cost        total = input_tokens + output_tokens        if total > self.alert_limit:            self.alert_count += 1            print("[ALERT] user=%s scene=%s tokens=%d over limit=%d" % (user, scene, total, self.alert_limit))     def report(self):        print("\n=== user cost report ===")        for user, cost in sorted(self.user_cost.items(), key=lambda kv: kv[1], reverse=True):            print("  %s: $%.4f" % (user, cost))        print("=== scene cost report ===")        for scene, cost in sorted(self.scene_cost.items(), key=lambda kv: kv[1], reverse=True):            print("  %s: $%.4f" % (scene, cost))        print("total requests=%d alerts=%d" % (len(self.records), self.alert_count))  def main():    tracker = TokenUsageTracker(alert_limit=8000)    tracker.record("alice", "customer-service", 1200, 350)    tracker.record("bob", "document-summary", 3000, 900)    tracker.record("mallory", "customer-service", 4500, 4200)   # 疑似刷量    tracker.record("alice", "smart-search", 600, 180)    tracker.record("mallory", "customer-service", 5200, 3800)   # 再次越线    tracker.report()  if __name__ == "__main__":    main()
目的：一次性跑通“记录调用 → 聚合成本 → 超限告警 → 输出报表”的完整链路，直观看到 Token 追踪器在真实监控里扮演的角色。
  1. tracker = TokenUsageTracker(alert_limit=8000)创建追踪器并设置单次告警阈值，对应“保险丝”粗细。
  2. cost = (input_tokens * self.input_price + output_tokens * self.output_price) / 1000.0输入输出分别计价再折算成美元，正是核心指标章的那个公式。
  3. self.user_cost[user] += cost把本次成本累加到该用户名下，实现按用户维度聚合。
  4. if total > self.alert_limit:单次总 Token 超过阈值就触发告警，对应漏电保护跳闸。
  5. for user, cost in sorted(self.user_cost.items(), key=lambda kv: kv[1], reverse=True):按花费倒序输出，一眼看到“用电大户”。
  6. tracker.record("mallory", "customer-service", 4500, 4200)模拟一条高消耗的可疑请求，跑完代码你会发现它触发了一次告警。

常见误区

误区我以为每次调用大模型都花一样的钱，所以监控只看请求次数，请求量不高就放心了。

正解Token 消耗随输入长度和输出长度剧烈波动。同样调一次接口，让模型写一句话和写一篇 2000 字文章，花费能差几十倍——就像空调和台灯都耗电，功率完全不同。监控必须以 Token 数和成本为核心指标，请求数只能做辅助参考。

为何常见：来自传统 API 按次计费的惯性思维，忽略了 LLM 按量计费的本质。

误区失败的请求没有返回结果，应该不花钱，所以日志里只记 200 状态码的调用。

正解很多 LLM API 在调用失败（超时、被限流、流式中断）时照样计费，因为算力已经消耗。重试更是雪上加霜：一次失败重试 3 次，就悄悄烧了 4 份钱。追踪要全量记录，再按状态码分类；异常往往反而藏在失败流量里。

为何常见：大家习惯用“成功即完成”的传统接口思维理解计费，忽略了算力资源在请求发出时已被占用。

误区我担心半夜被警报吵醒，把阈值设成日常用量的 10 倍，结果月底账单翻倍都没响过一次。

正解阈值过大等于没装保险丝，过小则天天跳闸。正确做法是分级阈值加动态基线：基础阈值保底，动态基线抓异常，再结合持续时间和平滑窗口降误报。告警的价值不在多，而在“该响的时候一定响”。

为何常见：人天然厌恶被打扰，于是用“调大阈值”换取安静，却牺牲了预警能力。

误区我往项目里加了 OpenTelemetry 的 JS SDK，觉得所有 Token 消耗都会自动出现在看板上。

正解SDK 只自动埋点框架能识别的调用，需要配置正确 attribute（如 gen_ai.usage.input_tokens）才会收集；部分自研封装或流式调用还得手动补埋点，采样率也会影响统计。接入后必须做“计量校验”：拿 10 条已知请求对照真实账单，确认分毫不差再上线。

为何常见：工具宣传的“零侵入”容易让人以为自动化等于完整，忽略了配置和验证环节。

误区成本日报就是一行总数，今天花了 8000 块，比昨天涨了 10%，发给老板就完事。

正解没有拆分的总数无法回答“谁花的、花在哪”。合格报表至少要按用户、场景、模型三张透视表展开，并支持下钻到单条请求。运维每天靠它定位成本异常，财务靠它分摊预算，业务靠它判断优化效果——报表是分析工具，不是汇报道具。

为何常见：把报表当成“向上汇报”的仪式，忽略了聚合加下钻才是成本治理的真正入口。

面试题

Q1. 在大模型应用中，"Token"最适合被类比为什么？

单选题 · easy

  • A.家庭电表里的电量读数← 正确答案
  • B.服务器上的磁盘空间
  • C.网络带宽的流量包
  • D.数据库中的表字段数量

答案：A。Token 是 LLM 的计量计价单位，像电表的度数一样按消耗量计费；磁盘、带宽、字段描述的是其他资源维度，无法体现“模型按量收费”的本质。

Q2. 计算一次 LLM 调用的费用时，需要统计哪些 Token？

单选题 · easy

  • A.只有输入的提示词 Token
  • B.只有生成的回答 Token
  • C.输入与输出 Token 的总和← 正确答案
  • D.上下文窗口的最大容量

答案：C。主流 API 都按输入、输出分别计价，且输出单价通常更高；因此计费基础是输入与输出 Token 的总和，而不是上下文窗口容量。这就像电费单把白天和夜间电量分开算，最终都加进总账。

Q3. 存量系统不允许改动业务代码，最适合的 Token 追踪接入方式是？

单选题 · mid

  • A.在每次调用后手动埋点
  • B.在数据库里手动补录用量
  • C.在网关或代理层统一拦截← 正确答案
  • D.让前端页面自行上报数据

答案：C。网关代理处在所有请求的必经之路上，可以零侵入完成 Token 计量、限流和缓存，类似在总闸装电表；手动埋点和前端上报都要改代码或不可靠，数据库补录更无法实时追踪。

Q4. 某天 Token 总量突增 3 倍，但业务请求量只涨了 20%，最可能的原因是？

单选题 · mid

  • A.用户输入的平均长度变短了
  • B.出现了恶意刷量或重试死循环← 正确答案
  • C.模型响应速度变得更快了
  • D.结果缓存命中率明显提高了

答案：B。用量增速远超业务增速，说明单位请求的 Token 消耗被放大，常见于恶意刷量、指数级重试或提示词爆炸——就像家里没人却电表狂转，多半是漏电或有人偷电。缓存提升反而会降低用量，其余选项方向相反。

Q5. 关于动态基线告警，下列说法正确的是？

单选题 · mid

  • A.它与固定阈值告警完全等价
  • B.它只能检测用量下降的情况
  • C.它参考历史同时段数据自适应← 正确答案
  • D.它需要开发人员每周手动调整

答案：C。动态基线用历史同时段数据算均值和标准差，白天高峰不误报、深夜突增抓得准，就像保险丝会自动适配换季的用电负荷；固定阈值做不到自适应，检测方向和人工调整也都不是动态基线的特性。

Q6. 用 z-score 检测 Token 异常时，某时段历史波动极小导致 z 值虚高，合理的处理方式是？

单选题 · hard

  • A.把标准差直接设为零不再计算
  • B.放弃该时段所有的异常检测
  • C.加入最小基线时长与平滑窗口← 正确答案
  • D.只保留每日一次的统计任务

答案：C。σ 太小时 z 值会被放大，属于“噪声放大”现象。加入最小基线时长（如至少 14 天数据）和滑动平均窗口，能让 μ、σ 更稳健；把 σ 设为零或放弃检测都会留下监控盲区。

Q7. 在成本报表中，把用户 A 的全部请求成本加总属于哪种分析？

单选题 · hard

  • A.按场景维度聚合
  • B.按用户维度聚合← 正确答案
  • C.按模型维度聚合
  • D.按时间维度聚合

答案：B。按 user_id 分组求和就是用户维度聚合，相当于按房间分电表核算；场景维度看业务线，模型维度看机型，时间维度看周期，各自回答不同的问题。

Q8. 以下哪些手段可以有效降低 Token 消耗成本？

多选题 · mid

  • A.对重复问答启用缓存← 正确答案
  • B.低价值场景改用小模型← 正确答案
  • C.提示词中追加冗长历史记录
  • D.对异常用户启用速率限制← 正确答案

答案：ABD。缓存让部分请求不再调用模型，小模型单价更低，限流阻止刷量烧钱；而追加冗长历史会显著拉高输入 Token，恰恰是最常见的成本浪费。

Q9. 设计 Token 告警规则时，合理的设计包括？

多选题 · hard

  • A.结合历史数据确定动态基线← 正确答案
  • B.为不同业务场景设置不同阈值← 正确答案
  • C.所有场景统一用最高的阈值
  • D.告警触发时保留请求上下文← 正确答案

答案：ABD。不同场景的用量特征不同（客服高峰在白天、摘要任务在深夜），必须分开设阈值；统一最高阈值会让小场景“失明”。保留上下文则能让值班人员直接定位“谁在哪个请求里烧了钱”，对应急响应至关重要。

Q10. 关于 Token 用量数据采集，下列说法正确的有？

多选题 · mid

  • A.通过应用日志也能做离线分析← 正确答案
  • B.失败的请求可能已经产生费用← 正确答案
  • C.请求重试不需要再记录成本
  • D.请求 ID 用于关联完整调用链← 正确答案

答案：ABD。日志是全量记录的重要兜底；LLM API 可能在超时或流式中断时照样计费，重试则会重复计费，所以重试必须记录；请求 ID 把一次调用从入口串到模型响应，离线分析和链路追踪因此成为可能。