从零搭建AI工程体系：架构设计、数据管道与模型服务实战

1. 从零搭建AI工程体系，为什么我劝你别一上来就调包

"ai-engineering-from-scratch"这个标题，第一次看到的时候我愣了一下。市面上讲AI的文章，十篇里有八篇在教你pip install几个库，然后调个API就宣称自己"搞定了AI工程"。但真正在生产环境里趟过坑的人都知道，从零构建一套AI工程体系，跟调包跑个demo之间，隔着的不是几行代码，而是一整套思维方式的转变。

我自己是从传统后端转过来的，头两年做AI项目基本就是"能跑就行"的状态——模型加载进来，接口包一层，返回结果就完事。直到有一次线上推理服务在高峰期直接雪崩，排查了整整两天才发现是预处理环节的tokenizer在多线程下出现了资源竞争。那次之后我才真正意识到，AI工程不是"把模型跑起来"，而是要把数据管道、模型服务、监控告警、版本管理这一整套东西从地基开始搭稳。

这篇内容适合几类人看：一是刚入行AI方向、还没被生产环境毒打过的工程师；二是从其他技术栈转过来、想系统理解AI工程全貌的开发者；三是带团队做AI产品、需要判断技术方案合理性的技术负责人。我会把从零搭建AI工程体系的核心环节拆开讲，包括整体架构怎么设计、数据管道怎么搭、模型服务怎么做、监控怎么做，以及那些只有踩过坑才知道的细节。不堆概念，只讲能落地的东西。

2. 整体架构设计：先想清楚数据怎么流，再想模型怎么跑

2.1 为什么"从零"反而是一种优势

很多人觉得从零搭建是劣势，什么都得自己写。但我的实际经验恰恰相反——从零开始意味着你对每一层都有完全的控制权，不会出现"这个框架封装太深、出了问题根本查不到"的情况。

举个具体的例子。用现成的推理框架部署模型，表面上很省事，但一旦遇到性能瓶颈，你面对的是一个黑盒。你不知道请求在框架内部经过了哪些队列、哪些线程池、哪些内存拷贝。而如果你从零搭建，哪怕只是用一个简单的HTTP服务包一个模型，你至少清楚每一个环节发生了什么，优化的时候知道该动哪里。

从零搭建的另一个好处是，你对技术选型的理解会深刻得多。当你自己实现过一个简易的批处理调度器之后，再用vLLM或者TGI这类框架，你就能理解它们到底在优化什么，参数该怎么调，而不是照着文档瞎填。

当然，从零不等于什么都自己造轮子。我的原则是：核心链路的每一层都要能自己实现一遍以理解原理，但生产环境该用成熟方案就用成熟方案。理解原理是为了在出问题时能定位，用成熟方案是为了效率和稳定性。

2.2 分层架构的核心思路

一套完整的AI工程体系，我习惯把它分成五层来看：

这个分层不是拍脑袋定的，而是按照"数据流向"来划分的。数据从底层往上流，每一层只关心自己的职责，层与层之间通过明确的接口通信。这样做的好处是，任何一层出问题，影响范围是可控的，替换某一层的实现也不会牵一发而动全身。

我见过太多项目把数据处理、模型推理、业务逻辑全揉在一个服务里，结果就是改一个Prompt模板都要重新部署整个服务，数据清洗的逻辑和推理的逻辑耦合在一起，测试都没法写。分层不是为了好看，是为了让每一部分都能独立演进。

2.3 技术选型的取舍逻辑

选型这件事，我的核心原则是：优先选你能hold住的，而不是最火的。

拿推理服务来说，市面上有vLLM、TGI、TensorRT-LLM、Ollama等等。如果你团队里没人懂CUDA底层，那TensorRT-LLM的编译优化对你来说就是灾难。vLLM的PagedAttention确实香，但如果你连KV Cache是什么都说不清楚，出了问题只能干瞪眼。

我的建议是分阶段来：

• 第一阶段（验证期）：用最简单的方案，比如FastAPI包一个模型，先把链路跑通，理解请求从进入到返回的完整流程。
• 第二阶段（优化期）：引入批处理、缓存、异步处理，自己实现一个简易的调度器，理解吞吐量和延迟之间的权衡。
• 第三阶段（生产期）：根据实际瓶颈选择成熟框架，这时候你已经知道该关注哪些指标了。

数据库选型也是同理。向量数据库有Milvus、Qdrant、Weaviate、pgvector等等。如果数据量在百万级别以下，pgvector完全够用，而且省去了维护一套独立系统的成本。别一上来就上分布式向量数据库，运维成本会教你做人。

3. 数据管道搭建：AI工程里最容易被低估的环节

3.1 数据管道的核心职责

数据管道在AI工程里的地位，怎么强调都不过分。我甚至可以说，一个AI项目的成败，七成取决于数据管道，三成才是模型本身。

数据管道要干的事包括：数据采集、格式统一、去重、清洗、分块、向量化、存储、更新。每一个环节都有坑。

先说格式统一。原始数据可能来自各种来源——网页、PDF、数据库、API返回的JSON。这些数据的结构千差万别，你得先统一成一种内部格式。我习惯用JSONL作为中间格式，每行一条记录，包含id、content、metadata三个字段。简单、通用、好处理。

去重这件事比想象中复杂。简单的完全匹配去重只能去掉一模一样的文本，但实际数据里大量存在"近似重复"——比如同一篇文章的不同版本、同一问题的不同表述。这时候就需要用MinHash或者SimHash这类近似去重算法。我的经验是，去重阈值设在0.85到0.9之间比较合适，太低会误删有用数据，太高又去不干净。

3.2 分块策略：决定检索质量的关键

分块（chunking）是RAG系统里最关键的环节之一，但很多人随便按固定长度切一切就完事了。实际上分块策略直接决定了检索质量。

我试过几种分块方式，各有适用场景：

• 固定长度分块：按token数或字符数切，简单粗暴。适合结构规整的文本，比如日志、代码。但容易把一句话切断，导致语义不完整。
• 递归分块：按段落、句子、短语的层级递归切分，尽量保持语义完整。适合文章、文档类内容。LangChain的RecursiveCharacterTextSplitter就是这个思路。
• 语义分块：用embedding计算相邻句子的相似度，在相似度骤降的地方切分。效果最好，但计算成本高。
• 结构化分块：按文档本身的结构切，比如Markdown按标题切、代码按函数切。适合有明确结构的内容。

我的实际做法是混合策略：先按文档结构切大块，再在大块内部按语义或递归方式切小块。块大小控制在256到512个token之间，块与块之间保留10%到20%的重叠，避免边界信息丢失。

注意：分块大小没有万能值。短查询为主的场景，块可以小一点（256 token）；需要长上下文理解的场景，块要大一点（512到1024 token）。一定要根据实际检索效果来调。

3.3 向量化与索引构建

向量化这一步，核心是选embedding模型。选型时关注三个维度：效果、速度、维度。

效果方面，可以看MTEB榜单，但别迷信榜单。榜单上的高分模型在你的领域数据上不一定好。我的做法是，拿一批真实查询和对应文档，人工标注相关性，然后测几个候选模型的召回率。这个工作量不大，但能避免选错模型。

速度方面，如果数据量大，embedding的生成速度会成为瓶颈。可以考虑用GPU加速，或者用ONNX Runtime做推理优化。批量处理比逐条处理快得多，batch size设到32或64通常能跑满GPU。

维度方面，维度越高表达能力越强，但存储和检索成本也越高。768维和1024维在实际效果上差距不大，但存储成本差不少。我的建议是，除非有明确的性能需求，否则768维是个不错的平衡点。

索引构建这块，如果数据量不大（百万级以下），用HNSW索引就够了，召回率和速度都不错。数据量再大，就得考虑IVF或者量化索引了。索引参数（比如HNSW的M和efConstruction）需要根据实际数据调，没有万能值。

3.4 数据更新的处理

数据更新是很多人忽略的问题。实际业务里，数据是不断变化的——新文档要加进来，旧文档要删除，已有文档要修改。

全量重建索引最简单，但数据量大时耗时太长。增量更新是更好的方案，但实现起来复杂。我的做法是：

• 新文档直接插入索引，同时记录插入时间。
• 删除文档用软删除，标记为已删除，检索时过滤掉。
• 修改文档当作"删除+插入"处理。

定期（比如每周）做一次全量重建，清理掉软删除的数据，重新平衡索引结构。这样既保证了更新的实时性，又避免了索引碎片化。

4. 模型服务化：从能跑到跑得稳的距离

4.1 推理服务的核心挑战

把模型跑起来不难，难的是在高并发下稳定运行。推理服务面临的核心挑战有三个：延迟、吞吐量、资源利用率。

延迟和吞吐量是一对矛盾。单条请求处理延迟低，但吞吐量上不去；批处理吞吐量高，但单条延迟会增加。怎么平衡，取决于业务场景。如果是实时对话，延迟优先；如果是离线批量处理，吞吐量优先。

资源利用率是另一个问题。GPU很贵，如果利用率上不去，成本就下不来。提高利用率的手段包括：动态批处理、请求排队、模型量化、KV Cache复用等等。

4.2 动态批处理的实现思路

动态批处理是提升吞吐量最有效的手段之一。核心思想是：不立即处理每个请求，而是等一小段时间（比如10毫秒），把这段时间内到达的请求攒成一批一起处理。

实现上，需要一个请求队列和一个调度循环。调度循环不断从队列里取请求，攒够一批或者等待超时，就调用模型推理。推理完成后，把结果分发给对应的请求。

这里有个关键参数：最大等待时间。设得太短，攒不到足够的请求，吞吐量上不去；设得太长，延迟增加，用户体验变差。我的经验值是10到50毫秒，具体看业务对延迟的容忍度。

还有一个参数是最大批大小。批太大，显存可能不够；批太小，吞吐量上不去。这个要根据模型大小和显存容量来算。粗略估算：批大小乘以单条请求的显存占用，不能超过可用显存的80%。

4.3 模型量化与加速

模型量化是降低推理成本的重要手段。常见的量化方案有：

• FP16：半精度，显存减半，效果几乎无损。基本是标配。
• INT8：8位整数，显存再减半，效果略有下降。适合对效果要求不那么极致的场景。
• INT4：4位整数，显存进一步降低，效果下降明显。适合显存极度受限的场景。

量化的实现方式有PTQ（训练后量化）和QAT（量化感知训练）。PTQ简单，直接对训练好的模型做量化，但效果可能下降较多。QAT在训练时就模拟量化，效果更好，但需要重新训练。

我的建议是，优先用FP16，如果显存不够再考虑INT8。INT4除非万不得已，否则别用，效果下降太明显。

除了量化，还有KV Cache优化、Flash Attention、连续批处理等技术，都能显著提升推理效率。这些技术的原理值得单独写一篇，这里不展开。

4.4 服务的高可用设计

生产环境的推理服务，高可用是必须的。核心手段包括：

• 多副本部署：至少两个副本，避免单点故障。
• 健康检查：定期检查服务状态，不健康的副本自动摘除。
• 优雅降级：过载时返回简化结果或排队提示，而不是直接报错。
• 限流熔断：防止突发流量打垮服务。

我踩过的一个坑是：健康检查只检查了HTTP端口是否响应，没检查模型是否真的能推理。结果有一次模型加载失败，但HTTP服务正常，健康检查通过了，流量全打到这个坏副本上，用户全部报错。后来改成健康检查里实际跑一次推理，才解决了这个问题。

5. 监控与可观测性：看不见的问题最致命

5.1 监控体系的三个支柱

AI工程的监控，比传统后端监控要复杂。除了常规的CPU、内存、网络指标，还要监控模型相关的指标。我把它分成三类：

• 系统指标：CPU、内存、GPU利用率、显存占用、网络IO。这些是基础，用Prometheus + Grafana就能搞定。
• 业务指标：QPS、延迟分布（P50、P95、P99）、错误率、超时率。这些反映服务质量。
• 模型指标：推理延迟、批大小分布、缓存命中率、输出长度分布。这些反映模型服务的健康度。

这三类指标缺一不可。只看系统指标，你不知道业务表现如何；只看业务指标，出了问题不知道是哪里卡的；不看模型指标，你不知道模型服务本身有没有异常。

5.2 日志与追踪

日志是排查问题的第一手资料。AI服务的日志要记录：请求ID、输入摘要、输出摘要、耗时、模型版本、错误信息。

请求ID特别重要，它能把一次请求在多个服务间的日志串起来。我习惯用UUID作为请求ID，在请求入口生成，一路透传下去。

追踪（tracing）比日志更高级，能可视化请求的完整调用链。OpenTelemetry是目前的通用方案，支持多种语言和框架。接入成本不高，但排查复杂问题时价值巨大。

注意：日志里不要记录完整的用户输入和模型输出，涉及隐私。记录摘要或哈希值即可。这个坑我踩过，后来花了很大力气做数据清理。

5.3 告警策略的设计

告警不是越多越好，太多告警会导致"告警疲劳"，真正重要的问题反而被忽略。我的告警设计原则是：

• 只对可行动的问题告警：收到告警后知道该做什么，否则不告警。
• 分级告警：P0（立即处理）、P1（当天处理）、P2（本周处理）。
• 设置合理的阈值和持续时间：避免瞬时抖动触发告警。比如错误率超过5%持续5分钟才告警。

常见的告警项包括：错误率突增、延迟P99超过阈值、GPU利用率持续过高或过低、显存接近上限、队列积压等等。

5.4 常见问题排查速查表

这张表是我自己排查问题时总结的，实际遇到问题时按这个顺序查，能省不少时间。

6. 实操心得与避坑指南

6.1 那些只有踩过才知道的坑

坑一：tokenizer不是线程安全的。很多tokenizer库在多线程下会有资源竞争问题。解决方案是每个线程一个tokenizer实例，或者加锁。我当初就是栽在这上面，线上服务跑着跑着就卡死。

坑二：GPU显存碎片化。长时间运行的服务，显存会逐渐碎片化，最终导致明明有足够显存却分配失败。解决方案是定期重启服务，或者用显存池化管理。

坑三：批处理不等于越快越好。批处理会增加单条请求的延迟。如果业务对延迟敏感，批处理窗口要设得很小，甚至不用批处理。我见过为了追求吞吐量把批处理窗口设到500毫秒的，用户体验极差。

坑四：模型版本管理混乱。没有版本管理，出了问题不知道回滚到哪个版本。解决方案是用模型注册表，每次部署记录版本号和对应的配置。

坑五：忽略冷启动。服务重启后，第一批请求会特别慢，因为模型要加载、缓存要预热。解决方案是启动时做预热，跑几条假请求把缓存填上。

6.2 性能优化的优先级

性能优化要有优先级，别上来就抠细节。我的优先级排序是：

1. 先解决瓶颈：用profiling工具找到真正的瓶颈，别凭感觉优化。
2. 再优化架构：架构层面的优化收益最大，比如加缓存、改批处理策略。
3. 然后调参数：批大小、超时时间、线程数这些参数调优。
4. 最后抠代码：代码层面的微优化收益最小，放在最后。

我见过太多人一上来就优化代码，结果瓶颈根本不在代码上，白费功夫。

6.3 团队协作的注意事项

AI工程不是一个人的事，团队协作有几个点要注意：

• 接口先行：层与层之间的接口先定义好，各自并行开发。
• 配置外置：所有配置项外置，不同环境用不同配置，别硬编码。
• 文档同步：架构变更、接口变更及时更新文档，别让文档变成摆设。
• 代码评审：AI代码也要评审，特别是数据处理和模型推理部分，容易出隐蔽的bug。

6.4 持续迭代的思路

AI工程体系不是搭完就完事了，要持续迭代。迭代的方向包括：

• 效果迭代：换更好的模型、优化Prompt、改进检索策略。
• 性能迭代：优化推理速度、降低延迟、提升吞吐量。
• 成本迭代：量化模型、优化资源调度、降低单位请求成本。
• 稳定性迭代：完善监控、优化告警、提升容错能力。

迭代要有数据支撑，别拍脑袋。每次迭代前定义好指标，迭代后对比指标，用数据说话。

7. 从零搭建的完整流程回顾

把整个流程串一遍，从零搭建AI工程体系的步骤大致是：

1. 需求分析：明确业务场景、性能要求、成本预算。
2. 架构设计：分层设计，定义层间接口。
3. 数据管道搭建：采集、清洗、分块、向量化、索引。
4. 模型服务搭建：推理服务、批处理、缓存、高可用。
5. 监控体系搭建：指标、日志、追踪、告警。
6. 测试与调优：功能测试、性能测试、参数调优。
7. 上线与迭代：灰度发布、监控观察、持续迭代。

每一步都有细节，都有坑。但只要你理解了每一层在干什么、为什么这么干，遇到问题就能定位、能解决。

我自己走完这一整套流程，花了大概半年时间，中间踩了无数坑。但现在回头看，这些坑都是值得的。因为踩过之后，你对整个系统的理解是调包调不出来的。你知道每个环节的边界在哪里，知道什么情况下会出问题，知道怎么优化。

最后分享一个我个人的习惯：每搭完一个环节，我都会写一份"如果这个环节挂了，会怎样"的分析。这个习惯帮我提前发现了很多单点故障，也让我对系统的整体可靠性有了更清晰的认知。从零搭建AI工程，技术是一方面，更重要的是这种系统性的思考方式。