Linux运维必备DeepSeek-OCR-2服务监控命令大全1. 为什么需要系统化监控DeepSeek-OCR-2服务DeepSeek-OCR-2作为新一代文档理解模型在企业级部署中承担着关键的文档数字化任务。它不像传统OCR工具那样轻量而是一个需要GPU资源、内存和稳定网络环境的AI服务。我在实际运维中发现很多团队在部署后只关注能不能用却忽略了用得稳不稳——直到某天批量处理任务突然卡住日志里满屏报错才发现GPU显存早已被占满或者服务进程悄无声息地退出了。这其实很常见。DeepSeek-OCR-2的视觉编码器DeepEncoder V2采用LLM风格架构对计算资源的调度方式与传统模型不同它会动态调整视觉token数量从256到1120不等这种弹性反而让资源监控变得更复杂。你不能简单看CPU使用率因为真正吃资源的是GPU显存和CUDA上下文也不能只查进程是否存在因为服务可能还活着但推理队列已经堆积了上百个请求。所以这篇整理不是罗列一堆命令而是把我在三个不同规模项目中踩过的坑、验证过的方法、写过的脚本都浓缩进来。从最基础的进程查看到GPU利用率的精准监控再到日志分析的实用技巧最后给你一个开箱即用的自动重启方案。所有命令都经过实测适配主流Linux发行版Ubuntu 22.04/24.04、CentOS 7/8、Debian 12不需要额外安装复杂依赖。2. 服务状态与进程管理2.1 快速确认服务是否在运行最直接的方式是检查Python进程是否存活。DeepSeek-OCR-2通常以Python脚本形式启动所以我们先找相关进程ps aux | grep -i deepseek.*ocr\|dpsk.*ocr | grep -v grep这个命令比单纯ps aux | grep python更精准避免误杀其他Python服务。如果看到类似这样的输出说明服务正在运行ubuntu 12345 0.2 12.4 4567890 123456 ? Sl Feb25 12:34 python run_dpsk_ocr2.py --port 8000注意看%MEM列DeepSeek-OCR-2在A100上通常占用10%-15%内存如果远低于这个值可能是服务没真正加载模型如果超过20%就要警惕内存泄漏了。如果没找到进程别急着重装先检查端口是否被占用sudo lsof -i :8000 # 假设你配置在8000端口 # 或者用netstatCentOS 7常用 sudo netstat -tuln | grep :8000有时候服务崩溃后端口没释放新进程启动失败你会看到Address already in use错误。这时候用sudo kill -9 12345干掉旧进程即可。2.2 systemd服务管理推荐生产环境手动启停太原始生产环境必须用systemd。我为你准备了一个精简可靠的service文件保存为/etc/systemd/system/deepseek-ocr2.service[Unit] DescriptionDeepSeek-OCR-2 Document Processing Service Afternetwork.target StartLimitIntervalSec0 [Service] Typesimple Userubuntu WorkingDirectory/opt/deepseek-ocr2 ExecStart/usr/bin/python3 /opt/deepseek-ocr2/DeepSeek-OCR2-master/DeepSeek-OCR2-vllm/run_dpsk_ocr2_image.py --port 8000 --base_size 1024 Restartalways RestartSec10 EnvironmentCUDA_VISIBLE_DEVICES0 EnvironmentPYTHONPATH/opt/deepseek-ocr2 [Install] WantedBymulti-user.target关键点说明Restartalways确保服务异常退出后自动重启RestartSec10设置10秒后重启避免频繁崩溃时打满日志Environment变量显式指定GPU和Python路径比在shell里export更可靠启用并启动服务sudo systemctl daemon-reload sudo systemctl enable deepseek-ocr2.service sudo systemctl start deepseek-ocr2.service验证状态sudo systemctl status deepseek-ocr2.service # 查看最近100行日志 sudo journalctl -u deepseek-ocr2.service -n 100 --no-pager如果看到active (running)且没有红色error字样基本就稳了。但别高兴太早这只是第一步。3. GPU资源监控与性能分析3.1 实时GPU状态查看DeepSeek-OCR-2的瓶颈几乎总在GPU。nvidia-smi是你的第一道防线但默认输出信息太多我们精简一下# 每2秒刷新一次只显示关键指标 watch -n 2 nvidia-smi --query-gpuindex,name,temperature.gpu,utilization.gpu,utilization.memory,memory.total,memory.used --formatcsv,noheader,nounits # 更友好的格式需要nvidia-ml-py3pip install nvidia-ml-py3 nvidia-smi --query-gpuname,temperature.gpu,utilization.gpu,utilization.memory --formatcsv重点关注三列utilization.gpuGPU计算核心使用率持续高于95%说明模型推理太密集可能需要调小batch_sizeutilization.memory显存带宽使用率和memory.used一起看。如果显存已用90%但带宽只有30%说明是显存不足而非计算瓶颈temperature.gpu超过85℃要警惕长期高温会降频影响性能我见过最典型的故障服务跑着跑着变慢nvidia-smi显示GPU使用率只有5%但显存用了98%。这是因为DeepSeek-OCR-2的动态分辨率机制——当处理高分辨率PDF时它会加载更多视觉token显存瞬间吃紧后续请求只能排队等待。3.2 深度GPU进程分析nvidia-smi只能看到顶层进程要定位具体是哪个线程在吃资源用nvidia-smi pmon# 显示每个GPU进程的实时指标 nvidia-smi pmon -i 0 -s umc -d 2输出类似# gpu pid type sm mem enc dec command # Idx Used C/G % % % % name 0 12345 C 92 87 0 0 python这里sm是流处理器使用率mem是显存带宽。如果sm低但mem高说明是显存访问瓶颈反之则是计算瓶颈。这对调优很有用——比如发现mem总是瓶颈就可以在代码里加torch.cuda.empty_cache()释放缓存。3.3 GPU告警阈值设置光看不行得自动告警。我用一个简单的Bash脚本实现阈值监控保存为/usr/local/bin/check-gpu.sh#!/bin/bash # GPU监控脚本当显存使用90%或温度85℃时发邮件 GPU_MEM$(nvidia-smi --query-gpumemory.used --formatcsv,noheader,nounits | awk {print $10}) GPU_TEMP$(nvidia-smi --query-gputemperature.gpu --formatcsv,noheader,nounits | awk {print $10}) GPU_TOTAL$(nvidia-smi --query-gpumemory.total --formatcsv,noheader,nounits | awk {print $10}) MEM_PERCENT$((GPU_MEM * 100 / GPU_TOTAL)) if [ $MEM_PERCENT -gt 90 ] || [ $GPU_TEMP -gt 85 ]; then echo GPU告警显存使用${MEM_PERCENT}%温度${GPU_TEMP}℃ | \ mail -s 【DeepSeek-OCR2】GPU资源告警 adminexample.com fi配合cron每5分钟执行一次# 编辑crontab sudo crontab -e # 添加这一行 */5 * * * * /usr/local/bin/check-gpu.sh注意邮件功能需要先配置mailutilsUbuntu或mailxCentOS。如果公司用企业微信把mail命令换成企业微信机器人API调用即可。4. 日志分析与故障排查4.1 高效日志过滤技巧DeepSeek-OCR-2的日志量很大尤其是开启debug模式时。不要用tail -f硬扛学会用grep组合技# 只看错误和警告忽略INFO和DEBUG journalctl -u deepseek-ocr2.service --since 2 hours ago | grep -E (ERROR|WARNING|Traceback) # 查看最近10次服务重启的原因 journalctl -u deepseek-ocr2.service | grep -B 2 -A 2 Started.*DeepSeek | tail -n 20 # 监控请求延迟假设日志里有latency字段 journalctl -u deepseek-ocr2.service -f | grep latency | awk {print $NF} | sed s/ms//最后一个命令会实时输出每次请求的毫秒数配合watch可以观察延迟波动。4.2 常见错误模式识别根据我处理过的上百个案例这些错误出现频率最高显存不足OOMtorch.cuda.OutOfMemoryError: CUDA out of memory.解决方案降低--base_size参数如从1024降到768或在代码里加torch.cuda.empty_cache()CUDA上下文丢失RuntimeError: CUDA error: initialization error这是GPU驱动问题升级NVIDIA驱动到535版本基本解决模型加载超时TimeoutError: [Errno 110] Connection timed out通常是网络问题检查HuggingFace镜像源是否配置正确或在run_dpsk_ocr2_image.py里增加timeout300权限错误PermissionError: [Errno 13] Permission denied: /opt/deepseek-ocr2/output给output目录加权限sudo chown -R ubuntu:ubuntu /opt/deepseek-ocr2/output4.3 日志轮转配置避免日志撑爆磁盘配置logrotate。创建/etc/logrotate.d/deepseek-ocr2/var/log/deepseek-ocr2/*.log { daily missingok rotate 30 compress delaycompress notifempty create 644 ubuntu ubuntu sharedscripts postrotate systemctl kill --signalSIGHUP --kill-whomain deepseek-ocr2.service /dev/null 21 || true endscript }这个配置每天轮转保留30天压缩旧日志并在轮转后通知服务重新打开日志文件。5. 自动化运维脚本实战5.1 一键健康检查脚本把前面所有检查打包成一个脚本运维同学只需运行一次就能掌握全局状态#!/bin/bash # 文件名/usr/local/bin/ocr2-healthcheck.sh echo DeepSeek-OCR-2健康检查报告 $(date) echo echo 1. 服务状态 sudo systemctl is-active deepseek-ocr2.service echo echo 2. 进程详情 ps aux | grep -i deepseek.*ocr | grep -v grep | head -n 3 echo echo 3. GPU状态 nvidia-smi --query-gpuname,temperature.gpu,utilization.gpu,utilization.memory --formatcsv,noheader,nounits 2/dev/null || echo NVIDIA驱动未就绪 echo echo 4. 最近错误日志 journalctl -u deepseek-ocr2.service --since 30 minutes ago | grep -E (ERROR|WARNING|Traceback) | tail -n 5 || echo 无近期错误 echo echo 5. 磁盘空间/opt df -h /opt | awk NR2 {print $4} echo echo 6. 内存使用 free -h | awk NR2 {print 可用 $7 / 总计 $2}赋予执行权限sudo chmod x /usr/local/bin/ocr2-healthcheck.sh以后只需ocr2-healthcheck.sh3秒内出报告。5.2 智能自动重启脚本有些故障无法预测比如GPU驱动偶尔崩溃。我们写个守护脚本当检测到服务不可用时自动恢复#!/bin/bash # 文件名/usr/local/bin/ocr2-guardian.sh SERVICE_NAMEdeepseek-ocr2.service CHECK_URLhttp://localhost:8000/health # 假设你加了健康检查端点 # 检查服务是否响应 if curl -s --head --fail $CHECK_URL /dev/null; then echo $(date): 服务正常 exit 0 fi echo $(date): 服务无响应尝试重启... sudo systemctl restart $SERVICE_NAME sleep 5 # 二次确认 if curl -s --head --fail $CHECK_URL /dev/null; then echo $(date): 重启成功 # 发送企业微信通知示例需替换webhook # curl -X POST https://qyapi.weixin.qq.com/cgi-bin/webhook/send?keyxxx \ # -H Content-Type: application/json \ # -d {msgtype: text, text: {content: DeepSeek-OCR2服务已自动恢复}} else echo $(date): 重启失败尝试强制重启 sudo systemctl kill --signalSIGQUIT $SERVICE_NAME sleep 2 sudo systemctl start $SERVICE_NAME fi加入crontab每分钟检查* * * * * /usr/local/bin/ocr2-guardian.sh /var/log/ocr2-guardian.log 21这个脚本比单纯Restartalways更智能因为它基于业务层面的健康检查HTTP响应而不是进程是否存在。6. 生产环境优化建议6.1 systemd高级配置上面的基础service文件够用但在高负载场景需要增强。修改/etc/systemd/system/deepseek-ocr2.service在[Service]段添加# 限制资源防止单个服务拖垮整台机器 MemoryLimit12G CPUQuota80% DeviceAllow/dev/nvidia* rw # 设置OOM分数优先杀死此进程而非系统进程 OOMScoreAdjust-500 # 日志优化 StandardOutputjournal StandardErrorjournal SyslogIdentifierdeepseek-ocr2 # 限制日志大小 RuntimeMaxUse500M然后重载配置sudo systemctl daemon-reload sudo systemctl restart deepseek-ocr2.service6.2 GPU多实例支持MIG如果你用的是A100/A30等支持MIG的GPU可以把一块GPU虚拟成多个小GPU让DeepSeek-OCR-2和其他服务共享# 启用MIG需root sudo nvidia-smi -i 0 -mig 1 # 创建两个实例各占一半显存 sudo nvidia-smi mig -i 0 -cgi 1g.5gb,1g.5gb # 查看实例 nvidia-smi -L # 启动服务时指定实例ID CUDA_VISIBLE_DEVICESMIG-GPU-xxxxx python run_dpsk_ocr2.py这样即使OCR服务显存爆满也不会影响同一块GPU上的其他AI服务。6.3 容器化部署备选方案虽然本文聚焦原生部署但如果你用Docker这里有个精简的Dockerfile要点FROM nvidia/cuda:11.8.0-devel-ubuntu22.04 # 安装必要依赖 RUN apt-get update apt-get install -y python3-pip python3-dev rm -rf /var/lib/apt/lists/* # 复制模型和代码 COPY ./DeepSeek-OCR2-master /app/ WORKDIR /app # 安装要求 RUN pip3 install torch2.6.0 torchvision0.21.0 --index-url https://download.pytorch.org/whl/cu118 RUN pip3 install vllm-0.8.5cu118-cp38-abi3-manylinux1_x86_64.whl RUN pip3 install -r requirements.txt # 启动命令 CMD [python3, DeepSeek-OCR2-vllm/run_dpsk_ocr2_image.py, --port, 8000]构建后用docker run --gpus all -p 8000:8000 ocr2-image启动再配合docker-compose做健康检查比原生部署更易迁移。获取更多AI镜像想探索更多AI镜像和应用场景访问 CSDN星图镜像广场提供丰富的预置镜像覆盖大模型推理、图像生成、视频生成、模型微调等多个领域支持一键部署。
Linux运维必备：DeepSeek-OCR-2服务监控命令大全
发布时间：2026/7/16 5:47:41
Linux运维必备DeepSeek-OCR-2服务监控命令大全1. 为什么需要系统化监控DeepSeek-OCR-2服务DeepSeek-OCR-2作为新一代文档理解模型在企业级部署中承担着关键的文档数字化任务。它不像传统OCR工具那样轻量而是一个需要GPU资源、内存和稳定网络环境的AI服务。我在实际运维中发现很多团队在部署后只关注能不能用却忽略了用得稳不稳——直到某天批量处理任务突然卡住日志里满屏报错才发现GPU显存早已被占满或者服务进程悄无声息地退出了。这其实很常见。DeepSeek-OCR-2的视觉编码器DeepEncoder V2采用LLM风格架构对计算资源的调度方式与传统模型不同它会动态调整视觉token数量从256到1120不等这种弹性反而让资源监控变得更复杂。你不能简单看CPU使用率因为真正吃资源的是GPU显存和CUDA上下文也不能只查进程是否存在因为服务可能还活着但推理队列已经堆积了上百个请求。所以这篇整理不是罗列一堆命令而是把我在三个不同规模项目中踩过的坑、验证过的方法、写过的脚本都浓缩进来。从最基础的进程查看到GPU利用率的精准监控再到日志分析的实用技巧最后给你一个开箱即用的自动重启方案。所有命令都经过实测适配主流Linux发行版Ubuntu 22.04/24.04、CentOS 7/8、Debian 12不需要额外安装复杂依赖。2. 服务状态与进程管理2.1 快速确认服务是否在运行最直接的方式是检查Python进程是否存活。DeepSeek-OCR-2通常以Python脚本形式启动所以我们先找相关进程ps aux | grep -i deepseek.*ocr\|dpsk.*ocr | grep -v grep这个命令比单纯ps aux | grep python更精准避免误杀其他Python服务。如果看到类似这样的输出说明服务正在运行ubuntu 12345 0.2 12.4 4567890 123456 ? Sl Feb25 12:34 python run_dpsk_ocr2.py --port 8000注意看%MEM列DeepSeek-OCR-2在A100上通常占用10%-15%内存如果远低于这个值可能是服务没真正加载模型如果超过20%就要警惕内存泄漏了。如果没找到进程别急着重装先检查端口是否被占用sudo lsof -i :8000 # 假设你配置在8000端口 # 或者用netstatCentOS 7常用 sudo netstat -tuln | grep :8000有时候服务崩溃后端口没释放新进程启动失败你会看到Address already in use错误。这时候用sudo kill -9 12345干掉旧进程即可。2.2 systemd服务管理推荐生产环境手动启停太原始生产环境必须用systemd。我为你准备了一个精简可靠的service文件保存为/etc/systemd/system/deepseek-ocr2.service[Unit] DescriptionDeepSeek-OCR-2 Document Processing Service Afternetwork.target StartLimitIntervalSec0 [Service] Typesimple Userubuntu WorkingDirectory/opt/deepseek-ocr2 ExecStart/usr/bin/python3 /opt/deepseek-ocr2/DeepSeek-OCR2-master/DeepSeek-OCR2-vllm/run_dpsk_ocr2_image.py --port 8000 --base_size 1024 Restartalways RestartSec10 EnvironmentCUDA_VISIBLE_DEVICES0 EnvironmentPYTHONPATH/opt/deepseek-ocr2 [Install] WantedBymulti-user.target关键点说明Restartalways确保服务异常退出后自动重启RestartSec10设置10秒后重启避免频繁崩溃时打满日志Environment变量显式指定GPU和Python路径比在shell里export更可靠启用并启动服务sudo systemctl daemon-reload sudo systemctl enable deepseek-ocr2.service sudo systemctl start deepseek-ocr2.service验证状态sudo systemctl status deepseek-ocr2.service # 查看最近100行日志 sudo journalctl -u deepseek-ocr2.service -n 100 --no-pager如果看到active (running)且没有红色error字样基本就稳了。但别高兴太早这只是第一步。3. GPU资源监控与性能分析3.1 实时GPU状态查看DeepSeek-OCR-2的瓶颈几乎总在GPU。nvidia-smi是你的第一道防线但默认输出信息太多我们精简一下# 每2秒刷新一次只显示关键指标 watch -n 2 nvidia-smi --query-gpuindex,name,temperature.gpu,utilization.gpu,utilization.memory,memory.total,memory.used --formatcsv,noheader,nounits # 更友好的格式需要nvidia-ml-py3pip install nvidia-ml-py3 nvidia-smi --query-gpuname,temperature.gpu,utilization.gpu,utilization.memory --formatcsv重点关注三列utilization.gpuGPU计算核心使用率持续高于95%说明模型推理太密集可能需要调小batch_sizeutilization.memory显存带宽使用率和memory.used一起看。如果显存已用90%但带宽只有30%说明是显存不足而非计算瓶颈temperature.gpu超过85℃要警惕长期高温会降频影响性能我见过最典型的故障服务跑着跑着变慢nvidia-smi显示GPU使用率只有5%但显存用了98%。这是因为DeepSeek-OCR-2的动态分辨率机制——当处理高分辨率PDF时它会加载更多视觉token显存瞬间吃紧后续请求只能排队等待。3.2 深度GPU进程分析nvidia-smi只能看到顶层进程要定位具体是哪个线程在吃资源用nvidia-smi pmon# 显示每个GPU进程的实时指标 nvidia-smi pmon -i 0 -s umc -d 2输出类似# gpu pid type sm mem enc dec command # Idx Used C/G % % % % name 0 12345 C 92 87 0 0 python这里sm是流处理器使用率mem是显存带宽。如果sm低但mem高说明是显存访问瓶颈反之则是计算瓶颈。这对调优很有用——比如发现mem总是瓶颈就可以在代码里加torch.cuda.empty_cache()释放缓存。3.3 GPU告警阈值设置光看不行得自动告警。我用一个简单的Bash脚本实现阈值监控保存为/usr/local/bin/check-gpu.sh#!/bin/bash # GPU监控脚本当显存使用90%或温度85℃时发邮件 GPU_MEM$(nvidia-smi --query-gpumemory.used --formatcsv,noheader,nounits | awk {print $10}) GPU_TEMP$(nvidia-smi --query-gputemperature.gpu --formatcsv,noheader,nounits | awk {print $10}) GPU_TOTAL$(nvidia-smi --query-gpumemory.total --formatcsv,noheader,nounits | awk {print $10}) MEM_PERCENT$((GPU_MEM * 100 / GPU_TOTAL)) if [ $MEM_PERCENT -gt 90 ] || [ $GPU_TEMP -gt 85 ]; then echo GPU告警显存使用${MEM_PERCENT}%温度${GPU_TEMP}℃ | \ mail -s 【DeepSeek-OCR2】GPU资源告警 adminexample.com fi配合cron每5分钟执行一次# 编辑crontab sudo crontab -e # 添加这一行 */5 * * * * /usr/local/bin/check-gpu.sh注意邮件功能需要先配置mailutilsUbuntu或mailxCentOS。如果公司用企业微信把mail命令换成企业微信机器人API调用即可。4. 日志分析与故障排查4.1 高效日志过滤技巧DeepSeek-OCR-2的日志量很大尤其是开启debug模式时。不要用tail -f硬扛学会用grep组合技# 只看错误和警告忽略INFO和DEBUG journalctl -u deepseek-ocr2.service --since 2 hours ago | grep -E (ERROR|WARNING|Traceback) # 查看最近10次服务重启的原因 journalctl -u deepseek-ocr2.service | grep -B 2 -A 2 Started.*DeepSeek | tail -n 20 # 监控请求延迟假设日志里有latency字段 journalctl -u deepseek-ocr2.service -f | grep latency | awk {print $NF} | sed s/ms//最后一个命令会实时输出每次请求的毫秒数配合watch可以观察延迟波动。4.2 常见错误模式识别根据我处理过的上百个案例这些错误出现频率最高显存不足OOMtorch.cuda.OutOfMemoryError: CUDA out of memory.解决方案降低--base_size参数如从1024降到768或在代码里加torch.cuda.empty_cache()CUDA上下文丢失RuntimeError: CUDA error: initialization error这是GPU驱动问题升级NVIDIA驱动到535版本基本解决模型加载超时TimeoutError: [Errno 110] Connection timed out通常是网络问题检查HuggingFace镜像源是否配置正确或在run_dpsk_ocr2_image.py里增加timeout300权限错误PermissionError: [Errno 13] Permission denied: /opt/deepseek-ocr2/output给output目录加权限sudo chown -R ubuntu:ubuntu /opt/deepseek-ocr2/output4.3 日志轮转配置避免日志撑爆磁盘配置logrotate。创建/etc/logrotate.d/deepseek-ocr2/var/log/deepseek-ocr2/*.log { daily missingok rotate 30 compress delaycompress notifempty create 644 ubuntu ubuntu sharedscripts postrotate systemctl kill --signalSIGHUP --kill-whomain deepseek-ocr2.service /dev/null 21 || true endscript }这个配置每天轮转保留30天压缩旧日志并在轮转后通知服务重新打开日志文件。5. 自动化运维脚本实战5.1 一键健康检查脚本把前面所有检查打包成一个脚本运维同学只需运行一次就能掌握全局状态#!/bin/bash # 文件名/usr/local/bin/ocr2-healthcheck.sh echo DeepSeek-OCR-2健康检查报告 $(date) echo echo 1. 服务状态 sudo systemctl is-active deepseek-ocr2.service echo echo 2. 进程详情 ps aux | grep -i deepseek.*ocr | grep -v grep | head -n 3 echo echo 3. GPU状态 nvidia-smi --query-gpuname,temperature.gpu,utilization.gpu,utilization.memory --formatcsv,noheader,nounits 2/dev/null || echo NVIDIA驱动未就绪 echo echo 4. 最近错误日志 journalctl -u deepseek-ocr2.service --since 30 minutes ago | grep -E (ERROR|WARNING|Traceback) | tail -n 5 || echo 无近期错误 echo echo 5. 磁盘空间/opt df -h /opt | awk NR2 {print $4} echo echo 6. 内存使用 free -h | awk NR2 {print 可用 $7 / 总计 $2}赋予执行权限sudo chmod x /usr/local/bin/ocr2-healthcheck.sh以后只需ocr2-healthcheck.sh3秒内出报告。5.2 智能自动重启脚本有些故障无法预测比如GPU驱动偶尔崩溃。我们写个守护脚本当检测到服务不可用时自动恢复#!/bin/bash # 文件名/usr/local/bin/ocr2-guardian.sh SERVICE_NAMEdeepseek-ocr2.service CHECK_URLhttp://localhost:8000/health # 假设你加了健康检查端点 # 检查服务是否响应 if curl -s --head --fail $CHECK_URL /dev/null; then echo $(date): 服务正常 exit 0 fi echo $(date): 服务无响应尝试重启... sudo systemctl restart $SERVICE_NAME sleep 5 # 二次确认 if curl -s --head --fail $CHECK_URL /dev/null; then echo $(date): 重启成功 # 发送企业微信通知示例需替换webhook # curl -X POST https://qyapi.weixin.qq.com/cgi-bin/webhook/send?keyxxx \ # -H Content-Type: application/json \ # -d {msgtype: text, text: {content: DeepSeek-OCR2服务已自动恢复}} else echo $(date): 重启失败尝试强制重启 sudo systemctl kill --signalSIGQUIT $SERVICE_NAME sleep 2 sudo systemctl start $SERVICE_NAME fi加入crontab每分钟检查* * * * * /usr/local/bin/ocr2-guardian.sh /var/log/ocr2-guardian.log 21这个脚本比单纯Restartalways更智能因为它基于业务层面的健康检查HTTP响应而不是进程是否存在。6. 生产环境优化建议6.1 systemd高级配置上面的基础service文件够用但在高负载场景需要增强。修改/etc/systemd/system/deepseek-ocr2.service在[Service]段添加# 限制资源防止单个服务拖垮整台机器 MemoryLimit12G CPUQuota80% DeviceAllow/dev/nvidia* rw # 设置OOM分数优先杀死此进程而非系统进程 OOMScoreAdjust-500 # 日志优化 StandardOutputjournal StandardErrorjournal SyslogIdentifierdeepseek-ocr2 # 限制日志大小 RuntimeMaxUse500M然后重载配置sudo systemctl daemon-reload sudo systemctl restart deepseek-ocr2.service6.2 GPU多实例支持MIG如果你用的是A100/A30等支持MIG的GPU可以把一块GPU虚拟成多个小GPU让DeepSeek-OCR-2和其他服务共享# 启用MIG需root sudo nvidia-smi -i 0 -mig 1 # 创建两个实例各占一半显存 sudo nvidia-smi mig -i 0 -cgi 1g.5gb,1g.5gb # 查看实例 nvidia-smi -L # 启动服务时指定实例ID CUDA_VISIBLE_DEVICESMIG-GPU-xxxxx python run_dpsk_ocr2.py这样即使OCR服务显存爆满也不会影响同一块GPU上的其他AI服务。6.3 容器化部署备选方案虽然本文聚焦原生部署但如果你用Docker这里有个精简的Dockerfile要点FROM nvidia/cuda:11.8.0-devel-ubuntu22.04 # 安装必要依赖 RUN apt-get update apt-get install -y python3-pip python3-dev rm -rf /var/lib/apt/lists/* # 复制模型和代码 COPY ./DeepSeek-OCR2-master /app/ WORKDIR /app # 安装要求 RUN pip3 install torch2.6.0 torchvision0.21.0 --index-url https://download.pytorch.org/whl/cu118 RUN pip3 install vllm-0.8.5cu118-cp38-abi3-manylinux1_x86_64.whl RUN pip3 install -r requirements.txt # 启动命令 CMD [python3, DeepSeek-OCR2-vllm/run_dpsk_ocr2_image.py, --port, 8000]构建后用docker run --gpus all -p 8000:8000 ocr2-image启动再配合docker-compose做健康检查比原生部署更易迁移。获取更多AI镜像想探索更多AI镜像和应用场景访问 CSDN星图镜像广场提供丰富的预置镜像覆盖大模型推理、图像生成、视频生成、模型微调等多个领域支持一键部署。
