当前位置：首页 > news >正文

从模型到应用：基于FastAPI与Docker的AI服务化实战

news 2026/5/27 23:11:37

1. 项目概述从模型到应用的最后一公里“我们训练了一个准确率高达95%的情绪识别模型但不知道怎么把它变成一个能用的App。”——这是我过去几年里从数据科学家和机器学习工程师那里听到最多的一句话。今天我想以一个完整项目的复盘来聊聊这个从“模型文件”到“可部署AI应用”的最后一公里。这个项目我称之为“MoodSense AI”一个能够通过分析文本实时感知用户情绪的轻量级应用。MoodSense AI的核心目标很明确将一个训练好的情绪分类机器学习模型封装成一个稳定、高效、易于扩展的Web服务并最终提供一个简洁友好的用户界面。听起来像是标准的MLOps流程没错但魔鬼藏在细节里。这个项目涉及模型服务化、API设计、前后端集成、性能优化以及持续维护等一系列环环相扣的环节。无论你是刚入行的机器学习工程师还是想为自己的研究模型找个“出口”的数据科学家这篇文章将带你走完从model.pkl到用户指尖可交互产品的完整路径。我们会避开那些华而不实的理论聚焦于我在实际部署中踩过的坑、验证过的方案以及那些让应用真正“跑起来”的关键决策。2. 整体架构设计与技术选型考量2.1 为什么选择“模型即服务”的微服务架构在项目启动时我们面临几个核心选择是将模型直接嵌入到Web应用的后端代码中还是将其作为独立的服务进行部署经过权衡我们选择了后者即构建一个独立的模型推理服务。这么做的理由很充分首先解耦与独立伸缩。模型推理通常对计算资源尤其是GPU/CPU的需求模式与Web业务逻辑服务器不同。业务服务器可能面临突发的高并发请求而模型服务则更关注推理的稳定性和低延迟。将它们分离允许我们根据各自的压力独立进行水平扩展。例如在流量低谷期我们可以缩减Web服务器实例但保持模型服务稳定运行以备不时之需。其次技术栈灵活性。我们的情绪识别模型基于PyTorch训练。Web后端可能使用FastAPI或Django。如果模型嵌入后端后端环境就必须包含PyTorch及其庞大的依赖这可能导致部署包臃肿且版本管理复杂。独立服务允许模型服务专注于Python科学计算生态而Web服务可以使用更轻量、更适合IO密集型任务的技术栈。最后模型更新与回滚的便利性。模型需要迭代更新。如果模型嵌入应用每次更新都可能需要重新构建和部署整个应用风险高、流程长。独立的模型服务可以通过更换镜像或模型文件进行热更新或A/B测试对前端应用几乎无感大大提升了运维的敏捷性。注意对于超轻量级如几MB且推理极快的模型或者对延迟要求极其苛刻要求微秒级的场景嵌入部署以减少网络开销可能是更好的选择。但对于MoodSense AI这类模型几百MB且要求高可用和易维护的场景微服务架构是更稳妥的长期选择。2.2 技术栈的敲定过程基于上述架构我们确定了以下技术栈每一个选择背后都有实际的考量模型服务层FastAPI UvicornFastAPI 替代了早期考虑的Flask。原因在于FastAPI天生支持异步async/await对于IO密集型如等待模型推理的API性能更好。它自动生成的交互式API文档Swagger UI对于前后端联调和测试是巨大的生产力工具。其基于Pydantic的数据验证能让我们在请求入口就确保输入数据的格式正确避免脏数据进入模型。Uvicorn 一个快速的ASGI服务器是运行FastAPI应用的绝佳搭档。我们用它来在生产环境承载服务。模型推理核心PyTorch ONNX Runtime可选PyTorch 训练框架自然也是推理的首选。我们使用torch.jit.trace或torch.jit.script将模型转换为TorchScript格式这能提升推理速度并实现模型与代码的分离。ONNX Runtime 作为一个性能优化选项。我们将PyTorch模型导出为ONNX格式然后用ONNX Runtime进行推理。实测在某些CPU环境下ONNX Runtime能带来20%-30%的推理速度提升且对内存的使用更高效。我们将其设计为可配置的后端通过环境变量切换。Web应用层Vue.js Element PlusVue.js 选择它而非React主要是考虑到其渐进式框架的特性和更平缓的学习曲线适合快速构建交互界面。其响应式数据绑定和组件化开发能让我们高效地构建实时显示情绪分析结果、历史记录等复杂交互。Element Plus 基于Vue 3的UI组件库提供了丰富的、设计良好的基础组件按钮、输入框、图表等能极大加速前端开发保证界面风格统一。部署与运维Docker Docker Compose NginxDocker 容器化是保证环境一致性的不二法门。我们为模型服务和Web应用分别构建Docker镜像确保从开发到测试再到生产环境完全一致“在我机器上能跑”的问题彻底成为历史。Docker Compose 用于本地开发和轻量级单机部署。一个docker-compose.yml文件就能定义并启动所有服务模型服务、Web前端、Nginx简化了协作和演示流程。Nginx 作为反向代理和静态文件服务器。它接收所有外部请求将API请求转发给模型服务将页面请求转发给前端服务同时处理负载均衡、SSL终止等任务。这个技术栈组合在开发效率、运行性能和运维复杂度之间取得了良好的平衡。3. 模型服务化的核心实现细节3.1 模型封装与加载优化模型服务化的第一步是把训练好的模型“包”起来。我们创建了一个ModelHandler类它的职责是管理模型的生命周期。# model_handler.py import torch import logging from typing import Dict, Any from pathlib import Path class MoodSenseModelHandler: def __init__(self, model_path: str, use_onnx: bool False): self.logger logging.getLogger(__name__) self.use_onnx use_onnx self.model None self.tokenizer None # 假设我们使用基于Transformer的模型 self._load_model(model_path) def _load_model(self, model_path: str): 加载模型支持PyTorch和ONNX两种格式 model_path Path(model_path) if not model_path.exists(): raise FileNotFoundError(fModel file not found: {model_path}) if self.use_onnx and model_path.suffix .onnx: # 使用ONNX Runtime加载 import onnxruntime as ort self.logger.info(fLoading ONNX model from {model_path}) self.session ort.InferenceSession(str(model_path)) # 注意ONNX模型需要额外的预处理/后处理适配 else: # 使用PyTorch加载TorchScript self.logger.info(fLoading TorchScript model from {model_path}) self.model torch.jit.load(model_path, map_locationcpu) self.model.eval() # 至关重要设置为评估模式 self.logger.info(Model loaded successfully.) def preprocess(self, text: str) - Dict[str, torch.Tensor]: 文本预处理分词、转换为ID、构建attention mask等 # 这里调用tokenizer实际项目中可能是Hugging Face的AutoTokenizer # 示例化处理 inputs self.tokenizer(text, return_tensorspt, paddingTrue, truncationTrue, max_length128) return inputs def predict(self, inputs: Dict[str, torch.Tensor]) - Dict[str, Any]: 执行模型推理 with torch.no_grad(): # 禁用梯度计算节省内存和计算 if self.use_onnx: # ONNX推理 ort_inputs {self.session.get_inputs()[0].name: inputs[input_ids].numpy()} ort_outputs self.session.run(None, ort_inputs) logits torch.tensor(ort_outputs[0]) else: # PyTorch推理 logits self.model(**inputs) probabilities torch.softmax(logits, dim-1) predicted_class_id torch.argmax(probabilities, dim-1).item() confidence probabilities[0][predicted_class_id].item() return { emotion: self.id2label[predicted_class_id], # 映射回情绪标签 confidence: round(confidence, 4), probabilities: {self.id2label[i]: round(prob, 4) for i, prob in enumerate(probabilities[0].tolist())} } async def async_predict(self, text: str): 异步预测接口供FastAPI调用 # 预处理是CPU密集型可以放在线程池中运行避免阻塞事件循环 inputs await asyncio.to_thread(self.preprocess, text) result self.predict(inputs) return result关键点与避坑指南model.eval() 加载PyTorch模型后务必调用这会关闭Dropout和BatchNorm层的训练模式行为保证推理结果的一致性。torch.no_grad() 在推理上下文中使用能显著减少内存消耗并加速计算。线程池处理CPU密集型任务 FastAPI是异步框架但模型加载、预处理分词是CPU密集型操作。如果直接在异步函数中执行会阻塞整个事件循环。使用asyncio.to_thread将其抛到线程池中执行是标准做法。模型热更新我们设计了一个简单的健康检查接口和模型重载接口。通过发送特定信号或调用管理API服务可以动态加载新的模型文件而无需重启服务。这需要处理好旧模型请求的完成和新模型加载的原子性。3.2 高性能API设计与最佳实践有了模型处理器接下来就是用FastAPI将其暴露为HTTP API。# main.py from fastapi import FastAPI, HTTPException, BackgroundTasks from pydantic import BaseModel, Field from contextlib import asynccontextmanager import asyncio from model_handler import MoodSenseModelHandler import os # 定义请求响应模型 class TextRequest(BaseModel): text: str Field(..., min_length1, max_length500, example今天阳光明媚我感到非常开心) session_id: str Field(None, description可选会话ID用于追踪同一用户的多轮分析) class PredictionResponse(BaseModel): emotion: str confidence: float probabilities: dict request_id: str latency_ms: float # 应用生命周期管理 asynccontextmanager async def lifespan(app: FastAPI): # 启动时加载模型 model_path os.getenv(MODEL_PATH, ./model/traced_model.pt) use_onnx os.getenv(USE_ONNX, false).lower() true app.state.model_handler MoodSenseModelHandler(model_path, use_onnx) app.state.request_counter 0 yield # 关闭时清理资源 # 如果有GPU可能需要显式释放显存 if torch.cuda.is_available(): torch.cuda.empty_cache() app FastAPI(titleMoodSense AI API, lifespanlifespan) app.post(/predict, response_modelPredictionResponse, summary分析文本情绪) async def predict_emotion(request: TextRequest, background_tasks: BackgroundTasks): 接收一段文本返回分析出的主要情绪、置信度及各情绪概率分布。 start_time asyncio.get_event_loop().time() app.state.request_counter 1 request_id freq_{app.state.request_counter:08d} try: # 异步调用模型推理 result await app.state.model_handler.async_predict(request.text) except Exception as e: app.logger.error(fPrediction failed for request {request_id}: {e}, exc_infoTrue) raise HTTPException(status_code500, detailInternal server error during prediction.) latency_ms (asyncio.get_event_loop().time() - start_time) * 1000 # 可以在这里添加后台任务例如将请求日志和结果异步写入数据库或消息队列 # background_tasks.add_task(log_to_db, request_id, request.text, result, latency_ms) return PredictionResponse( emotionresult[emotion], confidenceresult[confidence], probabilitiesresult[probabilities], request_idrequest_id, latency_msround(latency_ms, 2) ) app.get(/health) async def health_check(): 健康检查端点用于K8s或负载均衡器探活 return {status: healthy, model_loaded: app.state.model_handler is not None} app.get(/metrics) async def get_metrics(): 简单的监控指标端点可集成Prometheus return { total_requests: app.state.request_counter, # 可以添加更多指标如平均延迟、错误率等 }API设计心得输入验证充分利用Pydantic。min_length和max_length能直接过滤掉无效输入避免不必要的模型调用。example字段能让Swagger文档更友好。错误处理一定要在模型调用处包裹try-except并记录详细的错误日志exc_infoTrue。向客户端返回通用的500错误避免泄露内部模型或代码信息。异步与后台任务核心推理路径保持异步。像日志记录、数据统计这类非即时需求交给BackgroundTasks能显著降低API的响应延迟。监控与可观测性/health和/metrics端点是生产级服务的标配。后期可以轻松集成Prometheus进行指标采集用Grafana展示。请求标识request_id 为每个请求生成唯一ID并贯穿日志和响应。这在排查分布式系统中的问题时是无价之宝。4. 前端交互与工程化实践4.1 构建响应式情绪分析界面前端的目标是提供一个直观、即时反馈的界面。我们使用Vue 3的Composition API来组织代码。!-- EmotionAnalyzer.vue -- template div classanalyzer-container el-card classinput-card template #header span 输入你想分析的文字/span /template el-input v-modelinputText typetextarea :rows4 placeholder请输入任何文字例如项目终于上线了但感觉压力好大... :maxlength500 show-word-limit keyup.enter.ctrlanalyze / div classaction-bar el-button typeprimary :loadingisAnalyzing clickanalyze {{ isAnalyzing ? 分析中... : 开始分析 }} /el-button el-button clickinputText 清空/el-button span classhint提示可按 CtrlEnter 快速提交/span /div /el-card el-card classresult-card v-ifresult template #header span 分析结果/span el-tag :typegetEmotionTagType(result.emotion) sizelarge {{ result.emotion }} /el-tag /template div classresult-body div classconfidence置信度: strong{{ (result.confidence * 100).toFixed(1) }}%/strong/div div classprob-chart div v-for(prob, emotion) in result.probabilities :keyemotion classprob-item span classemotion-label{{ emotion }}/span el-progress :percentageprob * 100 :stroke-width16 :colorgetEmotionColor(emotion) :show-textfalse / span classprob-value{{ (prob * 100).toFixed(1) }}%/span /div /div div classmeta请求ID: {{ result.request_id }} | 耗时: {{ result.latency_ms }} ms/div /div /el-card !-- 历史记录组件 -- HistoryPanel :recordshistoryRecords select-recordloadRecord / /div /template script setup import { ref, computed } from vue import { ElMessage } from element-plus import { analyzeText } from /api/moodApi import HistoryPanel from ./HistoryPanel.vue const inputText ref() const isAnalyzing ref(false) const result ref(null) const historyRecords ref([]) // 从本地存储或API获取 const analyze async () { if (!inputText.value.trim()) { ElMessage.warning(请输入一些内容再分析哦~) return } isAnalyzing.value true try { const response await analyzeText({ text: inputText.value }) result.value response.data // 保存到历史记录 historyRecords.value.unshift({ text: inputText.value, ...response.data, timestamp: new Date().toISOString() }) // 可选保存到localStorage saveHistoryToLocal() } catch (error) { ElMessage.error(分析失败: ${error.response?.data?.detail || error.message}) console.error(API Error:, error) } finally { isAnalyzing.value false } } // 工具函数根据情绪类型返回标签颜色和进度条颜色 const getEmotionTagType (emotion) { const map { 喜悦: success, 悲伤: info, 愤怒: danger, 恐惧: warning, 中立: } return map[emotion] || } const getEmotionColor (emotion) { const colorMap { 喜悦: #67C23A, 悲伤: #909399, 愤怒: #F56C6C, 恐惧: #E6A23C, 中立: #409EFF } return colorMap[emotion] || #909399 } /script前端开发要点用户体验提供多种交互方式按钮、快捷键CtrlEnter实时显示字数限制分析时显示加载状态这些都是提升用户体验的关键细节。结果可视化使用Element Plus的Tag和Progress组件将枯燥的概率数据转化为直观的色彩和进度条一目了然。错误友好提示捕获API错误并从错误响应中提取对用户友好的信息进行展示而不是显示原始的HTTP错误码。状态管理对于这个轻量应用使用ref和computed进行组件内状态管理足够了。如果功能变复杂如多用户、实时协作可以考虑引入Pinia。4.2 前后端联调与跨域问题解决开发阶段前端运行在localhost:8080后端API运行在localhost:8000这就遇到了经典的跨域CORS问题。我们在FastAPI后端通过中间件解决# main.py (追加) from fastapi.middleware.cors import CORSMiddleware # 在创建app后添加CORS中间件 app.add_middleware( CORSMiddleware, allow_origins[http://localhost:8080, https://your-production-domain.com], # 指定允许的前端地址 allow_credentialsTrue, allow_methods[*], # 允许所有方法 (GET, POST, etc.) allow_headers[*], # 允许所有头部 )实操心得在生产环境中allow_origins应该严格配置为确切的前端域名而不是[*]这是基本的安全最佳实践。对于更复杂的情况如多环境可以通过环境变量动态配置允许的源。5. 容器化部署与生产环境配置5.1 编写生产就绪的Dockerfile模型服务后端的Dockerfile需要精心设计以减小镜像体积、加速构建并确保安全。# backend/Dockerfile # 阶段一构建依赖 FROM python:3.10-slim as builder WORKDIR /app # 安装系统依赖根据模型需要例如ONNX Runtime可能需要一些库 RUN apt-get update apt-get install -y --no-install-recommends \ gcc \ g \ rm -rf /var/lib/apt/lists/* # 复制依赖文件并安装 COPY requirements.txt . RUN pip install --user --no-cache-dir -r requirements.txt # 阶段二运行环境 FROM python:3.10-slim WORKDIR /app # 创建非root用户运行应用 RUN groupadd -r appuser useradd -r -g appuser appuser # 从构建阶段复制已安装的Python包 COPY --frombuilder /root/.local /home/appuser/.local COPY --frombuilder /app/requirements.txt . # 复制应用代码和模型文件 COPY . . COPY --chownappuser:appuser ./model /app/model # 设置环境变量 ENV PYTHONPATH/app ENV PATH/home/appuser/.local/bin:$PATH ENV MODEL_PATH/app/model/traced_model.pt # 切换到非root用户 USER appuser # 暴露端口 EXPOSE 8000 # 启动命令使用uvicorn CMD [uvicorn, main:app, --host, 0.0.0.0, --port, 8000, --workers, 4]关键优化点多阶段构建第一阶段builder安装编译依赖和Python包第二阶段只复制安装好的包和运行所需的最小文件最终镜像体积可以缩小一半以上。使用slim镜像python:3.10-slim比完整版镜像小很多。非root用户运行这是一个重要的安全实践避免容器内应用以root权限运行。--no-cache-dir 在pip install时使用避免缓存文件增大镜像。固定workers数量 Uvicorn的--workers设置为CPU核心数的1-4倍根据实际负载调整。对于CPU密集型的模型推理worker数不宜过多否则会因进程切换和资源竞争导致性能下降。前端Dockerfile则相对简单主要是构建静态文件并用Nginx服务。# frontend/Dockerfile # 构建阶段 FROM node:18-alpine as build WORKDIR /app COPY package*.json ./ RUN npm ci --onlyproduction COPY . . RUN npm run build # 生产阶段 FROM nginx:alpine COPY --frombuild /app/dist /usr/share/nginx/html # 可以复制自定义的nginx配置 # COPY nginx.conf /etc/nginx/conf.d/default.conf EXPOSE 80 CMD [nginx, -g, daemon off;]5.2 使用Docker Compose编排服务docker-compose.yml文件将整个应用栈后端、前端、代理定义在一起一键启动。# docker-compose.yml version: 3.8 services: moodsense-backend: build: ./backend container_name: moodsense-api ports: - 8000:8000 environment: - MODEL_PATH/app/model/traced_model.pt - USE_ONNXfalse - LOG_LEVELINFO # 将模型目录作为卷挂载方便更新模型而不重建镜像 volumes: - ./model:/app/model:ro # 资源限制防止单个容器耗尽主机资源 deploy: resources: limits: cpus: 2.0 memory: 2G reservations: memory: 512M healthcheck: test: [CMD, curl, -f, http://localhost:8000/health] interval: 30s timeout: 10s retries: 3 start_period: 40s networks: - moodsense-net moodsense-frontend: build: ./frontend container_name: moodsense-ui ports: - 8080:80 depends_on: - moodsense-backend networks: - moodsense-net # 可选添加一个Nginx作为统一入口和负载均衡 reverse-proxy: image: nginx:alpine container_name: moodsense-proxy ports: - 80:80 - 443:443 # 如果配置了SSL volumes: - ./nginx/conf.d:/etc/nginx/conf.d:ro - ./ssl_certs:/etc/nginx/ssl:ro # SSL证书目录 depends_on: - moodsense-backend - moodsense-frontend networks: - moodsense-net networks: moodsense-net: driver: bridge编排要点资源限制为模型服务设置CPU和内存限制至关重要尤其是在共享主机上。这能防止某个服务崩溃时拖垮整个系统。健康检查为后端服务配置healthcheckDocker Compose或更高级的编排器如K8s可以据此判断容器是否真的“就绪”实现更优雅的服务发现和负载均衡。网络所有服务置于同一自定义网络下可以通过服务名如moodsense-backend进行内部通信而不是IP地址。模型卷挂载将模型文件目录以只读ro方式挂载进容器。这样当你需要更新模型时只需替换主机上的文件然后通知服务重载模型即可无需重新构建和部署容器镜像。6. 性能调优与生产环境监控6.1 模型推理性能压测与优化服务上线前我们使用locust进行了压力测试模拟高并发场景。# locustfile.py from locust import HttpUser, task, between class MoodSenseUser(HttpUser): wait_time between(1, 3) # 用户等待时间 host http://localhost:8000 task def predict_emotion(self): sample_texts [ 这真是美好的一天, 我对这个结果感到非常失望。, 有点紧张但更多的是期待。 ] import random text random.choice(sample_texts) self.client.post(/predict, json{text: text})通过压测我们发现了几个瓶颈并进行了优化模型加载与预热第一个请求总是很慢。我们在服务启动后在lifespan的启动事件中主动用一个样本进行一次推理完成模型和运行时的“预热”。批处理预测单个请求处理一条文本效率低。我们增加了/batch_predict端点支持传入文本列表。在模型内部通过动态填充padding将多个样本组成一个批次进行推理能充分利用GPU/CPU的并行计算能力吞吐量提升显著在我们的测试中批次大小为8时吞吐量提升约5倍。硬件加速如果模型支持且服务器有GPU使用GPU进行推理是最大的性能提升点。在Docker中需要传递--gpus all参数并在代码中确保torch使用CUDA。ONNX Runtime优化如前所述切换到ONNX Runtime并启用其内置的性能优化如启用执行提供器CUDAExecutionProvider或TensorrtExecutionProvider能带来额外收益。6.2 监控、日志与告警应用上线后可观测性就是生命线。结构化日志使用structlog或json-logger替代基本的print输出JSON格式的日志便于被ELKElasticsearch, Logstash, Kibana或Loki等日志系统收集和检索。日志中必须包含request_id、timestamp、level、service_name等关键字段。应用指标暴露我们在/metrics端点中返回了请求计数。更专业的做法是集成prometheus-fastapi-instrumentator这样的库自动暴露丰富的Prometheus指标请求延迟分布、状态码计数等。健康检查与就绪探针在Kubernetes部署时我们配置了livenessProbe指向/health和readinessProbe。readinessProbe会在模型加载完成后再返回成功确保流量不会打到未准备好的Pod上。基础监控除了应用层我们还需要监控宿主机的CPU、内存、磁盘I/O以及容器本身的资源使用情况。这通常由云平台或运维工具如GrafanaPrometheusNode Exporter提供。7. 常见问题排查与经验总结在实际部署和运维MoodSense AI的过程中我遇到了不少典型问题这里整理成排查清单希望能帮你少走弯路。问题现象可能原因排查步骤与解决方案API响应慢尤其第一个请求1. 模型未预热。2. 冷启动导致。1. 在应用启动后主动进行一次推理预热。2. 对于Serverless部署如AWS Lambda考虑使用预留实例。对于容器确保有最小副本数运行。并发请求时内存飙升直至OOM1. 未使用torch.no_grad()。2. 未进行GPU显存管理。3. 批处理批次过大。1. 检查所有推理代码是否在with torch.no_grad():上下文中。2. 定期调用torch.cuda.empty_cache()谨慎使用。3. 限制批处理的最大批次大小并实现动态批处理。Docker容器内无法访问GPU1. 未安装NVIDIA容器运行时。2. Docker命令或Compose文件未指定GPU。1. 在主机安装nvidia-container-toolkit并重启Docker。2. 运行命令添加--gpus all或在Compose的deploy.reservations.devices中指定。前端调用API出现CORS错误后端CORS中间件配置不正确。1. 检查后端allow_origins是否包含了前端的确切地址含端口。2. 生产环境避免使用*。模型更新后服务预测结果异常1. 新模型与预处理/后处理代码不兼容。2. 模型文件损坏或版本错误。1. 实施严格的模型版本管理并保证预处理代码与模型版本绑定。2. 在模型服务中增加模型校验逻辑如计算样本输出的校验和。3. 采用蓝绿部署或金丝雀发布先引流少量流量到新版本。服务健康检查失败1. 模型加载失败。2. 依赖服务如数据库不可用。3. 资源不足内存、磁盘。1. 检查模型文件路径和权限。2. 健康检查端点应只检查核心功能如模型加载避免依赖外部服务。3. 检查容器和宿主机的资源使用情况。最后一点个人体会将一个ML模型变成真正的AI应用技术实现只占一半另一半是工程化思维。你需要像对待一个产品一样对待它考虑它的性能、稳定性、可维护性、可观测性和用户体验。从MoodSense AI这个项目来看最宝贵的经验不是用了某个酷炫的框架而是建立了从代码开发、容器构建、服务编排到监控告警的完整、可重复的流水线。这套流程一旦跑通后续部署任何新的模型应用都会变得有章可循效率倍增。记住可复现、可监控、可回滚是生产级AI应用的三大基石。

查看全文

http://www.rkmt.cn/news/1407936.html