LLM API接入避坑指南：从调通到稳定部署的实战经验

兄弟们，最近在落地LLM API接入，踩了不少坑，分享点干货，直接上代码级别的经验。

**1. 基础调通：别再用requests裸调了** 🚀  
官方SDK虽然文档拉胯，但比手写requests省心太多。重点看超时设置和重试机制，默认超时往往只有10秒，大模型推理经常超时，设到60秒起步。另外，建议用指数退避+随机抖动做重试，别一失败就狂刷，容易被封IP。

**2. 并发与限流：别以为一个API Key就能疯狂压** 💥  
大部分API都按token限流，不是按请求数。实测OpenAI的TPM限制比RPM更难把控。建议自己加个本地令牌桶，根据模型延迟动态调整并发数。如果接的是私有化部署，记得用连接池复用，别每次请求都新建TCP连接。

**3. 生产化落地：错误处理要细化** 🔧  
别只catch HTTPError！实际生产中会遇到：模型过载（429）、上下文超长（400）、内容审核拒绝（403）等。建议按错误码分流，比如429走退避重试，403直接提示用户修改输入，避免无效开销。

**4. 成本监控：token数比响应时间更关键** 💸  
搭建个简易日志系统，记录每次请求的prompt/completion token数。用OpenAI的话，注意system prompt也会计费，别把大段指令塞进去。建议把固定模板的token预热缓存，能省不少钱。

**最后问个问题：各位在生产环境中，遇到过哪些因为API不稳定导致的神坑？比如模型突然返回空字符串或乱码，你们是怎么兜底的？** 😅

令牌桶那块确实说到点上了，我试过用redis+lua搞分布式限流，比本地令牌桶更稳，多个实例也不会撞车 🎯 另外你们API key轮换策略是咋做的？我碰到过单key并发太高直接被限流。

Redis+Lua分布式限流这个思路我记下了👍 单key限流我踩过坑，后来用多个key做round-robin轮换，配合本地缓存减少请求，总算稳住了。你们key池一般维护多少个？

@楼上 轮换key这招确实稳，我一般维护20个key池，配合本地缓存做二级兜底。但要注意key过期时间别设太短，否则轮换时容易撞空窗期😅

我也有类似经历，当时的情况是刚开始也遇到很多困惑，后来我发现实践比理论更重要。

这个关于API接入的分享很有价值，特别是提到的实践比理论更重要，我实际部署时也遇到过类似情况。

关于LLM API接入避坑指南：从我补充一点：可以延伸到更广泛的场景，可能对你有帮助。