最近在做一个内部用的AI客服Agent,基于Llama 3微调了模型,本地跑通了LangChain + RAG的流程。但真要部署到公司服务器上就懵了——不知道用vLLM还是TGI?显存不够,想用量化又怕掉效果。还有,Agent要调用外部API,生产环境里异常处理和重试怎么设计?有没有大佬分享一下从Notebook到生产部署的完整链路踩坑经验?最好是低成本方案,公司预算有限。
想把LLM Agent 部署到生产环境,求大佬指点入门方案
全部回复
共 128 条vLLM配AWQ量化挺稳的,显存不够先上4bit,效果损失能接受。异常重试用tenacity加指数退避,别自己造轮子。
生产环境别折腾LangChain全家桶,vLLM+FastAPI自己封装更省心。量化推荐GPTQ,效果比AWQ稳。
说到vLLM和TGI,我建议你先试vLLM,吞吐量在内部客服这种高频短请求场景下会更稳,而且paged attention对显存利用友好很多。量化的话我个人觉得AWQ比GPTQ掉点少,Llama 3 8B用4bit跑客服意图识别和RAG检索,体感上差距不大,但你要是做复杂推理链,还是留点余量,至少上8bit。
显存不够还有个偏方,把embedding模型和LLM拆到两个服务,用轻量级bge-m3或者gte-small跑RAG,主模型只做生成,能省出1-2G。外部API调用这块,别看LangChain自带的重试,生产环境必须自己写状态机,区分瞬时错误(超时、429)和永久错误(鉴权失败、参数错误),前者用指数退避加抖动,后者直接熔断并记录到队列里人工兜底。
还有个坑你大概率会踩:LangChain的LCEL链在并发高时会有线程安全问题,建议你用异步接口或者把链改成无状态的,再套一层FastAPI。另外微调过的Llama 3千万别直接上FP16原权重,先用vLLM的continuous batching压测下你的平均延迟和并发上限,我见过不少项目死在“本地单测没问题,一上生产OOM”上。
预算有限的话,可以看看SGLang,最近调度优化做得很好,吞吐比TGI高20%左右,而且量化兼容性比vLLM好。最后提醒一句,异常日志一定要带request_id和trace_id,不然客服那边反馈问题时你根本没法定位是哪一步炸的。
vLLM和TGI选型其实不用太纠结,你场景里RAG占大头,吞吐量要求不高的话vLLM的PagedAttention更省显存,量化直接上AWQ或GPTQ,4bit下Llama 3损失能控制在2%以内,先跑个评测集对比下就心里有数了。异常重试这块建议单独封装一层,用tenacity库做指数退避,外部API超时设短点比如3秒,重试3次就降级到预设回复,别让Agent卡死在那儿。低成本部署的话,可以试试双卡分片或者CPU offload,我们之前用两张3090跑70B量化模型,延迟5秒内,内部客服够用了。
说实话你这条链路能本地跑通已经赢了一半了,真正恶心人的全在部署那层。vLLM和TGI我建议直接上vLLM,社区活跃度高,bug修得快,而且PagedAttention对显存利用率提升明显,你那个微调过的Llama 3用float16跑不动的话,先试AWQ量化,4bit下效果损失比GPTQ小,尤其是客服这种短对话场景其实感知不强。显存不够还有个土办法,就是别把整个RAG的embedding模型和LLM塞同一张卡,分开部署用内网调用,成本比硬上量化划算。
至于Agent调外部API,你千万别自己写重试逻辑,直接用tenacity库,指数退避加抖动,再配个断路器模式,不然你生产环境里某个第三方接口抖一下,整个Agent线程池就全堵死了。还有个坑是超时设置,LLM生成本来就慢,但API调用的超时一定要比模型推理超时短得多,不然用户那边早断了你这边还在等响应。
低成本方案的话,你可以考虑用Ray Serve或者BentoML把推理服务包成独立微服务,这样跟你LangChain那套逻辑解耦,后面模型更新或者换量化方案不影响业务代码。另外强烈建议你提前做并发压测,别信什么“内部用没多少人”,客服Agent高峰期涌进来几十个会话,vLLM默认配置很容易OOM,得设好max-num-seqs和gpu-memory-utilization。最后问一句,你那边数据隐私要求严吗?如果日志里要脱敏,那LangSmith那套追踪工具链可能得自己改,这往往是被忽略的大坑。
vLLM和TGI选哪个其实取决于你并发量,内部客服的话vLLM的PagedAttention对显存利用率更友好,量化可以用GPTQ或AWQ,4bit基本不掉多少效果。外部API调用这块建议直接上tenacity做重试加退避,再配个熔断,不然一个接口挂了整个Agent就卡死。预算有限就别碰K8s了,docker compose加个nginx够用,省下来的钱买张24G卡更实在。
我们当时也是本地跑通就以为完事了,结果上生产第一个坑就是并发一上来vLLM直接OOM。量化可以先用GPTQ试试,4bit掉点其实没那么夸张,但得拿业务数据实测别偷懒。外部API那块建议直接上tenacity做重试加指数退避,再配个降级兜底,不然一个超时能把整个对话链路拖死。
预算紧就先上vLLM加4bit量化,掉点效果但能跑起来,后面再慢慢调。
vLLM和TGI都试过,小规模部署vLLM吞吐确实更香,量化建议先上GPTQ 4bit跑一轮评测,掉点一般能接受。异常重试这块强烈推荐tenacity,配合指数退避和超时,别自己手写。预算紧的话可以看看Ollama做兜底,虽然性能一般但省心。