如果你最近在关注AI应用开发可能会发现一个有趣的现象很多开发者包括一些经验丰富的工程师在尝试将AI模型或Agent落地时常常会卡在同一个环节不是模型调参也不是算法优化而是如何把一个AI想法稳定、高效、可维护地“构建”和“部署”成一个真正的应用。你或许已经用ollama跑通了本地大模型用Dify或FastAPI搭起了RAG问答的demo甚至用Spring AI写好了业务逻辑。但当你想把这个“玩具”交给团队测试或者放到生产环境服务真实用户时问题就接踵而至环境依赖混乱、服务启动失败、资源消耗失控、版本回退困难……原本炫酷的AI能力瞬间被工程化的琐碎细节拖垮。这引出了本文的核心判断在AI应用开发中最重要的技能可能不再是钻研某个前沿模型而是掌握一套标准、可靠的构建与部署工程化能力。这决定了你的AI想法是止步于个人笔记本上的Demo还是能成长为支撑业务的服务。本文将抛开泛泛而谈直接切入构建Build与部署Deploy的核心流程、实用工具链和避坑指南目标是让你读完就能着手优化自己的AI项目工程体系。1. 重新理解“构建”与“部署”AI应用的特殊性在传统Web开发中构建通常指编译、打包部署则是将产物放到服务器运行。但对于AI应用尤其是涉及大模型的场景这两个环节的内涵和外延都发生了显著变化。构建Build在AI语境下至少包含三层代码构建与传统应用类似处理依赖安装、代码打包如Python wheel、Docker镜像。模型构建处理模型文件的下载、转换、量化、裁剪。例如将Hugging Face上的.safetensors模型转换为llama.cpp支持的GGUF格式就是一个关键的构建步骤。环境构建创建包含特定CUDA版本、Python版本、系统库的确定性运行环境。AI库如PyTorch, transformers对系统环境极为敏感。部署Deploy则面临新挑战资源异构性可能需要CPU、GPU甚至特定型号、大内存等不同资源。服务模式多样性可能是常驻的API服务如用FastAPI封装模型也可能是按需调用的Serverless函数或是批处理任务。弹性与成本如何根据负载自动扩缩容同时控制GPU等昂贵资源的成本。监控与观测不仅要监控服务状态还要监控模型性能延迟、吞吐量、资源使用率GPU显存和业务指标回答准确率。忽视这些特殊性直接套用传统的Java Web项目部署经验是很多AI应用项目陷入混乱的根源。2. 环境准备确立标准化的起点混乱从环境开始。确保团队每个成员、每台服务器都有一致的起点是后续所有工作的基础。2.1 核心工具链清单以下工具构成了现代AI应用构建部署的基石建议优先掌握工具类别推荐工具解决的核心问题环境与依赖管理Docker, Conda, Poetry, uv创建隔离、可复现的Python/系统环境。模型管理与服务化Ollama, vLLM, TensorRT-LLM, llama.cpp高效加载、运行和提供大模型推理服务。API框架与编排FastAPI, LangChain, LlamaIndex, Spring AI将模型能力封装成API并编排复杂AI工作流。容器编排与部署Docker Compose, Kubernetes (K8s), Docker Swarm在多台机器上编排、管理和扩展容器化应用。配置与秘钥管理Docker环境变量, Kubernetes ConfigMap/Secret, Vault安全地管理应用配置和敏感信息如API密钥。监控与日志Prometheus, Grafana, ELK Stack收集指标、可视化性能、集中管理日志。2.2 基础环境配置示例以一个基于Python的AI API项目为例第一步是锁定环境。使用pyproject.toml和uv管理依赖推荐uv是一个用Rust写的极速Python包管理器和解析器比传统pip快一个数量级。# pyproject.toml [project] name ai-chat-api version 0.1.0 dependencies [ fastapi0.104.0, uvicorn[standard]0.24.0, pydantic2.5.0, httpx0.25.0, # AI相关核心依赖严格锁定版本 transformers4.36.0, torch2.1.0, sentence-transformers2.2.2, ] [project.optional-dependencies] dev [pytest, black, isort, mypy]然后使用uv创建虚拟环境并安装依赖# 同步安装生产依赖 uv sync # 激活虚拟环境uv自动管理 source .venv/bin/activate # Linux/macOS # .venv\Scripts\activate # Windows使用 Dockerfile 定义完整运行时环境这是确保环境一致性的终极手段。# Dockerfile # 使用带有CUDA基础镜像确保GPU支持 FROM nvidia/cuda:12.1.0-runtime-ubuntu22.04 # 设置工作目录 WORKDIR /app # 安装系统依赖 RUN apt-get update apt-get install -y \ python3.10 \ python3-pip \ curl \ rm -rf /var/lib/apt/lists/* # 使用uv进行高效的依赖安装 COPY pyproject.toml ./ RUN curl -LsSf https://astral.sh/uv/install.sh | sh \ /root/.cargo/bin/uv pip install -e . # 复制应用代码 COPY . . # 暴露端口 EXPOSE 8000 # 启动命令 CMD [uvicorn, main:app, --host, 0.0.0.0, --port, 8000]3. 构建流程实战从代码到可部署镜像构建的目标是产出一个包含所有代码、依赖、模型和配置的不可变制品通常是Docker镜像。3.1 多阶段构建优化镜像大小AI应用镜像往往很大几个GB因为包含了模型文件。多阶段构建可以显著优化。# Dockerfile.multistage # 第一阶段构建阶段 FROM python:3.10-slim AS builder WORKDIR /app COPY pyproject.toml ./ RUN pip install --user --no-cache-dir uv \ /root/.local/bin/uv pip install --system --no-cache-dir -e . # 第二阶段模型下载与处理阶段 FROM builder AS model-downloader WORKDIR /models # 使用 huggingface-cli 安全下载模型需提前配置HF_TOKEN RUN pip install --no-cache-dir huggingface-hub \ python -c from huggingface_hub import snapshot_download; snapshot_download(repo_idBAAI/bge-small-zh-v1.5, local_dirbge-embedding) # 第三阶段最终运行阶段 FROM python:3.10-slim WORKDIR /app # 从builder阶段复制已安装的Python包 COPY --frombuilder /usr/local/lib/python3.10/site-packages /usr/local/lib/python3.10/site-packages COPY --frombuilder /usr/local/bin /usr/local/bin # 从model-downloader阶段复制模型 COPY --frommodel-downloader /models /app/models # 复制应用代码 COPY . . # 创建非root用户运行提高安全性 RUN useradd -m -u 1000 appuser chown -R appuser /app USER appuser EXPOSE 8000 CMD [uvicorn, main:app, --host, 0.0.0.0, --port, 8000]3.2 集成模型构建步骤对于需要转换格式的模型如转GGUF构建流程中应包含此步骤。# 一个示例的构建脚本 build.sh #!/bin/bash set -e # 遇到错误即停止 echo 1. 下载原始模型... python scripts/download_model.py --repo_id Qwen/Qwen2.5-7B-Instruct echo 2. 转换模型格式为GGUF用于llama.cpp... # 假设使用 llama.cpp 的 convert.py python /path/to/llama.cpp/convert.py \ --outfile ./models/qwen2.5-7b-instruct.gguf \ --outtype q4_0 # 量化类型 echo 3. 构建Docker镜像... docker build -f Dockerfile.multistage -t my-ai-app:latest . echo 4. 保存镜像到文件便于传输... docker save my-ai-app:latest -o my-ai-app-latest.tar4. 部署策略深度解析从单机到云原生部署方式的选择直接关系到应用的稳定性、成本和运维复杂度。4.1 单机部署最简单快速的起点使用Docker Compose可以在单台机器上轻松定义和运行多容器应用非常适合开发、测试和小型生产环境。# docker-compose.yml version: 3.8 services: ai-api: build: . image: my-ai-app:latest container_name: ai-api-service ports: - 8000:8000 environment: - MODEL_PATH/app/models/qwen2.5-7b-instruct.gguf - EMBEDDING_MODEL_PATH/app/models/bge-embedding - OPENAI_API_KEY${OPENAI_API_KEY} # 从.env文件读取 volumes: # 挂载模型目录避免每次构建都重新下载 - ./models:/app/models # 挂载日志目录 - ./logs:/app/logs deploy: resources: reservations: devices: - driver: nvidia count: 1 capabilities: [gpu] # 声明需要GPU restart: unless-stopped # 可以添加其他服务如数据库、缓存 redis: image: redis:alpine ports: - 6379:6379启动命令# 启动所有服务 docker-compose up -d # 查看日志 docker-compose logs -f ai-api4.2 Kubernetes部署生产级弹性与可靠性当需要高可用、自动扩缩容和复杂的服务治理时K8s是首选。以下是一个典型的Deployment和Service配置。# k8s-deployment.yaml apiVersion: apps/v1 kind: Deployment metadata: name: ai-api-deployment spec: replicas: 2 # 初始副本数 selector: matchLabels: app: ai-api template: metadata: labels: app: ai-api spec: containers: - name: ai-api image: my-registry.com/my-ai-app:latest ports: - containerPort: 8000 env: - name: MODEL_PATH value: /app/models/model.gguf - name: CUDA_VISIBLE_DEVICES value: 0 # 指定GPU resources: requests: memory: 8Gi cpu: 2 nvidia.com/gpu: 1 # 请求1个GPU limits: memory: 16Gi cpu: 4 nvidia.com/gpu: 1 # 限制使用1个GPU volumeMounts: - name: model-storage mountPath: /app/models readOnly: true volumes: - name: model-storage persistentVolumeClaim: claimName: model-pvc # 使用持久化存储卷存放大模型 nodeSelector: accelerator: nvidia-gpu # 调度到有GPU标签的节点 --- apiVersion: v1 kind: Service metadata: name: ai-api-service spec: selector: app: ai-api ports: - port: 80 targetPort: 8000 type: LoadBalancer # 或 ClusterIP根据需求使用Horizontal Pod Autoscaler (HPA)实现基于CPU/内存或自定义指标的自动扩缩容# k8s-hpa.yaml apiVersion: autoscaling/v2 kind: HorizontalPodAutoscaler metadata: name: ai-api-hpa spec: scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: ai-api-deployment minReplicas: 2 maxReplicas: 10 metrics: - type: Resource resource: name: cpu target: type: Utilization averageUtilization: 70 # CPU平均使用率超过70%时扩容 - type: Resource resource: name: memory target: type: Utilization averageUtilization: 804.3 Serverless部署极致弹性与成本优化对于流量波动大或希望零运维的场景可以考虑Serverless。例如使用Google Cloud Run或AWS Lambda需注意冷启动和GPU支持问题。# 一个适配Cloud Run/FastAPI的示例 main.py import os from fastapi import FastAPI, HTTPException from pydantic import BaseModel import torch from transformers import pipeline app FastAPI(titleAI Chat API) # 注意在Serverless中模型加载必须在全局范围或使用懒加载以应对冷启动 # 这里使用懒加载模式 _model None _pipe None def get_model(): global _model, _pipe if _model is None: model_id os.getenv(MODEL_ID, gpt2) _model pipeline(text-generation, modelmodel_id, device0 if torch.cuda.is_available() else -1) return _model class ChatRequest(BaseModel): prompt: str max_length: int 100 app.post(/chat) async def chat(request: ChatRequest): try: pipe get_model() result pipe(request.prompt, max_lengthrequest.max_length) return {response: result[0][generated_text]} except Exception as e: raise HTTPException(status_code500, detailstr(e)) app.get(/health) async def health(): return {status: healthy}部署到Cloud Run的命令# 构建并推送镜像 gcloud builds submit --tag gcr.io/PROJECT-ID/my-ai-app # 部署到Cloud Run分配GPU gcloud run deploy my-ai-app \ --image gcr.io/PROJECT-ID/my-ai-app \ --platform managed \ --region us-central1 \ --allow-unauthenticated \ --memory 8Gi \ --cpu 2 \ --gpu 1 \ --set-env-vars MODEL_IDQwen/Qwen2.5-7B-Instruct5. 核心应用示例构建一个本地RAG知识库问答系统让我们综合运用上述技能构建一个基于llama.cppQwen2.5-7BFastAPI的本地RAG系统。这个示例涵盖了从环境构建到服务部署的全流程。5.1 项目结构local-rag-system/ ├── Dockerfile ├── docker-compose.yml ├── requirements.txt ├── app/ │ ├── main.py # FastAPI 主应用 │ ├── embedding.py # 嵌入模型处理 │ ├── vector_store.py # 向量数据库操作 │ └── rag_chain.py # RAG 检索与生成链 ├── models/ │ └── (模型文件存放处) ├── data/ │ └── documents/ # 知识库文档 └── scripts/ └── download_model.py5.2 核心代码实现应用入口 (app/main.py)from fastapi import FastAPI, HTTPException from pydantic import BaseModel from typing import List, Optional import logging from app.rag_chain import RAGChain app FastAPI() rag_chain None logging.basicConfig(levellogging.INFO) logger logging.getLogger(__name__) class QueryRequest(BaseModel): question: str top_k: Optional[int] 3 class QueryResponse(BaseModel): answer: str sources: List[str] # 引用来源 app.on_event(startup) async def startup_event(): 启动时初始化RAG链避免每次请求都加载模型 global rag_chain try: # 这里会加载嵌入模型和LLM可能耗时较长 rag_chain RAGChain( embedding_model_path./models/bge-small-zh, llm_model_path./models/qwen2.5-7b-instruct.gguf, vector_store_path./data/vector_store ) logger.info(RAG chain initialized successfully.) except Exception as e: logger.error(fFailed to initialize RAG chain: {e}) raise app.post(/query, response_modelQueryResponse) async def query_knowledge_base(request: QueryRequest): if rag_chain is None: raise HTTPException(status_code503, detailService initializing) try: answer, source_docs rag_chain.query(request.question, top_krequest.top_k) return QueryResponse(answeranswer, sources[doc.metadata.get(source, ) for doc in source_docs]) except Exception as e: logger.error(fQuery error: {e}) raise HTTPException(status_code500, detailInternal server error) app.get(/health) async def health_check(): return {status: ready, model_loaded: rag_chain is not None}RAG链核心 (app/rag_chain.py)import os from typing import List, Tuple from langchain.text_splitter import RecursiveCharacterTextSplitter from langchain_community.vectorstores import Chroma from langchain_community.embeddings import HuggingFaceEmbeddings from langchain_community.llms import LlamaCpp from langchain.chains import RetrievalQA from langchain.prompts import PromptTemplate class RAGChain: def __init__(self, embedding_model_path: str, llm_model_path: str, vector_store_path: str): # 1. 初始化嵌入模型 self.embeddings HuggingFaceEmbeddings( model_nameembedding_model_path, model_kwargs{device: cpu}, # 或 cuda encode_kwargs{normalize_embeddings: True} ) # 2. 初始化向量数据库如果不存在则从文档创建 if not os.path.exists(vector_store_path): self._create_vector_store(vector_store_path) self.vector_store Chroma( persist_directoryvector_store_path, embedding_functionself.embeddings ) self.retriever self.vector_store.as_retriever(search_kwargs{k: 3}) # 3. 初始化本地LLM (llama.cpp) self.llm LlamaCpp( model_pathllm_model_path, n_ctx2048, # 上下文长度 n_threads4, # CPU线程数 temperature0.1, verboseFalse, ) # 4. 定义Prompt模板 prompt_template 基于以下上下文信息请回答问题。如果你不知道答案就说不知道不要编造。 上下文 {context} 问题{question} 答案 self.PROMPT PromptTemplate( templateprompt_template, input_variables[context, question] ) # 5. 构建检索问答链 self.qa_chain RetrievalQA.from_chain_type( llmself.llm, chain_typestuff, retrieverself.retriever, chain_type_kwargs{prompt: self.PROMPT}, return_source_documentsTrue ) def _create_vector_store(self, persist_path: str): 从文档目录创建向量存储 from langchain_community.document_loaders import DirectoryLoader, TextLoader loader DirectoryLoader(./data/documents, loader_clsTextLoader) documents loader.load() text_splitter RecursiveCharacterTextSplitter(chunk_size500, chunk_overlap50) splits text_splitter.split_documents(documents) vector_store Chroma.from_documents( documentssplits, embeddingself.embeddings, persist_directorypersist_path ) vector_store.persist() def query(self, question: str, top_k: int 3) - Tuple[str, List]: 执行查询 self.retriever.search_kwargs[k] top_k result self.qa_chain({query: question}) return result[result], result[source_documents]5.3 一键部署与运行使用docker-compose编排所有服务包括本示例的RAG API和一个简单的Web前端。# docker-compose.yml version: 3.8 services: rag-api: build: . image: local-rag-api:latest container_name: rag-api ports: - 8000:8000 volumes: - ./models:/app/models - ./data:/app/data environment: - EMBEDDING_MODEL_PATH/app/models/bge-small-zh - LLM_MODEL_PATH/app/models/qwen2.5-7b-instruct.gguf deploy: resources: reservations: devices: - driver: nvidia count: 1 capabilities: [gpu] restart: unless-stopped healthcheck: test: [CMD, curl, -f, http://localhost:8000/health] interval: 30s timeout: 10s retries: 3 web-ui: image: nginx:alpine container_name: rag-web-ui ports: - 8080:80 volumes: - ./web-ui:/usr/share/nginx/html depends_on: - rag-api构建并启动# 1. 下载模型假设脚本已存在 python scripts/download_model.py # 2. 构建镜像 docker-compose build # 3. 启动服务 docker-compose up -d # 4. 测试API curl -X POST http://localhost:8000/query \ -H Content-Type: application/json \ -d {question: 什么是RAG, top_k: 2}6. 监控、日志与可观测性部署上线只是开始保证服务稳定运行更需要监控。对于AI应用除了常规指标还需关注模型相关指标。6.1 集成Prometheus监控在FastAPI应用中集成Prometheus客户端暴露指标。# app/monitoring.py from prometheus_fastapi_instrumentator import Instrumentator import prometheus_client as prom from typing import Callable import time # 自定义指标记录每次查询的token数和延迟 QUERY_DURATION prom.Histogram( rag_query_duration_seconds, Time spent processing a RAG query, buckets(0.1, 0.5, 1.0, 2.0, 5.0, 10.0) ) TOKENS_GENERATED prom.Counter( rag_tokens_generated_total, Total tokens generated by the LLM ) def monitor_query(func: Callable) - Callable: 装饰器用于监控RAG查询 async def wrapper(*args, **kwargs): start_time time.time() try: result await func(*args, **kwargs) duration time.time() - start_time QUERY_DURATION.observe(duration) # 假设result包含token数 if hasattr(result, token_count): TOKENS_GENERATED.inc(result.token_count) return result except Exception as e: # 可以记录错误指标 raise e return wrapper # 在main.py中初始化 # from app.monitoring import Instrumentator # Instrumentator().instrument(app).expose(app)6.2 配置Grafana仪表盘通过Docker Compose快速搭建监控栈。# docker-compose.monitoring.yml version: 3.8 services: prometheus: image: prom/prometheus:latest container_name: prometheus volumes: - ./prometheus.yml:/etc/prometheus/prometheus.yml - prom_data:/prometheus command: - --config.file/etc/prometheus/prometheus.yml - --storage.tsdb.path/prometheus - --web.console.libraries/etc/prometheus/console_libraries - --web.console.templates/etc/prometheus/consoles - --storage.tsdb.retention.time200h - --web.enable-lifecycle ports: - 9090:9090 restart: unless-stopped grafana: image: grafana/grafana:latest container_name: grafana volumes: - grafana_data:/var/lib/grafana - ./grafana/provisioning:/etc/grafana/provisioning environment: - GF_SECURITY_ADMIN_PASSWORDadmin ports: - 3000:3000 restart: unless-stopped depends_on: - prometheus volumes: prom_data: grafana_data:对应的Prometheus配置# prometheus.yml global: scrape_interval: 15s evaluation_interval: 15s scrape_configs: - job_name: rag-api static_configs: - targets: [host.docker.internal:8000] # 或服务名如 rag-api:8000 metrics_path: /metrics7. 常见问题与排查指南在构建和部署AI应用时以下问题最为常见。问题现象可能原因排查方式解决方案容器启动失败提示CUDA错误1. 宿主机无GPU/NVIDIA驱动2. Docker未安装NVIDIA Container Toolkit3. 基础镜像CUDA版本不匹配1.nvidia-smi检查驱动2.docker run --rm --gpus all nvidia/cuda:12.1.0-base nvidia-smi测试3. 检查Dockerfile FROM镜像标签1. 安装正确版本的NVIDIA驱动和Docker GPU支持2. 使用nvidia/cuda官方镜像并匹配宿主机CUDA版本模型加载慢首次请求超时1. 模型文件过大从远程加载2. 冷启动未做模型预热3. 磁盘IO慢1. 观察容器日志查看加载阶段2. 检查模型文件是否在镜像内或持久化卷中1. 将模型打包进镜像或使用持久化卷2. 在应用启动时startup_event预加载模型3. 使用更快的存储如SSDAPI响应慢吞吐量低1. 模型未量化推理速度慢2. 未使用GPU或GPU型号旧3. 批处理batching未开启4. 向量检索未优化1. 使用perf或nvtop监控资源2. 检查推理框架配置如vLLM的tensor并行1. 将模型量化为INT8/INT4如GGUF格式2. 使用vLLM、TGI等高性能推理框架3. 对向量检索使用FAISS或优化Chroma配置内存/显存溢出OOM1. 模型参数过大2. 并发请求过多3. 内存泄漏1. 监控容器内存使用docker stats2. 检查Python内存分析工具1. 使用量化模型减少内存占用2. 在K8s中设置合理的resources.limits3. 实现请求队列或限流向量检索准确率低1. 文本分块chunk策略不当2. 嵌入模型不适合领域3. top_k参数太小1. 检查检索出的文档相关性2. 评估不同嵌入模型在领域数据上的表现1. 调整分块大小和重叠度2. 在领域数据上微调嵌入模型或更换模型3. 增加top_k并结合重排序re-ranking依赖版本冲突1. PyTorch/CUDA版本不匹配2. 不同AI库版本要求冲突1. 查看错误堆栈信息2. 使用pip check或uv tree1. 严格锁定所有依赖版本pyproject.toml2. 使用Docker隔离环境3. 优先使用框架官方推荐的版本组合8. 最佳实践与工程建议基于大量项目经验以下实践能显著提升AI应用的工程化水平。模型与代码分离管理永远不要将大模型文件几个GB提交到Git仓库。使用.gitignore忽略models/目录。使用独立的模型存储如S3、NAS、Hugging Face Hub和版本控制如DVC。在构建时通过脚本下载模型或使用持久化存储卷在运行时挂载。配置外部化与安全所有配置模型路径、API密钥、超参数必须通过环境变量或配置文件管理严禁硬编码。敏感信息如API Key使用K8s Secret、Docker Secret或专门的秘钥管理服务如HashiCorp Vault。示例# 错误做法代码中写死 # api_key sk-123456 # 正确做法从环境变量读取 import os api_key os.getenv(OPENAI_API_KEY) if not api_key: raise ValueError(OPENAI_API_KEY environment variable not set)构建缓存优化合理设计Dockerfile将变化频率低的层如系统包安装、基础依赖放在前面变化频率高的层如应用代码放在后面。利用Docker BuildKit的缓存机制和多阶段构建避免重复下载模型和安装依赖。健康检查与就绪探针为服务添加/health端点实时反映服务状态如模型是否加载完成。在K8s和Docker Compose中配置livenessProbe和readinessProbe实现故障自愈和优雅流量处理。# docker-compose.yml 片段 healthcheck: test: [CMD, curl, -f, http://localhost:8000/health] interval: 30s timeout: 10s retries: 3 start_period: 60s # 给予足够的启动时间日志结构化使用JSON格式输出日志便于后续使用ELK等工具收集和分析。记录关键信息请求ID、用户ID脱敏后、模型名称、输入token数、输出token数、耗时、错误码。import json import logging import uuid from contextvars import ContextVar request_id_ctx ContextVar(request_id, default) class JsonFormatter(logging.Formatter): def format(self, record): log_record { timestamp: self.formatTime(record), level: record.levelname, request_id: request_id_ctx.get(), message: record.getMessage(), module: record.module, } if record.exc_info: log_record[exception] self.formatException(record.exc_info) return json.dumps(log_record, ensure_asciiFalse)制定回滚与降级策略每次部署必须有清晰的版本标签如Docker镜像的:v1.2.3。在K8s中使用Deployment的滚动更新策略并确保能快速回滚到上一版本。为AI服务设计降级方案当主要模型服务不可用时可降级到更轻量的模型或返回预定义的兜底答案。掌握从环境构建、镜像打包、服务部署到监控运维的完整技能栈是让AI应用从实验走向生产的关键。这要求开发者不仅关注算法效果更要像一名软件工程师一样思考基础设施、可靠性和可维护性。建议从一个小而具体的项目开始实践上述的每一个步骤逐步构建起属于自己的AI工程化体系。 AI应用工程化实战：从模型到服务的构建与部署全流程指南
如果你最近在关注AI应用开发可能会发现一个有趣的现象很多开发者包括一些经验丰富的工程师在尝试将AI模型或Agent落地时常常会卡在同一个环节不是模型调参也不是算法优化而是如何把一个AI想法稳定、高效、可维护地“构建”和“部署”成一个真正的应用。你或许已经用ollama跑通了本地大模型用Dify或FastAPI搭起了RAG问答的demo甚至用Spring AI写好了业务逻辑。但当你想把这个“玩具”交给团队测试或者放到生产环境服务真实用户时问题就接踵而至环境依赖混乱、服务启动失败、资源消耗失控、版本回退困难……原本炫酷的AI能力瞬间被工程化的琐碎细节拖垮。这引出了本文的核心判断在AI应用开发中最重要的技能可能不再是钻研某个前沿模型而是掌握一套标准、可靠的构建与部署工程化能力。这决定了你的AI想法是止步于个人笔记本上的Demo还是能成长为支撑业务的服务。本文将抛开泛泛而谈直接切入构建Build与部署Deploy的核心流程、实用工具链和避坑指南目标是让你读完就能着手优化自己的AI项目工程体系。1. 重新理解“构建”与“部署”AI应用的特殊性在传统Web开发中构建通常指编译、打包部署则是将产物放到服务器运行。但对于AI应用尤其是涉及大模型的场景这两个环节的内涵和外延都发生了显著变化。构建Build在AI语境下至少包含三层代码构建与传统应用类似处理依赖安装、代码打包如Python wheel、Docker镜像。模型构建处理模型文件的下载、转换、量化、裁剪。例如将Hugging Face上的.safetensors模型转换为llama.cpp支持的GGUF格式就是一个关键的构建步骤。环境构建创建包含特定CUDA版本、Python版本、系统库的确定性运行环境。AI库如PyTorch, transformers对系统环境极为敏感。部署Deploy则面临新挑战资源异构性可能需要CPU、GPU甚至特定型号、大内存等不同资源。服务模式多样性可能是常驻的API服务如用FastAPI封装模型也可能是按需调用的Serverless函数或是批处理任务。弹性与成本如何根据负载自动扩缩容同时控制GPU等昂贵资源的成本。监控与观测不仅要监控服务状态还要监控模型性能延迟、吞吐量、资源使用率GPU显存和业务指标回答准确率。忽视这些特殊性直接套用传统的Java Web项目部署经验是很多AI应用项目陷入混乱的根源。2. 环境准备确立标准化的起点混乱从环境开始。确保团队每个成员、每台服务器都有一致的起点是后续所有工作的基础。2.1 核心工具链清单以下工具构成了现代AI应用构建部署的基石建议优先掌握工具类别推荐工具解决的核心问题环境与依赖管理Docker, Conda, Poetry, uv创建隔离、可复现的Python/系统环境。模型管理与服务化Ollama, vLLM, TensorRT-LLM, llama.cpp高效加载、运行和提供大模型推理服务。API框架与编排FastAPI, LangChain, LlamaIndex, Spring AI将模型能力封装成API并编排复杂AI工作流。容器编排与部署Docker Compose, Kubernetes (K8s), Docker Swarm在多台机器上编排、管理和扩展容器化应用。配置与秘钥管理Docker环境变量, Kubernetes ConfigMap/Secret, Vault安全地管理应用配置和敏感信息如API密钥。监控与日志Prometheus, Grafana, ELK Stack收集指标、可视化性能、集中管理日志。2.2 基础环境配置示例以一个基于Python的AI API项目为例第一步是锁定环境。使用pyproject.toml和uv管理依赖推荐uv是一个用Rust写的极速Python包管理器和解析器比传统pip快一个数量级。# pyproject.toml [project] name ai-chat-api version 0.1.0 dependencies [ fastapi0.104.0, uvicorn[standard]0.24.0, pydantic2.5.0, httpx0.25.0, # AI相关核心依赖严格锁定版本 transformers4.36.0, torch2.1.0, sentence-transformers2.2.2, ] [project.optional-dependencies] dev [pytest, black, isort, mypy]然后使用uv创建虚拟环境并安装依赖# 同步安装生产依赖 uv sync # 激活虚拟环境uv自动管理 source .venv/bin/activate # Linux/macOS # .venv\Scripts\activate # Windows使用 Dockerfile 定义完整运行时环境这是确保环境一致性的终极手段。# Dockerfile # 使用带有CUDA基础镜像确保GPU支持 FROM nvidia/cuda:12.1.0-runtime-ubuntu22.04 # 设置工作目录 WORKDIR /app # 安装系统依赖 RUN apt-get update apt-get install -y \ python3.10 \ python3-pip \ curl \ rm -rf /var/lib/apt/lists/* # 使用uv进行高效的依赖安装 COPY pyproject.toml ./ RUN curl -LsSf https://astral.sh/uv/install.sh | sh \ /root/.cargo/bin/uv pip install -e . # 复制应用代码 COPY . . # 暴露端口 EXPOSE 8000 # 启动命令 CMD [uvicorn, main:app, --host, 0.0.0.0, --port, 8000]3. 构建流程实战从代码到可部署镜像构建的目标是产出一个包含所有代码、依赖、模型和配置的不可变制品通常是Docker镜像。3.1 多阶段构建优化镜像大小AI应用镜像往往很大几个GB因为包含了模型文件。多阶段构建可以显著优化。# Dockerfile.multistage # 第一阶段构建阶段 FROM python:3.10-slim AS builder WORKDIR /app COPY pyproject.toml ./ RUN pip install --user --no-cache-dir uv \ /root/.local/bin/uv pip install --system --no-cache-dir -e . # 第二阶段模型下载与处理阶段 FROM builder AS model-downloader WORKDIR /models # 使用 huggingface-cli 安全下载模型需提前配置HF_TOKEN RUN pip install --no-cache-dir huggingface-hub \ python -c from huggingface_hub import snapshot_download; snapshot_download(repo_idBAAI/bge-small-zh-v1.5, local_dirbge-embedding) # 第三阶段最终运行阶段 FROM python:3.10-slim WORKDIR /app # 从builder阶段复制已安装的Python包 COPY --frombuilder /usr/local/lib/python3.10/site-packages /usr/local/lib/python3.10/site-packages COPY --frombuilder /usr/local/bin /usr/local/bin # 从model-downloader阶段复制模型 COPY --frommodel-downloader /models /app/models # 复制应用代码 COPY . . # 创建非root用户运行提高安全性 RUN useradd -m -u 1000 appuser chown -R appuser /app USER appuser EXPOSE 8000 CMD [uvicorn, main:app, --host, 0.0.0.0, --port, 8000]3.2 集成模型构建步骤对于需要转换格式的模型如转GGUF构建流程中应包含此步骤。# 一个示例的构建脚本 build.sh #!/bin/bash set -e # 遇到错误即停止 echo 1. 下载原始模型... python scripts/download_model.py --repo_id Qwen/Qwen2.5-7B-Instruct echo 2. 转换模型格式为GGUF用于llama.cpp... # 假设使用 llama.cpp 的 convert.py python /path/to/llama.cpp/convert.py \ --outfile ./models/qwen2.5-7b-instruct.gguf \ --outtype q4_0 # 量化类型 echo 3. 构建Docker镜像... docker build -f Dockerfile.multistage -t my-ai-app:latest . echo 4. 保存镜像到文件便于传输... docker save my-ai-app:latest -o my-ai-app-latest.tar4. 部署策略深度解析从单机到云原生部署方式的选择直接关系到应用的稳定性、成本和运维复杂度。4.1 单机部署最简单快速的起点使用Docker Compose可以在单台机器上轻松定义和运行多容器应用非常适合开发、测试和小型生产环境。# docker-compose.yml version: 3.8 services: ai-api: build: . image: my-ai-app:latest container_name: ai-api-service ports: - 8000:8000 environment: - MODEL_PATH/app/models/qwen2.5-7b-instruct.gguf - EMBEDDING_MODEL_PATH/app/models/bge-embedding - OPENAI_API_KEY${OPENAI_API_KEY} # 从.env文件读取 volumes: # 挂载模型目录避免每次构建都重新下载 - ./models:/app/models # 挂载日志目录 - ./logs:/app/logs deploy: resources: reservations: devices: - driver: nvidia count: 1 capabilities: [gpu] # 声明需要GPU restart: unless-stopped # 可以添加其他服务如数据库、缓存 redis: image: redis:alpine ports: - 6379:6379启动命令# 启动所有服务 docker-compose up -d # 查看日志 docker-compose logs -f ai-api4.2 Kubernetes部署生产级弹性与可靠性当需要高可用、自动扩缩容和复杂的服务治理时K8s是首选。以下是一个典型的Deployment和Service配置。# k8s-deployment.yaml apiVersion: apps/v1 kind: Deployment metadata: name: ai-api-deployment spec: replicas: 2 # 初始副本数 selector: matchLabels: app: ai-api template: metadata: labels: app: ai-api spec: containers: - name: ai-api image: my-registry.com/my-ai-app:latest ports: - containerPort: 8000 env: - name: MODEL_PATH value: /app/models/model.gguf - name: CUDA_VISIBLE_DEVICES value: 0 # 指定GPU resources: requests: memory: 8Gi cpu: 2 nvidia.com/gpu: 1 # 请求1个GPU limits: memory: 16Gi cpu: 4 nvidia.com/gpu: 1 # 限制使用1个GPU volumeMounts: - name: model-storage mountPath: /app/models readOnly: true volumes: - name: model-storage persistentVolumeClaim: claimName: model-pvc # 使用持久化存储卷存放大模型 nodeSelector: accelerator: nvidia-gpu # 调度到有GPU标签的节点 --- apiVersion: v1 kind: Service metadata: name: ai-api-service spec: selector: app: ai-api ports: - port: 80 targetPort: 8000 type: LoadBalancer # 或 ClusterIP根据需求使用Horizontal Pod Autoscaler (HPA)实现基于CPU/内存或自定义指标的自动扩缩容# k8s-hpa.yaml apiVersion: autoscaling/v2 kind: HorizontalPodAutoscaler metadata: name: ai-api-hpa spec: scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: ai-api-deployment minReplicas: 2 maxReplicas: 10 metrics: - type: Resource resource: name: cpu target: type: Utilization averageUtilization: 70 # CPU平均使用率超过70%时扩容 - type: Resource resource: name: memory target: type: Utilization averageUtilization: 804.3 Serverless部署极致弹性与成本优化对于流量波动大或希望零运维的场景可以考虑Serverless。例如使用Google Cloud Run或AWS Lambda需注意冷启动和GPU支持问题。# 一个适配Cloud Run/FastAPI的示例 main.py import os from fastapi import FastAPI, HTTPException from pydantic import BaseModel import torch from transformers import pipeline app FastAPI(titleAI Chat API) # 注意在Serverless中模型加载必须在全局范围或使用懒加载以应对冷启动 # 这里使用懒加载模式 _model None _pipe None def get_model(): global _model, _pipe if _model is None: model_id os.getenv(MODEL_ID, gpt2) _model pipeline(text-generation, modelmodel_id, device0 if torch.cuda.is_available() else -1) return _model class ChatRequest(BaseModel): prompt: str max_length: int 100 app.post(/chat) async def chat(request: ChatRequest): try: pipe get_model() result pipe(request.prompt, max_lengthrequest.max_length) return {response: result[0][generated_text]} except Exception as e: raise HTTPException(status_code500, detailstr(e)) app.get(/health) async def health(): return {status: healthy}部署到Cloud Run的命令# 构建并推送镜像 gcloud builds submit --tag gcr.io/PROJECT-ID/my-ai-app # 部署到Cloud Run分配GPU gcloud run deploy my-ai-app \ --image gcr.io/PROJECT-ID/my-ai-app \ --platform managed \ --region us-central1 \ --allow-unauthenticated \ --memory 8Gi \ --cpu 2 \ --gpu 1 \ --set-env-vars MODEL_IDQwen/Qwen2.5-7B-Instruct5. 核心应用示例构建一个本地RAG知识库问答系统让我们综合运用上述技能构建一个基于llama.cppQwen2.5-7BFastAPI的本地RAG系统。这个示例涵盖了从环境构建到服务部署的全流程。5.1 项目结构local-rag-system/ ├── Dockerfile ├── docker-compose.yml ├── requirements.txt ├── app/ │ ├── main.py # FastAPI 主应用 │ ├── embedding.py # 嵌入模型处理 │ ├── vector_store.py # 向量数据库操作 │ └── rag_chain.py # RAG 检索与生成链 ├── models/ │ └── (模型文件存放处) ├── data/ │ └── documents/ # 知识库文档 └── scripts/ └── download_model.py5.2 核心代码实现应用入口 (app/main.py)from fastapi import FastAPI, HTTPException from pydantic import BaseModel from typing import List, Optional import logging from app.rag_chain import RAGChain app FastAPI() rag_chain None logging.basicConfig(levellogging.INFO) logger logging.getLogger(__name__) class QueryRequest(BaseModel): question: str top_k: Optional[int] 3 class QueryResponse(BaseModel): answer: str sources: List[str] # 引用来源 app.on_event(startup) async def startup_event(): 启动时初始化RAG链避免每次请求都加载模型 global rag_chain try: # 这里会加载嵌入模型和LLM可能耗时较长 rag_chain RAGChain( embedding_model_path./models/bge-small-zh, llm_model_path./models/qwen2.5-7b-instruct.gguf, vector_store_path./data/vector_store ) logger.info(RAG chain initialized successfully.) except Exception as e: logger.error(fFailed to initialize RAG chain: {e}) raise app.post(/query, response_modelQueryResponse) async def query_knowledge_base(request: QueryRequest): if rag_chain is None: raise HTTPException(status_code503, detailService initializing) try: answer, source_docs rag_chain.query(request.question, top_krequest.top_k) return QueryResponse(answeranswer, sources[doc.metadata.get(source, ) for doc in source_docs]) except Exception as e: logger.error(fQuery error: {e}) raise HTTPException(status_code500, detailInternal server error) app.get(/health) async def health_check(): return {status: ready, model_loaded: rag_chain is not None}RAG链核心 (app/rag_chain.py)import os from typing import List, Tuple from langchain.text_splitter import RecursiveCharacterTextSplitter from langchain_community.vectorstores import Chroma from langchain_community.embeddings import HuggingFaceEmbeddings from langchain_community.llms import LlamaCpp from langchain.chains import RetrievalQA from langchain.prompts import PromptTemplate class RAGChain: def __init__(self, embedding_model_path: str, llm_model_path: str, vector_store_path: str): # 1. 初始化嵌入模型 self.embeddings HuggingFaceEmbeddings( model_nameembedding_model_path, model_kwargs{device: cpu}, # 或 cuda encode_kwargs{normalize_embeddings: True} ) # 2. 初始化向量数据库如果不存在则从文档创建 if not os.path.exists(vector_store_path): self._create_vector_store(vector_store_path) self.vector_store Chroma( persist_directoryvector_store_path, embedding_functionself.embeddings ) self.retriever self.vector_store.as_retriever(search_kwargs{k: 3}) # 3. 初始化本地LLM (llama.cpp) self.llm LlamaCpp( model_pathllm_model_path, n_ctx2048, # 上下文长度 n_threads4, # CPU线程数 temperature0.1, verboseFalse, ) # 4. 定义Prompt模板 prompt_template 基于以下上下文信息请回答问题。如果你不知道答案就说不知道不要编造。 上下文 {context} 问题{question} 答案 self.PROMPT PromptTemplate( templateprompt_template, input_variables[context, question] ) # 5. 构建检索问答链 self.qa_chain RetrievalQA.from_chain_type( llmself.llm, chain_typestuff, retrieverself.retriever, chain_type_kwargs{prompt: self.PROMPT}, return_source_documentsTrue ) def _create_vector_store(self, persist_path: str): 从文档目录创建向量存储 from langchain_community.document_loaders import DirectoryLoader, TextLoader loader DirectoryLoader(./data/documents, loader_clsTextLoader) documents loader.load() text_splitter RecursiveCharacterTextSplitter(chunk_size500, chunk_overlap50) splits text_splitter.split_documents(documents) vector_store Chroma.from_documents( documentssplits, embeddingself.embeddings, persist_directorypersist_path ) vector_store.persist() def query(self, question: str, top_k: int 3) - Tuple[str, List]: 执行查询 self.retriever.search_kwargs[k] top_k result self.qa_chain({query: question}) return result[result], result[source_documents]5.3 一键部署与运行使用docker-compose编排所有服务包括本示例的RAG API和一个简单的Web前端。# docker-compose.yml version: 3.8 services: rag-api: build: . image: local-rag-api:latest container_name: rag-api ports: - 8000:8000 volumes: - ./models:/app/models - ./data:/app/data environment: - EMBEDDING_MODEL_PATH/app/models/bge-small-zh - LLM_MODEL_PATH/app/models/qwen2.5-7b-instruct.gguf deploy: resources: reservations: devices: - driver: nvidia count: 1 capabilities: [gpu] restart: unless-stopped healthcheck: test: [CMD, curl, -f, http://localhost:8000/health] interval: 30s timeout: 10s retries: 3 web-ui: image: nginx:alpine container_name: rag-web-ui ports: - 8080:80 volumes: - ./web-ui:/usr/share/nginx/html depends_on: - rag-api构建并启动# 1. 下载模型假设脚本已存在 python scripts/download_model.py # 2. 构建镜像 docker-compose build # 3. 启动服务 docker-compose up -d # 4. 测试API curl -X POST http://localhost:8000/query \ -H Content-Type: application/json \ -d {question: 什么是RAG, top_k: 2}6. 监控、日志与可观测性部署上线只是开始保证服务稳定运行更需要监控。对于AI应用除了常规指标还需关注模型相关指标。6.1 集成Prometheus监控在FastAPI应用中集成Prometheus客户端暴露指标。# app/monitoring.py from prometheus_fastapi_instrumentator import Instrumentator import prometheus_client as prom from typing import Callable import time # 自定义指标记录每次查询的token数和延迟 QUERY_DURATION prom.Histogram( rag_query_duration_seconds, Time spent processing a RAG query, buckets(0.1, 0.5, 1.0, 2.0, 5.0, 10.0) ) TOKENS_GENERATED prom.Counter( rag_tokens_generated_total, Total tokens generated by the LLM ) def monitor_query(func: Callable) - Callable: 装饰器用于监控RAG查询 async def wrapper(*args, **kwargs): start_time time.time() try: result await func(*args, **kwargs) duration time.time() - start_time QUERY_DURATION.observe(duration) # 假设result包含token数 if hasattr(result, token_count): TOKENS_GENERATED.inc(result.token_count) return result except Exception as e: # 可以记录错误指标 raise e return wrapper # 在main.py中初始化 # from app.monitoring import Instrumentator # Instrumentator().instrument(app).expose(app)6.2 配置Grafana仪表盘通过Docker Compose快速搭建监控栈。# docker-compose.monitoring.yml version: 3.8 services: prometheus: image: prom/prometheus:latest container_name: prometheus volumes: - ./prometheus.yml:/etc/prometheus/prometheus.yml - prom_data:/prometheus command: - --config.file/etc/prometheus/prometheus.yml - --storage.tsdb.path/prometheus - --web.console.libraries/etc/prometheus/console_libraries - --web.console.templates/etc/prometheus/consoles - --storage.tsdb.retention.time200h - --web.enable-lifecycle ports: - 9090:9090 restart: unless-stopped grafana: image: grafana/grafana:latest container_name: grafana volumes: - grafana_data:/var/lib/grafana - ./grafana/provisioning:/etc/grafana/provisioning environment: - GF_SECURITY_ADMIN_PASSWORDadmin ports: - 3000:3000 restart: unless-stopped depends_on: - prometheus volumes: prom_data: grafana_data:对应的Prometheus配置# prometheus.yml global: scrape_interval: 15s evaluation_interval: 15s scrape_configs: - job_name: rag-api static_configs: - targets: [host.docker.internal:8000] # 或服务名如 rag-api:8000 metrics_path: /metrics7. 常见问题与排查指南在构建和部署AI应用时以下问题最为常见。问题现象可能原因排查方式解决方案容器启动失败提示CUDA错误1. 宿主机无GPU/NVIDIA驱动2. Docker未安装NVIDIA Container Toolkit3. 基础镜像CUDA版本不匹配1.nvidia-smi检查驱动2.docker run --rm --gpus all nvidia/cuda:12.1.0-base nvidia-smi测试3. 检查Dockerfile FROM镜像标签1. 安装正确版本的NVIDIA驱动和Docker GPU支持2. 使用nvidia/cuda官方镜像并匹配宿主机CUDA版本模型加载慢首次请求超时1. 模型文件过大从远程加载2. 冷启动未做模型预热3. 磁盘IO慢1. 观察容器日志查看加载阶段2. 检查模型文件是否在镜像内或持久化卷中1. 将模型打包进镜像或使用持久化卷2. 在应用启动时startup_event预加载模型3. 使用更快的存储如SSDAPI响应慢吞吐量低1. 模型未量化推理速度慢2. 未使用GPU或GPU型号旧3. 批处理batching未开启4. 向量检索未优化1. 使用perf或nvtop监控资源2. 检查推理框架配置如vLLM的tensor并行1. 将模型量化为INT8/INT4如GGUF格式2. 使用vLLM、TGI等高性能推理框架3. 对向量检索使用FAISS或优化Chroma配置内存/显存溢出OOM1. 模型参数过大2. 并发请求过多3. 内存泄漏1. 监控容器内存使用docker stats2. 检查Python内存分析工具1. 使用量化模型减少内存占用2. 在K8s中设置合理的resources.limits3. 实现请求队列或限流向量检索准确率低1. 文本分块chunk策略不当2. 嵌入模型不适合领域3. top_k参数太小1. 检查检索出的文档相关性2. 评估不同嵌入模型在领域数据上的表现1. 调整分块大小和重叠度2. 在领域数据上微调嵌入模型或更换模型3. 增加top_k并结合重排序re-ranking依赖版本冲突1. PyTorch/CUDA版本不匹配2. 不同AI库版本要求冲突1. 查看错误堆栈信息2. 使用pip check或uv tree1. 严格锁定所有依赖版本pyproject.toml2. 使用Docker隔离环境3. 优先使用框架官方推荐的版本组合8. 最佳实践与工程建议基于大量项目经验以下实践能显著提升AI应用的工程化水平。模型与代码分离管理永远不要将大模型文件几个GB提交到Git仓库。使用.gitignore忽略models/目录。使用独立的模型存储如S3、NAS、Hugging Face Hub和版本控制如DVC。在构建时通过脚本下载模型或使用持久化存储卷在运行时挂载。配置外部化与安全所有配置模型路径、API密钥、超参数必须通过环境变量或配置文件管理严禁硬编码。敏感信息如API Key使用K8s Secret、Docker Secret或专门的秘钥管理服务如HashiCorp Vault。示例# 错误做法代码中写死 # api_key sk-123456 # 正确做法从环境变量读取 import os api_key os.getenv(OPENAI_API_KEY) if not api_key: raise ValueError(OPENAI_API_KEY environment variable not set)构建缓存优化合理设计Dockerfile将变化频率低的层如系统包安装、基础依赖放在前面变化频率高的层如应用代码放在后面。利用Docker BuildKit的缓存机制和多阶段构建避免重复下载模型和安装依赖。健康检查与就绪探针为服务添加/health端点实时反映服务状态如模型是否加载完成。在K8s和Docker Compose中配置livenessProbe和readinessProbe实现故障自愈和优雅流量处理。# docker-compose.yml 片段 healthcheck: test: [CMD, curl, -f, http://localhost:8000/health] interval: 30s timeout: 10s retries: 3 start_period: 60s # 给予足够的启动时间日志结构化使用JSON格式输出日志便于后续使用ELK等工具收集和分析。记录关键信息请求ID、用户ID脱敏后、模型名称、输入token数、输出token数、耗时、错误码。import json import logging import uuid from contextvars import ContextVar request_id_ctx ContextVar(request_id, default) class JsonFormatter(logging.Formatter): def format(self, record): log_record { timestamp: self.formatTime(record), level: record.levelname, request_id: request_id_ctx.get(), message: record.getMessage(), module: record.module, } if record.exc_info: log_record[exception] self.formatException(record.exc_info) return json.dumps(log_record, ensure_asciiFalse)制定回滚与降级策略每次部署必须有清晰的版本标签如Docker镜像的:v1.2.3。在K8s中使用Deployment的滚动更新策略并确保能快速回滚到上一版本。为AI服务设计降级方案当主要模型服务不可用时可降级到更轻量的模型或返回预定义的兜底答案。掌握从环境构建、镜像打包、服务部署到监控运维的完整技能栈是让AI应用从实验走向生产的关键。这要求开发者不仅关注算法效果更要像一名软件工程师一样思考基础设施、可靠性和可维护性。建议从一个小而具体的项目开始实践上述的每一个步骤逐步构建起属于自己的AI工程化体系。