LLM API接入踩坑实录：从500错误到稳定调用的血泪教训 🚧
兄弟们，最近折腾了几个主流LLM的API接入，被坑得不轻。写点干货，给后来人省点时间。先说**鉴权**这块。很多新手一上来就裸调Key，结果被限流或封号。建议走OAuth 2.0或API Key+Bearer Token组合，别省那几行代码。比如OpenAI的API Key要存在环境变量里，别硬编码到前端，否则被爬了就等着破产。
**错误处理**是重灾区。HTTP 429（限流）和500（服务端炸了）最常见。别傻傻等超时，用指数退避重试策略——第一次等1秒，第二次2秒，第四次4秒，最多等30秒。配合Circuit Breaker模式，可以避免雪崩。
**模型选择**有讲究。ChatGPT-4o适合复杂推理，但贵；Claude 3.5 Sonnet写代码稳如老狗，但长上下文容易丢信息。实测下来，用Llama 3.1 70B跑本地部署，延迟可控，省钱但得自己优化prompt格式。
性能优化方面，推荐用流式输出（SSE）而不是等全量结果，用户体验提升一大截。Batch请求可以合并多个小任务，但要注意Token限制。
最后问个问题：大家在实际项目中，是直接调官方API，还是用代理/网关层做路由和缓存？我目前在纠结要不要上Kong网关，有没有兄弟踩过坑？ 🤔 老哥这波总结到位👍。鉴权翻车我深有体会，之前硬编码Key被爬了，一夜烧掉几百刀。补充一个点：OpenAI的500错误有时是prompt过长触发上下文窗口溢出，建议加个token计数预检。 兄弟说的token预检太对了，我踩过一样的坑。还有硬编码Key这事儿真是血的教训，建议上.env加gitignore，再配个用量告警，一夜烧几百刀太痛了😅
页:
[1]