企业官网建设流程全解析

做了两年多的大模型高效推理与部署技术实战，我最大的感受是：模型训练只是开始，真正让模型产生价值的是后面那段路。很多人拿到一个开源基座模型，在单卡上能跑起来就以为完事了，结果一测延迟、一压并发，漏洞百出。这篇文章我不打算讲训练，也不会把Transformer结构翻来覆去地推公式，而是聚焦于“如何把一个大模型高效、稳定、低成本地部署到生产环境”这一件事。适合谁看？你刚从训练切到推理部署，想搞懂量化、KV Cache、批处理这些概念；或者你已经能跑通demo，但被显存、延迟、并发问题折磨过，这篇会非常对胃口。

1. 先搞清楚：大模型部署难的根源在哪里

1.1 训练和推理是两种完全不同的工程问题

很多从算法转工程的同学初期会不适应，因为他们习惯用训练的思路看推理。训练阶段我们关心的是收敛速度和GPU利用率，一批batch可以很大，跑一个step哪怕花几秒都没关系，反正最后看的是loss曲线。但推理阶段完全相反，在线服务的用户等不了几秒才收到第一个token，后台的并发可能同时来几十上百个请求，每一毫秒的延迟都会变成真金白银的机器成本和用户体验损失。

打个比方，训练像是印刷厂批量印书，印一万本分摊下来每本成本很低；推理像是现场答疑，每个人问的问题都不同，你必须一个一个回答，还要尽量让对方少等。这个根本差异决定了技术选型：训练堆算力、拉大batch就够了，推理则要反复优化“单次响应时间”和“单位显存能同时服务多少人”。

还有一个隐藏差异是访存瓶颈。Transformer前向推理时，每一层都要读取全部权重矩阵做矩阵乘法，一个7B参数的模型光是权重就有14GB（FP16），而一次推理实际需要的计算量相对固定。GPU的算力很强，但显存带宽往往跟不上，很多场景下推理速度不是被“算力”卡住，而是被“搬运权重”卡住。这也是为什么后面所有加速手段，本质都在想办法减少权重的搬运量。

1.2 先看三个数字：延迟、吞吐、显存占用

部署大模型，团队里必须统一一套度量口径，不然后面所有优化都是各说各话。我建议从三个数字入手。

第一个是延迟，细分为首Token延迟（TTFT）和单Token生成延迟（TPOT）。TTFT是用户从发出请求到收到第一个输出字的耗时，决定“有没有反应”；TPOT是随后每生成一个字需要的耗时，决定“读起来顺不顺”。假设一个回答要输出1000个token，TTFT是600ms，TPOT是30ms，那么用户感知的总时间就是600ms + 1000 * 30ms = 30.6秒。如果TPOT从30ms变成60ms，总时间直接飙到60.6秒，体验天差地别。所以不要只看端到端总耗时，要把TTFT和TPOT分开测。

第二个是吞吐，常用单位是“每秒生成token数”或“每秒处理请求数”。吞吐和延迟通常是矛盾的：并发越高，每个请求分到的资源越少，单路延迟越差，但整体吞吐会上升。生产环境要的不是单纯“快”，而是“在可接受的延迟范围内尽量多接请求”。

第三个是显存占用。部署一个模型，显存里放三样东西：模型权重、KV Cache、中间激活值。7B模型FP16权重约14GB，看起来一张24GB的卡放得下，但一旦并发上来，KV Cache会迅速膨胀，可能比权重还大。我在后面的章节会给具体计算公式，这里先记住一个原则：看显存不能只看“模型多大”，要看“模型+并发+上下文长度”三者叠加后的峰值。

这三个数字对应三类业务问题：延迟决定单用户体验，吞吐决定服务成本，显存决定硬件预算。上线前把这三张表拉出来，谁能说服谁就清楚了。

1.3 部署场景决定优化方向

同样是部署一个大模型，不同业务场景的优化优先级完全不同，别指望一套方案通吃。

在线对话类应用最看重TTFT和TPOT，用户已经养成了“秒回”预期。这类场景适合做连续批处理、KV Cache复用、尽量压低单请求延迟。即使吞吐稍微低一点，也不能让P99延迟太难看。

离线批量任务，比如深夜跑一批文档摘要、数据清洗、批量标签生成，用户不关心单条多快，只关心总耗时和成本。这类场景可以把batch拉到很大，甚至牺牲单条延迟换取吞吐，让模型在一个batch里尽可能处理更多请求。

边缘和端侧部署则是另一套逻辑，设备显存小、功耗敏感、网络不稳定。这种情况下INT4量化几乎是必选项，有时还要配合剪枝和蒸馏，甚至直接换一个更小的模型。端侧跑大模型不是把数据中心那套搬过去，而是要重新做一遍“资源约束下”的取舍。

明确场景后再选引擎、选量化精度、选并发参数，才不会南辕北辙。

2. 高效推理的核心技术拆解

2.1 权重量化：用INT8/INT4换速度与显存

量化是推理部署里性价比最高的优化手段之一。核心逻辑很简单：原本用FP16表示的每个权重占2字节，换成INT8占1字节，换成INT4只占0.5字节。所以7B模型FP16权重14GB，INT8约7GB，INT4约3.5GB。显存降下来了，搬运权重的字节数也降下来了，访存瓶颈明显缓解。

但量化不是白拿的好处。权重精度降低后，模型输出的质量会有轻微下降，尤其是复杂推理、数学、多轮对话这类任务。实际项目中通常的做法是：大模型尽量用INT4/INT8，小模型如果质量损失明显就退回FP16；对业务关键指标做AB测试，不要只看一两个评测分数。量化的粒度也有讲究，按Tensor、按Channel、按Group量化效果差很多。目前业内常用的AWQ这类方案会根据激活值分布自动选择更重要的权重通道，用更高精度保护它，效果比朴素量化好不少。

还有一个常被忽略的点：不仅权重可以量化，KV Cache也可以量化。长上下文场景下KV Cache会吃掉大量显存，把它从FP16降到INT8，能腾出接近一半的缓存空间，相应地就能提升并发或者支持更长的上下文。不过KV Cache量化对质量更敏感，需要谨慎验证。

2.2 KV Cache和自回归解码的隐藏瓶颈

大模型生成文本是自回归的，每次只能生成一个token，然后把新的token拼到输入末尾再跑下一次前向。如果不做缓存，每生成一个token都要重新计算之前所有token的中间状态，计算量随序列长度线性膨胀，生产环境根本没法用。

KV Cache就是用来避免这种重复计算的。它把每个token在每一层产生的Key和Value缓存下来，后续生成时只计算新token对应的部分。问题是，KV Cache占用的显存非常惊人。计算公式可以简化成这样：KV Cache大小 = 2 × 层数 × 注意力头数 × 每个头的维度 × 序列长度 × batch大小 × 每个元素字节数。

我算过一个实际例子：假设一个模型有32层，32个注意力头，每个头的KV维度是128，FP16，同时服务8个请求，每个请求上下文长度2048。那么KV Cache大小 = 2 × 32 × 32 × 128 × 2048 × 8 × 2字节，约8GB。这个数字和7B模型的14GB权重放在一起，已经非常可观。如果上下文长度翻倍到4096，KV Cache直接变成16GB，一张24GB的卡很容易爆。

这也是为什么新模型都在用GQA这类分组注意力机制，目的就是减少KV Cache的体量。推理框架方面，vLLM之所以快，很大程度得益于它把KV Cache切成固定大小的块来管理，按需分配，避免了传统静态缓存预留带来的浪费和碎片。这个概念叫PagedAttention，类比操作系统的分页内存管理，本质是“按页分配、动态续租”，用极小的代价换来了更高的显存利用率。

理解自回归之后就会明白，推理过程天然分为两个阶段：prefill阶段处理用户输入的整段prompt，计算量大、耗时集中；decode阶段逐个生成token，计算量小但极度依赖访存和KV Cache。优化方向完全不同，prefill靠几何级并行算力，decode靠减少访存和增加有效batch。

2.3 连续批处理：把GPU利用率拉满的秘诀

传统批处理有一个很笨的做法：等到攒够一批固定数量的请求再一起处理，批次内所有请求一起开始、一起结束。问题在于，如果批次里A请求的答案只有50个token，B请求的答案有500个token，B会拖住整批直到全部完成，空出的显存和算力全浪费了。

连续批处理（Continuous Batching）彻底改掉了这个模式。它不再以“整个批次”为单位调度，而是以“一个token生成步骤”为单位调度。具体来说，每个请求独占一个逻辑槽位，某个请求生成结束后，这个槽位立刻释放，新请求马上补进来，不需要等整批结束。GPU永远在处理不同进度、不同长度的请求，像一个餐厅里每张桌子吃完就翻台，而不是等所有客人统一离场。

实际使用时，连续批处理对吞吐的提升非常明显，尤其在请求长度参差不齐的在线场景。但它也有代价：调度频率变高，框架本身的逻辑更复杂；如果某类请求特别长，仍然会占用大量KV Cache，挤压其他请求。所以生产环境还要配合最大并发数、最大序列长度、排队策略一起控制。

2.4 投机采样：看起来“偷懒”但很有效的加速方法

生成一个token要跑一次模型前向，前向速度看着不快，所以有人想了个“歪招”：大模型生成，要不要先让一个小模型猜几个token，再用大模型一次性校验？如果猜对了，一个前向就能确认多个token的合法性，相当于一个生成步骤“白赚”了好几个token，decode阶段耗时立减。

这个思路就是投机采样。它不改变最终输出分布，只是在保证质量的前提下减少解码步数。实际收益取决于小模型的猜中率，猜得越准，加速比越高。我看过一些场景，在短文本和常见句式上，用投机采样能把TPOT压到原来的三分之一。实现上可以绑定一个额外的草稿模型，也可以用一个模型内部的提前退出分支。

要注意的是，投机采样不是所有场景都有效。当输出内容高度不确定、逻辑跳跃很大时，小模型猜不中，就会反复校验，反而增加开销。另外，额外部署草稿模型也有显存和工程成本。它更适合在线低并发、单路延迟敏感的场景，离线高吞吐任务里不如把batch拉大实在。

3. 部署方案选型：模型、硬件、推理引擎怎么配

3.1 推理引擎选择和对比

当前开源推理引擎不少，我简单说一下常见选择的适用边界。

vLLM是目前GPU服务端部署里口碑最稳的方案之一，特色就是PagedAttention加连续批处理，吞吐高、并发能力强，而且对外提供标准HTTP接口，接入成本低。适合在线高并发场景，也适合快速搭建一个可用的推理服务。它的缺点是对某些自定义模型结构支持需要额外适配，版本迭代频繁，有时升级会带来兼容性变化。

llama.cpp走的是另一条路，主打轻量化和跨平台，甚至能在纯CPU环境跑。它的显存占用极低，适合端侧设备、MacBook、无GPU服务器这类场景。缺点是GPU大规模高并发能力不如vLLM，功能丰富度也一般。

还有一些专用推理后端，针对特定型号的GPU做深度优化，性能上限往往是最高的。但这类方案通常和硬件绑定较深，部署和运维复杂度也高，适合对性能压榨到极致的大型生产集群，不适合小团队一上来就踩坑。

我自己的建议是：第一套方案优先用vLLM，因为它最容易跑通、社区大、问题好查；等业务真的到了需要极限性能或者特殊硬件优化的时候，再评估专用后端。不要一开始就在“极致性能”上耗费大量工程时间，先把服务跑稳更重要。

3.2 显存估算与硬件选型

硬件选型不能只看“模型多大”，我通常按下面的公式估算显存需求：

总显存 ≈ 模型权重 + KV Cache + 激活值 + 框架冗余

激活值一般占几个GB，可以先忽略或者按1-2GB估算。权重按精度换算：7B模型FP16约14GB，INT8约7GB，INT4约3.5GB。KV Cache按照上一节的公式估算，取决于并发数和序列长度。框架冗余通常是预留10%的显存，防止碎片和临时峰值。

举例来说，如果我要部署一个7B模型，INT8权重占7GB，希望支持8路并发、上下4000左右，KV Cache可能要5-6GB，再留一点冗余，合计约15GB。那么一张24GB单卡勉强够用。如果把模型改成INT4，权重降到3.5GB，KV Cache不变，合计约10GB，同一张卡能支撑的并发数就上去了。

多卡并行方面，常用的张量并行可以把权重切到多张卡上，但卡间通信会成为新的瓶颈。7B模型通常单卡搞定，13B可以看显存情况，70B级别才需要认真考虑多卡方案。我的经验是：能用单卡就不用多卡，多卡带来的通信开销和工程复杂度远高于想象。

3.3 服务化封装与对外接口设计

部署大模型不是把引擎跑起来就行，还要让业务方方便调用。现在主流做法是封装成HTTP服务，接口设计尽量兼容业界常见的Chat格式，请求里包含prompt、max_tokens、temperature等参数，返回内容支持流式输出。流式输出非常重要，用户第一句话能很快显示出来，体感会比等完整回复好很多。

接口下面要做三件事。第一，设置合理的超时和重试策略。大模型单次请求耗时可能几十秒，网关超时绝不能按普通接口的几秒来配置。第二，健康检查接口要和推理引擎的状态绑定，不能只检查进程活着。最好暴露模型是否就绪、当前排队长度、显存占用等状态。第三，限制单请求的max_tokens上限，防止用户传入一个极大的生成长度把整个服务的KV Cache拖垮。

服务化本身的技术栈并不复杂，复杂的是把并发控制、排队、监控这些生产细节处理好。一个能跑通的Demo和能扛住线上流量的服务，差别往往就在这些细节上。

4. 手把手部署一个高效推理服务

4.1 环境准备和模型就绪

在一套全新环境里，我习惯先用Docker把运行时固定下来。大模型部署最烦的就是依赖冲突，用容器镜像把PyTorch版本、CUDA版本、推理引擎版本一起锁住，换机器也能复现。

模型准备方面，先确认权重格式和分词器是否齐全，尤其是chat版本的模型，一般自带对话模板和特殊token，服务化时会自动套用。如果要用量化版本，可以直接下载已经量化好的权重，也可以自己对原始权重跑一遍AWQ这类量化脚本。自己量化需要准备一份校准集，校准集内容要和你的业务接近，不然量化后效果会偏差。

准备环境时还需要检查GPU驱动和CUDA版本是否匹配。很多启动失败的案例，根本不是模型问题，而是驱动和PyTorch要求的CUDA版本对不上。先跑一个简单的矩阵乘法脚本验证GPU可用，再启动推理服务，能省掉大量排查时间。

4.2 启动推理服务：最小可用配置

以vLLM为例，一个最小可用启动命令大概是这样的：

python -m vllm.entrypoints.api_server \ --model ./models/my-7b \ --tokenizer ./models/my-7b \ --tensor-parallel-size 1 \ --max-model-len 8192 \ --gpu-memory-utilization 0.9 \ --quantization awq \ --max-num-seqs 64 \ --port 8000

逐个解释关键参数。

--model和 --tokenizer 指定模型路径，要确保模型权重和分词器都放在本地，避免每次启动都去远程拉取，既慢又不可控。

--tensor-parallel-size 表示张量并行卡数，单卡部署就是1。除非模型单卡放不下，否则不建议开大。

--max-model-len 是模型能处理的上下文最大长度，包括输入和输出。设得太长会让KV Cache预留空间变大，实际并发能力下降；设得太短又会截断用户内容。要根据业务实际内容长度来定。

--gpu-memory-utilization 控制推理引擎最多使用多少比例的GPU显存，剩余部分留给其他任务和系统开销。我一般用0.9，不要设成0.95以上，很容易在并发波动时撞上显存天花板。

--quantization awq 表示使用AWQ量化权重。如果模型本身就是FP16，就不需要这个参数。

--max-num-seqs 限制同时处理的序列数。这是并发上限，不是越大越好，要根据显存容量来调，后面会专门讲崩溃问题。

启动完成后，先用curl发一个简单请求验证：

curl http://localhost:8000/generate \ -H "Content-Type: application/json" \ -d '{"prompt": "用一句话解释什么是缓存", "max_tokens": 128, "temperature": 0.7}'

如果返回正常文本，说明最小链路已经跑通，然后才是性能和并发调优。

4.3 性能测试和关键调优参数

跑通之后，不要急着上线，先做一次完整的性能摸底。我常用的方法是写一个Python脚本，用线程模拟不同并发数，统计TTFT、TPOT和总吞吐。先测单路，确认没有明显延迟问题，再逐步增加并发，观察P50和P99。

调优有几个关键参数值得反复试。

一是max-num-seqs。它直接决定KV Cache上界。并发数提上去，吞吐往往提高，但单个请求的TPOT会变慢，因为算力和带宽被分摊了。如果P99延迟超出预期，就往下调。这个参数需要做一组对照实验，而不是拍脑袋定。

二是gpu-memory-utilization。设得太低浪费资源，设得太高容易OOM。0.9只是一个起点，如果并发压测时频繁报显存不足，可以考虑降到0.85，同时把max-num-seqs降下来。

三是量化精度。同一个模型FP16和INT4的延迟表现完全不同，但业务质量也可能不同。这里没有统一答案，必须用你的业务数据集做AB测试，选一个“质量和性能综合最优”的组合。

四是max-model-len。很多团队习惯把8K、16K甚至更大设到最大，结果KV Cache爆炸，并发只能开到很小。如果业务实际只有2K上下文，就要果断把它设成2K或4K，省下的显存全都可以兑换成并发能力。

性能测试完要沉淀一份基线数据，包括模型名称、精度、参数配置、TTFT、TPOT、吞吐、显存峰值。这组数据以后每次改动都拿来对比，能很快看出优化是正向还是负向。

4.4 生产环境运维要点

推理服务上线后的运维，比起普通后端服务多了一层“显存和排队”的维度，很多故障表现很隐蔽。

首先是监控指标。除了常规的CPU、内存、QPS，还一定要看GPU显存利用率、GPU利用率、排队请求数、TTFT和TPOT分位数。我见过GPU利用率很高，但TTFT也飙升的情况，原因是请求都挤在prefill阶段抢算力，decode阶段的响应反而被拖慢。光看一个指标会误判。

其次是弹性伸缩。大模型服务不能简单地看CPU使用率扩容，更合理的信号是排队长度和TTFT。如果排队请求超过阈值且TTFT明显恶化，就再拉起一个新副本；如果长期空闲，就缩容。多副本之间没有状态关联，扩容很方便，但要注意把模型权重放在共享存储或提前预热到本地磁盘，否则新副本启动会非常慢。

第三是版本和回滚。模型参数、推理引擎版本、量化方式都会影响线上效果，任何改动都要有明确的版本记录。我习惯把每个模型版本打包成一个独立的可部署目录，里面包含配置文件和启动脚本，回滚时直接切换目录重启。

5. 实战中踩过的坑和排查手册

5.1 显存OOM：最经典的翻车现场

大模型部署遇到最多的故障就是CUDA OOM，而且往往不是启动时报错，而是跑了一会儿、并发一上来才爆。

典型的故障链路是：模型权重14GB，KV Cache按max-num-seqs和max-model-len预留，本来算得好好的，结果某个用户请求的prompt特别长，生成长度又大，动态KV Cache瞬间超过预留空间，直接OOM。

排查的时候先看两个数：max-num-seqs和max-model-len。它们的乘积决定了KV Cache的极端上界。如果max-num-seqs=64，max-model-len=8192，KV Cache可能会占到几十GB，显存必然不够。解决办法就是降并发、缩短上下文上限、或者改用INT4权重释放空间。

还有一个常见坑是环境里残留了之前的推理进程，显存被占着看不到。启动前执行进程检查，确保没有僵尸GPU进程。另外，如果用了多个推理副本跑在同一张卡上，也会互相挤兑。

5.2 首Token慢、生成Token慢：瓶颈定位法

同样一个模型，别人部署TTFT只要200ms，你那边却要800ms，这就要分阶段定位。

TTFT慢，重点看prefill阶段。输入prompt越长，prefill的计算量越大，TTFT自然越慢。如果prompt很短TTFT依然慢，通常是模型权重精度太高、GPU算力不够、或者框架没有用上连续批处理。可以试试换成INT4/INT8量化，或者在多卡间做张量并行。

TPOT慢，重点看decode阶段。decode每个token的计算量不大，瓶颈主要在显存带宽和KV Cache访问。如果显存带宽没跑满，可能根本原因是batch太小，GPU没有足够的并行度；如果KV Cache太大，访问局部性差，也会拖慢速度。投机采样在这个阶段往往能发挥奇效。

还有一种隐蔽的慢，发生在tokenizer文本处理这类CPU环节。如果每次请求都要做特别复杂的模板拼接，CPU消耗过高，也会拉长整体延迟。可以单独压测tokenizer，排除这个因素。

5.3 量化后效果变差怎么找回质量

很多人量化完一测，发现模型说话开始颠三倒四，第一反应就是“量化有害，还是换回FP16”。但实际项目里，量化出来的效果差距往往和量化方式、校准数据紧密相关，是可以挽救的。

先检查校准集。AWQ这类量化方案需要一个校准集来统计激活分布，如果你的校准集是新闻摘要，线上跑代码生成，分布差异太大，量化后效果自然差。把校准集换成贴近业务的样本，重新量化，通常能改善一大截。

再看量化粒度。某些模型对激活值异常敏感，粗糙的按层量化会损失太多信息。尝试支持更细粒度量化的配置，或者对特定敏感层保留FP16精度，效果也会更好。

最后是评估方法。量化后模型在通用评测集上的分数可能只掉一两个点，但在你业务的高难度样例上可能明显退步。一定要建立自己的业务评估集，包含典型场景和边界case，量化前后都跑一遍，再决定是否接受。

5.4 并发高时排队、超时怎么办

服务并发一高，最直接的反馈就是响应变慢、客户端超时。这时候先看排队数，如果排队很长，说明推理引擎处理速度小于请求到达速度，需要扩容或者限流。

常见的做法是给服务加排队策略，让短请求优先，避免被几个长请求堵死。vLLM这类框架本身会做调度，但你也可以在上层网关控制最大并发数，超过阈值就返回429或者进入等待队列。

流式输出也是一个缓解手段。就算生成时间没有缩短，但只要用户可以边看边等，主观体验会好很多。这个改动不需要换引擎，只需要客户端支持SSE流式解析。

还要检查客户端的超时配置是否合理。大模型接口的合理超时往往要设置在60秒以上，如果网关层的超时只有5秒，再快也白搭。上线前一定要打通全链路超时配置，避免网关比模型还“着急”。

6. 我在反复部署中的几点实在体会

6.1 别把“能跑”当“能上线”

刚开始接触部署时，我也犯过一个错误：模型能在单卡上正常生成文本，就觉得项目已经完成了。结果同事一压并发，单卡最多同时处理两三个请求，稍微长一点的回答就开始超时。后来我才养成了一个习惯，任何模型交付前都必须有一份压测报告，写明在什么并发下、什么P99延迟、什么吞吐水平。“能跑”只是起点，性能达标才是真正的上线标准。

6.2 技术选型要跟着业务走，不是跟着新词走

圈子里每隔几个月就会出现新的加速框架、新的量化算法，看起来每一项都值得追，但真正要落地时，稳定性和团队熟悉度比最新功能重要得多。我见过有人为了一个性能优势换掉整个推理引擎，结果迁移花了两周，线上还出现一堆兼容问题，得不偿失。现在我的原则是：用成熟方案撑住业务，把新方案放在独立环境做验证，验证充分了再考虑切换。

6.3 后续可以扩展的方向

推理部署本身也在快速变化。长上下文场景下，稀疏注意力、状态缓存复用会越来越重要；多模态模型部署要额外考虑视觉编码器的开销；端侧部署需要把量化、剪枝、蒸馏结合成一套完整流程。还有成本优化，比如把不同规格的模型按任务复杂度混合调度，热门模型常驻显存、冷门模型动态加载，都能省下不少成本。

如果你只记住一句话，我会说：先把延迟的构成拆清楚再动优化。TTFT慢和TPOT慢是两种完全不同的病，量化降的是权重搬运，连续批处理提升的是GPU利用率，调并发提升的是吞吐，每一种技术都有自己对应的“症状”。带着指标去做实验，用数据判断每一步改动是变好还是变坏，才不会在繁多的新名词里迷路。我后来的每一次部署升级，都靠这份“指标锚点”做出取舍，少踩了很多坑。希望这套实战思路也能让你少走一点弯路。