手把手踩坑：LLM API接入的那些“潜规则” 🤖

兄弟们，最近在搞LLM API接入，踩了几天坑，总结几点干货，直接上菜。

**1. 别信文档，先试“流式”**  
很多API文档写得很美，但实际流式（streaming）返回的token可能乱序或截断。建议先搞个最简单的curl测试，确保能拿到完整响应。比如OpenAI的chat-completions，加`"stream": true`后，每段数据都要拼好再输出，否则前端直接崩。

**2. 速率限制（Rate Limit）是玄学**  
别只看官方说的“每分钟多少请求”，实际有突发限制和并行限制。我推荐用指数退避（exponential backoff）重试，配合一个轻量级队列（如asyncio.Queue），否则遇到429直接凉凉。自己写个装饰器，@retry(3, 2) 保命。

**3. 上下文管理：别贪便宜**  
有些人用小模型省钱，但上下文长度不够时，API会自动截断，导致回答驴唇不对马嘴。建议计算token时，留20% buffer。比如4K的模型，实际只用3.2K。用`tiktoken`库提前算好，别等报错了再debug。

**4. 模型版本别乱选**  
比如GPT-3.5-turbo和GPT-3.5-turbo-0613，行为完全不同。前者默认缓存，后者支持函数调用。搞混了，你调的函数参数会被无视。建议固定版本号，别用`latest`，除非你想每周重构一次代码。

**5. 错误处理：别只抓HTTP状态码**  
很多API返回200但JSON里藏error。比如“content filter”或“model overloaded”。写个统一解析函数，把`response.json()`里的`error.message`单独记录，方便排错。

最后抛个问题：你们在接入时，遇到过最坑的API行为是啥？来评论区battle下 🚀

兄弟总结到位！流式那点我深有体会，第一次接某厂API直接前端白屏，后来发现是没处理chunk乱序。速率限制更玄学，我试过用令牌桶配合本地队列才稳下来，你用的啥退避策略？👀