AI推理服务部署，GPU显存和算力到底怎么取舍？CPU什么时候反而成了瓶颈

从一个部署困惑说起

做开发的同事最近遇到这么一件事：他用一台单卡 GPU 服务器跑一个 13B 级别的大语言模型推理接口，刚开始白天请求不多，接口响应还算正常，可一到晚上并发一上来，显存明明还有空余，GPU 利用率却怎么都拉不满，反倒是整机负载看着不低，接口延迟直线往上窜。他第一反应是"是不是算力不够，得换更大的卡"，但翻了监控才发现，卡在前面的是 CPU——请求预处理和分词（tokenize）把几个核心打满了，GPU 在等数据喂进来。

这类问题在自建 AI 推理服务里特别常见，尤其是预算有限、想用单实例先把服务跑起来的中小团队。显存、算力、CPU、内存、带宽这几样资源，单独看每一项都不难理解，难的是它们在真实负载里会互相牵制：哪一项先到天花板，哪一项其实长期闲置，往往和直觉相反。下面我们就抛开"越大越好"的粗办法，把单实例部署里这几项资源各自的边界和取舍讲清楚。

先搞清显存、算力、CPU、带宽各自管什么

部署一个推理服务，机器上至少有五类资源在同时工作，但它们负责的环节完全不同，不能混为一谈。

显存（GPU 显存）管的是"模型能不能装得下"。模型权重、推理过程中产生的激活值（activation）、以及自回归生成时不断增长的 KV Cache，全都住在显存里。显存不够，模型根本加载不进来，或者服务一并发就崩。

GPU 算力管的是"算得快不快"。同样一个 token、同样一张图，算力高的卡在单位时间里能算更多次，于是吞吐（throughput，每秒处理的 token 数或请求数）更高，单请求延迟更低。

CPU 管的是"进和出的搬运与加工"。把用户发来的文本做分词、把图片做解码和归一化、把模型输出解码回文字、做请求排队和调度，这些大多在 CPU 上完成。很多人以为推理就是 GPU 一件事，其实 CPU 是 GPU 的"前厅和后厨"。

系统内存（RAM）和带宽管的是"临时周转和外部往来"。内存要足够放下批处理缓冲、分词结果、并发请求的上下文；出入口带宽则影响模型从对象存储拉取的速度、以及同时服务多少外部用户时网络会不会先饱和。

理解这一点很关键：这五项不是并列的"都得堆高"，而是有先后依赖关系的链条。链条上最弱的一环，就是整个服务的真实上限。

显存才是模型能不能跑起来的硬门槛

对任何大模型推理而言，显存是第一位要确认的硬指标。原因很简单——模型权重必须完整驻留在显存中才能做前向计算。一个 13B 参数的模型，如果用 FP16（半精度）加载，权重本身就要占用约 26GB 显存；再加上推理时的激活值和随对话长度增长的 KV Cache，实际峰值往往要逼近甚至超过 30GB。这就是为什么一张 24GB 的卡（如 L4、A10G）在 FP16 下加载 13B 会很吃紧，而 48GB 的 L40S 或 80GB 的 A100/H100 则从容得多。

这里有个常被忽略的细节：KV Cache 不是固定开销，它随并发数和序列长度线性增长。假设你服务一个长上下文场景，单请求上下文 8K token，13B 模型每 token 的 KV Cache 大约几百 KB 到 1MB 量级，几十个并发叠加起来就是数 GB 甚至更多。所以"能加载模型"和"能稳定扛并发"对显存的要求差着一截，评估时要把并发下的 KV Cache 一并算进去。

量化是绕开显存门槛的主要手段。把 13B 从 FP16 量化到 INT8，权重体积直接减半到约 13GB；量化到 INT4（4bit）更是降到约 6.5GB，于是 24GB 的卡也能比较舒服地跑起来，甚至还能留出空间给 KV Cache 和多并发。代价是精度有不同程度损失，对多数通用对话、摘要、分类场景影响可控，但对数学推理、代码生成等敏感任务需要实测。换句话说，显存不够时，第一选择往往不是加卡，而是先看能不能量化。

显存够用之后，GPU算力决定你能扛多少并发

显存解决的是"能不能跑"，算力解决的是"能跑多快、来多少人你接不接得住"。这两件事优先级不同：显存是入场券，算力是吞吐的天花板。

举个直观的例子。同样是 13B 模型、同样量化到 INT4，一张 L4（FP16 算力约 242 TFLOPS，含稀疏）和一张 L40S（FP16 算力约 733 TFLOPS，含稀疏）都能装下模型，但后者单位时间能算的次数大约是前者的三倍，于是单卡能支撑的并发请求数、每秒生成的 token 数都更高，在同样延迟目标下能服务更多用户。如果你的痛点是"晚上一并发就慢"，那在显存已经够用的前提下，升级算力才是正解。

需要提醒的是，算力只有在"GPU 真的在满负荷算"时才划算。如果你的负载里大量时间是花在等 CPU 分词、等网络取数、等外部 RAG 检索上，那 GPU 算力再高也是闲置，这时候加算力就是浪费钱。所以算力要不要加，得先看监控里 GPU 利用率在高峰期是不是真被打满。

7B和13B级别模型的显存占用到底怎么算

给一个可落地的估算公式，方便自己动手算。模型权重显存 ≈ 参数量 × 每参数字节数：FP16 是 2 字节，INT8 是 1 字节，INT4 是 0.5 字节。

按这个算，7B 模型：FP16 约 14GB，INT8 约 7GB，INT4 约 3.5GB。13B 模型：FP16 约 26GB，INT8 约 13GB，INT4 约 6.5GB。70B 模型：FP16 约 140GB（必须多卡或高显存卡），INT4 约 35GB（单张 48GB/80GB 卡可跑，但并发受限）。

这还没算 KV Cache。以 13B、上下文 4K、batch 攒到 32 个并发为例，KV Cache 可能额外吃掉几 GB 到十几 GB。所以实际选卡时，建议用"权重 + 预期峰值 KV Cache + 2~4GB 余量"来倒推所需显存，而不是只看权重。一个常见错误是盯着"模型能加载"的显存下限买卡，结果上线后稍微一并发就 OOM（显存溢出）。

另外，不同推理框架对显存的占用也有差别。像 vLLM、TensorRT-LLM 这类支持 PagedAttention、连续批处理（continuous batching）的引擎，能把 KV Cache 管理得更紧凑，同等显存下并发能力明显优于朴素实现。选型时框架和卡要一起看，不能只比较硬件。

GPU型号横向对比：从L4到H100怎么选

下面这张表把当前主流数据中心推理 GPU 的关键参数放在一起对比。数值均取自 NVIDIA 官方规格，FP16 算力为 Tensor Core 含稀疏（sparsity）的标称值，实际可用要视框架与精度支持而定。

从表里能直接看出取舍逻辑：L4 胜在省电、便宜、单槽好塞，适合 7B 级别轻量推理和视频类负载；L40S 用 48GB 显存和三倍于 L4 的算力，成为 13B 全精度服务的高性价比甜点；A100 80GB 的杀手锏是 HBM2e 高带宽和 MIG 切分，一张卡能当多个独立实例用；H100 则面向需要极致吞吐和超大模型的前沿场景。对绝大多数 7B/13B 自建推理服务来说，L4 和 L40S 是更常见的起点。

CPU为什么会在推理里悄悄成为瓶颈

回到开头那个案例。为什么显存和算力都还有富余，服务却卡住了？因为推理服务的实际工作流是：CPU 接收请求 → 分词/解码/预处理 → 数据搬运到 GPU → GPU 计算 → 结果搬回 → CPU 后处理/解码输出。只要其中任意一步慢了，GPU 就在空等。

CPU 最容易吃力的地方有几个。第一是分词（tokenization）。现代大模型的分词器（如基于 BPE 的实现）跑在 CPU 上，面对高并发的短请求洪流时，分词本身会变成并行计算量。当单卡 GPU 算得很快（比如小模型或量化后），CPU 反而成了喂不饱 GPU 的短板。第二是请求调度与连续批处理的编排，这部分逻辑多在线程/进程里跑，并发一高就抢占 CPU。第三是多模态场景的预处理：图像要解码、resize、归一化，音频要重采样、特征提取，这些都是 CPU 密集型，且往往比文本分词重得多。

一个常被引用的现象是：在云上的 GPU 实例里，vCPU 数量常常和 GPU 严重不匹配。例如某些单卡 L4 实例只配了 4 个 vCPU、16GB 内存，对跑一个 7B 模型本身够用，但一旦你加上 RAG 检索、加上重预处理、加上多个后端服务混部，4 核立刻不够分。所以给推理服务配机器时，CPU 核数不能只看"能不能启动服务"，而要看"峰值并发下的全链路占用"。

预处理与后处理：CPU真正吃力的地方

把 CPU 的工作拆细一点，能更清楚它在哪耗时。预处理阶段，文本类主要是分词和张量拼接，开销相对可控；但如果你做检索增强生成（RAG），那一步的向量检索、文档切块、嵌入计算可能大量落在 CPU 或另一块嵌入 GPU 上，链路一长，CPU 调度压力就上来了。图像、音视频类推理的预处理更重，解码和变换在 CPU 上跑满核是常态。

后处理阶段同样不能忽视。模型输出的是 token id 序列，需要 CPU 做 detokenize 还原成文字，再做流式封装（SSE/WebSocket）推送给用户。如果是做内容审核、后过滤、格式转换，这些也多在 CPU 完成。高并发下，哪怕每请求只多花几毫秒后处理，乘以每秒几千次请求，CPU 占用就非常可观。

应对 CPU 瓶颈的实务手段有几种：把分词做成批量（batching）而非逐条，减少 Python GIL 带来的串行损耗；用多进程 worker 而不是单进程扛所有请求；把重预处理（如图像解码）尽量下沉到 GPU 的解码单元（如 NVIDIA NVDEC）或专用媒体库；在容器编排层面给推理进程绑定独立 CPU 核，避免被系统任务或其他容器挤占。本质上，CPU 瓶颈不是靠"买更多核"一个办法解决，而是先定位是哪一段预处理/后处理在吃资源，再针对性优化。

出入口带宽：什么时候它才真正成为限制

对纯文本大语言模型推理来说，带宽常常被高估为瓶颈。一个 7B 模型流式输出，即便按每秒 50 个 token、每 token 约 2~4 字节算，单用户占用也就几百字节每秒，上千并发加起来也就几 MB/s，普通机房带宽绰绰有余。所以如果你的服务是"用户发一段文字、回一段文字"，带宽基本不是问题。

但有几类情况带宽会先到顶。其一是模型冷启动与自动扩缩容：新实例拉起时要从对象存储或镜像仓库下载数 GB 到数十 GB 的权重文件，如果走的是公网或限速的内部通道，这段时间会很长，直接影响扩容速度。其二是多模态/媒体类推理：用户上传高清图片、长音频、视频流，入口带宽会被直接打满，尤其是做实时音视频分析时，原始流本身就是大流量。其三是把推理服务当内部中台、被几十个上游业务高频调用时，即使单次 payload 小，聚合后的东西向流量也不可小觑。

所以带宽的优先级判断很清晰：文本推理单实例，带宽放最后考虑，只要不是极端并发都不用担心；但一旦涉及模型快速拉起、媒体上传、或做大并发网关，就要把出入口带宽和对象存储的内网吞吐一起规划，必要时走内网专线拉权重、用 CDN 分发静态资源。

系统盘与存储IO：被忽视的冷启动杀手

存储 IO 是另一块容易被轻视的资源，它主要影响"加载速度"和"冷启动体验"。模型权重要从磁盘读进显存，读盘快慢直接决定服务从启动到可服务的耗时。同样一个 26GB 的 13B FP16 权重，从 NVMe SSD（顺序读可达数 GB/s）加载可能只要几秒，从普通 SATA SSD（约 500MB/s）要几十秒，从网络块存储或机械盘则可能要按分钟计。

对做弹性伸缩的团队，这个差异会被放大：每次新实例拉起都重读一遍模型，IO 慢就意味着扩容响应慢、故障恢复慢、蓝绿发布慢。实务上建议把模型权重放在本地 NVMe 而不是依赖网络挂载盘，镜像里尽量预置常用模型，减少运行时下载；如果必须用对象存储，至少保证内网高带宽通道。另外，系统盘 IO 还影响容器镜像拉取、页面缓存和日志写入，长期高负载下慢盘会拖垮整体稳定性。

还有一个关联点：内存（RAM）和 IO 是搭档。如果内存足够，系统会把频繁读取的权重文件缓存进 page cache，二次加载就几乎不耗 IO；反之内存紧张时，缓存被回收，每次都重新读盘。所以"内存偏小 + 慢盘"的组合，会让推理服务的冷启动和重启体验非常糟糕，这一点在预算有限、拼命压配置时尤其容易踩坑。

单实例还是多实例：扩容的两条路径

当单实例扛不住时，扩容思路有两条。第一条是"纵向加单卡规格"：显存不够就换更大显存的卡，算力不够就换更高算力的卡。优点是不用改架构，部署简单；缺点是贵，且单卡总有物理上限，到 H100 这一档成本陡增。第二条是"横向加实例数"：保持单实例配置不变，前面加负载均衡，起多个相同实例分流。优点是弹性好、单点故障影响小、可以按流量增减；缺点是要有请求路由、要处理实例间状态（推理一般无状态，较易），并且每个实例都要各自加载一份模型，总显存占用是倍数关系。

对 7B/13B 级别、流量波动明显的服务，横向扩实例往往更经济：平时 1~2 个 L4 实例够用，晚高峰拉到 4~6 个，流量退去再缩回。这里又回到前面的资源判断——如果你扩了实例但 CPU 先到顶，那问题不在 GPU 数量，而在每实例的 CPU 配比或预处理架构。反过来，如果你扩了实例但显存一直闲置、GPU 利用率却上不来，那可能是负载均衡把请求打得太散，batch 攒不起来，连续批处理失效，需要调调度策略而不是继续加机器。

示例场景：一个中小团队在美西机房的实际配置思路

下面用一组假设案例来说明配置思路，注意这是虚构的示例，用于演示方法，不是真实客户部署。

假设场景一：一个十人左右的创业团队，在美西（洛杉矶/硅谷）机房准备上线一个对内对外的 7B 对话助手，预期日间稳定 30~50 并发、晚高峰偶尔到 150 并发，预算有限。按前面的公式，7B 在 INT4 下权重约 3.5GB、FP16 约 14GB。如果接受 INT4 量化、且用 vLLM 这类连续批处理框架，一张 24GB 的 L4 就能装下模型并留出 KV Cache 空间；此时瓶颈更可能在 CPU 预处理和晚高峰并发，所以机器应选"单 L4 + 至少 8 核 CPU + 32GB 内存 + 本地 NVMe"的配置，而非盲目上更大显卡。需要裸金属或美西本地机房资源的，也可以向一万网络这类提供 GPU 租用与机房托管的服务商询价，按机型拿包月报价再对比云上按需价。

假设场景二：同团队三个月后接入了 RAG 知识库，并要跑一个 13B 的摘要模型做后台批处理，并发峰值更高、且要求长上下文。这时 24GB 卡在 FP16 下会非常局促，更稳妥的起点是 48GB 的 L40S，配合 16 核以上 CPU、64GB 内存，把分词和批处理 worker 分开；模型权重放本地 NVMe，知识库检索走内网。这个阶段算力开始变得重要，因为摘要是批量任务、对吞吐敏感，L40S 三倍于 L4 的 FP16 算力能直接缩短作业时间。

这两个例子想说明的是：配置不是"选最贵的卡"，而是把显存、算力、CPU、IO、带宽按当前负载排序，先补最弱的一环。预算有限时，优先保证显存够装模型 + CPU 不拖后腿，往往比直接堆算力更划算。

成本怎么估：裸机GPU与云GPU的取舍

谈完技术，绕不开钱。推理服务的成本构成一般是：GPU 算力费用（占比最大）+ CPU/内存/磁盘等配套 + 带宽与流量 + 运维与停机风险。云 GPU 实例按小时或包月计费，弹性好、起步快、免运维，适合流量不稳定或试水阶段；裸金属 GPU 服务器（含美西等机房的独享物理机）通常是包月/包年，单价相对低、性能稳定不被邻居干扰，适合流量可预期、要长期跑的生产负载。

具体怎么选，没有放之四海皆准的答案，但有条经验：如果你的服务 7×24 满负荷跑、且机型固定，裸金属往往摊薄后更省；如果流量起伏大、要频繁扩缩，云的弹性更值钱。价格方面，不同云厂商、不同地域、不同计费模式（按需/Spot/预留）差异较大，公开渠道的小时单价也随促销和政策变动，因此本文不给出任何精确数字，实际金额请以各家官方实时报价为准，或向一万网络等服务商按具体机型与租期询价后再做测算。

成本估算的一个实用做法是"按每千次请求摊成本"：先压测出某机型在目标延迟下的每秒请求数（QPS），再把月度费用除以该 QPS 下的总请求数，得到单次推理的真实成本。这样比单纯比"哪张卡便宜"更有意义，因为一张贵但吞吐高三倍的卡，摊到每次请求上可能反而更省。别忘了把 CPU 配比不足导致的 GPU 闲置也计入隐性成本——你为闲置算力付了钱，却没用上。

常见配置误区与避坑清单

把高频踩坑点列出来，方便部署前自查。

误区一：显存只看"模型能加载"的下限。正确做法是权重 + 峰值 KV Cache + 余量，再倒推显存。

误区二：GPU 利用率低就立刻加算力。先确认是不是 CPU 分词/预处理、网络取数、或 batch 没攒起来导致的 GPU 空等，再加卡可能是白花钱。

误区三：CPU 核数只看"能启动服务"。高并发下分词、调度、后处理、RAG 检索都抢 CPU，建议按峰值全链路占用预留，必要时多进程 worker + CPU 绑核。

误区四：把模型权重放网络慢盘。冷启动和扩缩容会非常慢，优先本地 NVMe，并配合足够内存做 page cache。

误区五：带宽焦虑症。纯文本推理单实例带宽几乎不会是瓶颈，把带宽预算留给模型拉起、媒体上传和高并发网关更划算。

误区六：忽视框架对资源的放大效应。同一个模型，用支持 PagedAttention 和连续批处理的引擎，同等显存并发能力可能差出数倍，框架选型要和硬件一起评估。

结论：不同模型规模下的配置优先级

把上面的判断收成可执行的优先级，按模型规模和并发分情况给建议。

情形一：7B 级别、并发不高（百内）、预算紧。优先级是 显存够装（24GB 起步，INT4 可压到很小） > CPU 不拖后腿（8 核+/32GB） > 本地 NVMe 加载 > 算力（L4 级已够） > 带宽。此情形下堆算力收益最低。

情形二：13B 级别、要全精度或长上下文、中等并发。优先级是 显存（48GB 更稳） > 算力（L40S 级能显著提吞吐） > CPU（16 核+/64GB，预处理重的加更多） > IO > 带宽。此时算力和显存同等关键。

情形三：70B 级别或超高并发生产。优先级是 显存/多卡互联（80GB 卡或切分） > 算力与带宽（H100 级、NVLink） > CPU 配比 > IO。这种规模一般已超出"单实例省钱"的叙事，更应考量多实例或集群方案。

情形四：多模态/媒体推理。额外把 CPU 预处理能力和出入口带宽提到高位，能用 GPU 媒体引擎（NVDEC/NVENC）就尽量下沉，别让解码把 CPU 打满。

一句话总结配置哲学：先按模型规模和精度锁定显存下限，再按并发和延迟目标决定算力档位，全程盯着 CPU 和 IO 是否悄悄成为短板，最后才谈带宽。预算有限时，把第一笔钱花在"显存够 + CPU 不卡 + 本地快盘"这三件上，往往比直接上更大显卡更能解决真实卡顿。

FAQ：AI推理服务单实例部署常见问答

显存到底该选多大？7B和13B分别怎么估

显存估算有个直接可用的公式：权重显存 ≈ 参数量 × 每参数字节数，FP16 取 2 字节、INT8 取 1 字节、INT4 取 0.5 字节。按此，7B 模型 FP16 约 14GB、INT4 约 3.5GB；13B 模型 FP16 约 26GB、INT4 约 6.5GB。但这只是权重，真实运行还要叠加激活值和随并发、上下文长度增长的 KV Cache，后者可能再吃掉几 GB 到十几 GB。所以选卡时建议按"权重 + 峰值 KV Cache + 2~4GB 余量"倒推，而不是只看能加载的下限。对 7B，24GB 卡配 INT4 很宽裕；对 13B，想跑 FP16 多并发，48GB 的 L40S 比 24GB 卡从容太多，能少很多 OOM 烦恼。

CPU为什么在推理服务里反而成了瓶颈

因为推理不是 GPU 一个人的事，而是一条"CPU 接请求→分词/预处理→搬数据到 GPU→GPU 算→结果搬回→CPU 后处理输出"的链路，任一段慢了 GPU 就空等。CPU 最容易卡的地方有三个：一是分词（tokenization），高并发短请求洪流下分词本身变成并行计算量，小模型算得快时 CPU 反而喂不饱 GPU；二是请求调度与连续批处理的编排逻辑，多在进程/线程里跑，并发一高就抢核；三是多模态预处理，图像解码缩放、音频重采样都在 CPU 上且比文本重得多。云上单卡 GPU 实例常只配 4 个 vCPU，跑单个模型够，一旦叠加 RAG、重预处理、多服务混部就立刻不够分。所以 CPU 核数要按峰值全链路占用预留，而非"能启动就行"。

云GPU实例和裸金属GPU服务器怎么选

核心差别在弹性、成本和运维责任。云 GPU 实例按小时或包月计费，起步快、免运维、随时扩缩，适合流量不稳、试水阶段或波峰波谷明显的服务；裸金属 GPU 服务器是独享物理机，通常包月/包年，单价摊薄后更低、性能不被邻居干扰、延迟更稳定，适合 7×24 满负荷、机型固定的生产负载。实务上可这样判断：长期高负载优先裸金属更省，流量起伏大优先云的弹性更值。价格方面各家地域、计费模式（按需/Spot/预留）差异较大，公开小时单价也随促销变动，本文不列精确数字，实际请以官方实时报价为准或按机型向服务商询价，再做"每千次请求摊成本"的对比更靠谱。

出入口带宽到底要准备多少

对纯文本大语言模型推理，带宽几乎不会是单实例的瓶颈。一个 7B 模型流式输出，即便按每秒 50 token、每 token 几字节算，单用户占用仅数百字节每秒，上千并发也才几 MB/s，普通机房带宽足够。真正需要认真规划带宽的有三类：一是模型冷启动和自动扩缩容，新实例要从对象存储拉数 GB 到数十 GB 权重，公网或限速通道会让扩容很慢；二是多模态/媒体推理，用户上传高清图、长音频、视频流，入口带宽直接被打满；三是把推理当内部中台被几十个上游高频调用，聚合后的东西向流量也不可小觑。所以带宽优先级判断很清晰：文本单实例放最后，涉及模型快拉起、媒体上传或高并发网关时，再把出入口带宽和内网吞吐一并规划。

模型加载很慢、冷启动要几分钟怎么办

加载慢的根因基本在存储 IO 和网络。权重要从磁盘读进显存，速度取决于盘的类型：NVMe SSD 顺序读可达数 GB/s，普通 SATA SSD 约 500MB/s，网络块存储或机械盘可能按分钟计。同样的 26GB 权重，NVMe 几秒、慢盘几十秒甚至更久。解决办法有几条：把权重放本地 NVMe 而非网络挂载盘；镜像里预置常用模型减少运行时下载；保证足够内存让系统用 page cache 缓存频繁读取的权重，二次加载几乎不耗 IO；若必须用对象存储，走内网高带宽通道。另外容器镜像拉取、日志写入也吃 IO，长期高负载下慢盘会拖垮稳定性，所以"小内存+慢盘"组合要避开。

流量上来了该怎么扩容，加卡还是加实例

扩容有纵向和横向两条路。纵向是换更大显存或更高算力的单卡，部署简单但贵且有物理上限；横向是保持单实例配置、前面加负载均衡起多个相同实例分流，弹性好、单点故障影响小，但每个实例都要各自加载一份模型，总显存是倍数关系。对 7B/13B 这种流量波动明显的服务，横向扩实例往往更经济：平时 1~2 个 L4，晚高峰拉到 4~6 个，退潮再缩。这里要注意监控导向——如果扩了实例 CPU 先到顶，问题在每实例 CPU 配比而非 GPU 数；如果显存闲置但 GPU 利用率上不来，可能是负载均衡把请求打太散、batch 攒不起来，该调调度策略而不是继续加机器。扩容前先看监控定位短板，比盲目堆资源省钱得多。

7B和13B大概是什么配置能跑起来

给一组可直接参考的起步配置。7B 级别：若接受 INT4 量化并配合 vLLM 等连续批处理框架，单张 24GB 卡（如 L4）即可装下模型并留 KV Cache 空间，配套建议 8 核 CPU、32GB 内存、本地 NVMe；若坚持 FP16，则 24GB 卡偏紧，建议直接上 48GB 档。13B 级别：INT4 下单张 24GB 卡能跑但并发受限，FP16 多并发建议 48GB 的 L40S，配套 16 核 CPU、64GB 内存；若还要长上下文或 RAG，CPU 和内存还要再加。这里的关键不是"7B 用 L4、13B 用 L40S"这种机械对应，而是按"权重+KV Cache+余量"算显存、按并发和延迟定算力、按预处理负载定 CPU，三者各自独立判断后再组合。

推理成本到底怎么估才不冤枉花钱

最实在的估法是"按每次请求摊成本"，而不是比哪张卡单价低。步骤：先用压测得出某机型在目标延迟下的每秒请求数（QPS），再把月度总费用除以该 QPS 下的总请求数，得到单次推理真实成本。一张贵但吞吐高三倍的卡，摊到每次请求可能反而更省。费用构成上，GPU 算力一般占大头，其次是 CPU/内存/磁盘配套、带宽流量、运维与停机风险。云 GPU 弹性好但单价高，裸金属长期跑更省，选哪个看流量形态。注意把"CPU 配比不足导致 GPU 闲置"算作隐性成本——你为用不上的算力付了钱。各厂商地域、计费模式差异较大，精确金额请以官方实时报价为准，或按机型租期向服务商询价后再测算，别拿网络上的零散单价直接下定论。

来源：NVIDIA 官方 L4 产品规格页（GPU 显存 24GB、FP16/INT8 Tensor Core 算力、72W 功耗等参数，2026-11-08 访问）

来源：NVIDIA 官方 L40S 产品规格页（48GB GDDR6 ECC、FP16 733 TFLOPS、显存带宽 864GB/s 等参数，2026-11-08 访问）

来源：NVIDIA A100 Tensor Core GPU 数据手册（80GB HBM2e、FP16 624 TFLOPS 含稀疏、MIG 与 NVLink 带宽等，2026-11-08 访问）

来源：NVIDIA H100 产品规格页（80GB HBM3、FP16 1979 TFLOPS、NVLink 900GB/s 等参数，2026-11-08 访问）

来源：AWS EC2 加速计算实例类型官方文档（G5/G6/G6e/P4/P5 机型与 GPU 对应关系、网络带宽说明，2026-11-08 访问）

来源：Google Cloud 加速优化机型与定价文档（G2 L4、A2 A100、A3 H100 机型映射与计费说明，2026-11-08 访问）