这篇文章用 localaihub.com 社区经验帖的方式写，尽量讲人话，也尽量把账算实。这里不会给一个“所有人通用”的价格表，因为 2026 年 GPU 云价格变化快，供应也不稳定。更有价值的是学会拆账：显存账、吞吐账、延迟账、量化账、工程账、运维账、风险账。只看 GPU 小时单价，最后通常会低估成本；只看模型 benchmark，最后通常会高估线上体验。

本文资料检索截至 2026 年 5 月，参考了 AWS、Google Cloud、Azure、Lambda 等 GPU 资源文档或价格页，vLLM、TensorRT-LLM、TGI、SGLang、Triton、KServe、llama.cpp、Hugging Face bitsandbytes 等项目文档，以及 PagedAttention、QLoRA、Llama 3、DeepSeek-R1 等论文或技术报告。价格和规格请以上线时官方页面为准，本文重点是成本模型和决策方法。

一、先说结论：大模型部署成本不是显卡价格，而是“单位有效回答”的成本

如果一个服务每月租 GPU 花 3 万元，但只服务内部 20 个测试用户，单位有效回答成本就很高。如果同样 3 万元支撑 5 万个高价值业务请求，且减少了人工处理时间，它可能很划算。大模型部署不能只看“每小时多少钱”，要看“每个能被用户接受的结果多少钱”。

单位有效回答成本至少包含这些部分：GPU 计算成本、CPU 和内存成本、本地盘或对象存储成本、镜像和模型分发成本、公网流量成本、日志和监控成本、工程人力成本、值班和故障成本、评测和标注成本、安全合规成本、空闲冗余成本。自建机房还要加电力、制冷、机柜、网络、硬件折旧、备件、维修和采购周期。云上还要考虑可用区价格、容量抢占、保留实例、spot 中断、跨区流量和供应不足。

更实际的公式是：

月成本 = 固定资源成本 + 弹性资源成本 + 存储与网络成本 + 运维人力成本 + 质量治理成本 + 风险冗余成本

单位有效回答成本 = 月成本 / 通过质量标准且成功交付的回答数

“成功交付”这几个字很关键。模型超时、输出格式错、答非所问、引用错、用户重试三次才满意，都不能按一次完美回答算。很多部署账本看起来便宜，是因为只算了 tokens/s，没有算失败和重试。

二、显存账：权重、KV cache、并发和上下文一起算

大模型部署第一笔账是显存。显存里至少有权重、KV cache、运行时 buffer、CUDA graph 或 kernel workspace、临时张量、碎片和框架开销。权重大小容易估，KV cache 容易被忽略。

权重粗算方法很简单：参数量乘以每个参数字节数。FP16/BF16 大约 2 字节，INT8 大约 1 字节，INT4 大约 0.5 字节，FP8 大约 1 字节。一个 7B 模型 FP16 权重大约 14GB，一个 70B 模型 FP16 权重大约 140GB。实际加载还会有额外开销，所以不能把卡上标称显存全部当可用空间。

但是在线推理不是只放权重。生成式模型为了避免每生成一个 token 都重新计算整个上下文，会保存每层 attention 的 key 和 value，也就是 KV cache。KV cache 随着并发序列数和上下文长度线性增长。你把最大上下文从 8K 开到 32K，把并发从 16 开到 64，显存压力会明显放大。很多团队刚启动模型时没问题，一上真实并发就 OOM，原因往往不是权重放不下，而是 KV cache 被低估。

一个实用判断是：小模型高并发时，KV cache 可能比你想象中更早成为瓶颈；大模型长上下文时，权重和 KV cache 会一起压垮显存。部署参数里的 max_model_len、max_num_seqs、max_num_batched_tokens、gpu_memory_utilization 不是随便填的，它们决定服务端愿意为多少上下文和并发预留空间。

vLLM 的 PagedAttention、TensorRT-LLM 的 paged KV cache、SGLang 的 prefix caching 和 RadixAttention，都在解决 KV cache 管理问题。它们可以提高显存利用率，减少碎片，提升吞吐，但不能违反物理上限。如果业务真的需要 128K 上下文和高并发，就要准备更多 GPU、KV cache offload、上下文压缩、分层路由或异步处理，而不是期待一个参数开关解决。

社区里常见的错误是用“模型文件大小”估算部署成本。例如看到某个 70B INT4 文件只有 40GB 左右，就以为一张 48GB 卡能稳定支撑生产流量。单用户低并发也许能跑，但生产服务还要保留 KV cache、batch、runtime 开销和安全余量。显存占用长期超过 90% 时，线上风险会显著增加：小流量波动、长 prompt、异常重试、并发尖峰都可能触发 OOM。

三、吞吐账：tokens/s 要拆成输入、输出和请求分布

吞吐不是一个数字。大模型服务至少有两种吞吐：prefill 吞吐和 decode 吞吐。Prefill 处理输入 prompt，适合并行；decode 逐 token 生成，更受内存带宽、KV cache 和 batch 调度影响。一个服务“每秒 5000 tokens”到底是输入 token、输出 token，还是混合 token？是在离线固定 batch 下测的，还是在线随机请求下测的？这些差别很大。

真实业务请求分布通常长这样：大量短问答，少量长文档；大量输出 200 token 以内的请求，少量输出几千 token 的报告；白天有突发，夜间低峰；某些用户会连续追问，某些任务会同时触发检索和工具调用。平均值会掩盖问题。你要看 p50、p95、p99 的输入长度、输出长度、并发和延迟。

算吞吐账时，可以先做一个简单容量模型。

假设一天 100,000 次请求，平均输入 1,000 token，平均输出 500 token，那么每天处理 100,000,000 输入 token 和 50,000,000 输出 token。输出 token 通常更贵，因为 decode 是逐步生成。再假设流量集中在 10 小时内，峰值小时是平均小时的 3 倍，那么峰值小时可能要处理 30,000 次请求，也就是 30,000,000 输入 token 和 15,000,000 输出 token。再考虑 p95 延迟目标，你不能让所有请求排队慢慢处理，必须留冗余。

吞吐账不能只算“总 token 除以 tokens/s”。在线服务有排队，有 batch 组装等待，有长短请求互相影响，有用户取消，有网关超时，有模型实例重启。动态 batching 可以提高 GPU 利用率，但 batch 等待时间过长会伤害首 token 延迟。连续 batching 比静态 batch 更适合 LLM 在线服务，因为请求可以流式加入和退出，但参数仍要按真实流量调。

压测要模拟真实分布，而不是只用同一个 prompt 重复打。至少准备几类场景：短输入短输出、短输入长输出、长输入短输出、长输入长输出、多轮对话、RAG 拼接上下文、工具调用前后多次模型调用。每类都要测 TTFT、输出 token 间隔、端到端延迟、成功率、GPU 利用率、显存、KV cache 使用和错误类型。

四、延迟账：用户在乎的不是平均速度

用户感知延迟通常分三段。

第一段是排队时间。请求到达网关后，可能要等待推理实例有位置。高峰期排队是最常见的延迟来源之一。排队时间持续升高，说明容量不足或调度策略不合适。

第二段是首 token 延迟，也就是 TTFT。它包括请求转发、tokenization、prefill、batch 等待和第一次 decode。聊天、客服、代码助手对 TTFT 很敏感，因为用户看到第一个字就会觉得“系统开始工作了”。同样 10 秒完成回答，一个 0.8 秒出首 token、后续流式输出的服务，体验远好于 8 秒才开始吐字的服务。

第三段是输出速度。输出 token 间隔太慢，用户会觉得回答拖沓。报告生成类任务可以接受慢一点，代码补全和交互式问答不能。不同产品应该有不同 SLO：客服可能要求 p95 TTFT 小于 2 秒，长文档总结可以允许更高 TTFT，但要给进度和异步通知。

延迟账最怕平均值。平均 TTFT 1 秒不代表用户体验好，如果 p99 是 20 秒，高价值用户刚好在 p99，就会投诉。线上看 p95、p99 比看平均更有意义。还要按模型、租户、上下文长度、输出长度、时间段拆开看。很多系统不是整体慢，而是长 prompt 把短请求拖慢，或者某个大客户的批量任务挤占了交互池。

常见优化包括：分离交互池和批处理池；限制最大上下文和最大输出；给长任务走异步；启用 prefix cache；调小或调大 batch 等待窗口；按模型大小路由；用小模型处理简单任务；对固定系统提示词做缓存；为高优用户保留并发；对超长请求先压缩再生成。不要只想着换更贵 GPU，很多延迟问题来自调度和产品形态。

五、量化账：省显存不等于省总成本

量化很诱人，因为它能把模型权重从 BF16/FP16 压到 INT8、INT4、FP8、NF4 或 GGUF 的多种格式。Hugging Face bitsandbytes 支持 8-bit 和 4-bit，AWQ 和 GPTQ 常用于权重量化，vLLM 支持多种量化实现，llama.cpp 生态有大量 GGUF 量化模型。看起来只要把模型量化，显存就省了，成本就降了。

现实更复杂。

首先，量化主要省权重，不一定省 KV cache。一个长上下文高并发服务，KV cache 可能占掉大量显存。你把 70B 权重从 FP16 降到 INT4，确实腾出了空间，但如果 KV cache 仍用 FP16，长上下文并发仍会碰上限。部分引擎支持 KV cache 低精度，但要评测质量和稳定性。

其次，量化不一定更快。速度取决于硬件、内核、batch、模型结构和引擎支持。某些 INT4 权重量化在特定 GPU 上吞吐很好，换到另一张卡可能因为 kernel 不成熟而变慢。FP8 在 Hopper 或更新架构上有优势，但老卡未必适合。GGUF 在本地推理很方便，但大规模在线服务和 vLLM/TensorRT-LLM 路线的运维方式不同。

第三，量化会影响质量。影响不一定体现在闲聊上，常常体现在数学、代码、结构化输出、长上下文引用、少数语言、专业术语和边界安全上。一个量化模型在普通问答里看起来正常，在 JSON 严格输出、工具参数生成或财务数字总结里可能错误率上升。生产评测必须覆盖业务格式和关键指标。

第四，量化会增加版本管理成本。你可能同时维护 BF16、FP8、AWQ、GPTQ、GGUF 多个版本，每个版本都有不同引擎、启动参数和评测结果。如果没有模型 manifest 和自动评测，很快会不知道线上到底跑的是哪个版本。

比较稳的策略是：先用 BF16/FP16 或官方推荐精度建立质量基线，再尝试 FP8/INT8/INT4；每个量化版本必须跑同一套业务评测和压测；如果质量下降换来的成本节省低于用户损失，就不要上；如果量化后吞吐没有提升，只是能塞进更小显卡，也要计算稳定性风险和运维复杂度。

六、GPU 账：H100、A100、L4、4090、B200，不是越新越合适

选 GPU 要看模型大小、上下文长度、并发、精度、预算和供应。

H100/H200/B200 适合高吞吐、低延迟、大模型和高并发，NVLink/NVSwitch 对多卡张量并行很重要。A100 仍然适合不少中大型推理和训练任务。L4、L40S、A10 这类卡适合中小模型、embedding、rerank、轻量推理或成本敏感任务。消费级 4090/5090 对实验和内部低 SLA 服务很划算，但数据中心合规、稳定性、远程管理、ECC、供电散热和多卡互联都要考虑。

云厂商实例规格也不能只看 GPU 型号。AWS P5 p5.48xlarge 是 8 张 H100 80GB，官方规格页还列出 vCPU、内存、网络和本地存储。Azure ND H100 v5 系列面向高端 GPU 训练和推理。Google Cloud A3/A4 系列围绕 H100/H200/B200 等资源提供不同形态。Lambda 这类 GPU 云给出按 GPU 小时的价格和集群租用方式。不同地区、承诺期、按需或预留价格差别很大，容量可得性也差别很大。

对社区团队和创业项目来说，第一原则是别用最大卡掩盖架构问题。比如一个 7B 模型客服系统，如果平均输出 200 token，流量也不大，用 H100 可能长期闲置；一个 70B 长文档系统，如果需要 32K 上下文和多人并发，一张消费卡再便宜也不稳定；一个内部批处理总结任务，可能用 spot 或夜间低价资源更合适；一个实时代码助手，则要优先保证低 TTFT 和稳定流式输出。

多卡部署还有通信账。张量并行会把模型切到多张 GPU，推理时需要频繁通信。如果卡之间没有高速互联，性能可能不如预期。PCIe 多卡和 NVLink/NVSwitch 机器差距很大。跨机器张量并行更复杂，网络延迟和带宽会成为硬瓶颈。能单卡稳定跑的模型，运维复杂度通常低很多；必须多卡时，要确认引擎对 tensor parallel、pipeline parallel 和分布式 serving 的支持成熟。

七、云上、自建和混合部署：便宜不只是单价低

云上优点是启动快、弹性好、少管硬件，缺点是长期成本高、容量可能紧、数据出入和合规要处理。自建优点是长期摊销可能便宜、数据边界清楚、资源可控，缺点是采购周期长、硬件运维难、利用率不足时浪费大。混合部署适合很多团队：核心稳定流量放自有或长期租用资源，突发批处理放云上；敏感数据在内网，公开低风险任务走外部 API；大模型少量高价值调用走商业 API，小模型高频任务本地跑。

算自建账时，不要只用 GPU 采购价除以三年小时数。还要加服务器、CPU、内存、NVMe、网卡、交换机、机柜、电力、制冷、带宽、备件、保修、人工、机房空间和闲置率。GPU 利用率如果长期只有 20%，看似便宜的自建会变贵。云上虽然单价高，但如果你的流量波动大、项目还在验证阶段，按需租用可能更便宜。

算云上账时，也不要只看宣传价。按需、预留、spot、capacity block、集群承诺价完全不同。很多低价需要长期承诺或大规模集群，并不适合小团队。公网出流量、对象存储、快照、日志、跨区同步、负载均衡和 NAT 网关也会产生费用。高峰期抢不到卡，会让你多区域部署或保留冗余，成本继续上升。

一个务实建议：验证期优先云上或现成 API，确定任务价值和流量后再决定自部署；稳定高频、数据敏感、模型可控的任务适合本地或私有云；突发离线任务适合弹性资源；实时交互任务不要依赖不稳定 spot；高价值客户服务要保留冗余，不要把成本压到单点刚好够用。

八、运维账：真正花钱的是稳定运行

部署一个 demo 和运行一个生产服务是两回事。Demo 可以手动重启，生产服务要有人负责模型版本、镜像安全、驱动、CUDA、NCCL、推理引擎、容器、节点健康、日志、监控、告警、备份和回滚。

大模型服务的故障类型很多：模型加载失败、显存碎片、OOM、CUDA kernel 错误、NCCL 通信失败、tokenizer 不一致、请求超过上下文、流式响应断开、网关超时、节点磁盘满、模型文件下载慢、镜像拉取失败、驱动版本不兼容、量化 kernel 不支持、GPU 温度或功耗异常。每一种都需要可观测性和处理预案。

运维成本还包括升级成本。vLLM、SGLang、TensorRT-LLM、TGI、Triton、CUDA、NVIDIA 驱动都在快速更新。新版本可能带来性能提升，也可能改变默认参数或引入兼容问题。生产升级不能直接替换镜像，应该先在影子流量或压测环境验证：同一模型、同一请求集、同一采样参数下，质量是否一致，延迟是否改善，显存是否变化，错误率是否增加。

日志和监控也不是免费。高流量模型服务如果完整记录 prompt 和 response，存储成本很快上来，更重要的是隐私风险。实践上应记录元数据和抽样内容，敏感字段脱敏，按租户和权限控制访问。质量回放需要样本，但样本不能变成无法管理的数据湖。

值班成本同样要算。一个模型服务晚上 OOM，如果没有自动熔断和降级，可能影响所有上层应用。多模型平台要支持回退到小模型、切到备用实例、拒绝超长请求、暂停批处理任务、限制异常租户，而不是让所有请求一起失败。

九、质量账：便宜模型答错，最后最贵

成本优化不能只看硬件。一个便宜模型如果让用户多问三次，让人工客服介入，让开发者修错误代码，让运营人员重写文案，真实成本可能更高。大模型服务的成本账必须和质量账合并。

质量评测要覆盖真实业务。客服看一次解决率、事实准确性、拒答边界和转人工率；代码助手看采纳率、测试通过率、漏洞率和上下文理解；知识库问答看引用正确率、无答案拒答率和幻觉率；报告生成看结构、数字、来源和可编辑性；Agent 看工具调用成功率、恢复能力和操作安全。

量化、小模型路由、蒸馏、缓存都会影响质量。最好的成本策略通常不是“全站换小模型”，而是分层：简单任务小模型，复杂任务大模型；固定格式任务蒸馏模型，开放推理任务强模型；高频知识问答 RAG 加中等模型，关键决策强模型加人工确认；低价值长任务异步处理，高价值交互任务保低延迟。

还要算重试成本。模型失败后，用户会重试，应用也可能自动重试。一次失败不只是浪费一次 token，还可能造成流量放大。比如成功率从 99% 掉到 95%，看似只差 4 个百分点，但在高峰期可能意味着大量重试、排队增加、延迟变差，最后触发连锁故障。

十、RAG 和 Agent 的额外账

很多应用不是直接问模型，而是 RAG 或 Agent。RAG 会增加 embedding、向量库、检索、重排、上下文拼接和引用验证成本。Agent 会增加多轮模型调用、工具 API、状态存储、权限校验和执行日志成本。

RAG 的成本不只是向量库。文档入库要切分、清洗、去重、embedding、版本管理；查询时要召回、重排、压缩、拼接；回答后要验证引用。上下文拼太多会增加输入 token 成本和 TTFT，拼太少会降低准确率。很多 RAG 系统贵不是因为 embedding，而是每次把几十段长文档塞进大模型。

Agent 的成本更容易失控。一个用户请求可能触发 5 次模型调用、3 次检索、2 次外部 API、1 次代码执行。模型越“会思考”，如果没有预算控制，就越可能循环。生产 Agent 必须设置最大步骤数、最大 token、工具权限、失败退出条件、用户确认点和审计日志。否则一次复杂任务的成本可能是普通问答的几十倍。

因此部署大模型前，要按产品形态估算调用放大系数。普通聊天可能是 1 次模型调用；RAG 可能是 1 次 embedding 加 1 次 rerank 加 1 次生成；Agent 可能是 3 到 20 次模型调用。只按“每个用户问题一次生成”估成本，会严重低估。

十一、一个可落地的部署前测算表

部署前可以用下面这张文字版清单做测算。

第一，业务流量。每日请求数、峰值 QPS、峰值并发、输入 token 分布、输出 token 分布、长上下文比例、流式比例、重试比例。

第二，质量目标。必须使用哪个模型等级，是否允许小模型路由，是否允许量化，格式错误率上限，事实错误率上限，人工兜底成本。

第三，延迟目标。p50、p95、p99 TTFT，p95 端到端延迟，输出 token 速度，长任务是否可异步。

第四，显存需求。模型权重精度，最大上下文，最大并发序列，KV cache dtype，安全余量，多卡并行方式。

第五，吞吐压测。按真实请求分布压测，不只测固定 prompt；记录排队、prefill、decode、成功率、OOM 和 GPU 指标。

第六，资源方案。GPU 型号、单机还是多机、云上还是自建、按需还是预留、是否需要冗余、是否支持灰度和回滚。

第七，运维能力。谁负责驱动和引擎升级，谁处理夜间故障，日志保留多久，如何脱敏，如何告警，如何恢复。

第八，成本输出。月固定成本、峰值弹性成本、每千输入 token 成本、每千输出 token 成本、每次成功回答成本、失败重试成本、人工介入成本。

这个表第一次填可能很粗，但比直接租卡上线强很多。上线后用真实数据回填，成本模型会越来越准。

十二、什么时候不该自部署

不是所有团队都该自部署大模型。下面几种情况，优先考虑商业 API 或托管服务。

第一，流量很小且不稳定。GPU 空闲时间太长，自部署浪费。

第二，团队没有 GPU 运维经验。驱动、CUDA、推理引擎和监控会消耗大量时间。

第三，业务质量要求高但评测体系还没有。你不知道模型好坏，自部署只会放大不确定性。

第四，模型更新很快。你需要持续追最新强模型，而不是维护一个固定开源模型。

第五，合规允许外部 API，且数据脱敏后风险可控。此时商业 API 的总成本可能更低。

反过来，如果你有稳定高频流量、明确数据边界、可控模型质量、强运维能力和成本优化需求，自部署就值得认真算。尤其是 embedding、rerank、小模型分类、内部知识问答、批量文档处理、固定业务生成等任务，本地部署经常能拿到更好的成本和可控性。

十三、社区建议：从小闭环开始，不要一上来造大平台

很多团队部署失败，不是技术不够强，而是一开始目标太大。想同时支持十几个模型、自动伸缩、多租户计费、RAG、Agent、微调、评测、灰度和可视化，最后每个都半成品。

更稳的顺序是：

先选一个高价值场景，明确输入输出和质量标准。再选一个基座模型，跑通推理服务和应用调用。然后建立最小观测：token 数、TTFT、输出速度、错误率、显存和 GPU 利用率。接着做真实请求压测，确定瓶颈。之后再引入量化、小模型路由、缓存、RAG 或 Agent。每加一个优化，都要证明它让单位有效回答成本下降，而不是只让架构图更漂亮。

部署大模型最怕“感觉”。感觉这个模型够强，感觉这张卡够用，感觉 INT4 不影响质量，感觉用户不会同时来，感觉日志以后再补。生产系统会把这些感觉逐个打穿。社区里最值得复用的经验不是某个神奇参数，而是把每个假设变成可测指标。

十四、样例测算：一个中型知识库问答服务

下面用一个接近真实社区项目的例子算账。假设团队要给内部两百名员工提供知识库问答，工作日使用，主要问题来自产品、售后、实施和运营。每天三万次请求，平均输入一千二百 token，平均输出三百五十 token。因为接了 RAG，每次请求还会做一次 embedding 查询、一次重排，并把三到六段文档拼进 prompt。高峰集中在上午十点到十二点、下午三点到五点，峰值小时是平均小时的三倍。

先算 token。每天输入约三千六百万 token，输出约一千零五十万 token。高峰小时如果承载全天四分之一请求，就是七千五百次请求，输入九百万 token，输出二百六十多万 token。再考虑百分之八的用户重试、百分之五的系统二次改写、百分之二的超长文档请求，峰值容量至少要留出百分之二十到三十的余量。

如果用一个中等模型做主力，单卡可以稳定跑交互池，成本可能可控。但如果直接上 70B 模型，并要求所有请求同步返回，GPU 数量、TTFT 和排队都会上升。更合理的架构是三层：高频简单问答走 7B 或 14B 模型，复杂制度解释和跨文档总结走更强模型，长报告生成进入异步队列。这样不是降低质量，而是把强模型用在真正需要推理和综合的地方。

再看上下文。平均输入一千二百 token 听起来不大，但 RAG 拼接后可能变成四千到八千 token。若某些用户上传长文档，输入会轻易超过三万 token。把所有实例都开到 32K 上下文，会降低可承载并发，因为 KV cache 预留变大。更稳的做法是交互池限制 8K 或 16K，长文档池单独配置 32K 或 64K，并用队列控制并发。用户体验上，短问答保持快，长任务允许等待或通知。

质量成本也要进入测算。假设小模型一次回答成本低，但事实错误率高，导致百分之十五请求要追问；强模型单次成本高，但追问率降到百分之五。若人工每处理一次升级问题要五分钟，人工成本可能超过 GPU 节省。知识库问答尤其要看一次解决率、引用正确率和无答案拒答率，不能只看模型单价。

最终方案可以这样落地：一个交互池承载普通问答，严格限制最大输入和输出；一个高质量池承载复杂问题，由路由器按问题类型、检索置信度和用户等级选择；一个异步池承载长文档总结和批量生成。每个池单独看 TTFT、输出速度、成功率、显存和单位有效回答成本。这样扩容时不会盲目加卡，而是知道哪个池真的缺资源。

十五、样例测算：小团队自部署代码助手

代码助手和知识问答不一样。用户更在乎低延迟、上下文窗口、代码正确性和 IDE 中的流畅感。假设一个十人研发团队自部署代码助手，主要用于解释代码、生成单元测试、修复报错和写脚本。每天请求量不大，只有五千次，但上下文经常包含文件片段、错误栈、依赖信息和历史对话，平均输入可能达到三千 token，输出五百 token。

如果团队为了“效果好”直接部署大模型，GPU 长时间空闲，单位成本会很高。更合理的方案是本地或私有云部署一个中小代码模型处理高频补全和解释，把复杂重构、跨文件分析和疑难错误路由到商业 API 或更强自部署模型。低频强需求不一定要占用常驻大卡。对于十人团队，稳定、低维护成本通常比完全本地化更重要。

代码场景的量化评测要格外谨慎。聊天看起来正常，不代表代码可用。量化后要测编译通过率、单元测试通过率、静态扫描结果、依赖版本准确性和是否编造不存在的 API。很多代码模型在 INT4 下仍能写出像样代码，但细节错误增多，例如参数名错、导入路径错、边界条件漏掉。一次错误代码被复制进项目，后续排查成本远高于一次推理成本。

部署清单也不同。代码助手要限制仓库权限，避免把私有代码发到不该去的模型；要记录模型是否允许训练使用用户代码；要支持按项目配置上下文范围；要避免把 .env、密钥、证书、客户数据放进 prompt；要对生成命令和文件修改做确认。若接入 Agent 自动改代码，还要有 diff 预览、测试运行、回滚和审计。

这个案例说明：小团队未必需要大而全的平台。先把请求路由、权限、评测和成本记录做好，再决定哪些模型常驻、哪些模型按需调用。自部署不是信仰，而是成本、隐私、体验和控制权的平衡。

十六、部署清单：上线前逐项确认

上线前至少确认以下事项。

模型方面，确认模型许可证允许当前用途，权重来源可信，tokenizer 和聊天模板完整，量化版本有独立评测，最大上下文不是随意开大，推荐采样参数已固化。不要让应用层每次随意传 temperature、top_p、max_tokens，除非产品确实需要开放这些控制。

资源方面，确认每个模型实例的显存水位、KV cache 上限、最大并发序列、最大批处理 token、CPU 内存、本地磁盘、模型加载时间和重启时间。多卡部署要确认通信拓扑，别把需要高速互联的张量并行放在普通 PCIe 或跨机器弱网络上。

接口方面，确认网关支持鉴权、租户配额、按 token 限流、超时、取消请求、流式响应、错误码分类和请求追踪。大模型错误不能都返回同一个失败提示。用户输入超长、租户额度不足、模型繁忙、工具失败、内容被拒绝，应有不同处理。

观测方面，确认有 TTFT、输出 token 间隔、端到端延迟、输入 token、输出 token、排队时间、prefill 时间、decode 时间、GPU 利用率、显存、KV cache 使用率、OOM、取消请求、超时和按租户成本。只看 QPS 和平均延迟不够。

质量方面，确认有离线评测集、线上抽样回看、用户反馈入口、失败样本归因和版本对比。评测集要覆盖业务真实问题，而不是只放公开 benchmark。对 RAG，要单独评估召回、引用和无答案拒答；对 Agent，要评估工具调用、步骤数、失败恢复和权限边界。

安全方面，确认日志脱敏、密钥过滤、上传文件扫描、提示词注入防护、工具权限、敏感操作确认、模型输出审核和数据保留期限。内部服务也不能默认安全，很多事故恰恰发生在“只有内网用户会用”的系统里。

发布方面，确认灰度比例、回滚模型、旧版本保留时间、配置变更记录、镜像版本、驱动和 CUDA 版本、推理引擎版本。不要在同一次发布里同时换模型、换引擎、换 prompt、换检索索引，否则出问题无法归因。

十七、压测方法：别用假流量骗自己

压测应该模拟真实请求，而不是拿一个短 prompt 循环打满。至少要准备四类请求：短问答、长上下文问答、长输出生成、RAG 或 Agent 多步骤请求。每类按实际比例混合，并加入用户取消、超时、重试和突发峰值。压测持续时间也要足够长，短时间跑通不能代表显存碎片、日志堆积和队列积压不会出现。

压测结果要分段看。排队时间高，说明容量或调度有问题；prefill 慢，说明输入太长、batch 策略不合适或 tokenizer/上下文处理有瓶颈；decode 慢，说明输出并发、KV cache、量化 kernel 或 GPU 带宽可能是瓶颈。端到端延迟只是结果，分段指标才能指导优化。

还要做降级压测。主动让一个模型实例下线，看网关是否把流量切走；主动制造超长请求，看系统是否拒绝或异步处理；主动提升某个租户流量，看限流是否生效；主动切换量化版本，看质量评测和回滚是否可用。生产事故不会按 demo 剧本发生，压测要提前暴露薄弱点。

压测后要输出容量结论。例如：当前配置在 p95 TTFT 小于两秒、p95 输出速度满足要求时，能支撑每分钟多少请求；超过这个点后，首先恶化的是排队还是 decode；扩一张卡能提高多少；把最大上下文从 32K 降到 16K 能释放多少并发；把长任务迁到异步池能降低多少 p99。没有这些结论，压测只是热闹。

十八、成本优化顺序：先砍浪费，再换硬件

很多团队一慢就想换 H100，一贵就想 INT4。更稳的优化顺序是先砍明显浪费。

第一，限制无意义上下文。RAG 不要把所有召回片段都塞给模型，先重排、去重、压缩，再拼接。多轮对话不要无限追加历史，应该摘要旧上下文或按任务保留关键信息。上下文越长，TTFT 和 KV cache 成本越高。

第二，限制无意义输出。很多应用默认 max_tokens 给得过大，模型会越写越长。按场景设置输出上限，报告类可以长，分类、抽取、客服建议不需要长篇大论。输出 token 是持续成本，啰嗦也是钱。

第三，做模型路由。简单问题、小任务、格式化抽取、分类和改写不必都走最大模型。路由规则可以先从保守启发式开始，再逐步引入置信度、历史反馈和成本预算。关键是失败要能升级到强模型，而不是让小模型硬答所有问题。

第四，做缓存。系统提示词、企业规范、常见文档前缀、热门问题、检索结果和部分确定性任务都可能缓存。缓存不是只缓存最终答案，也可以缓存 prefix、embedding、rerank 结果和工具查询结果。

第五，评估量化和蒸馏。当浪费已经减少，再看量化是否能在质量可接受的前提下降低显存或提高吞吐。对高频固定任务，蒸馏小模型往往比直接压大模型更稳。

第六，最后再扩硬件。硬件扩容应该基于容量模型：增加 GPU 后瓶颈是否还在 GPU，还是已经转移到检索、网关、数据库、网络或外部工具。盲目加卡有时只会让成本上升，延迟不变。

十九、预算审批怎么写：让老板看懂这笔钱买了什么

很多大模型项目卡在预算，不是因为方案一定贵，而是因为申请材料只写了“需要几张显卡”。业务负责人看不懂显卡和模型参数之间的关系，也看不出这笔钱能换来什么结果。更好的预算说明应该从业务价值开始，再落到容量和资源。

一份可读的预算说明可以分四段。第一段写业务目标，例如减少客服转人工、提升研发问题处理速度、缩短报告生成时间、保障内部知识问答可用。第二段写需求规模，例如日请求量、峰值并发、平均上下文、长任务比例、目标响应时间和可用性要求。第三段写资源方案，例如交互池、长任务池、备用实例、存储、监控和人力投入。第四段写验收指标，例如一次解决率、引用正确率、平均处理时长、单位有效回答成本和故障恢复时间。

预算里还要明确“不买什么”。比如第一期不训练基础模型，不建设复杂多租户计费，不支持无限长上下文，不承诺所有任务实时完成。把边界写清楚，反而更容易获得信任。否则团队会被期待用一套小预算完成所有大模型平台能力，最后质量和稳定性都不达标。

采购时也要避免一次买满。开发期可以先租云上资源或使用少量本地卡，拿到真实流量和压测数据后再决定长期资源。稳定负载适合长期租用或自建，突发负载适合弹性资源，低频强模型需求适合外部 API 或共享强模型池。预算不是一次性拍脑袋，而是随着用量、质量和成本数据滚动修正。

如果要向管理层解释为什么不能只买最便宜方案，可以用风险语言：显存没有余量会导致高峰失败，缺少备用实例会导致单点故障，没有评测会导致质量退化不可见，没有监控会导致故障定位慢，没有日志脱敏会带来合规风险。这些不是技术洁癖，而是生产服务的基本保险。

二十、结语：算清楚，才有资格谈规模化

大模型部署的真实成本由显存、吞吐、延迟、质量和运维共同决定。权重能不能放进显卡只是入门题；能不能在真实流量下稳定、快速、可回滚、可观测、可解释地交付结果，才是生产题。

如果你正在准备部署第一个大模型服务，建议先做三件事：第一，用真实业务样本建立评测集；第二，用真实请求分布做压测；第三，把成本按“有效回答”而不是“GPU 小时”计算。这样你会更早发现：该换模型时换模型，该量化时量化，该做缓存时做缓存，该买卡时买卡，该用外部 API 时就用外部 API。

真正成熟的大模型团队，不是最会堆 GPU 的团队，而是最清楚每一块 GPU 在为哪个用户价值服务的团队。

参考资料

• AWS EC2 加速计算实例规格：包含 P5 等 GPU 实例的官方规格说明。
• AWS EC2 Capacity Blocks for ML Pricing：AWS 机器学习容量块价格页面，可参考 H100 容量预订价格形态。
• Google Cloud GPU pricing：Google Cloud GPU 官方价格入口，用于核对 A3/A4 等资源费用。
• Azure ND H100 v5 系列：Azure H100 GPU 虚拟机规格说明。
• Lambda GPU Cloud Pricing：Lambda GPU 云价格页面，展示 H100、B200 等资源价格形态。
• vLLM 文档：PagedAttention、continuous batching、量化和 OpenAI 兼容 serving 资料。
• Efficient Memory Management for Large Language Model Serving with PagedAttention：PagedAttention 论文，解释 KV cache 分页管理对吞吐的影响。
• NVIDIA TensorRT-LLM 文档：NVIDIA GPU 上 LLM 推理优化、in-flight batching、paged KV cache 和量化资料。
• Hugging Face Text Generation Inference 文档：TGI 部署和服务化资料。
• SGLang 文档：SGLang serving、prefix caching、RadixAttention 和多 GPU 相关资料。
• NVIDIA Triton Inference Server 文档：模型仓库、动态 batching、指标和生产推理服务资料。
• KServe Generative Inference 文档：Kubernetes 上生成式推理服务、OpenAI 兼容接口和扩缩容资料。
• Hugging Face bitsandbytes 文档：8-bit、4-bit 量化和低显存推理/训练资料。
• vLLM Quantization 文档：vLLM 不同量化实现及硬件兼容说明。
• llama.cpp 项目：GGUF、本地推理、多后端和低比特量化资料。
• QLoRA: Efficient Finetuning of Quantized LLMs：QLoRA 论文，解释 4-bit 量化微调的工程意义。
• The Llama 3 Herd of Models：Llama 3 技术报告，可参考预训练、后训练和部署前评测思路。
• DeepSeek-R1: Incentivizing Reasoning Capability in LLMs via Reinforcement Learning：DeepSeek-R1 论文，可参考推理模型、蒸馏和成本质量权衡。