从标题“ai-engineering-from-scratch”展开这篇文章核心讲的是“AI工程化落地”这件事。如果你所在的技术团队最近被AI项目砸中又或者你个人想从普通后端/算法工程师切换到AI应用方向那这个话题基本绕不过去。更重要的是标题里的“from-scratch”很诚实——绝大多数团队不是从成熟的MLOps平台起步而是从零散的业务场景、临时脚本、甚至几个实验性的Prompt开始摸索AI工程的。这篇文章就以一个真实从业者的视角把从零搭建AI工程体系的过程、技术选型、性能优化、评估机制、成本治理这些核心环节完整拆解一遍既有踩坑实录也有可直接复用的参数和经验希望能给你在AI工程化这条路上省掉几个月的试错时间。1. 项目整体思路AI工程不等同于“调接口”我的开局可能和不少团队一样业务方突然丢来一个需求——“用大模型把客服工单自动分类”、“给文档库做个智能问答”然后所有人都以为这事儿找个API接一下就能上线但真实动手后才发现AI工程根本不是一个“接入动作”而是一整套从数据、模型、推理、评估到运维的闭环体系。1.1 为什么AI工程和传统软件工程完全是两个物种传统软件工程的核心是确定性——输入A走逻辑B输出C行为可预测bug可复现。但AI工程面对的是概率系统同样一句用户提问模型每次输出的Token分布都有细微差别同一个Prompt在不同模型版本上的表现可能天差地别。这种“不确定性”会直接影响整个工程质量体系的构建方式你没法像写单元测试那样断言一段回答“必须等于某个字符串”需要重新设计验证方法。另一个维度是资源密度。普通后端一个接口可能只消耗几MB内存AI推理请求一上来就是GB级显存、数百ms到数秒的响应时间还伴随Token费用。我做过的某个RAG问答服务高峰期单日Token消耗量换算成成本会让人肉疼这就意味着每个请求链路都需要扣细节——上下文塞多少、缓存怎么设计、模型怎么选、请求怎么并发。所以我给这个项目的定位是分四层推进算力资源层、数据与模型层、推理服务层、应用编排与评估层。每一层独立建设再通过统一接口串联这样任何一个环节需要替换或升级不会牵一发动全身。1.2 从零起步时最容易踩的决策陷阱第一个陷阱是一上来就选超大模型。很多团队迷信“参数越大越强”直接把70B甚至更大规模的模型拉上线结果卡在显存和成本上连基础并发都扛不住。我见过一个团队为了展示效果用了大模型做内部Demo报价单出来以后直接劝退。合理的路线是根据任务复杂度先选7B~14B量级的开源模型比如Qwen系列、Llama系列这些成熟选择性能足够覆盖大部分业务部署成本又可控。第二个陷阱是忽视数据工程。大模型应用里60%的效果其实来自数据质量而不是模型本身。很多团队拿到模型就开始调Prompt却忘了把业务数据清理成结构化、可检索的形态。我在RAG项目里最深的体会是切片策略和Embedding模型的选择对召回质量的影响远比花时间微调Prompt更大。第三个陷阱是缺少“评估门禁”。初期团队经常靠人工点几个测试用例就说“效果不错”但上线后用户反馈却完全不是那么回事因为试的那几个用例恰恰是模型表现最好的部分。AI工程必须把评估体系当成和模型本身同等重要的一层来建设没有量化指标就无法迭代。2. 技术选型与基础设施算力、框架、部署方案的落地路径确定了“从零搭建”的分层思路之后最耗精力的就是基础设施和框架选型。选型的原则其实很朴素——优先考虑团队已有的运维能力再考虑业务的性能要求最后才看技术热门度。2.1 算力层的两种选择对比做AI工程首先要直面算力问题。自建GPU集群和租用云GPU是两条不同的路我整理了一个对比维度自有GPU集群云GPU按需租用前期投入高机房、硬件、网络都要准备低按小时付费弹性扩容受限扩容周期以周计灵活分钟级扩容运维成本高需要专人管理驱动、散热、故障低平台层已封装适合场景长期稳定负载、数据敏感型业务项目初期、波峰波谷明显的场景从我的实践经验来看项目初期用云GPU跑通全流程是最明智的等模型稳定、流量模型清晰后再考虑是否迁移到自有集群。在GPU选型上7B~14B参数的模型用单张A10/A10040G显存或民用级409024G显存基本能支撑起中低并发的业务。如果跑70B以上模型就需要多卡张量并行显存带宽和卡间通信会成为关键瓶颈。2.2 容器化与调度方案的成熟组合算力环境准备好以后调度层是另一个关键环节。我推荐直接用Kubernetes加上GPU插件做资源编排原因是生态成熟且绑架风险低。团队如果在K8s上不熟至少也应该把NVIDIA Container Toolkit和Docker Compose这套组合用起来把环境依赖固化进镜像。推理这个环节的特殊性在于它既需要短时高并发的弹性又需要稳定的GPU常驻。我用K8s的Deployment管理推理服务利用HPAHorizontal Pod Autoscaler配置自定义指标如GPU利用率、请求队列深度做自动伸缩服务入口再挂一层消息队列削峰整体结构是这样的apiVersion: autoscaling/v2 kind: HorizontalPodAutoscaler metadata: name: llm-inference-hpa spec: scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: llm-inference-server minReplicas: 2 maxReplicas: 8 metrics: - type: External external: metric: name: gpu_utilization selector: matchLabels: resource: nvidia_gpu target: type: AverageValue averageValue: 70这个配置的思路是让GPU利用率维持在70%左右过高则扩容新副本过低则回收空闲副本。有一点要注意LLM推理和普通Web服务不同扩容前必须考虑显存能不能承载目标并发否则副本副本加多了显存反而先爆了。2.3 推理引擎选型从原生transformers到专用引擎很多人刚接触LLM部署时会直接用transformers库的generate接口这在实验环境没问题但生产环境并发一上来就会遇到两个严重问题显存浪费严重静态batch导致GPU利用率低和排队延迟不可控。专用推理引擎就是解决这件事的。目前社区里主流的几个选择vLLM生态最好实现了PagedAttention和Continuous Batching吞吐量比transformers原生方案高出3~10倍是我生产环境的主力。SGLang在复杂调度和高并发场景下表现更强适合服务规模较大的团队。TensorRT-LLMNVIDIA官方出品极致性能优化但编译和部署链路更复杂。llama.cpp适合CPU推理、边缘设备部署量化支持好。我的经验是大部分业务场景vLLM足够用了社区活跃、修复快。如果量化精度损失接受不了、必须用FP16跑更大的模型再考虑TensorRT-LLM这类深度优化方案。2.4 应用编排层模型能力到业务能力的最后一公里基础设施和推理服务就绪后剩下的就是“如何让业务方更容易使用模型能力”。应用编排层会承担这些事把模型API封装成业务服务隐藏模型细节。管理Prompt模板、上下文组装、外部工具调用。实现流式输出、会话管理、多轮记忆。连接企业知识库实现RAG。RAG这块是目前落地最多的场景我建议直接用LangChain或LlamaIndex这类框架在里面快速验证切片、检索、重排的流程跑通以后再针对性能瓶颈做自定义优化。这里有个容易误入的坑就是过度依赖框架封装、出了问题排查困难。我通常会把框架当作初学者工具核心链路检索→拼装→生成→校验都用自己可控的代码实现框架只承担基础的连接件作用。3. 核心细节解析推理性能优化与显存管理实操如果前面的工程框架是骨架那推理性能优化就是血液。AI工程最容易被质问的就是“并发上不去、响应太慢、成本太高”这三个问题的根源几乎都在推理性能和显存管理。3.1 KV Cache的显存计算为什么你的并发总是上不去大模型推理时每生成一个Token都要把之前所有Token的Key和Value缓存下来用于注意力计算这就是KV Cache。它和输入长度成正比更是并发的大敌。我直接用一个7B模型的真实参数来算一笔账假设某7B模型有32层、32个KV头、每个头的维度是128使用FP16精度2字节。那么每个Token产生的KV Cache大小是2K和V两份 × 32层数 × 32KV头数 × 128头维度 × 2FP16每参数字节数 2 × 32 × 32 × 128 × 2 524,288 字节 512KB也就是说一个Token就要吃掉0.5MB显存。如果每条用户请求的上下文长度是2000 Token那么单个请求的KV Cache就是1GB。一张80GB的A100单是KV Cache就能被几十个并发请求吃满连模型权重约14GB和计算预留都放不下了。所以部署推理服务时不能只看模型参数文件有多大还必须按这个公式评估“最大上下文长度 × 最大并发数 × 单Token KV Cache大小”的显存上界否则必炸。3.2 量化策略精度与显存的平衡艺术量化是用更低比特数表示权重和激活值大幅降低显存占用的技术手法。我的量产经验数据大致如下量化方案显存节省质量损失适用场景FP16基准无对质量要求极高的核心业务INT8约50%很小可忽略生产环境默认选择INT4约75%部分任务下降明显长上下文、高并发、边缘设备实践下来INT8在大多数业务场景的质量损失可以忽略但对数学、代码生成这类精确任务会有轻微影响。INT4虽然能省很多显存但在复杂推理任务上表现不稳定我一般不推荐在核心链路上用。如果非要用INT4务必用模型本身的校准数据集评估关键指标后再决定。3.3 批处理策略从静态Batch到动态Continuous Batching传统的transformers库在推理时会把一批请求归拢后统一计算这会产生一个严重问题——不同请求的生成长度不同短的请求早结束了但GPU还得陪着长请求一起算造成大量计算浪费。vLLM的Continuous Batching就是解决这个问题的。它把请求级调度改成Token级调度每当一个请求的某个Token生成完毕就立刻释放它的计算槽位马上分配给其他排队的请求。这样GPU利用率能大幅提升实测下来吞吐量提升3~10倍是常事。我在部署时配置了这样的核心参数# vLLM 启动7B模型示例 python -m vllm.entrypoints.openai.api_server \ --model /models/qwen2.5-7b-instruct \ --tensor-parallel-size 1 \ --gpu-memory-utilization 0.9 \ --max-model-len 4096 \ --max-num-seqs 32 \ --enable-prefix-caching解释一下关键参数的选择逻辑gpu-memory-utilization 0.9允许框架用满90%的显存剩余10%留给CUDA上下文和其他开销这个比例经过大量实践验证是安全且激进的平衡点。max-num-seqs 32单卡上同时处理的最大序列数设置太高会OOM太低浪费算力我根据上面的KV Cache公式计算后定为32。enable-prefix-caching相同前缀的Prompt直接复用KV Cache多轮对话和固定系统提示词的场景收益特别明显。3.4 长上下文场景下的工程处理长文本和超长文档处理是另一个隐蔽的性能杀手。把整本PDF往模型里塞2分钟的等待和巨额Token费用都会让人崩溃。工程上长上下文的正确姿势是通过RAG把文档切片只检索相关片段送入上下文。用MapReduce模式把长文档先拆块处理再做结果汇总。能走流式输出就绝不等待完整结果。长对话场景设置轮次清理避免上下文无限膨胀。4. 质量评估与回归AI工程的定海神针我见过太多团队把评估当成上线前的一次性人工测试然后项目就进入“改了大家随意”、“什么都能过”的失控状态。AI工程的迭代速度比传统软件快得多没有自动化的评估体系一夜之间所有成员都会变成测试员整个项目寸步难行。4.1 不同评估维度怎么选择产线级的LLM应用要评估的维度通常不止一个我们项目里就建立了四层评估体系评估维度衡量内容常用方法内容正确性回答是否准确、有无幻觉关键信息点匹配、专家打分、LLM-as-Judge指令遵循度是否按要求格式、长度、语气回答规则校验、模式匹配、人工抽检工具调用成功率Agent/Function Call是否调对工具调用日志回放性能成本延迟、Token消耗、并发上限监控系统量化采集从我的实操经验看给“内容正确性”打分最好别用单一的BLEU或者ROUGE。这些基于n-gram重叠的指标在对话场景中美貌但失实——两个完全不同的句子可能语义一样重叠率却很低。现在行业里普遍采用两种替代方案一是构造标准答案后做语义相似度匹配二是用更强的LLM作为打分器判断回答质量后者用得好了效率相当高。4.2 LLM-as-Judge怎么让模型给模型当裁判让一个强模型给另一个模型的输出打分就是LLM-as-Judge。这是个很高效的方法但设计Judge Prompt时要非常小心因为Judge模型自身也有偏好和偏见。我在项目里总结了几条关键经验给Judge提供结构化评分标准比如分维度准确性、完整性、格式打分再汇总。采用“参考标准答案”模式比无参考打分更稳定至少不容易被带偏。让Judge输出评判理由加比分绝不只是给一个数字否则出问题时没法定位。定期用一批人工标注样本校验Judge本身的稳定性发现偏差及时调整。一个我用的Judge Prompt模板大致长这样你是一个严格的评审专家。请根据以下标准对AI助手的回答进行打分 1. 准确性0-5分事实是否有误是否包含虚构内容。 2. 完整性0-5分是否覆盖用户问题的所有关键方面。 3. 格式规范0-5分是否按要求输出格式是否整齐。 参考标准答案 {reference_answer} 用户问题 {user_query} AI助手回答 {candidate_answer} 请输出JSON格式评分和理由。关键点在于“参考标准答案”。有了它Judge的评分稳定性会明显提升这是我们在实际项目中反复验证过的结论。4.3 回归测试的自动化建设评估指标定好了还得把它变成可重复执行的自动化流程。我在CI/CD里面加了一步每当更新Prompt、换模型、调整检索参数时自动跑全量评估集然后用统一报表展示各维度的得分变化。只有关键指标全部达标的版本才能发布上线。这一步看起来平平无奇但实际效果非常显著。它把AI迭代从“玄学调参”变成了“可追踪的实验”出了问题能说清楚是哪个改动影响的、影响有多大这在传统软件里是习以为常的能力到了AI项目里反而成了稀缺品质。5. 实操过程与核心环节实现从零搭建一个RAG问答服务前面讲的都比较系统我结合一个具体的RAG问答需求完整走一遍实操流程。这能让你更直观地感受从零开始搭建一个AI工程服务的全貌。5.1 需求定义与数据清洗假设业务方想把历史客服对话记录变成一个智能问答系统。第一步不是选模型而是先梳理数据来源客服对话记录可能是Excel、PDF、文本文件格式混乱、质量参差不齐还有大量敏感信息。我当时的做法是先写脚本统一解析格式把常见问题整理成结构化QA对把长文档按标题层级切成逻辑单元再人工清洗掉无意义的寒暄、广告、脏数据。这一步看起来最土但对最终效果的影响是最大的。清洗完的数据格式大概长这样{ id: qa_00123, category: 退款流程, question: 退款需要多久到账, answer: 通常情况下退款将在3-5个工作日内原路返回, source: 2024_06_客服对话记录.xlsx }结构化QA对用于精确召回长文本切片用于语义检索两类数据分开索引效果会好很多。5.2 Embedding模型与向量库选型中文场景下我建议优先考虑专门的向量模型效果通常会比多语言通用模型好不少。选择策略有三个参考看它在C-MTEB中文基准上的得分、看模型本身参数量能否满足检索速度、看是否支持最近的指令型检索能力。向量库的选型上如果数据量在百万级以内用开源的Milvus或者轻量级Chroma足够数据量再大一点就得上ES配合向量索引方便后续做关键词与向量的混合检索。我的经验是业务用Milvus起步非常顺滑它原生支持HNSW这类常见索引性能和易用性兼顾得很好。5.3 检索策略调优从朴素TopK到混合检索重排RAG最核心的问题是检索质量。前期的朴素方案是拿用户query的向量和文档向量的余弦相似度排序取TopK片段塞给模型。但这个方案很容易被“高相似度但完全不相关”的片段干扰。我做过的几轮调优包括加关键词过滤作为召回前置用BM25先粗筛一遍再做向量精排。引入重排模型Reranker对候选片段做细粒度相关性打分。调整TopK数量测试不同K值的答案覆盖率和精确率的平衡点。实测下来的结论是加了BM25与向量混合检索后命中率提升约15%再加一层重排相关性精准度能提升到90%以上。但重排模型会增加几十毫秒延迟需要结合业务的响应时间预算做权衡。5.4 上下文组装与Prompt模板RAG最后一步是把检索到的参考片段和用户问题组装成模型输入。这部分的工程细节容易忽略但影响很大。组装Prompt时我会按“系统指令 参考片段 用户问题”的顺序排列并在系统指令里明确要求模型“只能用给出的参考文档回答问题如果文档中没有答案要明确说不知道”。这个方法能显著降低幻觉率也是目前RAG场景的行业标配做法。系统你是一个企业知识库问答助手。 请严格依据下面的【参考资料】回答用户问题。 如果参考资料中没有确切答案请回复根据现有资料无法回答这个问题。 【参考资料】 {retrieved_chunks} 用户问题{question}动态上下文组装必须实现片段去重和相关性阈值过滤把不相关的碎片直接丢掉既能省Token又避免误导模型。5.5 上线与压测流程服务开发完成后我不能直接丢给业务方。先在Staging环境做压测主要关注两个指标并发上限用k6或locust模拟用户请求观察显存利用率和响应时间拐点。延迟分布重点看P95和P99响应时间因为大模型响应长尾严重平均延迟意义不大。压测结果不达标优先从上下文裁剪、缓存策略、并发调度三个方向优化改完后再重复压测直到数据符合SLO。6. 常见问题与排查技巧实录我在这条路上踩过的坑不少抽几个高频问题分享出来都是可以直接照搬排查思路的实用经验。6.1 显存溢出排查现象服务运行一段时间后报CUDA Out of Memory重启后好转持续运行又复发。排查思路先看是模型权重还是KV Cache吃掉了显存。先用nvidia-smi观察显存分配情况再用vLLM的日志观察KV Cache的allocated blocks是否持续增长。如果是KV Cache增长导致的重点检查是否有慢请求占用大量上下文、是否启用了Prefix Caching、max-num-seqs是不是设置得太大。我遇到过的一个案例根源是业务方在某个长文档对话里不断追加上下文单个请求最长跑到了4万多Token直接把GPU显存耗尽。最后的解决方案是在网关层对单请求的上下文长度做了硬限制。6.2 响应延迟突然飙升排查思路先看是模型生成慢还是上游检索慢。我在项目里给每条请求都加了分阶段耗时追踪把“检索耗时”和“生成耗时”分开上报一旦延迟飙升就能快速定位瓶颈环节。生成耗时飙升通常有几个原因并发太高导致排队、上下文过长导致注意力计算压力大、量化后的模型在极端场景下重试导致累积时间。检索耗时飙升则多半是向量库连接池满了或者是重排模型被并发打满。根据阶段数据对症下手比盲目扩容有效得多。6.3 模型输出经常出现幻觉幻觉是LLM应用最头疼的问题完全消除不现实但可以显著压低概率。我在项目里用了三层防护在Prompt里强制要求模型在信息不足时明确说“不知道”。在RAG链路里加上引用来源标注要求模型输出时把依据片段编号写出来。对高风险场景设置“置信度阈值”低于阈值就直接转入人工处理不让模型硬答。第一层和第三层的组合在实际客服场景里把幻觉率从15%以上压到了3%以内代价是约5%的请求需要人工介入但相比AI客服乱答带来的风险这个代价完全值得。6.4 工具调用不稳定的Agent问题Agent场景里最大的坑是工具调用经常反反复复不稳定要么漏掉参数要么调用错误的工具要么一个简单任务循环调了好几次工具没结果。我的工程化思路是把工具类型缩小、描述写清楚、参数定义规范化给模型的信息越简洁越不容易选错。在Agent循环里加最大迭代次数和超时机制杜绝死循环。每次工具调用都记录完整日志包括模型输出、解析后的参数、工具返回结果、错误信息。排错时最依赖的就是这份日志。6.5 常见问题速查表问题现象优先排查方向常见解决方案并发一高就OOMKV Cache vs 模型权重降max-num-seqs、开Prefix Caching、降上下文上限响应慢但GPU利用率低排队 vs 批处理策略检查是否用了Continuous Batching、提升并发请求到达率检索内容总是不相关切片粒度、Embedding模型调整切片大小、换中文向量模型、加重排层回答总是编造内容提示词约束不足强制限定引用范围、加入“不知道”选项、设置信度兜底Token费用增长失控上下文膨胀限制最大上下文、做多轮裁剪、引入缓存7. 成本控制与算力治理的实践经验很多AI项目不是死在技术上而是死在账单上。模型推理调用费用、GPU租赁费用、数据标注费用加起来在没有任何治理的情况下会迅速超过预算。这部分聊聊我积累的几招治理经验。7.1 Token成本治理三板斧第一板斧是缓存复用。高频相似请求直接命中缓存不重复调模型。语义缓存的实现思路是把用户query做Embedding后对比相似度超过阈值就直接把上次的答案取回来——这个策略在客服类场景能节省30%以上Token消耗。第二板斧是模型分层。简单任务用小的快的模型复杂任务才上大模型。我们内部的实践是做了个路由层先根据任务类型和难度把请求分流简单的意图识别用轻量模型就够了只有涉及复杂推理、长文本处理或代码生成时才路由到更大参数量模型。成本直接下降接近一半。第三板斧是Token预算管理。给每个业务线设置日/周额度和告警阈值超限自动拦截降级。这需要产品侧充分沟通但确实能防止某个激进功能直接把预算烧穿。7.2 GPU利用率优化GPU是按小时计费的利用率低就等同于烧钱。我优化GPU利用率的方式有优先部署支持Continuous Batching的推理引擎把单卡并发拉上去这是提升利用率最直接的手段。把离线批处理任务批量评测、数据清洗、批量生成排到在线服务的低谷期运行实现高峰在线、低谷离线混跑。按流量趋势提前扩容避免流量突增时临时开高价实例应付。7.3 弹性伸缩策略优化弹性伸缩不是越大越好而是要平衡响应速度和资源成本。我把推理服务拆成两个池子在线服务池和弹性任务池。在线池常驻最小副本数保底服务质量弹性池根据消息队列积压量自动扩缩容。这样设置之后高峰期的成本能压下来低谷期也不会白白烧钱整体成本控制在一个比较理想的区间。最后分享一点项目沉淀AI工程从零搭建的这个过程回头看来最难的部分其实不是技术而是团队心智的转变。大家习惯了写代码追求“确定结果”但AI系统天然带着概率和不确定性你必须把评估、监控、回滚当成基础能力来建设而不是可有可无的附加项。我个人最深的体会是——别追求一步到位先让端到端的最小闭环跑起来再逐层做优化。一开始可能有各种各样的问题但这是最真实的学习路径。另一个很值得分享的心得是AI工程迭代的节奏比传统软件快得多成本也肉眼可见地往上走所以“每一次改动都带上评估和压测”这条底线一定要从第一天就守住。希望这篇从头搭建的记录能帮你少踩几个我踩过的坑。
