微调模型的 API 指标：应该追踪什么

一个微调模型只有在真实 API 流量下保持足够快、足够稳、足够便宜时，才值得留着。

如果从第一天起只追踪几样东西，我会盯着延迟、吞吐量、错误率、超时率、成功率、回退率、token 用量、每请求成本、队列深度和任务完成率。为什么？因为一个模型可以返回 200 OK，却仍然把任务搞砸、烧掉额外的 token，或者把用户逼走。

简而言之：

• 延迟： 盯着 TTFT 和 p95/p99，而不只是平均值。
• 吞吐量： 在生产并发下测试 RPS/TPS，而不是一次一个请求。
• 可靠性： 拆分 4xx、5xx、429、503 和 504，让失败模式一目了然。
• 超时： 更长的输出常常把微调模型推过请求截止时间。
• 成功 vs. 回退： 一个能工作的 API 响应，和一个可用的答案不是一回事。
• Token： 从 API usage 字段追踪输入、输出和总 token。
• 成本： 衡量每请求成本、每 1,000 token 成本和 p95 成本，而不只是月度支出。
• 容量： 队列深度和 KV 缓存压力常常在 GPU 图表之前就显示出麻烦。
• 用户结果： 盯着任务完成率、人工审查和放弃率。
• 回滚风险： 如果 p99 飙升、5xx + 超时超过 5%，或者相对基础模型的胜率跌破 50%–55%，我会把它当作一个硬性警告。

用自定义算力指标进行微调

快速对比

结论： 我不会仅凭离线分数来评判一个微调模型。我会在生产中把它与基础模型对比，在上线前设定回滚阈值，并保留一个仪表盘，在一个视图里展示 速度、失败、支出和结果。

为什么微调之后 API 指标更重要

微调会改变模型在生产中的行为。在真实流量下，延迟、token 用量和失败模式都可能变动。在某些情况下，微调通过替换长提示词来减少输入 token。在另一些情况下，它通过让补全更长而推高输出成本 ^[6]。这就是为什么离线的胜利本身意义不大。你必须对照真实的 API 指标来检验它们。

离线测试和生产之间的差距是真实存在的。研究表明，一个微调模型可以在特定任务的留出集上提升 12 分，却在像 GSM8K 这样的通用推理基准上损失 6 分 ^[2]。这不是什么奇怪的边缘情况。它是一种已知的失败模式，叫做 灾难性遗忘，即提升一项技能可能削弱其他技能。

这里的教训相当简单：一个微调可以帮到你在意的任务，同时仍然损害别处的表现。而那种基准漂移，如果你只盯着离线分数是看不清楚的。你要在生产信号紧挨着评测结果时才能看到它。

质量漂移不是唯一的问题。领域微调还可能削弱基础模型的拒绝行为，这让模型更容易被越狱和提示注入攻破 ^[2]。在生产中，这种滑坡会很快显现：成功率下降、回退率上升，错误激增开始以静态测试集捕捉不到的方式出现。这些变化会体现在随后的 API 指标中。

1. 端到端延迟

端到端延迟是从客户端发出请求到完整响应到达的总时间。这包括网络时间、排队、推理和响应传输 ^[7][9]。对于微调端点，这是最先要盯的生产信号之一。

一个理解延迟的简单方式是：total time ≈ TTFT + output_tokens × TPOT ^[9]。

TTFT 衡量第一个 token 出现的速度，这对流式应用非常重要 ^[9][10]。TPOT 是生成 token 之间的平均时间 ^[9]。这种拆分帮你看清微调之后发生了什么变化。响应速度是否变慢了？流式是否更晚开始了？token 生成是否放缓了？

微调模型通常比基础模型慢 10%–20%。如果延迟跳升超过 50%，那通常指向未合并的 LoRA 权重、缺失的量化，或者输出变得太长 ^[7][8]。有用的对比是对照基础模型。它会告诉你微调提升的任务质量是否足以证明这个速度代价是值得的。

尾部延迟是用户在慢速回合、重试和队列峰值中会注意到的东西。p95 TTFT 超过 3–4 秒会给用户造成明显的卡顿 ^[3]。在交互式聊天中，p95 TTFT 低于 500 ms 感觉是即时的。一旦超过 3–4 秒，体验就会迅速下滑 ^[12]。所以不要只对均值设 SLA。要对尾部延迟设。

高尾部延迟通常指向队列深度问题或冷启动开销，而不是原始 GPU 速度 ^[10]。这就是为什么百分位延迟本身比平均响应时间更重要。

在测量之前，先运行 2–3 次预热请求。首次调用延迟通常高出 30%–50% ^[8]。

2. p50、p90 和 p99 延迟

平均延迟会让情况看起来比实际更好。你可能看到平均响应时间为 1.2 秒，就以为端点表现良好，而 p99 却是 9 秒 ^[15]。这意味着 1% 的用户仍在等将近 10 秒，尽管仪表盘说一切看起来正常。百分位帮你看清微调是帮到了大多数请求，还是只是把卡顿推进了尾部。

以下是每个百分位对你的微调端点意味着什么：

用这些百分位在相同的流量组合下对比基础模型和微调模型。

微调之后，p50 和 p99 可能朝不同方向移动。如果你的微调导致更短、更结构化的输出，p50 可能下降，因为典型请求完成得更快。但 p99 可能攀升，如果模型有时变得更啰嗦 ^[7][15]。这种分化很重要。如果 p99 上升而 p50 保持平稳，那就是深入排查的信号，而不是平均响应时间。

p99 是你的回滚风险数字。 在你的 CI/CD 管道中围绕 p99 阈值设置回归门禁 ^[15]。如果一次模型更新把尾部延迟推过你的限制，构建应该在它进入生产之前就失败。

延迟告诉你请求感觉有多慢。接下来，看看端点能处理多少请求。

3. 吞吐量与每秒请求数（RPS）

延迟告诉你单个请求的表现。吞吐量告诉你端点在一段时间内能处理多少工作。

要追踪的主要数字是每秒请求数（RPS）、每秒 token 数（TPS）和每分钟 token 数（TPM） ^[17][18]。它们共同显示你的微调端点能否跟上实际流量，尤其是在使用统一 LLM API 管理多个供应商时。

这里有个陷阱：一个模型在一次性测试中可能看起来很快，一旦流量堆积起来却会崩溃。在并发下，你可能撞上吞吐量崩溃，即增加更多并行请求不再增加输出，而延迟开始猛烈飙升。那个拐点——吞吐量停止扩展的地方——就是你的容量天花板 ^[15]。

RPS 背后最大的因素之一是输出长度。如果微调开始给出更长的答案，即使回复更好，吞吐量也会下降，成本会上升 ^[6][8]。

盯着**有效吞吐量（goodput）**也有帮助，而不只是原始吞吐量。有效吞吐量是仍然满足延迟 SLO 的请求所占的比例。如果有效吞吐量低，端点可能很忙但仍然没达标。那种差距往往指向弱批处理或服务器饱和 ^[17]。

所以当你对 RPS 和 TPS 做基准测试时，要在生产并发下测试，而不是用单请求运行。与速率上限、队列深度和 VRAM 相关的限制常常在系统承压之前一直隐藏 ^[7][9][15]。如果端点在那里能守住容量，那就该检查这些请求是否成功了。

4. 按 HTTP 状态码统计的错误率

一旦负载受控，接下来要盯的是可靠性：端点失败的频率。错误率告诉你请求是否按应有的方式完成。实践中，这分成两桶：客户端失败和服务端失败。

4xx 错误上升通常指向提示词或 schema 不匹配，或者微调引入的上下文窗口问题。503 或 504 错误上升通常指向服务器压力或超时压力。当 5xx 错误激增时，把它当作严重的回滚风险。

这里还有一个金钱角度。失败的请求仍然消耗 token。要追踪浪费的支出，把失败请求的 token 费用加总，尤其是除 429 以外的 4xx 错误和任何 5xx 错误 ^[22]。而且如果重试逻辑过于激进，那些糟糕的重试会把推理成本推高 3 到 5 倍 ^[21]。

以下是最常见状态码的简单对照，它们通常来自哪里，以及接下来该做什么：

不要对每个错误码使用相同的重试逻辑。重试 400 只会烧掉更多算力，因为请求本身仍然是坏的。指数退避应该用在 429 错误上 ^[21]。如果 503 或 504 在三次检查中持续出现，触发熔断器并把流量路由到基线模型。

接下来，检查慢响应是否在完成之前就超时了。

5. 超时率

当错误上升而没有明显的彻底失败跳增时，超时率是下一个要检查的。超时仍然是一个失败的请求：客户端在截止时间前没有得到响应。把超时率追踪为超过那个截止时间的请求所占的比例，它通常表现为服务端超时错误。

微调模型更容易撞上超时，因为它们常常产生更长的输出。如果训练数据偏啰嗦，模型可能比基础模型每请求生成更多 token。这在使用 阿里 Qwen 模型或其他优先输出详细响应的高性能 LLM 时很常见。更多 token 意味着更多生成时间，而那多出来的时间正是把请求推过截止时间的原因 ^[8]。

如果队列深度持续高于零，系统已经处于容量上限。当这种情况发生时，超时率通常很快就会攀升 ^[12]。把队列深度当作早期预警信号，而不是等超时出现。如果队列深度和超时同时上升，你面对的就是一个容量问题，需要立即采取行动。一旦超时率稳定下来，把真正的成功与回退响应区分开。

6. 成功率与回退率

即使超时消失了，请求仍然可能没完成任务。成功率告诉你模型是否真的完成了任务，而不只是它是否返回了 HTTP 200。 这意味着检查诸如 schema 合规、正确的工具调用和事实准确性之类的东西。一个微调模型可以有很高的 token 准确率，却因为任务层面的回退而在真实生产查询中失败 15%–30% ^[23]。

回退率告诉你在微调端点失败、超时或被安全过滤器拦截之后，流量不得不被送往别处的频率 ^[4][5]。这就是为什么它应该紧挨着成功率一起追踪。你衡量的不只是完成，而是你能用的输出。

把这两个指标一起用作完成质量的主要信号。如果任何一个滑落，那就是检查微调相对基础模型是否仍然站得住脚的时刻。如果相对基础模型的胜率跌破 50%–55%，那是一个常见的回滚阈值 ^[2][4]。

如果成功率保持高位但成本开始攀升，接下来检查 token 用量。

如果每个请求的服务成本都太高，高成功率就没多大意义。

7. 每请求 token 用量

在可靠性之后，token 用量告诉你模型是否精简到足以规模化运行。它还显示微调是否在做它的本职工作——用习得的行为替代提示词开销。更低的 token 用量通常意味着更低的成本和更快的回复。

把输入、输出和总 token 作为独立的数字来追踪。这让你更容易在缓慢增长变成成本问题之前发现它。高输入 token 通常指向提示词膨胀或上下文溢出。高输出 token 通常意味着冗长的补全、弱的停止规则，或者没有输出上限。而且输出 token 比输入 token 更贵，所以冗长是最大的成本风险 ^[15]。

从每次响应的 API usage 对象中获取 token 计数，而不是从本地分词器估算 ^[15][25]。本地估算可能与计费数偏离。如果你看到 token 三倍激增，在找到原因之前先假设是提示词膨胀或上下文溢出 ^[3]。在 CI/CD 中设置输出 token 上限也有帮助，这样你能在冗长回归上线之前抓住它 ^[15]。

token 计数直接映射到支出，这就是为什么下一个指标是每请求成本。

8. 每请求成本与每 1,000 token 成本

Token 变成钱。但月度账单本身并不告诉你支出为什么上升。要看清是什么在驱动它，追踪每请求成本和每 1,000 token 成本。这给你下一层生产分析。

每请求成本显示单个用户动作的成本。从该请求已计费的输入、输出和缓存 token 费用计算它 ^[26][28]。然后单独追踪每 1,000 token 的计费费率。当你把这两个数字一起观察时，你能分辨支出上升是因为流量更多，还是因为提示词和补全在变长。这种模式常被称为 token 蔓延 ^[15][26]。

微调推理每 token 可能贵 2–5 倍，但当它缩短提示词长度时，仍能降低每请求成本 ^[29][30]。为什么？微调模型把角色定义、护栏和少样本示例烘焙进它的权重。所以每次调用的提示词都变短了。在一次基准测试中，微调模型只需要 42 个补全 token，而基础模型需要 85 个——每请求推理成本降低 50.6% ^[19]。说白了，更高的单价可能输给更低的 token 数量。那正是你想在真实 API 流量中衡量的收益。

给每次 API 调用打上 feature_name 和 user_tier 标签，这样你能把支出与产品使用连起来 ^[27][28]。当成本开始漂移时，这让数据有用得多。

有几项检查最重要：

• 密切盯着输出 token。按旗舰模型定价，它们可能比输入 token 贵 5 倍，所以砍掉一个啰嗦的答案，比砍掉相同数量的提示词 token 省得更多 ^[15]。
• 在你的 CI/CD 管道中给平均输出 token 设一个上限。这帮你在冗长回归进入生产之前抓住它 ^[15]。
• 按功能和用户层级审查成本，而不只是看总量。否则，昂贵的用量可能藏在一个看起来健康的总数里。

在成本之后，看看支出是匹配真实需求还是只是闲置容量。

接下来，把这些成本与基础设施利用率和队列长度对比。

9. 基础设施利用率与队列长度

如果延迟和超时上升了，接下来看服务层：队列、内存和缓存压力。队列深度在这里最重要。 GPU 利用率往往滞后于需求，所以它是一个滞后信号。这就是为什么自动扩缩应该基于每个副本的队列深度，而不是算力百分比 ^[10][32]。

KV 缓存使用是另一个团队常常忽略的指标。KV 缓存把 token 上下文存储在 GPU 内存中，当那块内存吃紧时，即使 GPU 算力看起来仍然空闲，引擎也可能开始给新请求排队 ^[31][32]。一个好的经验法则：把 40%–50% 的 KV 缓存使用当作早期预警，把 90%+ 当作饱和 ^[31][32]。

微调模型又加了一层曲折。LoRA 适配器需要在基础模型权重之上的内存，而在扩容后的第一个请求上加载它们会造成冷启动延迟。在大多数情况下，这会给 TTFT 增加几百毫秒 ^[10]。在启动时预加载适配器可以避免大部分这种损失。单独盯着 CPU 也有帮助，因为分词和预处理会增加容易被忽视的延迟 ^[10]。

如果这些容量信号仍然看起来健康，就转向输出质量。

10. 用户满意度与任务完成率

在延迟、成本和可靠性之后，最后一项检查很简单：模型完成任务了吗？ 一个微调端点可以快、便宜且稳定，却仍然没达标。

**任务完成率（TCR）**是无需人工帮助就解决的请求所占的比例。人工审查率是仍然需要人工修正的输出所占的比例。这个差别很重要。一个模型可以返回 HTTP 200，却仍然交回一些需要人先清理才能使用的东西。所以 TCR 追踪的是业务结果，而不只是 API 是否回答了。

在结构化输出工作上，500 个高质量样本可以把格式合规率从 68%–74% 推到 97%–99% ^[33]。这种跃升减少了员工需要介入的频率。一旦格式正确，就把微调模型直接对照基础模型比较。

速度在这里仍然重要。P99 延迟超过 5 秒会驱动大约 45% 的放弃率 ^[33]。所以如果微调拖慢了体验，用户会很快用行动告诉你——通过离开。

要做直接的质量检查，用配对竞技场测试。把 200–500 个生产样本同时跑过基础模型和微调模型，然后用 LLM-as-a-judge 并排给输出打分。之后，固定裁判模型和评分标准，让未来的测试保持一致。如果相对基础模型的胜率跌破 50%–55%，那是一个常见的回滚阈值 ^[2][4]。

把这些信号一起盯着也有帮助：

• TCR
• 竞技场胜率
• 一套冻结的基准套件

如果模型在通用基准上下降超过 5 分，就把它当作硬性失败，即使特定任务的分数上升了 ^[2]。

在决定微调是否已准备好投入生产时，把这些质量检查与前面章节的 API 指标放在一起用。

延迟与吞吐量对比表

对一个微调端点来说，没有单一指标能讲清全部故事。举个例子，平均延迟会抹平请求间的波动，尤其是在涉及供应商端排队和批处理时 ^[9]。

这就是为什么先各自单独测量延迟和吞吐量，然后在设定 SLO 之前把它们并排对比会有帮助。

按端点类型、模型版本、地区和一天中的时段拆分结果。高峰时段流量常常把非高峰测试抓不到的延迟问题暴露出来。

这些切分让你更容易看清微调端点在真实流量下从哪里开始吃力。

预示回滚风险的可靠性指标

需要回滚的最清晰信号是相对基础模型的胜率。运行配对金丝雀和影子路由，这样你能并排比较微调模型和基础模型。如果胜率跌破 50%，微调在生产中就不再增加价值了。当金丝雀队列在 30–60 分钟内保持任一单项评分标准质量分下降 2 分时，你的路由层还应该自动回滚 ^[2][4]。一旦这些对比转为负面，下一步很简单：找出正在崩溃的提示词分组。

还有几个信号应该充当回滚触发器：5xx + 超时率、拒绝率、无效输出率、429 激增和回退行为。这些是你在决定微调是否应该继续上线时最重要的数字。单独追踪 429 激增。它们常常指向更高的算力成本或更深的队列 ^[24][5]。

把拒绝率和无效输出率分开也有帮助，而不是把它们混为一谈。拒绝率超过 2% 常常指向安全回归，或者供应商过滤器与你的自定义提示词冲突 ^[5][35]。无效输出率通常指向 schema 漂移或更弱的指令遵循 ^[2][24]。

按提示词类型、工作流路由和模型版本拆分每个指标。一个模型可能在通用请求上看起来没问题，却仍然在结构化输出路径或领域特定提示词上吃力。这种切分让你更容易判断模型是否安全到可以继续运行，以及成本画像是否仍然站得住脚。

以美元计的成本、Token 和资源指标

在延迟、吞吐量和可靠性之后，下一步很简单：这个端点值这个钱吗？ 如果每个请求都太贵，稳定的流量帮助不大。一旦可靠性受控，你需要把 token 用量转化为美元。

对于 GPT-4o，微调推理定价在基础费率之上带有 1.5 倍加价。折算下来是每 100 万输入 token 3.75 美元和每 100 万输出 token 15 美元 ^[36]。只有当微调降低了获得成功结果的成本时，这笔额外开销才合理。一种常见的削减支出的方式是通过 AI API 的聚合折扣和模型级联：把简单查询发给更小、成本更低的模型，把更大的模型留给更难的任务 ^[37]。

跨精简、预期和高负载三种情况预测支出也有帮助。然后再叠加重试、回退使用和评测运行 ^[26]。这一步比许多团队预想的更重要，因为 40% 的团队在使用的第一个季度就超出了 AI API 预算 ^[37]。除此之外，追踪每请求的 p95 成本，而不只是平均值。否则，长上下文提示词或反复重试会以均值显示不出来的方式扭曲你的预测 ^[24]。原始支出只有在你把它与成功结果连起来时才变得有用。

那个连接就是每次成功结果的成本。实践中，这可能意味着每解决一张支持工单的成本，或每个被接受答案的成本。如果一个微调模型提升了成功结果的比例，即使每请求价格上升，你的每次解决成本也可能下降 ^[26][37]。

对于自托管部署，GPU 利用率是主要成本驱动因素。固定的 GPU 支出只有在使用量越过某个阈值后才划算。换句话说，高利用率在它改善成本效率时才重要。你还应该把队列长度和利用率放在一起盯。如果队列深度持续攀升，那通常是饱和、成本增加和更多扩容压力的信号 ^[11][15]。

把这些指标一起用，来分辨健康负载和昂贵浪费之间的区别。

你能通过 API 观察到的质量信号

一旦延迟、吞吐量和成本都处于良好状态，下一步很简单：检查模型是否真的在帮助用户把事情做成。速度当然重要。但一个快速却解决不了问题的答案仍然是一次失手。

先专注于任务完成率、升级率和人工交接率。这些是你主要的结果信号。它们告诉你微调模型是自己处理了请求，还是需要有人介入。这比基准分数更重要，因为这些指标来自真实的请求和会话日志。

你还可以追踪点赞/点踩评分和放弃率，作为与 API 流量挂钩的会话级支撑信号。即使反馈稀疏，它仍然能显示反复出现的痛点。放弃率尤其有用，因为它显示模型从哪里开始漂移、丢失上下文，或者在对话中途不再有用。

用 LLM-as-judge 抽样真实流量来估计幻觉和安全问题也有帮助。5% 的抽样通常足以捕捉异常，同时又不会把评测支出推得太高 ^[39]。也要留意护栏触发频率。如果超过 20% 的请求被拦截，那可能指向不安全输出的跳增，或者用户想要的与系统预期的之间不匹配 ^{[38] [1] [2]}。拒绝率急剧上升常常意味着过滤器变得太敏感，或者提示词模板在技术栈某处坏掉了 ^{[39] [2]}。

每一次真实的失败都应该作为永久案例回到离线测试集里。这就是你阻止同样的问题日后偷偷溜回来的方法。

用下面的表把主要质量信号与支撑信号区分开。

在可观测性仪表盘中，把这些信号与延迟和成本一起使用。

微调端点的可观测性仪表盘

追踪单个指标有帮助。但真正的回报来自你在一个地方看到全部。

一个可靠的微调端点可观测性配置建立在四大支柱上：用于汇总信号（如延迟和错误率）的指标、用于单个请求完整路径的追踪、用于所发生事情结构化记录的日志，以及用于异步质量检查的评测 ^[40][42]。

对微调模型来说这更加重要。一个请求可以在系统层面成功，却仍然在含义层面失败，即使在使用 AI 聊天界面时也是如此。所以仪表盘需要展示语义失败，而不只是传输成功。老派的 APM 能显示一个响应是健康的。它无法告诉你答案是否错了。一个 200 OK 仍可能藏着一个糟糕的结果。

围绕五个视图搭建仪表盘：延迟、可靠性、成本、质量和容量。使用带有 GenAI 语义约定的 OpenTelemetry，并对追踪做尾部采样，这样你能保留所有慢速和失败的请求，同时只采样一小部分正常流量 ^[40][41]。这种配置在事故期间也见成效：追踪可以把平均恢复时间缩短 3 倍 ^[42]。

用这些信号创建一个带有五个核心面板的仪表盘：延迟、可靠性、成本、质量和容量。

一个好的理解方式：延迟告诉你系统移动得 有多快，可靠性显示它是否保持在线，成本显示每个答案花了你多少钱，质量显示答案是否好，容量告诉你系统何时开始过热。

仪表盘设计表

这张表把每个仪表盘小组件与最合适的图表类型，以及在事故和成本审查期间让它有用的过滤器连起来。

要让这些过滤器从第一天就起作用，在埋点时给追踪打上模型 ID、提示词版本和环境标签。OpenTelemetry GenAI 语义约定包括诸如 gen_ai.request.model 和 gen_ai.usage.input_tokens 之类的属性 ^[40]。

选择能让失败模式一眼就看出来的图表。

成本归因显示哪个模型版本在驱动支出。追踪浏览器对 RAG 和 agent 工作流最重要，因为它展示跨检索、工具调用和推理的延迟与错误 ^[43][40]。

在定义好每个小组件之后，设置保留和采样规则。把所有高延迟、错误和低质量分的请求存进追踪浏览器。然后以 5%–20% 的比例采样常规成功请求，以控制存储成本 ^[40]。

结论

微调评估必须证明改进，而不只是变化。这就是为什么最终记分卡需要一起审视速度、可靠性、成本和结果指标。

如果你孤立地调优一个指标，生产问题会很快悄悄溜进来。一个模型可能变快了但变得更不稳定。或者它可能缩短了审查时间却推高了错误。关键是追踪全貌，而不是其中一片。

从基础模型开始。没有那个基线，你无法证明微调做得更好。运行一个 5%–10% 的金丝雀，通过影子路由把那些结果与基础模型对比。当延迟超过基线 2 倍，或者错误率持续 5 分钟超过 5% 时设置告警。一旦这些护栏设好，就把这些数字与运营节省连起来。

每个指标都应该映射到一个业务结果。人工审查率是运营节省的直接代理。如果那个数字不动，微调就没在创造生产价值。

仪表盘和告警不是可选项。在上线之前搭好可观测性，让回归在用户注意到之前就显现。

常见问题

我应该先监控哪些 API 指标？

从基础设施和可靠性指标开始，检查系统是否稳定。专注于第 95 百分位的 TTFT、端到端延迟、硬性错误率、拒绝率和每请求成本。

一旦你有了这些基线，就用 LLM-as-judge 评分和能力漂移盯着输出质量。这帮你发现模型是否开始在核心技能上滑坡。

我如何把微调模型与基础模型对比？

在相同的留出测试集上运行两个模型——数据从未在训练中使用过——这样你能干净地衡量差距。先在基础模型上从一个强提示词基线开始。这给你一个公平的比较点，而不是给自己开小灶。

从质量、延迟和成本三方面对比模型。

对于质量，使用适合任务的指标，比如：

• 分类或抽取任务用 F1
• 有唯一正确答案的任务用 精确匹配
• 结构化输出用 JSON 解析率

对于延迟，衡量端到端响应时间，而不只是原始模型运行时间。这意味着计时从提示词提交到最终输出的完整请求路径。

对于成本，使用每个模型的每 100 万 token 定价，并根据测试集上实际的输入和输出 token 用量计算你要付多少钱。

我应该何时回滚一个微调模型？

当生产监控显示质量明显下降时回滚。这可能指向模型漂移或在真实输入上的失败。

如果模型在你的拒绝集上滑坡、打开了新的提示注入弱点，或者在生产金丝雀测试中表现不如当前版本，你也应该回滚。

密切关注 p95 延迟和用户报告的质量问题，这样你能及早发现麻烦。