企业官网建设流程全解析

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 一张能直接抄的打分表

纯靠嘴说容易飘,我更习惯把决策落到打分表上。下面这张表是我现在给新项目做选型时的固定动作,各项权重根据业务调整,总分高者胜:

用法很直接:每一行给两档各打 1 到 5 分,乘权重累加。我不追求这个分数有多"科学",它的价值在于逼你把模糊的直觉写成可讨论的数字。团队里两个人对同一个需求争得面红耳赤时,把表一填,分歧往往立刻收敛——因为分歧的真正来源通常是"延迟重要还是成本重要"这个前提没对齐,而不是模型本身。

3. API 接入实战:从密钥到第一条稳定请求

3.1 环境准备与密钥管理,别在这里栽跟头

现在绝大多数推理平台都提供兼容主流协议的统一接口,也就是说,你原来用的 SDK 大概率只需要改base_url和model两个字段就能跑。这对迁移极其友好,但也埋了一个雷:很多人直接把示例代码里的 Key 硬编码进脚本,提交到了代码仓库。

我的固定做法分三步。第一步,密钥只走环境变量,本地用.env文件并立刻加进.gitignore;第二步,生产和测试用两把不同的 Key,生产 Key 设配额告警;第三步,所有请求走一个统一封装的客户端,不要散落在各处。第三步的意义在于,当你要加日志、加重试、切换模型名时,只需要改一个文件。我见过一个项目里二十几个文件各自import openai各自建 client,后来要统一改超时时间,改了两天。

# .env 文件,记得加进 .gitignore INFER_BASE_URL=https://api.example-inference.com/v1 INFER_API_KEY=sk-xxxxxxxxxxxxxxxx INFER_MODEL_FLASH=v4-flash INFER_MODEL_PRO=v4-pro

注意：Key 一旦被提交到公开仓库,光删除文件是不够的,提交历史里还在。正确做法是立刻去控制台吊销这把 Key 重新签发。别心疼那几秒钟。

3.2 最小可运行请求,把每个参数讲清楚

先从非流式请求开始,因为它最容易调试。下面这段是最小可运行版本:

import os from openai import OpenAI from dotenv import load_dotenv load_dotenv() client = OpenAI( base_url=os.getenv("INFER_BASE_URL"), api_key=os.getenv("INFER_API_KEY"), timeout=60.0, # 总超时,见下方说明 max_retries=0, # 重试自己写,别用 SDK 默认的 ) resp = client.chat.completions.create( model=os.getenv("INFER_MODEL_FLASH"), messages=[ {"role": "system", "content": "你是一名严谨的技术文档编辑,只输出结果不解释过程。"}, {"role": "user", "content": "把下面这段描述压缩成一句话:……"}, ], temperature=0.3, max_tokens=512, ) 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( model=model, messages=[{"role": "user", "content": prompt}], stream=True, 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="", flush=True) 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( model=os.getenv("INFER_MODEL_PRO"), messages=[{"role": "user", "content": text}], tools=tools, tool_choice="auto", temperature=0.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, prefer="flash", max_attempts=3): 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( model=model, messages=messages, timeout=60 ) 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 错误码对照表

注意：排查时永远先看finish_reason。它是stop、length、content_filter还是tool_calls,直接决定了你该往哪个方向查。很多人跳过这一步,对着输出瞎猜半小时。

6.2 流式和结构化输出最容易翻车的两个地方

第一个是流式下的断线重连。用户在页面上等了十几秒,网络抖一下连接断了,你如果直接重发整个请求,用户会看到答案从头再来一遍,体验极差。正确做法是在服务端缓存已生成的片段,重连时先补发已有内容再续上。这个功能实现起来有点烦,但交互式产品的体验差距非常明显。

第二个是JSON 解析的容错。即使开了结构化输出,也偶尔会遇到前后带反引号、带一句"好的,以下是结果"的情况。我的做法是解析前先做一次清洗:去掉 markdown 代码块标记、截取第一个{到最后一个}之间的内容,再解析。解析失败不要直接抛错给用户,走一次带纠错提示的重试,成功率能到九成以上。

6.3 我个人最后留的三条经验

第一,任何模型名都不要硬编码在业务代码里。我第一次接这类服务时把模型名写在了二十几个地方,后来平台调整命名,我改了一下午。现在我全部走配置中心,切换档位只改一个值,灰度也方便——先给 5% 流量切过去,盯一天指标再全量。

第二,评测集要跟着业务一起长。我现在的习惯是每周从线上抽十条"用户点踩"的样本,补进评测集。半年下来这套集子已经覆盖了我业务里几乎所有难缠的输入,每次平台发新版本、每次我调提示词,跑一遍就知道有没有退化。这套东西的价值远超它占用的那点时间。

第三,别迷信"最强档一定更好"。我有一次把整个客服问答链路全切到 Pro,本以为能提升满意度,结果用户反馈"回答太啰嗦,绕来绕去"。强模型倾向于把话说全,而客服场景要的是干脆利落。后来我在提示词里加了"回答不超过两句"的硬约束,又把大部分流量切回 Flash,满意度反而涨了。模型选型这事,最终还是要回到你的业务到底需要什么,而不是排行榜上谁排第一。