★ FEATURED ARTICLE 1. 先把两档模型这件事想明白1.1 一个上线公告背后的三个工程决策国内某推理云平台上线了新一代大模型的两个版本一个叫Flash一个叫Pro。公告本身没什么好看的真正值得琢磨的是它给工程团队扔出来的三个问题同一个系列为什么要分两档两档之间的能力差距到底值不值那个价差以及最现实的一个——我的业务代码里到底该写死哪个模型名。初学者看到这种公告容易直接滑过去觉得反正调 API 都是那一行改个 model 参数而已。但只要你在生产环境里跑过大模型请求就知道这三个问题一个比一个要命。模型名写死意味着后续所有优化都得改代码发版选错档位意味着要么白烧钱要么线上回答质量塌方。这篇东西我不打算复述官方文档。我想聊的是一个真正要把Flash 与 Pro接进业务的人脑子里应该建立怎样的判断框架以及API 接入过程里那些文档不会写、但会让你在凌晨两点被叫起来的问题。文中我用平台代指这家推理云服务商用V4代指这个模型系列用v4-flash、v4-pro作为示意模型名实际调用时以平台控制台里的字段为准。这样写不影响你照着做,反而避免了你复制粘贴时把人家的示例 Key 也一起搬走。适合谁看:手里有一个已经跑起来的 LLM 应用、正在纠结要不要上新一代模型的人;或者正准备从零接一家推理平台、想少走点弯路的开发者。纯小白也能看,因为我会把每个参数为什么这么设讲清楚,不假设你之前调过别家的接口。1.2 同一系列分两档,本质是在卖确定性很多人的第一反应是:Pro 就是 Flash 的加强版,参数更多、更聪明。这个理解不算错,但它解释不了一件事——如果只是能力更强,为什么不直接叫标准版和旗舰版,非要用 Flash 这个词?Flash 这个词的指向非常明确:速度、响应快、便宜、适合高频调用。也就是说,平台卖的不是能力上限,而是单位时间内的确定产出。我自己的理解是,同一系列拆成两档,是在切两类完全不同的负载曲线。一类是交互式高并发:用户点一下按钮就得在 1 秒内看到第一个字,一天几十万次调用,单次成本敏感度极高,答案错一点点用户也不会立刻发现。另一类是低频高质量:一次调用要处理几千字的合同、一段复杂的代码、一份需要推理的报告,一天可能就几千次,但一次答错的代价远大于调用费本身。这两类负载放在同一个模型上,注定有一方是亏的。平台解法就是把它们拆开,让你按负载曲线买单,而不是按我是不是大客户买单。理解了这一层,选型就不再是哪个更好的问题,而是我这个场景的负载曲线长什么样的问题。这个问题一旦问对,答案通常非常明确,不需要纠结很久。1.3 我的默认策略:能 Flash 就 Flash,Pro 当兜底我踩过的最贵的一个坑,是早期做内容摘要服务时为了保险全线用了最强档。上线两个月账单比预算高了三倍多,而抽查了两百条输出,和 Flash 版本的差异小到编辑肉眼都分不出来。摘要这类任务本身有天花板——原文就那么多信息,再强的模型也变不出花来。从那以后我的默认策略就变了:先用 Flash 打底,用一套离线评测集证明它确实不行了,再针对那一小部分流量上 Pro。这个思路有一个前提,你必须有一套自己的评测集。别用平台给的公开跑分,那玩意儿和你的业务分布差得远。我的做法是从真实日志里抽 50 到 100 条输入,人工标注出及格线以上的答案,然后让两个档位各跑一遍,人工盲评打分。五十条样本,两个人一个下午就能评完,这个投入和线上踩坑的代价比,基本可以忽略。提示评测集一定要包含你业务里最脏的那批输入——空输入、超长输入、中英混杂、带特殊符号、带攻击性措辞的。干净样本测出来的差异,在生产环境里基本没有参考价值。2. 选型量化:把感觉换成数字2.1 单请求成本的计算模板价格表看一眼就完了,真正要算的是单请求成本,也就是一次完整业务调用花多少钱,它由输入 token、输出 token 和两者的单价共同决定。公式很简单:单请求成本 输入token数 × 输入单价 输出token数 × 输出单价这个公式谁都会写,难的是把两个 token 数估准。新手最常犯的错是只算用户输入,忘了系统提示词。假设你的系统提示词有 1200 token(带几个工具定义和输出格式约束,很容易到这个量级),用户问题平均 200 token,输出平均 400 token,那么单请求实际是 1400 输入加 400 输出。如果系统提示词占了一大半,那你优化成本的着力点根本不在模型选型上,而在提示词瘦身和前缀缓存上。这一点后面第 4、5 章会专门讲。还有一个更隐蔽的变量:很多模型在生成正式回答前会先输出一段推理过程,这部分同样计入输出 token。也就是说你在价格表里看到的输出单价,实际消耗可能比你预期的多出不少。我的建议是,接一家新平台的第一件事,就是把usage字段原样打到日志里,跑一百条真实请求,把输入输出 token 的实际分布画出来,再去核对成本。凭直觉估的数,通常偏差在 30% 以上。2.2 延迟要拆成三段看,不要看总数这个接口要 3 秒这种描述在生产环境里几乎毫无意义。延迟必须拆成三段:排队时间(请求到平台,等待资源调度)、首字延迟(从开始处理到吐出第一个 token)、生成速度(每秒输出多少 token)。三段加起来才是总时长,但它们的优化手段完全不同。排队时间你控制不了,只能靠错峰、限流、换区域来规避。首字延迟和提示词长度强相关,输入越长,首字越慢,所以系统提示词臃肿的团队首字延迟普遍难看。生成速度则主要取决于档位——这也是 Flash 存在的核心价值。一个 400 token 的回答,如果生成速度是 50 token/s,光生成就要 8 秒;如果是 150 token/s,不到 3 秒。对交互式场景来说,这个差距直接决定了用户是等下去还是关掉页面。所以选型时我会做一个很土的表格:把两档模型在你的典型输入长度下,分别测首字延迟 P50 和 P95、生成速度均值。P95 比均值重要得多,用户感知到的卡顿永远是那 5% 的长尾。2.3 一张能直接抄的打分表纯靠嘴说容易飘,我更习惯把决策落到打分表上。下面这张表是我现在给新项目做选型时的固定动作,各项权重根据业务调整,总分高者胜:评估维度权重判断依据倾向 Flash倾向 Pro任务复杂度30%是否需要多步推理、长链条逻辑分类、抽取、改写、摘要复杂推理、代码生成、方案评审延迟敏感度25%用户是否在同步等待同步等待、要求秒级首字异步任务、可接受数十秒调用量级20%日请求数与成本预算十万级以上万级以下上下文长度15%单次输入的 token 量短上下文为主经常超长文档容错空间10%答错一次的业务代价可重试、可人工兜底一次错就要写事故报告用法很直接:每一行给两档各打 1 到 5 分,乘权重累加。我不追求这个分数有多科学,它的价值在于逼你把模糊的直觉写成可讨论的数字。团队里两个人对同一个需求争得面红耳赤时,把表一填,分歧往往立刻收敛——因为分歧的真正来源通常是延迟重要还是成本重要这个前提没对齐,而不是模型本身。3. API 接入实战:从密钥到第一条稳定请求3.1 环境准备与密钥管理,别在这里栽跟头现在绝大多数推理平台都提供兼容主流协议的统一接口,也就是说,你原来用的 SDK 大概率只需要改base_url和model两个字段就能跑。这对迁移极其友好,但也埋了一个雷:很多人直接把示例代码里的 Key 硬编码进脚本,提交到了代码仓库。我的固定做法分三步。第一步,密钥只走环境变量,本地用.env文件并立刻加进.gitignore;第二步,生产和测试用两把不同的 Key,生产 Key 设配额告警;第三步,所有请求走一个统一封装的客户端,不要散落在各处。第三步的意义在于,当你要加日志、加重试、切换模型名时,只需要改一个文件。我见过一个项目里二十几个文件各自import openai各自建 client,后来要统一改超时时间,改了两天。# .env 文件,记得加进 .gitignore INFER_BASE_URLhttps://api.example-inference.com/v1 INFER_API_KEYsk-xxxxxxxxxxxxxxxx INFER_MODEL_FLASHv4-flash INFER_MODEL_PROv4-pro注意Key 一旦被提交到公开仓库,光删除文件是不够的,提交历史里还在。正确做法是立刻去控制台吊销这把 Key 重新签发。别心疼那几秒钟。3.2 最小可运行请求,把每个参数讲清楚先从非流式请求开始,因为它最容易调试。下面这段是最小可运行版本:import os from openai import OpenAI from dotenv import load_dotenv load_dotenv() client OpenAI( base_urlos.getenv(INFER_BASE_URL), api_keyos.getenv(INFER_API_KEY), timeout60.0, # 总超时,见下方说明 max_retries0, # 重试自己写,别用 SDK 默认的 ) resp client.chat.completions.create( modelos.getenv(INFER_MODEL_FLASH), messages[ {role: system, content: 你是一名严谨的技术文档编辑,只输出结果不解释过程。}, {role: user, content: 把下面这段描述压缩成一句话:……}, ], temperature0.3, max_tokens512, ) print(resp.choices[0].message.content) print(resp.usage) # 一定要打出来几个参数的取舍说清楚。temperature在抽取、分类、格式化这类任务上我给 0.1 到 0.3,因为我要的是稳定复现,同样的输入今天和明天应该给出同样的结构;创意类任务才往上调。max_tokens是硬上限,设太小会被截断成半句话,设太大在某些平台会预占资源影响排队,我的经验值是预期输出长度 × 1.5。timeout要按场景给,同步交互给 30 到 60 秒够了,长文档处理给 300 秒以上。max_retries设 0 是有意的——SDK 自带的重试不区分错误类型,遇到参数错误也重试,白白浪费时间还污染日志,重试逻辑自己写更可控,第 4 章我会给出写法。第一次跑通之后,别急着接业务。先拿这条脚本跑 20 条你业务里的真实输入,把usage和耗时全部打出来。这一步能提前暴露超长输入、编码异常、内容被拦截等一堆问题,比上线后才发现划算太多。3.3 流式输出,90% 的 bug 都出在拼包上交互式场景必须上流式。流式的坑集中在两处:一是首字延迟的测量方式,二是 SSE 数据包的拼接。先说第一处。很多人测首字延迟是掐表算请求发出到控制台打印第一个字,如果你中间经过了网关、日志收集、前端渲染,这个数字是不可信的。正确做法是在服务端收到第一个 chunk 时就打时间戳,和请求发出时间做差,前端渲染耗时单独统计。第二处更凶险。流式返回的是一行行data: {...}的文本片段,一个 chunk 可能只包含半个 JSON,直接json.loads会抛异常。你必须维护一个缓冲区,按换行切分,把不完整的尾巴留在缓冲区里等下一包:import json, time def stream_answer(prompt: str, model: str): t0 time.time() first_token_at None buf, out , [] stream client.chat.completions.create( modelmodel, messages[{role: user, content: prompt}], streamTrue, stream_options{include_usage: True}, # 流式也要拿到 usage ) for chunk in stream: if chunk.usage: # 最后一个包带用量 print(usage:, chunk.usage) if not chunk.choices: continue delta chunk.choices[0].delta text getattr(delta, content, None) if text: if first_token_at is None: first_token_at time.time() - t0 out.append(text) print(text, end, flushTrue) print(f\n首字延迟: {first_token_at:.2f}s, 总耗时: {time.time() - t0:.2f}s) return .join(out)注意我加了stream_options里的include_usage。默认情况下流式请求的最后一个包才带 token 用量,很多平台需要显式开启,不开启你就永远拿不到准确的计费数据,只能靠字符数估算,误差能到 20% 以上。这是个非常容易忽略、但影响成本核算精度的细节。还有一种情况要处理:如果这个系列模型会输出推理过程,你的 delta 里可能同时有思考内容和正式回答两个字段。渲染时要把思考内容单独处理(比如做成折叠区),千万别一股脑拼进正文,否则用户看到的答案前面会挂一大段自言自语。3.4 结构化输出和工具调用,把不确定性关进笼子里只要你的下游要解析模型输出,就一定要用结构化输出,别指望正则从自然语言里抽取。两种做法:一是response_format指定 JSON 模式,二是我更推荐的工具调用(函数调用)。前者的坑在于,开启 JSON 模式后,提示词里必须明确出现JSON字样,并且最好给一个字段说明,否则模型可能给你一个空对象;后者更稳,因为参数结构是被 schema 约束死的。但工具调用有一个反直觉的性能特征:工具定义本身也占输入 token,而且工具越多,首字延迟越高。我曾经在一个请求里塞了十二个工具定义,光定义就三千多 token,首字延迟直接翻倍。优化办法是把工具按场景拆组,每轮只暴露当前可能用到的三到五个。这需要一点业务侧的设计,但收益很直接。tools [{ type: function, function: { name: extract_invoice, description: 从文本中抽取发票关键字段, parameters: { type: object, properties: { amount: {type: number, description: 金额,单位元}, date: {type: string, description: 开票日期,YYYY-MM-DD}, items: {type: array, items: {type: string}}, }, required: [amount, date], }, }, }] resp client.chat.completions.create( modelos.getenv(INFER_MODEL_PRO), messages[{role: user, content: text}], toolstools, tool_choiceauto, temperature0.1, )拿到工具调用结果后,一定要自己再做一层校验:金额是不是负数、日期能不能被解析、必填字段是不是真的都有。模型很擅长看起来很对,字段名对、类型对、值离谱,这种事我见得太多。校验失败的请求降级到 Pro 重跑一次,命中率能提升不少。4. 生产化:路由、降级、缓存三件套4.1 分层路由,让便宜的那档吃掉大部分流量路由的核心思想是先用最便宜的手段判断难度,再决定用哪档模型。我在实际项目里常用三级判断:第一级是规则,比如输入长度小于 500 字且属于已定义的简单意图,直接走 Flash;第二级是分类器,用一个极小的模型或者关键词规则把请求打成简单/复杂;第三级才是兜底,分不清的一律走 Flash,靠后置的质量检测把它捞回来。这套设计的关键在第三级——不要试图在入口处就判断准确。入口处信息最少,判断最容易错。我宁愿让 Flash 先跑,然后对输出做质量检测(比如是否为空、是否符合 schema、是否触发了敏感规则、置信度是否过低),不合格的再升级到 Pro 重跑。这样做的成本结构非常漂亮:假设 85% 的请求 Flash 就能搞定,15% 升级,综合成本比全线用 Pro 低了不是一点半点,而用户感知到的质量几乎没差别,因为差的那部分被捞回来了。有一个细节要注意:升级重跑要带上第一次失败的原因作为额外上下文,比如上一次输出未通过 JSON 校验,请严格输出合法 JSON。这个小小的提示能让二次成功率提升非常明显。4.2 降级链和重试,要区分能重试和不能重试429(限流)、500、503、超时,这些是能重试的;400(参数错)、401(认证失败)、内容被拦截,重试一万次也是同样的结果,只会浪费配额。所以重试逻辑必须按状态码分支:import random, time RETRYABLE {429, 500, 502, 503, 504} def call_with_fallback(messages, preferflash, max_attempts3): chain [v4-flash, v4-pro] if prefer flash else [v4-pro] last_err None for model in chain: for attempt in range(max_attempts): try: return client.chat.completions.create( modelmodel, messagesmessages, timeout60 ) except Exception as e: code getattr(e, status_code, None) last_err e if code not in RETRYABLE: raise # 不可重试,直接上抛 # 指数退避 抖动,避免重试风暴 sleep min(2 ** attempt random.random(), 8) time.sleep(sleep) raise last_err退避里的随机抖动(也就是那个random.random())不是可选项。没有抖动,所有失败请求会在同一时刻齐刷刷重试,本来是轻微限流,瞬间变成雪崩。这个技巧在分布式系统里是老生常谈,但在调大模型接口时经常被忘掉,因为大家潜意识里觉得这就是个 HTTP 请求。降级链的顺序也要想清楚。Flash 挂了降级到 Pro,成本会飙升,所以必须配一个熔断:如果一分钟内降级比例超过阈值,触发告警并把流量切回 Flash 或者返回兜底文案,而不是无限降级烧钱。4.3 前缀缓存是白捡的钱,但条件很苛刻提示词前缀缓存这个东西,用好了能把系统提示词那部分成本砍掉一大半,用不好就完全命中不了,你还以为平台在骗人。命中条件通常非常严格:前缀必须从第一个 token 开始完全一致,中间差一个空格、差一个时间戳、差一句当前用户是 VIP,整个缓存就失效了。我见过最典型的反例是把当前时间、用户 ID、随机数拼在系统提示词开头。这一改,缓存命中率直接从 80% 掉到 0,而且因为没人监控这个指标,烧了两个月才发现。正确做法是把固定不变的部分放最前面(角色定义、输出格式、工具说明),把每次都变的部分放到最后(用户输入、时间戳、上下文片段)。顺序一动,效果天差地别。验证方法也简单:连续发两次一模一样的请求,对比返回的usage里缓存命中相关的字段(不同平台字段名不一样,查文档确认),第二次的缓存命中 token 数应该明显大于 0。如果还是 0,回头检查你的提示词里是不是藏了动态内容。5. 成本压降与性能调优的实操记录5.1 提示词瘦身,往往比换模型省得多前面算过,系统提示词 1200 token、用户输入 200 token 的场景下,输入成本的大头在提示词。这时候你把模型从 Pro 换成 Flash,省的只是单价差;而把提示词从 1200 压到 400,省的是绝对量。两者叠加才是正确姿势。提示词瘦身我一般按这个顺序做。先删掉所有请你务必非常重要一定要这类不改变行为的强调词,它们只增加 token 不增加约束力。再把冗长的自然语言规则改写成短句或列表,同样的约束用列表表达通常能省三成。然后把示例(few-shot)从五个减到两个,只保留最能体现边界情况的那两个。最后检查有没有和历史对话一起无脑塞进去的内容——多轮对话场景里,把全部历史都带上是最常见的浪费,通常保留最近三轮加一个摘要就够了。实测下来,一套提示词从 1200 token 压到 400 token 左右是完全可行的,而且输出质量基本不变,有时候反而更好——因为规则少了,模型不容易自我矛盾。5.2 压测怎么做才不算白压压测大模型接口和压测普通 HTTP 接口不一样,不能只看 QPS。你要关注四个数:成功率、P95 延迟、限流触发率、单位时间成本。而且必须分档位分别压,因为两档的限流配额通常是独立计算的。我的做法是阶梯加压:从 1 并发开始,每分钟翻倍,一直加到限流开始频繁触发或者 P95 延迟明显劣化,那个点就是你的实际容量上限。压测时长至少 10 分钟,因为很多限流策略是按分钟窗口滚动的,压测 30 秒看不出真实情况。压测数据用真实日志里的样本,别用hello这种,长度分布完全不对。还有一个容易忽略的点:压测要跑完整链路,包括你的重试、降级、日志。我在一次压测里发现,加了详细日志之后 P95 延迟涨了 40%,原因是日志写磁盘同步阻塞了主线程。这种问题不压测根本发现不了。5.3 需要盯住的几个指标上线之后,监控面板上我固定放这么几个东西:每档模型的调用量占比、降级率、平均输入输出 token、缓存命中率、P95 首字延迟、错误码分布。这几个指标基本能覆盖 90% 的线上问题。其中最灵敏的是降级率。它一旦抬头,要么是 Flash 那边的质量撑不住了(说明你的业务分布变了),要么是限流了(说明流量涨了)。不管哪种,都值得看一眼。其次是平均输入 token,它突然上涨通常意味着有人往提示词里加了东西,或者多轮对话的历史没做截断——这两个都是成本失控的前兆。6. 常见问题速查与踩坑清单6.1 错误码对照表现象最可能的原因处理方式401 UnauthorizedKey 错误、过期、或环境变量没加载打印 Key 前 8 位核对,确认.env被读取404 model not found模型名写错,或该档位未开通去控制台复制准确模型名,注意大小写和连字符429 Too Many Requests触发 RPM 或 TPM 限制加指数退避加抖动,同时申请提额400 参数错误max_tokens超上限、messages 格式错、空内容逐字段打印请求体核对400 内容相关拦截输入或输出触发安全策略记录原始输入,做前置过滤,不要重试返回内容被截断命中max_tokens上限检查finish_reason是否为 length流式输出中断网络抖动或服务端超时客户端加读超时,支持断点续传式重发输出为空字符串JSON 模式但提示词未提 JSON、或触发了过滤检查提示词与finish_reason注意排查时永远先看finish_reason。它是stop、length、content_filter还是tool_calls,直接决定了你该往哪个方向查。很多人跳过这一步,对着输出瞎猜半小时。6.2 流式和结构化输出最容易翻车的两个地方第一个是流式下的断线重连。用户在页面上等了十几秒,网络抖一下连接断了,你如果直接重发整个请求,用户会看到答案从头再来一遍,体验极差。正确做法是在服务端缓存已生成的片段,重连时先补发已有内容再续上。这个功能实现起来有点烦,但交互式产品的体验差距非常明显。第二个是JSON 解析的容错。即使开了结构化输出,也偶尔会遇到前后带反引号、带一句好的,以下是结果的情况。我的做法是解析前先做一次清洗:去掉 markdown 代码块标记、截取第一个{到最后一个}之间的内容,再解析。解析失败不要直接抛错给用户,走一次带纠错提示的重试,成功率能到九成以上。6.3 我个人最后留的三条经验第一,任何模型名都不要硬编码在业务代码里。我第一次接这类服务时把模型名写在了二十几个地方,后来平台调整命名,我改了一下午。现在我全部走配置中心,切换档位只改一个值,灰度也方便——先给 5% 流量切过去,盯一天指标再全量。第二,评测集要跟着业务一起长。我现在的习惯是每周从线上抽十条用户点踩的样本,补进评测集。半年下来这套集子已经覆盖了我业务里几乎所有难缠的输入,每次平台发新版本、每次我调提示词,跑一遍就知道有没有退化。这套东西的价值远超它占用的那点时间。第三,别迷信最强档一定更好。我有一次把整个客服问答链路全切到 Pro,本以为能提升满意度,结果用户反馈回答太啰嗦,绕来绕去。强模型倾向于把话说全,而客服场景要的是干脆利落。后来我在提示词里加了回答不超过两句的硬约束,又把大部分流量切回 Flash,满意度反而涨了。模型选型这事,最终还是要回到你的业务到底需要什么,而不是排行榜上谁排第一。
阅读完成 · 觉得有帮助？
