开篇：升级不是“一键替换”
从 GPT-3 到 GPT-4，OpenAI 把模型宽度（width）和深度（depth）同时放大，官方只说“更多参数”，但落到代码里，第一个体感就是token 上限从 4k 飙到 32k/128k，紧接着是价格 ×15和延迟 ×2。很多团队凌晨两点做完热升级，结果 8 点业务高峰直接 429 爆满，用户群里“机器人卡成 PPT”。
痛点总结一句话：
- 响应延迟翻倍，SLA 破功
- token 预算失控，账单惊吓
- 旧 prompt 在新模型里“水土不服”，效果反而掉点
下面这份笔记，记录了我们组从灰度到全量、从提示工程到微调踩过的坑，给你一条可复制的升级路线。
1. API 版本迁移：一张表看懂 Breaking Changes
| 维度 | GPT-3.5-turbo 0301 | GPT-4-turbo 2024-04-09 | 注意事项 | |---|---|---|---|---| | 最大上下文 | 4,096 tokens | 128,000 tokens | 计费分段变化，>8k 部分加价 | | 参数名 |engine|model| 旧参数直接 400 | | system 角色 | 被忽略 | 权重最高 | 必须重写 system prompt | | finish_reason |stop/length| 新增tool_calls| 下游 switch-case 要补分支 | | logit_bias 值域 | [-100,100] | [-100,100] | 相同，但 GPT-4 更敏感 | | 函数调用 | 不支持 | 并行 func | 需升级 openai>=1.0 |
一句话：openai-python 1.x 全面异步，0.x 代码直接报废。
2. 微调（Fine-tune）超参数速查表
微调 GPT-4 还没全量开放，但 GPT-3.5-turbo 微调已可用，经验值如下：
| 参数 | 推荐值 | 说明 |
|---|---|---|
| learning_rate | 1e-5 ~ 3e-5 | 太大容易灾难遗忘 |
| batch_size | 4 ~ 8 | 受限于 4k 长度，自动截断 |
| epochs | 2 ~ 3 | 早停法看验证 loss |
| prompt_loss_weight | 0.1 | 降低系统提示的权重，让模型更关注用户输入 |
| compute_classification_metrics | true | 做分类任务必开，方便挑 checkpoint |
小技巧：
- 数据量 < 300 条，用 1e-5 + 2 epoch 即可；
- 数据量 > 3k 条，可线性放大 lr 到 3e-5，epoch 保持 2 防止过拟合。
3. 可运行代码：带流式 + 重试 + 限速
安装最新版（写作时 1.30）
pip install -U "openai>=1.30"import openai, time, os, json from openai import OpenAI client = OpenAI(api_key=os.getenv("OPENAI_API_KEY")) def chat_stream(prompt: str, max_retry=3, temperature=0.3): """带重试、流式、自动降速的 GPT-4 调用""" for attempt in range(max_retry): try: stream = client.chat.completions.create( model="gpt-4-turbo", messages=[{"role": "user", "content": prompt}], temperature=temperature, stream=True, max_tokens千人千面=4096 ) for chunk in stream: delta = chunk.choices[0].delta.content if delta: yield delta return except openai.RateLimitError as e: wait = int(e.headers.get("x-ratelimit-reset-after", 2**attempt)) time.sleep(wait) except openai.APIError as e: if e.status >= 500: time.sleep(2**attempt) else: raise raise RuntimeError("重试耗尽") if __name__ == "__main__": for text in chat_stream("用三句话介绍量子计算"): print(text, end="", flush=True)要点
- 用
stream=True把首 token 时间（TTFT）从 2s 降到 300ms； - 捕获
RateLimitError并读 header 里的重置时间，比盲等靠谱； - 外层
for循环实现指数退避。
4. 性能优化：并发与长文本
4.1 并发限速器
OpenAI 对“ TPM（token per minute）+ RPM（request per minute）”双维度限速，粗暴多线程必 429。推荐asyncio+asyncio.Semaphore+aiohttp自建令牌桶，或者直接用官方库里的AsyncClient配合limiter=openai.RateLimiter(max_requests=200, max_tokens=40_000)。
4.2 长文本 Chunking 算法
128k 看似豪爽，但 >8k 加价 2×，而且延迟与长度线性相关。生产常用递归字符切分：
- 按
\n\n切段落 → 2. 按\n切行 → 3. 按句号为chunk_size=800兜底 - 相邻 chunk 重叠 10% 防止断句掉信息
代码片段：
def recursive_split(text: str, max_tokens=800, overlap=0.1): from tiktoken import encoding_for_model enc = encoding_for_model("gpt-4") tokens = enc.encode(text) step = int(max_tokens * (1 - overlap)) chunks = [tokens[i:i+max_tokens] for i in range(0, len(tokens), step)] return [enc.decode(c) for c in chunks]5. 生产环境检查清单
- [ ] 监控
- 延迟：P99 线 < 2s，P999 线 < 5s（Grafana + Prometheus histogram）
- token 用量：每 10s 采样，异常突增 > 30% 报警
- [ ] 内容安全
- 输入侧正则过滤身份证 / 手机号 / 银行卡（开源库
china_idi） - 输出侧调用 OpenAI Moderation API，category 分数 > 0.8 直接拦截
- 输入侧正则过滤身份证 / 手机号 / 银行卡（开源库
- [ ] 灾备
- 双模型路由：GPT-4 主 → GPT-3.5 降级，故障率 < 0.1%
- 异步写队列，失败请求自动落库，可重放
- [ ] 成本
- 预算熔断：日消耗 > 200 USD 自动切到 3.5；周维度看 ROI 效果
- [ ] 合规
- 日志脱敏：用
faker把 PII 替占位符，保留格式 - 数据驻留：选择
data_residency=eu避免跨境争议
- 日志脱敏：用
6. 留给你的两个开放问题
- 当 GPT-4 的 P99 延迟已逼近业务上限，你会优先降温度减少重试，还是直接降级到 3.5 做提示工程？效果与推理成本到底怎样平衡才优雅？
- 面对垂直领域知识，一边是“微调小模型”，一边是“大模型+外挂知识库”，你的选择标准是什么？数据量、更新频率、还是预算天花板？
7. 把耳朵、嘴巴和大脑串起来：豆包实时通话实验
写完上面这段“文字版”升级笔记，我顺手又跑了一遍从0打造个人豆包实时通话AI的实验。把 ASR→LLM→TTS 整条链路跑通后，发现语音场景对延迟更敏感：GPT-4 首 token 一旦过 600ms，就会被人耳明显感知“卡顿”。实验里的默认配置已经帮你把 chunk 大小、VAD（语音活动检测）和并发槽位调好，小白也能 30 分钟跑通；我改两行参数就把 3.5-turbo 模型替换进去，成本瞬间砍半，效果依旧在线。如果你也在给 AI 找“声音”，不妨去亲手试一试，看看到底是微调香，还是提示工程更省事。
