最近圈子里讨论最多的一件事，就是某模型推理云平台上线了新一代国产大模型的 V4 版本，并且一口气放出了 Flash 和 Pro 两条产品线。我在消息出来当天就把手上三个线上业务的调用切过去试了一遍，从玩具级别的对话 Demo 到日均百万级 token 的文档处理流水线都跑了一轮。这篇就把整个过程摊开讲：这两条线到底差在哪、什么业务该选哪个、API 怎么接、接完之后怎么压成本、线上出问题怎么排查。不管你是刚拿到 API Key 想跑通第一条请求的新手，还是已经在做多模型路由和成本治理的老手，下面这些内容应该都能直接拿去用。本文所有产品名称统一以“平台方”“V4 系列”“Flash 版”“Pro 版”代称，代码里的地址和 Key 请替换成你自己的。
1. 先把这次上线的产品结构看明白
1.1 Flash 与 Pro 不是简单的“大小号”关系
很多人第一反应是：Flash 就是小模型，Pro 就是大模型，选大的准没错。这个理解在 V4 这代上会吃亏。我实际跑下来，两者更像是“同一代基座、不同推理预算配置”的两个产物，而不是两个代际的产品。
最直观的差别在推理深度上。Pro 版在给出答案前会做更长的内部推理，尤其是在数学推导、多步逻辑、复杂代码重构这类任务上，它的中间过程明显更充分；Flash 版则把这条推理链压得很短，甚至在简单问题上直接走“直觉通道”，用极低的延迟给出结果。这就导致一个反直觉的现象：在分类、抽取、改写、意图识别这类任务上，Flash 的准确率跟 Pro 的差距往往在 1 到 2 个百分点以内，但延迟只有 Pro 的三分之一到五分之一，成本差距更大。
我自己拿一份 2000 条的客服工单做对比测试，任务是“判断工单属于哪个业务线并抽取关键实体”。Flash 版准确率 94.2%，平均耗时 620ms；Pro 版准确率 95.6%，平均耗时 2.4 秒。多出来的那 1.4 个百分点准确率，换来的是四倍延迟和数倍成本。这种场景下选 Pro 就是纯浪费。
反过来，在“给一段有 bug 的代码找出问题并重写”这种任务上，Flash 版的表现就会明显掉档，它经常只改表面语法问题，抓不到深层逻辑错误；Pro 版则能顺着调用链往上追。所以选型的核心不是“哪个更强”，而是你的任务需不需要长推理链。
1.2 平台方为什么要做双版本而不是一个全能款
这里得说一句平台侧的逻辑，理解了它，你在选型时就不容易纠结。推理服务的成本结构里，输出 token 的生成成本是大头，而 Pro 版长推理意味着输出 token 数量可能是 Flash 的数倍——注意，很多平台的计费口径里，推理过程产生的 token 也是要算钱的。如果只提供一个满血版本，那所有轻量任务都在为不必要的推理付钱，平台的单价也压不下来，用户侧的成本焦虑会直接劝退一大批量级用户。
所以双版本的本质是一次成本与质量的显式分层，把选择权交回给业务方。对平台来说，Flash 承担了绝大多数高并发、低价值的流量，Pro 承接高价值、低频次、需要深推理的请求，整体资源利用率更高。对我们这些使用者来说，好处是可以做分层路由——把 80% 的简单请求打到 Flash，20% 的复杂请求打给 Pro，整体成本能降一个量级，而端到端的业务指标几乎不掉。
我踩过的一个坑是：早期图省事，全量走 Pro，结果月底账单一出来，单次请求成本是预期的三倍多，原因就是大量“你好”“谢谢”这类寒暄也走了完整推理。后来做了路由分流，成本立刻回到可控区间。
1.3 版本迭代节奏对新接入方意味着什么
V4 这代上线后，平台方通常会保留上一代模型的可用期，给存量业务留迁移窗口。我的建议是：新项目直接用 V4，老项目别急着全量切。原因在于新版本在提示词上的行为会有细微漂移——同样一段提示词，老版本和新版本在输出格式的稳定性、对指令的服从度上可能有差异，尤其是那些靠着大量 prompt 微调才调稳的业务，直接切过去很可能出现格式解析失败率上升。
我自己的做法是保留一个“版本号常量”，在配置中心里统一管理，切版本只改一处，随时能回滚。这个习惯在模型快速迭代的时期能救命。
2. 选型决策：把业务指标翻译成模型参数
2.1 先回答三个问题，再谈选哪个
在写任何代码之前，我会逼着团队先回答三个问题，答不上来就先别接。
第一个问题：你的用户能容忍多长的等待？这决定了延迟预算。同步交互类场景，比如输入框联想、实时客服，用户的心理阈值大概在 1 秒以内，超过 1.5 秒就会明显感觉“卡”。Flash 版在短输出场景基本能压进 500ms，Pro 版的长推理很容易冲破这个线。异步场景，比如后台批量生成报告、夜间跑数据清洗，延迟完全不敏感，那就优先看质量。
第二个问题：单次任务的错误代价有多大？如果错了用户自己看一眼就能纠正，比如生成一段文案，那用 Flash 完全够；如果错了会直接造成资损或需要人工返工，比如自动审核、合同条款抽取，那就得用 Pro，或者至少用 Flash 加一层校验。
第三个问题：你的量级和成本上限是多少？拿日均 10 万次请求来算，Flash 和 Pro 的单次成本差距乘以 10 万再乘以 30 天，往往就是一笔能决定项目做不做得下去的钱。我一般会让团队先算一笔“月度成本上限”，再反推能用哪个版本。
这三个问题回答完，选型基本就自动出来了，不需要看任何 benchmark 榜单。榜单只能告诉你模型的上限，告诉不了你业务的约束。
2.2 Flash 与 Pro 的边界对照表
下面这张表是我根据自己跑过的几类任务整理的，可以直接对照参考。需要说明的是，具体数值会随任务复杂度、提示词质量、输出长度变化很大，这里给的是量级参考，不是精确承诺。
| 任务类型 | 推荐版本 | 延迟量级 | 质量差距 | 备注 |
|---|---|---|---|---|
| 文本分类、意图识别 | Flash | 300–800ms | 很小，1–2 个点 | 短输出，收益最高 |
| 信息抽取、结构化转 JSON | Flash | 500ms–1.5s | 小 | 建议配合 schema 校验 |
| 文案改写、摘要 | Flash | 1–2s | 中等 | 长文摘要可考虑 Pro |
| 多轮闲聊、客服问答 | Flash | 500ms–1s | 小 | 注意上下文长度控制 |
| 代码生成、单文件 | Flash 起步 | 1–3s | 中等 | 复杂重构切 Pro |
| 代码调试、跨文件重构 | Pro | 5–20s | 大 | 必须用 Pro |
| 数学推导、多步逻辑 | Pro | 5–15s | 大 | Flash 容易跳步 |
| 长文档深度分析 | Pro | 10–60s | 大 | 建议异步化处理 |
| Agent 规划与工具调用 | Pro 主导 | 视步数 | 大 | 规划用 Pro，执行可用 Flash |
这张表里我最想强调最后一行。做 Agent 类应用时，一个高性价比的组合是：规划环节交给 Pro，具体工具调用和结果格式化交给 Flash。规划错了后面全错，这块钱不能省；执行环节是重复劳动，Flash 完全够用。我在一个多步骤的数据处理 Agent 上做过这个改造，整体成本降了约 60%，任务成功率反而略有提升，因为规划环节的质量上去了。
2.3 分层路由的落地方式
分层路由听起来复杂，实现在代码里其实很简单。我的做法是在业务层加一个复杂度判定函数，输入是用户请求，输出是走 Flash 还是 Pro。
判定逻辑我一般按这几条来：
- 输入长度超过阈值（比如 8000 字符）且任务涉及全局理解，走 Pro；
- 命中关键词表（如“分析原因”“为什么”“对比优缺点”“重写这段代码”），走 Pro；
- 请求历史里出现过格式解析失败或用户负面反馈，这次走 Pro；
- 其余默认走 Flash。
这个判定函数不需要多聪明，规则化实现就能覆盖 90% 的情况。关键在于要能统计：每一次路由决策都要打点记录，跑一周之后你能看到 Pro 的调用占比，如果只有 5% 到 15%，说明路由是健康的；如果 Pro 占了 60% 以上，那说明你的规则太松，或者你的业务确实全是硬任务。
还有一个降级思路值得提前设计好：Pro 超时或失败时，自动降级到 Flash 重试一次。这在长推理场景下特别有用，因为 Pro 的响应时间波动比 Flash 大得多，遇到高峰期抖动时，降级重试能保住大部分用户体验。当然，降级重试必须记录，否则你会丢失“质量不达标却返回了结果”的隐蔽问题。
3. API 接入实战：从拿到 Key 到跑通第一条请求
3.1 接入前的准备工作
正式写代码前，有几件事先做好，能省掉后面大量麻烦。
第一，API Key 绝对不要写进代码。我见过太多项目把 Key 硬编码在源码里然后推到公开仓库。正确做法是放在环境变量或配置中心，本地开发用.env文件并加进.gitignore。生产环境用密钥管理服务，按环境、按服务维度分发不同的 Key，这样一旦某个服务出问题，可以单独吊销。
第二，搞清楚计费口径。几乎所有平台都按输入 token 和输出 token 分别计价，而且价格不同，通常输出更贵。Pro 版因为有推理 token，实际消耗的输出量可能远大于你看到的最终回复长度。这个差异在算预算时最容易漏。
第三，准备好一个测试用的语料集。不要用“你好，介绍一下自己”这种请求做验证，它测不出任何问题。准备 20 到 50 条真实业务样本，包含正常样本和边界样本，每次切换版本或改提示词都跑一遍，记录准确率、延迟、token 消耗三个指标。
第四，确认 SDK 与接口协议。V4 系列一般走兼容主流协议的风格，意味着你可以直接用现成的客户端库，只需要改base_url和模型名。这对存量项目迁移非常友好，改动量基本只有两三行。
3.2 第一条请求：完整代码与参数逐项说明
下面这段是我实际用的最小可运行示例，用 Python 写，走兼容协议的 SDK。
pip install openai python-dotenv# .env 文件，不要提交到仓库 API_KEY=your_api_key_here BASE_URL=https://your-endpoint.example.com/v1 MODEL_FLASH=v4-flash MODEL_PRO=v4-proimport os import time from dotenv import load_dotenv from openai import OpenAI load_dotenv() client = OpenAI( api_key=os.getenv("API_KEY"), base_url=os.getenv("BASE_URL"), timeout=60.0, # 整体超时，长推理场景必须显式设置 max_retries=2, # SDK 层重试，注意只对幂等请求安全 ) def chat(prompt: str, model: str, temperature: float = 0.2) -> dict: start = time.perf_counter() resp = client.chat.completions.create( model=model, messages=[ {"role": "system", "content": "你是一个严谨的信息抽取助手，只输出 JSON，不要任何解释。"}, {"role": "user", "content": prompt}, ], temperature=temperature, max_tokens=1024, stream=False, ) cost_ms = (time.perf_counter() - start) * 1000 usage = resp.usage return { "content": resp.choices[0].message.content, "finish_reason": resp.choices[0].finish_reason, "prompt_tokens": usage.prompt_tokens, "completion_tokens": usage.completion_tokens, "latency_ms": round(cost_ms, 1), } if __name__ == "__main__": sample = "订单号 A1024，客户反馈：收到的商品外包装破损，内件完好，希望补发包装。" r = chat(sample, os.getenv("MODEL_FLASH")) print(r)这段代码里有几个参数值得掰开讲，因为它们直接决定了行为能不能控住。
temperature：抽取、分类、格式转换这类任务，我一般给 0 到 0.3。温度高了输出格式会飘，JSON 少个引号就能让你的解析器崩掉。创意写作类才需要 0.7 以上。很多人抱怨“模型输出不稳定”，八成是温度没压下来。
max_tokens：这是成本的第一道闸门。不设上限，遇到模型“话唠”时输出能翻好几倍。按业务实际需要设置，比如摘要类给 500，分类类给 20 就够了。我见过一个分类任务没设上限，模型每次都要先解释一遍再给答案，成本白白多了三倍。
timeout与max_retries：SDK 默认超时可能长达数分钟，长推理场景下这个默认值会让你以为服务挂了。我通常按任务的 P99 延迟再加 50% 来设，比如 Flash 任务给 30 秒，Pro 的长推理任务给 120 秒。重试次数给 2 次足够，太多了会在服务波动时放大流量。
finish_reason：这个字段必须检查。如果是长度截断，说明max_tokens不够，返回的内容是不完整的，直接拿去解析会出错。
3.3 流式输出该怎么处理
同步交互场景一定要用流式。原因不只是“体验好”，而是首字延迟决定了用户觉得你快不快。Flash 版在流式模式下的首 token 通常在 200 到 400ms 之间返回，而等完整响应可能需要 1.5 秒以上，这个感知差距是数量级的。
def chat_stream(prompt: str, model: str): stream = client.chat.completions.create( model=model, messages=[{"role": "user", "content": prompt}], temperature=0.2, max_tokens=1024, stream=True, stream_options={"include_usage": True}, # 流式下默认不返回用量，需显式开启 ) first_chunk_at = None buffer = [] usage = None for chunk in stream: if first_chunk_at is None and chunk.choices: first_chunk_at = time.perf_counter() if chunk.usage: usage = chunk.usage if chunk.choices and chunk.choices[0].delta.content: piece = chunk.choices[0].delta.content buffer.append(piece) yield piece yield {"__usage__": usage, "__first_token__": first_chunk_at}这里有个极容易踩的坑：流式模式下用量统计默认是不返回的。你不开include_usage，就永远算不出真实成本，只能靠估算。我第一次做成本核算时就是因为这个，账目和平台侧对不上，查了半天才发现。
另外流式下要处理连接中断。用户关页面、网络抖动、网关超时都会导致流断掉，服务端要能感知并停止生成，否则白白消耗 token。生产环境里我一般会在生成循环里加一个“客户端是否还活着”的检查，发现断了就主动关闭流。
3.4 结构化输出与工具调用的稳定性技巧
结构化输出是业务落地最关键的一环。我的经验是：不要指望模型百分百输出合法 JSON，哪怕你用最强版本。正确姿势是“约束 + 校验 + 修复”三层。
第一层是提示词约束。把 JSON Schema 直接写进系统提示词，并明确“只输出 JSON，不要 markdown 代码块包裹，不要任何前后缀”。这一条能消掉大部分格式问题。
第二层是解析校验。用json.loads加 schema 校验库做严格检查，捕获异常而不是让程序崩掉。
第三层是修复重试。解析失败时，把错误信息和原始输出一起回传给模型，让它自己改一遍。这个“自修复”模式在实际业务里把格式成功率从 92% 拉到了 99.5% 以上。代价是多一次调用，所以要加个重试次数上限，一般 1 次就够。
工具调用方面，我建议工具描述写得越死越好。参数类型、必填项、取值范围、枚举值全部写清楚，不要留“模型自己领会”的空间。我遇到过一个典型案例：一个工具的参数叫date，描述只写了“日期”，结果模型有时候传2024-01-01，有时候传“明天”，有时候传“下周一”。改成明确写“格式必须是 YYYY-MM-DD 的字符串，不允许相对时间”之后，问题就消失了。
4. 成本治理：把账单压到能接受的位置
4.1 算清楚一次请求到底花多少钱
成本这件事必须先量化，不然所有优化都是凭感觉。计算方式很直接：
单次成本 = 输入token数 × 输入单价 + 输出token数 × 输出单价拿一个真实场景举例。我处理一份文档，输入 3000 token，输出 500 token。假设输入单价为 a，输出单价为 b（不同平台不同，这里只讲方法）。单次成本就是 3000a + 500b。看起来不大，但日均 2 万次调用，一个月就是 600 万次，这个量级下单价差一点点，月度账单就差出一大截。
关键是要统计分布而不是看平均值。我一般会记录 P50、P90、P99 三档的 token 消耗。因为成本往往被长尾拖垮——我遇到过一个情况，平均值看起来只要 1200 token，但 P99 是 15000 token，而长尾请求占了总量的 3%，却贡献了近 30% 的成本。找出这些长尾请求，往往是优化收益最大的地方。
长尾的常见来源有三个：用户粘贴了超长文本、多轮对话历史没有裁剪、模型进入了重复输出的循环。前两个很好解决，第三个需要在max_tokens和提示词里做双保险。
4.2 上下文管理的几个实用手段
历史裁剪是最基础的。多轮对话不能无限拼接历史，我一般保留最近 6 到 10 轮，更早的用一句话摘要替代。这个改动在客服类场景里通常能砍掉 40% 以上的输入 token，用户完全感知不到。
提示词分层是第二个手段。把系统提示词按稳定性分层：完全不变得放最前面（有利于平台侧做前缀缓存），每次请求变化的放最后。别小看这个顺序，很多平台的缓存机制是按前缀匹配的，你把变化的用户输入放在最前面，缓存就彻底失效了。我做过对比，调整顺序后，缓存命中率从几乎为零提升到了 60% 以上，输入成本直接降了一半。
输出长度约束是第三个手段。在提示词里明确“回答不超过 100 字”“只列出三条”，比单纯设max_tokens更有效，因为它省的是生成成本而不是截断成本。截断意味着模型已经生成了那些 token 但被丢弃，钱还是花了。
批量合并是第四个手段，很多人忽略。如果你要处理 100 条短文本，逐条调用 100 次和合并成 10 次调用，输入侧的重复系统提示词可以减少 90%。当然合并有上限，条数太多会导致准确率下降，我一般控制在每批 10 到 20 条。
4.3 并发与限流的正确姿势
平台侧一般都会给账号维度或 Key 维度的速率限制，通常是每分钟请求数和每分钟 token 数两个维度。踩过的坑是：只关注了请求数限制，忽略了 token 数限制，结果在大文档场景下被限流，报错信息还不太明显。
我的处理方案是一个简单的令牌桶加并发控制：
import asyncio from asyncio import Semaphore class RateLimitedClient: def __init__(self, client, max_concurrency=8, min_interval=0.05): self.client = client self.sem = Semaphore(max_concurrency) self.min_interval = min_interval self._last = 0.0 self._lock = asyncio.Lock() async def _pace(self): async with self._lock: loop = asyncio.get_event_loop() now = loop.time() wait = self._last + self.min_interval - now if wait > 0: await asyncio.sleep(wait) self._last = loop.time() async def call(self, **kwargs): async with self.sem: await self._pace() return await asyncio.to_thread( self.client.chat.completions.create, **kwargs )并发数不是越大越好。我实测过，在同一个账号下把并发从 8 提到 32，吞吐确实上去了，但 P99 延迟翻了一倍多，而且错误率明显上升。稳定在 8 到 16 之间是比较舒服的区间，具体取决于你的任务长度。
重试必须做指数退避加抖动。固定间隔重试会在服务波动时形成“重试风暴”，把本来快恢复的服务再次打垮。退避基数给 0.5 秒，每次翻倍，加上随机抖动，重试上限 3 次。
5. 线上稳定性：错误处理与可观测性
5.1 常见错误与应对动作速查
下面这张表是我这几个月实际遇到过的错误分类和对应处理，按出现频率排序。
| 现象 | 常见原因 | 处理动作 |
|---|---|---|
| 429 类限流错误 | 请求数或 token 超限 | 降并发、加退避、错峰调度 |
| 超时无响应 | 长推理输出过多、服务波动 | 缩短max_tokens、设显式超时、降级到 Flash |
| 返回内容被截断 | max_tokens不足 | 检查finish_reason，提高上限或拆分任务 |
| JSON 解析失败 | 温度过高、提示词约束不足 | 降温、加 schema、加自修复重试 |
| 内容答非所问 | 上下文过长、指令冲突 | 裁剪历史、提示词去重、明确优先级 |
| 用量统计缺失 | 流式未开用量返回 | 开启include_usage |
| 首字延迟突然变大 | 输入过长导致预填充慢 | 压缩输入、拆分文档、启用缓存 |
这张表里我认为最容易被忽略的是“返回内容被截断”。因为很多 SDK 不会因为截断而报错，接口返回 200，你拿到一段看似正常但实际不完整的内容，直接入库就是脏数据。我现在的规范是：任何一次调用都必须检查finish_reason，只要不是正常结束，就走异常分支。
5.2 双版本降级链路的设计
这是我强烈建议每个接 V4 的团队都做的一件事。链路大致是这样：
正常情况下，路由判定 → Pro 或 Flash → 返回。当 Pro 调用失败或超时时，自动用 Flash 重试一次，并在响应里打上degraded=true标记。如果 Flash 也失败，返回兜底文案或走人工队列。
关键在于降级必须可见。我见过团队做了降级但没打点，结果某天 Pro 侧一直超时，全部流量悄悄走了 Flash，业务方还在纳闷“最近效果怎么变差了”，查了两天才找到原因。
降级阈值也要设，比如“过去 5 分钟内 Pro 失败率超过 20% 就熔断 5 分钟”，避免持续把请求打到已经出问题的链路上。熔断恢复要渐进，先放 10% 流量试探，正常了再全量，不要一下子全放开。
5.3 必须打的几个观测指标
没有观测就没有优化。我上线时最少会打这几类点：
第一类是延迟分位数，不要只看平均值。P50 告诉你常态，P99 告诉你最差体验，两个都要看。Pro 版的 P99 往往比 P50 高一个数量级，只看平均会严重低估问题。
第二类是token 用量分布，输入、输出分开统计，并且看分位数。这直接对应成本。
第三类是任务成功率，包括接口成功率和业务成功率。接口 200 但内容不合格，属于业务失败，这类必须单独统计。
第四类是路由分布，Flash 和 Pro 的调用占比随时间的变化。如果某天 Pro 占比突然从 10% 跳到 40%，要么是业务变了，要么是路由规则出了 bug。
第五类是降级次数，这个指标异常往往是最早的故障信号。
这些指标我一般用一个简单的看板承载，不追求花哨，关键是每天有人看。
6. 实操避坑清单与个人心得
6.1 提示词必须按版本分别调
这是我最想强调的一条。V4 的 Flash 和 Pro 虽然同代，但在指令服从度、输出风格上是有差异的。同一套提示词，可能在 Flash 上稳定输出 JSON，在 Pro 上却喜欢先分析两句再给结论——因为 Pro 的推理倾向更强。
我的做法是维护两套提示词模板，共用主体，但针对版本做微调。比如给 Pro 的模板里额外加一句“先完成分析，最终只输出 JSON 结果，不要输出分析过程”。这句话在 Flash 上不需要，加了反而会干扰它。
维护两套模板的代价是版本管理变复杂，所以要有一套提示词的回归测试。我用的方法是准备 30 条固定样本，每次修改提示词就跑一遍，记录准确率和格式成功率，低于阈值就不许上线。这套流程听起来笨，但它救过我两次。
6.2 关于评测集的真心话
用公开榜单选模型是最省事也最容易翻车的做法。榜单任务是标准化的，你业务的输入分布跟它差得远。我见过一个团队因为某模型在公开评测上高两分就全量切换，结果业务指标掉了五个点，因为他们业务里大量是带错别字的短文本，而榜单上没有这种噪声。
正确的做法是建自己的小评测集，50 到 200 条就够，关键是覆盖你的真实分布，包括那些“脏”样本。标注不需要很精细，只要有个相对正确的答案就行。每次模型升级、提示词修改、参数调整，都跑一遍。这套东西建起来花不了两天，但长期收益巨大。
评测维度我一般看四个：准确率、格式合格率、平均延迟、平均 token 消耗。前两个看质量，后两个看成本，四个一起看才能做出正确的取舍。经常出现的情况是：准确率涨了 0.5 个点，但 token 消耗涨了 40%，这种就不划算。
6.3 灰度上线不能省
任何模型版本切换、提示词大改、路由策略调整，都必须灰度。我的标准流程是新旧并行，先放 5% 流量，观察 24 小时，看错误率、延迟、成本三条线是否平稳，再放到 30%，最后全量。整个过程快的话三天，慢的话一周。
灰度期间要做双跑对比，也就是同一批请求同时打给新旧两套配置，离线比对结果差异。这个做法会多花一倍的调用成本，但比线上出事故便宜太多了。我在一次版本切换里靠双跑发现了新版本在处理某个特定格式的日期时会静默返回错误格式，如果直接上线，这批数据会全部写错。
6.4 一些零散但管用的细节
system提示词尽量放在消息列表最前面，别混在user消息里，这对缓存命中率影响很大。
不要在提示词里写“请尽可能准确”，这种话没有约束力，只会浪费 token。要写就写具体的：“如果信息不足，输出{"status": "insufficient"}，不要猜测”。
处理长文档时，先做一次轻量的结构识别（用 Flash），把文档切成有意义的段落，再针对性地把相关段落喂给 Pro。这比把整篇文档一股脑塞进去，成本和效果都好得多。
上线初期把max_tokens设得保守一点，观察一周的实际输出长度分布，再按 P95 往上调。反过来做，先设大再往下压，很容易在前期产生不必要的成本。
最后，给所有 Key 设置用量告警。我自己设的是日用量超过预算 70% 就告警，超过 100% 自动降级到 Flash。这个机制在一次代码 bug 导致无限重试的事件里救过我，否则一晚上的循环调用能把一个月的预算烧光。
这些东西没有一条是高深的技术，但每一条都是踩过之后才记住的。V4 这代产品整体是往“让业务方自己掌控成本和质量”的方向走的，Flash 与 Pro 的分层给了很大的调优空间，用好这套分层，比追着榜单换模型实在得多。
