前阵子帮一个创业团队把内部用的问答服务从“一个人在自己电脑上跑着玩”升级成“能扛住几百人同时访问的生产服务”，踩了一路的坑，也把现在这套大模型服务器部署的打法彻底摸清了。如果你也在纠结：到底是本地部署大模型、租云服务器、还是直接用免费大模型API？框架选型该选vLLM还是Ollama？以及从下载模型到上线的完整生产级流程该怎么走？这篇文章应该能帮你省下好几个周末。接下来我用实际跑通过的方式来拆解：框架选型、云服务对比，以及一套比较稳妥的生产级部署流程。
从2026年这个节点往回看，大模型部署已经从“实验室玩具”变成了“工程问题”。工具链越来越成熟，但坑也多得很，稍不留神就在框架兼容、显存规划、网络传输上翻车。我会尽量把每个关键决策背后的理由讲清楚，而不是丢给你一堆命令让你自己去猜。
1. 部署前的思路定盘：先搞清楚你要解决什么问题
很多人在选型之前就急着下载模型，结果要么显存不够跑不起来，要么跑起来了但并发一高就卡死。我自己的经验是，部署前先把需求盘清楚，后面的决策会顺畅很多。
1.1 三种部署方式的成本账
大模型部署方式大致分三类：本地裸机部署、云服务器部署、调用托管API。光看字面你可能觉得“本地最省钱”“API最省事”，但实际算下来完全不是这么回事。
本地裸机部署的特点是：前期一次性投入大、后期边际成本低、数据完全不出内网。适合两种人：一种是预算充足但数据敏感的企业，比如医疗、金融、政务，模型和数据都要留在自己手里；另一种是技术爱好者，手头有块24GB显存的显卡，纯粹为了自己研究，不想把对话记录发给第三方。
云服务器部署的特点是：弹性、灵活、按需付费。你需要的时候租一台带GPU的实例，跑完就释放，不用的时候不花钱。适合个人开发者、小团队做产品验证，也适合业务量波动很大的场景。
调用托管API是最省心的：你根本不需要关心GPU、显存、框架、并发，一套HTTP请求就把能力接进来了。像市面上很多免费大模型API或限时赠送额度的服务，适合做MVP、写论文辅助、做轻度集成。但缺点是长期跑量后单次成本累积起来很可观，而且数据合规上始终是个绕不开的话题。
用生活化一点的话说：本地部署像买房，云服务器像租房，API调用像住酒店。买房前期压力大但住得踏实；租房灵活但长期租金不便宜；酒店最轻松，但你永远不拥有那个空间。
1.2 需求自查清单：照着填就行
在做技术选型之前，我建议先回答下面五个问题，答案会直接决定你的部署路线：
| 问题 | 考虑要点 | 影响 |
|---|---|---|
| 数据是否允许出内网？ | 公司合规、用户隐私、行业监管 | 不允许就只能本地或私有云 |
| 预期并发量有多大？ | 几个内部人用还是几百人同时在线 | 决定是单卡还是多卡集群 |
| 可接受的响应延迟是多少？ | 3秒以内还是30秒以上都能忍 | 决定量化级别和推理引擎 |
| 预算是一次性还是每月持续？ | 现金流情况 | 决定买硬件还是租实例 |
| 团队有没有GPU运维经验？ | docker、nvidia驱动、监控告警 | 决定自建还是用托管服务 |
这五个问题里最容易被忽视的是第一个。很多小团队一开始觉得“调用API多方便”，结果业务做到B轮，投资方尽调发现数据流向不合规，整个架构推倒重来。这种事情我见过不止一次。
还有一个容易踩的误区：业务场景真的需要大模型吗？我见过有团队做个简单的工业质检、纺织服装缺陷检测，硬要上一个70B的大模型，结果既要调优又要买一堆卡。其实这种场景用轻量视觉模型甚至传统CV方案就能解决，成本低十倍不止。选型不是越大越好，够用、稳定、便宜才是硬道理。
1.3 模型规模与硬件预算怎么算
搞清楚了路线，接下来就是硬件预算。这里有一个非常实用的粗算公式：
所需显存(GB) ≈ 模型参数量(十亿) × 权重精度字节数 + KV Cache及其他开销举个例子：Qwen2.5-7B-Instruct这种7B模型，如果以FP16精度加载，权重大约占用 7×2=14GB；再加上推理过程中的KV Cache、激活值、临时缓冲区，实际部署到16GB显存的卡上很紧张，24GB卡（如RTX 3090/4090）就比较舒服。如果做4bit量化，权重降到大约 7×0.5≈3.5GB，那么一张8GB显存的卡也能勉强跑起来。简单说：24GB显存可以比较舒服地跑7B~8B模型，48GB（如A6000、L40S）可以跑13B~14B，80GB（如A100/H100）才能摸到70B级别的边。
多模态大模型更吃显存，因为除了语言权重还要加载视觉编码器，同等参数量下要多预留20%~30%的显存。所以如果你打算部署的是多模态模型，计算预算的时候别卡得太死。
这里是我踩过的一个比较无语的坑：一度只盯着模型权重大小，忘了KV Cache的存在。结果显存看着够，一运行就OOM，还以为是代码写错了。后来才知道，并发越高、上下文越长，KV Cache占用越大。所以后面我会反复强调：预估显存时，一定要把“并发”和“上下文长度”这两个变量算进去。
2. 2026框架选型：推理引擎的横向对比
选框架这件事，我建议你把它放在“选模型”之后、“买服务器”之前。因为不同框架对显存的管理方式、并发处理能力、生态集成度差异太大了，直接决定了同一个模型在你机器上到底能跑多快、扛多少并发。
2.1 为什么框架选型比选模型更关键
很多新手有个错觉：模型下载下来就能用。实际上，裸模型只是“权重文件”，真正跑起来需要一套推理引擎来做张量计算、内存管理、算子编译。这套引擎就是框架。
以2026年主流的部署场景来看，有四个框架值得重点关注：vLLM、Ollama、LMDeploy、TensorRT-LLM。
vLLM是目前生产环境事实上的标准。它的核心优势是PagedAttention，说白了就是把显存里的KV Cache像操作系统的内存分页一样管理，能大幅提高显存利用率和吞吐量。配合Continuous Batching（连续批处理），多用户并发请求时可以动态合并成一个batch去算，GPU利用率拉得很高。我们压测下来，同样是Qwen2.5-7B，vLLM的吞吐量比朴素的transformers管道高出数倍不止。生产环境直接选它，基本不会错。
Ollama则走的是“轻量易用”路线。一条命令装完，一条命令拉起模型，Windows、macOS、Linux全支持，对个人电脑极其友好。还记得当时社区流行的“在Windows 11上玩转本地大模型：从安装到运行Llama 3”那类教程吗？用的就是Ollama。它内置了模型仓库、量化管理、OpenAI兼容API，对个人学习、单机部署、小团队内部试用来说体验相当顺滑。但你要真拿它去抗几百并发，它的调度能力、队列管理、监控集成都会捉襟见肘。
LMDeploy是国内团队开源的推理引擎，主打量化友好和TurboMind后端。模型格式转换、W4A16量化、KV Cache管理都做得不错，如果你主要用国内开源模型，它对Qwen、InternLM系列的算子优化很到位，部署体验也很顺。
TensorRT-LLM是NVIDIA官方的推理引擎，做深度算子融合和编译优化，在英伟达卡上的单卡延迟能做到极低。缺点是工程复杂度高，模型转换、编译、调参数要花不少时间。适合对时延极度敏感、且团队有CUDA功底的生产场景。说实话，小团队一般不建议折腾它，性价比不高。
2.2 四大主流引擎的定位差异对比
我整理了一张表，方便你根据自己的场景快速定位方向：
| 框架 | 适合场景 | 并发能力 | 部署难度 | 生态集成 | 显存管理 | 一句话结论 |
|---|---|---|---|---|---|---|
| vLLM | 生产环境、高并发API服务、多卡推理 | 高，PagedAttention+连续批处理 | 中等，Docker化后其实不难 | OpenAI兼容API，LangChain等直接对接 | 极强，KV Cache按页管理 | 生产首选，省显存且吞吐高 |
| Ollama | 个人电脑、单机试玩、Windows/macOS/Linux本地方案 | 低，单机并发一般 | 极低，一条命令拉起 | 自带模型仓库、OpenAI兼容API | 有GGUF量化支持 | 本地体验极佳，但别上生产 |
| LMDeploy | 国内开源模型、量化部署、边缘业务 | 中高，TurboMind调度不错 | 中等 | 对国内模型支持极好 | 支持W4A16等量化 | 国内模型私有化首选 |
| TensorRT-LLM | 极致延迟、英伟达生态、大厂基础设施 | 高，但依赖编译配置 | 高，需要CUDA功底 | 深度绑定英伟达 | 高性能但配置复杂 | 性能天花板，但工程量大 |
另外两个值得提的：如果追求极致轻量，llama.cpp在CPU环境也能跑量化模型，虽然速度一般但是兼容性奇高，边缘设备上常看到它；如果是Hugging Face生态的重度用户，Text Generation Inference（TGI）也不错，不过整体性能和调度我觉得还是vLLM更成熟。还有一个SGLang，在复杂推理和多模态场景下表现很亮眼，可以作为2026年的重点观察项。
2.3 不同场景下的框架推荐
结合我自己实际部署过的项目，给出一套比较“无脑”的选型建议：
- 个人电脑上的Windows 11环境，想本地部署LlaMA、Qwen系列玩一玩：直接用Ollama。下载安装包、双击、打开终端执行
ollama run qwen2.5，两分钟跑通。不需要配Python环境，不需要装CUDA，也不需要处理模型文件格式这种破事。 - 团队内部小范围试用，几十个人访问，机器是单卡24GB或双卡：用vLLM跑一套OpenAI兼容API。你只需要一个Docker命令，然后所有同事都能用HTTP方式调用，代码零改动就接上。
- 企业私有化部署，要求低显存+高精度平衡、模型是Qwen或InternLM系：LMDeploy。它的AWQ量化配合W4A16，能在同样显存下塞进更大的模型，对中文算子优化也到位。
- 大厂已有运维体系，业务对时延极度敏感：TensorRT-LLM。前提是你有专门的人能维护编译流程，不然别轻易上。
关于“主流微调工具框架选型”这里我多说一句。不少人把“微调框架”和“推理框架”混在一起问。微调（如LLaMA-Factory、MS Swin、DeepSpeed）解决的是“把模型调成你自己的”，推理框架解决的是“把模型稳定跑起来”。如果你只是部署现成模型做推理，前面这四个框架怎么选就够了；但如果你打算自己做微调，那思路完全不同，涉及数据准备、显卡训练、显存深度优化，那是另一篇长文的范畴了。这里只提示一个原则：先确定你的模型方案是直接下载还是微调产出，再决定推理框架，顺序别反。
2.4 别忽略的配套组件：量化与格式选择
无论选哪个框架，模型文件的格式和量化精度都得提前想清楚。目前最常见的格式是safetensors（PyTorch原生权重）和GGUF（llama.cpp/Ollama专用格式）。vLLM、LMDeploy可以直接吃safetensors，Ollama、llama.cpp用GGUF。
量化精度上，FP16精度最高但显存占用最大；INT8、INT4（AWQ、GPTQ）显存省一大截，但会牺牲少量精度。我个人的经验是：如果显存刚好卡在“差一点点就能跑”的边界，优先考虑做低精度量化，而不是换小模型；但如果显存充足，别随便量化，FP16省心多了，别为了省那几GB搞出一堆推理结果不对的麻烦。
3. 云服务对比：这笔钱怎么花才不冤
如果决定走云服务器路线，接下来的问题就是：花钱买哪家的GPU实例？怎么避免月账单爆炸？有没有什么低成本方案能先跑起来？
3.1 主流云GPU实例怎么挑
到了2026年，主流云厂商的GPU实例产品线已经非常同质化了，核心差异在三个点：卡型、带宽、计费方式。
卡型方面，你需要关注的是显存大小和计算精度。当前主流的卡型大概这样分档：
| 卡型 | 显存 | 适合模型规模 | 参考用途 |
|---|---|---|---|
| RTX 4090 / L20 | 24GB / 48GB | 7B~14B（FP16）或更大（量化） | 小团队通用、开发测试 |
| A10 / T4 | 24GB / 16GB | 7B~13B（量化） | 低成本推理、入门 |
| A100 / H100 | 40GB / 80GB | 13B~70B+ | 企业级、大规模并发、微调 |
| H20（国内合规供应版） | 96GB | 70B级 | 大模型重载场景 |
选卡的时候有个很关键的点：看“显存单价”而不是“总价”。不同卡型按小时价格差异很大，但你要算的是“每GB显存每小时多少钱”。之前有人租了一个看起来很便宜的实例，结果跑一个14B模型显存不够，要开两张卡做张量并行，总成本反而比一张高级卡贵。这种账一定要提前算清楚。
计费方式上，按量付费适合测试期，包年包月适合业务稳定的生产期，竞价实例（抢占式）适合跑离线批处理任务。如果你做的是推理服务，强烈不建议用竞价实例——你以为省了钱，实际上人家一回收，整条业务就断了。做批量离线推理或者模型调参，倒是可以用竞价实例，只要任务能断点续跑。
另外，别小看“带宽”这个指标。大模型权重动辄几十GB，如果你租的实例出口带宽只有1Mbps，光从对象存储下载模型就要等半天。我建议选实例时至少配100Mbps以上的带宽，或者走云厂商的内网对象存储，下载速度完全不是一个量级。
3.2 低成本过渡方案：ECS + frp 把内网服务暴露出去
如果你有自己的GPU机器但没公网IP，或者压根不想把模型文件传到云上，只想让别人能访问到内网跑着的大模型服务，有一个很成熟的低成本方案：云服务器 + frp内网穿透。
原理很简单：frp是一种反向代理工具，内网机器主动连出一台有公网IP的云服务器，然后云服务器把特定公网端口“转发”到内网机器的某个服务端口上。相当于你花几十块钱买一台最低配的ECS，就能把内网的GPU服务“映射”到公网，用户访问云服务器端口，实际流量都打到内网GPU机上。
（这里要特别说明：frp用于自己是没问题的内网穿透方案，但公网暴露有安全风险，生产环境建议加鉴权、IP白名单等防护。我讲的是技术实操，合规使用你自己衡量。）
具体配置我给个最小可用的例子。假设你的云服务器公网IP是 47.95.xx.xx，内网GPU机的vLLM服务跑在 8000 端口：
先下载frp服务端到你那台云服务器上，解压后编辑frps.toml：
bindPort = 7000 auth.token = "your-secret-token"启动服务端：
./frps -c frps.toml然后在内网GPU机上配置frp客户端frpc.toml，把本地的vLLM服务映射到云服务器的 18000 端口：
serverAddr = "47.95.xx.xx" serverPort = 7000 auth.token = "your-secret-token" [[proxies]] name = "vllm-api" type = "tcp" localIP = "127.0.0.1" localPort = 8000 remotePort = 18000启动客户端：
./frpc -c frpc.toml然后，所有外部请求只要访问http://47.95.xx.xx:18000/v1/chat/completions，就会被转发到内网GPU机的8000端口上。实测下来延迟增加约1~3ms，对LLM动辄几百毫秒的推理时间来说，几乎无感。
这套方案甚至不需要GPU云服务器，可以省下大笔GPU实例的费用。我见过不少个人开发者和预算有限的小团队，靠这种组合把“免费的大模型API”或者私有RAG服务暴露给几十个用户用，跑了好几个月也没出问题。
但有两件事必须提醒：一是frp的官方版本迭代很快，配置格式在不同版本之间有变化，建议直接用官方最新文档里的配置写法；二是安全上至少要做三件事——auth.token一定要设、云服务器安全组只放行你需要的端口、在frp服务端做流量限速，否则你的公网端口会被扫描器盯上，被薅流量是小，被拿去做坏事才是大麻烦。
3.3 私有化部署与混合架构的现实取舍
很多企业客户会问“能不能全部私有化？”答案是“能，但你要想清楚成本”。企业大模型私有化部署不只是买几台服务器，还包括内网基础环境、模型资产管理、监控告警体系、权限审计、数据流动管控。整体下来，一个像样的私有化环境，预算可以轻松到几十万甚至上百万。对大多数中小企业来说，更现实的方案是混合架构：核心敏感数据走本地私有化模型，非敏感业务走云上弹性服务，两边通过内部网关统一调度，既满足合规要求，又能控制成本。
还有一条路是用开源的PaaS平台，比如Railway这类容器部署平台，把模型服务作为容器直接推到平台上去跑，自动扩容、日志、监控全包了。这对不想自己维护K8s集群的团队来说非常省心。不过大模型推理的GPU资源调度在通用PaaS平台上支持程度参差不齐，部署前一定先确认平台有没有NVIDIA GPU实例类型，别等部署完才发现跑不了。
4. 生产级部署流程：从裸机到稳定服务
这一部分我直接给可复现的实操流程，按步骤抄就能把服务拉起来。以目前最主流的组合为例子：Ubuntu 22.04系统 + NVIDIA GPU + Docker + vLLM + Qwen2.5-7B-Instruct。
4.1 环境准备：Ubuntu、驱动与Docker
拿到一台带GPU的服务器，先做三件事：装驱动、装Docker、装NVIDIA Container Toolkit。
先用nvidia-smi确认驱动是否已经存在及GPU是否正常识别。如果没装驱动，要么用系统自带软件源安装，要么去官方驱动页面下载对应型号。生产环境我强烈建议用Docker跑推理服务，不要把vLLM直接装到宿主机上，不然Python依赖、CUDA版本、算子编译四处打架，后续维护会非常痛苦。
Docker安装没什么好说的，一条官方脚本搞定。关键是NVIDIA Container Toolkit，它让Docker容器里能用上宿主机的GPU：
curl -fsSL https://nvidia.github.io/libnvidia-container/gpgkey | \ sudo gpg --dearmor -o /usr/share/keyrings/nvidia-container-toolkit-keyring.gpg curl -s -L https://nvidia.github.io/libnvidia-container/stable/deb/nvidia-container-toolkit.list | \ sed 's#deb https://#deb [signed-by=/usr/share/keyrings/nvidia-container-toolkit-keyring.gpg] https://#g' | \ sudo tee /etc/apt/sources.list.d/nvidia-container-toolkit.list sudo apt-get update && sudo apt-get install -y nvidia-container-toolkit sudo nvidia-ctk runtime configure --runtime=docker sudo systemctl restart docker装完验证一下，能在容器里看到GPU就说明环境OK了：
docker run --rm --gpus all nvidia/cuda:12.1.0-base-ubuntu22.04 nvidia-smi这里你可能会问为什么是CUDA 12.1？主要因为vLLM官方镜像一般会跟随最新的稳定CUDA版本走，而12.1是目前兼容性最好的组合之一。具体版本号以你拉取的镜像实际要求为准。
4.2 模型获取：下载与格式选择
模型文件从哪下载？Hugging Face是最全的，但对国内网络环境不太友好，速度慢而且断连频繁。更推荐用ModelScope，不需要额外配置代理，直接命令行就能拉：
# 安装modelscope pip install modelscope # 下载Qwen2.5-7B-Instruct到本地目录 modelscope download --model Qwen/Qwen2.5-7B-Instruct --local_dir /models/Qwen2.5-7B-Instruct如果你人在海外或网络环境通畅，Hugging Face的huggingface-cli也行：
pip install huggingface_hub huggingface-cli download Qwen/Qwen2.5-7B-Instruct --local-dir /models/Qwen2.5-7B-Instruct下载之前先确认格式。如果你的场景是vLLM，直接下载safetensors格式就行，不用自己转换。但如果你后面想用Ollama跑同款模型，就得下载对应的GGUF文件，或者用ollama pull qwen2.5:7b让Ollama自己处理。这里又说回上一节的结论：框架决定格式，格式决定下载源，别搞反了。
如果公司内网有多台机器都要用同一个模型，建议下一台机器上搭个对象存储或HTTP目录，其他机器直接从内网拉，不要每台机器都去公网下载。顺带一提，局域网内传大文件时可以直接用FTP服务（Ubuntu上用vsftpd很方便），几千兆的模型文件通过万兆内网分分钟传完，比走外网省心多了。
4.3 vLLM部署实战：启动参数逐个解释
模型下载好之后，用vLLM官方Docker镜像直接把服务拉起来。这是目前最省事也最稳定的方式：
docker run -d --gpus all \ -v /models:/models \ -p 8000:8000 \ vllm/vllm-openai:latest \ --model /models/Qwen2.5-7B-Instruct \ --served-model-name qwen \ --tensor-parallel-size 1 \ --gpu-memory-utilization 0.9 \ --max-model-len 8192 \ --host 0.0.0.0 \ --port 8000逐个参数解释一下，理解了你才能真正调好：
--model：模型所在路径，vLLM会从该目录加载权重和配置。--served-model-name：对外暴露的模型名称，客户端请求里填的这个名字必须和它一致，随意换成你喜欢的品牌名也行。--tensor-parallel-size：张量并行规模。单张卡填1，两张卡写2，表示把模型切分到两张GPU上协同推理。注意不是越大越好，跨卡通信有开销，小模型用多卡反而变慢。--gpu-memory-utilization：显存利用率上限，0.9表示最多用90%的显存。留出一点余量给CUDA环境和其他进程，防止OOM，这是我在真实环境里踩出来的经验。--max-model-len：最大上下文长度。设太大会额外占用显存，设太小会影响长对话。7B模型8K是比较稳妥的起步值，如果业务需要长文档，再往上加并重新估算显存。--host 0.0.0.0 --port 8000：让服务监听所有网卡，方便外部访问。
启动之后先用curl简单测一下：
curl http://localhost:8000/v1/chat/completions \ -H "Content-Type: application/json" \ -d '{ "model": "qwen", "messages": [{"role": "user", "content": "你好，请介绍一下你自己"}], "max_tokens": 128 }'如果返回正常的JSON，说明服务已经通了。接下来可以做并发压测，用wrk或hey随便压一下，观察显存占用和响应时间，再决定要不要调整参数。
4.4 服务化增强：监控、日志、告警
一个生产级服务不能只是“能返回结果”，还要能看到它在做什么、出了问题能及时知道。vLLM原生暴露了一个Prometheus指标端点，地址是http://localhost:8000/metrics，里面包含吞吐量、排队请求数、显存使用、推理延迟等关键指标。你可以用Prometheus + Grafana做可视化监控大盘，设置告警规则，比如“排队请求数超过50持续5分钟”就触发通知。
日志方面，建议至少开启访问日志，记录每次请求的耗时、参数和结果状态。这地方有个容易被忽略的细节：一定要设日志轮转，不然跑个把月日志文件能把磁盘塞满。用Docker的话，把日志输出到宿主机的json-file驱动里，配置好max-size和max-file，或者直接对接ELK/S3。
生产环境还建议把服务放到一个编排体系里。单机就用docker-compose管理服务定义和资源限制，多机就直接上Kubernetes或者用云厂商托管的容器服务。服务健康检查、滚动更新、自动重启这几件事，能自动化的尽量自动化，别依赖人肉盯梢，人总有打盹的时候。
5. 常见坑与排查速查手册
最后一部分直接上干货，把我在部署大模型过程中踩过、也帮别人排查过的高频问题整理成速查表。
5.1 显存类问题：OOM和“服务假死”
显存溢出是部署大模型遇到最多的故障，表现通常是：日志里报CUDA out of memory，或者服务压根起不来。排查步骤：
- 先用
nvidia-smi看清楚当前显存占用情况，确认是不是有其他进程占着显存没释放。 - 如果是vLLM，重点看启动日志里KV Cache的分配情况。如果
gpu-memory-utilization调太高，可能没给CUDA context留足空间，建议降到0.85~0.9。 - 检查
max-model-len，设得越长，KV Cache预留越大，7B模型在8K上下文下和32K上下文下显存占用能差出好几GB。 - 并发太高也会导致OOM。vLLM里用
--max-num-seqs限制同时处理的序列数，把它从默认值调低，能明显缓解高并发下的显存压力。
还有一个经常被误解的点：vLLM启动时就会预留显存，不是等请求来了才分配。所以你在nvidia-smi里看到显存被吃满很正常，这是框架故意的，别慌。只要没有报错、响应正常，就是健康的。
5.2 API服务异常：401、超时、模型名不匹配
如果客户端调用一直401，先看请求头里有没有带正确的API Key；vLLM默认不校验Key，但如果你套了一层鉴权网关，就要检查网关配置。如果返回404或报“model not found”，几乎都是因为--served-model-name和请求体里model参数不一致。这种低级错误其实很常见，尤其是你换了模型后忘了同步客户端。
响应超时则要区分是推理慢还是排队慢。推理慢通常是模型太大或量化精度太低；排队慢是并发超出服务能力。前者考虑换大卡或做量化，后者考虑水平扩容或上调--max-num-seqs。
5.3 下载与文件搬运：慢、断、毁
模型文件动辄十几GB，下载中途失败、校验不一致是常事。我的建议是：优先用支持断点续传的工具（modelscope和huggingface-cli都支持）；下载完核对文件大小和sha256，很多本地推理报错其实是文件损坏导致的；传输到生产服务器时走内网，能不走公网就不走公网。
这里再分享一个冷门但很实用的小技巧：如果你在某个平台已经下一份完好的模型，可以在本地起一个HTTP静态文件服务，让其他机器直接从内网wget拉取。配合千兆以上内网，速度远胜外网，而且不存在被限速的问题。如果你习惯用FTP，Ubuntu上装个vsftpd做内网大文件分发也是挺顺手的方案。
5.4 服务挂了的快速止血流程
线上服务挂了，第一反应不是查日志，而是先恢复可用性。我的止血流程是：
- 先看是不是GPU进程崩了：
nvidia-smi看进程是否还在、显存是否释放。 - 看vLLM容器是否还活着：
docker ps看状态，如果是restarting说明一直起不来。 - 查看最近日志：
docker logs --tail 100 <容器名>，定位是OOM还是算子不支持还是端口冲突。 - 如果短期无法修复，先把服务切到备用实例或临时用免费大模型API顶上，保证业务连续性，再慢慢排查根因。
这个流程看起来简单，但真遇到事故时能让你省下大量手忙脚乱的时间。血的教训从来都是“日志没看、先重启导致问题重复三次”，最后发现是显存泄漏，重启没用。
我自己在实际操作中的一个体会是：大模型服务器部署这件事，难点其实不在“把模型跑起来”，而在“把它稳定地跑下去”。跑起来只需要一条Docker命令，稳定跑下去需要你对显存、并发、监控、安全乃至成本都有全局的把握。框架选型、云服务对比、生产级流程这些事，本质上都是在回答同一个问题——当用户连上来的时候，你的服务能接住，且不会在凌晨三点悄悄挂掉。
最后再分享一个小技巧：每一次部署，都把你用的命令、参数、踩坑记录整理成一页内部文档。等三个月后你忘了当初为什么设--max-model-len 8192的时候，这份文档就是你的救命稻草。别人也能从中受益，何乐而不为呢。
