企业官网建设流程全解析

1. 从一台裸机到可用的模型服务：这次部署到底在解决什么问题

很多人第一次接触大模型本地化部署，脑子里想的都是"把模型跑起来就行"。但真正落到生产环境，你会发现"跑起来"和"能用"之间隔着一条很宽的沟。这次要聊的，是在一台云服务器上把 Deepseek 系列模型通过 Harness 这套推理服务框架完整部署起来，并且让它具备公网可访问、带鉴权的能力。说白了，就是让一个部署在远端机房里的模型服务，能够被你在任何地方、用任何客户端安全地调用，而不是只能蹲在服务器终端里自娱自乐。

先把这个标题拆开看。云服务器意味着你没有本地显卡，算力是租来的，网络是公网的，安全边界是模糊的。Deepseek是当前开源模型里综合表现相当能打的一支，尤其是它的 MoE 架构在推理效率和效果之间取得了不错的平衡。Harness在这里指的是一套把模型加载、请求调度、接口暴露串起来的推理服务框架，它的价值在于把底层复杂的张量并行、显存管理、批处理调度这些脏活累活封装掉，让你通过一个配置文件就能把服务拉起来。公网鉴权访问则是整个部署里最容易被忽视、但出事概率最高的环节——服务一旦暴露在公网而没有鉴权，轻则被人白嫖算力，重则成为别人跑恶意任务的跳板。

这篇文章适合谁看？如果你手里有一台带 GPU 的云服务器，想部署一个自己的模型服务给团队内部或者小范围外部使用，同时对 Linux 操作、Docker、反向代理这些概念有基本认知，那这篇内容基本可以照着走。如果你是完全的新手，也没关系，我会把每一步背后的"为什么"讲清楚，让你不只是抄命令，而是理解每个环节在防什么、解决什么。

我自己的经历是，第一次部署的时候觉得"不就是拉个镜像跑起来吗"，结果在显存分配、端口暴露、鉴权配置上连续踩了三个坑，前后折腾了一整天才跑通。所以这篇内容会重点讲那些文档里不会写、但实际部署中一定会遇到的问题。

2. 部署前的环境盘点：云服务器选型与依赖确认

2.1 云服务器配置的取舍逻辑

部署大模型服务，第一道坎就是选机器。云服务器厂商的 GPU 实例五花八门，价格差异巨大，选错了要么跑不起来，要么花冤枉钱。这里给一个基本的判断框架。

首先要明确你要部署的 Deepseek 模型规模。Deepseek 系列有多个参数量版本，从几 B 到几百 B 不等。模型参数量和显存需求之间有一个粗略的换算关系：FP16 精度下，每 10 亿参数大约需要 2GB 显存。也就是说，一个 7B 的模型，光加载权重就需要约 14GB 显存，再加上推理过程中的 KV Cache、中间激活值，实际占用会更高，通常要预留 1.5 到 2 倍的余量。

如果你预算有限，可以考虑量化版本。INT8 量化能把显存需求砍掉将近一半，INT4 则能压到四分之一左右，代价是精度有轻微损失。对于大多数对话类应用，INT8 量化的效果损失几乎感知不到，是很划算的选择。

除了显存，还要关注几个容易被忽略的点。CPU 核心数影响的是数据预处理和请求调度的效率，建议至少 8 核。内存建议不低于显存的 1.5 倍，因为模型加载时会有临时的内存占用峰值。磁盘方面，模型文件动辄几十 GB，系统盘肯定不够，要单独挂一块数据盘，建议 SSD，容量至少是模型文件大小的 3 倍，留出日志和缓存的余地。网络带宽决定了模型下载速度和推理请求的响应延迟，公网带宽建议不低于 10Mbps，如果调用量大还要考虑按流量计费的成本。

2.2 系统环境与基础依赖

操作系统我建议用 Ubuntu 22.04 LTS，原因是它的内核版本对 NVIDIA 驱动的兼容性最好，社区资料也最全。如果你用的是其他发行版，大部分步骤是通用的，但驱动安装部分可能需要调整。

登录服务器后，第一件事是更新系统并安装基础工具：

sudo apt update && sudo apt upgrade -y sudo apt install -y build-essential git curl wget vim htop nvtop

这里nvtop是专门用来看 GPU 占用的工具，比nvidia-smi的实时刷新体验好很多，强烈建议装上。

接下来确认 GPU 是否被正确识别：

lspci | grep -i nvidia

如果这条命令没有任何输出，说明云服务器可能没有正确挂载 GPU，需要去控制台检查实例配置。正常情况下你应该能看到 NVIDIA 的显卡型号信息。

然后是驱动。很多云厂商的 GPU 镜像已经预装了驱动，先用nvidia-smi确认一下。如果能看到显卡信息和驱动版本，就跳过安装步骤。如果没有，需要手动安装：

sudo apt install -y nvidia-driver-535 sudo reboot

驱动版本的选择有个经验：不要盲目追新。新驱动有时候会和 CUDA 版本、推理框架产生兼容性问题。选一个比框架官方推荐版本略高一点的稳定版就行。重启后再次运行nvidia-smi，确认驱动正常工作。

2.3 容器运行时与 GPU 支持

我强烈建议用 Docker 来部署，而不是直接在宿主机上装环境。原因很简单：模型推理框架的依赖极其复杂，Python 版本、CUDA 版本、各种底层库之间经常打架，一旦污染了宿主机环境，后面排查问题会让你怀疑人生。容器化之后，环境是隔离的，出问题直接删掉重建，干净利落。

安装 Docker 和 NVIDIA Container Toolkit：

curl -fsSL https://get.docker.com | sh sudo apt install -y nvidia-container-toolkit sudo nvidia-ctk runtime configure --runtime=docker sudo systemctl restart docker

验证 GPU 在容器内是否可用：

docker run --rm --gpus all nvidia/cuda:12.1.0-base-ubuntu22.04 nvidia-smi

如果这条命令能正常输出显卡信息，说明容器 GPU 支持已经打通。这一步非常关键，很多后续问题都源于这里没配置好。我遇到过的情况是，宿主机nvidia-smi正常，但容器里就是识别不到 GPU，最后发现是nvidia-container-toolkit装完后没有重启 Docker 服务。

注意：云服务器的 GPU 驱动版本和 CUDA 版本要匹配。CUDA 12.1 需要驱动版本不低于 530，CUDA 11.8 需要不低于 520。版本不匹配会直接导致容器启动失败。

3. Harness 推理服务的部署与模型加载

3.1 为什么选 Harness 而不是裸跑推理脚本

在讲具体部署之前，先说说为什么用 Harness 这类推理服务框架，而不是自己写个 Python 脚本调 transformers 库跑推理。

自己写脚本的问题在于，你很快就会发现需要处理一堆和生产相关的事情：并发请求怎么调度、多个请求怎么批处理、显存不够时怎么排队、服务挂了怎么自动重启、日志怎么收集。这些事情每一件单独看都不难，但加在一起就是一个完整的服务框架的工作量。Harness 这类框架的价值就在于，它把这些通用能力都封装好了，你只需要关心模型配置和业务逻辑。

另一个考虑是性能。Harness 通常内置了连续批处理（continuous batching）和 PagedAttention 这类优化技术，能把 GPU 利用率拉高好几倍。同样的硬件，用框架跑和裸跑，吞吐量可能差三到五倍。对于按小时计费的云服务器来说，这个差距直接体现在成本上。

3.2 拉取镜像与目录规划

先规划好目录结构，避免文件散落各处：

sudo mkdir -p /data/harness/{models,configs,logs,cache} sudo chown -R $USER:$USER /data/harness

models放模型权重，configs放服务配置文件，logs放运行日志，cache放推理过程中的临时缓存。分开管理的好处是备份和迁移时目标明确，不会把几十 GB 的模型和几 KB 的配置混在一起。

拉取 Harness 的官方镜像。具体镜像名称根据你使用的框架版本而定，这里以通用形式示意：

docker pull harness/inference-server:latest

拉取完成后用docker images确认镜像存在。如果拉取速度慢，可以配置国内镜像加速源，这个在 Docker 官方文档里有详细说明，这里不展开。

3.3 模型权重的获取与校验

模型权重有两种获取方式：从官方仓库下载，或者从已有的存储复制。如果服务器公网带宽充足，直接下载是最简单的：

cd /data/harness/models git lfs install git clone https://your-model-repo/deepseek-model.git

这里要注意，大模型仓库通常用 Git LFS 管理大文件，必须先装git lfs，否则克隆下来的只是一堆指针文件，不是真正的权重。克隆完成后检查文件大小，一个 7B 模型的权重文件应该在 14GB 左右，如果只有几 KB，那肯定是 LFS 没生效。

下载完成后一定要做完整性校验。模型文件在传输过程中损坏是很常见的情况，如果不校验直接加载，可能会遇到莫名其妙的报错，排查起来非常痛苦。通常仓库里会提供一个校验和文件：

sha256sum -c checksums.txt

如果所有文件都显示 OK，说明下载完整。如果有 FAILED，删掉对应文件重新下载。

3.4 配置文件的关键参数解读

Harness 的配置文件决定了服务的行为，这里挑几个最关键的参数讲清楚它们的作用和设置逻辑。

model: path: /data/harness/models/deepseek-model dtype: float16 max_model_len: 8192 gpu_memory_utilization: 0.90 server: host: 0.0.0.0 port: 8000 max_concurrent_requests: 64 scheduler: batch_size: 16 max_batch_tokens: 32768

dtype决定推理精度。float16是默认选择，兼顾精度和显存。如果显存紧张可以改成bfloat16，它在某些显卡上效率更高，但兼容性稍差。max_model_len是模型能处理的最大上下文长度，设得越大占用的显存越多，要根据实际需求来，不要盲目拉满。

gpu_memory_utilization这个参数特别重要，它控制框架能占用多少比例的显存。设成 0.90 意味着留 10% 给系统和其他进程。这个值设得太高（比如 0.98）容易导致 OOM，设得太低又浪费显存。我的经验是 0.85 到 0.92 之间比较稳妥，具体要看你的显卡型号和是否有其他进程共用。

max_concurrent_requests和batch_size共同决定了服务的并发能力。这两个值不是越大越好，超过 GPU 实际处理能力后，请求会排队，延迟反而上升。合理的做法是先设一个保守值，然后用压测工具逐步往上调，找到吞吐量和延迟的平衡点。

3.5 启动服务与首次验证

配置文件准备好后，用 Docker 启动服务：

docker run -d \ --name harness-server \ --gpus all \ --shm-size 16g \ -p 127.0.0.1:8000:8000 \ -v /data/harness/models:/data/harness/models \ -v /data/harness/configs:/data/harness/configs \ -v /data/harness/logs:/data/harness/logs \ harness/inference-server:latest \ --config /data/harness/configs/server.yaml

注意这里的端口映射写的是127.0.0.1:8000:8000，而不是8000:8000。这是一个关键的安全设计：服务只监听本地回环地址，外网无法直接访问。后面我们会通过反向代理来暴露服务并加上鉴权。如果直接写成8000:8000，服务就裸奔在公网上了，非常危险。

--shm-size 16g这个参数也值得说一下。Docker 默认的共享内存只有 64MB，而推理框架在进程间通信时会大量使用共享内存，不调大很容易出现莫名其妙的崩溃。16GB 是个比较安全的经验值。

启动后用docker logs -f harness-server观察日志。正常启动会看到模型加载进度、显存分配情况、服务监听端口等信息。模型加载时间取决于模型大小和磁盘速度，7B 模型大概需要一到三分钟。看到类似Server started on port 8000的日志，说明服务已经就绪。

在服务器本地验证：

curl http://127.0.0.1:8000/v1/models

如果返回模型列表的 JSON，说明服务正常工作。再发一个推理请求测试：

curl http://127.0.0.1:8000/v1/chat/completions \ -H "Content-Type: application/json" \ -d '{ "model": "deepseek-model", "messages": [{"role": "user", "content": "你好"}], "max_tokens": 50 }'

能正常返回生成结果，就说明模型服务本身没问题了。接下来要解决的是如何安全地从公网访问它。

4. 公网访问的安全设计：反向代理与鉴权体系

4.1 为什么不能直接把服务端口暴露到公网

这是整个部署里最需要重视的部分。我见过太多人为了图省事，直接把推理服务的端口映射到0.0.0.0，然后公网 IP 加端口就能访问。这种做法的问题在于，你的服务对全世界开放，任何人扫到你的端口就能白嫖你的 GPU 算力，甚至可能通过构造恶意请求来攻击你的服务。

更严重的是，很多推理框架的默认配置是没有鉴权的，或者只有简单的 API Key，而 API Key 如果通过 HTTP 明文传输，在公网上很容易被截获。一旦被人拿到，你的服务器就成了别人的免费算力池。

正确的做法是：服务只监听本地，通过反向代理暴露，代理层做 TLS 加密和鉴权。这样即使有人扫到了你的域名，没有合法的凭证也无法调用服务。

4.2 Nginx 反向代理的配置要点

在宿主机上安装 Nginx：

sudo apt install -y nginx

然后创建一个站点配置：

server { listen 443 ssl http2; server_name your-domain.com; ssl_certificate /etc/letsencrypt/live/your-domain.com/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/your-domain.com/privkey.pem; ssl_protocols TLSv1.2 TLSv1.3; location /v1/ { auth_basic "Restricted"; auth_basic_user_file /etc/nginx/.htpasswd; proxy_pass http://127.0.0.1:8000; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; proxy_read_timeout 300s; proxy_send_timeout 300s; proxy_buffering off; } }

几个关键点解释一下。proxy_read_timeout和proxy_send_timeout设成 300 秒，是因为大模型推理的响应时间可能很长，尤其是生成长文本时，默认的 60 秒很容易超时。proxy_buffering off是为了支持流式输出，如果开启缓冲，流式响应会被 Nginx 攒着一起发，失去了流式的意义。

auth_basic是 Nginx 内置的基础认证，配合htpasswd文件使用。生成密码文件：

sudo apt install -y apache2-utils sudo htpasswd -c /etc/nginx/.htpasswd your-username

执行后会提示输入密码。这个密码就是调用服务时的凭证。基础认证虽然简单，但配合 HTTPS 使用已经能挡住绝大多数未授权访问。

4.3 证书申请与自动续期

HTTPS 证书用 Let's Encrypt 免费申请：

sudo apt install -y certbot python3-certbot-nginx sudo certbot --nginx -d your-domain.com

Certbot 会自动修改 Nginx 配置并申请证书。证书有效期 90 天，需要配置自动续期：

sudo systemctl enable certbot.timer sudo systemctl start certbot.timer

可以用sudo certbot renew --dry-run测试续期流程是否正常。这一步很多人会忘，结果三个月后证书过期，服务突然不可用，排查半天才发现是证书问题。

4.4 鉴权方案的进阶选择

基础认证够用，但如果你要给多个用户分配不同的权限，或者需要更细粒度的控制，可以考虑更完善的方案。

API Key 方案是在 Nginx 层或者应用层校验请求头里的 Key。优点是客户端调用方便，缺点是 Key 一旦泄露就需要全部更换。实现方式可以是在 Nginx 里用map指令匹配请求头，或者写一个简单的鉴权服务。

JWT 方案适合有用户体系的场景。用户先通过账号密码换取 Token，后续请求带 Token 访问。Token 有有效期，可以刷新，安全性更高。实现上需要一个签发和校验 Token 的服务，通常用 Python 或 Node.js 写一个轻量级的中间件就行。

IP 白名单是最简单粗暴的方案，只允许特定 IP 访问。适合调用方 IP 固定的场景，比如公司内网出口。配置方式是在 Nginx 里加allow和deny指令。但云服务器的公网 IP 可能会变，而且移动办公场景下 IP 不固定，所以这个方案通常作为辅助手段，和其他方案配合使用。

我的建议是，如果是个人或小团队使用，基础认证加 HTTPS 就够了。如果是对外提供服务，至少要用 API Key 方案，并且做好调用频率限制，防止被滥用。

5. 部署后的稳定性保障与性能调优

5.1 服务自启与崩溃恢复

云服务器可能会因为各种原因重启，比如宿主机维护、系统更新、意外断电。如果服务不能自动恢复，每次重启都要手动登录去拉起来，非常麻烦。

Docker 提供了重启策略，在启动容器时加上--restart unless-stopped：

docker run -d \ --restart unless-stopped \ --name harness-server \ ...

这样容器会在 Docker 服务启动后自动拉起，除非你手动停止它。配合docker update --restart unless-stopped harness-server可以给已经运行的容器加上这个策略。

但光有容器重启还不够。有时候容器没挂，但里面的推理进程卡死了，表现为请求一直不返回。这种情况需要健康检查机制。可以在 Nginx 层配置一个健康检查端点，定期探测服务是否正常响应，异常时触发告警或者自动重启容器。

5.2 显存监控与 OOM 预防

显存溢出（OOM）是推理服务最常见的崩溃原因。表现是服务突然无响应，日志里出现CUDA out of memory错误。预防 OOM 的核心是控制并发量和上下文长度。

监控显存使用情况：

watch -n 2 nvidia-smi

这个命令每两秒刷新一次显存占用。观察在正常负载下显存的使用峰值，如果经常接近上限，说明配置太激进，需要调低gpu_memory_utilization或者max_concurrent_requests。

另一个容易忽略的点是显存碎片。长时间运行后，显存会出现碎片化，即使总空闲显存够，也可能因为不连续而分配失败。缓解办法是定期重启服务，比如每天凌晨低峰期重启一次。可以在 crontab 里配置：

0 4 * * * docker restart harness-server

这个操作对用户的影响很小，但能有效避免碎片导致的偶发 OOM。

5.3 请求队列与限流策略

当请求量超过 GPU 处理能力时，请求会排队。如果队列无限增长，延迟会越来越高，最终所有请求都超时。所以必须设置队列上限和限流策略。

在 Harness 配置里设置最大队列长度：

scheduler: max_queue_size: 128 queue_timeout: 60

max_queue_size是队列能容纳的最大请求数，超过这个数的请求直接拒绝，返回 429 状态码。queue_timeout是请求在队列里等待的最长时间，超过就超时返回。这两个参数配合使用，能保证服务在高负载下不会雪崩。

在 Nginx 层也可以做限流：

limit_req_zone $binary_remote_addr zone=api:10m rate=10r/s; location /v1/ { limit_req zone=api burst=20 nodelay; ... }

这段配置限制每个 IP 每秒最多 10 个请求，突发允许 20 个。nodelay表示突发请求立即处理而不是排队。限流能防止单个用户占用过多资源，保证服务的公平性。

5.4 日志收集与问题定位

日志是排查问题的第一手资料。Docker 容器的日志默认存在/var/lib/docker/containers/下，但直接看这个目录很不方便。更好的做法是把日志挂载到宿主机目录，然后用日志工具管理。

在启动容器时挂载日志目录：

-v /data/harness/logs:/data/harness/logs

然后在 Harness 配置里指定日志输出路径。日志要分级别，INFO级别记录正常请求，WARNING记录异常但可恢复的情况，ERROR记录导致请求失败的错误。生产环境不要开DEBUG，日志量太大，磁盘很快就满了。

日志轮转也要配置，否则日志文件会无限增长。可以用logrotate：

/data/harness/logs/*.log { daily rotate 7 compress missingok notifempty }

这段配置表示每天轮转一次，保留 7 天，旧日志压缩存储。对于请求量大的服务，可能需要按小时轮转。

6. 实际部署中踩过的坑与应对经验

6.1 模型加载卡住不动

第一次部署时遇到模型加载到一半就卡住，日志停在某个进度不动了。排查了半天，最后发现是磁盘 IO 瓶颈。模型文件放在了一块低性能的云盘上，读取速度跟不上，加载进程就卡在那里。

解决办法是把模型文件放到 SSD 上，或者用内存盘加速。如果模型文件不大，可以复制到/dev/shm下，这是内存文件系统，读取速度极快。但要注意内存盘会占用系统内存，模型太大就不适合了。

另一个可能的原因是模型文件损坏。前面提到的完整性校验一定要做，不要跳过。损坏的文件会导致加载进程在读取到损坏部分时卡死或报错。

6.2 容器内 GPU 不可见

这个问题前面提过，但值得再强调一次。症状是宿主机nvidia-smi正常，但容器里执行nvidia-smi报错说找不到设备。原因通常是nvidia-container-toolkit没有正确配置，或者 Docker 服务没有重启。

排查步骤：先确认nvidia-container-toolkit已安装，然后检查/etc/docker/daemon.json里是否有nvidiaruntime 的配置。如果没有，运行sudo nvidia-ctk runtime configure --runtime=docker重新生成配置，然后重启 Docker。

还有一个隐蔽的情况是云服务器的 GPU 驱动版本和容器内 CUDA 版本不兼容。比如宿主机驱动是 470，容器里用的是 CUDA 12.1，就会报错。解决办法是统一版本，要么升级驱动，要么换用匹配 CUDA 版本的镜像。

6.3 流式输出被缓冲

配置好 Nginx 后，发现流式输出变成了"一次性返回"，用户要等很久才能看到第一个字。原因是 Nginx 默认开启了proxy_buffering，它会把后端的响应攒起来一起发给客户端。

解决办法是在 location 块里加proxy_buffering off;。另外还要确认proxy_cache也是关闭的，缓存会干扰流式输出。如果用了 CDN，CDN 层也可能有缓冲，需要在 CDN 配置里关闭相关选项。

6.4 鉴权配置生效但请求被拒

配置了基础认证后，用 curl 测试一直返回 401。检查了用户名密码都没错，最后发现是 Nginx 的auth_basic指令作用范围问题。如果auth_basic写在location块里，只对该路径生效；如果写在server块里，对整个 server 生效。要确认你的配置位置和请求路径匹配。

还有一个常见问题是密码文件权限。htpasswd生成的密码文件如果权限不对，Nginx 进程读不到，也会导致认证失败。确保文件权限是 644，属主是 root。

6.5 长时间运行后响应变慢

服务跑了一段时间后，发现响应越来越慢，重启后又恢复正常。这种情况通常是显存碎片或者内存泄漏导致的。显存碎片前面说了，定期重启可以缓解。内存泄漏则需要看框架本身是否有已知问题，或者检查是不是某些请求触发了异常路径导致资源没释放。

另一个可能的原因是日志文件太大，写日志变成了瓶颈。检查日志目录大小，配置好轮转策略。如果日志级别设得太低，改成INFO或WARNING。

7. 客户端接入与调用示例

7.1 用 curl 快速验证

服务部署好之后，用 curl 做一次完整的端到端验证：

curl https://your-domain.com/v1/chat/completions \ -u your-username:your-password \ -H "Content-Type: application/json" \ -d '{ "model": "deepseek-model", "messages": [{"role": "user", "content": "介绍一下你自己"}], "stream": true, "max_tokens": 200 }'

-u参数传入基础认证的用户名密码。stream: true开启流式输出，能看到逐字返回的效果。如果这条命令能正常返回，说明整个链路是通的。

7.2 Python 客户端封装

实际使用中，通常会封装一个 Python 客户端方便调用：

import requests class DeepseekClient: def __init__(self, base_url, username, password): self.base_url = base_url.rstrip('/') self.auth = (username, password) def chat(self, messages, stream=False, **kwargs): payload = { "model": "deepseek-model", "messages": messages, "stream": stream, **kwargs } resp = requests.post( f"{self.base_url}/v1/chat/completions", auth=self.auth, json=payload, stream=stream, timeout=300 ) resp.raise_for_status() if stream: return self._parse_stream(resp) return resp.json() def _parse_stream(self, resp): for line in resp.iter_lines(): if line: line = line.decode('utf-8') if line.startswith('data: '): data = line[6:] if data != '[DONE]': yield data

这个客户端封装了认证和流式解析，用起来比较顺手。timeout设成 300 秒，因为长文本生成可能耗时较长。

7.3 常见调用错误与排查

调用过程中可能遇到各种错误，这里列几个常见的：

遇到 502 和 504 时，先确认后端服务是否正常运行，然后检查 Nginx 的超时配置是否足够大。遇到 500 时，一定要看服务日志，里面会有详细的错误堆栈。

8. 一些个人体会和后续可扩展的方向

部署这套东西最大的感受是，安全配置不能省。我见过太多因为图省事直接暴露端口导致算力被白嫖的案例。多花半小时配置反向代理和鉴权，能省掉后面无数的麻烦。

另一个体会是，监控和日志要从第一天就做好。不要等到出问题了才想起来加日志，那时候已经晚了。显存监控、请求延迟、错误率这几个指标要持续关注，异常时能第一时间发现。

如果后续要扩展，有几个方向可以考虑。一是多模型支持，在同一台服务器上部署多个模型，通过路由分发请求。二是自动扩缩容，根据请求量动态调整实例数量，低峰期释放资源省钱。三是缓存层，对常见问题缓存回答，减少 GPU 计算压力。这些都是在基础部署跑通之后可以逐步完善的。

最后分享一个小技巧：部署完成后，写一个简单的健康检查脚本，定期探测服务状态，异常时发通知。这个脚本不需要多复杂，一个 curl 加一个判断就够了，但能让你在服务出问题时第一时间知道，而不是等用户来投诉。