1. 为什么AI工程成了比“会调模型”更值钱的技能这两年有个现象很有意思会训练模型的人渐渐不那么稀缺了稀缺的是能把模型真正用起来、跑起来、扛住线上流量的人。打开招聘网站AI应用开发工程师、AI工程化岗位的需求量肉眼可见地在涨薪资也在往上走。这背后的逻辑其实不复杂——企业不缺demo缺的是能落地的产品。把一个模型从Notebook里搬到生产环境中间隔着数据清洗、推理优化、服务封装、部署运维一整套链路这条路走通的人才是市场真正抢着要的。我见过太多“模型跑得通、服务起不来”的团队。模型精度刷到90%以上结果一上线上QPS一高就崩或者接口延迟动不动三四秒业务方直接劝退。问题出在哪出在很多人没把“AI工程”当作一个完整的学科来对待只盯着模型本身忽略了模型之外的工程环节。这套技能图谱我想按实际工作流的顺序来梳理从环境准备、模型选型到代码构建、服务封装再到部署上线和后期迭代每个环节讲清楚要掌握什么、为什么需要、有哪些坑。目标读者是正准备入行AI应用开发的工程师或者已经在做算法、想往工程方向延伸的朋友。这篇文章不做那种“一键跑通”的教程而是帮你建立起一套完整的工程思维框架。2. 构建AI应用的前置条件环境、数据和模型选型2.1 环境准备——本地依赖和镜像构建的坑先说环境。大部分AI应用开发的第一步就是把本地依赖装好。这个环节看起来简单实际上翻车率极高。PyTorch、CUDA、cuDNN、Python版本之间互相打架是每个AI工程师的日常噩梦。我建议从一开始就养成两个习惯第一所有项目都用虚拟环境隔离依赖conda和venv都行别嫌麻烦第二把依赖版本锁死requirements.txt里精确到小版本号别用这种模糊写法。顺便说一句深度学习版本的CUDA和PyTorch之间的匹配关系一定要去官网查对照表不要想当然。我以前遇到过CUDA 11.8配了编译期默认的PyTorch结果跑起来直接报undefined symbol错误查了半天才发现是CUDA runtime版本不匹配。等本地验证通过下一步就是容器化。Dockerfile构建镜像这事儿看着简单里面全是细节。我见过好几个项目镜像体积动不动就上GB构建一次等十分钟。优化思路无非几条选择合适的基础镜像python:3.10-slim比python:3.10体积小一大截GPU环境用nvidia/cuda官方镜像对应的runtime版本别用devel版本除非你要编译自定义算子把依赖安装和代码拷贝分成两个层COPY requirements.txt先执行RUN pip install再COPY代码这样代码改动不会触发依赖重装利用Docker的层缓存能省大量构建时间多阶段构建编译阶段用完整镜像运行阶段只拷产物。2.2 数据准备和构建知识库——从RAG到GraphRAGAI应用和传统软件最大的区别在于AI的效果上限是数据决定的。本地部署大模型时如果要用私有知识库最常见的技术方案就是RAG检索增强生成。RAG的核心流程不复杂把文档切块、向量化、存入向量数据库用户提问时检索相关内容拼进Prompt再送给大模型生成答案。但这里面有大量工程细节。切块大小怎么定我实测下来中文场景512到1024个字符左右比较合适太长检索精度下降太短上下文碎片化。Embedding模型怎么选BGE系列、M3E这些都是中文场景下比较稳的选择别张口就用OpenAI的embedding国内业务数据和合规都会出问题。真正进阶一点的做法是用知识图谱替代或补充向量检索。构建知识图谱的流程是实体识别、关系抽取、属性提取然后存入图数据库Neo4j是社区里最常用的。这个方案的优点是能回答多跳问题比如“A公司的供应商里哪些同时和B公司有合作”这种问题靠向量检索基本答不了。缺点也很明显——构建和维护成本高实体识别的准确率直接影响下游效果。农业、医疗、法律这类专业领域聪明的做法是“向量检索为主图谱辅助”兼顾效果和成本。2.3 模型选型——本地部署还是调用API这是每个AI应用项目都要做的第一个决策。我见过不少团队一上来就追求大参数模型结果部署成本爆炸推理延迟高到没法用。选模型这事得基于具体场景倒推。如果是To C的聊天助手对延迟要求高QPS波动大本地部署一个7B、13B的模型用vLLM或TensorRT-LLM做推理加速单卡A10就够扛了如果是企业内部的知识问答数据不能出内网那就必须本地部署这时候推理框架的选择就很关键如果业务刚起步、调用量不确定直接用API先跑通业务闭环再根据用量考虑要不要私有化部署这才是合理节奏。现在本地部署大模型的主流工具Ollama算是最省心的一个。一条命令就能把模型拉起来OpenAI兼容的接口格式配合FastAPI写业务逻辑非常顺滑。但Ollama更适合开发调试和小规模部署真到生产环境vLLM的吞吐量和并发控制能力还是更可靠。我看过一份压测数据同样一张A100上vLLM的吞吐量能做到Ollama的3到5倍这个差距在线上就是实打实的成本差距。3. AI应用开发的核心从模型到服务的最后一公里3.1 用FastAPI和SQLAlchemy构建高性能后端模型本身不产生价值被调用才产生价值。把模型包成服务FastAPI是当前AI工程领域事实上的标准选择。为什么是FastAPI而不是Flask或Django三个理由第一异步原生支持。大模型推理本身就是IO密集型的同步框架会阻塞worker线程FastAPI的async/await机制能让你在等待模型推理时同时处理其他请求资源利用率不是一个量级。第二自动生成OpenAPI文档。前后端联调时Swagger UI直接可点可测省掉大量沟通成本。第三Pydantic的数据校验。请求参数在入口就做了类型校验非法输入根本进不到业务逻辑层这在模型服务这种对输入格式敏感的场景里简直救命。SQLAlchemy在AI应用里的角色是管理业务数据的ORM框架。用户信息、调用记录、任务状态这些结构化数据用SQLAlchemy定义模型、做迁移比手写SQL要规范和高效得多。我个人习惯是SQLAlchemy 2.0的Declarative风格配合Alembic做数据库迁移表结构变更可控可回滚。3.2 构建和测试的基本功——别让构建拖垮迭代速度很多AI项目翻车不是翻在模型效果而是翻在工程基建。这里说的“构建”不仅仅是代码编译包括代码的构建、测试、集成也就是CI/CD流水线。我接触过的AI团队里极少有把CI/CD做扎实的最典型的表现是“本地能跑就万事大吉”。以Java Web项目为例Maven或Gradle是标配构建工具但很多AI项目是Python写的那就需要用Poetry或uv来管理依赖和构建。Poetry的lock文件能保证开发、测试、生产环境依赖完全一致这一点对AI项目的可复现性至关重要。测试这一环AI应用比传统应用多了一个维度不光要测代码逻辑还要测模型效果。代码层面pytest是基础接口测试用TestClient模拟请求验证状态码、响应格式和延迟指标模型层面要有独立的评测集每次迭代都要回归跑一遍防止模型效果回退。我在实际开发中会加一个“冒烟测试”环节——部署前用固定的测试用例集做一次快速验证通过才允许上线这套机制帮我拦截了至少五次线上事故。3.3 把模型服务封装成可复用的工程组件模型封装这事儿新手和熟手的差距巨大。新手通常把模型加载、预处理、推理、后处理全写在一个函数里看着方便改起来痛苦。我推荐的模式是分层封装模型层只负责权重加载和forward调用不关心输入是什么格式服务层负责请求解析、参数校验、调用模型层业务层负责Prompt组装、后处理逻辑、调用外部工具。这三层之间用接口隔离每一层都能单独测试和替换。比如业务层要改Prompt模板根本不需要动模型层的代码模型要从A换成B只要接口兼容服务层和业务层完全不用改。这里还涉及一个很多人忽略的点——模型的“工程化”不是把模型文件存下来就行。做AI应用开发你迟早要面对“模型版本管理”的问题。模型文件动辄几个GB塞进Git不现实我的方案是把模型元信息版本号、训练数据描述、精度指标、关联代码commit记在数据库或配置文件中模型文件本身走对象存储或专门的模型仓库如MLflow。4. 部署AI应用上线的关键一环4.1 推理服务部署——从本地到生产环境部署是整个AI工程链路里最考验综合能力的一环。前面说的本地能跑、测试通过都不代表能部署上线。生产环境要面对的是并发、延迟、资源和稳定性四个维度的问题。部署方式上我推荐先把服务容器化然后用Docker Compose在单机上编排等规模上去了再引入Kubernetes。很多人一上来就上K8s结果复杂度直接压垮团队。我见过一个团队三个人维护一个K8s集群光踩坑就踩了一个月最后又退回Docker Compose。合理的演进路线是先单机、再集群别一步到位。GPU资源的分配是另一个大坑。一块GPU共享给多个服务用NVIDIA MPS或MIG都是方案但性能和隔离性的取舍需要实际测试。最稳妥的做法是一个服务独占一块GPU等业务量级确实上来再考虑共享。4.2 用vLLM或Ollama承载本地模型推理本地部署大模型这两年最大的进展就是推理框架的成熟。Ollama把部署门槛降到了极低几行命令就能跑起一个对话模型对开发者友好到无脑。但生产环境我强烈建议用vLLM做推理引擎。原因有三个PagedAttention——显存管理机制能显著提高GPU利用率同样一张卡能跑的并发请求数翻倍Continuous Batching——动态拼批推理吞吐量远高于静态批处理OpenAI协议兼容——前端和业务代码可以直接复用无缝切换。部署DeepSeek这类重量级模型时这些特性的差距会被放大得非常明显。DeepSeek-V3这种671B参数的MoE模型没有vLLM级别的推理框架想在消费级硬件上跑起来几乎不可能。硬件上A100、H100这种旗舰卡当然好但实际部署中更常见的是A10、A30这一档的中端卡这时候推理框架的选择比显卡本身更影响性能表现。4.3 部署到GitHub Pages或服务器——经典方案复盘部署这个主题想多说两种典型场景。第一种是个人项目或文档站目标平台是GitHub Pages静态托管、免费、省心。配合Hexo或VuePress这类静态站点生成器写Markdown、执行构建、推送代码GitHub Actions自动触发部署整套流程不到半小时就能配好。第二种是正式业务目标平台是自己的服务器或云主机Nginx做反向代理和负载均衡HTTPS证书用certbot一键签发数据库单独容器应用容器通过内部网络访问数据库这是目前中小型AI应用最稳的架构。两种场景的部署细节差异很大但核心原则是共通的部署流程必须可重复、自动化、可回滚。手动在服务器上敲命令部署一次两次可以时间长了必然出问题。哪怕用最基础的脚本把部署步骤固化下来也比手工强一百倍。5. 实际项目中的踩坑实录与排查方法5.1 常见部署问题速查表按我自己在这些项目里踩过的坑整理了一份排查速查表覆盖面比较广希望对大家有帮助。症状可能原因排查思路与解法服务启动报“CUDA out of memory”模型加载时显存占用过高或推理框架显存管理不当先确认模型精度FP16/BF16用nvidia-smi监控显存占用考虑开启vLLM的--gpu-memory-utilization参数限制显存使用接口响应很慢超过3秒未使用推理加速框架、并发处理不当、模型本身太大确认是否用了vLLM或TensorRT-LLM加速检查GPU利用率是否跑满必要时升级推理引擎或做模型量化容器内GPU不可用Docker未配置GPU runtime安装NVIDIA Container Toolkit启动容器时加--gpus all参数模型效果和本地不一致服务端和本地tokenizer版本不一致或推理参数temperature等设置不同逐个字段比对服务端和本地的推理参数确保tokenizer文件一致请求量一大就502服务崩溃或worker进程数不足看日志定位是否OOM或线程死锁用Gunicorn/FastAPI的worker数量设置结合压测结果调优数据库连接池耗尽SQLAlchemy连接池配置过小调大pool_size和max_overflow参数同时排查代码中是否有连接泄漏5.2 推理性能优化的三个实操方向部署之后最常做的事就是性能调优。我梳理了三个性价比最高的方向。第一是模型量化。把FP16降成INT8或INT4显存占用直接减半甚至更多推理速度也能明显提升。代价是精度损失但这个损失在大多数业务场景下是可以接受的。我用过GPTQ和AWQ两大量化方案AWQ在同样的压缩比下质量损失更小AGI时代的工程经验基本一致。第二是并发参调。很多人以为并发越高越好实际上当并发请求太多时推理系统会陷入资源争抢反而拖慢单个请求的响应速度。vLLM的max-num-seqs参数和FastAPI的worker数量需要联动调整。我的调试方法是用压测工具先打一轮单并发找到P95延迟再逐步增加并发观察延迟变化曲线找到拐点把并发控制在拐点附近既保证吞吐又不至于延迟失控。第三是Prompt工程优化。这里的优化指的不是效果而是输入token数量。Prompt越长每次推理的prefill时间越长成本越高。把历史对话做裁剪、把知识库检索结果做精简、把系统提示词压缩都能直接降低推理延迟。有次我把一个系统的历史消息从保留20轮改成保留10轮P95延迟直接降了35%这个性价比比换显卡高多了。5.3 线上问题排查的实战记录最后分享一次真正的线上事故排查。某次凌晨两点告警电话把我叫醒——AI问答服务接口超时率飙到30%。第一反应是看GPU显存和利用率都正常。再看日志发现大量超时请求卡在数据库查询阶段。继续排查数据库的连接池满了大量连接处于idle in transaction状态明显是事务没有正确提交导致连接泄漏。翻代码才发现某个异常分支里SQLAlchemy session没有做close操作异常一抛连接就泄漏了。那次之后我把所有的数据库操作统一改为依赖注入方式管理session并在入口处加了全局异常处理器兜底关闭连接。这套改动之后类似问题再没出现过。这次事故给我的教训就一句话AI应用首先是应用其次才是AI。模型再强工程基建烂照样线上崩。6. 按这条路线你该怎么一步步学习AI工程既然聊到这里我索性把AI应用开发的学习路线也整理出来给想入门的朋友一条相对清晰的路径。第一阶段1-2周打好后端基础。掌握Python或Java的核心语法特别是异步编程、装饰器、类型注解这些AI服务开发高频用到的特性。然后用FastAPI写一个简单的CRUD接口配合SQLAlchemy操作数据库把HTTP协议和RESTful设计的基本功练扎实。第二阶段2-3周熟悉大模型和AI应用的基本交互模式。了解Prompt Engineering的基本方法能用LangChain或直接调用API实现一个基础的知识库问答应用。这个阶段的重点是理解RAG的流程和各类参数的作用别急着上生产。第三阶段3-4周掌握本地模型部署。用Ollama跑起一个开源模型用FastAPI封装成HTTP服务再和前端页面打通。然后过渡到vLLM了解推理加速的底层原理对比不同推理框架在吞吐量和延迟上的差异。第四阶段1-2个月系统学习部署和运维。Docker容器化、Docker Compose编排、Nginx反向代理、HTTPS配置这套组合拳要熟练掌握。然后了解Kubernetes的基本概念和常用操作重点理解Pod、Service、Deployment这三个核心对象。第五阶段持续深入一个垂直场景。农业、法律、医疗、金融选一个你感兴趣的领域做一套完整的知识库问答系统。这个过程中会逼着你处理真实场景的数据问题、业务逻辑和部署需求这才是真正走向资深的路径。这套路线的核心逻辑是先跑通再优化再深入。很多人卡在第一步就没迈出去总觉得要先把数学、算法、模型原理全搞明白才能动手这是最大的误区。AI工程是工程学科动手做比什么都重要。
