企业官网建设流程全解析

前两天某开发者A同学跑来找我，满脸疑惑地甩过来一张账单：上个月AI接口调用次数只多了20%，账单却翻了两倍多。我看了下他代码库里的重试逻辑，三分钟就知道问题出在哪了——他写了一个while True循环，超时就重新请求，最多循环10次。账单翻倍不是调用量涨了，而是同一批请求被服务端反复处理、反复计费。

这个问题在圈子里太常见了，几乎每周都有人踩。很多人对AI接口容错有个根深蒂固的误解：超时等于失败，失败就该重试。实际上，对生成式AI接口来说，超时很可能只是网络层等不及了，服务端那边模型还在吭哧吭哧地生成token。网络超时和服务端成功处理，完全可以同时发生。"AI接口超时就重试，你可能多付了一次钱"，说的就是这个反直觉的细节。下面我从计费链路开始拆，把重试策略一步步讲透，后端、算法以及做AI应用集成的同学应该都用得上。

1. 先看计费链路：网络超时为什么不等于"没成功"

1.1 LLM接口计费和普通API计费的本质差异

传统HTTP API，比如查询订单、提交表单，服务端处理一般是毫秒到几百毫秒。请求到达服务端后快速处理完，响应很快回来。如果客户端在10秒内没收到响应，大概率服务端真的没处理成功，或者响应在传输途中丢了，后者很少见。所以"超时重试"在传统接口上虽然也有隐患，但整体风险可控。

大模型生成接口完全不同。一个中等复杂度的请求，模型生成几百到上千token，耗时通常是几秒到几十秒，遇到长文本、复杂推理甚至到几分钟。你客户端设置的超时阈值，比如10秒、30秒，很可能小于服务端真实处理时间。客户端等不及主动断开连接，但服务端那边的生成任务还在跑，最终照常写日志、照常计费。用点外卖类比就是：你下单后等了10分钟没动静，以为商家没接单，又下了一单，结果商家两单都做了，你付两次钱。

这个差异是理解整篇文章的钥匙：对LLM接口来说，客户端读超时通常只代表"我没等到响应"，不代表"服务端没干活"。

1.2 一个请求从发出到扣费经历了什么

一次完整的LLM接口调用，在客户端视角是这样的：

DNS解析 -> 建立TCP连接 -> TLS握手 -> 发送请求头和请求体 -> 穿过负载均衡 -> 服务端鉴权 -> 进入排队 -> 模型推理（毫秒到分钟级） -> 逐token生成 -> 网络返回 -> 客户端读完响应。

超时发生在不同阶段，后果天差地别：

• 连接阶段超时：TCP连接都没建立起来，请求大概率没到服务端，这种重试是安全的。
• 请求已发送、等待响应时超时：请求和数据已经完整到达服务端，很可能已经进入模型推理，这时候重试大概率重复计费。

计费的触发点也要说清楚：主流大模型API基本都是按实际生成的token数计费。只要进入推理阶段并产生了输出，就记一笔费用。即使客户端因为超时断开，已经生成的token也不会退还。很多平台甚至会把超时的请求算作"成功请求"记录在调用日志里，你登录服务商控制台能看到那次超时对应的完整usage数据，证明钱确实收了。

1.3 服务端有没有"去重"机制可依赖

做过支付系统的人会第一时间想到幂等键：是不是可以像支付接口一样，传一个idempotency_key，服务端检测到重复请求就返回上次的结果？现实是残酷的：目前绝大多数大模型API并不提供类似支付接口那种可靠的幂等机制。你传同一个请求ID进来，服务端不会自动识别"这跟上一次是同一个任务"然后返回缓存；它只会当成两个独立请求，跑两次推理，收两次钱。

个别平台会提供request_id去重、结果缓存或提示词缓存选项，但要么限制窗口很短，要么只对完全相同的prompt生效，不保证在所有场景下都生效。把业务稳定性建立在"平台可能会去重"这种假设上，风险太高。所以做工程架构时，默认假设应该是：任何一次已经发出去的请求，只要它到达了服务端，就要认为它会被计费。在这个假设下设计重试策略，才不会在账单上踩坑。

2. 常见重试姿势为什么在悄悄烧钱

2.1 无脑全重试：重复计费的最大来源

我在不少项目代码里见过这种写法：

while True: try: resp = requests.post(url, json=payload, timeout=30) return resp.json() except Exception: time.sleep(1) continue

这个循环看起来"完美容错"，但每次读超时都可能已经把同一个prompt送去推理了一轮。循环10次，最坏情况就是同一个需求被服务端处理10轮，账单直接乘以10。更糟糕的是它连4xx错误也会重试——请求参数有问题，重试一万次还是失败，但部分4xx错误（比如内容审核拦截、输入超长）依然会消耗token，照样扣钱。

重试代码写得越"健壮"越危险，因为它把"失败"和"该重试"混为一谈。失败只是结果，该不该重试要看失败发生在链路哪一段。无脑全重试等于完全不区分失败原因，把成本风险完全敞开。

2.2 SDK默认重试参数：你以为没写重试就没重试

很多人觉得自己代码里没有任何重试逻辑，怎么会重复调用。但实际情况是，不少主流AI服务商的官方Python SDK内部默认开启自动重试，遇到连接错误、429限流、部分5xx状态码时，会默认重试一到两次。

表面看代码人畜无害：

client = SomeLLMClient(api_key="sk-xxx") resp = client.chat.completions.create( model="your-model", messages=[{"role": "user", "content": "你好"}], )

实际上SDK底层已经按默认策略悄悄重试了。如果你不知道默认值、不懂如何关闭或调节，生产环境就会在不知不觉中多付钱。我见过一个批处理任务，业务代码只调了一次接口，但服务商账单里同一个请求出现了三次，就是因为SDK默认重试了两次。

建议：使用任何AI服务商的SDK之前，先花十分钟读一遍重试策略文档。在成本敏感的批处理场景里，很多人会显式把SDK的重试次数调成0，然后在业务层用自己设计的策略统一处理，这样每一轮重试都是可控、可观测的。

2.3 固定间隔重试与重试风暴

固定等1秒再重试，最大的问题不是成本本身，而是并发场景下的"羊群效应"。假设有100个任务在同一个时刻到达服务端，服务端负载过高，这批任务集体超时。如果大家都固定等1秒再重试，100个重试请求又会同时打过去，服务端被打得更慢，造成更大面积的超时，然后第二批100个任务再次同时重试。

这种重试风暴的可怕之处在于：服务端可能还没崩，账单已经先崩了。重复请求成倍增加，每一轮都可能是真实计费。正确做法是在重试等待时间中加入随机抖动（jitter），把同一时刻冲上去的重试请求随机摊开，让服务端有时间恢复。具体公式后面会给出。

2.4 重试后直接丢弃结果：三重计费

还有一个容易被忽略的坑：某些批处理代码里，重试成功拿到返回结果之后，没有保存结果也没有做业务落库，因为外层又抛了个异常导致整个任务重跑；或者任务队列开启了至少一次投递，消费者处理失败后，整批消息被重新消费。这种"应用层重试"叠加"接口层重试"，会让同一个请求被处理三轮以上，每一轮都付钱。

接口重试只是第一层，任务调度层的重试、业务层的补偿都可能造成重复调用。我建议在任务日志里记录同一个业务ID被调用的次数，全局统计一次，结果往往很吓人。成本治理必须从接口层往上看到业务层，漏掉任何一层都可能让优化白做。

3. 设计重试策略前必须分清的三种超时

3.1 超时的三个层次：连接、读取、等待

在HTTP客户端里，超时一般分两类：连接超时和读超时。有些SDK还会单独提供"总请求时间"或"写超时"参数。

连接超时指的是建立TCP连接的最长时间。如果连不上，说明请求还没发出去，服务端无从计费。这个值不用设太大，5到10秒足够，设大了只会拖慢故障感知。

读超时指的是发起请求后，等待响应数据的最大间隔。这个值对LLM调用至关重要。很多平台官方建议LLM接口的读超时至少设置到120秒以上，长文本、复杂推理场景给到300秒也不夸张。如果用的是流式接口，读超时的含义会变成"两个数据包之间的最大间隔"，只要持续有token返回就不会触发，因此可以适当调小。

很多团队习惯性地把timeout=30从普通接口复制到AI接口上，这是成本事故的源头之一。30秒对普通HTTP接口很宽裕，对大模型生成接口却常常不够。服务端还在正常生成，客户端却已经失去耐心断开连接，白白错过一次成功且已计费的调用。

3.2 可安全重试 vs 不可安全重试的判断矩阵

设计重试策略的核心，是建立一张"能否重试"的判断表。下面这张矩阵是我在实际项目里沉淀下来的，可以直接抄：

429限流通常发生在鉴权和排队阶段，还没进入模型推理，所以重试相对安全。服务端5xx错误要谨慎处理，保守做法是留足超时时间后最多重试一次，然后立刻进入补偿流程。读超时是最危险的，因为它是"客户端主动放弃等待"，而不是"服务端明确拒绝"，这时候服务端那边大概率已经在生成token了。

3.3 指数退避与抖动：公式与计算示例

确定"该重试"之后，下一个问题是"怎么等"。业界标准做法是指数退避加抖动：

import random import time def retry_wait(attempt: int, base: float = 1.0, max_wait: float = 30.0, jitter_max: float = 0.5) -> float: exp_backoff = min(max_wait, base * (2 ** attempt)) return exp_backoff + random.uniform(0, jitter_max)

设基础等待1秒，最大等待30秒，抖动上限0.5秒，重试次数从0开始：

• 第0次重试前等待：1 + 0到0.5之间的随机数，约1到1.5秒
• 第1次重试前等待：2 + 随机数，约2到2.5秒
• 第2次重试前等待：4 + 随机数，约4到4.5秒
• 第3次重试前等待：8 + 随机数，约8到8.5秒

最多重试3次，额外等待时间大约在7到8.5秒之间。这个量级对绝大多数瞬时故障已经足够，不会让用户等太久，也不会在同一时刻把大量重试请求集中打到服务端。抖动的作用是打散重试时间点，避免同一个批次的请求像阅兵一样齐刷刷地再次冲上去。

3.4 关键缓解手段：流式输出降低读超时误判

除了超时参数和重试策略，还有一个非常有效的手段：优先使用流式接口。

流式接口的优势在于，服务端一旦开始生成，就会立即返回第一个token，后续持续输出。读超时只作用于"等待下一个数据包"的间隔，而不是"等待完整响应"。模型正常生成时，token会持续不断回来，客户端不会误触发读超时。一旦真的触发读超时，往往说明连接已经中断，服务端也可能因为无法回写而终止任务，此时的计费通常只到中断点为止。

成本敏感的应用应该优先使用stream=True，既能大幅降低伪超时的概率，又能让用户看到打字机效果，体验也更好。缺点是代码稍微复杂一点，需要处理增量解析，但这点复杂度换来的成本确定性非常值。

4. 实操：从裸请求到带成本保护的重试封装

4.1 第一版裸请求：最简单但最危险

先看最常见的裸请求写法，很多脚本和原型代码都是这样起步的：

import requests resp = requests.post( "https://api.of-your-llm.example/v1/chat/completions", headers={"Authorization": "Bearer sk-xxx"}, json={ "model": "your-model", "messages": [{"role": "user", "content": "你好"}], "max_tokens": 512, }, timeout=30, )

这段代码的问题很明显：timeout=30对LLM生成来说太短了。生成512个token，很多模型需要30到60秒，30秒超时基本是把正常请求往外推。一旦读超时，用户大概率会手动再跑一次，或者加个重试循环，重复计费就这么来了。

4.2 第二版封装：按异常类型决定是否重试

我把裸请求升级成一个带保护的重试封装，核心原则是：连接超时重试，读超时宁可放弃也不重发，5xx谨慎处理，429按服务端建议等待：

import requests import time import random import logging logger = logging.getLogger(__name__) def call_llm(prompt: str, max_attempts: int = 3): url = "https://api.of-your-llm.example/v1/chat/completions" headers = {"Authorization": "Bearer sk-xxx"} payload = { "model": "your-model", "messages": [{"role": "user", "content": prompt}], "max_tokens": 512, "stream": False, } for attempt in range(max_attempts): try: resp = requests.post(url, json=payload, headers=headers, timeout=(10, 120)) resp.raise_for_status() return resp.json() except requests.exceptions.ConnectTimeout: # 连接阶段超时：请求大概率没到达服务端，可以安全重试 wait = min(30.0, 1.0 * (2 ** attempt)) + random.uniform(0, 0.5) logger.warning("connect timeout, attempt=%d, will retry in %.1fs", attempt, wait) time.sleep(wait) except requests.exceptions.ReadTimeout: # 读超时：请求可能已经在服务端计费，宁可不重试 logger.error("read timeout at attempt=%d, request may have been charged", attempt) raise except requests.exceptions.HTTPError as exc: status = exc.response.status_code if status == 429: retry_after = float(exc.response.headers.get("Retry-After", "1")) time.sleep(min(30, attempt + 1) + random.uniform(0, 0.5)) continue if status >= 500: # 服务端错误：最多重试一次，避免重复计费 if attempt >= 1: raise wait = min(30.0, 1.0 * (2 ** attempt)) + random.uniform(0, 0.5) logger.warning("http %d, attempt=%d, retry in %.1fs", status, attempt, wait) time.sleep(wait) continue raise raise RuntimeError("llm call failed after max attempts")

读超时直接抛异常，不让它进入重试循环，这是整个封装里最关键的决定。因为网络读超时发生时，客户端无法知道服务端是否已经完成计费，此时再发一个请求几乎必然重复计费。宁可让这一笔调用失败，进入补偿队列或人工排查，也不要拿真金白银去赌。

4.3 第三版：把成本记录织进调用函数

重试策略稳定之后，下一步是让每一次调用都留下成本痕迹。我在上面封装的基础上加了一圈成本记录逻辑：

def estimate_cost(prompt_tokens: int, completion_tokens: int) -> float: # 示例价格，按你实际合同价替换 input_price_per_1k = 0.5 output_price_per_1k = 1.5 return (prompt_tokens / 1000) * input_price_per_1k + (completion_tokens / 1000) * output_price_per_1k def call_llm_with_cost(prompt: str, task_id: str): result = call_llm(prompt) usage = result.get("usage", {}) prompt_tokens = usage.get("prompt_tokens", 0) completion_tokens = usage.get("completion_tokens", 0) total_tokens = usage.get("total_tokens", 0) request_id = result.get("id", "") cost_estimate = estimate_cost(prompt_tokens, completion_tokens) logger.info( "task_id=%s request_id=%s prompt_tokens=%d completion_tokens=%d total_tokens=%d cost=%.6f", task_id, request_id, prompt_tokens, completion_tokens, total_tokens, cost_estimate, ) return result

request_id和total_tokens是排除重复计费的关键字段。有了这两条日志，后面做成本聚合和异常排查就有了依据。

4.4 用日志验证"没有重复扣费"

封装上线后，怎么验证重试策略真的在省钱？方法是看日志里同一个业务任务对应的请求记录。正常情况下，一次业务任务只应该对应一次成功的LLM调用：

2025-06-01 10:00:01 INFO task_id=task_12345 attempt=0 connect timeout, will retry in 1.3s 2025-06-01 10:00:03 INFO task_id=task_12345 success request_id=req_abc123 total_tokens=856 cost=0.00082

这条日志说明第一次调用在连接阶段就失败了，没有到达服务端，重试之后才成功，只发生了一次计费。这是理想情况。

如果你看到这样的日志：

2025-06-01 10:00:01 INFO task_id=task_12345 success request_id=req_abc123 total_tokens=856 cost=0.00082 2025-06-01 10:00:02 INFO task_id=task_12345 success request_id=req_def456 total_tokens=901 cost=0.00091

同一个task_id下面出现了两个不同的request_id，说明同一个请求被执行了两次、计费了两次。这时候就要回头查调用链，看看是哪一层的重试逻辑在捣乱。

5. 成本侧防线：用量记录、聚合与告警

5.1 单次调用的成本计算

只统计调用次数是没有意义的。LLM接口的成本模型是：成本 = 输入token数 × 输入单价 + 输出token数 × 输出单价。prompt越长越贵，max_tokens设得越大，单次调用越贵。重试不会改变单次单价，但会把整个成本复制N份。

我在项目里把每次调用的usage字段落库，字段包括：任务ID、请求ID、模型名、输入token数、输出token数、总token数、估算成本、时间戳。这张表就是成本分析的地基。没有这张表，所有成本优化都是拍脑袋。

5.2 按任务维度聚合成本

有了明细表，问题就变成了简单的SQL聚合。我常用这一条找出"重复调用最多、烧钱最多"的任务：

SELECT task_id, COUNT(*) AS call_count, SUM(estimated_cost) AS total_cost FROM llm_call_logs GROUP BY task_id HAVING COUNT(*) > 1 ORDER BY total_cost DESC LIMIT 20;

call_count > 1基本意味着某个任务被重复执行了。按total_cost排序，可以快速定位最烧钱的问题任务。实际执行时经常会看到一些任务被调用了五六次，每次都成功、每次都在计费，日志里却没有明显异常——这类问题只有用成本聚合才能揪出来。

为了更直观，可以做成一张每日任务成本排行榜，表格结构类似：

5.3 告警策略与阈值设计

成本只有记录而没有告警，防线依然不完整。我建议设置三类告警：

• 单次调用成本异常：某次调用的输出token数超过该任务历史均值的N倍，触发提醒。很多重复走流程的请求，会因为某种原因生成超长内容，单次成本突然飙升。
• 日成本突增：当日总成本比过去7天日均值高出50%，立即告警。这类告警能抓住重试风暴、配置错误、循环调用这类问题。
• 同任务重复调用：同一task_id的request_id数量超过预期，比如批处理任务预期1次，实际出现3次，直接告警。这一步是重试策略失效的兜底。

告警渠道用即时通讯群机器人就行，成本数据接上群机器人之后，问题通常在几分钟内就会被发现，而不是等月底账单出来才追悔莫及。

5.4 把重试策略收拢成公共组件

在一个小团队里，如果每个人各写一套重试逻辑，成本治理就是一句空话。我的做法是把LLM调用封装成一个统一的公共库，重试策略、超时参数、成本日志全部集中在一处，通过配置控制：

# 公共配置，禁止业务代码绕过 LLM_CONFIG = { "connect_timeout": 10, "read_timeout": 120, "max_attempts": 3, "retry_base_wait": 1.0, "retry_max_wait": 30.0, "jitter_max": 0.5, }

团队接入时只允许调用公共函数，比如call_llm_with_cost，不允许在业务代码里手写requests.post裸调大模型接口。这样重试策略、成本记录、告警上报才能统一生效。你永远不知道某个成员在业务代码里写了一个什么样的重试循环，直到月底账单给你上一课。

我在实际项目里看到，把读超时从30秒调到120秒，同时去掉读超时后的自动重试，账单立刻回到正常水位。更意外的是，整体耗时反而降了——此前一次次无效重试不仅烧钱，还让用户等待时间成倍拉长。所以我一直建议团队：先调超时，再谈重试；先看日志，再调策略。成本问题本质上是数据问题，把每一次调用的usage、request_id和cost记下来，所有优化都会变得清晰可见。