很多团队第一次把 LLM 接进生产环境时预算表上通常只写了“一张显卡多少钱”。真正上线后才发现模型权重只是成本的一个角KV Cache、推理框架选型、并发扩容、接口限流、日志存储、GPU 空转每一项都在持续吃掉预算。这篇文章把 LLM 生产化过程中的真实成本拆开讲。不劝你买某块卡也不劝你无脑上云 API而是给出一套可以自己估算的维度模型参数量和精度决定权重显存上下文长度和并发决定 KV Cache推理框架决定吞吐上限再往下还有存储、带宽、运维和合规成本。如果你是做后端、做 AI 平台化或者正在给团队选型 LLM 推理方案这篇可以直接收藏。文末会给一个可按业务场景复制的成本评估模板。1. LLM 生产部署核心成本速览先看一张总表把成本分成固定和动态两类后面所有讨论都围绕这张表展开。成本维度性质主要构成可控性模型权重显存固定参数量、精度、模型架构高可通过量化降低KV Cache 显存动态上下文长度、并发数、层数中受业务上下文长度约束推理计算资源固定动态GPU、CPU、内存、带宽中框架优化空间大存储成本动态模型文件、日志、输入输出中需要压测和清理策略推理框架与运维持续节点部署、监控、故障恢复高框架选型影响明显数据合规与安全持续脱敏、审计、权限管理必须预算不能省这里有一个容易忽略的点权重显存是“一次性”的模型加载完就固定了KV Cache 才是随业务流量实时变化的。一个并发只有 10、上下文开到 32K 的服务KV Cache 就可能吃掉比模型权重还大的显存。后面第三节专门算这笔账。2. 模型选型参数量和精度是第一个成本锚点2.1 参数量的乘法效应参数量直接决定权重显存下限。以常见开源模型量级来看7B/8B 级别单卡可以尝试适合做垂直场景的底座。13B/14B 级别单卡高显存或双卡效果和成本相对平衡。32B/70B 级别基本进入多卡推理或强量化区间。百亿参数以上接近多节点部署范畴运维复杂度明显上升。这里说的“单卡可以尝试”只是权重层面。真正能不能跑还要看上下文长度、并发数、是否量化以及推理框架是否做了显存管理。下面给出不同参数量在不同精度下的权重显存估算表注意这是简化计算实际模型会因为 embedding、LM head、MoE 结构等差异略有浮动。精度字节/参数7B 权重13B 权重70B 权重FP32428GB52GB280GBFP16/BF16214GB26GB140GBINT817GB13GB70GBINT40.53.5GB6.5GB35GB这里最核心的结论是参数量每翻一倍权重显存就翻一倍精度从 FP16 降到 INT4权重显存能降到四分之一。所以量化是成本优化的第一手段而不是扩容。2.2 精度选择FP16、BF16、FP8、INT8、INT4生产环境里精度选择不是“越低越好”而是“质量还能接受的前提下尽量低”。FP16/BF16默认选项。质量损失最小但显存占用最高。要注意硬件支持差异BF16 在 A100、H100 等新卡上支持良好部分老卡只有 FP16 支持完整。FP8新一代硬件上的折中方案显存比 FP16 少一半质量损失相对可控。INT8显存收益明显推理速度通常也有提升但需要好的校准数据集。INT4显存最低消费级显卡跑大模型的常见方案。如果校准不当复杂任务上会明显掉点。从成本视角看精度每降一档等于用少量质量损失换一次硬件规模缩减。生产环境里必须做量化前后的效果对比不能只盯着显存数字。2.3 开源自建 vs 云 API这是生产选型里最容易算错账的地方。云 API 的成本是线性增长的按 token 付费调用量越大费用越高但省掉了 GPU 采购、运维、监控、故障恢复的人力成本。自建模型是固定成本卡买了或租了不管用不用都在花钱但调用量大之后单 token 边际成本会明显下降。所以核心问题不是“哪个更便宜”而是“你的模型利用率有多高”。如果一天只有几百次调用自建大概率不划算如果是日均千万 token 的稳定流量自建的性价比会逐渐体现。3. 显存成本权重只是入门KV Cache 才是大头3.1 显存里的三件套一个 LLM 推理服务在 GPU 上占用的显存大致由四块构成模型权重。KV Cache。激活值activation。框架临时 buffer 和 CUDA context。很多人只算了第一块结果服务启动后动不动 OOM就是因为忽略了 KV Cache。KV Cache 的大小和输入输出长度、并发数强相关而且是在服务运行中动态变化的。3.2 权重显存估算权重显存最简单def weight_memory_gb(params_b, bytes_per_param): return params_b * 1e9 * bytes_per_param / 1e97B 模型用 BF16大约 14GB70B 模型用 BF16大约 140GB。这个数值在选卡时可以直接用来做“权重下限”判断。3.3 KV Cache 估算KV Cache 的公式KV Cache 字节数 2K 和 V × 层数 × KV头维度 × 上下文长度 × 并发数 × 精度字节这里“2”是 K 和 V 各一份。注意很多模型用了 GQA/MQAKV 头数可能小于 Q 头数所以实际 KV Cache 会比“按所有头计算”更小。写成一个估算函数def kv_cache_memory_gb(layers, kv_head_dim, ctx_len, batch_size, bytes_per_param2): bytes_per_sequence 2 * layers * kv_head_dim * ctx_len * bytes_per_param return bytes_per_sequence * batch_size / 1e9以一个简化的 7B 模型为例假设 32 层、KV 头维度 128估算结果如下上下文长度batch1batch16batch642048约 33MB约 536MB约 2.1GB8192约 134MB约 2.1GB约 8.6GB32768约 536MB约 8.6GB约 34.4GB从这张表能直观看出为什么长上下文是成本放大器上下文长度翻 4 倍KV Cache 翻 4 倍并发翻 4 倍KV Cache 又翻 4 倍。两者同时增长显存压力是乘数级的。3.4 为什么长上下文和并发是成本放大器生产环境里业务侧经常提出“上下文越长越好”“并发越高越好”但每个需求最终都会换算成显存和 GPU 数量。上下文从 8K 提到 32KKV Cache 变成 4 倍。并发从 16 提到 64KV Cache 又变成 4 倍。前两项乘起来显存需求变成 16 倍。这就是为什么很多团队换了更大的模型后反而把上下文从 32K 降回 8K或者限制单实例并发。容量规划时建议留出至少 10% 到 20% 的显存余量给激活值和临时 buffer。4. 推理框架选型同样的卡吞吐能差几倍4.1 主流推理框架对比框架定位适合场景是否适合直接上生产vLLM高吞吐推理服务预置 API、高并发、多用户是TensorRT-LLMGPU 深度优化推理追求极致吞吐和低延迟是TGIHuggingFace 官方推理服务与 HF 生态集成是SGLang高性能结构化推理复杂采样、长上下文是llama.cpp单机/边缘推理小模型、CPU/GPU 混合小型服务可用Ollama本地开发体验开发机、原型验证一般不建议直接上生产框架选型不是“哪个火用哪个”。vLLM 的优势在于连续批处理和显存管理适合高并发在线服务TensorRT-LLM 优化更彻底但模型编译和部署链路更重适合固定模型长期运行llama.cpp 适合资源受限的边缘场景。4.2 连续批处理是关键传统推理服务按静态 batch 处理请求batch 里只要有一个请求生成长文本其他短请求也得等它结束GPU 利用率上不去。连续批处理Continuous Batching的思路是每个 token 生成完成后立刻把完成的请求移出 batch再补入新请求。这样短请求不会被长请求拖住GPU 利用率会明显提升。PagedAttention 这类显存管理机制则把 KV Cache 分成物理块管理减少显存碎片提高可用 batch 数。这就是为什么同一个模型vLLM 能同时服务更多请求显存占用却更稳定。4.3 用 vLLM 起一个 OpenAI 兼容服务下面是生产环境常见的一种启动方式以 vLLM 为例。注意路径、端口和模型名按实际环境修改python -m vllm.entrypoints.openai.api_server \ --model /data/models/llama-3-8b-instruct \ --tensor-parallel-size 1 \ --max-model-len 8192 \ --gpu-memory-utilization 0.9 \ --port 8000启动后可以用 curl 验证curl http://127.0.0.1:8000/v1/chat/completions \ -H Content-Type: application/json \ -d { model: /data/models/llama-3-8b-instruct, messages: [{role: user, content: 用一句话解释 KV Cache}], max_tokens: 128 }返回 JSON 里的choices数组就是模型输出。这个接口是 OpenAI 兼容格式很多现有代码可以少改甚至不改就接进来。4.4 框架选型的隐性成本框架本身的切换成本经常被低估。换一个推理框架往往意味着模型格式可能要从 HuggingFace 格式转 TensorRT Engine。服务化代码要改动超时、流式、错误码逻辑都不同。监控指标要重新适配比如 vLLM 暴露的指标和 TensorRT-LLM 不同。团队要重新积累故障排查经验。我的建议是小流量阶段就固定一个主推框架压测通过后不要频繁换。框架调优带来的吞吐收益通常远大于“再换一个试试”的短期快感。5. 自建推理 vs 云 API按真实负载算账5.1 云 API 侧成本云 API 按 token 计费公式很简单单月 token 消耗 QPS × 每次请求平均 token 数 × 月秒数 API 成本 单月 token 消耗 / 100万 × 每百万 token 单价写成一个估算函数def estimate_api_cost(days, qps, tokens_per_req, price_per_million_tokens): secs_per_month days * 24 * 3600 total_tokens qps * tokens_per_req * secs_per_month cost total_tokens / 1_000_000 * price_per_million_tokens return total_tokens, cost云 API 还隐藏了两个问题一是 rate limit业务突发流量会被限流二是长上下文调用价格远高于短文本因为模型计费通常按输入和输出 token 合计。生产环境建议把输入缓存、Prompt 压缩做起来否则同样的任务量费用可能差出好几倍。5.2 自建侧成本自建不是只有 GPU 费用完整账单包括GPU 实例月租或一次性采购摊销。CPU 内存、系统盘、数据盘。公网带宽或内网流量费。日志存储、监控系统、对象存储。运维人力包括模型更新、框架升级、故障恢复。估算模板def estimate_self_hosted_cost(gpu_instances, price_per_instance_month, storage_gb, price_per_gb_month, ops_cost0): return gpu_instances * price_per_instance_month storage_gb * price_per_gb_month ops_cost这里不写死云厂商具体价格因为实例定价和带宽费用变化很快而且不同区域差异很大。实际评估时把所在云厂商的报价填进去就行。5.3 自建更划算的几个典型条件月调用 token 量很高且趋势稳定。延迟敏感云 API 的网络开销和排队时间不可接受。数据不能出企业内网必须私有化部署。原本就有 GPU 资源或长期闲置算力池。反过来如果是新产品验证阶段、调用量波动大、团队没有 GPU 运维经验先用云 API 跑通业务逻辑反而更省钱。等到月成本稳定了再决定要不要自建。6. 批量任务的成本与并发控制6.1 典型离线批量场景LLM 生产化里大量工作其实是离线批量任务批量摘要、批量文本分类、批量翻译、批量结构化抽取。这类任务的特点是量大、无实时要求、需要稳定吞吐。批量任务最容易踩的坑是同步 for 循环调用 API一个请求超时就把整个任务拖住。正确做法是异步并发控制限制最大并发数失败有限次重试记录成功 ID 以便断点续跑。6.2 并发控制示例import asyncio import aiohttp async def process_item(sem, session, item): async with sem: payload { model: your-model-name, messages: [{role: user, content: item[text]}], max_tokens: 512, } async with session.post(http://127.0.0.1:8000/v1/chat/completions, jsonpayload, timeoutaiohttp.ClientTimeout(total120)) as resp: data await resp.json() return item[id], data[choices][0][message][content] async def run_batch(items, concurrency8): sem asyncio.Semaphore(concurrency) async with aiohttp.ClientSession() as session: tasks [process_item(sem, session, item) for item in items] results await asyncio.gather(*tasks, return_exceptionsTrue) return resultsconcurrency的取值要按 GPU 显存和模型并发能力压测得出。并发设得太大会让服务端 OOM 或延迟飙升设得太小GPU 利用率上不去。批量任务阶段应该专门做一次“并发-延迟-成功率”三点测试。6.3 Prompt 前缀复用很多批量任务有固定前缀比如系统提示词、用户指令模板。如果推理框架支持 Prefix Caching相同前缀的 KV Cache 可以复用能明显降低计算成本。对于不支持前缀缓存的框架可以在 Prompt 层面压缩把固定指令模板精简减少重复 token。大批量任务里每省一个 token 都是钱。6.4 失败重试与幂等批量任务必须设计重试网络超时指数退避重试重试次数不要超过 3 次。服务端限流等一段时间后重试。模型输出格式异常不要盲目重试先检查是不是 Prompt 本身的问题。已完成任务要记录防止进程崩溃后重复处理。批量任务的稳定性往往比单次延迟更有价值。7. 生产环境部署与运维成本7.1 基础设施与版本管理生产环境建议把 LLM 服务容器化用 Docker 或 Kubernetes 管理。重点是把 CUDA、PyTorch、推理框架版本固定下来不要随便升级。GPU 驱动和 CUDA 版本不一致是常见的启动失败原因。模型文件建议单独放对象存储或模型仓库启动时按版本拉取而不是每次都重新上传几百 GB 文件。加载模型很慢时先检查磁盘 IO 和网络带宽。7.2 必须盯住的五个指标指标含义关注原因TTFT首 token 延迟用户等待体感TPOT生成每个 token 的耗时输出速度TGS每秒生成 token 数系统吞吐QPS每秒成功请求数容量评估GPU 利用率GPU 计算资源使用率成本有效性TTFT 偏高通常说明排队或前缀匹配慢TGS 偏低说明 batch 数不够或模型较大GPU 利用率和吞吐不成正比时要考虑框架 overhead 和显存瓶颈。7.3 容易忽略的成本陷阱GPU 空转请求量波动大但 GPU 一直满规格运行。冷热流量明显时不如用弹性伸缩或混部。日志膨胀每个请求都打完整输入输出日志收集和存储费用会非常夸张。建议只记录关键元信息和采样率。冷启动恢复模型加载几十秒甚至几分钟扩容节点时服务恢复慢。有容灾要求的服务需要长期保留热备节点。多模型重复加载一个服务同时挂多个模型每个模型占一份显存。要按业务优先级控制同时加载的模型数量。8. 常见问题与排查方法问题现象可能原因排查方式解决方案启动后直接 OOM模型权重、KV Cache、buffer 总和超显存看启动日志和nvidia-smi显存占用降低并发、缩短 max-model-len、量化模型模型加载特别慢磁盘 IO 或网络带宽瓶颈观察加载耗时和磁盘速率模型放本地 SSD或预热模型缓存并发一高 TTFT 就涨请求排队、Prefix Cache 未命中看服务端队列长度和 GPU 利用率增加副本、优化 batch 策略、做负载均衡量化后效果明显变差校准集不合适或量化粒度太粗对比量化前后同一批测试用例换量化方法或回到更高精度API 调用频繁超时客户端超时设置过短或服务端排队看服务端指标和客户端错误码超时设为 120 秒以上增加重试GPU 利用率低但吞吐不高小 batch 或 CPU 与 GPU 传输瓶颈看 batch 大小和 TGS 指标开启连续批处理增大并发请求多卡负载不均衡张量并行配置或请求偏差看每张卡利用率调整并行策略均匀分发请求排查顺序建议是先看日志再看指标最后才动配置。不要一遇到 OOM 就调低并发先判断是权重问题还是 KV Cache 问题。9. 一套可执行的成本评估流程9.1 小流量压测模板正式采购或上云之前先做一个小规模压测选定 1 到 2 个代表模型确定精度和上下文长度。用推理框架启动单副本服务。固定一个典型 Prompt 长度逐步提高并发。记录 TTFT、TGS、GPU 显存、QPS、错误率。找到“显存刚好够用且错误率低”的并发上限。用这个上限反推需要几个副本。9.2 月度成本模板def monthly_cost_report(qps, tokens_per_req, days30, gpu_instance_price0, extra_cost0): total_tokens qps * tokens_per_req * days * 24 * 3600 gpu_cost gpu_instance_price * days * 24 return { total_tokens_month: total_tokens, gpu_runtime_cost: gpu_cost, extra_cost: extra_cost, suggested_budget: gpu_cost extra_cost }压测得到的 QPS 上限决定了你需要多少个 GPU 实例副本。QPS 翻倍副本数可能翻倍KV Cache 和带宽也会翻倍。建议把这份报告按月留存用来观察调用量增长和成本增长是否匹配。9.3 优化优先级通常按这个顺序做成本优化第一次优化量化模型精度。第二次优化压缩 Prompt 长度开启前缀缓存。第三次优化调整并发和 batch 策略提高 GPU 利用率。第四次优化做模型路由简单请求走小模型。前两步通常能在不换硬件的情况下省下最多成本。动辄扩容反而是最贵的选择。10. 最佳实践与合规边界最后给几条工程化建议。第一第一次部署先用最小配置跑通小模型加低并发把指标监控和服务日志搭起来再逐步放大。第二模型文件、输入素材、输出结果分目录管理生产环境要控制访问权限防止敏感数据外泄。第三批量任务要加日志和失败重试避免一条坏数据拖垮整个队列。第四涉及人脸、声音、版权素材、个人数据时必须确认授权和合规边界不能只考虑技术成本。LLM 生产化的真实成本不是买一张显卡那么简单。模型选型、精度、上下文长度、并发、推理框架、批量任务、运维监控每一个环节都在影响最终账单。最值得做的事是先跑通一套小模型加量化的最小系统用压测数据算清楚单 token 成本再做扩容或上云的决策。这样每一步花钱都有据可依。 LLM生产部署成本拆解：从KV Cache到推理框架的完整估算指南
很多团队第一次把 LLM 接进生产环境时预算表上通常只写了“一张显卡多少钱”。真正上线后才发现模型权重只是成本的一个角KV Cache、推理框架选型、并发扩容、接口限流、日志存储、GPU 空转每一项都在持续吃掉预算。这篇文章把 LLM 生产化过程中的真实成本拆开讲。不劝你买某块卡也不劝你无脑上云 API而是给出一套可以自己估算的维度模型参数量和精度决定权重显存上下文长度和并发决定 KV Cache推理框架决定吞吐上限再往下还有存储、带宽、运维和合规成本。如果你是做后端、做 AI 平台化或者正在给团队选型 LLM 推理方案这篇可以直接收藏。文末会给一个可按业务场景复制的成本评估模板。1. LLM 生产部署核心成本速览先看一张总表把成本分成固定和动态两类后面所有讨论都围绕这张表展开。成本维度性质主要构成可控性模型权重显存固定参数量、精度、模型架构高可通过量化降低KV Cache 显存动态上下文长度、并发数、层数中受业务上下文长度约束推理计算资源固定动态GPU、CPU、内存、带宽中框架优化空间大存储成本动态模型文件、日志、输入输出中需要压测和清理策略推理框架与运维持续节点部署、监控、故障恢复高框架选型影响明显数据合规与安全持续脱敏、审计、权限管理必须预算不能省这里有一个容易忽略的点权重显存是“一次性”的模型加载完就固定了KV Cache 才是随业务流量实时变化的。一个并发只有 10、上下文开到 32K 的服务KV Cache 就可能吃掉比模型权重还大的显存。后面第三节专门算这笔账。2. 模型选型参数量和精度是第一个成本锚点2.1 参数量的乘法效应参数量直接决定权重显存下限。以常见开源模型量级来看7B/8B 级别单卡可以尝试适合做垂直场景的底座。13B/14B 级别单卡高显存或双卡效果和成本相对平衡。32B/70B 级别基本进入多卡推理或强量化区间。百亿参数以上接近多节点部署范畴运维复杂度明显上升。这里说的“单卡可以尝试”只是权重层面。真正能不能跑还要看上下文长度、并发数、是否量化以及推理框架是否做了显存管理。下面给出不同参数量在不同精度下的权重显存估算表注意这是简化计算实际模型会因为 embedding、LM head、MoE 结构等差异略有浮动。精度字节/参数7B 权重13B 权重70B 权重FP32428GB52GB280GBFP16/BF16214GB26GB140GBINT817GB13GB70GBINT40.53.5GB6.5GB35GB这里最核心的结论是参数量每翻一倍权重显存就翻一倍精度从 FP16 降到 INT4权重显存能降到四分之一。所以量化是成本优化的第一手段而不是扩容。2.2 精度选择FP16、BF16、FP8、INT8、INT4生产环境里精度选择不是“越低越好”而是“质量还能接受的前提下尽量低”。FP16/BF16默认选项。质量损失最小但显存占用最高。要注意硬件支持差异BF16 在 A100、H100 等新卡上支持良好部分老卡只有 FP16 支持完整。FP8新一代硬件上的折中方案显存比 FP16 少一半质量损失相对可控。INT8显存收益明显推理速度通常也有提升但需要好的校准数据集。INT4显存最低消费级显卡跑大模型的常见方案。如果校准不当复杂任务上会明显掉点。从成本视角看精度每降一档等于用少量质量损失换一次硬件规模缩减。生产环境里必须做量化前后的效果对比不能只盯着显存数字。2.3 开源自建 vs 云 API这是生产选型里最容易算错账的地方。云 API 的成本是线性增长的按 token 付费调用量越大费用越高但省掉了 GPU 采购、运维、监控、故障恢复的人力成本。自建模型是固定成本卡买了或租了不管用不用都在花钱但调用量大之后单 token 边际成本会明显下降。所以核心问题不是“哪个更便宜”而是“你的模型利用率有多高”。如果一天只有几百次调用自建大概率不划算如果是日均千万 token 的稳定流量自建的性价比会逐渐体现。3. 显存成本权重只是入门KV Cache 才是大头3.1 显存里的三件套一个 LLM 推理服务在 GPU 上占用的显存大致由四块构成模型权重。KV Cache。激活值activation。框架临时 buffer 和 CUDA context。很多人只算了第一块结果服务启动后动不动 OOM就是因为忽略了 KV Cache。KV Cache 的大小和输入输出长度、并发数强相关而且是在服务运行中动态变化的。3.2 权重显存估算权重显存最简单def weight_memory_gb(params_b, bytes_per_param): return params_b * 1e9 * bytes_per_param / 1e97B 模型用 BF16大约 14GB70B 模型用 BF16大约 140GB。这个数值在选卡时可以直接用来做“权重下限”判断。3.3 KV Cache 估算KV Cache 的公式KV Cache 字节数 2K 和 V × 层数 × KV头维度 × 上下文长度 × 并发数 × 精度字节这里“2”是 K 和 V 各一份。注意很多模型用了 GQA/MQAKV 头数可能小于 Q 头数所以实际 KV Cache 会比“按所有头计算”更小。写成一个估算函数def kv_cache_memory_gb(layers, kv_head_dim, ctx_len, batch_size, bytes_per_param2): bytes_per_sequence 2 * layers * kv_head_dim * ctx_len * bytes_per_param return bytes_per_sequence * batch_size / 1e9以一个简化的 7B 模型为例假设 32 层、KV 头维度 128估算结果如下上下文长度batch1batch16batch642048约 33MB约 536MB约 2.1GB8192约 134MB约 2.1GB约 8.6GB32768约 536MB约 8.6GB约 34.4GB从这张表能直观看出为什么长上下文是成本放大器上下文长度翻 4 倍KV Cache 翻 4 倍并发翻 4 倍KV Cache 又翻 4 倍。两者同时增长显存压力是乘数级的。3.4 为什么长上下文和并发是成本放大器生产环境里业务侧经常提出“上下文越长越好”“并发越高越好”但每个需求最终都会换算成显存和 GPU 数量。上下文从 8K 提到 32KKV Cache 变成 4 倍。并发从 16 提到 64KV Cache 又变成 4 倍。前两项乘起来显存需求变成 16 倍。这就是为什么很多团队换了更大的模型后反而把上下文从 32K 降回 8K或者限制单实例并发。容量规划时建议留出至少 10% 到 20% 的显存余量给激活值和临时 buffer。4. 推理框架选型同样的卡吞吐能差几倍4.1 主流推理框架对比框架定位适合场景是否适合直接上生产vLLM高吞吐推理服务预置 API、高并发、多用户是TensorRT-LLMGPU 深度优化推理追求极致吞吐和低延迟是TGIHuggingFace 官方推理服务与 HF 生态集成是SGLang高性能结构化推理复杂采样、长上下文是llama.cpp单机/边缘推理小模型、CPU/GPU 混合小型服务可用Ollama本地开发体验开发机、原型验证一般不建议直接上生产框架选型不是“哪个火用哪个”。vLLM 的优势在于连续批处理和显存管理适合高并发在线服务TensorRT-LLM 优化更彻底但模型编译和部署链路更重适合固定模型长期运行llama.cpp 适合资源受限的边缘场景。4.2 连续批处理是关键传统推理服务按静态 batch 处理请求batch 里只要有一个请求生成长文本其他短请求也得等它结束GPU 利用率上不去。连续批处理Continuous Batching的思路是每个 token 生成完成后立刻把完成的请求移出 batch再补入新请求。这样短请求不会被长请求拖住GPU 利用率会明显提升。PagedAttention 这类显存管理机制则把 KV Cache 分成物理块管理减少显存碎片提高可用 batch 数。这就是为什么同一个模型vLLM 能同时服务更多请求显存占用却更稳定。4.3 用 vLLM 起一个 OpenAI 兼容服务下面是生产环境常见的一种启动方式以 vLLM 为例。注意路径、端口和模型名按实际环境修改python -m vllm.entrypoints.openai.api_server \ --model /data/models/llama-3-8b-instruct \ --tensor-parallel-size 1 \ --max-model-len 8192 \ --gpu-memory-utilization 0.9 \ --port 8000启动后可以用 curl 验证curl http://127.0.0.1:8000/v1/chat/completions \ -H Content-Type: application/json \ -d { model: /data/models/llama-3-8b-instruct, messages: [{role: user, content: 用一句话解释 KV Cache}], max_tokens: 128 }返回 JSON 里的choices数组就是模型输出。这个接口是 OpenAI 兼容格式很多现有代码可以少改甚至不改就接进来。4.4 框架选型的隐性成本框架本身的切换成本经常被低估。换一个推理框架往往意味着模型格式可能要从 HuggingFace 格式转 TensorRT Engine。服务化代码要改动超时、流式、错误码逻辑都不同。监控指标要重新适配比如 vLLM 暴露的指标和 TensorRT-LLM 不同。团队要重新积累故障排查经验。我的建议是小流量阶段就固定一个主推框架压测通过后不要频繁换。框架调优带来的吞吐收益通常远大于“再换一个试试”的短期快感。5. 自建推理 vs 云 API按真实负载算账5.1 云 API 侧成本云 API 按 token 计费公式很简单单月 token 消耗 QPS × 每次请求平均 token 数 × 月秒数 API 成本 单月 token 消耗 / 100万 × 每百万 token 单价写成一个估算函数def estimate_api_cost(days, qps, tokens_per_req, price_per_million_tokens): secs_per_month days * 24 * 3600 total_tokens qps * tokens_per_req * secs_per_month cost total_tokens / 1_000_000 * price_per_million_tokens return total_tokens, cost云 API 还隐藏了两个问题一是 rate limit业务突发流量会被限流二是长上下文调用价格远高于短文本因为模型计费通常按输入和输出 token 合计。生产环境建议把输入缓存、Prompt 压缩做起来否则同样的任务量费用可能差出好几倍。5.2 自建侧成本自建不是只有 GPU 费用完整账单包括GPU 实例月租或一次性采购摊销。CPU 内存、系统盘、数据盘。公网带宽或内网流量费。日志存储、监控系统、对象存储。运维人力包括模型更新、框架升级、故障恢复。估算模板def estimate_self_hosted_cost(gpu_instances, price_per_instance_month, storage_gb, price_per_gb_month, ops_cost0): return gpu_instances * price_per_instance_month storage_gb * price_per_gb_month ops_cost这里不写死云厂商具体价格因为实例定价和带宽费用变化很快而且不同区域差异很大。实际评估时把所在云厂商的报价填进去就行。5.3 自建更划算的几个典型条件月调用 token 量很高且趋势稳定。延迟敏感云 API 的网络开销和排队时间不可接受。数据不能出企业内网必须私有化部署。原本就有 GPU 资源或长期闲置算力池。反过来如果是新产品验证阶段、调用量波动大、团队没有 GPU 运维经验先用云 API 跑通业务逻辑反而更省钱。等到月成本稳定了再决定要不要自建。6. 批量任务的成本与并发控制6.1 典型离线批量场景LLM 生产化里大量工作其实是离线批量任务批量摘要、批量文本分类、批量翻译、批量结构化抽取。这类任务的特点是量大、无实时要求、需要稳定吞吐。批量任务最容易踩的坑是同步 for 循环调用 API一个请求超时就把整个任务拖住。正确做法是异步并发控制限制最大并发数失败有限次重试记录成功 ID 以便断点续跑。6.2 并发控制示例import asyncio import aiohttp async def process_item(sem, session, item): async with sem: payload { model: your-model-name, messages: [{role: user, content: item[text]}], max_tokens: 512, } async with session.post(http://127.0.0.1:8000/v1/chat/completions, jsonpayload, timeoutaiohttp.ClientTimeout(total120)) as resp: data await resp.json() return item[id], data[choices][0][message][content] async def run_batch(items, concurrency8): sem asyncio.Semaphore(concurrency) async with aiohttp.ClientSession() as session: tasks [process_item(sem, session, item) for item in items] results await asyncio.gather(*tasks, return_exceptionsTrue) return resultsconcurrency的取值要按 GPU 显存和模型并发能力压测得出。并发设得太大会让服务端 OOM 或延迟飙升设得太小GPU 利用率上不去。批量任务阶段应该专门做一次“并发-延迟-成功率”三点测试。6.3 Prompt 前缀复用很多批量任务有固定前缀比如系统提示词、用户指令模板。如果推理框架支持 Prefix Caching相同前缀的 KV Cache 可以复用能明显降低计算成本。对于不支持前缀缓存的框架可以在 Prompt 层面压缩把固定指令模板精简减少重复 token。大批量任务里每省一个 token 都是钱。6.4 失败重试与幂等批量任务必须设计重试网络超时指数退避重试重试次数不要超过 3 次。服务端限流等一段时间后重试。模型输出格式异常不要盲目重试先检查是不是 Prompt 本身的问题。已完成任务要记录防止进程崩溃后重复处理。批量任务的稳定性往往比单次延迟更有价值。7. 生产环境部署与运维成本7.1 基础设施与版本管理生产环境建议把 LLM 服务容器化用 Docker 或 Kubernetes 管理。重点是把 CUDA、PyTorch、推理框架版本固定下来不要随便升级。GPU 驱动和 CUDA 版本不一致是常见的启动失败原因。模型文件建议单独放对象存储或模型仓库启动时按版本拉取而不是每次都重新上传几百 GB 文件。加载模型很慢时先检查磁盘 IO 和网络带宽。7.2 必须盯住的五个指标指标含义关注原因TTFT首 token 延迟用户等待体感TPOT生成每个 token 的耗时输出速度TGS每秒生成 token 数系统吞吐QPS每秒成功请求数容量评估GPU 利用率GPU 计算资源使用率成本有效性TTFT 偏高通常说明排队或前缀匹配慢TGS 偏低说明 batch 数不够或模型较大GPU 利用率和吞吐不成正比时要考虑框架 overhead 和显存瓶颈。7.3 容易忽略的成本陷阱GPU 空转请求量波动大但 GPU 一直满规格运行。冷热流量明显时不如用弹性伸缩或混部。日志膨胀每个请求都打完整输入输出日志收集和存储费用会非常夸张。建议只记录关键元信息和采样率。冷启动恢复模型加载几十秒甚至几分钟扩容节点时服务恢复慢。有容灾要求的服务需要长期保留热备节点。多模型重复加载一个服务同时挂多个模型每个模型占一份显存。要按业务优先级控制同时加载的模型数量。8. 常见问题与排查方法问题现象可能原因排查方式解决方案启动后直接 OOM模型权重、KV Cache、buffer 总和超显存看启动日志和nvidia-smi显存占用降低并发、缩短 max-model-len、量化模型模型加载特别慢磁盘 IO 或网络带宽瓶颈观察加载耗时和磁盘速率模型放本地 SSD或预热模型缓存并发一高 TTFT 就涨请求排队、Prefix Cache 未命中看服务端队列长度和 GPU 利用率增加副本、优化 batch 策略、做负载均衡量化后效果明显变差校准集不合适或量化粒度太粗对比量化前后同一批测试用例换量化方法或回到更高精度API 调用频繁超时客户端超时设置过短或服务端排队看服务端指标和客户端错误码超时设为 120 秒以上增加重试GPU 利用率低但吞吐不高小 batch 或 CPU 与 GPU 传输瓶颈看 batch 大小和 TGS 指标开启连续批处理增大并发请求多卡负载不均衡张量并行配置或请求偏差看每张卡利用率调整并行策略均匀分发请求排查顺序建议是先看日志再看指标最后才动配置。不要一遇到 OOM 就调低并发先判断是权重问题还是 KV Cache 问题。9. 一套可执行的成本评估流程9.1 小流量压测模板正式采购或上云之前先做一个小规模压测选定 1 到 2 个代表模型确定精度和上下文长度。用推理框架启动单副本服务。固定一个典型 Prompt 长度逐步提高并发。记录 TTFT、TGS、GPU 显存、QPS、错误率。找到“显存刚好够用且错误率低”的并发上限。用这个上限反推需要几个副本。9.2 月度成本模板def monthly_cost_report(qps, tokens_per_req, days30, gpu_instance_price0, extra_cost0): total_tokens qps * tokens_per_req * days * 24 * 3600 gpu_cost gpu_instance_price * days * 24 return { total_tokens_month: total_tokens, gpu_runtime_cost: gpu_cost, extra_cost: extra_cost, suggested_budget: gpu_cost extra_cost }压测得到的 QPS 上限决定了你需要多少个 GPU 实例副本。QPS 翻倍副本数可能翻倍KV Cache 和带宽也会翻倍。建议把这份报告按月留存用来观察调用量增长和成本增长是否匹配。9.3 优化优先级通常按这个顺序做成本优化第一次优化量化模型精度。第二次优化压缩 Prompt 长度开启前缀缓存。第三次优化调整并发和 batch 策略提高 GPU 利用率。第四次优化做模型路由简单请求走小模型。前两步通常能在不换硬件的情况下省下最多成本。动辄扩容反而是最贵的选择。10. 最佳实践与合规边界最后给几条工程化建议。第一第一次部署先用最小配置跑通小模型加低并发把指标监控和服务日志搭起来再逐步放大。第二模型文件、输入素材、输出结果分目录管理生产环境要控制访问权限防止敏感数据外泄。第三批量任务要加日志和失败重试避免一条坏数据拖垮整个队列。第四涉及人脸、声音、版权素材、个人数据时必须确认授权和合规边界不能只考虑技术成本。LLM 生产化的真实成本不是买一张显卡那么简单。模型选型、精度、上下文长度、并发、推理框架、批量任务、运维监控每一个环节都在影响最终账单。最值得做的事是先跑通一套小模型加量化的最小系统用压测数据算清楚单 token 成本再做扩容或上云的决策。这样每一步花钱都有据可依。