1. 从零手搓AI工程为什么我不建议你直接调包很多人一听到“AI工程”这四个字第一反应就是打开某个云平台拖几个组件调几个API然后跑通一个Demo就觉得自己已经入门了。我刚开始接触这个方向的时候也是这么想的直到有一次线上推理服务在高峰期直接雪崩日志里全是显存溢出和请求超时我才意识到——只会调包的人根本不知道系统在哪个环节出了问题更别提优化了。ai-engineering-from-scratch这个标题核心不在“AI”而在“from scratch”。它强调的是一种从底层构建、从原理出发的工程能力。你要做的事情不是调用一个现成的模型接口而是理解一个AI系统从数据输入到结果输出的完整链路数据怎么预处理、模型怎么加载、推理怎么调度、显存怎么管理、服务怎么暴露、并发怎么控制。这些环节里任何一个出问题整个系统就会像多米诺骨牌一样倒下。这篇文章适合三类人第一类是有一定编程基础想从传统后端或数据方向转入AI工程的同学第二类是在做AI应用开发但总觉得“知其然不知其所以然”的开发者第三类是对AI系统底层机制好奇想自己动手搭一套可运行、可调试、可扩展的推理服务的技术爱好者。我会从最基础的环境搭建讲起一直讲到如何做一个能扛住一定并发压力的推理服务中间会穿插大量我在实际项目中踩过的坑和总结的经验。需要提前说明的是这篇文章不会涉及任何特定云厂商的绑定操作也不会教你如何“一键部署”。我们要做的是理解每一层在干什么为什么这么干以及不这么干会出什么问题。只有把底层逻辑吃透了你换任何平台、任何框架都能快速上手。2. 环境搭建别让CUDA版本成为你的第一个噩梦2.1 硬件与驱动的前置检查在开始写任何代码之前有一件事比装Python包重要一百倍确认你的硬件和驱动状态。我见过太多人卡在“torch.cuda.is_available()返回False”这一步然后开始疯狂重装驱动最后把系统搞崩。其实这个问题90%的情况下不是驱动坏了而是版本不匹配。先做三件事。第一确认你的GPU型号和计算能力。在终端执行nvidia-smi你会看到显卡型号、驱动版本、CUDA版本以及当前显存占用。这里显示的CUDA版本是驱动支持的最高CUDA版本不是你实际安装的CUDA Toolkit版本。很多人会把这两个搞混以为显示12.4就是自己装了12.4其实不是。第二确认你的CUDA Toolkit版本。执行nvcc --version如果提示找不到命令说明你根本没装CUDA Toolkit或者环境变量没配好。第三确认你的深度学习框架版本。以PyTorch为例执行python -c import torch; print(torch.__version__, torch.version.cuda)这会告诉你PyTorch编译时链接的CUDA版本。这三者之间的关系是驱动版本决定了你最高能用哪个CUDA版本CUDA Toolkit版本决定了你编译自定义算子时能用什么特性而PyTorch的CUDA版本必须和CUDA Toolkit版本兼容。我个人的经验是不要追求最新版本而是选择一个经过社区验证的稳定组合。比如驱动535系列配CUDA 12.2再配PyTorch 2.1.x这个组合我在多个项目里用过稳定性很好。注意如果你用的是WSL2环境nvidia-smi能显示信息不代表CUDA一定能用。WSL2的CUDA支持需要额外的驱动组件而且对版本匹配更敏感。建议在WSL2里先用torch.cuda.is_available()做一次快速验证再继续后续步骤。2.2 Python环境隔离的几种方案对比环境隔离这件事看起来简单但选错了方案后面会非常痛苦。我试过三种主流方案venv、conda和Docker。它们各有适用场景没有绝对的好坏。venv是Python自带的最轻量创建速度快适合纯Python项目。但它的缺点也很明显不能管理非Python依赖比如CUDA Toolkit、cuDNN这些库。如果你的项目需要编译自定义CUDA算子venv就力不从心了。conda能管理非Python依赖可以安装cudatoolkit、cudnn这些包省去了手动配置的麻烦。但conda的环境体积大解析依赖慢而且有时候会出现“conda装的CUDA和系统CUDA冲突”的问题。我的建议是如果你只是跑推理不编译自定义算子conda是省心的选择如果你要编译算子最好用系统级CUDA然后用venv隔离Python包。Docker是最彻底的隔离方案能把整个运行环境打包包括系统库、CUDA驱动、Python依赖。它的缺点是学习曲线陡而且需要额外配置GPU透传。但在团队协作和部署场景下Docker的优势无可替代。我现在的做法是开发阶段用conda快速迭代部署阶段用Docker保证一致性。方案隔离级别管理非Python依赖体积适用场景venvPython包级否小纯Python推理项目conda环境级是大需要CUDA Toolkit的快速开发Docker系统级是很大团队协作与生产部署2.3 依赖安装的版本锁定策略依赖版本锁定是很多新手忽略的一步。我刚开始的时候也是pip install torch transformers一把梭结果今天跑通的代码明天换台机器就报错。后来我养成了一个习惯所有项目必须有一个requirements.txt而且所有版本号必须精确到小版本。为什么精确到小版本因为深度学习框架的API变动很频繁比如PyTorch从1.x到2.x很多函数的默认行为都变了。Transformers库更是如此不同版本之间模型加载方式可能完全不同。我建议的做法是先用pip install装好能跑通的版本然后执行pip freeze requirements.txt把当前环境的完整依赖树导出。下次部署时用pip install -r requirements.txt复现。但这里有个坑pip freeze会导出所有依赖包括间接依赖有时候会有平台相关的包混进去。更稳妥的做法是用pip-tools或者poetry来管理。不过对于个人项目pip freeze已经够用了。关键是养成习惯不要等到出问题了才想起来锁版本。3. 模型加载与推理从“能跑”到“跑得稳”之间隔着什么3.1 模型格式的选择与转换逻辑模型加载是AI工程里最容易被低估的环节。很多人以为model AutoModel.from_pretrained(xxx)就完事了但在生产环境里模型格式的选择直接影响加载速度和内存占用。常见的模型格式有几种PyTorch原生的.bin或.ptHugging Face的safetensorsONNX以及TensorRT引擎。它们各有优劣。.bin格式是PyTorch的默认保存格式兼容性最好但加载时需要反序列化速度慢而且存在安全风险pickle反序列化可能执行恶意代码。safetensors是Hugging Face推出的格式加载速度快内存映射友好而且没有安全问题现在已经是主流选择。ONNX是跨框架的中间表示适合在不同推理引擎之间迁移。TensorRT是NVIDIA的推理优化引擎能把模型编译成针对特定GPU优化的引擎推理速度最快但编译过程复杂而且不跨平台。我的建议是开发阶段用safetensors部署阶段如果追求极致性能再考虑转TensorRT。转换过程本身也有讲究比如ONNX导出时需要指定动态轴否则batch size会被固定死。TensorRT编译时需要设置最大batch size和最大序列长度设置太小会限制吞吐设置太大会浪费显存。提示从safetensors转ONNX时务必用torch.onnx.export的dynamic_axes参数把batch维度和序列维度标记为动态。否则你后面想改batch size就得重新导出非常麻烦。3.2 显存管理的三个关键参数显存管理是AI工程的核心技能之一。我见过太多项目因为显存问题在线上崩溃。这里讲三个最关键的参数max_batch_size、max_seq_length和gpu_memory_utilization。max_batch_size决定了单次推理能处理多少条请求。设太小吞吐上不去设太大显存不够直接OOM。怎么算假设你的模型是7B参数FP16精度那么模型权重占14GB左右。如果GPU是24GB显存剩下10GB给KV Cache和中间激活。KV Cache的大小和batch size、序列长度、层数、注意力头数都有关。粗略估算每token每层的KV Cache大约是2 * hidden_size * 2 bytes。对于7B模型hidden_size通常是4096那么每token每层约16KB32层就是512KB。如果序列长度是2048batch size是8那么KV Cache就是512KB * 2048 * 8 ≈ 8GB。加上模型权重14GB总共22GB刚好卡在24GB边缘。max_seq_length直接影响KV Cache大小。很多模型默认支持4096甚至8192的序列长度但你的实际业务可能只需要512。把max_seq_length设小一点能省下大量显存从而支持更大的batch size。这是一个典型的权衡长序列和大的batch size往往不能兼得。gpu_memory_utilization是vLLM等推理框架提供的参数控制框架能使用多少比例的显存。默认是0.9意思是留10%给系统和其他进程。如果你发现推理过程中频繁OOM可以试着降到0.85或0.8。但降太多会导致可用显存不足反而降低吞吐。3.3 推理框架的选型原生PyTorch、vLLM还是TGI推理框架的选择决定了你的服务上限。原生PyTorch最灵活但性能最差因为没有做任何推理优化。vLLM是目前最流行的开源推理框架核心优势是PagedAttention能把KV Cache分页管理大幅减少显存碎片提升吞吐。TGI是Hugging Face推出的推理服务框架集成了连续批处理和流式输出部署简单。我做过一个对比测试同样的7B模型同样的GPU原生PyTorch的吞吐大约是每秒5个请求vLLM能到每秒20个TGI在每秒15个左右。差距非常明显。但vLLM的缺点是配置项多调参需要经验。TGI的优点是开箱即用但定制化能力弱一些。如果你要做的是通用对话服务vLLM是首选。如果你要快速搭一个DemoTGI更省事。如果你要研究推理优化本身原生PyTorch加自己写的调度逻辑更有学习价值。我的建议是先用vLLM把服务跑起来理解它的调度逻辑和参数含义然后再根据业务需求做定制。4. 服务化与并发让推理服务真正能扛住流量4.1 从单次推理到HTTP服务的封装思路把模型跑通只是第一步把它变成一个能对外提供服务的HTTP接口才是工程化的开始。这里涉及几个关键决策用什么Web框架、怎么处理并发、怎么管理模型生命周期。Web框架方面FastAPI是目前最主流的选择。它基于Starlette和Pydantic支持异步IO性能好而且自动生成API文档。Flask也能用但同步模型在高并发下会阻塞。我建议直接用FastAPI配合uvicorn作为ASGI服务器。模型生命周期管理是很多人忽略的点。模型加载很慢不能每次请求都加载一遍。正确的做法是在服务启动时加载一次然后常驻内存。但这里有个问题如果模型加载失败服务应该启动失败还是降级运行我的经验是启动时加载失败应该直接让服务退出因为一个没有模型的服务没有任何意义。可以用健康检查接口来暴露模型状态让负载均衡器知道这个实例是否可用。另一个关键点是请求队列。当并发请求超过模型处理能力时请求会堆积。如果不加控制内存会被撑爆。解决方案是引入一个有界队列当队列满时直接返回503而不是无限等待。这个队列的大小需要根据你的显存和延迟要求来定。一般来说队列长度不要超过max_batch_size * 2否则延迟会急剧上升。4.2 连续批处理与动态批处理的区别连续批处理和动态批处理是两个容易混淆的概念。动态批处理是指把多个请求攒在一起凑成一个batch送给模型。连续批处理是指在一个batch还在处理时就把新来的请求加入下一个batch而不是等当前batch完全结束。vLLM用的是连续批处理这是它吞吐高的核心原因。传统动态批处理的问题是如果一个batch里有长序列和短序列短序列处理完了也要等长序列GPU利用率低。连续批处理通过PagedAttention把KV Cache分页不同请求可以共享同一个batch的不同位置短序列完成后立即释放资源给新请求。理解这个机制对调参很重要。比如max_num_seqs参数控制同时处理的序列数设太小吞吐上不去设太大显存不够。max_num_batched_tokens控制一个batch里最多多少token这个参数直接影响延迟和吞吐的平衡。我的经验是先从默认值开始然后用压测工具逐步调整观察吞吐和延迟的变化曲线找到拐点。4.3 压测与容量评估的实操方法压测是验证服务能力的唯一手段。我见过很多人凭感觉说“我的服务能扛100并发”结果一压测就崩。压测工具方面wrk、ab、locust都可以用。对于AI推理服务我推荐用locust因为它能模拟真实的请求分布比如不同长度的输入。压测时要注意几个指标QPS每秒查询数、P99延迟、错误率、GPU利用率。QPS和延迟是一对矛盾QPS上去了延迟通常也会上去。关键是找到业务能接受的延迟上限对应的QPS。比如业务要求P99延迟不超过2秒那么你就要在压测中找到P99延迟等于2秒时的QPS这就是你的容量上限。容量评估还要考虑突发流量。线上流量往往不是均匀的会有尖峰。我的做法是在压测得到的容量上限基础上打七折作为安全水位。比如压测得到100 QPS时P99延迟2秒那么线上按70 QPS来规划资源。这样留出30%的余量应对突发。注意压测时一定要用真实的数据分布。如果你用固定长度的短输入压测得到的QPS会虚高。实际业务中长输入会拉低吞吐所以压测数据要覆盖你业务中可能出现的各种长度。5. 踩坑实录那些让我熬夜排查的典型问题5.1 显存泄漏为什么服务跑几小时就OOM显存泄漏是AI服务最隐蔽的问题之一。表现是服务刚启动时显存占用正常跑几个小时后显存逐渐涨满最后OOM崩溃。这个问题排查起来很痛苦因为不是必现的而且和请求模式有关。我遇到过一次典型的显存泄漏原因是请求处理过程中创建了中间张量但没有及时释放。PyTorch的显存管理是基于缓存分配器的当你创建一个张量时它会从缓存池里分配显存当你不再引用这个张量时显存会回到缓存池但不会立即还给GPU。所以nvidia-smi看到的显存占用会一直很高但这不一定是泄漏。真正的泄漏是缓存池里的显存不断增长从不释放。排查方法是在服务运行过程中定期打印torch.cuda.memory_allocated()和torch.cuda.memory_reserved()。如果memory_allocated持续增长说明有张量没被释放。常见原因包括把张量存到了全局变量里、在循环中不断创建新张量而没有复用、异常处理中没有清理中间变量。解决方案是在请求处理的最后显式调用torch.cuda.empty_cache()。但注意这个操作会清空缓存池导致下次分配显存时重新向GPU申请有性能开销。所以不要每次请求都调而是在显存增长到一定阈值时调。另一个方案是用del显式删除不再使用的张量然后调empty_cache。5.2 请求超时是模型慢还是调度慢请求超时是另一个常见问题。用户反馈“接口很慢”但你去看GPU利用率发现并不高。这时候要区分是模型推理慢还是调度环节慢。我的排查方法是在请求处理的关键节点打时间戳包括请求到达时间、进入队列时间、开始推理时间、推理结束时间、返回响应时间。这样能清楚看到时间花在哪里。如果队列等待时间长说明并发太高需要扩容或限流。如果推理时间长说明模型或参数需要优化。如果响应返回时间长可能是序列化或网络问题。有一次我遇到的情况是推理本身只要200毫秒但端到端延迟有5秒。排查后发现是FastAPI的默认线程池太小请求在等待线程。解决方案是调整uvicorn的--workers参数和FastAPI的线程池配置。这个坑很典型大家往往关注GPU侧忽略了Web框架侧的瓶颈。5.3 模型加载失败路径、权限与格式的三重检查模型加载失败的原因通常有三类路径不对、权限不够、格式不兼容。路径问题最常见特别是用相对路径时工作目录变了就找不到。我的习惯是所有模型路径都用绝对路径或者在启动时把模型路径转成绝对路径。权限问题在Docker环境里很常见。如果你用非root用户运行容器而模型文件是root拥有的就会读不了。解决方案是在Dockerfile里用chown把模型目录的权限给运行用户或者在启动脚本里用chmod放开读权限。格式不兼容通常发生在跨框架加载时。比如你用TensorFlow保存的模型想用PyTorch加载那肯定不行。即使是同框架不同版本的保存格式也可能不兼容。比如PyTorch 2.0保存的模型用1.13加载可能会报错。解决方案是保存模型时同时保存版本信息加载时先检查版本兼容性。6. 从能用到好用几个提升工程质量的细节6.1 日志与监控别等出事了才去看日志日志和监控是生产服务的眼睛。我见过很多项目日志只打print没有级别、没有时间戳、没有请求ID出了问题根本没法排查。正确的做法是用结构化日志每条日志包含时间戳、级别、请求ID、模块名、消息。Python里可以用logging模块配合json格式化器。监控方面至少要采集几个核心指标请求量、延迟分布、错误率、GPU利用率、显存占用。这些指标可以用Prometheus采集用Grafana展示。如果不想搭这么重的方案至少也要把指标定期写到日志里方便事后分析。请求ID是排查问题的利器。每个请求进来时生成一个唯一ID贯穿整个处理链路。这样当用户反馈“我的请求很慢”时你可以用请求ID把所有相关日志串起来快速定位问题。6.2 优雅停机别让正在处理的请求被粗暴中断优雅停机是指服务收到停止信号后不立即退出而是等待正在处理的请求完成同时拒绝新请求。这个功能在滚动更新时非常重要。如果没有优雅停机更新时正在处理的请求会直接失败用户会看到错误。FastAPI和uvicorn支持优雅停机但需要正确配置。uvicorn的--timeout-graceful-shutdown参数控制等待时间。FastAPI的shutdown事件可以用来清理资源比如关闭数据库连接、释放模型显存。我的做法是在shutdown事件里设置一个标志位让请求处理逻辑检查这个标志位如果服务正在关闭就快速返回503。6.3 配置管理别把参数硬编码在代码里配置管理是工程成熟度的标志。把max_batch_size、max_seq_length、模型路径这些参数硬编码在代码里改一个参数就要重新部署非常低效。正确的做法是用配置文件或环境变量。我推荐用环境变量加默认值的方案。环境变量在容器化部署时特别方便Kubernetes的ConfigMap和Secret就是基于环境变量的。Python里可以用os.getenv(MAX_BATCH_SIZE, 8)来读取同时提供合理的默认值。对于复杂的配置可以用YAML文件然后用Pydantic做校验确保配置项类型正确、取值范围合理。配置变更要有记录。我见过因为改了配置没记录导致线上出问题后排查了半天的情况。建议把配置变更也纳入版本管理每次变更都提交到Git写清楚变更原因和影响范围。7. 我个人在实际操作中的体会从零搭建AI工程这件事最大的价值不在于你最终做出了什么而在于过程中你被迫理解了每一个环节的细节。调包当然快但调包的人永远不知道包里面发生了什么。当你自己动手处理显存分配、请求调度、并发控制这些问题时你对整个系统的理解会完全不一样。我最大的体会是AI工程的难点不在AI而在工程。模型本身是算法团队交付的但怎么让模型稳定、高效、可扩展地运行是工程团队要解决的问题。这需要你既懂一点算法原理又懂系统设计还要有排查问题的耐心。另一个体会是不要追求一步到位。我刚开始的时候总想搭一个“完美”的系统结果花了大量时间在设计上迟迟跑不起来。后来我改变了策略先跑通最小闭环然后逐步优化。先让服务能处理一个请求再考虑并发先让服务能跑一小时再考虑跑一周。这种迭代式的做法比一开始就追求完美要高效得多。最后分享一个小技巧每次遇到问题解决之后一定要写下来。不是写给别人的是写给自己的。因为同样的问题三个月后你很可能再遇到一次到时候有笔记就能快速解决。我现在的项目里有一个TROUBLESHOOTING.md记录了所有踩过的坑和解决方案已经成了团队里最有价值的文档之一。