企业官网建设流程全解析

1. 大模型推理部署的现状与选型逻辑

1.1 为什么GPU推理部署成了绕不开的坎

这两年跟不少团队聊下来，一个共同的感受是：模型训练那关过了，真正让人头疼的反而是在线推理部署。训练可以慢慢调、可以排队跑，但推理是面向真实用户的，延迟高一点、吞吐低一点，用户体验和成本账单立刻就会给你脸色看。

大模型和生成式AI产品的推理负载有几个很鲜明的特点。第一是显存饥渴，一个7B参数的模型，FP16精度下光权重就要占掉大约14GB显存，再加上KV Cache、中间激活值，实际占用往往要奔着18到20GB去。第二是计算密集但访存更密集，自回归生成是一个token一个token往外蹦的，每生成一个token都要把整个模型权重过一遍，所以推理性能往往卡在显存带宽上，而不是纯算力上。第三是请求长度差异极大，有的用户就问一句话，有的用户贴进来一整篇文档，这种变长输入对批处理调度提出了很高要求。

正是这些特点，决定了GPU推理部署不能简单地"买张卡、装个环境、跑起来"就完事。你需要考虑用什么样的推理引擎、选什么样的GPU规格、走云端还是本地、成本怎么控制、并发上来之后怎么扩缩容。这一整套问题，就是本文要拆解的核心。

1.2 云端推理方案到底在解决什么问题

先把问题定义清楚。所谓"云端GPU推理方案"，本质上是在回答三个层面的问题：

• 算力从哪来：是租用云厂商的GPU实例，还是用Serverless形态的按需调用，还是自建机房。
• 推理怎么跑：用什么推理框架（vLLM、TensorRT-LLM、llama.cpp、SGLang等），怎么做量化，怎么管理KV Cache。
• 服务怎么交付：怎么暴露API、怎么做流式输出、怎么做并发调度和自动扩缩容。

这三个层面是层层递进的。很多人一上来就纠结"选哪家云"，其实更合理的顺序是先想清楚推理框架和服务架构，再反过来决定算力形态。因为不同的推理框架对GPU型号、显存、驱动版本的要求差别很大，选错了框架，后面换云就是大工程。

我个人的经验是，选型时按这个优先级来排：推理框架 > GPU规格 > 云厂商 > 计费模式。框架决定了你的性能上限和迁移成本，GPU规格决定了你能不能跑得动，云厂商更多是价格和稳定性的差异，计费模式则是最后优化成本的手段。

1.3 三类主流云端推理形态的取舍

目前市面上能落地的云端GPU推理方案，大致可以归为三类，各有各的适用场景。

第一类：GPU云服务器（IaaS）。就是租一台带GPU的虚拟机，你自己装驱动、装推理框架、部署服务。代表形态就是各家云厂商的GPU实例。这种方案控制力最强，什么都能自己调，适合对性能有极致要求、或者需要跑自定义模型的团队。缺点是运维成本高，你得自己处理扩缩容、故障恢复、驱动兼容这些琐事。

第二类：容器化推理服务（PaaS）。云厂商或第三方平台提供预置了推理框架的容器镜像，你把自己的模型挂上去就能跑，平台帮你处理调度和扩缩容。这种方案在灵活性和省心之间取了个平衡，适合大多数中小团队。

第三类：Serverless推理（FaaS形态）。你只管调用API，底层GPU资源完全由平台管理，按实际调用量计费。这种方案最省心，冷启动是主要痛点，适合流量波动大、或者刚起步验证产品的场景。

下面这张表可以帮你快速定位自己该往哪个方向走：

提示：不要一上来就追求"最省钱"的方案。推理部署的第一优先级永远是"跑得稳、延迟可控"，成本优化是稳定之后再做的事。我见过太多团队为了省一点GPU钱，选了不合适的方案，结果线上频繁超时，最后返工的成本远超省下的钱。

2. 推理框架选型：决定性能上限的关键一步

2.1 vLLM：高吞吐场景的默认答案

如果只能推荐一个通用的大模型推理框架，我会毫不犹豫地说vLLM。它的核心杀器是PagedAttention，这个技术把KV Cache按页来管理，就像操作系统管理内存分页一样，极大减少了显存碎片，让显存利用率能跑到90%以上。

传统推理框架处理变长请求时，KV Cache要么预分配一大块（浪费），要么动态增长（碎片化），vLLM的PagedAttention直接绕开了这个矛盾。实测下来，同样的GPU，vLLM的吞吐量能比朴素的HuggingFace Transformers实现高出十几倍甚至更多，尤其在并发请求多、输入长度差异大的场景下优势极其明显。

vLLM的部署也相对简单，基本就是一条命令的事：

pip install vllm python -m vllm.entrypoints.openai.api_server \ --model Qwen/Qwen2.5-7B-Instruct \ --tensor-parallel-size 1 \ --gpu-memory-utilization 0.9 \ --max-model-len 8192

这里几个参数值得说道说道。--tensor-parallel-size是张量并行度，单卡就填1，多卡按GPU数量填。--gpu-memory-utilization 0.9表示让vLLM用掉90%的显存，留10%给系统和其他进程，这个值不要设太满，否则容易OOM。--max-model-len是最大上下文长度，设得越大，KV Cache预留越多，能支持的并发就越少，需要根据实际业务权衡。

vLLM原生支持OpenAI兼容的API接口，这意味着你现有的基于OpenAI SDK写的代码，改个base_url就能直接对接，迁移成本极低。这一点对产品团队特别友好。

2.2 TensorRT-LLM：极致性能的代价

如果你的业务对延迟极其敏感，比如要做实时对话、或者单次推理的响应时间必须压到某个阈值以下，那TensorRT-LLM值得认真考虑。它是NVIDIA官方出的推理优化框架，会把模型编译成针对特定GPU架构优化的TensorRT引擎，能榨干硬件的每一分性能。

TensorRT-LLM的优势在于极致的低延迟和高吞吐，尤其在配合FP8、INT8量化时，性能提升非常可观。但它的代价也很明显：编译流程复杂、和GPU型号强绑定。你为A100编译的引擎，换到H100上就得重新编译，甚至驱动版本变了都可能要重来。而且它的模型支持不如vLLM那么即插即用，很多新模型需要等官方或社区适配。

我的建议是：除非你有明确的极致性能需求，并且有专人维护，否则优先选vLLM。TensorRT-LLM更适合那些已经把推理性能优化到瓶颈、需要再压榨最后一点性能的团队。

2.3 llama.cpp与GGUF：轻量部署的另一条路

前面两个都是面向数据中心GPU的方案，但现实中很多场景并不需要那么重的配置。比如内部工具、边缘设备、或者只是想快速验证一个想法，这时候llama.cpp配合GGUF格式的模型就非常合适。

GGUF是llama.cpp推出的模型格式，支持多种量化级别，从Q2到Q8，量化越狠模型越小、速度越快，但质量损失也越大。它的最大优势是CPU也能跑，GPU加速可选，而且对显存要求极低。一个7B模型量化到Q4，大概只要4GB左右，一张消费级显卡甚至纯CPU都能带得动。

# 用llama.cpp的server模式启动 ./llama-server -m qwen2.5-7b-instruct-q4_k_m.gguf \ -c 4096 \ -ngl 35 \ --host 0.0.0.0 --port 8080

-ngl 35表示把35层放到GPU上跑，剩下的在CPU上，这个数字要根据你的显存大小来调。-c 4096是上下文长度。llama.cpp的server同样提供OpenAI兼容接口，对接起来很方便。

不过要清醒认识到，llama.cpp的吞吐能力跟vLLM不在一个量级，它更适合低并发、对成本敏感、或者需要本地化部署的场景。如果你的产品要面向大量用户，还是老老实实上vLLM。

2.4 框架选型速查表

SGLang这里也提一句，它的RadixAttention对多轮对话场景的前缀复用做得很好，如果你的产品是聊天机器人形态，多轮对话占比高，SGLang能省下大量重复计算。选型时值得纳入对比。

3. GPU规格与云端实例怎么挑

3.1 显存是硬门槛，先算清楚再选卡

选GPU的第一原则：显存决定你能不能跑，算力决定你跑多快。很多人选卡时盯着算力参数看，结果买回来发现模型根本装不下，这是最常见的坑。

显存需求怎么估算？给你一个粗略但实用的公式：

推理显存 ≈ 模型参数量 × 精度字节数 × 1.2（开销系数） + KV Cache

以7B模型为例，FP16精度下：7B × 2字节 × 1.2 ≈ 16.8GB，再加上KV Cache。KV Cache的大小跟上下文长度、批大小、层数、隐藏维度都有关，粗略估算每1000 token上下文、每路并发大概要几百MB。所以一个7B模型跑FP16、支持8K上下文、并发4路，显存需求大概在20GB出头。

这就意味着，一张24GB的卡（比如4090、A10）能比较舒服地跑7B FP16，但如果你想跑14B甚至32B，就得考虑量化或者多卡了。INT8量化能把显存需求砍半，INT4再砍半，代价是质量有轻微损失，但对很多业务来说完全可接受。

3.2 主流云端GPU型号对比

云端能租到的GPU型号不少，我按常见程度和性价比梳理一下：

选卡的核心逻辑是匹配你的模型规模和并发需求。7B模型、中等并发，A10或L4就够了，没必要上A100。13B到34B，考虑L40S或A100 40GB。70B级别，基本就得A100 80GB或H100，而且往往需要多卡张量并行。

这里有个容易被忽略的点：显存带宽对推理性能的影响往往比算力更大。因为自回归生成是访存密集型的，每生成一个token都要读一遍权重。A100的显存带宽是A10的好几倍，所以在长文本生成场景下，A100的优势会非常明显，哪怕算力参数看起来差距没那么大。

3.3 多卡并行的两种方式及选择

当单卡装不下模型时，就得上多卡。多卡并行主要有两种：

张量并行（Tensor Parallelism）：把每一层的权重切分到多张卡上，每张卡算一部分，然后通信汇总。这种方式延迟低，但卡间通信频繁，对带宽要求高，一般要求卡在同一节点内、走NVLink或高速PCIe。vLLM的--tensor-parallel-size就是干这个的。

流水线并行（Pipeline Parallelism）：把模型的不同层放到不同卡上，像流水线一样传递。这种方式通信量小，但会有流水线气泡，延迟相对高。适合跨节点部署超大模型。

实际部署中，同节点内优先用张量并行，跨节点才考虑流水线并行。vLLM目前对张量并行支持很好，流水线并行支持相对有限，这也是选型时要考虑的因素。

注意：多卡并行不是简单的"卡越多越快"。张量并行的通信开销会随着卡数增加而上升，2卡到4卡可能还有明显收益，8卡以上收益就递减了。而且多卡实例的价格往往不是线性增长的，要算清楚性价比。

3.4 云端实例的隐藏成本

租GPU实例时，有几个隐藏成本容易被忽略：

• 存储成本：模型文件动辄几十GB，云盘存储是要单独计费的，而且模型加载时从云盘读取的速度会影响冷启动时间。
• 网络成本：如果推理服务要和其它服务通信，跨可用区的流量是要收费的。
• 闲置成本：GPU实例按小时计费，但你的流量不可能24小时满负荷，闲置时段就是在烧钱。这也是为什么自动扩缩容很重要。
• 快照和镜像成本：为了快速恢复，你可能会做实例快照，这些也是要占存储的。

我踩过的一个坑是：模型文件放在普通云盘上，每次实例重启加载模型要等好几分钟，后来换成高性能云盘，加载时间直接砍半。如果你的服务需要频繁扩缩容，模型加载速度直接决定了扩容的响应时间，这个钱不能省。

4. 从零搭建一套云端推理服务的完整流程

4.1 环境准备与依赖安装

假设我们选定了vLLM + A10实例的方案，从一台干净的GPU云服务器开始。第一步是确认驱动和CUDA环境。

# 查看GPU信息 nvidia-smi # 查看CUDA版本 nvcc --version

vLLM对CUDA版本有要求，一般需要CUDA 11.8以上。如果驱动太旧，需要先升级驱动。这里有个经验：云厂商提供的GPU镜像通常已经预装了合适的驱动和CUDA，直接用官方镜像能省掉大量兼容性折腾。自己从裸系统装驱动，很容易遇到版本冲突。

接下来装Python环境和vLLM：

# 建议用conda隔离环境 conda create -n vllm python=3.10 -y conda activate vllm # 安装vLLM pip install vllm

如果你的模型在HuggingFace上，还需要配置模型下载。国内环境下载大模型文件可能比较慢，可以提前用工具把模型拉到本地或者对象存储，再挂载到实例上。这一步的优化对冷启动速度影响很大。

4.2 模型加载与显存参数调优

启动vLLM服务时，参数调优是核心。除了前面提到的--gpu-memory-utilization和--max-model-len，还有几个关键参数：

python -m vllm.entrypoints.openai.api_server \ --model /path/to/your/model \ --served-model-name my-model \ --tensor-parallel-size 1 \ --gpu-memory-utilization 0.9 \ --max-model-len 8192 \ --max-num-seqs 32 \ --dtype auto \ --quantization awq

--max-num-seqs控制同时处理的最大请求数，这个值直接影响吞吐和延迟的平衡。设大了吞吐高但单请求延迟可能上升，设小了延迟低但吞吐上不去。一般从16到64之间调，根据实际压测结果定。

--quantization awq表示用AWQ量化，如果你用的是量化模型就加上，用原始FP16模型就不加。量化能显著降低显存占用，让同样的卡能跑更大的模型或更高的并发。

--dtype auto让vLLM自动判断精度，一般不用手动指定。

启动后，vLLM会打印显存分配情况和模型加载进度。第一次启动会比较慢，因为要加载权重、初始化KV Cache。如果显存不够，它会直接报OOM，这时候就要降低--gpu-memory-utilization或者--max-model-len，或者换量化模型。

4.3 服务暴露与流式输出对接

vLLM默认在8000端口提供OpenAI兼容API。生产环境一般不会直接暴露这个端口，而是前面挂一层网关（比如Nginx），做鉴权、限流、负载均衡。

流式输出是大模型产品的标配体验，用户不希望等整个回答生成完才看到内容。vLLM原生支持SSE流式输出，客户端只要在请求里带上stream: true就行：

from openai import OpenAI client = OpenAI( base_url="http://your-server:8000/v1", api_key="your-key" ) response = client.chat.completions.create( model="my-model", messages=[{"role": "user", "content": "介绍一下大模型推理"}], stream=True ) for chunk in response: if chunk.choices[0].delta.content: print(chunk.choices[0].delta.content, end="")

前端对接时，用EventSource或者fetch的ReadableStream来接收SSE数据，逐块渲染。这里有个细节：要处理用户中途取消请求的情况，前端abort之后，后端也要能感知并停止生成，否则GPU还在白白计算。vLLM支持请求取消，但需要你的网关层正确传递取消信号。

4.4 自动扩缩容与成本控制

流量不可能一直平稳，所以自动扩缩容是生产环境的必备能力。核心思路是根据GPU利用率和请求队列长度来触发扩缩容。

具体做法上，可以监控vLLM暴露的metrics（它内置了Prometheus指标），当请求排队数持续超过阈值、或者GPU利用率持续高位时，就增加实例；反之则减少。云厂商的弹性伸缩组一般支持基于自定义指标来扩缩容。

成本控制方面，几个实用手段：

• 用竞价实例跑非核心流量：竞价实例价格便宜很多，但可能被回收，适合能容忍中断的批处理任务。
• 错峰调度：如果业务有明显的流量波峰波谷，可以在低谷期缩容到最小实例数。
• 量化换成本：INT8或INT4量化能让同样的卡跑更多并发，等于变相降本。
• 共享实例：多个小模型共享一张卡，用vLLM的多模型支持或者多个进程分时复用。

我实测下来，一个7B模型、中等流量的产品，用A10实例配合自动扩缩容，月成本能控制在比较合理的范围。关键是要把扩缩容的触发阈值调准，扩得太激进浪费钱，扩得太慢用户等得急。

5. 常见问题排查与避坑经验

5.1 显存相关的典型问题

问题一：启动就OOM。这是最常见的。原因通常是--gpu-memory-utilization设太高，或者--max-model-len设太大导致KV Cache预留过多。解决办法是先把这两个值调低，跑起来之后再逐步往上加，找到稳定运行的临界点。

问题二：跑一段时间后OOM。这通常是KV Cache随着并发请求增长而耗尽。vLLM有抢占机制，显存不够时会抢占低优先级请求，但如果抢占太频繁，性能会急剧下降。这时候要么降低--max-num-seqs，要么降低--max-model-len，要么加卡。

问题三：显存碎片化。虽然vLLM的PagedAttention已经大幅缓解了碎片问题，但长时间运行后仍可能有碎片。定期重启服务是个简单有效的办法，或者用vLLM的显存分析工具排查。

5.2 性能不达预期的排查思路

性能问题排查，我一般按这个顺序来：

1. 先看GPU利用率。如果利用率很低，说明瓶颈不在GPU，可能在CPU预处理、网络传输或者调度上。
2. 看显存带宽。自回归生成是访存密集型的，如果显存带宽跑满了，说明已经到硬件极限，只能换更好的卡或者量化。
3. 看批处理效率。vLLM的连续批处理（continuous batching）是吞吐的关键，如果批大小一直上不去，检查是不是请求太稀疏或者--max-num-seqs设太小。
4. 看输入输出长度分布。如果大量请求是超长输入，prefill阶段会占用大量时间，可以考虑用chunked prefill来优化。

5.3 常见问题速查表

5.4 几个血泪教训

教训一：不要在生产环境用latest标签的镜像。我有次图省事用了vLLM的latest镜像，结果某天自动更新后行为变了，服务直接出问题。生产环境一定要锁定版本号。

教训二：模型文件一定要做校验。下载大模型文件时，网络中断导致文件损坏是常有的事，加载时报的错往往很隐晦。下载完用哈希校验一下，能省掉大量排查时间。

教训三：压测要用真实流量分布。用固定长度的请求压测，结果和真实场景差很远。真实用户的输入长度是长尾分布的，一定要用接近真实的分布来压测，否则上线后性能会打脸。

教训四：日志要打全，但别打太多。推理服务的日志量很大，全量打会拖慢性能还占存储。关键是要记录每个请求的输入输出长度、耗时、是否被抢占，这些是排查问题的核心信息。

教训五：监控GPU温度。云端GPU实例如果散热有问题，温度过高会触发降频，性能莫名其妙下降。这个坑比较隐蔽，但监控加上温度指标就能提前发现。

6. 不同业务场景的方案组合建议

6.1 面向C端的对话产品

这类产品流量大、并发高、对延迟敏感，推荐vLLM + A10/L4实例 + 自动扩缩容的组合。模型用7B到13B级别，配合INT8量化控制成本。前端用SSE流式输出保证体验。网关层做好限流和鉴权，防止被刷。

如果对话轮次多，可以考虑SGLang，它的前缀复用能省下大量重复计算。如果延迟要求极致，再考虑TensorRT-LLM。

6.2 面向B端的文档处理

这类场景输入长、并发低、对吞吐要求不高但对准确性要求高。推荐vLLM + L40S/A100实例，模型可以用14B到34B，上下文长度开到32K甚至更长。因为输入长，prefill是瓶颈，chunked prefill和前缀缓存能帮上大忙。

6.3 内部工具与验证场景

这类场景流量小、成本敏感、不需要高可用。推荐llama.cpp + 消费级GPU或纯CPU，模型量化到Q4，一张4090甚至纯CPU就能跑。部署简单，维护成本低，适合快速验证想法。

6.4 超大规模模型部署

70B以上的模型，单卡装不下，需要多卡张量并行。推荐vLLM + A100 80GB/H100多卡实例，配合FP8量化。这种配置成本很高，一定要做好流量预测和成本核算，避免资源浪费。

提示：方案组合没有标准答案，核心是匹配你的业务特点。流量大就优先吞吐，延迟敏感就优先响应速度，成本敏感就优先量化和小卡。先明确约束条件，再选方案，不要反过来。

7. 我个人的一些实操体会

折腾了这么多套推理部署，最大的体会是：部署方案的复杂度要和团队能力匹配。见过太多团队盲目追求"先进方案"，上了TensorRT-LLM或者复杂的多卡并行，结果没人维护得动，出问题排查半天，最后还不如老老实实用vLLM单卡跑得稳。

另一个体会是量化是性价比最高的优化手段。很多团队一上来就想加卡，其实先把模型量化到INT8，显存直接砍半，同样的卡能跑双倍并发，成本立竿见影地降下来。质量损失在大多数业务场景下用户根本感知不到。当然，量化前一定要做效果评估，有些对精度敏感的任务（比如代码生成、数学推理）量化后质量下降会比较明显。

还有一点，冷启动速度经常被低估。Serverless推理和自动扩缩容场景下，冷启动时间直接决定用户体验。优化冷启动的关键是加快模型加载，把模型放在高性能存储上、用更快的加载方式、甚至预热常驻实例，这些投入都是值得的。

最后分享一个小技巧：用vLLM的--enable-prefix-caching开启前缀缓存。如果你的产品有大量系统提示词（system prompt）是固定的，这个功能能把系统提示词的计算结果缓存下来，后续请求直接复用，能省下可观的prefill时间。这个开关默认可能是关的，记得手动打开。

推理部署这个领域变化很快，新的框架、新的优化技术层出不穷。但底层的逻辑是不变的：搞清楚你的瓶颈在哪，是显存、是带宽、还是调度，然后针对性地选方案。把这一层想透了，具体用哪个框架、哪家云，都是可以灵活调整的。