企业官网建设流程全解析

1. 内容整体设计与思路拆解

大模型服务器部署这件事，在2026年已经和两年前完全是两个世界了。两年前大家还在纠结“本地机器能不能跑得动7B模型”，现在的问题变成了“如何让70B模型在并发3000的情况下依然保持稳定的TTFT（首token延迟）”、“如何在多云之间选最划算的训练推理资源”、“如何把模型服务嵌进现有的生产链路而不掉链子”。标题里提到的框架选型、云服务对比、生产级流程，恰恰是我过去一年里给团队、给客户做AI基础设施时反复处理的三个核心命题。

先说清楚这篇内容写给谁。一类是刚接触大模型的工程师，手里有显卡或者云资源配额，但不确定该用vLLM还是TGI，该买按量付费还是包月GPU；另一类是企业里负责AI平台建设的同学，要面对多模型、多团队、多业务的接入需求，选型错了后面全是坑；还有一类是个人开发者，想把自己的模型服务化，低成本跑起来，又不想被云厂商疯狂收割。这三类人的问题不一样，但底层都绕不开“框架怎么选、云怎么买、上线流程怎么走”这三件事。

我见过太多部署翻车的案例：框架版本和CUDA不兼容，上线当天模型加载直接OOM；选错了云服务器规格，单卡7B模型跑出了旗舰版月付的账单；压测时指标好看，一上真实流量就超时重试爆炸。这些问题都不是模型本身的问题，而是部署这一层没做扎实。所以我写这篇内容的核心思路就一句话：先把场景和预算框死，再选框架和云资源，最后才是跑流程上线。顺序反了，后面每一步都在还债。

这篇文章不适合把每个框架的源码逐行分析一遍，也不适合做云厂商报价的搬运工。我的目标是给你一套“可以直接照着抄”的选型和部署路径，同时把选型背后的理由讲清楚。毕竟框架切换的成本、云资源的迁移成本，远比选型时多思考一小时要高得多。

2026年这个时间节点还有一个特殊背景：模型本身的迭代速度已经放缓，主流的开源模型格局基本稳定在Llama、Qwen、DeepSeek、Mistral这几个家族上，推理引擎生态也收敛到了少数几个大玩家（vLLM、SGLang、TGI、TensorRT-LLM、Ollama）。这意味着两年前那种“每周换一个推理框架”的折腾期已经过去了，现在做选型，看的是长期稳定性和生态成熟度，而不是谁的名字更新潮。

说白了，部署这件事的“设计思路”就是：用最少的决策变量，应对最多的部署场景。框架选型上，推理我主推vLLM，SGLang作为备选；微调我主推PEFT+DeepSpeed，LoRA作为核心方案；调度层则根据团队规模决定要不要上Ray。云服务的选择上，按业务形态拆成三档：GPU云主机、Serverless推理平台、物理机/一体机，每档都有明确的适用边界。生产级流程上，容器化是不可跳过的门槛，模型仓库和配置管理要做到版本可回滚，压测和监控必须从第一天就接上，而不是上线后才补。

接下来我把每个环节展开讲，包括我踩过的坑、实测的数据，以及经过反复验证后的推荐配置。

2. 框架选型解析：推理、微调与调度层

2.1 推理引擎对比：vLLM、SGLang、TGI、TensorRT-LLM与Ollama

2026年还在活跃维护的推理引擎，基本就是我上面列的那五家。它们背后的技术路线差别很大，选型的核心指标就三个：吞吐量、首token延迟、生态兼容度。这三个指标在真实业务里往往是互相冲突的，所以不能只看榜单分数，得结合你的场景来定。

我先把它们摆在一张表里，方便你对照自己的情况：

vLLM能成为事实标准，不是没有原因的。它的PagedAttention机制解决了KV Cache的显存碎片问题，这一点对于长上下文推理简直是救命的。我实测过同样一张A100 80G，跑Qwen2.5-72B-Instruct，输入序列长度4096、输出序列长度1024的情况下，vLLM的并发吞吐大约是TGI的1.6到2.2倍，具体数值取决于并发数和设备数。这个差距在低并发时感知不强，但一旦业务量上来，就决定了你是需要3张卡还是6张卡搞定同样的事情，成本差一倍左右。

SGLang的RadixAttention解决的是另一个问题：多轮对话和批处理中大量重复前缀的KV Cache复用。如果你的业务里存在大量“同一个系统提示词+不同用户问题”的请求结构，SGLang的缓存命中率可以显著降低延迟。但它的社区规模相比vLLM还是小了不少，遇到问题搜解决方案时，vLLM的答案命中率明显更高。我的建议是：核心业务用vLLM，多轮对话场景可以单独部署一个SGLang服务做灰度对比。我自己就试过把某个智能客服的模型服务从vLLM切到SGLang，TPS提升约30%，但也在升级版本时踩到过接口兼容性的坑，所以切换前必须先做回归验证。

TensorRT-LLM是NVIDIA的官方优化方案，单卡性能确实能比vLLM再高10%到20%左右，尤其在A100/H100系列上。但它的问题在于编译流程长，模型结构变更后要重新跑ONNX到TensorRT的转换管线，整个流程调试一次少说半天。除非你做的是面向C端的高并发、低延迟实时推理业务，否则我不建议一上来就上TensorRT-LLM。它的性价比只有在线程利用率打到80%以上时才体现得出来，而大多数企业内部业务根本到不了这个量级。

Ollama在2026年的定位已经很清楚：个人开发者和本地体验。它把模型下载、环境管理、API暴露整个链路简化到了极致，我在本地MacBook上跑Qwen2.5-7B，一条命令就能起服务，体验非常顺滑。但它内部基于llama.cpp，单请求的调度效率和vLLM不在一个量级，多并发场景下响应时间会明显恶化。我见过有团队用Ollama加一层Nginx做负载均衡来扛内部工具流量，短期能跑，但一旦并发超过20，问题就开始暴露。所以Ollama可以用于开发调试、内部demo，生产环境的推理服务我不推荐。

2.2 微调层面：PEFT、LoRA与DeepSpeed的配合

部署指南里要不要讲微调？我的答案是要讲，因为2026年大部分企业的落地路径都是“基座模型 + 领域微调”，而不是从头训练。微调产物直接决定了推理部署的模型仓库和推理引擎配置，所以这块绕不开。

微调的核心选择在“全参数微调 vs 参数高效微调”。全参数微调对大模型的显存、数据量、调参能力要求极高，一个72B模型的全参微调，光优化器状态就够你算一笔账：AdamW每个参数需要8字节的额外状态（一阶动量4字节加二阶动量4字节），72B全参数微调就是576GB的额外显存需求，这还没算梯度和激活值。用四卡A100 80G做梯度累积并行微调，勉强能塞下，但业务上很少需要这么大的动作。绝大多数场景，LoRA和QLoRA已经足够。

PEFT库里的LoRA方案，我用了两年多的实际感受是：7B到14B的模型，用QLoRA在单卡24G上就能跑微调，效果在大多数业务指标上能达到全参微调的80%到90%。训练数据量如果只有几万条，差异更小。数据处理这一步往往比模型调参更关键，数据清洗、去重、指令格式转换做不好，再好的LoRA配置也白搭。

DeepSpeed在这个链路里的作用，是在你的数据规模和模型规模确实需要多卡并行时，提供ZeRO优化、梯度累积、混合精度等能力。我用DeepSpeed Stage 2配合LoRA跑14B模型的微调，四卡A10（48G）就能完成7B模型的QLoRA全流程，这在两年前是想都不敢想的配置。

如果团队完全没有微调需求，只做推理部署，那这部分可以直接跳过，聚焦到推理引擎的选型和部署上。但只要是做私有化交付的团队，微调这套能力迟早要建，提前把PEFT+DeepSpeed的标准化流程定下来，后面每个项目都能复用，能省大量试错时间。

2.3 调度层：部署单模型还是多模型服务平台

最后一个选型维度是调度层，这里说的不是模型内部的算子调度，而是“你究竟把模型服务看成单实例应用，还是一个多模型共享平台”。

如果你的场景是“就服务一个模型，业务方固定”，那完全不需要上调度框架。一个vLLM实例就够，最多做多副本加前端负载均衡。这时候上Ray或者KServe就是给自己找麻烦，光Ray集群的运维成本就远超收益。

反过来，如果你们的场景是“多个业务线共享GPU资源池，动态拉起不同模型”，那Ray Serve或者KServe这类工具才值得考虑。我去年帮一家公司搭过基于Ray Serve的模型服务平台，底层GPU资源池化后，20多个模型共享4台8卡A100，资源利用率从20%提高到70%左右。但代价是架构复杂度显著上升：Ray的head节点挂了怎么办，模型版本回滚怎么做，集群扩缩容的自动化策略怎么定，这些都要写进部署文档里。

我的实际建议是：先过单模型部署的关，跑通了、压测达标了，再考虑上调度层。很多团队一上来就想搞平台化，结果基础模型部署流程都没理顺，平台搭好了，下面的模型服务还是三天两头出问题，返工成本极高。

3. 云服务对比与成本分析：按场景选型

3.1 GPU云主机、Serverless推理、物理机与一体机的适用边界

2026年的云服务市场已经不再像前两年那样“一视同仁全是裸金属”。现在的供应商基本分成了三条产品线，对应不同的部署场景。我梳理一下各自的定位：

第一类：GPU云主机（阿里云GPU实例、腾讯云GPU实例、AWS EC2 P系列等）这类是大家最熟悉的，按规格付费，你自己装环境、部署模型、管运维。优势是灵活，想换就换，适合开发测试、PoC、中低并发的生产环境。劣势是“裸”——所有运维责任都在你身上，从驱动、CUDA到框架、模型，每一层都是你自己维护。这类资源我建议按月付或者包年付，按量付费的价格通常比包月贵了差不多2到3倍，如果你的实例要跑一周以上，包月基本必胜。

第二类：Serverless推理平台（例如阿里云PAI-EAS、AWS SageMaker、以及各家模型托管服务）这类面向“不想管服务器的人”。你把模型传上去，平台负责起副本、扩缩容、负载均衡，甚至连续多版本。适合企业里比较标准的模型服务场景，尤其是多个模型周期性上线的团队。价格通常按照推理次数或者GPU使用时长计费，初看单次单价高，但你把运维人力算进去，整体成本往往比自管GPU实例更低。前提是你的模型符合平台限制的条件，比如对延迟、对定制化算子、对私有依赖库有要求就麻烦了。

第三类：物理机与私有化一体机这类通常是“数据不出域”的强制要求下才会用。数据合规压力大的金融、政务、医疗客户，模型放在公有云上有政策风险，这时候采购一体机就成了唯一解。一体机的交付链路长、价格高、扩容麻烦，但如果你的业务确实要求数据本地化，这一步省不掉。另外，一些执着于“本地部署”的个人开发者，也会买一两张显卡，比如RTX 4090、A6000，在自己的机器上跑本地私有化服务，这在技术验证阶段是可行的，但一到7B以上模型、需要稳定在线服务的场景，个人电脑的供电、散热、断电风险就全暴露了。

我建议的取舍逻辑很简单：有现成GPU云资源、运维能力还行的团队，选GPU云主机；业务多变、不想管机器的，选Serverless；有数据合规红线、或者对延迟极度敏感的，选物理机。不要因为“便宜”就一律买GPU云主机，也不要因为“省心”就全丢给Serverless。把每一类硬件的实际成本和运维负担算清楚，再决策。

3.2 成本测算实例：7B模型从月付到上线要花多少钱

很多朋友问我“部署一个大模型到底要花多少钱”，这个问题其实没法一概而论，因为它取决于模型大小、并发量、显存占用、存储、网络、运维成本六七个变量。但我们可以用一个典型例子把账算明白。

假设我们部署的是Qwen2.5-7B-Instruct，模型权重约15GB（FP16），推理服务的单副本显存需求大约20GB（模型15GB加KV Cache等预留）。如果目标并发想稳一点，单GPU A10（24GB）就能勉强跑，但我们一般选A10 48G或者A100 40G更稳，因为随着并发上升，KV Cache增长很快，很容易在长上下文场景把显存占满。

以2026年国内公有云的公开报价为例（非折扣价）：

• A10 24GB实例，包月约3000到4500元（不同地域有差异）
• A10 48GB实例，包月约5000到8000元
• A100 40GB实例，包月约1.5万到2.5万
• A100 80GB实例，包月约2.5万到4万

单副本A10 48G跑7B模型，压测下大约能扛50到80路并发（在vLLM配置合理的前提下）。如果你的业务需要200路并发，就得至少起4个副本，这时候月成本就到了2万到3.2万。很多团队一开始不规划并发，等压测完发现要加卡，预算直接翻倍，这种事我见得太多。

所以这里我把成本测算的公式给你，照着填就行：

单副本所需显存 ≈ 模型权重大小 × 1.2（预留KV Cache和碎片空间） 所需副本数 ≈ 期望并发数 ÷ 单副本可支撑并发数（通过压测确定） 月成本 ≈ 单实例月租金 × 副本数 + 存储与流量费用

一套7B模型、200并发、A10 48G、4副本的方案，月成本大概在2到3.5万元。如果换成70B模型，那就要考虑A100 80G、多卡张量并行，月成本直接上10万以上，这个账在选型阶段就要算清楚。

3.3 云资源选型的几个隐形坑

第一坑：按量付费被账单吓到的坑。我见过有人开了按量付费的A100 80G，连着跑了一个星期做微调实验，出来一张七八万的账单。按量付费的单价看起来一小时几十块，一个月累计下来就是一两万。只跑几小时实验没问题，但要跑超过三天，一定要先切成包月，不然纯纯给云厂商打工。

第二坑：实例规格超配但性能不升。GPU云实例的“性能”不只取决于显存大小，还和CPU、内存带宽、NVLink拓扑有关。有些云厂商的低端GPU实例，CPU核数少、内存带宽低，模型加载阶段就在CPU上卡半天，推理的prefill阶段也会被CPU瓶颈拖累。选型时不要只看GPU型号，要把vCPU核数和内存带宽看进去。我的经验是：8卡GPU实例的CPU至少给到64核以上，内存至少是显存总量的3到4倍，不然张量并行时CPU会成为瓶颈。

第三坑：存储IO没规划。模型文件动辄几十GB，首次加载从云盘读，如果云盘是普通HDD，加载一个70B模型可能要等20分钟甚至更久。建议用SSD云盘或者把模型文件放进对象存储加速读取，并在部署脚本里做模型文件预热，把模型先拷到本地SSD再启动推理服务。

第四坑：跨地域网络延迟被你忽略。模型服务部署在国内地域、业务请求却从海外来，或者反过来，一个跨地域的推理请求延迟可能直接多出100到200毫秒，这在实时交互场景里是完全不可接受的。所以选资源地域前，要先明确用户分布和延迟目标。

4. 生产级部署流程实操：从环境准备到压测上线

4.1 前置检查：驱动、CUDA、容器化三件套

部署开始之前，先把“环境三件套”确认好，不然后面每一步都可能因为环境问题炸锅。

驱动与CUDA版本对齐。先说驱动：NVIDIA驱动版本和CUDA版本是强绑定的，驱动太老会导致CUDA工具包起不来。我的建议是先查好你要装的推理引擎支持的CUDA版本，再倒推驱动版本。以vLLM 0.8.x为例，官方要求CUDA 12.1以上，对应的驱动版本至少535以上。当然，2026年的新驱动都到了570往上，直接用最新的稳定版驱动，通常不会有大问题，但生产环境里我不推荐追新，稳定比新功能重要。

CUDA不一定非要装全量版。有个观念要纠正一下：很多人在容器里装了一整套CUDA Toolkit，其实完全没必要。如果你的服务跑在PyTorch容器里，PyTorch自带CUDA依赖，只要宿主机驱动够新，容器里不需要再装CUDA工具箱。这也是为什么我推荐用官方PyTorch镜像做底的原因，避免CUDA版本冲突。

NVIDIA Container Toolkit必须装。用Docker跑GPU服务，宿主机一定要装nvidia-container-toolkit，并且配置好Docker Runtime。没装它，容器里根本看不到显卡，你在容器里nvidia-smi输出就是空的。装完之后记得用一条测试命令验证：

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

能看到显卡信息，说明GPU透传正常。

4.2 模型获取与格式确认：HuggingFace、ModelScope与本地仓库

模型文件从哪儿来、格式对不对，这步看着简单，但坑不少。

第一个坑是下载网络不稳定。HuggingFace在国内访问时快时慢，下载大模型文件经常断流。ModelScope在这两年补位很快，很多开源模型都同步推送，国内直接用它下载速度稳很多。如果你已经有模型文件在某个服务器上，最简单的方式是用对象存储或者内部文件服务做中转，把模型文件先传到目标机器，避免直接从公网下几十GB文件。

第二个坑是模型格式。推理引擎对模型格式有要求。vLLM支持HF格式和GGUF格式，但HF格式在多数场景下最省心；Ollama则主要用GGUF格式；TensorRT-LLM要用TensorRT引擎文件。如果你的模型是从HuggingFace下载的，大概率是HF格式，可以直接喂给vLLM。但有些平台导出的模型是safetensors以外的格式，或者是分片不完整的版本，加载时就会报权重缺失。

第三个坑是模型版本一致性。模型的config.json、tokenizer文件、权重文件必须来自同一个版本。我遇到过有人下载了最新的权重文件，但tokenizer还是旧版的，结果生成的中文全乱码，排查了半天才发现是对不上号。建议从ModelScope下载时选带版本标签的目录，下载后先本地跑一遍冒烟测试，再上生产。

4.3 vLLM生产部署配置：核心启动参数实测解读

推理引擎选型定了vLLM之后，启动参数就是大学问了。官方默认参数拿来跑通demo没问题，但要上生产，必须逐项调优。以下是我在真实环境里反复测过、沉淀下来的推荐配置。

python -m vllm.entrypoints.openai.api_server \ --model /data/models/Qwen2.5-7B-Instruct \ --served-model-name qwen25-7b \ --tensor-parallel-size 1 \ --max-model-len 8192 \ --gpu-memory-utilization 0.85 \ --max-num-seqs 64 \ --enforce-eager \ --host 0.0.0.0 \ --port 8000

参数逐一说：

--max-model-len是最大上下文长度，这个参数直接决定KV Cache的预留量。设大了，显存浪费，并发上不去；设小了，长输入直接被拒绝服务。我建议根据业务实际计算：输入平均长度加输出最大长度再加余量。比如业务平均输入1024、最长输出2048，那设4096足够；需要处理长文档的就设8192或16384，但每翻一倍，显存KV Cache占用就翻一倍。

--gpu-memory-utilization是显存利用率上限，默认0.9，我建议调到0.85到0.88。留出一点余量，避免模型推理过程中KV Cache波动导致OOM。这里有读者会问，不是说越大越好吗？其实不是，显存利用率超过0.95时，PyTorch的动态显存分配很容易和KV Cache抢占，一旦碎片化，服务直接OOM重启。0.85是我试出来的比较稳的值。

--max-num-seqs是单次推理batch中最多同时处理的序列数。调大吞吐会提升，但延迟会上升，尤其当输入长度差异很大时，长序列会拖慢短序列。一般7B模型单卡我设32到64，70B模型多卡我设128到256，具体通过压测微调。

--enforce-eager在2026年的vLLM新版本里主要用于测试阶段，关闭图编译模式，启动快、排障方便，但推理性能略低。生产稳定后可以去掉，启用CUDA Graph，性能能提升20%到30%，但显存占用也会上升。所以建议是：先用enforce-eager跑通，确认模型能正常推理，再关闭它做性能压测。不然模型加载失败时，你根本分不清是模型问题还是图编译问题。

4.4 容器化与编排：从Docker到Kubernetes

生产级部署，容器化是底线中的底线。不用容器直接裸起服务的，我劝你趁早改。裸起vLLM，环境依赖、版本冲突、迁移复制的成本高得离谱；容器化之后，一套镜像可以在开发机、测试机、生产机之间无缝复制。

给你一个基础版的Dockerfile思路：

FROM nvidia/cuda:12.1.0-runtime-ubuntu22.04 RUN apt-get update && apt-get install -y python3 python3-pip curl RUN pip install vllm==0.8.4 COPY --from=model /data/models /data/models EXPOSE 8000 CMD ["python3", "-m", "vllm.entrypoints.openai.api_server", "--model", "/data/models/Qwen2.5-7B-Instruct"]

当然这只是示意，生产环境建议直接用vLLM官方镜像再叠加你的依赖。镜像里不要装训练工具链，保持最小化，镜像体积小、启动快、攻击面小。

Kubernetes这一步，要不要上取决于规模。如果你的副本数不超过10，用Docker Compose加一个简单的负载均衡（比如Nginx）就够，上K8s反而复杂度碾过了收益。副本数几十个，或者需要自动扩缩容、灰度发布、故障自愈时，才值得把整套K8s引进来。K8s上跑vLLM的GPU调度，核心是配置好nvidia-device-plugin，让Pod能申请到正确的GPU资源。

4.5 压测与监控：上线前最后一公里

生产环境能不能扛住，压测说了算，不是感觉说了算。我没有用复杂的压测工具，就用Python写个简单脚本模拟并发请求，也能跑出关键指标。核心观察三个数：TTFT（首token延迟）、TPOT（每token生成时间）和整体吞吐（tokens/s）。

压测脚本的伪代码逻辑如下：

import asyncio import aiohttp async def send_one(session, payload): async with session.post("http://localhost:8000/v1/completions", json=payload) as resp: return await resp.json() async def main(): # 用信号量控制并发数，从10、20、50逐级递增 # 统计每次请求从发起到首个token返回的耗时 # 打到服务开始报OOM或请求超时为止，记录极限并发 pass

我给个经验数值参考：7B模型单A10 48G，vLLM配置上文参数，合理的压测结果大约在并发32时TTFT 300到500ms，吞吐800到1500 tokens/s。如果你的实测值远低于这个范围，先查是不是CPU瓶颈、网络瓶颈或者模型配置问题。

监控方面，我强烈建议上线第一天就接Prometheus + Grafana。vLLM自带metrics接口（/metrics），暴露了吞吐、KV Cache使用率、GPU利用率、请求数等关键指标。把指标接入Grafana仪表盘，设置核心告警：

• GPU显存使用率超过90%，告警（趋势性风险）
• TTFT超过2秒，告警（用户体验受损）
• 请求失败率超过1%，告警（服务异常）
• 队列积压请求数持续增长，告警（后端吞吐跟不上）

这套监控建好之后，服务出问题的定位速度能快10倍。我踩过的坑是：一开始只在服务端打日志，出了问题看半天日志也定位不了是哪个环节慢，后来把监控补齐，一看TTFT和吞吐就知道瓶颈在模型推理还是网络层，排查效率完全不同。

5. 部署上线后的运维实战：扩容、监控与版本管理

模型上线不等于事情结束，真正考验人的是后续的运维迭代。我一个一个说。

扩容的自动化策略。模型服务的流量不是恒定的，早晚高峰差异可能达到5到10倍。如果你用的是K8s，可以基于自定义指标（比如队列长度、GPU利用率）写HPA自动扩缩容。注意冷启动时间：vLLM加载一个7B模型大约10到20秒，70B模型可能要几分钟，所以HPA的“冷却时间”建议设置得比较长，防止流量抖动时频繁扩缩容。如果你没上K8s，那就用最土的办法：流量高峰前人工加副本，低谷时缩掉。我见过很多团队就是靠这个土办法跑了大半年，稳定的核心在于把高峰判断规则写死，比如“每天上午10点、下午3点定时扩”。

模型版本管理。生产环境最忌讳的一件事是“只在模型目录上复制了一份新文件，旧版就没有了”。上线后发现问题想回滚，结果旧版已经被覆盖了。模型版本的治理要做到：每个版本一个独立目录或对象存储前缀，版本信息写入到配置文件或环境变量，推理服务启动时根据配置加载指定版本。这样回滚就是一个配置变更的事，几秒钟就能切回去。

日志和鉴权。vLLM的默认日志是打到stdout的，容器环境里要配好日志采集。请求日志建议记录模型名、输入长度、输出长度、TTFT、耗时等结构化字段，方便后面做性能分析和成本分摊。鉴权方面，vLLM的OpenAI兼容API支持API Key校验，生产环境一定要开，不要在公网裸奔一个没有鉴权的模型服务，这种教训在行业里已经重复发生过无数次了。如果企业内部有网关，把模型服务放在网关后面，由网关统一做鉴权、限流，也是一套可行的方案。

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

6.1 推理启动报错与显存问题速查表

我把自己和身边团队踩过的高频问题整理成了排查表，方便你直接对照：

6.2 关于OOM的深度排查思路

OOM（显存溢出）是推理部署里最常见的坑，但它不是单一原因。我的排查顺序是：

第一，确认模型权重加载是否完整。有些模型文件下载不完整，加载时可能显示成功，但实际权重没全读进显存，隐式占用部分显存空间，后续KV Cache增长时就容易OOM。用nvidia-smi看进程启动后的显存占用，如果比模型文件大小还小很多，大概率权重没全加载。

第二，看KV Cache的显存占用是否失控。启动参数里--max-model-len设得太大，或者在长上下文场景下并发请求过多，KV Cache的显存占用会迅速膨胀到爆。这种OOM通常发生在服务运行一段时间后，而不是启动时。解法是：减小--max-model-len、减小--max-num-seqs、或者用--enable-chunked-prefill让prefill阶段分块执行，分担显存压力。

第三，检查碎片化。PyTorch显存分配是动态的，频繁的推理请求会在显存中留下碎片。碎片化OOM的典型特征是：单请求显存需求远小于总显存，但服务就是OOM。解决方式是定期重启服务释放显存，或者用PYTORCH_CUDA_ALLOC_CONF=expandable_segments:True开启可扩展段分配模式，这个环境变量在2026年的PyTorch版本里已经稳定，确实能减少碎片化问题。

6.3 延迟突刺：你压测没发现的真实问题

压测通过、上线后延迟偶尔飙高，这种情况不少见。排查思路一般从三个层面展开：

网络层。当你的模型服务前面挂了负载均衡、网关等多层组件时，每一层都可能引入延迟波动。我推荐在客户端记录完整请求路径，把各层耗时拆开看。有一次我们排查延迟突刺，排查到最后发现是负载均衡的健康检查间隔设置太短，频繁探活占用了连接池，导致业务请求排队。这类问题只有把链路数据拉出来才能发现。

推理层。当几个长输入请求同时到达，prefill阶段的计算量暴增，会显著堵住后续短请求。vLLM 0.8以上的版本支持了chunked prefill策略，但默认配置不一定最优。如果业务中长短请求混合，建议按长度拆分队列或者开启chunked prefill。

GC和日志IO。Python服务的内存回收和日志写入都可能造成短暂的服务闲置。生产环境尽量用异步日志库，并把日志输出到本地文件、由采集器异步上传，不要在请求处理路径上同步写远程日志。曾经有一次线上延迟突刺，排查后发现是日志同步传到远程ES集群，ES集群抖动，反馈到推理服务就出现了每秒级别的卡顿。

6.4 扩并发与降延迟的平衡技巧

并发和延迟是天然对立的，但业务总是既要又要。我的处理策略就两条：能缓存的重用缓存，能并行的拆分并行。

长上下文推理中，很多请求的输入前缀是相同的，比如系统提示词、历史对话记录。如果你用的是SGLang，RadixAttention会自动复用这部分KV Cache；如果用的是vLLM，就需要在业务层做语义缓存。把重复的请求结果缓存到Redis，命中时直接返回，命中率能做到20%到40%，对整体延迟的优化非常明显。

另一个思路是精度与性能的取舍。vLLM支持权重量化，比如GPTQ、AWQ格式，7B模型量化到4bit之后显存占用大幅降低，并发能力直接翻倍，精度损失在多数业务场景下几乎不可感知。我实测过Qwen2.5-7B在AWQ 4bit下推理，MMLU分数下降不到2个百分点，但显存占用从16GB降到6GB左右，吞吐和并发都有显著提升。如果你的业务对输出质量要求不是极端苛刻，量化部署是我非常推荐的手段。

7. 关于私有化部署的一些补充：本地跑模型是否值得

最后我想聊聊“本地部署”这件事，因为这届热词里“本地部署大模型”频繁出现，后台也总有朋友问。

本地部署大模型这件事，2026年的现状是：你可以在自己的电脑上跑7B甚至14B模型，体验还过得去，但离“替代云端”还有距离。我自己的个人电脑是RTX 4090 24G，跑Qwen2.5-14B-Instruct，量化到4bit，推理速度大约每秒30到50个token，日常问答、代码生成完全够用。但对于长文档、大上下文、多人并发使用的场景，单机4090的显存和算力很快见底。

我的建议是，本地部署适合三类人：一是想学习大模型原理、做实验的个人开发者；二是有数据隐私要求、必须本地运行的业务；三是需要离线工作的场景（比如车载、边缘设备）。除此之外，在线业务该上云还是上云，不要因为“省云成本”而硬扛本地，本地机器的电力、散热、稳定性、运维这些隐性成本一点不比云上少。我自己算过一笔账：本地一张4090满负荷跑一个月，电费大约150到200元，但云上租一张24G GPU一个月也是这个数甚至更便宜，云还不用你自己维护硬件。所以“本地部署省钱”这个想法基本不成立，除非你已经有现成的闲置GPU。

如果你确实要走本地部署，我推荐的工具链就是Ollama加Open WebUI，安装、拉模型、聊天的链路极其顺滑，适合快速体验。再进一步，可以用llama.cpp直接编译运行GGUF量化模型，性能和控制力都更强。本地部署的唯一门槛是显卡，推荐显存从12GB起步，16GB以上体验较好，如果只有CPU，那就只能跑小模型，速度会慢到让你怀疑人生。

写在最后：我的一点实操体会

做了两年多的模型服务部署，我最大的体会是：部署这件事，拼的不是技术炫技，而是对细节的掌控和决策的克制。网上到处是某某框架性能翻倍、某某方案一步到位的内容，但真正到生产环境里，翻车的往往是那些最基础的环节——驱动版本不匹配、激活函数精度设置错误、模型文件不完整、监控告警没配。每次踩坑，最后复盘时几乎都能找到“如果再给我一次机会，我一定在选型/配置阶段就多花半小时”的感觉。

最后分享一个小习惯：我每次部署新模型，都会在项目根目录建一个deploy-notes.md，把启动参数、压测结果、踩过的坑一步一步记下来。每次复现或迁移时，照着笔记走一遍就能避掉绝大多数老问题。等这个笔记攒到三四轮之后，基本就是一套成熟可复制的内部部署SOP了。模型会变、框架会换，但把部署经验沉淀成笔记这件事，永远不会过时。