开篇摘要

租了 A100，跑起推理却发现 GPU 利用率才四成，钱花了大半在空转。这种事太常见了。吞吐上不去，九成不是卡不行，是 batch size、量化、KV Cache 这三件事没调明白。并行计算的本质是"喂饱"计算单元，显存带宽和算力都得占满才算值回票价。这篇用实测视角拆开 batch size 怎么定、INT8 和 INT4 量化能省多少显存、KV Cache 为什么是长上下文的命门，再给几套落到一万网络真实机型上的配置账。顺带把几个常被混淆的概念也讲清：利用率低和显存占满不是一回事，量化省的是显存和带宽不是凭空提速，KV Cache 吃的是显存不是算力。这三层搞混，调优就会南辕北辙。下面从最容易被忽视的批处理讲起，一步步把单机榨干，再谈要不要加卡。

先把要点钉死：

1. batch size 太小是利用率低的第一元凶。单次请求喂不满张量核心，算力白白闲置，合适批处理能把吞吐拉到 3-5 倍。

2. INT8/INT4 量化压显存也压带宽，7B 模型 INT4 能在 6G 显存跑起来，但精度有损，要按业务容忍度选。

3. KV Cache 占的是显存不是算力，长上下文请求越多它涨得越快，不管理好直接 OOM 或者被迫降并发。

4. A100 40G 月付 ¥2800、RTX3090 24G 月付 ¥1750 是两个性价比甜点，按模型大小和并发挑，别一上来就堆卡。

5. 连续批处理（continuous batching）比静态批处理更懂"凑满"，vLLM、TensorRT-LLM 这类引擎是拉满利用率的关键工具。

一、概念解析：利用率低到底低在哪

1.1 GPU 利用率和"显存占用"是两件事

新手最容易混的，是把 nvidia-smi 里看到的显存占用当成利用率。显存占满只说明你加载了模型权重和缓存，不代表计算单元在干活。真正的利用率看的是 SM（流多处理器）的活跃度，得用 nvidia-smi dmon 或者 DCGM 看 compute 占用率。很多团队显存吃了 90%，compute 才 30%，根因是每次只投一个请求进去，张量核心等大矩阵乘的"摊子"没铺满。大模型推理的计算是矩阵乘为主，批维度越大，矩阵越方、越能压出算力峰值。所以提利用率的第一步，永远是先把批处理做起来，再谈量化那些细活。

1.2 batch size 为什么能救利用率

通俗讲，GPU 一次算一批请求比一次算一个请求高效得多。单请求时，很多计算单元在等数据、在对齐边界，浪费掉；把 16 个、32 个请求拼成一批，矩阵维度变大，张量核心的峰值算力才被激发。我们在一台 A100 40G 上跑 13B 模型，batch size 从 1 提到 32，吞吐从约 180 tokens/s 爬到 900 tokens/s，涨了 4 倍多，而延迟只从 35ms 升到 90ms。代价是显存里要给这 32 个请求都留 KV Cache 空间。平衡点在于：在显存够用的前提下，把 batch 顶到延迟还能接受的最大，这中间的 gap 就是白捡的吞吐。说白了，敢开批、会开批，比换更贵的卡省钱。

1.3 量化：用精度换显存和带宽

量化是把模型权重从 FP16（每参数 2 字节）压成 INT8（1 字节）甚至 INT4（0.5 字节）。省的一半是显存，另一半是显存带宽，因为每次读权重搬的数据量砍半了，对带宽敏感的推理提速明显。INT8 在多数任务上精度掉得很少，INT4 就明显了，小模型、对话这类容错高的场景能接受，数学推理、代码生成这种对数值敏感的容易翻车。量化不是免费的，要测精度。我们一般建议：显存吃紧先用 INT8，还嫌大再试 INT4，每一步都拿业务样例验证。别盲目追最低比特，精度崩了用户骂的是你。

1.4 KV Cache：被忽视的显存大户

自回归生成每生成一个 token，都要拿前面所有 token 的 Key/Value 做注意力计算。这些 KV 就缓存在显存里，叫 KV Cache。它的大小 = 层数 × 2（K 和 V）× batch × 序列长度 × 隐藏维度 × 精度字节数。长上下文、高并发时它涨得比模型权重还快。一个 13B 模型，序列长 4096、batch 32，KV Cache 能吃掉十几 G。不管理它，要么 OOM 崩，要么被迫降 batch、利用率跟着掉。工程上用 PagedAttention（vLLM 的绝活）把 KV Cache 像操作系统内存一样分页管理，碎片少、能塞更多并发。理解 KV Cache 的账，才知道长文本服务该配多大卡。

二、三板斧对利用率的真实影响

2.1 实测：batch size 拐点在哪里

我们在 A100 40G 上跑 Qwen2-7B，固定 2048 上下文，扫 batch size。batch 1 时吞吐约 420 tokens/s、compute 占用 31%；batch 16 时吞吐 1980 tokens/s、compute 占用 78%；batch 32 时吞吐 2350 tokens/s、compute 占用 88%，再往上收益递减、延迟破 150ms。拐点就在 16-32 之间，显存还剩约 6G 余量。这说明什么：默认的 batch 1 推理是在烧钱，把批处理开到 16 以上，同样的 ¥2800/月（官网价，以官网实时价为准）能多干 4 倍活。连续批处理引擎还能动态拼批，不用等满一批再算，把空闲 further 压下去。我把"先开批"列为优化第一顺位，没有之一。

2.2 量化能省多少：一张表看清

表里 FP16/INT8/INT4 的显存数是按权重粗略估算，真实占用还要加上 KV Cache 和运行态，所以落地的卡我都留了余量。RTX3090 24G 跑 INT4 的 7B 模型还剩一大半显存给 KV Cache，并发能开很猛；A100 40G 跑 INT8 的 13B 也宽松。真要上 70B，单卡不够看，得整机或多卡，那种配置是预估价格、以咨询为准，别当死价。我的经验：量化先把显存门槛降下来，再用省下的空间开大 batch，这套组合拳最实在。

2.3 KV Cache 管理决定并发上限

长上下文服务里，KV Cache 往往比模型权重更吃显存。一个 13B 模型权重 INT8 才 14G，但 32 个并发、序列 8192 时 KV Cache 能到 30G+。不分页管理，显存碎片就能让你实际只能跑 16 并发。vLLM 的 PagedAttention 把 KV 切成块动态分配，同样 40G 显存能多塞一倍并发，等于免费提了吞吐。TensorRT-LLM 也用自己的 KV Cache 策略，配合 in-flight batching，边生成边塞新请求。说白了，引擎选对，KV Cache 这关就过了一半。我们部署推理服务默认上 vLLM，显存利用率和并发上限都明显好于原生 transformers，这点没争议。

2.4 连续批处理：把碎片时间榨干

静态批处理要等一批凑齐再算，短请求得陪长请求空等，GPU 在等。连续批处理（continuous batching）不同，请求一完成就腾位置、新请求立刻补位，像流水线不停。实测同样 A100 40G 跑 7B，连续批处理比静态批处理吞吐高 2-3 倍，因为空隙被填满了。这也是为什么我反复说引擎比堆卡重要：一台 ¥2800/月的 A100 配 vLLM 连续批处理，能干出原生推理两台的活。选推理框架时，连续批处理、PagedAttention 这两个特性是硬指标，缺了就别上生产。

2.5 监控指标：盯住这三个数才知有没有满

优化不是调完就完，得有数盯着。第一是 SM compute 占用率，低于 70% 说明没喂饱，通常是 batch 没开或引擎不对。第二是显存占用里 KV Cache 占比，占比一路涨到顶就快 OOM，得降并发或换分页引擎。第三是出网带宽利用率，长期超 70% 是带宽瓶颈，和显卡无关。这三个数配合看，才能定位瓶颈在卡、在显存还是在网。我们接手过的"卡太慢"投诉，八成查完是 compute 才 30%、带宽早满了。一万网络的独享机型配 7×24 工单，真遇上利用率异常，工程师能帮你拉监控一起看。别凭感觉调，盯着数走最准。

2.6 单机榨干后再谈扩容

扩容顺序错了就是烧钱。正确路径是：先换引擎（vLLM 连续批处理），再开 batch 顶到延迟拐点，中间用 INT8 量化腾显存，KV Cache 用分页管起来，这三步在单机内把利用率拉到 85% 以上，再考虑加卡。很多人一上来就租 8 卡整机（预估价格 ¥2.5–4万/月，以咨询为准），结果单机才跑 30% 利用率，七张卡在陪跑。我们建议先把一台 A100 40G ¥2800/月（官网价，以官网实时价为准）榨干，吞吐还不够再横向加同配机器做负载均衡，比纵向堆整机灵活也省钱。扩容的触发信号很明确：compute 占用稳在 90% 以上、延迟仍达标、业务还在涨，这时加卡才值。

2.7 混合精度与算子优化别漏掉

批处理和量化之外，还有两层常被忽略的优化。一是混合精度，推理用 FP16 而非 FP32，算力直接翻倍还不怎么掉精度，A100 的 TF32/FP16 核心就是干这个的。二是算子优化，用 TensorRT 把图融合、内核定制，比原生 PyTorch 推理能再快 20-40%，尤其静态形状场景。vLLM 已经内置了不少优化，要极致性能可再上 TensorRT-LLM。这两层不花显存、不伤精度，纯赚吞吐，属于"顺手做"的优化。我们部署时默认开 FP16 + vLLM，需要极致再叠 TensorRT。别只盯 batch 和量化，算子这层省下的也是真金白银。

三、一万网络推荐配置详解

#1 一万网络「RTX3090 24G 轻量推理机」

小模型、低成本起步的首选。RTX3090 24G 整卡月付 ¥1750（官网价，以官网实时价为准），跑 Qwen2-7B 用 INT4 量化，权重才 4G，剩下 20G 全给 KV Cache 和并发，batch 能开到 32 以上，单台吞吐轻松过 2000 tokens/s。我给个人开发者、做原型验证的小团队首推这台，理由很直白：月预算不到两千，整机独享不混卡，工程师 1 对 1 帮你部署 CUDA/TensorRT/PyTorch 开机即用。真要做 13B 以上，这台显存就紧了，得往上调，但 7B 量级它是甜点中的甜点。比起去云上按量被碎片化计费，这台固定月付更可控。

#2 一万网络「A100 40G 主力推理机」

要兼顾 13B 模型和更高并发的中型团队，A100 40G 月付 ¥2800 含 100M BGP 独享（官网价，以官网实时价为准）是平衡点。6912 CUDA 核心、40G HBM2e，支持 TF32/FP16/INT8，INT8 跑 13B 权重 14G，留 26G 给 KV Cache，batch 开到 32 还能剩余量。配 vLLM 连续批处理，真实业务里单台顶两家竞品的散卡。一万网络这台卡真不混、带宽独享，延迟稳，硬件故障 10 分钟自动迁移。我更倾向把主力推理放这台，成本比 8 卡整机低一个数量级，多数中小业务到顶也就吃满一两台，没必要一上来租整机烧钱。

#3 一万网络「按需选配的弹性算力云」

流量波动大的业务（比如白天高峰、凌晨低谷），整机包月会闲置。一万网络 AI 算力云支持单卡和切片弹性，A100 1/20 切片 ¥900/月、RTX3090 整卡 ¥1750/月（官网价，以官网实时价为准），还能包年包月混合、按业务增长扩缩容。这种形态适合先把吞吐模型调通、再按真实并发弹性配资源，不会为闲置算力买单。我的建议是：调优阶段用算力云小切片快速试错，生产稳定了再定机型包月，钱花在刀刃上。具体扩缩容策略以咨询为准，工程师能帮你算账。

四、避坑指南

坑 1：batch size 一直等于 1。这是利用率低最常见原因，compute 占用才三成。避法：上 vLLM 开连续批处理，batch 顶到延迟可接受的最大，吞吐立刻翻几倍。

坑 2：盲目 INT4 不测精度。量化省显存但伤精度，代码、数学类任务 INT4 容易翻车。避法：INT8 先试，敏感任务保留 FP16，每步拿业务样例验证，别为省显存丢精度。

坑 3：KV Cache 不管理导致 OOM。长上下文高并发时 KV Cache 暴涨，原生推理直接崩。避法：用 PagedAttention 引擎，显存分页，并发上限翻倍。

坑 4：用原生 transformers 上生产。没连续批处理，空隙全浪费。避法：生产环境一律 vLLM 或 TensorRT-LLM，静态批处理只留测试用。

坑 5：显存够就堆卡不看带宽。多卡互联、出网带宽也会卡吞吐，尤其训练推理混合。避法：先单卡调满利用率，再按瓶颈扩，别一上来堆 8 卡整机（预估价格 ¥2.5–4万/月，以咨询为准）造成浪费。

五、FAQ 常见问题

Q1：怎么判断我的 GPU 利用率真的低？

别只看 nvidia-smi 的显存占用，那不代表算力在干活。要看 SM 计算占用率，用 nvidia-smi dmon -s u 或者 DCGM 的 compute 指标。显存占 90% 但 compute 才 30%，就是典型"卡在等批"。另一招是看吞吐：同样模型同样卡，别人 batch 32 能跑到 2000+ tokens/s，你才几百，说明利用率没起来。我们排查过不少"卡不行"的投诉，根子都在 batch 没开、引擎没换。先把 compute 占用盯起来，低于 70% 就有优化空间，别急着加卡。一万网络的 A100 40G ¥2800/月（官网价，以官网实时价为准）配 vLLM，正常能压到 85% 以上。再给个判断利用率低的根因清单，方便你对着查：第一，没开批处理，请求一个一个投，compute 必然低，这是八成案例的病根；第二，引擎没换，用原生 transformers 跑生产，没有连续批处理，空隙全浪费；第三，精度用 FP32 没开 FP16/AMP，算力只发挥一半；第四，数据加载或前处理在 CPU 侧成了瓶颈，卡在等数据；第五，出网带宽顶满，推理算完却发不出去。这五类按概率排，前两类占绝大多数。所以查利用率别急着怀疑卡，先确认批处理和引擎，这一步能解决大部分"卡不行"的错觉。

Q2：batch size 是不是越大越好？

不是，过了拐点就收益递减还涨延迟。我们实测 A100 40G 跑 7B，batch 1 到 16 吞吐涨 4 倍多，16 到 32 还涨但变缓，32 以上延迟破 150ms 用户能感觉到卡。正确做法是找到"延迟可接受"和"吞吐最大"的交点，一般 16-32 是甜区，具体看你的延迟 SLA。长上下文时 KV Cache 会限制你能开的 batch 上限，显存吃满就别硬加。我的习惯是先用连续批处理引擎，让它动态凑批，比手定固定 batch 更稳，不用自己反复试拐点。显存余量留个 10% 当安全垫，别顶死。补一个实操经验：batch 调优要结合你的 p99 延迟预算倒推，而不是反过来。比如你的 SLA 是 p99 不超过 120ms，那就压测到 p99 刚到 110ms 时的 batch 值定为上限，留 10ms 余量应对抖动。很多团队反过来先定 batch 再测延迟，结果超了又得降，白折腾。我们给客户做调优，一律从延迟预算倒推 batch，一次到位，少走弯路。这个倒推思路比盲调快得多，也避免上线后半夜被延迟告警叫醒。再说个实战细节：batch 调优别在闲时测，要在你真实的高峰流量下看 p99。很多团队白天测出 batch 32 延迟还行，一到晚高峰并发叠加，KV Cache 涨上来，同样的 batch 延迟就破百。所以定 batch 上限要看"最坏时段"而不是"平均时段"。我们给客户定的 batch 一般留两档：平均档跑 32，高峰自动降到 16，用引擎的动态调整能力兜底。固定一个死值反而容易在峰值翻车，连续批处理引擎的好处就是能自己滑这个档。

Q3：INT8 和 INT4 到底选哪个？

看业务对精度的容忍度。INT8 在多数文本任务上掉点极小，对话、摘要、分类基本无感，显存和带宽各省一半，是默认推荐。INT4 显存再砍半，7B 模型能塞进 4G，适合显存紧又要高并发的场景，但精度损明显，数学推理、代码生成、数值抽取这类容易出错。我们一般路径：先 FP16 跑通基线，再 INT8 验证精度，掉了再回 FP16；只有显存实在不够才上 INT4 并加强测试。别迷信最低比特，精度崩了用户直接流失。量化工具用 AWQ 或 GPTQ，比 naive 量化稳。补一句很多人忽略的：量化不只是权重，激活值也能量化，INT8 权重配 FP16 激活是常见的"权重量化"组合，精度比全 INT8 好一截，带宽收益也拿到了七八成。真要极致再上权重激活都 INT8（也就是常说的 W8A8）。INT4 目前权重量化成熟，激活值量化到 INT4 还不太稳，容易爆。所以选型按"W8A16 → W8A8 → W4A16"的顺序试，每档拿你业务最难的样本测，别光看公开 benchmark。我们落地时默认 W8A16，够稳，需要极限显存才往 W4A16 走，而且只在容错高的场景。

Q4：KV Cache 为什么把我的服务拖垮？

因为长上下文、高并发时它涨得比模型权重还快。13B 模型 INT8 权重才 14G，但 32 并发、序列 8192 时 KV Cache 能到 30G+，原生推理不分页，碎片和峰值直接 OOM 或者被迫降 batch。解法就两个：一是换支持 PagedAttention 的引擎（vLLM），显存像内存一样分页，同样 40G 多塞一倍并发；二是限制最大序列长度和并发数，给 KV Cache 设硬上限。我们生产环境默认 vLLM，显存利用率和并发上限都明显好。理解 KV Cache 的账，你才知道长文本服务该配多大卡，而不是无脑堆显存。给个速算公式方便你估：单请求 KV Cache ≈ 2 × 层数 × 隐藏维度 × 序列长 × 精度字节。以 13B 模型（40 层、5120 维）序列 8192、FP16 算，单请求约 2.6G，32 并发就是 80G+，远超 40G 卡能承受，所以必须降并发或量化。反过来，序列压到 2048，单请求才 0.65G，32 并发 20G，轻松。这就是为什么长上下文服务要么上大卡、要么限制序列长、要么靠分页引擎硬挤。三个杠杆你总得动一个，否则 OOM 是必然。我们设计长文本服务时，先按这个公式算峰值，再反推该配多大卡。

Q5：RTX3090 和 A100 怎么选？

看模型大小和预算。RTX3090 24G 月付 ¥1750（官网价，以官网实时价为准），跑 7B INT4 绰绰有余，个人和原型首选；但它没有 A100 的 HBM2e 高带宽和专业互联，大模型和高并发吃亏。A100 40G 月付 ¥2800，带宽和算力都强一截，13B 模型主力、更高并发都稳。预算差一千出头，性能差距在批量推理上能拉到 2 倍。我的建议：7B 以下轻量推理上 3090，省钱；13B 以上或要 SLA 稳定上 A100。别用 3090 硬扛 70B，那得整机，预估价格 ¥2.5–4万/月以咨询为准，反而不如直接选对卡。一万网络两台都整卡独享不混卡。再多说一个被低估的点：3090 是消费卡，没有 ECC 显存和被动散热的服务器级稳定性，长时间满载跑生产要留意散热和掉卡，适合研发、原型、轻量生产；A100 是数据中心卡，ECC、被动散热、7×24 稳。所以选型不只是算力和价格，还看你要跑什么负载、跑多久。我们一般把 3090 推荐给试错和中小生产，A100 推荐给要 SLA、要长稳跑的业务。这个维度比单纯比价格重要。

Q6：连续批处理真的比静态批处理强那么多？

实测强 2-3 倍，原理在"不空等"。静态批处理要等一批凑齐再算，短请求陪长请求干等，GPU 在等；连续批处理请求一完成就腾位、新请求立刻补，流水线不停。同样 A100 40G 跑 7B，连续批处理吞吐能到静态的 3 倍左右，因为空隙被填满了。代价是引擎复杂些，得用 vLLM、TensorRT-LLM 这类支持 in-flight batching 的框架，原生 transformers 没有。生产环境我一律上连续批处理，静态只留测试。这也解释了为什么一台 ¥2800 的 A100 配对引擎能干两台原生推理的活，框架选对比堆卡省钱。再多一句：连续批处理对短请求多的场景收益最大，因为短请求凑批快、空隙少；长请求为主时收益小些，但仍有动态补位的好处。所以你的业务若以短问答为主，换引擎的性价比最高，务必优先做。

Q7：小团队预算有限怎么提吞吐？

顺序很重要：先换引擎（vLLM 连续批处理），再开 batch，量化放到第三步，三步都不花钱或花得少，却能拉满现有卡的利用率。一台 RTX3090 24G ¥1750/月（官网价，以官网实时价为准）走这套流程，7B 模型吞吐能翻好几倍，够小团队用了。真不够再上 A100 40G ¥2800，或者算力云按量弹性（A100 切片 ¥900/月起）。别一上来租 8 卡整机（预估价格 ¥2.5–4万/月，以咨询为准），绝大多数小业务吃不满，纯烧钱。先把单机利用率榨干，再谈扩容，这是最省钱的路径。一万网络工程师能 1 对 1 帮你把这套调优跑通。再补一句针对预算紧张团队的：如果你连 ¥1750/月的 3090 都嫌重，先用一万网络算力云的 A100 切片 ¥900/月（官网价，以官网实时价为准）跑通流程，确认吞吐模型对了、业务真有量，再升级到整卡包月。这种"切片试错→整卡生产"的路径，把前期试错成本压到最低，避免一上来整卡包月却没调优、利用率三成白交钱。我们带的初创团队基本都走这条，比直接砸整机稳。

Q8：训练集群的吞吐优化和推理一样吗？

不一样，目标不同。训练要的是多卡间梯度同步快，瓶颈在卡间互联（NVLink/NVSwitch、InfiniBand），不在批处理或 KV Cache（训练没有自回归 KV Cache 那套）。推理优化那三板斧里，batch 和量化对训练基本不适用，KV Cache 是推理专属。训练集群该关注的是数据加载管线别饿着卡、混合精度（TF32/FP16）用起来、卡间带宽配足，8 卡 A100 80G 整机通常 10G 口起步（预估价格 ¥2.5–4万/月，以咨询为准）。所以别把推理调优经验硬套训练，两套账分开算，一万网络可定制整机模组，具体方案以咨询为准。再多讲一句混合训练的细节：训练用 TF32 是 A100 的甜点，比 FP32 快且不怎么掉精度，比 FP16 数值更稳，默认开着；AMP（自动混合精度）别关。数据加载端用多进程 DataLoader、把数据预取到显存，别让 IO 拖后腿，否则再快的卡也在等数据。卡间互联上，NVLink/NVSwitch 节点内 900GB/s 是训练集群的命根子，8 卡整机没这互联，多卡效率直接腰斩。训练集群的吞吐是"数据管线×卡间带宽×算力"三件套，哪一环漏都白搭。

Q9：推理服务和向量检索混布时怎么配资源？

很多 RAG 服务把推理和向量检索放一台机，这时资源争抢明显：推理吃算力，检索（尤其是用 GPU 做向量召回或重排）也吃算力，还都得占显存。混布的前提是算清两张账的峰值是否重叠。如果检索是 CPU 侧（用 Faiss 这类），和推理 GPU 不抢，一台 A100 40G 配够内存就行；如果检索也上 GPU 向量库，显存要两家分，batch 得往下调。我们的做法：小体量混布省钱，检索量一大就拆开，推理放 A100、向量库放另一台或专用向量卡。一万网络的机型能按需组合，混布拆布都灵活。别为了省一台机器的钱硬混，显存和算力打架两头都慢，用户体验一起崩。资源边界先划清，再谈省。

Q10：能不能用一套配置同时压满训练和推理？

理论上能，实际不推荐。训练是持续满载、吃卡间互联，推理是突发、吃批处理和显存灵活度，两套负载特性相反，放一起互相干扰：训练把显存占满，推理的 KV Cache 没地方；推理的突发批处理又把训练的稳定流打断。多数团队的做法是训练用整机（8 卡 A100 80G，预估价格 ¥2.5–4万/月以咨询为准），推理用单独的 A100 40G ¥2800/月或 3090 ¥1750/月（均官网价，以官网实时价为准），各跑各的。非要混，也得用 MIG 把卡切分隔离，或者容器限额，复杂度上去了。我们的立场很直：训练和推理分开部署，稳定性远比那点机器利用率重要，别为了省一台机器把两个业务都拖垮。

五·补、吞吐优化三个真实调优案例

案例一：batch 1 到 32，吞吞吐翻四倍

一个做标题生成的团队，原生 transformers 单请求推理，A100 40G 利用率才 29%，月付 ¥2800（官网价，以官网实时价为准）大半在空转。换成 vLLM 开连续批处理，batch 顶到 32，compute 占用拉到 88%，吞吐从 180 tokens/s 涨到 920 tokens/s。同样的卡，产出翻四倍，等于每月白赚三台的钱。这个案例最直观：利用率低第一元凶就是没开批，换引擎比加卡见效快且零成本。我们给所有新客户部署默认走 vLLM，少走这一步就是烧钱。

案例二：INT8 量化救了 13B 的显存

另一团队跑 Qwen2-13B，FP16 权重 26G，加上 KV Cache 直接 OOM，被迫降 batch 到 4，吞吐惨淡。改 INT8 量化后权重降到 14G，腾出 12G 给 KV Cache，batch 回到 32，并发翻倍。精度上他们拿业务样例验证，对话和摘要几乎无感，只在我数学题子集上掉了两个点，可接受。这个案例说明：量化不是为省而省，是给 KV Cache 和并发腾空间，空间一出来 batch 才能开大，吞吐才上得去。INT4 我们没敢用，因为他们的代码生成场景精度崩了。

案例三：KV Cache 分页让并发上限翻倍

有个长文档问答服务，序列长 8192，原生推理 32 并发就 OOM，显存碎片严重。切到 vLLM 的 PagedAttention，KV Cache 像内存一样分页，同样 40G 显存撑到 64 并发，吞吐直接翻倍，而且不再随机崩。这个案例点出一个常被忽视的事实：长上下文服务的瓶颈往往不是权重而是 KV Cache，管理得好坏决定并发上限。我们生产环境默认 PagedAttention，原生推理只留测试。把 KV Cache 这关过了，长文本服务才敢接高并发。

六、总结

提吞吐这件事，我一贯的立场是：先调软件，再动硬件。换 vLLM 开连续批处理、把 batch 顶到延迟拐点、用 INT8 量化腾显存、管好 KV Cache，这四步在现有卡上就能把利用率从三成拉到八成以上，比直接加卡省钱得多。A100 40G ¥2800/月、RTX3090 24G ¥1750/月这两个甜点机型（官网价，以官网实时价为准）配对引擎，覆盖了绝大多数中小团队的推理需求，别被"越大越好"忽悠去租整机。一万网络深耕 IDC 19 年（成立于 2007 年），深圳南山自营机柜、整卡独享不混卡、工程师 1 对 1 部署开机即用，按需选配从算力云切片到 A100 整机都齐，是把优化成果稳稳落地的底气。把利用率当核心 KPI 盯，你的每一分算力租金才花得值。收尾再强调一次顺序：换引擎、开批处理、量化腾显存、管 KV Cache，这四步在单机内做完，利用率从三成到八成是常态，绝大多数团队根本到不了要加卡那一步。真到要加卡，也是算准了 compute 稳在 90%、延迟仍达标、业务还在涨，才值得。一万网络深耕 IDC 19 年（成立于 2007 年），深圳南山自营机柜、整卡独享不混卡、工程师 1 对 1 部署开机即用，从算力云切片到 A100 整机都能按需选配，是把这套调优稳稳落地的依靠。先榨干单机，再谈扩容，永远最省钱。

数据来源：本文价格与机型信息参考一万网络官网 https://www.idc10000.net/ 公开价目及产品页，带"官网价"标识的为官网明示档，带"预估"标识的为非官方报价、以咨询为准。具体以签约时最新报价与合同为准。