1. 从零搭建AI工程能力为什么我劝你别一上来就调包这两年AI应用开发的门槛肉眼可见地在降低随便拉个框架、调个API、套个模板一个能跑通的Demo半天就能出来。但我自己带过几批人、也接手过不少半路出家的项目之后越来越确信一件事能跑通Demo和能交付一个稳定的AI工程系统中间隔着的不是几个库而是一整套工程思维。ai-engineering-from-scratch这个方向之所以值得单独拿出来聊恰恰是因为它逼着你把那些被高级框架封装掉的细节重新摊开看一遍——数据怎么进、模型怎么出、中间那层胶水代码到底在干什么。我写这篇东西的出发点很直接给那些想真正搞懂AI工程、而不是只会pip install之后复制粘贴的人一条可落地的路径。它适合有一定编程基础、但对AI系统内部机制还比较模糊的开发者也适合那些用惯了现成工具、想回头补课的中级工程师。整条路线我会按“先理解再实现、先手动再自动”的顺序展开核心思路是用最小的依赖把关键环节亲手写一遍等你对每个环节的输入输出、边界条件、性能瓶颈都有了肌肉记忆再去用成熟框架那才叫如虎添翼而不是被框架牵着走。需要先说明的是下面涉及的具体实现细节有一部分是基于我自己的实践和常见工程做法做的合理补全因为原始素材本身比较零散我会把“为什么这么选”讲清楚你完全可以按自己的场景调整。2. 整体路线设计与技术选型思路2.1 为什么坚持“从零”而不是“从框架”很多人会问现在框架这么成熟为什么还要从零写我的答案很实在框架帮你省掉的是重复劳动但它同时也会掩盖你对系统行为的判断力。举个我踩过的坑早期做一个文本分类服务用某个高层封装库本地测试准确率漂亮得不行一上线流量稍微大一点延迟就飙到几秒。排查了半天才发现问题出在框架默认的批处理策略上——它把每个请求单独编码完全没有利用批处理的并行能力。如果我从一开始就自己写过一遍推理流程知道batch_size对吞吐的影响这种问题五分钟就能定位。从零实现的价值不在于“造轮子”而在于建立对每个环节的掌控感。你知道数据在哪一步被转换、模型在哪一步被调用、显存在哪一步被占满出问题时你才有排查的抓手。所以整条路线的设计原则是每个核心环节先手写一个最小可用版本理解清楚之后再引入成熟工具做替换和优化。2.2 分阶段的能力地图我把整条路线拆成四个阶段每个阶段都有明确的产出物避免学了半天不知道自己在哪阶段核心目标关键产出建议投入基础层理解数据与张量手写数据处理管道1-2周模型层理解前向与反向手写小型网络训练2-3周服务层理解推理与部署可调用的推理接口2周工程层理解稳定性与扩展带监控的完整服务持续迭代这个划分不是绝对的但它的好处是每个阶段都能独立跑通、独立验证不会出现“学了一半发现前面基础没打牢”的尴尬。我见过太多人一上来就啃大模型微调结果连张量的维度变换都搞不清楚调参全靠玄学这种学习效率其实很低。2.3 技术栈的取舍逻辑在具体工具选择上我的原则是基础阶段尽量少依赖工程阶段尽量用成熟方案。基础阶段我会用Python加NumPy因为NumPy的API足够底层能让你看清矩阵运算的每一步模型阶段引入PyTorch因为它的动态图机制对调试友好print一下就能看到中间结果服务阶段用FastAPI轻量且异步支持好工程阶段再考虑引入Redis做缓存、Prometheus做监控这些。这里有个容易被忽略的点不要过早引入重型依赖。我见过有人为了做个简单的文本相似度服务上来就装了一堆分布式框架结果本地环境都跑不起来。工具是为问题服务的问题还没清晰之前工具越少越好。3. 核心环节拆解与手写实现要点3.1 数据处理管道一切问题的源头AI工程里百分之七八十的线上问题追根溯源都在数据处理环节。我自己的经验是数据管道的手写实现是整条路线里性价比最高的一课。你需要亲手处理的事情包括文本的分词与编码、数值的归一化、批次的拼接与填充、以及最容易被忽视的——异常数据的过滤。拿文本处理举例一个最小可用的管道大概长这样class SimpleTextPipeline: def __init__(self, vocab, max_len128): self.vocab vocab self.max_len max_len def encode(self, text): tokens text.strip().split() ids [self.vocab.get(t, self.vocab[unk]) for t in tokens] if len(ids) self.max_len: ids ids[:self.max_len] else: ids ids [self.vocab[pad]] * (self.max_len - len(ids)) return ids def batch(self, texts): return [self.encode(t) for t in texts]这段代码简单到不能再简单但它逼你面对几个关键问题词表外的词怎么处理、超长文本是截断还是分块、填充位放在前面还是后面。这些问题在框架里往往是一个参数就解决了但你不亲手写一遍就不知道这个参数背后到底发生了什么。注意填充位置的选择会影响模型对序列的理解。左填充在某些生成任务里会导致模型把填充位当成有效输入右填充则相对安全但具体还要看你的模型结构。3.2 模型前向与反向把黑盒拆开看模型这一层我的建议是先手写一个极简的全连接网络把前向传播和反向传播的每一步都算清楚。不用追求性能追求的是理解。你可以用NumPy实现一个两层网络手动计算梯度然后和PyTorch的自动求导结果对比验证自己的理解是否正确。这个过程中你会真正搞明白几件事学习率为什么不能太大、梯度消失是怎么发生的、batch size对梯度估计的影响。这些概念在教科书上都有但只有你自己算过一遍才会有直觉。我当年就是手写了一遍反向传播之后才真正理解为什么ReLU能缓解梯度消失——因为它的导数在正区间恒为1不会像Sigmoid那样在饱和区把梯度压没。等你对这套机制有了感觉再切换到PyTorch就会非常顺畅因为你知道loss.backward()背后到底在算什么optimizer.step()又改了什么。3.3 推理服务从脚本到接口的跨越把训练好的模型变成一个能对外服务的接口这一步是很多人从“学习者”变成“工程师”的分水岭。脚本里你可以慢慢跑但服务里你要考虑并发、超时、资源占用、错误处理。一个最小可用的推理服务核心是把模型加载和请求处理分开from fastapi import FastAPI import torch app FastAPI() model None app.on_event(startup) def load_model(): global model model torch.load(model.pt, map_locationcpu) model.eval() app.post(/predict) def predict(text: str): with torch.no_grad(): inputs preprocess(text) outputs model(inputs) return {result: postprocess(outputs)}这段代码看起来简单但里面藏着几个关键决策模型在启动时加载而不是每次请求加载、推理时关闭梯度计算、输入输出都要做预处理和后处理。每一条都是踩过坑之后总结出来的。比如不在启动时加载模型每个请求都重新加载一遍那延迟直接爆炸不关梯度计算显存占用会莫名其妙地涨。3.4 工程化收尾让服务真正能扛事到了工程层你要处理的就是那些“Demo阶段永远不会遇到”的问题请求排队、缓存命中、异常降级、日志追踪。我自己的做法是先加一层简单的请求队列用asyncio.Queue控制并发量避免请求把服务打挂然后对高频输入加一层内存缓存命中就直接返回最后给每个请求打上唯一ID方便出问题时追踪整条链路。这些措施单独看都不复杂但组合起来就能让服务的稳定性上一个台阶。我实测下来加了一层队列和缓存之后同样的硬件配置下服务的有效吞吐能提升三到五倍而且延迟曲线会平稳很多。4. 完整实操流程与关键参数记录4.1 环境准备与依赖管理动手之前先把环境理清楚这一步别偷懒。我的习惯是用conda建一个独立环境然后手动装依赖而不是直接pip install -r requirements.txt因为后者容易把版本搞乱。conda create -n ai-eng python3.10 conda activate ai-eng pip install numpy torch fastapi uvicorn版本上我建议Python用3.10PyTorch用2.x这两个组合目前最稳。NumPy注意别装太新的版本有些老代码对NumPy 2.0的API变更不兼容遇到报错先检查版本。提示如果你在M系列芯片的机器上跑PyTorch要装对应的版本否则会用CPU跑速度差很多。装完之后用torch.backends.mps.is_available()确认一下。4.2 数据准备与预处理实操数据这块我建议先用一个小规模的真实数据集跑通全流程别一上来就搞几百G的数据。我常用的是一个几万条文本的分类数据集足够验证整条链路。预处理的关键参数有这么几个我列个表方便对照参数建议值说明max_len128覆盖大多数样本超长截断batch_size32训练时用推理时可调大vocab_size30000词表大小太小会丢信息pad_token0填充位ID注意和真实词区分这些值不是拍脑袋定的max_len要看你的数据分布我一般会统计一下样本长度的分位数取95分位左右batch_size要看显存训练时从小往大试找到不爆显存的最大值。4.3 模型训练与验证的完整流程训练流程我习惯写成脚本参数用命令行传入方便复现import argparse import torch from torch.utils.data import DataLoader def train(args): model build_model(args) optimizer torch.optim.Adam(model.parameters(), lrargs.lr) loader DataLoader(dataset, batch_sizeargs.batch_size, shuffleTrue) for epoch in range(args.epochs): for batch in loader: optimizer.zero_grad() loss compute_loss(model, batch) loss.backward() optimizer.step() validate(model)这里有几个实操细节值得说optimizer.zero_grad()一定要在backward()之前调用否则梯度会累加验证集要单独跑别和训练混在一起每个epoch结束存一次checkpoint防止训练中断前功尽弃。4.4 服务部署与压测记录服务写完之后用uvicorn起起来然后用ab或者wrk做个简单压测看看QPS和延迟。我自己的记录是单核CPU、模型参数量在百万级别的情况下不做任何优化大概能跑到几十QPS加批处理之后能到几百。这个数字因模型而异但压测这一步不能省因为你永远不知道瓶颈在哪直到你真正压它。压测时重点看两个指标P99延迟和错误率。平均延迟好看但P99很高说明有长尾请求可能是某些输入触发了慢路径错误率不为零说明有边界情况没处理到。5. 常见问题排查与避坑经验实录5.1 训练不收敛的排查顺序训练不收敛是最常见的问题我的排查顺序是这样的先看数据、再看模型、最后看超参。数据方面检查标签有没有错、输入有没有异常值模型方面检查维度对不对、激活函数有没有用错超参方面先调学习率从1e-3往下试。有个很隐蔽的坑是数据泄漏就是验证集的数据不小心混进了训练集导致验证指标虚高。排查方法是把训练集和验证集的ID做个交集看看有没有重叠。5.2 推理延迟突然飙升的处理线上服务延迟飙升我遇到过几次原因各不相同。有一次是缓存失效导致所有请求都打到模型上有一次是某个长输入触发了OOM导致服务重启。排查思路是先看监控确认是整体变慢还是个别请求变慢然后看日志找到慢请求的特征最后复现定位到具体代码。注意服务重启会导致正在处理的请求全部失败所以一定要加优雅关闭等当前请求处理完再退出。5.3 显存不足的几种解法显存不足是训练和推理都会遇到的问题。解法按优先级排先减小batch size再考虑梯度累积最后才是模型量化。梯度累积是用时间换空间把大batch拆成小batch跑多次再更新效果等价但更省显存。量化则是把参数从float32降到float16甚至int8能省一半到四分之三的显存但可能损失一点精度。5.4 常见问题速查表现象可能原因排查方向loss不下降学习率过大/过小调整lr画loss曲线验证指标虚高数据泄漏检查训练验证集重叠推理延迟高无批处理/缓存失效加批处理检查缓存显存OOMbatch过大/未释放减小batch检查梯度服务频繁重启内存泄漏/异常未捕获看日志加异常处理这张表是我自己踩坑之后整理的遇到问题先对照着看能省不少时间。6. 从能跑到能扛工程能力的进阶方向把上面这套流程走通之后你手里就有了一个能跑、能调、能排查的最小AI工程系统。接下来往哪个方向深入取决于你的实际场景。如果是做在线服务重点补并发处理和资源调度如果是做离线批处理重点补数据管道的吞吐优化如果是做模型迭代重点补实验管理和版本控制。我自己的体会是AI工程的难点从来不在模型本身而在模型之外的那一整套支撑体系。模型可以换、可以调但数据管道、服务框架、监控体系这些东西一旦搭好就是长期复用的资产。所以别急着追新模型先把这套地基打牢后面换什么模型都是水到渠成的事。最后分享一个我一直在用的小技巧给每个环节都写一个最小验证脚本。数据管道写完写个脚本验证输入输出模型写完写个脚本验证前向反向服务写完写个脚本验证接口。这些脚本平时看着不起眼但出问题时它们就是你最快的定位工具。我现在的习惯是每加一个新功能先写验证脚本再写实现这样能逼着自己把接口想清楚也能在实现出问题时快速判断是哪个环节的锅。