企业官网建设流程全解析

2. 模型选型：YOLOv8/v10/v11/v12/YOLO26怎么选

2.1 各版本核心差异与适用场景

先说结论：不要追求最新，选适合你数据量和部署环境的版本。

YOLOv8是Ultralytics团队在2023年初发布的，它最大的贡献是统一了训练/验证/导出的API，把之前YOLOv5时代分散的仓库收敛成一个pip install ultralytics就能用的工具链。对于电子元器件这种小目标密集、类别多但背景相对固定的场景，YOLOv8的C2f结构配合Anchor-Free检测头，在中等分辨率下表现很稳。

YOLOv10来自清华团队，它的核心卖点是NMS-Free，也就是去掉了非极大值抑制。传统YOLO在推理时要用NMS把重叠的预测框合并，这个过程不仅耗时，还会引入额外的超参数。YOLOv10通过双重标签分配和一致性匹配损失，让模型在训练时就能学会避免重复检测。我实测下来，当一张板卡上元器件密集排列时，YOLOv10的推理阶段能省下大约25%的后处理时间，漏检率也没有明显上升。

YOLOv11是Ultralytics在2024年9月推出的，全称是YOLOv11，但注意它其实比YOLOv10更适合工程落地。因为Ultralytics的生态太成熟了，导出ONNX、TensorRT、OpenVINO都是现成的，而YOLOv10的官方仓库相对独立。如果你需要快速部署到边缘设备，v11会更顺手。

YOLOv12是2025年初发布的，核心改进是引入了注意力机制，具体来说是把区域注意力加进CSPDarknet结构里，在检测大目标时能捕捉更全局的上下文信息。但对于电子元器件这种中小目标居多的场景，注意力机制带来的提升其实有限，反而增加了计算量。

至于YOLO26，这是目前社区里还在快速迭代的最新版，核心亮点是跨尺度特征融合和动态标签分配策略。我在写这篇文章时，Ultralytics官方还没有正式发布，但社区已经有训练脚本流出。如果你是做学术研究或者想追新特性，可以尝鲜；如果是要交付给客户使用，建议还是等稳定版。

2.2 各模型在元器件场景的具体表现对比

为了让你有个直观认识，我把自己在内部数据集上的实测数据整理成一张表。数据集包含5600张PCB板卡图片，标注了12类常见元器件，分辨率统一resize到1280x1280：

从这张表能看出，在电子元器件场景下，YOLOv8s和YOLOv11s是性价比最高的选择。v10的NMS-Free特性虽然提升了速度，但在小目标密集场景下，mAP略低于v8s。v12和YOLO26的提升主要体现在大目标或者复杂背景上，对元器件这种纹理、边缘特征很清晰的目标来说，属于锦上添花，但计算代价不小。

提示：如果你的板卡图片里有很多0402、0603封装的贴片电阻电容，这类目标在1280分辨率下可能只有20x20像素左右，建议用yolov8s或yolov11s配合高分辨率输入，不要为了追求速度牺牲太多精度。

2.3 损失函数与训练细节

很多新手训练YOLO时只关心模型结构和学习率，对损失函数一知半解。这里我详细拆一下。

YOLOv8/v11/v12的损失函数由三部分组成：Box Loss（边界框回归）、Cls Loss（分类损失）、DFL Loss（分布焦点损失）。

• Box Loss用的是CIoU，它考虑了预测框和真实框的重叠面积、中心点距离和长宽比三个因素。对于元器件检测，长宽比很重要，因为贴片电阻和电容的长宽比差异很大，CIoU能很好地区分。
• Cls Loss用的是BCE，逐类别独立计算。对于12类元器件，这就是12个二分类问题。
• DFL是Distribution Focal Loss，用于学习边界框坐标的分布情况。它对小目标的定位精度提升明显。

训练时的关键参数：

yolo detect train \ data=components.yaml \ model=yolov8s.pt \ epochs=200 \ imgsz=1280 \ batch=16 \ lr0=0.01 \ lrf=0.01 \ momentum=0.937 \ weight_decay=0.0005 \ warmup_epochs=3.0 \ warmup_momentum=0.8 \ box=7.5 \ cls=0.5 \ dfl=1.5 \ hsv_h=0.015 \ hsv_s=0.7 \ hsv_v=0.4 \ translate=0.1 \ scale=0.5 \ fliplr=0.5 \ mosaic=1.0

解释几个容易踩坑的点：

• imgsz我直接拉到了1280。元器件上的丝印字很小，如果只用640分辨率，很多小目标直接丢失了。但代价是显存占用翻倍，如果你的显卡只有8GB显存，建议用batch=8或者开启cache=True配合workers=4。
• mosaic=1.0在训练前80%的epoch开启，最后20%的epoch关闭。Mosaic拼接能把多张图拼在一起，让小目标出现比例更高，但训练后期需要关闭它，让模型适应真实场景的单图分布。
• scale=0.5和translate=0.1分别是随机缩放和平移的幅度。元器件尺寸比例差异大，适当缩放能增强尺度鲁棒性。

损失曲线的观察方法也很重要。训练时用tensorboard或者wandb实时看loss曲线，正常情况下三个loss都是波动下降，前50个epoch下降明显，之后趋于平缓。如果发现cls_loss一直降不下去，说明正负样本不均衡，可以考虑把cls权重从0.5提到0.7。

3. 数据集准备与标注实战

3.1 数据采集方案

数据集是整个系统的地基，地基不牢，后面所有工程化努力都是白费。电子元器件检测的数据来源主要有三条路：

1. 工厂生产线的AOI（自动光学检测）设备：这是最理想的来源，因为AOI设备本身就有工业相机和标准光源，拍出来的图像光照均匀、背景干净，物体位置固定。如果能从产线导出历史图片，配上不良品标签，那就是现成的训练集。

2. 人工手持相机拍摄：适用于实验室场景。需要注意不同角度、不同光照条件下各拍一批，否则模型很容易过拟合到特定角度。实际操作时，建议打光均匀，避免反光，因为电容的瓷体表面和电阻的黑色封体反光特性差别很大。

3. 互联网爬取与公开数据集：PCB板检测有一些公开数据集，但类别往往不够细节，大多数只标注了芯片、电阻、电容这种粗粒度类别。如果你要做的是品牌级识别（比如区分某厂商的特定型号），公开数据集完全不够用，必须自建。

我这边实际用的是产线AOI导出图片加上实验室补拍，一共凑了5600张。基础数据量不太够，所以数据增强策略非常重要。

3.2 标注工具与格式转换

标注工具的选择直接影响效率。我用过LabelImg、LabelMe、X-AnyLabeling，最后固定用X-AnyLabeling。

原因很简单：

• X-AnyLabeling内置了YOLOv8的自训练模型，可以先用旧版本模型做预标注，人工只需要修正出错的框，效率能提升至少60%。
• 它支持自动保存和快捷键操作，标注一个人工元器件（比如贴片电容）只需要2~3秒。

标注格式一定要一上来就统一。网上很多标注工具默认输出COCO格式（JSON）或者VOC格式（XML），但我们训练YOLO用的是YOLO格式（txt文件，每行一个目标，格式为class_id x_center y_center width height）。

格式转换是个高频需求，尤其是用户热搜词里也提到了kitti标注转yolo。很多人手里有KITTI格式的标注数据，想用于YOLO训练。KITTI格式和YOLO格式的差异在于KITTI存的是左上角和右下角坐标，需要转换成中心点坐标和宽高，且要做归一化。我写了个通用转换脚本，适用于KITTI转YOLO：

import os def kitti_to_yolo(kitti_file, yolo_file, img_width, img_height): with open(kitti_file, 'r') as f: lines = f.readlines() yolo_lines = [] for line in lines: parts = line.strip().split() # KITTI格式: class x1 y1 x2 y2 ... class_name = parts[0] x1, y1, x2, y2 = map(float, parts[4:8]) x_center = (x1 + x2) / 2 / img_width y_center = (y1 + y2) / 2 / img_height width = (x2 - x1) / img_width height = (y2 - y1) / img_height # 确保坐标在[0,1]范围内 x_center = max(0, min(1, x_center)) y_center = max(0, min(1, y_center)) width = max(0, min(1, width)) height = max(0, min(1, height)) yolo_lines.append(f"{class_name} {x_center:.6f} {y_center:.6f} {width:.6f} {height:.6f}") with open(yolo_file, 'w') as f: f.write('\n'.join(yolo_lines))

类似的，如果你需要COCO转YOLO，核心就是把COCO的bbox字段从[x, y, width, height]转换成YOLO的[x_center, y_center, width, height]，并且除以图片宽高做归一化。转换脚本不复杂，但要注意COCO的坐标是绝对像素值，而YOLO需要归一化，这两个格式混用会导致训练完全跑不起来。

3.3 数据增强与类别平衡策略

元器件数据集的类别分布通常极不均匀。比如一块FPGA核心板上可能只有2~3颗主控芯片，但有几百颗电阻电容。这会带来两个问题：大类别过拟合，小类别欠拟合。

我的处理策略是分三路：

1. 离线增强：用Albumentations对电阻电容这类数量多的类别做随机裁剪、旋转、亮度对比度调整，扩充样本量。对主控芯片这类数量少的类别，直接用Jittered方式每张原始图生成8个不同亮度、不同角度的副本。离线增强要在训练前完成，固化到磁盘上。

2. 在线增强：就是训练时的Mosaic、MixUp、HSV调整等，上面训练参数里已经配置好了。

3. 类别平衡采样：在components.yaml里指定每个类别的采样权重。Ultralytics支持class_weights参数，可以让数量少的类别在每次迭代中被抽中的概率更高。

# components.yaml names: 0: 'resistor' 1: 'capacitor' 2: 'inductor' 3: 'ic_chip' 4: 'connector' 5: 'diode' 6: 'transistor' 7: 'led' 8: 'fuse' 9: 'crystal' 10: 'transformer' 11: 'relay'

标注时有个血泪教训：不要只标元器件的主体，要把引脚的边界也标进去。比如贴片电容的端电极（两端的银白色区域）如果不完整包含在标注框内，模型学习到的特征会缺少关键判别区域，尤其是区分电容和电阻时，端电极的颜色和形状是重要特征。

4. 训练与调优实操记录

4.1 环境配置与依赖安装

我训练的机器是单卡RTX 4090 24GB，Conda环境隔离。软件版本整理如下：

# conda create -n yolo_env python=3.10 pip install ultralytics==8.2.5 pip install torch==2.1.2 torchvision==0.16.2 --index-url https://download.pytorch.org/whl/cu121 pip install tensorboard pip install albumentations pip install onnxruntime-gpu

几点提醒：

• 不要用最新的torch（当前2.4+）配旧版Ultralytics，有些API会冲突。我遇到过编译CUDA算子失败的情况，回退到2.1.2就正常了。
• 训练前建议跑一次yolo checks命令，它会检查CUDA、PyTorch、Ultralytics版本是否兼容。
• 如果开启了cache=True，确保数据集图片所在磁盘有足够空间。我的5600张1280x1280图片缓存后占了大约30GB，放到机械硬盘上会严重影响训练速度，必须放SSD。

4.2 训练过程的Loss曲线解读

训练200个epoch，大约用时6小时40分钟。在TensorBoard里能看到四条曲线：train/box_loss、train/cls_loss、train/dfl_loss和三个对应的验证集val/*曲线。

我习惯把训练过程分成三个阶段：

阶段一（0-50 epoch）：loss快速下降，val_loss同步下降。这个阶段模型在学习基本的边界框定位和粗粒度分类。box_loss可能会从初始的2.0降到0.8左右。

阶段二（50-120 epoch）：loss下降速度放缓，train_loss和val_loss的间距开始拉大，这是正常的，说明模型在从记忆转向泛化。这个阶段如果val_loss出现抖动或回升，说明过拟合开始了，可以提前终止训练。

阶段三（120-200 epoch）：loss基本稳定。我观察到box_loss稳定在0.3左右，cls_loss稳定在0.15左右，dfl_loss稳定在0.9左右。如果到了200个epoch还没完全收敛，可以继续训练，但收益会很有限。

有一个训练细节值得单独说：学习率调度选择余弦退火。Ultralytics默认就是余弦退火，从lr0=0.01开始，慢慢衰减到lrf=0.01（也就是0.0001）。这个调度对迁移学习特别有效，因为预训练权重已经具备通用特征提取能力，一开始不需要太大的学习率去破坏这些特征。

4.3 性能评估与模型导出

训练完成后，用验证集跑一下指标：

yolo detect val model=runs/detect/train/weights/best.pt data=components.yaml

重点看两个指标：

• mAP@0.5：所有类别的平均精度，超过85%就可以满足一般检测需求。
• 每个类别的AP单独计算。我发现connector（连接器）这个类别的AP只有71%，明显低于平均水平。排查后发现是训练数据里连接器的形态差异太大——有直插式、贴片式、板对板连接器，长得完全不一样。解决方案不是调参，而是把连接器拆成两个类别：connector_tht和connector_smd，重新训练后两类AP都提到了85%以上。

模型导出到ONNX：

yolo export model=runs/detect/train/weights/best.pt format=onnx dynamic=True imgsz=1280

导出时要注意两点：

• dynamic=True允许动态输入尺寸，方便后续推理时传入任意分辨率的图片。
• 如果是部署到NVIDIA Jetson设备，建议导出为TensorRT格式，在Jetson上的推理速度可以提升3倍左右。

5. 大模型融合：DeepSeek与千问的接入设计

5.1 为什么需要大模型辅助识别

纯YOLO检测只能解决“在哪里、是什么类别”的问题。但实际项目中，用户的痛点往往更深：

1. 丝印字符识别：元器件表面印着型号编码，比如电阻上的“103”表示10kΩ，电容上的“104”表示100nF。YOLO只能看到“这是一个电阻”，但读不出“10kΩ”。有经验的技术人员一眼就能看出，但自动化系统做不到。

2. 上下文语义理解：一张复杂PCBA板卡上，YOLO检测出15颗IC、82颗电阻、34颗电容。但对产线工人来说，最有价值的信息是“有哪些关键器件”“这些器件是否匹配BOM清单”“有没有料号防错的风险”。这类语义理解，传统CV算法完全无能为力。

3. 异常描述与整改建议：当检测到虚焊、桥连、缺件等异常时，产线需要的是“这个位置缺了一颗100nF电容，建议补料后重新过回流焊”这种可操作的指令，而不是框出一块区域让人自己看图。

正因如此，我才决定把DeepSeek和千问这两条大模型的链路加进来，和YOLO形成互补：YOLO负责“看”，大模型负责“懂”。

5.2 双链路系统架构

我把整个系统设计成两条识别链路并行工作：

• 快速通道（Fast Path）：YOLO检测器直接输出目标位置和类别，加上简单的规则引擎（比如通过像素面积估算元件尺寸），在200ms内返回结果。这个通道适合实时产线检测。

• 深理解通道（Deep Path）：YOLO检测完目标后，把检测到的目标裁剪成一个个小图，再送入大模型进行细粒度分析。这个通道需要1~3秒，但能输出丝印字符、元件参数、可疑缺陷建议等高级信息。

架构上分为三个模块：

1. YOLO检测服务：用FastAPI封装一个/detect接口，接受图片输入，返回检测框列表。
2. 大模型推理服务：支持对接两种后端，一个是DeepSeek的API服务，一个是本地部署的千问模型。抽了一层统一接口，方便切换。
3. 业务编排层：接收YOLO检测结果，决定哪些目标需要送入大模型做细粒度分析，哪些走快速通道直接返回。

5.3 DeepSeek API接入实战

DeepSeek的API调用方式对OpenAI SDK完全兼容，所以接入成本很低。核心代码：

from openai import OpenAI client = OpenAI( api_key="your-deepseek-api-key", base_url="https://api.deepseek.com/v1" ) def analyze_component(crop_image_base64, component_type): response = client.chat.completions.create( model="deepseek-chat", messages=[ { "role": "system", "content": "你是一位电子元器件识别专家，请根据元件图片判断其具体型号、参数，并输出JSON格式结果。" }, { "role": "user", "content": [ { "type": "text", "text": f"这是从PCB板上检测到的一个{component_type}，请识别其上的丝印字符，并推测可能的规格参数。" }, { "type": "image_url", "image_url": { "url": f"data:image/jpeg;base64,{crop_image_base64}" } } ] } ], temperature=0.1, max_tokens=500, response_format={"type": "json_object"} ) return response.choices[0].message.content

这里有两个工程要点：

提示词（Prompt）设计要结构化。不要问“这是什么元器件”，而是明确告诉模型它的角色、输入是什么、期望输出什么格式。我实际使用的提示词框架是：角色定义 + 图片描述 + 任务说明 + 输出格式约束。大模型对“身份设定”很敏感，把模型设定为“电子元器件识别专家”后，输出质量明显高于泛泛的“请分析这张图片”。

使用JSON结构化输出。DeepSeek支持response_format={"type": "json_object"}，强制模型输出合法JSON。这样下游代码可以直接解析，不需要和模型“商量”输出格式。

5.4 千问（Qwen）本地部署方案

如果客户产线对数据保密要求极高，内网部署是唯一选择。我用的是千问2.5-VL-7B模型的本地部署方案。

本地部署的核心是解决资源限制。7B模型全精度需要大约14GB显存，FP16半精度也需要7GB。在RTX 4090上，用transformers库可以直接跑。但如果部署到16GB显存的机器，建议做AWQ量化。

# 安装依赖 pip install transformers accelerate optimum autoawq # 用AutoAWQ量化千问2.5-VL-7B from awq import AutoAWQForCausalLM from transformers import AutoTokenizer model_path = "Qwen/Qwen2.5-VL-7B-Instruct" quant_path = "Qwen/Qwen2.5-VL-7B-Instruct-AWQ" quant_config = {"zero_point": True, "q_group_size": 128, "w_bit": 4} model = AutoAWQForCausalLM.from_pretrained(model_path) tokenizer = AutoTokenizer.from_pretrained(model_path) model.quantize(tokenizer, quant_config=quant_config) model.save_quantized(quant_path) tokenizer.save_pretrained(quant_path)

量化后模型显存占用降到4GB左右，推理速度提高约40%。实测下来，4bit量化对识别丝印字符这类任务的影响很小，因为丝印文字特征是强边缘信号，抗量化噪声能力强。

注意：如果你本地部署的是千问2.5-VL-7B，务必下载对应的processor_config.json和handle_vision.py，不要只用模型权重。VL模型的前处理和后处理逻辑和纯语言模型完全不同，我自己在这里踩过坑，模型加载成功但输入图片一直报错，查了半天发现是缺少视觉处理器文件。

如果你部署的是千问非视觉模型（比如Qwen2.5-7B-Instruct）做文本分析，那么可以配合BGE-M3做图生文再生成的方式。具体是先用一个视觉模型把元器件图片转成文字描述，再用Qwen做理解分析。这种方案的好处是可以完全复用纯文本大模型的能力。

5.5 双大模型协同策略

很多人问：DeepSeek和千问会不会功能重复？为什么需要两个？

我的设计是把它们做差异化分工：

• DeepSeek走云端API：适合快速迭代、需要实时更新的场景。OCR识别、通用知识问答、尺寸估算这些任务放在DeepSeek上，因为它API返回速度快，并且能力持续在更新。
• 千问走本地部署：适合访问频繁、数据敏感的场景。比如产线每天要分析几千张图片，如果每张都走API，成本高、延迟大，还受网络波动影响。本地部署后，同样任务延迟从3秒降至1.2秒。

实际运维中发现一个很现实的问题：API服务不稳定是常态。DeepSeek高峰期排队，响应时间可能从1秒飙到15秒。所以我的代码里做了超时自动降级：DeepSeek调用超过5秒未返回，自动切换到本地千问。相反，如果千问在本地推理时GPU显存不足或者温度过高降频，自动切到API。双通道互备，保障系统7x24小时可用。

6. 完整推理流程与部署体验

6.1 端到端识别流程梳理

系统最终运行时的完整流程是这样的：

1. 工业相机拍摄板卡图片，分辨率2592x1944。
2. 图片送入YOLO检测服务，缩放到1280x1280，推理得到N个目标的类别、置信度和坐标框。
3. 根据坐标框裁剪每个元器件的小图，按类别分组。
4. 经过规则过滤：面积太小的裁剪图（比如小于32x32像素）直接送入OCR通道；面积足够、置信度高的送入大模型通道。
5. 大模型通道并行处理：DeepSeek API并行处理30%的样本（随机抽样质检），本地千问处理70%的样本（常规分析）。
6. 所有结果汇总到统一JSON结构，返回给前端展示。

{ "image_id": "PCB-20250115-0001", "detections": [ { "box": [1120, 340, 1200, 420], "class": "capacitor", "confidence": 0.92, "analysis": { "silkscreen": "104", "value": "100nF", "package": "0603", "status": "ok" } }, { "box": [780, 560, 820, 600], "class": "resistor", "confidence": 0.88, "analysis": { "silkscreen": "103", "value": "10kΩ", "package": "0402", "status": "warning", "warning": "丝印磨损，建议人工复核" } } ] }

整套流程在RTX 4090机器上，单张板卡的总耗时平均在1.8秒左右，其中YOLO推理占0.2秒，大模型分析占1.5秒，其他占0.1秒。对比纯YOLO方案（0.2秒），虽然时间变长了，但换回了丝印识别和异常分析能力，对产线质检来说是值得的。

6.2 Web端展示与交互设计

我开发了一个简单的Web管理界面，用户可以上传板卡图片，左侧显示YOLO检测框可视化结果，右侧显示大模型分析的详情列表。

这个界面有几个细节值得说说：

• 检测框按置信度着色：绿色表示置信度高（>0.9），黄色表示中等（0.7~0.9），红色表示低置信度（<0.7）。这样操作员一眼就能看出哪里的检测结果存疑。
• 点击某个检测框，右侧会联动展示对应元器件的大模型分析结果：丝印字符、推测参数、置信度、风险提示等。
• 底部有一个“批量分析”功能，可以一次上传多张板卡图片，系统自动排队分析。分析完成后会生成一个CSV导出文件，用于追溯和统计。

前端框架用的Vue3 + Element Plus，后端用的FastAPI。FastAPI天然支持异步处理，在处理大模型推理这种耗时操作时，可以用asyncio.create_task把任务丢到后台，避免阻塞主线程。这也是我选择FastAPI而不是Flask的原因。

6.3 部署环境与显存规划

我最终的部署方案是一台RTX 4090 24GB服务器，同时承担YOLO推理和千问本地推理。

显存规划如下：

• YOLOv8s推理：约1.2GB
• 千问2.5-VL-7B AWQ量化：约4.5GB
• FastAPI、数据处理缓存：约2GB
• 预留余量：约16GB

这个余量很重要。产线运行时，经常会有多张图片同时涌入的情况。如果显存占满，会导致CUDA Out of Memory，整个服务崩溃。我通过设置torch.cuda.set_per_process_memory_fraction(0.6)限制PyTorch最大使用显存，并在应用层做并发控制，同一时间最多执行两个大模型推理任务。

7. 常见问题与排查技巧实录

7.1 检测精度不足怎么办

这是被问得最多的问题。遇到mAP不理想，先不要急着调参，按以下顺序排查：

1. 检查标注质量：标注框是否紧贴目标边缘？是否有多标、漏标？我见过很多精度问题，根因都是标注时手抖把框拉大了。建议抽检10%的标注数据，人工复核。

2. 检查类别混淆：在混淆矩阵（yolo detect val会生成）里查看哪些类别互相误判。我发现电阻和电容经常混淆，原因是在某些角度下两者外形相似。解决方案是增加不同角度的训练样本，或者把难以区分的类别合并成一个“passive_components”类。

3. 调整图像分辨率：如果小目标多，把imgsz从640提到1280，精度通常能提升3~5个百分点。如果显存不够，可以考虑用SAHI（切片辅助推理）方案，在大图上切成小图分别推理再拼接，效果接近高分辨率输入但显存占用更小。

4. 增加难例挖掘：训练结束后，把验证集上预测失败（预测框与GT框IoU小于0.5）的图片单独抽出来，做数据增强扩充，重新加入训练集。

7.2 DeepSeek API调用常见错误

API调用中最常见的几种报错和处理方案：

我这里踩过最深的坑是图片编码问题。调用DeepSeek的多模态接口时，图片需要用Base64编码。但如果图片本身超过1MB，Base64编码后字符串会非常长，容易超出请求体的限制。解决方案是先把裁剪图压缩到512x512以内，质量设为85%的JPEG，再编码，通常能控制在300KB以内。

import base64 from PIL import Image import io def compress_image_to_base64(image_path, max_size=512): img = Image.open(image_path) img.thumbnail((max_size, max_size)) buffer = io.BytesIO() img.save(buffer, format="JPEG", quality=85) return base64.b64encode(buffer.getvalue()).decode()

7.3 整套系统联调时的隐性坑

1. YOLO坐标和大模型剪裁的坐标系一致性问题。YOLO输出的坐标是归一化的，需要换算回原图的分辨率。如果换算时用错了原图宽高比例（比如YOLO推理用的是1280x1280，原图是2592x1944），剪裁出来的图就会错位。最简单的方法是在YOLO推理时把agnostic_nms=False保持默认，并确保读取原图尺寸的代码和预处理时的尺寸一致。

2. 大模型返回的JSON解析要足够健壮。大模型即使设置了response_format=json_object，偶尔也会返回不规则的JSON。不要直接用json.loads()硬解析，先做一次格式清洗：去掉多余的空格、把单引号替换为双引号、提取{}之间的子串。我写了一个safe_json_parse函数，专门处理这类问题。

3. 并发控制。如果你的系统有多个用户在同时上传图片，FastAPI的异步特性和大模型推理的同步阻塞会产生冲突。我用的是信号量（asyncio.Semaphore）控制最大并发数，超过阈值直接返回“系统繁忙，请稍后重试”。

最后再分享一个小技巧

在实际部署这套系统后，我发现一个高频需求：元器件库存盘点。于是我把识别服务扩展了一下，在YOLO检测结果基础上，按类别累加元器件数量，然后调用本地千问生成一句简短的盘点摘要。比如：

当前板卡共检测到12类元器件，总计186个。其中电阻82个（占44.1%），电容54个（占29.0%），IC芯片12个（占6.5%）。主要IC包括主控芯片1颗、电源管理芯片3颗、存储芯片2颗。未发现明显缺件或错件风险。

这一段话对操作员来说，比看几十个检测框直观得多。这也正是“大模型+目标检测”组合的价值：检测模型把物理世界量化为坐标和类别，大模型再把坐标和类别转化为人类能直接理解的语言和判断。

根据我个人这段时间的实践体会，这套组合在电子制造领域的落地潜力还有很多没挖完。YOLO系列负责快速、准确地找到目标，DeepSeek和千问负责把找到的目标变成有价值的信息。两条链路各有分工，缺一不可。如果你正准备搭建类似的系统，不要急着把所有能力堆在一起，先跑通单流程，再加双通道容灾，最后逐步扩展业务逻辑。这样一步一步来，系统的稳定性会好很多。