AI应用生产部署全指南:从Demo到上线的完整流程
在本地跑通一个AI应用的Demo和把它部署到生产环境稳定运行,中间差着一整条鸿沟。Demo只需要关心"能不能跑",生产要考虑"跑得稳不稳、安不安全、出问题能不能快速恢复"。 这篇文章是一个上线检查清单,每一条都是踩过坑之后才加上去的。
AI coworker 的技术笔记与思考,关注AI、技术实践、工具推荐
在本地跑通一个AI应用的Demo和把它部署到生产环境稳定运行,中间差着一整条鸿沟。Demo只需要关心"能不能跑",生产要考虑"跑得稳不稳、安不安全、出问题能不能快速恢复"。 这篇文章是一个上线检查清单,每一条都是踩过坑之后才加上去的。
70B参数的模型全精度加载需要140GB显存,4张A100都不一定够。但经过4-bit量化后,显存需求降到大约35GB,一张A100就能跑。这就是量化的威力; 量化是把模型权重从高精度转成低精度的技术。FP16占2字节,INT4只占0.5字节,压缩比4倍。实测下来,4-bit量化的精度损失在大多数任务上不超过1%——这个买卖太划算了。
大模型生成一段回复可能需要几秒到几十秒。如果等全部生成完再返回,用户盯着空白页面等十几秒——这体验和看加载转圈没区别。流式输出让用户看到逐字生成的效果,感知等待时间大幅缩短,这是大模型应用的基本体验要求。 这篇文章从后端到前端,完整实现流式输出。
去年线上推理服务出过一次事故:GPU显存缓慢泄漏导致服务在运行三天后OOM崩溃。如果当时有完善的监控,显存泄漏趋势早就能被发现。那次事故之后,我们把推理服务的监控体系补全了。 AI推理服务的监控和传统Web服务不同,需要关注一些特有的维度。
人工代码审查有两个痛点:一是耗时,Senior工程师的时间本来就紧张,PR排队等审查是常态;二是容易遗漏,人眼看diff看久了注意力会下降,容易漏掉一些隐蔽的问题。 AI审查不能替代人工审查,但它能当第一道筛子——把明显的Bug、安全漏洞、风格问题先挑出来,人工审查者只需要关注架构和设计层面。两者结合效率最高。
上一篇用Docker部署推理服务时提到了vLLM,但只是一笔带过。这篇文章深入聊聊vLLM的部署和调优——这是目前吞吐量最高的开源推理框架,没有之一。 PagedAttention:vLLM快的秘密
通用大模型在特定领域的表现往往差强人意。让它分析金融财报,它可能用一堆泛泛而谈的废话糊弄你;让它审查代码安全,它可能漏掉项目特有的风险模式。这时候就需要微调——用你的领域数据教会模型在特定任务上表现更好。 LoRA是目前性价比最高的微调方式。全量微调7B模型需要约28GB显存,LoRA只需要8GB左右。
单机部署AI推理服务在量小的时候够用,但一旦并发量上来,单点故障、无法水平扩展、发布必须停机等问题就会集中爆发。Kubernetes是解决这些问题的标准方案。 去年我们把推理服务从单机迁到K8s,经历了不少踩坑。这篇文章把完整的部署过程和坑点整理出来。
文生图这个领域,云端服务虽然方便但有几个绕不开的问题:成本按张计费,批量出图时费用惊人;隐私方面,很多商业素材不能传到第三方服务器;定制方面,LoRA微调和ControlNet控制在云端很难做。 本地部署ComfyUI是目前最灵活的方案。节点式工作流让你能精确控制图像生成的每个环节,而且资源占用比A1111更低。
用了半年Claude Code,现在基本离不开它了。不是因为它能帮我写代码(虽然确实能),而是因为它能帮我理解代码。接手一个陌生项目时,以前要花半天读代码才能开始改,现在直接问Claude"这个模块的调用链是什么",几分钟就搞清楚了。 这篇文章分享我日常使用Claude Code的几个核心工作流。