1. 从零搭建AI工程能力为什么我劝你别一上来就调包这两年“AI工程”这个词被说得太多了多到有点变味。打开任何一个技术社区满屏都是“三行代码调用大模型”“十分钟搭建RAG”“零基础转行AI工程师”。我不否认这些内容降低了入门门槛但如果你真打算把AI工程当成一门能吃饭的手艺而不是发个朋友圈的谈资那“从零开始”这四个字的分量比你想的要重得多。我自己带过几个刚入行的同学也见过不少自学转岗的朋友。一个特别普遍的现象是大家能熟练地pip install一堆框架能照着文档把模型跑起来但一旦线上出了诡异问题——比如推理延迟突然翻倍、显存莫名其妙泄漏、检索结果时好时坏——就完全不知道从哪儿下手。根子就在于他们跳过了“从零”这个阶段直接站在了别人搭好的脚手架上脚手架一撤人就悬空了。所谓“ai-engineering-from-scratch”在我看来不是让你从零手写一个Transformer虽然写一遍确实有好处而是让你建立一套完整的、自底向上的认知链条数据怎么进来、模型怎么算、显存怎么管、服务怎么部署、效果怎么评估、成本怎么控制。这条链子上每一环你都得亲手摸过哪怕只是用最简陋的方式实现一遍你对整个系统的理解都会完全不一样。这篇文章适合谁看如果你是刚转行、正在疯狂补课的新人它能帮你把零散的知识点串成一条线如果你已经能跑通demo但一上生产就心虚它能帮你找到那些被框架藏起来的“黑盒”环节如果你只是对AI工程好奇想搞清楚这行到底在干什么那它也能给你一个不带滤镜的视角。我会尽量说人话把每个关键选择背后的“为什么”讲透而不是甩给你一堆命令让你自己悟。2. 整体思路先打通链路再谈优化2.1 为什么“端到端跑通”比“单点精通”更重要很多人的学习路径是反的先花两周啃完深度学习理论再花一周学PyTorch然后学LangChain再学向量数据库……每个模块单独看都懂但合在一起就懵。这就像学做菜你把刀工、火候、调味分别练了三个月结果第一次进厨房连先放油还是先放菜都不知道。我的建议是反过来的先用最笨的办法把“输入一句话→模型输出一句话”这条链路完整跑通哪怕用的是最土的方案。比如你完全可以用Flask写一个接口加载一个开源小模型接收请求、调用模型、返回结果。这个过程中你会遇到模型怎么加载、显存怎么分配、请求怎么排队、超时怎么处理。这些问题在框架文档里往往一笔带过但它们是AI工程真正的日常。端到端跑通之后你手里就有了一条“基线”。后面所有的优化——换更大的模型、加缓存、做量化、上分布式——都是在跟这条基线对比。没有基线你根本不知道优化有没有效果甚至不知道问题出在哪个环节。2.2 技术选型的核心逻辑别被“最新”绑架AI领域的技术迭代速度确实吓人今天刚学会的框架下个月可能就出了新版本。但如果你仔细观察那些真正在生产环境跑着的系统会发现它们用的技术往往不是最新的而是最稳的。我自己的选型原则有三条。第一优先选社区活跃、文档齐全的因为AI工程踩坑是常态有人踩过同样的坑能省你几天时间。第二优先选能“降级”的方案比如模型服务你得能随时切回一个更小更快的模型兜底而不是被某个特定模型绑死。第三优先选你能看懂源码的至少是能看懂核心逻辑的否则出了问题只能等社区修。拿模型推理框架举例。现在市面上有vLLM、TGI、TensorRT-LLM等等每个都有自己的优势场景。但如果你刚开始搭我建议先用最朴素的HuggingFace Transformers加一个简单的批处理逻辑把整个服务流程跑通。等你明确知道瓶颈在哪儿了——是吞吐不够还是延迟太高——再针对性地换框架。上来就上最复杂的方案出了问题你连排查的方向都没有。2.3 从“能跑”到“能用”的三个阶段我把AI工程能力的建设分成三个阶段每个阶段的目标和关注点完全不同。第一阶段是“能跑”。目标就是让模型在你的环境里输出结果。这个阶段你关注的是环境配置、依赖版本、模型加载。别小看这个阶段光是CUDA版本和PyTorch版本的匹配问题就能卡住不少人。第二阶段是“能用”。目标是在真实场景下稳定输出。这时候你要考虑的是并发、超时、错误处理、日志监控。一个请求进来如果模型推理要30秒用户早跑了你得想办法做流式输出或者异步处理。如果模型偶尔输出乱码你得有兜底策略。第三阶段是“好用”。目标是在成本和效果之间找到平衡。这时候你要做量化、蒸馏、缓存、路由。比如简单问题用小模型复杂问题才调大模型高频问题直接走缓存不重复推理。这些优化手段的前提是你已经对前两个阶段了如指掌。大部分教程只教第一阶段但真正拉开差距的是第二和第三阶段。而这两个阶段的能力恰恰只能通过“从零”实践来积累。3. 核心环节拆解那些框架不会告诉你的细节3.1 环境搭建版本地狱的逃生指南AI工程的环境配置是个玄学问题。我见过太多人卡在ImportError和CUDA out of memory上一卡就是好几天。这里分享几个我踩坑总结出来的原则。第一用容器别在宿主机上裸装。Docker不是万能的但它至少能保证你的环境是可复现的。今天跑通的代码明天换台机器还能跑这个价值在AI领域怎么强调都不过分。基础镜像建议直接用PyTorch官方提供的它已经把CUDA、cuDNN、PyTorch的版本匹配好了省去大量排查时间。第二锁定版本别用latest。pip install torch和pip install torch2.1.0是两个完全不同的世界。前者今天装和明天装可能得到不同版本后者至少保证你这次和下次装的一样。建议用requirements.txt或者poetry把版本锁死包括间接依赖。第三显存不够先别急着换卡先算账。一个7B参数的模型FP16精度下光权重就要占14GB左右加上KV Cache和中间激活值实际占用可能到20GB以上。如果你只有一张24GB的卡跑7B模型勉强够但并发一高就爆。这时候你可以考虑量化到INT8甚至INT4显存直接减半甚至更多代价是精度可能略有下降。这个取舍你得自己根据业务场景判断。注意量化不是万能的。有些模型量化后效果断崖式下跌尤其是小模型。建议量化后在你的实际测试集上跑一遍评估别只看论文里的指标。3.2 模型加载与推理显存都去哪儿了模型加载看起来就是一行from_pretrained的事但显存分配的门道很多。我拿一个实际案例来说明。假设你加载一个13B的模型FP16精度。权重本身占26GB左右。如果你用device_mapauto让HuggingFace自动分配它可能会把部分层放到CPU上推理速度会慢很多。如果你手动指定device_map{: 0}全部放GPU那显存必须够否则直接OOM。更隐蔽的是KV Cache的占用。自回归生成时每生成一个token都需要缓存之前所有token的Key和Value矩阵。这个缓存的大小跟批次大小、序列长度、模型层数、注意力头数都相关。粗略估算一个13B模型在批次为1、序列长度2048的情况下KV Cache可能占几个GB。批次翻倍KV Cache也翻倍。所以你会发现有时候模型能加载进去但一推理就OOM问题就出在KV Cache上。解决办法有几个。一是限制最大序列长度别让用户输入无限长。二是用PagedAttention这类技术vLLM的核心把KV Cache分页管理减少碎片。三是动态批处理把多个请求拼成一个批次提高显存利用率。这些手段在框架里可能就是一个参数的事但你不理解背后的原理就不知道什么时候该调哪个参数。3.3 服务化从脚本到API的距离把模型跑通之后下一步是把它变成一个服务。很多人直接用Flask写个接口就上线了结果一压测就崩。问题通常出在几个地方。第一模型推理是阻塞的。Flask默认是同步的一个请求进来模型推理期间整个进程都在等其他请求只能排队。解决办法是用异步框架比如FastAPI加async或者起多个worker进程。但起多个worker又带来新问题每个worker都要加载一份模型显存直接翻倍。这时候你就需要模型服务框架比如Triton或者vLLM的server模式它们支持多请求共享同一份模型权重。第二没有做请求队列和限流。线上流量是不可预测的突然来一波高峰如果没有队列和限流请求会全部堆在模型前面导致超时雪崩。我的做法是在服务前面加一层队列比如Redis或者RabbitMQ请求先入队模型按自己的能力消费。同时设置最大队列长度超过就直接拒绝保护后端。第三日志和监控缺失。模型服务出问题往往不是非黑即白的崩溃而是效果慢慢变差、延迟慢慢变高。如果没有详细的日志请求内容、响应时间、输出结果和监控指标QPS、P99延迟、显存使用率你根本发现不了问题。我建议至少记录每个请求的耗时和输出token数这两个指标能反映大部分异常。3.4 效果评估别拿感觉当标准AI工程和传统软件工程最大的区别在于AI系统的输出是不确定的。同样的输入模型可能给出不同的输出。这就导致“效果好不好”很难用传统的测试用例来验证。我见过不少团队上线前就找几个人随便试几个问题觉得“还行”就发了。结果上线后用户投诉不断。问题在于你试的那几个问题恰好是模型擅长的而用户问的是千奇百怪的东西。我的做法是建立一个评估集。这个评估集不需要很大但必须覆盖你的核心场景。比如你做客服机器人评估集里就要有退换货、物流查询、产品咨询、投诉建议等各类问题每个类别至少几十条。然后定义评估指标回答准确率、无关回答率、有害内容率。每次模型更新或者参数调整都跑一遍评估集看指标有没有下降。评估集的维护是个长期工作。线上发现的bad case要及时加进去模型迭代后要重新标注。这个过程很枯燥但它是AI工程从“玩具”走向“产品”的必经之路。4. 实操全流程手把手搭一个最小可用系统4.1 第一步用Docker把环境锁死我以PyTorch为例给一个可以直接抄的Dockerfile思路。基础镜像选pytorch/pytorch:2.1.0-cuda12.1-cudnn8-runtime这个镜像已经包含了CUDA和PyTorch省去大量配置时间。然后在里面装你的业务依赖比如transformers、fastapi、uvicorn、redis。关键点是所有依赖都写死在requirements.txt里并且指定精确版本。比如transformers4.36.0而不是transformers4.36。构建镜像的时候用--no-cache-dir减少体积。最后把模型文件也打进镜像或者挂载进去保证容器启动就能用。这个Dockerfile可能看起来很简单但它解决了一个大问题环境一致性。你在本地跑通的代码打成镜像后在任何支持Docker的机器上都能跑不会出现“在我电脑上好好的”这种情况。4.2 第二步写一个最笨的推理脚本先别管什么框架用最直接的方式加载模型并推理。代码大概长这样from transformers import AutoModelForCausalLM, AutoTokenizer import torch model_name your-model-path tokenizer AutoTokenizer.from_pretrained(model_name) model AutoModelForCausalLM.from_pretrained( model_name, torch_dtypetorch.float16, device_mapauto ) def generate(prompt, max_new_tokens256): inputs tokenizer(prompt, return_tensorspt).to(model.device) with torch.no_grad(): outputs model.generate( **inputs, max_new_tokensmax_new_tokens, do_sampleTrue, temperature0.7 ) return tokenizer.decode(outputs[0], skip_special_tokensTrue)这个脚本很简陋但它包含了核心要素模型加载、tokenization、生成、解码。你先把它跑通观察显存占用、生成速度、输出质量。这些观察结果会成为你后续优化的依据。提示第一次加载模型可能会很慢因为要从磁盘读几十GB的文件。建议把模型放在SSD上机械硬盘的读取速度会成为瓶颈。4.3 第三步包一层API并加上队列用FastAPI把上面的推理逻辑包起来同时加一个简单的内存队列。核心思路是API接收请求后不直接推理而是把请求放进队列由一个后台worker消费。这样可以控制并发避免显存爆炸。from fastapi import FastAPI from queue import Queue import threading app FastAPI() request_queue Queue(maxsize100) def worker(): while True: prompt, future request_queue.get() result generate(prompt) future.set_result(result) threading.Thread(targetworker, daemonTrue).start() app.post(/generate) async def generate_api(prompt: str): future asyncio.Future() request_queue.put((prompt, future)) return await future这个方案很粗糙但能让你理解队列和异步的基本原理。实际生产中你会用更成熟的方案比如Celery加Redis或者直接用vLLM的server。但原理是一样的请求和推理解耦用队列做缓冲。4.4 第四步加上日志和基础监控在每个请求处理前后打日志记录请求ID、输入长度、输出长度、耗时。这些日志写到文件或者直接输出到stdout用Docker的日志驱动收集。监控方面至少暴露一个/metrics接口返回当前队列长度、总请求数、平均延迟。这些数据可以用Prometheus抓取然后在Grafana里看趋势。别小看这些基础工作。我见过太多系统出问题的时候连“什么时候开始变慢的”都不知道只能靠猜。有了日志和监控你至少能定位到时间点和影响范围。5. 常见问题与排查技巧实录5.1 显存相关问题的排查思路显存问题是最常见的表现也最直接OOM崩溃。但OOM的原因有很多种得逐一排查。先看模型权重占了多少。用nvidia-smi看显存占用如果加载完模型就占了大部分那说明模型本身太大需要考虑量化或者换小模型。如果加载完还好一推理就爆那多半是KV Cache或者中间激活值的问题。这时候可以尝试减小批次大小、限制最大序列长度、开启梯度检查点如果是训练。还有一个隐蔽的问题是显存碎片。长时间运行后显存可能被分割成很多小块虽然总空闲量够但没有连续的大块可用。解决办法是定期重启服务或者用支持PagedAttention的推理框架。5.2 输出质量波动的应对策略模型输出时好时坏可能的原因有几个。一是输入分布变了用户问了训练数据里没有的东西。这时候需要收集bad case考虑做微调或者加检索增强。二是解码参数不合适比如temperature太高导致输出随机性太大或者top_p太小导致输出多样性不足。三是模型本身的能力边界有些问题它就是答不好这时候需要产品层面做兜底比如转人工或者返回固定话术。我的经验是先固定解码参数用评估集测一遍确认模型在标准条件下的表现。然后再看线上bad case判断是参数问题还是能力问题。别一上来就调参数那样你永远不知道问题出在哪儿。5.3 服务稳定性问题的速查表下面这个表是我自己总结的常见服务问题排查清单放在手边随时查。现象可能原因排查方法解决方向请求超时队列积压看队列长度和消费速度扩容worker或限流延迟逐渐升高显存碎片或内存泄漏监控显存和内存趋势定期重启或换推理框架部分请求失败输入超长或格式异常看失败请求的日志加输入校验和截断输出乱码tokenizer不匹配检查tokenizer和模型是否对应统一tokenizer版本吞吐上不去批次太小或同步阻塞看GPU利用率和批次大小动态批处理或异步化这张表不是万能的但能覆盖大部分日常问题。遇到新问题就补充进去慢慢就形成自己的知识库了。5.4 成本控制的几个实用技巧AI工程绕不开成本。GPU贵电费贵人力更贵。我分享几个实际有效的省钱办法。第一缓存高频请求。很多用户问的问题是重复的尤其是客服场景。把问题和答案缓存起来下次同样的问题直接返回不走模型。缓存可以用Redis设置合理的过期时间。第二路由分流。简单问题用小模型复杂问题才用大模型。怎么判断简单还是复杂可以用一个分类器或者用规则比如问题长度、是否包含特定关键词。这个策略能省下大量推理成本。第三量化。INT8量化通常能把显存减半速度提升30%以上精度损失在可接受范围内。INT4量化更激进但精度损失需要评估。建议从INT8开始试。第四按需伸缩。流量有高峰有低谷没必要一直开着最大配置。用Kubernetes的HPA或者简单的定时脚本在低谷时缩容高峰时扩容。这个需要你的服务是无状态的模型可以从共享存储加载。6. 从零到一之后下一步往哪儿走把上面这套流程走完你手里就有了一个能跑、能用、能监控的AI服务。虽然简陋但五脏俱全。接下来往哪个方向深入取决于你的实际需求。如果你追求效果可以研究微调。用LoRA或者QLoRA在特定数据上微调模型让它在你的场景下表现更好。微调的门槛比想象中低一张消费级显卡就能跑7B模型的LoRA。但微调的数据准备和评估是个细致活需要耐心。如果你追求性能可以研究推理优化。vLLM、TensorRT-LLM、FlashAttention这些技术能把吞吐提升几倍甚至十几倍。但每个技术都有自己的适用场景和坑建议先在测试环境验证别直接上生产。如果你追求工程化可以研究MLOps。模型版本管理、实验追踪、自动化评估、持续部署这些是团队协作的基础设施。工具链很长从MLflow到Weights Biases到Kubeflow选适合自己团队规模的就行别为了用而用。我个人在实际操作中的体会是AI工程最难的不是某个具体技术而是“判断力”——知道什么时候该用什么方案知道什么问题可以暂时忽略知道什么优化值得投入。这种判断力只能通过大量实践和踩坑来积累。所以别怕犯错别怕方案简陋先跑起来再慢慢迭代。你踩过的每一个坑都会变成别人问你时你能脱口而出的经验。