1. 从零手搓AI工程为什么我不建议你直接调包1.1 一个让我彻底改变主意的真实场景去年帮一个朋友排查线上推理服务的问题现象很典型模型在测试集上指标漂亮得不行一上生产环境延迟直接飙到800毫秒QPS连50都扛不住。团队里几个小伙子围着代码看了两天从模型结构查到数据预处理愣是没找到瓶颈。最后我让他们把推理链路拆开逐段打点发现真正的问题出在输入文本的tokenize环节——他们用的那个分词器每次调用都会重新加载词表文件单次耗时就有十几毫秒并发一上来直接把IO打满了。这个事让我感触特别深。现在市面上讲AI工程的内容绝大多数都在教你怎么调API、怎么用现成的框架搭个demo但真正到了生产环境决定系统能不能扛住的往往不是模型本身而是那些看起来不起眼的工程细节。ai-engineering-from-scratch这个项目标题之所以吸引我就是因为它强调“from scratch”——从零开始不依赖黑盒把每一个环节都掰开揉碎了理解。这篇文章适合谁看如果你已经会用PyTorch或TensorFlow跑通几个demo但对模型怎么变成线上服务、推理怎么优化、工程上哪些地方容易踩坑还比较模糊那接下来的内容应该能帮你少走不少弯路。如果你是完全零基础也没关系我会尽量用生活化的类比把原理讲清楚保证你能跟上思路。1.2 从零构建到底“零”在哪里很多人对“from scratch”的理解有偏差以为是要自己手写矩阵乘法、自己实现反向传播。其实在AI工程这个语境下从零构建的核心含义是不依赖高度封装的端到端框架而是用相对底层的工具把整个链路搭起来。具体来说包括但不限于这几个层面数据处理层自己写数据加载、清洗、分词的逻辑而不是直接调datasets.load_dataset()就完事模型训练层理解优化器、学习率调度、梯度累积这些机制怎么配合而不是把参数往Trainer里一塞推理服务层自己实现批处理、缓存、并发控制而不是套一个现成的serving框架监控运维层自己埋点、自己算指标、自己设计告警阈值这么做的价值在哪里我举个例子你就明白了。假设你用现成的框架部署了一个服务某天突然发现吞吐量上不去了。如果你对底层链路一无所知就只能去翻框架文档、提issue、等社区回复。但如果你是从零搭起来的你清楚地知道每一个请求经过了哪些环节、每个环节的耗时大概是多少、瓶颈可能出现在哪里排查效率完全不是一个量级。我个人的经验是从零构建一遍之后再用任何框架你都会有一种“透视”的感觉知道它帮你做了什么、哪些地方可能成为隐患。2. 核心链路的拆解与设计思路2.1 整体架构把大象放进冰箱分几步AI工程说到底就是一条流水线数据进来经过处理喂给模型模型吐出结果结果再经过后处理返回给调用方。听起来简单但每个环节都有讲究。我习惯把整条链路拆成五个阶段来设计阶段核心任务常见坑点数据接入读取原始数据、格式统一编码问题、字段缺失、脏数据预处理分词、截断、padding分词器加载慢、截断策略不合理模型推理前向计算、批处理显存溢出、batch size设置不当后处理解码、格式化、过滤解码逻辑与训练不一致服务封装接口暴露、并发控制线程安全、超时设置这个拆法看起来平平无奇但关键在于每个阶段的边界要清晰阶段之间的数据格式要约定好。我见过太多项目把预处理和推理揉在一起写结果想换个分词器就得动模型代码想加个后处理逻辑又得改服务层牵一发而动全身。设计思路上我倾向于“管道插件”的模式。主管道负责串联各个阶段每个阶段的具体实现做成可替换的插件。比如预处理阶段今天用A分词器明天想换成B只需要实现同样的接口然后替换掉就行主管道代码一行不用改。这种设计在项目初期可能显得有点过度工程但等到需求一变你就会感谢自己当初多写的那些抽象层。2.2 工具选型为什么我最终选了这几个工具选型这件事没有绝对的对错只有适不适合。我把自己在从零构建AI工程时常用的工具列一下并说明选择理由数据处理用Pandas NumPy的组合。有人会问数据量大了Pandas不是会爆内存吗确实但我的策略是小规模数据用Pandas快速验证逻辑大规模数据再切换到PyArrow或者自己写流式处理。一开始就上重型工具反而拖慢开发节奏。模型训练用PyTorch。这个选择比较个人化主要是PyTorch的动态图机制在调试时更直观想看中间变量随时可以print不像静态图那样需要先编译再运行。而且PyTorch的生态现在也很成熟了各种优化工具都能找到。推理服务用FastAPI。Flask当然也能用但FastAPI原生支持异步、自带请求校验、自动生成接口文档对于AI服务这种经常需要处理并发请求的场景来说省了不少事。而且它的性能在Python的Web框架里算是第一梯队的。监控用Prometheus Grafana。这套组合在传统后端领域已经很成熟了直接拿过来用就行。关键是要想清楚埋哪些指标请求量、延迟分布、错误率、GPU利用率、显存占用这几个是最基本的。选型的一个原则不要为了用新技术而用新技术。每引入一个工具都要问自己它解决了什么现有工具解决不了的问题如果答案不清晰那就先别引入。2.3 目录结构代码怎么放才不乱从零构建的项目目录结构一定要提前规划好否则写到后面就是一团乱麻。我常用的结构是这样的project/ ├── configs/ # 配置文件 ├── data/ # 数据相关 │ ├── raw/ # 原始数据 │ ├── processed/ # 处理后的数据 │ └── loader.py # 数据加载逻辑 ├── models/ # 模型定义 ├── preprocessing/ # 预处理模块 ├── postprocessing/ # 后处理模块 ├── serving/ # 服务层 │ ├── app.py # 接口定义 │ └── middleware.py # 中间件 ├── monitoring/ # 监控埋点 ├── utils/ # 通用工具 └── tests/ # 测试用例这个结构的好处是职责分明。想找数据处理的代码就去data/想改服务接口就去serving/不用在几百个文件里翻来翻去。而且这种结构天然适合多人协作每个人负责一个目录冲突概率大大降低。3. 关键环节的实操细节与避坑指南3.1 数据预处理那些文档里不会写的细节数据预处理是整个链路里最不起眼但最容易出问题的环节。我踩过的坑包括但不限于文本里有不可见字符导致分词结果异常、数字被错误地当成特殊token处理、超长文本截断后语义完全变了。先说分词器的加载。很多教程会告诉你tokenizer AutoTokenizer.from_pretrained(xxx)就完事了但在生产环境里这行代码每次调用都会去读磁盘上的词表文件。正确的做法是在服务启动时加载一次然后全局复用。如果用的是多进程部署每个进程加载一份不要在每个请求里重新加载。# 错误做法每次请求都加载 def process(text): tokenizer AutoTokenizer.from_pretrained(bert-base) return tokenizer.encode(text) # 正确做法全局加载一次 tokenizer AutoTokenizer.from_pretrained(bert-base) def process(text): return tokenizer.encode(text)再说截断策略。大部分模型的输入长度是有限制的比如512个token。超出的部分怎么处理直接截断尾部是最简单的但可能会丢失关键信息。我的做法是先按句子切分然后从后往前逐句丢弃直到长度符合要求。这样至少保证不会把一个完整的句子拦腰截断。还有一个细节是padding。训练时通常需要统一长度但推理时其实不需要。如果推理时也做padding会浪费计算资源。我见过一个服务明明每次只输入十几个token但因为设置了固定长度512每次都要算512个位置延迟直接翻了好几倍。3.2 模型推理批处理与显存的平衡术推理环节最核心的优化手段就是批处理。单条推理和批量推理的吞吐量差距可能是十倍甚至几十倍。但batch size不是越大越好受限于显存容量而且太大的batch会导致单次延迟升高。我的经验是先测出单条推理的显存占用然后根据可用显存算出理论最大batch size再取这个值的60%到70%作为实际使用值留出余量应对峰值。比如单条推理占用200MB显存可用显存8GB理论最大batch是40那实际就用24到28左右。# 动态批处理的简化逻辑 def dynamic_batch(requests, max_batch_size, max_wait_time): batch [] start_time time.time() while requests or batch: if requests and len(batch) max_batch_size: batch.append(requests.pop(0)) elif time.time() - start_time max_wait_time or not requests: yield batch batch [] start_time time.time()这段逻辑的意思是攒够max_batch_size就发车或者等超过max_wait_time也发车避免请求被无限期挂起。max_wait_time的设置很关键设太小了batch攒不起来设太大了延迟又太高。一般设置在10到50毫秒之间具体看业务对延迟的敏感程度。还有一个容易忽略的点是推理时的内存碎片。PyTorch的缓存分配器有时候会留下碎片导致明明显存够用却报OOM。解决办法是定期调用torch.cuda.empty_cache()但注意这个操作本身有开销不要频繁调用。我的做法是在batch之间调用而不是每个请求都调。3.3 服务封装并发下的线程安全问题服务层最容易出的问题是并发。Python的GIL让很多人以为多线程没用但实际上IO密集型的操作比如读文件、网络请求在多线程下还是能并发的。问题在于如果你的代码里有共享状态比如一个全局的缓存字典多线程同时读写就会出问题。import threading class SafeCache: def __init__(self): self._cache {} self._lock threading.Lock() def get(self, key): with self._lock: return self._cache.get(key) def set(self, key, value): with self._lock: self._cache[key] value加锁是最简单的解决方案但锁的粒度要控制好。如果整个推理过程都加锁那就变成串行了并发能力直接归零。正确的做法是只对共享数据的读写加锁推理计算本身不需要锁。超时设置也是服务层的必修课。一个请求进来如果模型推理卡住了不能让它无限期占用资源。我通常会在服务层设置两级超时单次推理的超时和整个请求的超时。单次推理超时设短一点比如5秒触发后直接返回错误整个请求超时设长一点比如30秒给重试留出空间。4. 性能调优与问题排查实战4.1 延迟优化从800毫秒到80毫秒的完整记录回到开头那个案例我详细记录一下优化过程供你参考。第一步定位瓶颈。在推理链路的每个环节打上时间戳记录耗时。发现tokenize占了600多毫秒推理本身只占100多毫秒后处理占几十毫秒。第二步分析原因。查看tokenize的代码发现每次调用都重新加载词表。词表文件有几十MB从磁盘读取加上解析单次就是几百毫秒。第三步实施优化。把词表加载移到服务启动时全局只加载一次。修改后tokenize耗时降到几毫秒。第四步验证效果。重新压测P99延迟从800多毫秒降到80毫秒左右QPS从不到50提升到400多。这个案例的教训是不要假设你知道瓶颈在哪里一定要用数据说话。我见过太多人凭直觉优化结果改了一堆地方性能纹丝不动。4.2 常见问题速查表现象可能原因排查方法解决方案延迟突然升高显存不足导致频繁GC查看GPU显存占用曲线减小batch size或清理缓存吞吐量上不去批处理未生效检查batch size实际值调整动态批处理参数结果不稳定并发下的数据竞争检查共享变量加锁或改用线程安全结构服务启动慢模型加载耗时打点记录加载时间使用更快的序列化格式内存持续增长缓存未清理监控内存曲线设置缓存过期策略4.3 监控埋点看不见的指标等于不存在监控这件事我的原则是宁可多埋不可漏埋。多埋了顶多浪费一点存储漏埋了出问题的时候就是两眼一抹黑。必埋的指标包括请求维度总请求数、成功数、失败数、各错误码分布延迟维度P50、P90、P99、最大值资源维度CPU利用率、内存占用、GPU利用率、显存占用业务维度输入长度分布、输出长度分布、特殊case占比埋点的方式我推荐用装饰器这样对业务代码侵入最小import time from functools import wraps def monitor(func): wraps(func) def wrapper(*args, **kwargs): start time.time() try: result func(*args, **kwargs) status success return result except Exception as e: status error raise finally: duration time.time() - start record_metric(func.__name__, duration, status) return wrapper埋点的一个小技巧记录延迟的时候不要只记平均值平均值会掩盖长尾问题。P99才是真正影响用户体验的指标。5. 从零构建的长期价值与扩展方向5.1 为什么我坚持每个项目都从零搭一遍有人觉得从零构建是重复造轮子浪费时间。我的看法恰恰相反从零构建是最高效的学习方式也是构建真正可靠系统的前提。当你用现成框架的时候你学到的是“怎么用这个框架”。当你从零构建的时候你学到的是“这个系统是怎么工作的”。前者会随着框架的更新换代而贬值后者是能跟你一辈子的底层能力。而且从零构建的项目你对每一行代码都有掌控力。出了问题能快速定位想加功能能灵活扩展想优化性能知道从哪里下手。这种掌控感是调包永远给不了的。5.2 后续可以怎么扩展这套从零构建的框架搭好之后扩展方向其实很多模型层面可以接入不同的模型对比效果和性能量化压缩引入INT8量化进一步降低显存占用和延迟分布式推理把模型切分到多张卡上支持更大的模型A/B测试同时部署多个版本根据流量分配对比效果自动扩缩容根据负载动态调整实例数量每一个方向都够写一篇独立的文章但核心思路是一样的先理解原理再动手实现最后用数据验证效果。我个人在实际操作中的体会是从零构建最大的收获不是某个具体的技能而是一种思维方式——遇到问题不慌知道怎么拆解、怎么定位、怎么解决。这种思维方式比任何框架和工具都值钱。