个人小项目接入大模型接口后，我是怎么解决响应慢和网络偶发断联的

自己平时写过不少辅助小工具，最近给一个长文本润色和排版的脚本换上了大模型接口。以前用正则匹配处理，虽然快但效果死板；换成大模型之后，生成质量确实上了一个台阶，但在日常使用中也多了两个挺烦人的毛病：一是偶发网络抖动导致任务直接崩掉，二是长文本等返回太慢，终端前面像卡死了一样。

这套脚本平时跑在华为云的一台轻量云服务器上，偶尔本地电脑也会直接调。折腾了两个晚上，改了三处地方，记录一下个人的优化方案。

第一处是给请求加上了带退避的重试机制，但排除了业务性错误。
最早写调用逻辑就是最简单的一行requests.post。但在实际运行中，外部的大模型API经常会遇到各种不可控情况：比如网络抖动瞬间断连、服务提供方偶尔报个502/503，或者触发了接口的高峰期限流（429）。
如果直接裸奔调，脚本一报错整批长文本就废了。
我引入了tenacity库来做重试，但这里有个容易踩坑的细节：不能盲目重试所有异常。像401（鉴权失败）、400（参数写错或者Prompt超长）这种属于业务逻辑问题，重试一百次也是徒劳，反而白白耗费时间。
我把重试条件严格限定在网络超时（Timeout）、连接错误（ConnectionError）以及特定的服务端错误状态码上，并且用上了指数退避加随机抖动（Exponential Backoff with Jitter），比如第一次重试等1秒，第二次等2秒、4秒，避免网络刚恢复时连续重试把接口直接打爆。

第二处是把整包阻塞等待改成了流式传输加心跳判定。
长文本处理通常需要模型生成比较长的时间，以前不设stream参数，接口客户端就在那里死等。如果Prompt有上千字，等十多秒是常态。
死等不仅体验差，还有一个隐患：有些云网络环境里的网关或者中间代理，对长时间没有数据传输的TCP连接会有空闲超时切断机制。有时候模型那边还在吭哧吭哧算，这边的网络层却以为连接僵死了，直接报个Connection reset。
把请求参数加上stream=True后，接口只要开始吐字就会持续通过SSE推流过来。
在客户端接收时，我顺手做了一个轻量的交互：终端里实时打出一个跳动的字符或者进度点，同时在内存里按Chunk拼接内容。更重要的是，基于流式传输，只要一段时间（比如15秒）完全没有新的Token推过来，就可以明确判定为假死断连，及时触发主动重连，不用傻傻等满整个全局超时时间。

第三处是给长文本加了一层分段滑动窗口，避开大模型的速度衰减。
最开始图省事，把几千字甚至上万字直接整篇丢进Prompt里让它改。
实际测试发现，不管是哪家的大模型，当输入和输出长度双双变长时，Token的生成速度是明显变慢的，而且长文本在生成到后半段时，格式走样、漏改错改的概率直线上升。
后来我把输入端改成了按自然段切分，每次取两到三个段落作为一个小批次，前一个批次的结尾几句话作为上下文冗余带入下一段，分批次发给接口并发或串行处理。
虽然调用次数变多了，但因为每次都是短文本，模型的首字返回极快，生成速度保持在峰值，多段拼接起来的排版质量也比整篇硬塞稳定得多。

第四个小细节是把Prompt模板固化，开启接口方的Prompt Cache。
现在不少主流大模型服务都支持前缀缓存（Prompt Caching），如果你的系统提示词（System Prompt）和格式要求很长，只要这部分内容完全保持固定不变，后续请求就能命中服务端的缓存，不仅计费便宜不少，而且预处理（TTFT，即首字返回时间）能压缩一大半。
我之前喜欢在System Prompt里动态拼入当天的系统时间或者当前执行的文件名，导致每次请求的开头都在变，彻底废掉了服务端的缓存机制。
发现后我把动态变量全部下移到User Prompt的结尾，让System Prompt保持一字不差的静态模板，改完后第一波字出来的速度明显快了一截。

经过这几处改造后，这个脚本已经平稳用了快一个月。无论是丢几百字的随笔还是上万字的文档，跑起来很少再遇到中途断连的情况，即使偶尔遇到服务方抖动也能自动静默重试救回来。对于经常用大模型做个人批处理脚本的场景来说，流式保活加上精细化的重试策略，基本能解决绝大部分“稳定性”问题。