1. 从零手搓AI工程为什么我不建议你直接调包很多人一听到“AI工程”这四个字第一反应就是打开某个云平台拖几个组件、调几个API然后跑通一个Demo就觉得自己已经入门了。我刚开始接触这个方向的时候也是这么想的直到有一次线上推理服务在高峰期直接雪崩日志里全是显存溢出的报错我才意识到——只会调包的人永远不知道系统在什么边界条件下会崩。ai-engineering-from-scratch这个项目标题本身就说明了一件事它不打算教你如何调用现成的框架而是要从最底层把AI工程这条链路重新走一遍。所谓“from scratch”不是让你从汇编语言开始写矩阵乘法而是让你理解一个AI系统从数据进入、模型加载、推理调度、结果返回这整条链路上每一个环节到底发生了什么。这件事的价值在于当你遇到性能瓶颈、内存泄漏、推理延迟抖动这些问题时你能定位到具体是哪一层出了问题而不是对着黑盒干瞪眼。这篇文章适合三类人第一类是有一定编程基础、想真正搞懂AI系统内部运转机制的开发者第二类是在工作中被推理性能问题折磨过、想系统补齐工程能力的算法工程师第三类是准备做AI应用但不想被某个平台绑死的独立开发者。我会从环境搭建、核心组件实现、性能调优、踩坑排查这几个维度把从零构建AI工程能力这件事讲透。需要提前说明的是本文不会涉及任何具体的商业平台推荐也不会教你绕过某些限制所有内容都基于公开的技术原理和通用的工程实践。我的目标是让你看完之后能自己动手搭出一套可运行、可调试、可优化的AI推理链路。2. 环境准备别急着装框架先把地基打牢2.1 硬件选型的真实考量很多人上来就问“我该买什么显卡”这个问题其实没有标准答案因为选型取决于你要跑什么规模的模型。但有一个原则是通用的显存比算力更重要。我见过太多人买了一堆算力很强但显存不够的卡结果模型加载到一半就OOM算力再强也白搭。以一个中等规模的Transformer模型为例假设参数量是7B用FP16精度存储光权重就需要大约14GB显存。这还没算上推理过程中的KV Cache、中间激活值、以及框架本身的开销。实际跑起来至少需要20GB以上的显存才能比较从容。如果你打算做微调那显存需求还要翻倍。所以我的建议是在预算允许的范围内优先保证显存容量其次再考虑算力。对于个人开发者来说一张24GB显存的卡是目前比较舒服的起点能覆盖大部分7B到13B模型的推理需求。2.2 软件栈的版本锁定策略AI工程领域最让人头疼的问题之一就是依赖冲突。PyTorch、CUDA、cuDNN、Python版本之间有着严格的对应关系装错一个版本就可能导致整个环境跑不起来。我的做法是永远用虚拟环境永远锁定版本号。具体操作上我习惯用conda创建独立环境然后在项目根目录放一个requirements.txt把所有依赖的精确版本都写死。比如conda create -n ai-eng python3.10 conda activate ai-eng pip install torch2.1.0cu118 torchvision0.16.0cu118 --index-url https://download.pytorch.org/whl/cu118 pip install transformers4.35.0 accelerate0.24.0这里的关键是torch的版本要和CUDA版本匹配transformers的版本要和torch兼容。我一般会去PyTorch官网查兼容性表格确认无误后再安装。这一步多花十分钟能省掉后面几小时的排错时间。注意不要用pip install torch这种不带版本号的命令它可能会装到和你CUDA不匹配的版本导致torch.cuda.is_available()返回False。2.3 目录结构的设计习惯一个清晰的目录结构能让你在项目变大之后依然保持掌控感。我通常会把项目分成这几个部分ai-eng-project/ ├── configs/ # 配置文件 ├── data/ # 数据相关 │ ├── raw/ # 原始数据 │ └── processed/ # 处理后数据 ├── models/ # 模型权重 ├── src/ # 源代码 │ ├── data/ # 数据处理模块 │ ├── model/ # 模型定义 │ ├── inference/ # 推理逻辑 │ └── utils/ # 工具函数 ├── scripts/ # 运行脚本 ├── tests/ # 测试代码 └── requirements.txt这个结构的好处是当你要换模型或者换数据集时只需要改configs/里的配置不用动核心代码。我在实际项目中反复验证过这种分离设计能显著降低维护成本。3. 推理链路的核心组件从输入到输出到底经历了什么3.1 文本预处理被大多数人低估的环节很多人觉得预处理就是tokenizer.encode()一下完事但实际上这里面的坑非常多。首先是最大长度截断的问题如果你不设置max_length遇到超长输入时tokenizer可能会直接报错或者产生不可预期的行为。其次是padding策略在批量推理时如果padding方式不对会导致显存浪费甚至结果错位。我一般会这样处理from transformers import AutoTokenizer tokenizer AutoTokenizer.from_pretrained(model_path) tokenizer.pad_token tokenizer.eos_token # 很多模型默认没有pad_token def preprocess(texts, max_length512): encoded tokenizer( texts, paddingTrue, truncationTrue, max_lengthmax_length, return_tensorspt ) return encoded这里有个细节pad_token的设置。很多生成式模型比如GPT系列默认没有定义pad_token如果不手动设置批量推理时会报错。我一般用eos_token来充当pad_token因为它在语义上最接近“无内容”的填充。3.2 模型加载显存优化的第一道关卡模型加载方式直接决定了你的显存占用。最朴素的方式是model.to(cuda)但这会把整个模型一次性塞进显存。如果你的显存不够就需要用到一些优化技术。量化加载是最常用的手段之一。以4-bit量化为例可以把7B模型的显存占用从14GB降到大约4GBfrom transformers import BitsAndBytesConfig bnb_config BitsAndBytesConfig( load_in_4bitTrue, bnb_4bit_compute_dtypetorch.float16, bnb_4bit_quant_typenf4 ) model AutoModelForCausalLM.from_pretrained( model_path, quantization_configbnb_config, device_mapauto )device_mapauto会让accelerate库自动决定每一层放在哪个设备上如果你有多张卡它会自动做模型并行。这个参数在单卡场景下也很有用因为它会自动把不适合放在显存里的部分比如某些缓冲区放到CPU上。梯度检查点是另一个常用技术它用计算时间换显存空间。在推理场景下一般用不到但如果你要做微调这个技术能把显存占用降低60%以上。3.3 推理执行batch size的取舍艺术Batch size的选择是一个典型的权衡问题。增大batch size能提高GPU利用率降低单条数据的平均延迟但会线性增加显存占用。我的经验是从batch size1开始测逐步翻倍直到显存占用达到总容量的80%左右。为什么要留20%的余量因为推理过程中会有一些动态分配的内存需求比如KV Cache会随着生成长度增加而增长。如果你把显存占满生成长文本时就会OOM。另外动态batch是一个很实用的技巧。在服务化场景下请求是陆续到达的如果每个请求都单独推理GPU利用率会很低。动态batch会把短时间内到达的请求攒在一起凑成一个batch再推理。vLLM这个框架在这方面做得很好它用PagedAttention技术把KV Cache分页管理显存利用率能提升好几倍。3.4 后处理解码策略决定输出质量模型输出的logits需要经过解码才能变成文本。最常见的两种解码策略是贪心解码和采样解码。贪心解码每次选概率最大的token输出稳定但容易重复。采样解码引入随机性输出更多样但可能跑偏。实际应用中我一般用top-p采样也叫nucleus sampling它从累积概率达到p的最小token集合中采样能在多样性和质量之间取得比较好的平衡。outputs model.generate( input_ids, max_new_tokens256, do_sampleTrue, top_p0.9, temperature0.7, repetition_penalty1.1 )temperature控制随机性值越低输出越确定repetition_penalty用来抑制重复但设得太高会导致输出变得不自然。这些参数没有万能值需要根据具体任务调。4. 性能调优实战从能用 to 好用4.1 延迟分解找到真正的瓶颈在优化之前你必须知道时间花在哪里了。一个完整的推理请求可以分解成这几个阶段阶段典型耗时优化手段网络传输10-50ms压缩请求体、就近部署预处理5-20ms缓存tokenizer、异步处理模型前向100-2000ms量化、算子融合、批处理后处理5-30ms流式输出、增量解码我见过很多人一上来就优化模型前向结果发现网络传输才是大头。所以第一步永远是打点计时用time.perf_counter()在关键位置插桩把每个阶段的耗时都记录下来。4.2 KV Cache自回归生成的加速核心自回归生成的特点是每生成一个token都需要之前所有token的Key和Value向量。如果每次都重新计算复杂度是O(n²)。KV Cache的思路是把之前算过的Key和Value存下来下一个token只需要计算当前的Query然后和缓存的Key、Value做注意力。这个技术能把生成复杂度降到O(n)但代价是显存占用随生成长度线性增长。对于长文本生成任务KV Cache可能占用比模型权重还多的显存。优化KV Cache的手段有几种MQAMulti-Query Attention让所有头共享同一组Key和ValueGQAGrouped-Query Attention折中一下分组共享。这些是模型架构层面的优化需要在训练时就确定。推理层面能做的主要是Cache量化把FP16的Cache降到INT8显存占用直接减半。4.3 算子融合与编译优化PyTorch的eager模式是逐算子执行的每个算子都会启动一个CUDA kernelkernel启动的开销在小模型上可能比计算本身还大。算子融合把多个连续的操作合并成一个kernel减少启动开销。torch.compile是PyTorch 2.0引入的编译优化工具它能自动做算子融合、内存规划等优化model torch.compile(model, modereduce-overhead)reduce-overhead模式会使用CUDA Graph技术把整个推理过程捕获成一个图后续执行时直接重放能显著降低kernel启动开销。实测下来在小batch场景下能有20%到30%的延迟降低。但torch.compile不是万能的它需要编译时间而且某些动态控制流会导致编译失败。我的建议是先用eager模式跑通确认正确性后再尝试compile。4.4 服务化部署的并发模型如果你要把模型做成服务并发模型的选择很关键。最简单的方式是同步阻塞每个请求占一个线程但Python的GIL会让这种方式在多核上表现很差。更好的方式是异步批处理。用一个队列接收请求后台有一个推理线程不断从队列里取请求凑成batch后调用模型然后把结果分发回去。这种方式能充分利用GPU的并行能力同时避免GIL的限制。vLLM和TGI这些框架已经把这套逻辑封装好了但理解背后的原理能让你在出问题时知道去哪里找原因。比如当队列积压时你需要决定是增加batch size还是增加推理实例这个决策依赖于你对延迟和吞吐的权衡。5. 踩坑实录那些文档里不会告诉你的问题5.1 显存泄漏一个隐蔽的杀手有一次我写了一个循环推理的脚本跑了几百条数据后发现显存占用一直在涨最后OOM。排查了半天发现是没有用torch.no_grad()包裹推理代码。PyTorch默认会构建计算图即使你不调用backward()中间激活值也会被保留导致显存持续增长。with torch.no_grad(): outputs model.generate(...)加上这个上下文管理器后显存占用就稳定了。这个坑很隐蔽因为在小规模测试时可能看不出来只有跑大量数据时才会暴露。5.2 版本不匹配最冤枉的时间浪费CUDA版本、PyTorch版本、显卡驱动版本这三者之间有一个兼容性矩阵。我曾经遇到过驱动太新导致PyTorch不识别显卡的情况报错信息是CUDA error: no kernel image is available for execution on the device。这个报错看起来像是代码问题实际上是版本问题。排查方法是先用nvidia-smi看驱动支持的CUDA版本然后去PyTorch官网查对应版本。如果驱动太新可以降级驱动如果太旧就升级驱动。不要试图用conda install cudatoolkit来绕过驱动版本因为PyTorch用的是系统CUDA驱动conda装的CUDA toolkit只是提供了编译工具。5.3 批处理中的padding陷阱批量推理时如果不同样本的长度差异很大padding会浪费大量计算。比如一个batch里大部分样本长度是50但有一个是500那所有样本都要padding到500计算量翻了10倍。解决方案是按长度分桶把长度相近的样本放在同一个batch里。或者用动态padding每个batch只padding到该batch的最大长度。HuggingFace的DataCollatorWithPadding就是做这个的。5.4 生成任务的重复问题生成式模型有时候会陷入重复循环输出类似“好的好的好的好的”这样的内容。这个问题在贪心解码时尤其严重。解决方法有几个一是用采样解码代替贪心二是设置repetition_penalty三是用no_repeat_ngram_size禁止重复的n-gram。outputs model.generate( input_ids, no_repeat_ngram_size3, repetition_penalty1.2 )但要注意no_repeat_ngram_size设得太小会影响正常输出比如“中华人民共和国”这种包含重复字符的词组可能会被误伤。我一般从3开始试根据实际效果调整。6. 从单机到服务工程化的最后一公里6.1 配置管理别把参数写死在代码里当你的项目从脚本变成服务时配置管理就变得很重要。我习惯用YAML文件管理配置然后用OmegaConf或Pydantic做校验model: path: /models/llama-7b quantization: 4bit max_length: 2048 inference: batch_size: 8 max_new_tokens: 256 temperature: 0.7这样做的好处是换模型或者调参数时不需要改代码只需要改配置文件。而且配置文件可以纳入版本管理方便回溯。6.2 日志与监控出问题时能快速定位日志要记录这几个关键信息请求ID、输入长度、输出长度、推理耗时、显存占用。这些信息在排查性能问题时非常有用。我一般用Python的logging模块配合structlog做结构化日志。监控方面至少要关注P50、P95、P99延迟和吞吐量。P99延迟高说明有长尾请求可能是某些输入触发了慢路径。吞吐量下降可能是显存碎片化或者队列积压导致的。6.3 优雅降级当资源不够时怎么办线上服务总会遇到资源不足的情况比如并发请求太多导致显存不够。这时候需要有降级策略一是限制最大并发数超过的请求直接返回繁忙二是动态降低batch size牺牲吞吐保延迟三是切换到小模型用质量换可用性。这些策略需要在代码里提前实现不能等出问题了再临时加。我一般会在服务启动时根据显存容量计算一个安全的并发上限然后在运行时动态调整。7. 我在这条路上踩过的几个认知误区第一个误区是追求最新框架。我有一段时间看到新框架就想试结果项目里堆了一堆半成品维护成本极高。后来我给自己定了个规矩新框架先在独立环境里跑通Demo确认稳定后再引入主项目。第二个误区是忽视数据质量。AI工程不只是模型和推理数据预处理和清洗同样重要。我见过太多项目在模型上花了大把时间结果因为训练数据里有大量噪声效果怎么调都上不去。第三个误区是过早优化。一开始就想着用各种高级技术结果代码复杂度飙升调试困难。正确的做法是先用最简单的方式跑通确认功能正确后再逐步优化。第四个误区是不写测试。AI系统的行为有随机性但这不意味着不需要测试。至少要对预处理、后处理这些确定性环节写单元测试对推理结果写一些断言检查比如输出不为空、长度在合理范围内。8. 后续可以继续深入的方向如果你已经把上面这些内容都跑通了接下来可以往这几个方向深入一是模型量化研究GPTQ、AWQ这些量化算法的原理和实现二是分布式推理学习张量并行和流水线并行怎么把大模型拆到多张卡上三是推理引擎优化看vLLM、TensorRT-LLM这些框架的源码理解它们是怎么做到高吞吐的。我个人在实际操作中的体会是AI工程这个方向动手比看书重要得多。很多问题只有亲自踩过坑才能理解很多优化只有实测过才知道效果。所以别光看文章找个模型从加载到推理到服务化完整走一遍你会比看十篇文章收获都大。