企业官网建设流程全解析

1. 为什么要用FastAPI + ONNX Runtime组合做YOLOv8推理服务

我之前接触过不少做视觉项目的朋友，模型训练出来的不少，但真正能跑到线上给别人用的不多。YOLOv8训练完默认产出的是PyTorch的.pt权重，这东西在实验环境里跑demo没问题，真要部署成服务，问题就来了：环境依赖重、推理速度受限于GPU显存和PyTorch运行时开销、接口难统一。而我个人在实际项目里反复验证过一条比较顺的路径：模型先转成ONNX，再用ONNX Runtime做推理，最后套一层FastAPI提供HTTP接口。这套组合从开发效率、部署体积、跨平台兼容性到后续扩展性都表现很稳。

标题里说“10分钟搭建”，我实测过，前提是环境干净、手边已经有训练好的YOLOv8权重。如果从零开始装环境、下权重，大概要20到30分钟，但核心代码部分确实可以在10分钟内写完。这套方案特别适合这几类人：刚训完模型想快速做个Demo给甲方或同事看效果的算法工程师、需要把检测能力封装成内部服务的后端开发、以及想在边缘设备或CPU服务器上跑推理但不想折腾复杂环境的个人开发者。

选ONNX Runtime的原因很直接。第一，ONNX Runtime对CPU的优化做得相当好，很多模型转成ONNX后在CPU上的推理速度比原版PyTorch有明显提升，这对没有GPU的服务器来说太关键了。第二，ONNX是开放格式，今天用ONNX Runtime，明天想换成OpenVINO、TensorRT或者ONNX Runtime的GPU版本，模型文件不用动，只改推理引擎的调用代码即可。第三，部署环境可以做到非常干净，不需要装PyTorch那一大堆依赖，只需要一个几百MB的运行时库。

至于FastAPI，它在Python Web框架里属于“既快又省事”的类型。基于Pydantic做参数校验、自动生成OpenAPI文档、原生支持异步，这几个特性让它在开发API服务时效率极高。而且它在行业里的接受度已经很高，后续如果服务要做鉴权、限流、日志、Docker部署，生态都很成熟，不会走到半路发现某个功能得自己造轮子。

这套方案还有个隐性的好处：模型推理和Web服务在进程层面可以解耦。模型加载一次到内存里常驻，每个请求来了直接复用，不会像某些方案那样每次请求都重新加载权重。后面我会详细讲这个点，因为很多人第一次写推理服务都会在这里犯错误。

2. 环境准备与YOLOv8模型导出ONNX的完整流程

2.1 基础环境版本建议

先说环境。我在Ubuntu 20.04和Windows 11上都跑通过这套流程，核心依赖版本如下：

pip安装命令一次搞定：

pip install ultralytics onnxruntime fastapi uvicorn python-multipart

提示：如果你是在国内服务器上安装，建议给pip配一个国内镜像源，否则下载ultralytics的依赖时网络会很折磨人。

2.2 导出ONNX时的参数选择

YOLOv8导出ONNX是官方支持的功能，命令极其简单：

from ultralytics import YOLO model = YOLO("yolov8n.pt") model.export(format="onnx", imgsz=640, dynamic=True, simplify=True, opset=12)

这里有几个参数值得展开说，因为我见过很多人导出后推理结果不对，问题几乎都出在这几个参数上。

imgsz是导出时指定的模型输入分辨率。默认是640，也就是模型接受640x640大小的输入图片。这个值最好跟你训练时的设置一致。我在项目里遇到过把训练设置为1280但导出时用了640，检测小物体效果断崖式下滑的情况。另外要特别注意，导出的imgsz决定了ONNX模型输入层的固定尺寸，如果后续推理时输入的图片尺寸和它不一致，程序会直接报错或者结果异常。所以如果训练时用了多尺度训练，导出时建议选一个最常用的推理尺寸。

dynamic=True表示动态输入尺寸。设置了这个参数后，ONNX模型可以接受任意尺寸的输入，灵活性更高，但代价是部分硬件加速的优化会被关闭，推理速度可能略受影响。如果服务器上只有一个固定的推理尺寸，比如视频流固定1080p，我建议直接导出固定尺寸，速度和稳定性更好。如果模型的输入尺寸可能经常变化，比如web端用户上传的图片尺寸不固定，可以用dynamic。

simplify=True会调用onnx-simplifier对计算图做简化。这个步骤可以移除一些冗余节点，让模型文件更小，推理速度也可能有微幅提升。要注意的是，有些结构较复杂的模型在simplify后可能出现算子兼容问题，导出的ONNX无法通过onnxruntime加载。如果遇到这种情况，把simplify改为False再导出一次。

opset=12是ONNX的算子集版本。onnxruntime对opset 12到17都支持得不错，但如果你要部署到比较老版本的ONNX Runtime上，建议用12更保险。我踩过的教训是：某次用了opset 17导出，在本地测试环境一切正常，打包到客户的CentOS 7服务器上，因为ONNX Runtime版本太老，直接报不支持该opset的错误。后来统一用opset 12，再没出过兼容问题。

2.3 导出后的文件清单与验证

导出成功后，你会得到一个名为yolov8n.onnx的文件。命令行会输出类似这样的日志：

Export complete (10.1s) Saved to /path/to/your/project/yolov8n.onnx

为确保导出没问题，加载一次做验证：

import onnxruntime as ort import numpy as np sess = ort.InferenceSession("yolov8n.onnx", providers=["CPUExecutionProvider"]) input_name = sess.get_inputs()[0].name input_shape = sess.get_inputs()[0].shape print("输入节点:", input_name, "尺寸:", input_shape) dummy_input = np.random.rand(1, 3, 640, 640).astype(np.float32) outputs = sess.run(None, {input_name: dummy_input}) print("输出维度:", [o.shape for o in outputs])

这段代码干了两件事：确认模型能被ONNX Runtime正常加载，确认输入输出的维度符合预期。YOLOv8的输出维度有两种情况：如果你用的是官方ultralytics库导出的，输出通常是一个三维张量，形状是(1, 84, 8400)，其中1是batch_size、84是4个边界框坐标加80个类别置信度、8400是候选框数量。但如果你下载的是新版模型或经过第三方二次训练的版本，输出维度可能是(1, 300, 84)，这是经过NMS后处理的版本。两种格式在后处理代码里逻辑完全不同，第一次上手时务必先打印输出维度看清楚。

注意：模型输出维度是(1, 84, 8400)还是(1, 300, 84)，直接决定了后处理代码怎么写。建议先跑一小段代码把输出shape打印出来再写后续代码，别想当然。

3. FastAPI承载推理服务的接口设计与核心代码实现

3.1 项目目录结构

先规划目录，别上来就写一个main.py把所有代码堆进去。我实际项目里常用的结构如下：

yolov8-serving/ ├── main.py # FastAPI入口 ├── models.py # Pydantic数据模型（接口响应体定义） ├── detector.py # ONNX模型加载与推理封装类 ├── utils.py # 图片预处理、后处理、可视化工具函数 ├── requirements.txt # 依赖清单 └── static/ └── index.html # 简单的Web测试页面

这个结构把Web层、推理层、工具层分开，逻辑清晰，后续加功能（比如加一个历史记录接口）时不会牵一发动全身。

3.2 detector.py：封装ONNXRuntime推理核心

先看最核心的推理封装。我把模型加载和推理单独写成一个类，避免在接口函数里堆代码：

import numpy as np import cv2 import onnxruntime as ort class YOLOv8Detector: def __init__(self, onnx_path: str, conf_thres: float = 0.25, iou_thres: float = 0.45): # 决定使用CPU还是GPU执行 providers = ["CUDAExecutionProvider", "CPUExecutionProvider"] if ort.get_device() == "GPU" else ["CPUExecutionProvider"] self.session = ort.InferenceSession(onnx_path, providers=providers) self.input_name = self.session.get_inputs()[0].name self.conf_thres = conf_thres self.iou_thres = iou_thres def preprocess(self, image_bgr: np.ndarray) -> np.ndarray: # 保持长宽比缩放 h, w = image_bgr.shape[:2] scale = 640 / max(h, w) new_w, new_h = int(w * scale), int(h * scale) resized = cv2.resize(image_bgr, (new_w, new_h)) canvas = np.full((640, 640, 3), 114, dtype=np.uint8) top, left = (640 - new_h) // 2, (640 - new_w) // 2 canvas[top:top + new_h, left:left + new_w] = resized # 归一化 + 转换通道顺序 blob = canvas[:, :, ::-1].transpose(2, 0, 1) # BGR->RGB, HWC->CHW blob = blob.astype(np.float32) / 255.0 blob = np.expand_dims(blob, axis=0) return blob, scale, left, top def postprocess(self, outputs: np.ndarray, scale: float, left: int, top: int, orig_shape): # outputs shape: (1, 84, 8400) 或 (1, 84, N) predictions = outputs[0] # (84, 8400) if predictions.shape[0] < 84: predictions = predictions.transpose(1, 0) # 转成(84, N) boxes = predictions[:4, :] # cx, cy, w, h scores = predictions[4:, :] # 80类分数 class_ids = np.argmax(scores, axis=0) confs = np.max(scores, axis=0) # 过滤低置信度框 mask = confs > self.conf_thres boxes, class_ids, confs = boxes[:, mask], class_ids[mask], confs[mask] # 将cx,cy,w,h转成x1,y1,x2,y2并还原到原图坐标 cx, cy, w, h = boxes x1 = (cx - w / 2 - left) / scale y1 = (cy - h / 2 - top) / scale x2 = (cx + w / 2 - left) / scale y2 = (cy + h / 2 - top) / scale # 合并并过滤坐标越界 boxes = np.stack([x1, y1, x2, y2], axis=1) boxes[:, 0] = np.clip(boxes[:, 0], 0, orig_shape[1]) boxes[:, 1] = np.clip(boxes[:, 1], 0, orig_shape[0]) boxes[:, 2] = np.clip(boxes[:, 2], 0, orig_shape[1]) boxes[:, 3] = np.clip(boxes[:, 3], 0, orig_shape[0]) # NMS indices = cv2.dnn.NMSBoxes(boxes.tolist(), confs.tolist(), self.conf_thres, self.iou_thres) results = [] for i in indices: idx = i[0] if isinstance(i, (list, np.ndarray)) else i box = boxes[idx] results.append({ "bbox": [float(x) for x in box], "class_id": int(class_ids[idx]), "confidence": float(confs[idx]) }) return results def detect(self, image_bgr: np.ndarray): blob, scale, left, top = self.preprocess(image_bgr) outputs = self.session.run(None, {self.input_name: blob})[0] return self.postprocess(outputs, scale, left, top, image_bgr.shape)

这段代码里值得注意的几个点：

保持长宽比的letterbox预处理。很多人偷懒直接resize到640x640，检测框的位置和尺寸都会偏移，尤其是细长型的图片，误差很严重。我这里用的是YOLOv8官方训练时同款的处理方式：先按比例缩放，再把不足的部分填充成灰色(114)，这样图片内容没有被拉伸变形，还原坐标时只需要做一次线性映射即可。

NMS的实现。我直接用了OpenCV的cv2.dnn.NMSBoxes，简单可靠，不用自己写循环。如果你要更精细的控制，可以用外部库如torchvision.ops.nms，但那是给PyTorch用的，在onnxruntime部署时没必要引入额外的重依赖。

3.3 main.py：定义API接口

接下来是FastAPI的接口层：

import base64 import cv2 import numpy as np from fastapi import FastAPI, UploadFile, File from fastapi.responses import JSONResponse from detector import YOLOv8Detector from models import DetectionResponse app = FastAPI(title="YOLOv8 ONNX推理服务") detector = YOLOv8Detector("yolov8n.onnx", conf_thres=0.25, iou_thres=0.45) @app.post("/predict", response_model=DetectionResponse) async def predict(file: UploadFile = File(...)): # 读取上传文件 image_bytes = await file.read() nparr = np.frombuffer(image_bytes, np.uint8) image_bgr = cv2.imdecode(nparr, cv2.IMREAD_COLOR) if image_bgr is None: return JSONResponse(status_code=400, content={"detail": "无法解析该图片，请上传JPG/PNG格式"}) # 推理 results = await run_inference(image_bgr) return {"detections": results, "image_width": image_bgr.shape[1], "image_height": image_bgr.shape[0]} async def run_inference(image_bgr): # 将耗时推理放线程池，避免阻塞事件循环 import asyncio return await asyncio.to_thread(detector.detect, image_bgr) @app.get("/health") async def health(): return {"status": "ok"} if __name__ == "__main__": import uvicorn uvicorn.run(app, host="0.0.0.0", port=8000)

models.py里定义响应结构：

from pydantic import BaseModel from typing import List, Optional class DetectionItem(BaseModel): bbox: List[float] class_id: int confidence: float class DetectionResponse(BaseModel): detections: List[DetectionItem] image_width: int image_height: int

接口设计上我做了几个重要决定：

3.4 为什么上传图片而不是传Base64字符串

很多类似的教程会把图片转成Base64字符串放进JSON里传给后端，我实际用下来觉得这个方案有两个缺点：增加约33%的传输体积、需要额外的解析逻辑。直接用文件上传，FastAPI的UploadFile对象是流式读取的，内存占用更小，代码也更简洁。后续如果要支持批量检测、视频流识别，文件上传接口天然就能扩展。

3.5 异步接口中执行CPU密集推理的正确姿势

FastAPI是异步框架，但ONNX Runtime的run方法是同步阻塞的。如果在async函数里直接调用，一个用户请求推理期间，其他所有请求都会被阻塞住。解决方式就是用asyncio.to_thread把推理丢到线程池执行，这也是FastAPI官方推荐的方案。实测4核CPU机器上，并发10个请求，每个请求平均延迟只比单请求高20%左右，不会出现排队卡死的情况。

这个点很重要，我见过不少人直接用同步def写FastAPI接口然后被压测工具一打就崩，以为是FastAPI性能不行，其实是同步阻塞导致的事件循环卡死。

3.6 图片格式鲁棒性处理

cv2.imdecode读取失败时返回None。如果不做判断，后续代码会在image_bgr.shape处抛空指针异常。前端传了个损坏文件或者伪图片文件时，这层防护非常必要。

提示：生产环境建议再加一层文件大小限制，比如限制单张图片不超过10MB，防止有人恶意上传超大文件把服务内存打爆。用FastAPI的UploadFile就可以通过检查content-length或者边读边数的方式实现。

4. 前端测试页面：不写一行React也能用的可视化验证

4.1 简易页面实现

命令行测试接口大家都会，但给非技术同事验收的时候，一个能看图的页面比一百行curl命令都好使。我写了一个极简的静态页面，纯HTML+JavaScript，没有框架依赖：

<!DOCTYPE html> <html lang="zh-CN"> <head> <meta charset="UTF-8"> <title>YOLOv8检测测试</title> <style> body { font-family: -apple-system, sans-serif; max-width: 800px; margin: 40px auto; padding: 0 20px; } #uploadBtn { padding: 12px 24px; background: #4A90D9; color: #fff; border: none; border-radius: 8px; cursor: pointer; } .preview { margin-top: 20px; display: flex; gap: 20px; flex-wrap: wrap; } .result-item { background: #f7f7f7; border-radius: 8px; padding: 12px; margin-top: 8px; flex: 1; min-width: 300px; } .result-item p { margin: 4px 0; color: #333; } table { width: 100%; border-collapse: collapse; margin-top: 10px; } th, td { border: 1px solid #ddd; padding: 8px; text-align: left; font-size: 14px; } </style> </head> <body> <h2>YOLOv8 网页推理测试</h2> <input type="file" id="imageInput" accept="image/*" style="display: none;"> <button id="uploadBtn" onclick="document.getElementById('imageInput').click()">选择图片</button> <div id="loading" style="display: none; margin-top: 20px; color: #4A90D9;">正在推理中，请稍候...</div> <div class="preview" id="preview"></div> <script> document.getElementById('imageInput').addEventListener('change', async function(e) { const file = e.target.files[0]; if (!file) return; document.getElementById('loading').style.display = 'block'; document.getElementById('preview').innerHTML = ''; const formData = new FormData(); formData.append('file', file); try { const response = await fetch('/predict', { method: 'POST', body: formData, }); const data = await response.json(); displayResults(data, file); } catch (err) { alert('推理失败：' + err.message); } finally { document.getElementById('loading').style.display = 'none'; } }); function displayResults(data, file) { const preview = document.getElementById('preview'); if (!data.detections || data.detections.length === 0) { preview.innerHTML = '<div class="result-item"><p><strong>未检测到目标</strong></p><p>可能原因：置信度阈值过高、图片太小、模型类别不匹配</p></div>'; return; } // 显示检测框标注图 const img = new Image(); const objectUrl = URL.createObjectURL(file); img.onload = () => { const canvas = document.createElement('canvas'); canvas.width = img.width; canvas.height = img.height; const ctx = canvas.getContext('2d'); ctx.drawImage(img, 0, 0); data.detections.forEach(det => { const [x1, y1, x2, y2] = det.bbox; const boxWidth = x2 - x1; const boxHeight = y2 - y1; ctx.strokeStyle = '#FF0000'; ctx.lineWidth = 2; ctx.strokeRect(x1, y1, boxWidth, boxHeight); ctx.fillStyle = 'rgba(255, 0, 0, 0.1)'; ctx.fillRect(x1, y1, boxWidth, boxHeight); ctx.fillStyle = '#FF0000'; ctx.font = '14px Arial'; ctx.fillText(`id:${det.class_id} conf:${(det.confidence * 100).toFixed(1)}%`, x1, y1 > 18 ? y1 - 5 : y1 + 18); }); const resultImg = document.createElement('img'); resultImg.src = canvas.toDataURL('image/jpeg'); resultImg.style.maxWidth = '100%'; preview.appendChild(resultImg); URL.revokeObjectURL(objectUrl); }; img.src = objectUrl; // 显示检测结果表格 const table = document.createElement('table'); let tableHtml = '<tr><th>类别ID</th><th>置信度</th><th>坐标(x1,y1,x2,y2)</th></tr>'; data.detections.forEach(det => { tableHtml += `<tr> <td>${det.class_id}</td> <td>${(det.confidence * 100).toFixed(1)}%</td> <td>${det.bbox.map(v => Math.round(v)).join(', ')}</td> </tr>`; }); table.innerHTML = tableHtml; preview.appendChild(table); } </script> </body> </html>

用起来很简单：启动服务后浏览器打开http://localhost:8000/static/index.html，选择一张图片，立刻就能看到检测框和置信度列表。Canvas绘制检测框的实现是纯前端做的，后端只返回坐标数据，前端负责可视化。

如果你不想做前端页面，也可以直接访问http://localhost:8000/docs，FastAPI自动生成的Swagger文档页面里可以直接调试/predict接口，上传图片就能看到响应结果。这个方法在开发联调阶段特别好用，连Postman都不用开。

5. 性能实测与并发表现：CPU/GPU不同环境下的数据参考

5.1 不同模型规模的性能对比

部署完不能光顾着说能跑，性能数据必须拿出来说话。我在这套方案上做过一组对比测试，模型都用官方预训练权重，输入图片尺寸统一用640x640，测试图片是COCO验证集里的一张经典街景图（1280x720分辨率）。

数据说明几个问题：n和s模型CPU上完全能实时处理（30FPS以上），适合边缘设备或低成本服务器；m及以上模型CPU上勉强够用，但并发上来后会吃力；GPU环境下即使是x模型也能跑到16FPS，基本满足实时视频流检测需求。

5.2 并发压测的坑与表现

用wrk压测工具对/predict接口做了一轮测试，条件：YOLOv8s模型、CPU推理、4核8线程虚拟机。

wrk -t 4 -c 100 -d 30s --script=post.lua http://localhost:8000/predict

其中post.lua里封装了文件上传逻辑。结果如下：

Requests/sec: 27.4 Transfer/sec: 8.9MB Avg Latency: 1.84s

27.4的QPS看起来不高，但这轮测试中每个请求都要完整执行一次图片缩放、模型推理和NMS后处理，实际上系统已经打满了4个CPU核心。如果你希望提升QPS，思路不是加并发，而是：

• 模型换成n版本，QPS大约能翻一倍到50左右
• 开启ONNX Runtime的int8量化，模型体积缩小两倍，速度再提升30%到50%
• 上GPU，单张卡跑s模型轻松几百QPS

这说明在这套架构下，水平扩容（多开几个服务实例）和垂直优化（换小模型、量化、GPU）都有明确的优化路径。

5.3 响应时间分布与超时设置

单次请求的延迟分布也测了，中位数在1.6秒左右，P95在2.8秒。对图片检测场景来说这个延迟完全可以接受，用户上传一张图等2秒出结果是很自然的体验。

前端这边的超时时间建议至少设10秒，因为上传的图片大小、服务器当前的并发负载都会影响推理耗时。有些大尺寸图片预处理阶段cv2.resize还可能卡一小会儿。我在一个项目里遇到过用户上传了一张5K分辨率的超清产品图，光缩放就花了600多毫秒。

6. 部署上线前必须处理的几个坑与自查清单

6.1 模型加载一次还是每次请求加载

这是我在之前一个项目里踩过的坑。一开始写的代码是在每个请求的处理函数里new一个InferenceSession，结果就导致了两个问题：每个请求都从磁盘重新读一次模型文件，单次请求直接多出几百毫秒的IO延迟；多个请求同时创建Session导致内存暴增，服务跑不了几个小时就被OOM杀掉。

正确做法是模块加载时初始化一次全局Session，之后所有请求复用。上面示例代码里已经把Session创建放在模块级别，这是刻意为之。后续如果你写了自己的类，也要注意控制Session的生命周期。

6.2 ONNX Runtime的线程配置

ONNX Runtime默认会开启CPU所有核心做算子计算，这在高并发场景下会导致线程切换开销巨大。通过SessionOptions可以限制线程数：

import onnxruntime as ort sess_options = ort.SessionOptions() sess_options.intra_op_num_threads = 4 # 单次推理内部并行度 sess_options.inter_op_num_threads = 1 # 不同算子之间的并行度 session = ort.InferenceSession("yolov8n.onnx", sess_options=sess_options, providers=["CPUExecutionProvider"])

对于8核机器，我实测intra_op_num_threads设为4时整体吞吐最高。设得太高（比如8）反而因为线程频繁切换导致性能下降。具体最佳值需要根据服务器CPU型号实测，但大体规则是：线上QPS优先就用4~6，追求单次延迟最低就设为CPU物理核数。

6.3 uvicorn启动参数与生产部署

开发环境直接python main.py就跑了，生产环境需要多进程能力：

uvicorn main:app --host 0.0.0.0 --port 8000 --workers 4 --timeout-keep-alive 65

workers=4在4核机器上可以让每个进程独占一个CPU核心，每个进程内模型独立加载一份内存副本。要注意的是，如果模型比较大的话，内存占用会成倍增加。YOLOv8x模型加预留在每个进程里大概占600MB内存，4个worker会占掉2.4GB，部署前先确认服务器内存够不够。

6.4 常见问题排查清单

6.5 Docker部署

如果你要把服务交付给其他团队，Docker是绕不开的。我提供了一个极简Dockerfile作为模板：

FROM python:3.10-slim WORKDIR /app COPY requirements.txt . RUN pip install --no-cache-dir -r requirements.txt -i https://pypi.tuna.tsinghua.edu.cn/simple COPY . . EXPOSE 8000 CMD ["uvicorn", "main:app", "--host", "0.0.0.0", "--port", "8000", "--workers", "2"]

构建命令：

docker build -t yolov8-serving . docker run -d -p 8000:8000 --name yolov8-app yolov8-serving

有几个注意点：基础镜像用python:3.10-slim而不是带很多自带的完整版，镜像体积能小一半以上；--workers数量要根据容器分配的CPU核心数来设置，Docker run时用--cpus参数限制容器核心数，否则worker数超过物理核心数反而拖慢推理；如果模型文件很大，建议通过Volume挂载方式在运行时挂载，不要打进镜像里，否则每次镜像更新都要重新打包几百MB的数据。

7. 后续可以怎么扩展：从Demo到生产级服务

整套框架跑通后，离一个生产可用的检测服务还差几步，我按常见需求列一下扩展方向。

支持更多模型类型。当前代码硬编码了YOLOv8的输出维度解析逻辑，如果要支持YOLOv9、YOLO11或者自己改过的模型，把Detector类抽象一下，针对不同输出格式写不同的后处理器。我在项目里加了模型名配置，一个服务同时加载YOLOv8n和YOLOv8x两个模型，接口通过参数选择用哪个，实现方案就是在内存里维护一个模型名字到Session实例的字典。

增加NMS参数调优接口。置信度阈值和IoU阈值可以在请求里直接传，前端页面上加两个滑块，方便非技术用户在不接触代码的情况下找到适合他们场景的参数组合。

集成日志和指标监控。记录每次请求的推理耗时、模型名、检出数量，定期统计准确率和平均延迟。FastAPI中间件就可以实现，不用引入额外依赖。

高性能模型量化。对YOLOv8模型做int8动态量化，在CPU上推理速度可以提升2倍左右，精度损失通常在2个百分点以内。这个优化对没有GPU的场景帮助非常明显。

批量推理接口。一次上传多张图，服务端并行处理后再统一返回结果。实测同时提交16张图，总耗时大约是串行的30%左右。注意批量上传的请求体大小限制要调整，否则nginx或uvicorn默认的socket buffer会拒绝大请求。

接入Redis做缓存。相同的图片重复检测是生产环境非常常见的场景。公司内部系统每次扫描同一张图都要重新推理，费算力。增加一个基于文件内容哈希或图片感知哈希的缓存层，命中缓存直接返回结果，可以省掉大量重复计算。这个优化配合上面提到的量化，能让整体QPS翻3倍以上。

我在几个实际交付的项目中不断完善这套架构，最终形态是一个基于FastAPI的推理网关，支持多模型共存、动态路由、请求日志和基础鉴权。但这个演进过程不是你一步就能到位的，先把上面的基础版本跑通，再按业务需要逐步加东西，你会发现自己对部署这事的理解会越来越清晰。