后端开发一枚，最近给公司内部系统接入GPT API，本以为看看文档调几下就完事了，结果踩了一堆坑。记录一下，给后来人排排雷。
坑一：注册和绑卡
OpenAI的API和ChatGPT Plus是两套付费体系，这个很多人搞混。ChatGPT Plus的$20/月订阅不包含API额度，API要单独充值。
注册API账号后必须绑一张信用卡才能使用付费模型。国内的Visa/Mastercard有的能绑有的不行，我试了两张卡一张成功一张失败，具体规律没摸清楚。绑完卡之后建议第一件事就是去Settings里设置Usage limits，设个monthly budget上限，不然万一代码写了个死循环调API，账单能让你哭出来。
坑二：API key管理
key生成后只显示一次，没保存就只能重新生成。建议直接存到环境变量里，千万别硬编码到代码里——我见过同事把key提交到GitHub公开仓库的，OpenAI几分钟就检测到然后把key废了，还好没产生费用。
另外可以给不同项目创建不同的key，方便追踪各个项目的用量和费用。
坑三：Rate Limit
这个坑最深。新账号的rate limit特别低，刚开始的tier大概是每分钟3个请求（RPM）和每分钟几千个token的限制。如果你的应用有并发需求，基本上一上来就会被限流。
提升rate limit需要充值和使用，OpenAI会根据你的消费记录自动升级tier。从Tier 1到Tier 5，限制逐步放宽。但这个过程没办法加速，急也没用。
我的解决方案是在应用层做了请求队列和重试机制，遇到429错误就指数退避重试。这块逻辑不复杂但必须做，不然用户体验会很差。
坑四：Token计费
GPT API是按token计费的，input和output分别计价。gpt-4o大概是$2.5/1M input tokens、$10/1M output tokens。听起来不贵，但坑在哪呢——system prompt也算input token。
我最开始写了一个很长的system prompt，大概2000多个token，每次请求都带着。一天跑了几千次，光system prompt就烧了不少钱。后来优化了prompt长度，砍到了500token以内，费用直接降了一大半。
还有一个点：返回JSON格式的数据时token消耗特别大，因为JSON的大括号、引号、key名这些都占token。如果对格式要求不严格，纯文本返回再自己解析能省不少。
坑五：模型选择
现在OpenAI的模型有好几个：
- gpt-4o：主力模型，性价比最高，多模态支持，大部分场景用这个
- gpt-4-turbo：老一代的4系列，已经不太推荐了
- gpt-3.5-turbo：便宜但能力差不少，简单任务可以用
- gpt-4o-mini：轻量版，便宜且快，适合对质量要求不高的场景
我最后的方案是根据任务复杂度动态选模型：简单的意图识别和分类用gpt-4o-mini，复杂的文本生成和分析用gpt-4o。这样平均成本降了大概40%。
总结
GPT API本身不难用，但周边的这些坑不踩一遍真的不知道。最大的建议就是：先设好费用上限，做好限流重试，优化prompt长度。这三件事做好，基本就不会有太大问题了。
3 个赞
再补一个大坑：计费的隐藏消耗。
楼主提到了system prompt占token的问题，我再展开说说。除了system prompt，对话历史也是每次请求都会重新发送的。也就是说如果你做的是多轮对话，第10轮的请求会把前9轮的所有内容都当作input发过去，input token是指数级增长的。
我之前做一个客服bot，用户聊着聊着一次请求就好几万token，一看账单人傻了。后来做了两个优化：一是对话超过一定轮数就做摘要压缩，把之前的内容总结成几百token的摘要；二是设了max_tokens限制输出长度，避免模型在不必要的地方长篇大论。
还有一点容易忽略的——函数调用（function calling）的定义也算input token。如果你定义了很多工具函数，每次请求都会带着这些函数的schema，这个开销积少成多很可观。建议只传当前场景需要的函数，别把所有函数一股脑全丢进去。
1 个赞
绑卡那些问题我直接绕过去了——用Azure OpenAI Service。公司本身有Azure订阅，走企业渠道申请GPT API，不用绑个人信用卡，rate limit也比直连OpenAI高，而且国内访问速度快不少。唯一的缺点是新模型上线比OpenAI直连慢一两周，但对生产环境来说稳定性更重要。如果是公司项目的话真的推荐走Azure这条路。
1 个赞
自己封装SDK踩过的坑也来分享下。
最开始我直接用官方的 openai Python包，基本功能没问题但有几个需要自己处理的点：
重试逻辑： 官方SDK有内置的retry机制但不够灵活。我自己封装了一层，区分了不同的错误码：429（限流）用指数退避重试，500/502/503（服务端错误）最多重试3次，400（参数错误）直接报错不重试。这个很重要，不然容易在一个失败的请求上浪费大量时间和token。
超时设置： 默认的超时时间对长输出来说可能不够。如果让模型生成一篇长文章，streaming模式下第一个token可能要等十几秒，不设合适的超时会误判为失败。我设了connect timeout 10s、read timeout 120s。
流式输出处理： streaming返回的是SSE格式的chunk，需要自己拼接。注意最后一个chunk的finish_reason字段，可能是"stop"（正常结束）、“length”（达到max_tokens）或"content_filter"（内容被过滤），不同的原因需要不同的处理逻辑。
日志和监控： 每个请求记录model、token用量、响应时间、error信息，接到Grafana做看板。这个事前期觉得麻烦但后期排查问题和优化成本全靠它。
2 个赞
嫌麻烦的话可以考虑用国内的API中转服务，绑卡和网络问题一次解决。速度一般比直连快，而且支持支付宝充值。当然安全性就是另一回事了，生产环境不建议用，但个人开发和测试完全可以。
2 个赞
感谢各位补充！对话历史的token膨胀那个确实是大坑，我当初也栽过。另外刚发现一个新坑：gpt-4o的structured outputs模式虽然能保证返回合法JSON，但偶尔会在schema很复杂时变慢很多，大家注意下。
3 个赞
我第一次接GPT API的时候光鉴权就搞了两天，文档写得太绕了
同感，官方文档跟天书一样，最后还是看YouTube教程搞定的
我也踩了token计费的坑，输入输出价格不一样这件事文档藏得太深了
我第一次接GPT API的时候光鉴权就搞了两天，文档写得太绕了
Azure OpenAI这个方案确实绕过了绑卡麻烦，企业账号申请快
我也踩了token计费的坑，输入输出价格不一样这件事文档藏得太深了
GPT API鉴权那块一开始确实绕，文档组织得乱，搞懂了就没问题
我接GPT API的时候key忘了加Bearer前缀，排了半天才发现
对，而且不同模型的token上限差很远，gpt-4o和mini差了快十倍
我也踩了好久的坑，key格式总搞错，后来才发现是环境变量没生效
同感，官方文档跟天书一样，最后还是看YouTube教程搞定的