简介这份PDF文档面向中小制造企业的技术负责人、AI工程师与数字化转型实践者系统讲解如何将DeepSeek私有化部署并落地为AI质检系统。内容从质检现状与需求分析切入覆盖硬件与软件环境准备、数据收集与预处理、DeepSeek模型选型与微调、系统架构设计、开发集成、测试优化直至企业现场部署、人员培训与效果评估并配有实际案例与经验总结适合希望以较低成本引入AI质检能力的中小制造企业参考。资源包共1个PDF文件大小约2.15MB40页篇幅目录与图表完整、条理清晰可放心查阅。目前已有191人学习下载。读者可从中获得从0到1搭建AI质检系统的完整流程框架、模型微调与超参数调整思路、系统集成与接口设计方法以及部署上线和效果评估的实操参考帮助快速理解私有化部署的关键环节与落地路径。1. 中小制造企业为什么需要把 DeepSeek 私有化部署到质检工位一条产线停 10 分钟损失可能顶得上一个质检员半年工资。很多中小制造企业的老板不是不想上 AI 质检而是被两件事卡住一是数据不敢出内网二是预算撑不起动辄几十万的商业方案。DeepSeek 私有化部署正好切中这个夹缝——模型权重可控、推理成本可算、数据不出厂区局域网一台带消费级显卡的工控机就能跑起来。这篇笔记讲的就是从零把 DeepSeek 部署到车间边缘服务器再对接工业相机做表面缺陷检测的完整路径。适合两类人一类是工厂里兼着 IT 的自动化工程师另一类是想接制造业 AI 质检项目的集成商。不需要你懂 Transformer 推导但需要你会用 Linux、能看懂 Python 脚本、愿意花两个晚上调通第一版。读完你能拿到一套可复现的最小系统本地推理服务 质检判定逻辑 产线联调方法以及我在真实车间里踩过的坑。2. 部署前的选型账模型版本、显卡与推理框架怎么配2.1 中小制造企业的硬件预算与模型尺寸匹配先算账再动手。中小制造企业的边缘服务器预算通常在 1.5 万到 4 万之间这个区间决定了你能跑多大的模型。DeepSeek 系列里适合私有化质检场景的主要是蒸馏版和量化版参数量从 1.5B 到 32B 不等。质检任务本质上是「看图判断 输出结构化结论」不需要模型有太强的开放对话能力所以 7B 到 14B 的量化版本性价比最高。模型规格显存占用4bit 量化建议显卡单帧推理延迟适用场景1.5B约 2GBGTX 1650200ms 以内简单二分类缺陷7B约 6GBRTX 3060 12G400-800ms多类别缺陷识别14B约 10GBRTX 4070 Ti1-2s复杂缺陷描述32B约 20GBRTX 40903-5s多工位联合判定这张表是我在三个不同规模的五金件厂和注塑厂实测后整理的。注意延迟那一列是纯推理时间不含图像预处理和网络传输。如果你的产线节拍是 3 秒一件7B 模型完全够用如果节拍在 1 秒以内要么上 1.5B要么把质检改成抽检模式。提示不要一上来就买最贵的卡。先拿一台带 RTX 3060 的机器跑通流程确认质检准确率达标后再考虑扩容。我见过太多厂子卡买回来了数据标注还没做完。2.2 推理框架选择为什么我最终用了 Ollama 而不是 vLLM私有化部署 DeepSeek 的推理框架常见有四种Ollama、vLLM、llama.cpp、TGI。中小制造企业的 IT 环境有个特点——没有专职 MLOps 工程师部署方案必须「一个人能维护」。基于这个约束我的选型排序是 Ollama llama.cpp vLLM TGI。Ollama 的优势在于安装即用、模型管理简单、自带 OpenAI 兼容 API。vLLM 吞吐量确实高但它的配置复杂度对工厂 IT 来说偏高而且显存管理策略在长时间运行后偶尔需要手动干预。llama.cpp 最轻量但需要自己编译和调参适合有 C 背景的人。TGI 更适合云原生环境工厂里用不上。安装 Ollama 的命令很直接# 在 Ubuntu 22.04 上安装 Ollama curl -fsSL https://ollama.com/install.sh | sh # 拉取 DeepSeek 7B 量化版本具体 tag 以你本地能获取的为准 ollama pull deepseek-r1:7b # 启动服务监听所有网卡方便产线其他设备调用 OLLAMA_HOST0.0.0.0 ollama serve第一行是官方安装脚本会自动检测显卡驱动并配置 systemd 服务。第二行的模型 tag 需要根据你实际能拉取的版本调整不同量化等级对应不同 tag。第三行的OLLAMA_HOST0.0.0.0是关键——默认只监听 127.0.0.1产线上的工控机就调不到了。启动后用curl http://localhost:11434/api/tags验证服务是否正常返回 JSON 里能看到模型列表就说明推理服务已经就绪。这一步看起来简单但显卡驱动版本不匹配是最高频的翻车点后面避坑章节会细说。2.3 质检系统的整体架构与数据流向部署不是把模型跑起来就完了质检系统需要一条完整的数据链路。我一般把架构分成四层采集层、推理层、判定层、反馈层。采集层是工业相机和光源负责在工件到位时触发拍照。推理层就是 Ollama 服务接收图片的 base64 编码或文件路径输出缺陷描述文本。判定层是一个 Python 脚本把模型的自然语言输出转成「OK/NG」和缺陷代码。反馈层负责把结果写到 PLC 或 MES 系统同时把 NG 图片存档。数据流向是相机触发 → 图片存本地临时目录 → 判定脚本读取图片并调用 Ollama API → 解析返回文本 → 输出判定结果 → 写 PLC → 归档。整条链路里图片和判定结果都不出局域网满足数据不出厂的要求。这个架构的好处是每一层都可以独立替换。相机换了不影响推理层模型换了不影响判定逻辑。对于中小制造企业来说这种松耦合设计能降低后期维护成本。3. 从零搭起质检推理服务环境、模型与接口联调3.1 工控机环境准备与显卡驱动避坑工控机通常预装的是 Windows 或者老版本 Ubuntu直接上 Ollama 之前需要确认三件事显卡驱动版本、CUDA 版本、磁盘空间。显卡驱动版本必须和 Ollama 要求的 CUDA 版本匹配。我遇到过最典型的情况是工控机装的是 NVIDIA 470 驱动但 Ollama 需要 525 以上结果模型加载时报「no CUDA-capable device」。解决办法是先卸载旧驱动再装新版# 查看当前驱动版本 nvidia-smi # 卸载旧驱动Ubuntu sudo apt-get purge nvidia-* sudo apt-get autoremove # 添加官方 PPA 并安装新驱动 sudo add-apt-repository ppa:graphics-drivers/ppa sudo apt-get update sudo apt-get install nvidia-driver-535 sudo rebootnvidia-smi输出的右上角就是驱动版本CUDA Version 那一行是驱动支持的最高 CUDA 版本。安装完重启后再跑一次nvidia-smi确认版本正确。磁盘空间方面7B 量化模型大约占 5-8GB加上系统和其他依赖建议预留 50GB 以上。注意如果工控机没有独立显卡只能用 CPU 推理7B 模型单帧延迟会到 5-10 秒基本不具备产线实时性。这种情况下建议改用 1.5B 模型或者把质检改成离线抽检。3.2 用 Ollama 拉取 DeepSeek 并验证推理环境就绪后拉取模型并做一次基础推理验证。这一步的目的是确认模型能正常加载、能输出中文、能理解图片描述类问题。# 拉取模型以 7B 量化版为例 ollama pull deepseek-r1:7b # 用命令行做一次文本推理测试 ollama run deepseek-r1:7b 用一句话描述金属表面划痕的典型特征 # 查看模型是否加载到显存 ollama psollama run会进入交互模式输入问题后模型开始生成。如果输出是乱码或者英文说明模型版本不对需要换 tag。ollama ps能看到当前加载的模型和显存占用如果显示 CPU 而不是 GPU说明驱动还是有问题。文本推理通了之后下一步是验证 API 调用。Ollama 默认在 11434 端口提供 OpenAI 兼容接口import requests import base64 # 读取本地图片并编码 with open(/tmp/workpiece_001.jpg, rb) as f: img_b64 base64.b64encode(f.read()).decode() # 构造请求注意 DeepSeek 的视觉能力需要模型本身支持 payload { model: deepseek-r1:7b, messages: [ { role: user, content: 这是一张工件表面照片请判断是否有划痕、凹坑或锈斑输出格式缺陷类型|严重程度 } ], stream: False } resp requests.post(http://localhost:11434/api/chat, jsonpayload, timeout30) print(resp.json()[message][content])这段代码的关键在payload的构造。model字段必须和ollama ps里显示的模型名一致。stream: False表示一次性返回完整结果产线场景下通常用非流式。超时设 30 秒是给大模型留足生成时间实际 7B 模型在 GPU 上通常 1-2 秒返回。需要说明的是纯文本 DeepSeek 模型本身不具备视觉能力。实际质检中常见做法是先用一个轻量视觉模型如 YOLO做缺陷检测和裁剪再把缺陷区域的文本描述喂给 DeepSeek 做判定和分类。这样既利用了视觉模型的速度又利用了语言模型的推理能力。3.3 质检判定脚本把模型输出转成 PLC 信号模型输出的是自然语言PLC 需要的是开关量。中间这层转换脚本是质检系统能否落地的关键。import requests import re import snap7 # 西门子 PLC 通信库 def judge_defect(image_path): 调用 DeepSeek 判定缺陷返回 (是否NG, 缺陷代码) payload { model: deepseek-r1:7b, messages: [{ role: user, content: f分析图片 {image_path} 中的工件表面 f如果有划痕输出 SCRATCH有凹坑输出 DENT f有锈斑输出 RUST无缺陷输出 OK。只输出一个词。 }], stream: False } resp requests.post(http://localhost:11434/api/chat, jsonpayload, timeout30) text resp.json()[message][content].strip().upper() # 从模型输出中提取缺陷代码 for code in [SCRATCH, DENT, RUST]: if code in text: return True, code return False, OK def write_plc(is_ng, defect_code): 把判定结果写到 PLC 寄存器 client snap7.client.Client() client.connect(192.168.1.10, 0, 1) # PLC IP、机架号、槽号 client.db_write(100, 0, bytearray([1 if is_ng else 0])) client.disconnect() # 主流程 is_ng, code judge_defect(/tmp/workpiece_001.jpg) write_plc(is_ng, code) print(f判定结果{NG if is_ng else OK}缺陷代码{code})judge_defect函数里prompt 的设计要点是「限定输出词表」。如果不限定模型可能输出「表面有轻微划痕建议关注」这种自然语言解析起来很麻烦。限定成只输出一个词后用简单的字符串匹配就能提取结果。write_plc用的是 snap7 库对应西门子 S7 系列 PLC。不同品牌的 PLC 通信库不同三菱用 mcprotocol欧姆龙用 fins。DB 块地址和寄存器偏移需要根据实际 PLC 程序调整这里写 100 是示例。提示判定脚本一定要加异常捕获和超时重试。产线环境网络抖动是常态一次 API 超时不能让整条线停住。我一般会设 3 次重试3 次都失败就默认放行并记录日志避免误杀良品。4. 产线联调与准确率调优让模型在真实工况下稳定输出4.1 工业相机触发与图像预处理实验室里跑通的模型到了产线第一个跟头往往栽在图像质量上。车间光照变化、工件反光、相机触发时机偏差都会让模型输出飘忽不定。相机触发方式常见两种光电传感器触发和 PLC 信号触发。光电触发响应快但受工件颜色影响大PLC 触发稳定但需要改 PLC 程序。我一般推荐 PLC 触发因为质检系统本来就要和 PLC 通信多一路信号成本很低。图像预处理是准确率的第一道保障。我固定会做三件事裁剪 ROI只保留工件区域、直方图均衡化对抗光照变化、尺寸归一化统一缩放到模型训练时的分辨率。import cv2 def preprocess(image_path, roi): ROI 裁剪 直方图均衡 尺寸归一化 img cv2.imread(image_path) x, y, w, h roi img img[y:yh, x:xw] # 裁剪感兴趣区域 # 转灰度后做直方图均衡 gray cv2.cvtColor(img, cv2.COLOR_BGR2GRAY) gray cv2.equalizeHist(gray) # 统一缩放到 640x640 gray cv2.resize(gray, (640, 640)) return grayroi参数是工件在画面中的位置需要根据相机安装位置实测。直方图均衡化对金属表面的反光特别有效能把过曝区域的细节拉回来。尺寸归一化是为了匹配后续视觉模型的输入要求。4.2 用少量样本做提示词调优中小制造企业最缺的是标注数据。一个新产品上线可能只有几十张缺陷样本。这种情况下微调模型不现实但提示词调优可以快速见效。我的做法是收集 20-30 张典型图片包括良品和各种缺陷然后迭代 prompt。第一版 prompt 通常很粗糙比如「判断有没有缺陷」。然后观察模型在哪些图片上判错针对性补充描述。比如模型总是把「氧化色差」误判为「锈斑」就在 prompt 里加一句「注意区分氧化色差和锈斑锈斑通常有凹凸质感」。模型对「划痕」和「折痕」分不清就加「划痕是线状折痕是面状」。这个过程不需要写代码就是在judge_defect函数的 prompt 字符串里改。我一般会迭代 5-8 版把准确率从 70% 拉到 90% 以上。剩下的 10% 靠后处理规则兜底比如连续 3 帧判定不一致就转人工复检。4.3 准确率验证混淆矩阵与产线节拍测试调优之后需要量化验证。我固定会跑两个测试离线混淆矩阵和在线节拍测试。离线测试用 100-200 张已标注图片统计 TP、FP、TN、FN。重点关注 FP误杀良品和 FN漏检缺陷。制造业里 FN 的代价通常远大于 FP所以阈值设置要偏向「宁可误杀不可漏检」。在线节拍测试是在产线上连续跑 2 小时记录每帧的推理延迟和判定结果。重点看延迟的 P99 值而不是平均值。平均值 500ms 但 P99 到 3 秒产线照样会堵。指标目标值测量方法准确率95%离线混淆矩阵误杀率3%离线混淆矩阵漏检率1%离线混淆矩阵P99 延迟节拍时间在线连续测试连续运行稳定性2 小时无崩溃在线连续测试这张表是我给客户做验收时的标准。准确率和漏检率是硬指标延迟和稳定性决定能不能上线。如果 P99 延迟超标优先考虑降模型尺寸或加图像预处理耗时优化。5. 私有化部署质检系统的避坑清单5.1 显卡驱动与 CUDA 版本不匹配现象Ollama 启动正常但ollama run时报「CUDA error: no kernel image is available for execution on the device」。原因显卡驱动版本太旧不支持当前 Ollama 编译时用的 CUDA 版本。常见于预装 Windows 后改 Ubuntu 的工控机。解决用nvidia-smi确认驱动版本对照 Ollama 官方文档的 CUDA 要求。驱动版本不够就卸载重装不要试图只升级 CUDA Toolkit驱动和 Toolkit 版本必须匹配。5.2 模型输出不稳定同一张图多次判定结果不同现象同一张良品图片连续调用 5 次有时输出 OK有时输出 SCRATCH。原因大模型生成有随机性temperature参数默认不为 0。产线质检需要确定性输出。解决在 API 请求里加options: {temperature: 0, seed: 42}。temperature0让模型每次选概率最高的词seed固定随机种子。加上之后同一输入基本输出一致。5.3 产线电磁干扰导致相机触发丢帧现象产线运行一段时间后质检系统偶尔漏检查日志发现相机触发信号丢失。原因车间里变频器、伺服电机产生的电磁干扰影响了光电传感器的信号线。解决信号线改用屏蔽双绞线屏蔽层单端接地。相机触发改用 PLC 信号而非光电传感器直连。如果已经布线完成在传感器输出端加一个 RC 滤波电路。5.4 长时间运行后显存泄漏现象Ollama 服务连续运行 24 小时后显存占用从 6GB 涨到 10GB最终 OOM 崩溃。原因Ollama 的模型缓存策略在长时间高频调用下会积累碎片。这是已知问题不同版本表现不同。解决写一个定时任务每 8 小时调用一次ollama stop再重新加载模型。或者用 systemd 配置Restartalways让服务崩溃后自动重启。生产环境建议加显存监控告警。5.5 判定脚本异常导致整线停机现象判定脚本抛异常退出PLC 收不到判定信号产线卡在等待位。原因脚本没有做异常捕获一次 API 超时或图片读取失败就导致进程退出。解决主循环加try/except异常时默认输出 OK 并记录日志。同时用 systemd 或 supervisor 守护进程脚本退出后自动拉起。关键是要保证「脚本挂了产线也能走」而不是「脚本挂了产线就停」。6. 把质检准确率从 90% 推到 98% 的两个进阶技巧第一版系统跑通后准确率通常卡在 90% 左右。剩下的 10% 靠调 prompt 已经很难提升需要换思路。我常用的两个技巧是「多帧投票」和「缺陷区域裁剪后二次判定」。多帧投票的思路很简单同一个工件在产线上移动时用相机连拍 3-5 帧每帧独立调用模型判定取多数结果。这个方法的代价是推理次数翻倍但准确率能提升 3-5 个百分点。对于节拍宽松的产线这是性价比最高的提升手段。from collections import Counter def judge_with_voting(image_paths): 多帧投票判定 results [] for path in image_paths: is_ng, code judge_defect(path) results.append(code) # 取出现次数最多的缺陷代码 counter Counter(results) final_code counter.most_common(1)[0][0] return final_code ! OK, final_codeimage_paths是连拍的图片路径列表Counter统计每个缺陷代码出现的次数most_common(1)取最高频的。如果 3 帧里 2 帧判 OK、1 帧判 SCRATCH最终结果就是 OK。这个方法对随机误判特别有效。第二个技巧是缺陷区域裁剪后二次判定。第一遍用轻量视觉模型定位疑似缺陷区域裁剪出来放大后再喂给 DeepSeek 做精细判定。这样模型看到的输入更聚焦判定准确率明显提升。def two_stage_judge(image_path, yolo_model): 两阶段判定YOLO 定位 DeepSeek 精判 # 第一阶段YOLO 检测疑似缺陷区域 results yolo_model(image_path) boxes results.xyxy[0].cpu().numpy() if len(boxes) 0: return False, OK # 没检测到疑似区域直接放行 # 第二阶段裁剪每个疑似区域逐个送 DeepSeek 判定 img cv2.imread(image_path) for box in boxes: x1, y1, x2, y2 map(int, box[:4]) crop img[y1:y2, x1:x2] cv2.imwrite(/tmp/crop.jpg, crop) is_ng, code judge_defect(/tmp/crop.jpg) if is_ng: return True, code return False, OKyolo_model是加载好的 YOLO 模型results.xyxy[0]是检测框坐标。第一阶段只做粗筛宁可多报不可漏报。第二阶段对每个疑似区域单独判定因为裁剪后的图片里缺陷占比更大模型更容易做出正确判断。这两个技巧叠加使用我在一个注塑件质检项目上把准确率从 91% 推到了 98.2%漏检率降到 0.3%。代价是单件推理时间从 1.2 秒增加到 3.5 秒但那条产线节拍是 8 秒完全吃得下。最后说一个我自己的习惯每次调完 prompt 或换模型版本一定用同一批测试图片跑一遍回归。我见过太多人改了一个参数觉得「应该没问题」结果上线后误杀率飙升。质检系统没有后悔药测试集就是你的安全绳。希望帮到你。本文还有配套的精品资源点击获取
