最近帮团队做了一轮 AI 模型部署的自动化脚本开发，起因很简单：环境越来越多，手动拷贝命令部署模型的次数已经多到让人崩溃。从最开始只在本地电脑跑一个 Ollama，到后来要在几台服务器上部署同一套推理服务，再把 Web 端和 App 端都能用上，这中间踩了一遍遍重复的坑。后来我索性把整个过程脚本化、自动化，把“部署模型”从一门手艺变成了一条可重复执行的流水线。这篇文章就把这套思路和落地细节整理出来，希望能帮你少走点弯路。

这篇内容主要面向正在做模型部署、或者刚接触 AI 应用落地的开发者，也适合设备端、边缘端折腾部署的人参考。不管你是用 Ollama、Docker 还是 ONNX Runtime，脚本化的内核都是相通的：把环境准备、模型下载、服务启动、健康检查、升级回滚这些事，变成一段段可以复现、可以审计的命令。读完你可以直接照着抄，也可以按自己的场景改造。

1. 先把需求看清楚：自动化脚本到底要替我们干什么

1.1 手动部署模型的真实痛点

我最早部署模型的时候，流程是这样的：先手动装驱动，再看显卡驱动版本能不能对上 CUDA，然后把模型文件下载下来，放到指定目录，再写一个 Python 脚本调用模型，最后开着终端跑起来。听起来不难，但一旦机器数量上来，或者模型更新了几次版本，问题就全都冒出来了。

这里列几个我踩过最典型的坑：

• 依赖环境的“漂移”：同一套代码在开发机上跑得好好的，换一台机器就报缺少某个库，或者 CUDA 版本不对接不上。
• 模型文件管理的混乱：模型下载链接失效、下载一半中断、磁盘空间不够，没有人知道当前目录下哪个模型文件才是真正在用的。
• 服务启动方式的差异：有时候用命令行前台跑，有时候用 systemd 托管，有时候用 Docker 启动，换个人部署就换一种方式。
• 验证缺失：部署完没人确认服务是否真的正常响应，直到前端调用报错才发现模型根本没加载成功。

这些痛点的本质是“部署过程依赖人的记忆和临时判断”。自动化脚本的核心价值，就是把部署过程从“操作”变成“状态管理”——检测当前状态、补齐缺失部分、启动服务并验证结果。

1.2 自动化脚本的能力边界

做自动化之前，先得想清楚哪些事情适合脚本做，哪些事情不该硬塞进脚本里。我这套方案里，脚本负责四类事情：

• 环境检测与依赖安装：检测 GPU 驱动、Python 版本、Docker 是否安装，缺什么补什么。
• 模型与服务的标准化启动：统一用一套命令、一套参数拉起模型服务，避免不同机器的行为差异。
• 健康检查与状态上报：启动后自动调用接口验证模型是否可用，并把结果写入日志。
• 升级与回滚：保留上一版本的模型配置，新版本失败时能快速切回去。

不能交给脚本做的是：模型本身的调优、业务逻辑的改动，以及涉及数据安全的敏感操作。脚本只保证“流程可靠”，不负责“结果正确”。

1.3 什么场景最适合用这套方案

根据我自己的经验，下面几类场景收益最大：

• 本地开发环境：Mac、Windows 11 上用 Ollama 部署本地模型，一键安装、自动拉模型、开机自启。
• 服务器推理服务：用 Docker 部署自建的推理接口，多台机器批量初始化。
• 边缘设备部署：树莓派、Jetson 这类设备上部署 YOLOv5 等模型，脚本里封装交叉编译和依赖安装。
• 自动化测试配套：部署完成后，自动跑一轮 Web 端和 App 端的冒烟测试，确认模型服务真的可用。

2. 方案设计：为什么我选择 Shell + Python + Docker 的组合

2.1 工具选型背后的逻辑

市面上的部署工具不少，有容器化平台、有模型服务框架，也有像 Ollama 这样极简的本地推理工具。我在设计自动化脚本时，没有执着于“全家桶”，而是选了一套最顺手、也最容易替换的组合：Shell 做环境层，Python 做逻辑层，Docker 做隔离层，Ollama/ONNX Runtime/TorchServe 做推理层。

选择 Shell 的原因很简单：环境检测、安装依赖、启动服务、设置 systemd，这些操作在 Shell 里最直接。Python 则负责更复杂的逻辑判断，比如读取配置文件、解析模型列表、做 HTTP 健康检查。Docker 的加入是为了解决“环境漂移”问题——把 CUDA、Python 依赖、系统库全部锁进镜像里。

你看，这里其实不需要区分谁更高级，而是让每层工具干自己最擅长的事。这和写业务代码一样，没有银弹，适合的就是最好的。

2.2 轻量本地场景：Ollama + 模型量化

如果你是个人开发，想在 Mac 或者 Windows 11 上快速跑本地模型，我强烈建议优先用 Ollama。它的好处是，一条命令就能装好，另一条命令就能拉取模型，而且内置了模型量化格式，部署起来非常省心。

在脚本里，我会先检测本机是否安装了 Ollama，没有就自动安装；然后读取一个 models.conf 文件，里面写明要拉取的模型名称和版本，比如 llama3.2:3b 、 qwen2.5:7b 。脚本逐条执行 ollama pull ，然后调用 /api/tags 接口确认模型真的存在，最后再向 /api/generate 发一个测试请求，验证模型能正常生成内容。

这套流程用手动做大概要敲十几条命令，但用脚本做就是一次点击、一个日志文件、一个可预期的结果。

2.3 生产服务场景：Docker + ONNX Runtime

到了生产环境，或者模型要同时服务多个业务方的时候，我建议把推理服务容器化。一个典型的组合是：FastAPI + ONNX Runtime，用 Docker 打包成镜像。

脚本在这个场景中的职责是：

• 检查 Docker 是否运行、GPU 是否可用。
• 拉取指定版本的镜像。
• 用 docker run 启动容器，传入必要的环境变量、端口映射和模型路径。
• 启动后用 curl 调用 /health 和 /v1/models 接口做健康检查。
• 如果健康检查连续失败，自动回滚到上一个容器镜像。

这里有一个关键点：脚本一定要把镜像版本和模型文件版本作为参数传入，而不是在脚本里硬编码。只有这样，才能在模型升级时只改配置不改代码。

2.4 部署到边缘设备的时候要额外考虑什么

在树莓派、飞牛、STM32 这类设备上部署 YOLOv5 或者其他模型，环境比服务器复杂得多。脚本里我一定会做几件事：

• 检测 CPU 架构，不同架构要装不同的 Python wheel 包。
• 设置内存和 swap 限制，防止设备部署过程中直接卡死。
• 先跑一段小模型的推理测试，确认设备能扛得住，再部署正式模型。

比如树莓派 5 上部署自己训练的 YOLOv5，脚本会先检查是否装了 onnxruntime ，再检查模型文件是否存在，然后用一张测试图片跑一次推理，把识别结果和耗时写入日志。如果耗时超过阈值，就提示用户考虑量化模型或者换更小的模型结构。

3. 核心代码实现：从零搭一套模型部署自动化脚本

3.1 脚本目录结构与配置设计

先给大家看一下我常用的项目结构。这个结构看起来很朴素，但胜在清晰，后期扩展也方便。

ai-deploy/
├── deploy.sh                # 入口脚本
├── common/
│   ├── env_check.sh         # 环境检测
│   ├── utils.sh             # 通用函数（日志、重试、回滚）
├── models.conf              # 模型配置清单
├── services/
│   ├── ollama.service       # systemd 服务模板
│   └── fastapi.service      # FastAPI 服务模板
├── python/
│   ├── health_check.py      # 健康检查脚本
│   └── model_validate.py    # 模型验证脚本
└── docker/
    ├── Dockerfile           # 推理服务镜像
    └── docker-compose.yml   # 容器编排

models.conf 是核心配置文件，内容大概是这样的：

# 本地 Ollama 模型配置
[ollama]
models = llama3.2:3b, qwen2.5:7b
host = 127.0.0.1
port = 11434
auto_pull = true

# Docker 推理服务配置
[docker_service]
image = registry.example.com/ai-inference:1.4.0
container_name = ai-inference
gpu = all
health_url = http://127.0.0.1:8000/health
model_path = /models/yolov5s.onnx

为什么要用配置文件而不是直接在脚本里写死？因为模型部署本身就是一个“多版本、多环境”的问题。配置文件让脚本变成了一个通用的执行器：换模型、换机器，只需要改配置，不需要改逻辑。

3.2 环境检测脚本：部署前先摸清家底

部署流程的第一步，永远是环境检测。我不会让脚本直接开始安装东西，而是先收集当前机器的状态，然后判断哪些步骤可以跳过。

下面这段 env_check.sh 是我常用的检测逻辑：

#!/bin/bash

log() {
    echo "[$(date '+%Y-%m-%d %H:%M:%S')] $*" | tee -a deploy.log
}

check_command() {
    if command -v "$1" >/dev/null 2>&1; then
        log "OK: $1 已安装"
        return 0
    else
        log "WARN: $1 未安装"
        return 1
    fi
}

check_gpu() {
    if command -v nvidia-smi >/dev/null 2>&1; then
        nvidia-smi --query-gpu=name,memory.total --format=csv,noheader
    else
        log "WARN: 未检测到 NVIDIA GPU，将使用 CPU 推理"
    fi
}

check_disk() {
    # 检查 /var/lib/docker 和当前目录所在磁盘的剩余空间
    for dir in "/var/lib/docker" "$(pwd)"; do
        available=$(df -BG "$dir" | awk 'NR==2 {print $4}' | tr -d 'G')
        log "磁盘检查: $dir 剩余 ${available}G"
        if [ "$available" -lt 10 ]; then
            log "ERROR: 磁盘空间不足，至少需要 10G"
            exit 1
        fi
    done
}

在实际使用中，我还会检查内核参数、防火墙状态、端口是否被占用。这些检查越前置，后面出现诡异问题的概率越低。我遇到过一台服务器部署完才发现 8000 端口被别的服务占着，健康检查反复失败，最后排查了半天。早该在启动前查一下端口占用。

3.3 一键部署 Ollama 本地模型的完整脚本

如果你只想在本地快速部署一个 AI 模型，下面这段脚本可以直接拿去用。它做了几件事：安装 Ollama、拉取模型、启动服务、验证生成接口。

#!/bin/bash
# deploy_ollama.sh
set -euo pipefail

MODEL_LIST="${1:-llama3.2:3b}"
OLLAMA_PORT="${OLLAMA_PORT:-11434}"

log() { echo "[$(date '+%F %T')] $*"; }

# 1. 检测 Ollama 是否已安装
if ! command -v ollama &>/dev/null; then
    log "未检测到 Ollama，开始安装..."
    curl -fsSL https://ollama.com/install.sh | sh
fi

# 2. 启动 Ollama 服务
if ! curl -s "http://127.0.0.1:${OLLAMA_PORT}/api/tags" >/dev/null; then
    log "启动 Ollama 服务..."
    nohup ollama serve >/tmp/ollama.log 2>&1 &
    for i in $(seq 1 15); do
        if curl -s "http://127.0.0.1:${OLLAMA_PORT}/api/tags" >/dev/null; then
            break
        fi
        sleep 2
    done
fi

# 3. 拉取模型
IFS=',' read -ra MODELS <<< "$MODEL_LIST"
for model in "${MODELS[@]}"; do
    model=$(echo "$model" | xargs)   # 去空格
    log "拉取模型: $model"
    ollama pull "$model"
done

# 4. 模型存在性验证
log "验证模型是否就绪..."
curl -s "http://127.0.0.1:${OLLAMA_PORT}/api/tags" | python3 -m json.tool

# 5. 一次真实推理测试
log "发起测试推理请求..."
curl -s "http://127.0.0.1:${OLLAMA_PORT}/api/generate" \
    -H "Content-Type: application/json" \
    -d "{\"model\": \"${MODELS[0]}\", \"prompt\": \"用一句话介绍你自己\", \"stream\": false}" \
    | python3 -c "import sys, json; print('推理结果:', json.load(sys.stdin).get('response', ''))"

log "Ollama 模型部署完成"

这段脚本看起来简单，但我实际跑下来有几个细节非常值得注意：

• set -euo pipefail 必须加上，否则某一步失败脚本还会继续往下跑，最后抛出一个莫名其妙的错误。
• Ollama 服务启动需要等待，不能立刻去调接口。用循环等待的方式，最多等 30 秒，比 sleep 30 更稳。
• 拉模型之前用逗号分隔的方式支持一次拉多个模型，这个在批量初始化机器时特别有用。

3.4 用 Docker 部署自建推理服务并做健康检查

本地跑模型只是第一步，真正上线给业务调用时，我更习惯用 Docker 打包推理服务。下面是我在项目里常用的一段部署脚本。

#!/bin/bash
# deploy_docker_service.sh
set -euo pipefail

IMAGE_NAME="${IMAGE_NAME:-registry.example.com/ai-inference:1.4.0}"
CONTAINER_NAME="${CONTAINER_NAME:-ai-inference}"
PORT_MAP="${PORT_MAP:-8000:8000}"
GPU_ENABLE="${GPU_ENABLE:-true}"

# 1. 拉取最新镜像
docker pull "$IMAGE_NAME"

# 2. 停止并删除旧容器
docker rm -f "$CONTAINER_NAME" 2>/dev/null || true

# 3. 根据 GPU 参数组装 docker run 命令
DOCKER_RUN_ARGS=(
    --name "$CONTAINER_NAME"
    -p "$PORT_MAP"
    --restart unless-stopped
    -e "MODEL_PATH=/models/model.onnx"
    -v /data/models:/models:ro
)

if [ "$GPU_ENABLE" = "true" ]; then
    DOCKER_RUN_ARGS+=(--gpus all)
fi

# 4. 启动新容器
docker run -d "${DOCKER_RUN_ARGS[@]}" "$IMAGE_NAME"

# 5. 健康检查
HEALTH_URL="${HEALTH_URL:-http://127.0.0.1:8000/health}"
for i in $(seq 1 30); do
    if curl -sf "$HEALTH_URL" >/dev/null; then
        echo "健康检查通过"
        exit 0
    fi
    echo "等待服务启动... (${i}/30)"
    sleep 2
done

echo "健康检查失败，开始回滚..."
docker rm -f "$CONTAINER_NAME"
docker run -d --name "$CONTAINER_NAME" -p "$PORT_MAP" "$PREVIOUS_IMAGE"
exit 1

这里有一个我没有写进脚本、但特别想强调的设计：回滚逻辑。生产环境部署失败并不可怕，可怕的是失败之后服务彻底不可用。所以在启动新容器之前，我会先记录当前正在运行的镜像版本，存到 /var/lib/ai-deploy/previous_image 文件中。一旦新容器健康检查不通过，脚本能自动把旧镜像拉起来。

Docker 命令的组装方式也有讲究。我一开始把参数直接写在一行 docker run 里，后来发现 GPU 和 CPU 环境差异太大，就改成了数组形式，根据不同条件追加参数。这样脚本的复用性高了很多。

3.5 Web 端和 App 端的部署后自动化验证

光把模型服务部署起来还不够，真实项目里还要确认 Web 端和 App 端能正常调用模型。我把这部分做成了部署后的冒烟测试，核心思路是：模拟真实用户请求，验证整条链路是通的。

对于 Web 端，我用的是 Playwright 写自动化脚本，调用页面上的 AI 对话框，输入测试文本，等待响应返回，然后断言结果里包含预期关键词。

# smoke_test_web.py
from playwright.sync_api import sync_playwright
import sys

base_url = sys.argv[1] if len(sys.argv) > 1 else "http://localhost:3000"

with sync_playwright() as p:
    browser = p.chromium.launch(headless=True)
    page = browser.new_page()
    page.goto(base_url)
    page.fill("#chat-input", "你好，请介绍一下你自己")
    page.click("#send-btn")
    page.wait_for_selector(".response-text", timeout=30000)
    response = page.inner_text(".response-text")
    assert len(response) > 0, "模型响应为空"
    print(f"Web端冒烟测试通过，响应内容: {response[:50]}...")
    browser.close()

对于 App 端，我用 Appium 驱动 Android 模拟器，启动应用后找到聊天输入框，输入文本并发送，再断言界面上出现回复。Appium 的配置比 Playwright 多一点，但思路完全一样。

这里我特别想提醒大家：部署后的验证脚本，很可能比部署脚本本身更重要。因为模型服务有没有“起来”和有没有“能用”是两回事。健康检查只能说明进程活着，冒烟测试才能证明业务链路没问题。

3.6 把脚本交给 systemd：让部署变成开机自启的服务

本地手动跑脚本没问题，但服务器重启之后怎么办？如果每个环境都要人登录上去手动执行一次，自动化就没有意义了。我的方案是把整个部署流程封装成一个 systemd 服务。

下面是一个服务模板的例子，贴出来给大家参考：

[Unit]
Description=AI Model Deployment Service
After=docker.service
Requires=docker.service

[Service]
Type=oneshot
RemainAfterExit=yes
WorkingDirectory=/opt/ai-deploy
ExecStart=/usr/bin/bash /opt/ai-deploy/deploy.sh
ExecStop=/usr/bin/docker rm -f ai-inference
User=deploy
StandardOutput=journal
StandardError=journal

[Install]
WantedBy=multi-user.target

设置开机启动的命令：

sudo cp services/ai-deploy.service /etc/systemd/system/
sudo systemctl daemon-reload
sudo systemctl enable ai-deploy.service
sudo systemctl start ai-deploy.service

Type=oneshot 配合 RemainAfterExit=yes 的意思是：脚本执行完就认为任务完成，但服务状态保持 active，方便用 systemctl status 查看。日志统一交给 journald 管理，排查问题时一行 journalctl -u ai-deploy.service -f 就能实时跟踪部署日志，比到处找 log 文件省事多了。

4. 从一次部署到持续稳定：脚本工程的进阶实践

4.1 幂等性设计：脚本可以跑一万次都不出错

自动化脚本最忌讳的事情，就是跑第二次的时候爆炸。比如第一次已经安装了 Ollama，第二次执行又去安装一遍，结果冲突。所以我给脚本加了一个设计原则：每一步操作前先判断当前状态，只有状态不符合预期时才执行动作。

具体到代码里就是：

• 安装前先检测是否已安装。
• 拉模型前先检查模型是否已存在。
• 创建容器前先删除同名容器。
• 写配置文件前先备份原文件。

这就是“幂等性”。简单说，不管脚本被调用多少次，最终状态都是一致的。我甚至会给同一个环境连续执行两次部署脚本，验证第二次执行应该直接跳过所有步骤、快速返回。如果第二次不是秒结束，说明幂等性没做好。

4.2 配置管理：把环境差异从代码里剥离出来

不同环境的差异，比如开发机的端口、生产环境的 GPU 数量、边缘设备的模型路径，这些都不应该写死在脚本里。我一般用一个 .env 文件来管理，脚本启动时先加载。

#!/bin/bash
# 读取 .env 配置
if [ -f .env ]; then
    set -a
    source .env
    set +a
fi

.env 文件长这样：

# 环境: dev | prod | edge
ENV=dev
OLLAMA_PORT=11434
MODEL_LIST=llama3.2:3b,qwen2.5:7b
DOCKER_IMAGE=registry.example.com/ai-inference:1.4.0
ENABLE_GPU=true

这样做的最大好处是，换一套环境只需要换一个文件。我在实际项目里还配合 Git 分支管理 .env.${ENV} 文件，部署时指定环境名，脚本自动加载对应配置。整个部署过程就变成了一条命令：

./deploy.sh --env prod

4.3 日志与审计：出了问题能知道发生了什么

自动化的另一大价值是“可审计”。手动部署的时候，出了问题只能靠回忆，脚本化之后每一步都有日志记录，这就是排错的底气。

我常用的日志策略是三个层次：

• 控制台实时输出：人盯着屏幕能看到进度。
• 文件持久化： deploy.log 保留最近 30 次部署记录。
• 结构化字段：每行日志带上时间、动作、目标、结果，方便用 grep 过滤。

比如这样一条日志：

[2025-02-18 14:32:10] [ACTION] [ollama_pull] [llama3.2:3b] [START]
[2025-02-18 14:32:48] [ACTION] [ollama_pull] [llama3.2:3b] [SUCCESS]

一旦部署有问题，我只需要用 grep '\[ERROR\]' deploy.log 就能定位到失败步骤，再结合前后日志判断原因，效率比手动排查高很多。

4.4 接入 CI/CD：模型部署也能一键发布

如果你团队里有 GitLab 或者 GitHub Actions，我强烈建议把部署脚本接入 CI/CD。我的做法是：模型文件更新后，打一个 tag 推送到仓库，CI 自动触发构建镜像、执行部署脚本、运行冒烟测试，测试通过后打上 deployed 标签。

这样整个流程的入口就从“人登录服务器执行命令”变成了“推送代码”。人是容易犯错的，但流程不会。自动化测试脚本如果是部署流程的一部分，那它的价值就不仅仅是省力，而是保证了每次发布的质量都是一致的。

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

5.1 问题速查表

下面这个表格是实际操作中我遇到最多的问题和解决方案，建议收藏。

现象	可能原因	排查思路
Ollama 服务启动但请求超时	端口被占用 / 模型过大加载慢	检查端口占用，看 /tmp/ollama.log 日志
GPU 显存不足导致推理失败	模型量化级别太高或并发过大	换成更低量化模型，或限制并发请求数
Docker 容器启动后立即退出	镜像内缺少模型文件 / 启动命令错误	docker logs <container> 查看退出原因
模型拉取到一半中断	网络不稳定 / 磁盘空间不足	重新执行 ollama pull ，它支持断点续传
健康检查接口返回 503	服务还没加载完模型 / 依赖服务未启动	增加等待时间，检查服务日志
ONNX Runtime 报“CPU 无法支持某个算子”	模型算子版本与 ONNX Runtime 版本不匹配	升级 onnxruntime 或导出模型时兼容较低 opset
脚本第二次执行报错	幂等性没做对	检查是否重复创建容器/重复写配置，先清状态再执行
App 端自动化测试找不到元素	元素定位失效 / 应用启动太慢	增加等待策略，或用 Appium Inspector 查看真实控件树

5.2 一条让我排查了一晚上的错误

有一次部署一个 YOLOv5 模型，脚本一直报错，健康检查始终通过不了。我反复检查容器状态，模型文件也在，端口映射也对，但接口就是 503。最后我进容器里面执行测试命令，才发现问题出在模型路径上。

我用的是相对路径 /models/model.onnx ，但实际进入容器后，工作目录根本不是根目录，导致 ONNX Runtime 加载模型时找不到文件。后来我在部署脚本里加了一行检查，在启动容器前先确认模型文件在挂载目录里真实存在。这个教训告诉我：容器内的路径和容器外的路径是两套体系，脚本里一定要做路径存在性验证，绝不能假设。

5.3 关于模型量化格式选择的经验

现在部署模型绕不开量化格式，尤其是 GGUF、ONNX、TensorRT 这些词经常出现。我在脚本里会做一个可配置的模型格式参数，不同环境选择不同格式。

• 本地 Mac / Windows 开发：优先选 GGUF 量化模型，部署简单、资源占用低。
• 服务器 NVIDIA GPU 推理：优先 ONNX Runtime 配合 CUDA，性能好、生态成熟。
• 边缘设备：优先 INT8 量化后的 ONNX 模型，体积小、内存占用低。

可以在 models.conf 里加一个字段表示模型格式，脚本根据格式决定调用 Ollama、ONNX Runtime 还是 TensorRT 的启动命令。这种设计的好处是，模型格式的切换对上层调用方完全透明，服务接口保持一致，只是底层引擎不同。

5.4 自动化脚本本身的测试

最后提醒一个问题：自动化脚本也是会出 bug 的。我见过很多团队，把部署脚本写完就再也不管，等到真正部署的时候才发现脚本本身早就坏了。

我的建议是至少准备一个“干跑模式”（dry-run）。脚本先遍历所有步骤，只输出将要执行的操作，不真正执行。这样每次改动脚本后，都可以用干跑模式快速验证逻辑没有明显错误。

再进一步，可以准备一个最小的测试模型，比如几十 MB 的那种，在 CI 里跑一遍完整的部署流程。不求性能多好，只求流程通畅。

6. 个人实操总结与体会

做了这么多模型部署自动化的工作，我最大的体会是：自动化脚本真正的价值不是“快”，而是“稳定”和“可复现”。手动部署一百次，可能有一百种不同的结果；脚本部署一万次，结果是完全一致的。这种确定性，在团队协作和生产环境里太重要了。

我个人建议，如果你刚开始做这件事，不要一上来就追求大而全的平台化方案。先从最痛的场景入手，比如本机部署 Ollama 模型这一件事，用脚本把它做好。跑顺了之后，再扩展 Docker、再加健康检查、再接入 CI/CD。一步步来，每一步都能看到实际收益。

最后再分享一个小技巧：部署脚本写完以后，一定记得写一个配套的“查看部署状态”脚本。很多时候我们不着手部署，但需要快速知道当前环境发生了什么——服务是否在跑、模型是哪个版本、日志最后几行是什么。一个简单的 status.sh 能让你在任何时间都对环境心里有数。我自己就在 status.sh 里封装了检查 Ollama 进程、检查 Docker 容器、输出最近 10 条部署日志，一条命令搞定，非常方便。希望这套思路能帮到正在折腾模型部署的你。