1. 从零搭建AI工程能力为什么“会调包”远远不够很多人第一次接触AI工程是从一行pip install或者一个现成的API调用开始的。调通一个模型接口返回一段看起来像模像样的文本就觉得自己已经“入门”了。但真正进入项目交付阶段问题会一个接一个冒出来模型响应忽快忽慢、上下文一长就崩、并发一上来就超时、成本失控、输出格式不稳定、换一个模型效果天差地别。这些问题的根源往往不在于模型本身而在于工程能力的缺失。ai-engineering-from-scratch这个标题核心讲的不是“从零训练一个大模型”而是从零构建一套能支撑AI应用稳定运行的工程体系。它面向的是那些已经会用模型、但还没建立起完整工程思维的开发者以及想从传统后端、数据方向转型到AI应用方向的工程师。你需要关心的不只是“模型能不能跑”而是“模型在生产环境里能不能稳定、可控、可观测地跑”。我见过太多团队模型选型讨论了两周工程架构却只花了半天结果上线第一周就被各种边界情况打穿。这篇文章我会把AI工程从零搭建的完整链路拆开讲清楚每个环节为什么这么做、怎么做、容易在哪里翻车。内容会覆盖环境与依赖管理、推理服务封装、上下文与状态管理、可观测性与成本控制、以及从Demo到生产的演进路径。全程不堆砌术语尽量用实际项目里的做法来说明。2. 环境与依赖管理AI项目最容易失控的第一环2.1 为什么AI项目的依赖比普通后端更棘手普通Web项目的依赖相对稳定一个框架版本能用很久。但AI项目的依赖链条要复杂得多深度学习框架、推理加速库、CUDA驱动、Python版本、模型权重格式、分词器版本任何一环版本不匹配都可能出现“本地能跑、服务器报错”的经典问题。更麻烦的是很多AI库的版本更新非常频繁API变动大今天能用的写法下个月可能就废弃了。我在实际项目里踩过最典型的一个坑本地用某个版本的推理库跑得好好的部署到服务器后因为CUDA版本差了半个小版本直接报了一堆看不懂的符号错误。排查了大半天才发现是底层驱动的问题。从那以后我养成了一个习惯——AI项目的环境必须锁定到可复现的粒度不能只写一个requirements.txt就完事。2.2 用容器把“环境”变成可交付物我的做法是从项目第一天起就用容器来管理运行环境。不是等到部署才想起来写Dockerfile而是开发阶段就用同一套镜像。这样能保证开发、测试、生产三个环境的一致性。下面是一个我常用的基础镜像结构思路FROM python:3.11-slim # 系统级依赖单独一层方便缓存 RUN apt-get update apt-get install -y --no-install-recommends \ build-essential \ rm -rf /var/lib/apt/lists/* # 先装依赖再拷代码利用镜像层缓存 COPY requirements.txt . RUN pip install --no-cache-dir -r requirements.txt COPY . . CMD [python, -m, app.main]这里有个细节值得说先拷贝依赖文件、安装依赖再拷贝源代码。这样只要依赖没变改代码时重新构建镜像会直接命中缓存构建时间能从几分钟降到几秒。这个技巧在迭代频繁的AI项目里特别实用因为AI项目的依赖安装往往很慢。2.3 依赖锁定的具体做法光有requirements.txt不够因为它通常只写了顶层依赖不锁定间接依赖的版本。我推荐用pip-tools或者poetry来生成锁定文件。以pip-tools为例# requirements.in 里写顶层依赖 pip-compile requirements.in -o requirements.txt生成的requirements.txt会包含所有间接依赖的精确版本和哈希值。这样无论在哪台机器上安装得到的依赖树都是一致的。对于模型权重文件我建议单独管理不要打进镜像而是通过挂载卷或者对象存储的方式在运行时加载。原因很简单模型文件动辄几个G打进镜像会让镜像体积爆炸推送和拉取都极其痛苦。提示模型权重和代码要分离管理。代码走镜像权重走存储。这样更新代码不用重新传模型更新模型也不用重新构建镜像。3. 推理服务封装把模型变成一个靠谱的接口3.1 直接调用模型脚本的问题在哪很多人的第一版AI服务就是一个Python脚本里面加载模型然后写个循环处理请求。这种写法在Demo阶段没问题但一旦要对外提供服务就会暴露出一堆问题模型加载慢导致首次请求超时、多个请求互相阻塞、没有超时控制、异常直接抛给用户、无法水平扩展。这些问题的本质是你把“模型推理”和“服务治理”混在了一起。正确的做法是把模型推理封装成一个独立的服务层对外暴露标准的HTTP或gRPC接口。服务层负责请求解析、参数校验、超时控制、错误处理、日志记录模型层只负责纯粹的推理计算。这样职责清晰后续替换模型、调整推理逻辑都不会影响服务接口。3.2 一个最小可用的推理服务结构我用FastAPI搭推理服务比较多因为它异步支持好、类型校验强、文档自动生成。一个典型的服务结构大概是这样from fastapi import FastAPI, HTTPException from pydantic import BaseModel import asyncio app FastAPI() class InferRequest(BaseModel): text: str max_tokens: int 256 class InferResponse(BaseModel): result: str latency_ms: float app.on_event(startup) async def load_model(): # 启动时加载模型避免首次请求超时 global model model load_your_model() app.post(/infer, response_modelInferResponse) async def infer(req: InferRequest): if not req.text.strip(): raise HTTPException(status_code400, detailtext 不能为空) try: # 用线程池跑同步推理避免阻塞事件循环 result await asyncio.to_thread(model.generate, req.text, req.max_tokens) return InferResponse(resultresult, latency_ms...) except Exception as e: # 记录详细日志对外只返回通用错误 logger.exception(推理失败) raise HTTPException(status_code500, detail推理服务内部错误)这里有几个关键点。第一模型在启动时加载而不是每次请求加载否则首次请求会慢到无法接受。第二同步推理放到线程池里跑因为大多数模型推理是CPU/GPU密集型的同步操作直接放在异步函数里会阻塞整个事件循环。第三异常要分层处理内部记录详细堆栈对外只返回通用错误信息避免泄露内部细节。3.3 超时与并发控制不能省AI推理的耗时波动很大同样的请求可能几百毫秒也可能几秒。如果没有超时控制一个慢请求可能拖垮整个服务。我的做法是在服务层设置两层超时请求级超时和推理级超时。请求级超时由网关或框架控制推理级超时在调用模型时控制。import signal def run_with_timeout(fn, timeout_sec): def handler(signum, frame): raise TimeoutError(推理超时) signal.signal(signal.SIGALRM, handler) signal.alarm(timeout_sec) try: return fn() finally: signal.alarm(0)并发控制同样重要。GPU资源有限同时跑太多推理请求会导致显存溢出或者排队严重。我通常会用信号量或者队列来限制并发数让请求有序排队而不是一拥而上把服务打挂。注意超时时间要根据实际业务场景设定不要照搬网上的默认值。交互式场景可能要求2秒内返回批处理场景可以放宽到几十秒。设定前先做压测拿到真实的耗时分布。4. 上下文与状态管理AI应用区别于普通接口的核心4.1 为什么AI服务需要“记忆”普通REST接口大多是无状态的来一个请求处理一个处理完就结束。但AI应用尤其是对话类、助手类应用往往需要记住之前的交互内容。这就是上下文管理要解决的问题。上下文管理做得好不好直接决定了用户体验的连贯性和系统的资源消耗。最朴素的做法是把所有历史消息都塞进每次请求里。这在对话轮次少的时候没问题但轮次一多上下文长度会迅速膨胀导致推理变慢、成本飙升甚至超出模型的最大上下文限制。我见过一个项目用户聊了二十轮之后每次请求都要带上几千个token的历史成本直接翻了好几倍。4.2 上下文裁剪的几种策略上下文管理没有银弹要根据业务特点选择策略。我常用的有几种策略做法适用场景代价滑动窗口只保留最近N轮短对话、客服丢失早期信息摘要压缩把早期对话总结成一段话长对话、助手需要额外推理关键信息抽取只保留实体和关键事实任务型对话实现复杂向量检索把历史存入向量库按需召回知识型应用需要检索层实际项目里往往是组合使用。比如最近几轮用滑动窗口原样保留更早的内容做摘要压缩同时把重要的事实性信息抽取出来单独存储。这样既控制了上下文长度又尽量保留了关键信息。4.3 会话状态的存储选型会话状态存哪里也是个需要认真考虑的问题。存内存最简单但服务重启就丢多实例部署也没法共享。存Redis是常见做法读写快、支持过期适合大多数场景。如果会话数据量大、需要复杂查询可以考虑存数据库。import redis import json r redis.Redis(hostlocalhost, port6379, decode_responsesTrue) def save_session(session_id, messages, ttl3600): r.setex(fsession:{session_id}, ttl, json.dumps(messages)) def load_session(session_id): data r.get(fsession:{session_id}) return json.loads(data) if data else []这里有个经验会话一定要设过期时间。不设过期的会话数据会无限增长最后把存储撑爆。过期时间根据业务定客服场景可能几小时个人助手可能几天。另外会话ID的生成要用足够随机的值避免被猜到导致串号。提示上下文裁剪逻辑要可配置不要写死在代码里。不同业务、不同模型对上下文长度的容忍度不一样做成配置项方便调整。5. 可观测性与成本控制让AI服务“看得见、管得住”5.1 AI服务需要观测哪些指标普通服务的监控指标是QPS、延迟、错误率。AI服务除了这些还需要关注一些特有的指标token消耗量、推理耗时分布、上下文长度分布、模型命中率、缓存命中率。这些指标直接关系到成本和体验。我一般会把指标分成三类。第一类是性能指标请求延迟的P50、P95、P99推理队列长度并发数。第二类是成本指标每次请求的输入token数、输出token数、累计消耗。第三类是质量指标输出被截断的比例、格式解析失败的比例、用户重试的比例。这三类指标缺一不可只看性能不看成本月底账单会教你做人只看成本不看质量用户会教你做人。5.2 用结构化日志记录每次推理日志是排查问题的基础。AI服务的日志不能只记“请求成功/失败”要记录足够多的上下文。我通常会在每次推理后打一条结构化日志import logging import json logger logging.getLogger(inference) def log_inference(request_id, model, input_tokens, output_tokens, latency_ms, status): logger.info(json.dumps({ request_id: request_id, model: model, input_tokens: input_tokens, output_tokens: output_tokens, latency_ms: latency_ms, status: status, }))结构化日志的好处是可以直接被日志系统解析、聚合、告警。比如你可以设置一条规则当某小时内总token消耗超过阈值时触发告警。这种基于日志的告警比事后看账单要主动得多。5.3 缓存是成本控制的第一利器AI推理很贵但很多请求其实是重复的或者高度相似的。缓存能省下大量成本。缓存分几个层次精确缓存相同的输入直接返回之前的结果语义缓存语义相似的输入复用结果前缀缓存相同的前缀部分复用计算结果。精确缓存实现最简单用一个字典或者Redis就行。语义缓存需要计算输入的向量表示然后做相似度匹配实现复杂一些但命中率更高。前缀缓存则依赖推理框架的支持很多推理引擎已经内置了这个能力。import hashlib def cache_key(text, params): raw f{text}|{json.dumps(params, sort_keysTrue)} return hashlib.sha256(raw.encode()).hexdigest() def get_cached(text, params): key cache_key(text, params) return r.get(fcache:{key})缓存要注意失效策略。模型更新了、参数变了缓存都要失效。我一般会在缓存key里带上模型版本和关键参数这样模型一换旧缓存自然就不会被命中。注意缓存不是万能的。对于创意类、需要多样性的场景缓存反而会伤害体验。要根据业务判断哪些请求适合缓存。6. 从Demo到生产AI工程能力的演进路径6.1 Demo思维和生产思维的分水岭Demo的目标是“证明可行”生产的目标是“稳定可靠”。这两者的关注点完全不同。Demo阶段你关心的是模型能不能输出想要的结果生产阶段你关心的是在流量高峰、异常输入、依赖故障的情况下服务还能不能正常工作。我总结了一个简单的判断标准如果你的AI服务在以下情况下会挂那它就还停留在Demo阶段——模型加载失败、输入超长、并发突增、依赖服务超时、磁盘写满、内存不足。生产级的AI服务必须对这些问题有预案。6.2 灰度发布和回滚机制AI服务有个特殊之处模型更新会直接改变输出结果。新模型可能在某些场景下更好在另一些场景下更差。所以模型更新不能像普通代码更新那样一把梭要做灰度。我的做法是维护多个模型版本通过配置控制流量分配。比如新模型先接10%的流量观察一段时间的关键指标没问题再逐步放大。一旦发现异常能快速把流量切回旧版本。这套机制的关键是配置要能热更新不能改个流量比例还要重启服务。def select_model(request_id): # 根据配置的流量比例选择模型版本 ratio get_config(new_model_ratio, 0.0) bucket hash(request_id) % 100 return new if bucket ratio * 100 else old6.3 压测和容量规划AI服务的容量规划比普通服务难因为推理耗时和输入长度强相关。同样一个接口输入100个token和输入2000个token耗时可能差十倍。所以压测不能只压固定输入要覆盖不同长度的输入分布。我一般会准备几组代表性的输入样本分别压测拿到不同输入长度下的QPS和延迟曲线。然后根据业务的实际输入分布估算需要的实例数。这里要留足余量因为AI推理的耗时波动大平均值好看不代表P99好看。输入长度平均延迟P99延迟单实例QPS短200 token300ms800ms20中200-800 token900ms2.5s8长800 token2.5s6s3这张表是我在一个项目里实测的数据可以看到输入长度对性能的影响非常显著。容量规划时如果只按平均值算高峰期必然出问题。6.4 持续迭代的工程习惯AI工程不是一次性的工作而是持续迭代的过程。模型会更新业务需求会变化流量会增长。我养成的几个习惯是每次模型更新都跑回归测试确保核心场景不退化定期review成本报表找出异常消耗保持依赖更新但更新前一定在测试环境验证把踩过的坑写成文档避免重复踩。这些习惯看起来琐碎但正是它们决定了一个AI服务能不能长期稳定运行。技术方案可以抄工程习惯抄不来只能靠一次次实践积累。7. 一些踩坑之后的个人体会做AI工程这几年最大的体会是模型能力决定上限工程能力决定下限。一个模型再强如果工程做不好用户感受到的就是慢、不稳定、贵。反过来工程做得扎实即使模型不是最强的也能提供稳定可用的服务。另一个体会是AI工程没有标准答案。上下文怎么裁、缓存怎么设、并发怎么控都要结合具体业务来定。网上看到的方案可以参考但不能照搬。我建议每个做AI工程的人都要养成看自己服务真实数据的习惯用数据说话而不是凭感觉调参。最后分享一个实用的小技巧在服务里加一个“调试模式”开启后记录完整的请求和响应内容。平时关着出问题时临时打开能极大加快排查速度。这个开关我几乎每个AI项目都会加救过我好几次。