私有化部署大模型:开源闭源怎么选,显存并发合规怎么算

选型为什么卡半个月：把"开源闭源"翻译成三个工程口径

私有化部署的决策卡点，很少出在"模型选项太少"。恰恰相反，能跑的开源权重越来越多，闭源厂商的私有化授权也都给得出方案，可摆在桌上的备选越多，拍板反而越难。我见过一家制造企业的技术负责人，前后评估了十几个方案，耗了大半个月还在原地打转——不是哪个模型明显不行，而是没有一把尺子能把这些方案量到同一个刻度上比。决策卡住的真因是维度没量化，不是信息不够。

大多数选型文档会给出一套四维框架：数据安全等级、并发与性能要求、预算成本、团队能力。这四个维度本身没错，缺一不可，问题是它们太粗，落不到一张采购单上。"数据不能出域"是一句立场，不是一个约束——它没告诉你要买几张卡、模型能不能量化、日志要不要留审计。"性能要够用"同样是空的，够用是多少 QPS、首 token 要压到几百毫秒、p99 能容忍多大抖动，全藏在"够用"这两个字底下。维度停在形容词层面，评审会就只能反复争论倾向，争不出可执行的结论。

把这套粗框架往下翻译，其实能收敛成三个能算的工程口径。第一个是显存：模型参数决定了你的地板，但真正吃显存的往往是推理时的 KV Cache，它随并发数和上下文长度线性长，参数量只是账单的一小半。第二个是并发：先定延迟目标和峰值 QPS，再反推单卡能扛多少路、总共要几张卡，而不是先买硬件再看能跑多快。第三个是合规：把"满足等保"这种说法拆成数据是否出域、模型权重能否落在自己机房、调用链路要留多久审计这类能逐条打勾的硬约束。这三个口径的共同点是都能落到数字、落到采购单，评审时不再是比谁的立场更稳，而是比谁的数算得更实。

这么拆之后，"开源还是闭源"这个老问题的位置也变了。它不该是选型的前提，而是三口径算完之后自然掉出来的结果。举个例子：合规口径要求权重必须留在本地、连模型文件都不能托管在厂商侧，那闭源 API 这条路基本就被划掉了，剩下的才是在开源权重里挑哪个量级；反过来，如果数据出域在你的行业里是被允许的，预算又紧、团队也撑不起 GPU 运维，那闭源的私有化或专属实例可能反而更省心。先站队再找理由，容易把工程问题打成偏好之争；先算口径再看结果，开源闭源就退回成它本来的样子——一个交付形态的选择，而不是信仰。

所以这篇文章不打算给你一张"开源 vs 闭源"的对照表让你站队，而是先把显存、并发、合规这三把尺子交到你手里。后面几节会逐个展开：显存怎么从参数和 KV Cache 算到真实占用，并发怎么从延迟目标反推卡数，合规怎么拆成能核对的清单，再把三者合到成本和回本上，最后落成一张能直接报采购的规模—硬件对照表。等这三个口径都算清楚了，开源还是闭源这个问题，多半你自己已经有答案了，根本不用纠结大半个月。

显存口径：参数只是地板，KV Cache 才是并发的真实账单

很多团队第一次做私有化选型，拿到模型参数量就去对显卡规格，结果上线后并发一放量就 OOM。根本原因是把"能装下模型"和"能跑并发"混为一谈。显存需求分两层，参数加载是地板，KV Cache 才是真正随业务弹性增长的那一块。

第一层：权重加载的静态下限

FP16 精度下，每个参数占 2 字节，加上运行时框架开销，经验估算如下：

这组数字的意义是：单请求、空载状态下的最低门槛。一张 80 GB 的 A100 装 7B 绰绰有余，装 14B 也够，但这只是起点，不是终点。

第二层：并发放大的 KV Cache 账单

推理阶段每个活跃请求都需要独立维护一块 KV Cache（Key-Value 缓存，用于存储注意力机制的中间状态）。实际显存占用的完整公式是：

总显存 = 权重显存 + 并发请求数 × 单请求 KV Cache 大小

单请求的 KV Cache 体积取决于模型层数、注意力头数和序列长度。以一个中等规模模型为例，单请求 KV Cache 会随序列长度占用相当一部分显存。这意味着权重加载之后，剩余显存能支撑的并发路数有限——而且这是上限，实际调度还要为系统预留余量。

反过来看那个常见的踩坑场景：如果采购依据是"7B 只需要 20 GB"，买了一张 24 GB 消费级卡，权重上去之后只剩 4 GB 给 KV Cache，两三个并发请求就把显存打满，直接触发 OOM。参数规格没说错，但忽略了并发这一层，采购就错了。

量化：显存换精度的杠杆

当目标硬件的显存无法容纳 FP16 权重时，量化是最常用的工程手段。INT8 量化将权重从 16 位压缩到 8 位，显存占用降低约 75%，而多数测评显示精度损失在 2% 以内——对大多数企业内部问答、文档处理场景来说是可接受的代价。

实际效果：大模型经过 INT8 量化后显存占用明显下降，从"必须多机"变成"单机可跑"。这不是精度无损的免费午餐，而是一个明确的工程权衡：用可量化的精度损失换取硬件成本的大幅压缩。

INT4 量化可以把显存压得更低，但精度下降通常较为明显，是否可用取决于具体任务对准确率的敏感度，需要在自有数据集上实测，不能只看通用 benchmark。

容量基准：7B 在 A100 80G 上的实测参考

7B 参数模型在单张 A100 80GB 上完整加载 FP16 权重，推理延迟可以稳定在 200ms 以下——这是一个值得记住的容量基准点。它的意义在于：你可以以此为锚，向上推算 14B 和 70B 需要多少卡，向下推算在更小的卡（如 A10 24G）上跑 7B 量化版本的延迟代价。

选型前先算这张账

在进入"买几张卡"的决策之前，建议先把以下三个数字确定下来：

• 峰值并发数：业务侧能给出的最高同时在线请求数，这决定 KV Cache 预算
• 平均序列长度：输入+输出的 token 总长，直接影响单请求 KV Cache 体积
• 精度容忍度：业务场景能接受 INT8 还是必须 FP16，决定是否可以量化压缩

三个数字确定之后，套上述公式就能算出最低显存需求，再加 20%–30% 的安全余量，才是真正的采购下限。跳过这一步直接对参数量买卡，是选型卡半个月甚至返工的主要原因之一。

并发口径：从延迟目标和 QPS 反推该买几张卡

很多团队卡在选型上，根源不是不懂硬件，而是跳过了一个前置动作：先把延迟 SLA 写成数字。"响应要快"这种描述对采购单没有任何约束力；"首 Token 延迟不超过 1 秒"才是可以反推卡数的工程入口。

第一步：区分场景，SLA 差距决定配置差距

两类场景的资源需求量级完全不同，混在一起估算会导致要么严重超配要么上线即崩：

• 实时对话（C 端或内嵌业务流程）：首 Token 延迟必须控制在 1 秒以内，否则用户感知明显卡顿。这个约束直接限制了批大小（batch size）——批越大吞吐越高，但排队等待时间同步拉长，两者之间存在硬性张力，不能只盯吞吐数字。
• 内部工具 / 低并发后台任务：几十人同时在线的知识库问答、代码审查、报告生成，延迟 3–5 秒完全可接受。这类场景的瓶颈是显存容量而非延迟，可以用更大批次换更高吞吐，同等硬件下实际服务人数是实时对话场景的数倍。

这两种场景混用同一套配置标准，要么给低并发内部工具买了过贵的低延迟硬件，要么把实时对话压在一台吞吐机上让用户一直等第一个字。

第二步：推理框架决定你能榨出多少吞吐

硬件是上限，推理框架决定你能用到上限的几成。三个主流框架定位清晰，混用或选错会让同等硬件效果差一倍以上：

• Ollama：一条命令拉起，适合本地开发和概念验证。没有生产级并发管理，不要在真实负载下用它做性能基准。
• vLLM：目前社区最活跃的生产推理框架，核心是 PagedAttention 机制——把 KV Cache 按需分页而非预分配连续块，显存碎片大幅减少，同显存下可支撑的并发请求数显著提升。生产高并发首选。
• TensorRT-LLM：NVIDIA 官方出品，针对自家 GPU 做了深度内核优化，延迟和吞吐的天花板高于 vLLM，但部署复杂度和维护成本更高。对延迟 SLA 极苛刻（比如实时语音、金融交易辅助）且运维团队有 CUDA 经验的场景值得投入。

第三步：用 QPS × 单请求 KV 估显存，再用延迟校验批大小

反推卡数的计算路径分两条线，取较大值：

显存约束线：目标并发 QPS 乘以单请求 KV Cache 占用（由上下文长度和模型层数决定，详见本系列第 2 节），加上模型权重本身的显存底座，得出峰值显存需求。这条线给出"最少需要多少显存"。

延迟约束线：首 Token 延迟 SLA 反过来限制了 prefill 阶段允许的最大批大小。批越大、prefill 耗时越长、首 Token 越晚到。如果你的 SLA 是 1 秒，那就需要在目标 QPS 下测出满足延迟的最大批大小，再确认该批大小下单卡/多卡的算力是否够用。

两条线都通过，卡数才算够。只看显存不看延迟，上线后首 Token 超时；只看延迟基准测试不看峰值显存，高峰 OOM 直接崩服务。

规模与卡数的工程参照

以上数字来自行业部署实践的普遍参照区间，具体值仍需以实际上下文长度、并发峰值和批大小测试结果为准。70B 跨到 8 张卡的场景，张间通信带宽（NVLink vs PCIe）会成为新的瓶颈，评估时需要同步确认互联拓扑，不只是凑够显存总量。

结论是：并发口径的选型不是查表，而是从你的 SLA 数字出发，经过框架选择、KV 估算、延迟校验三道过滤，最后得出一个可以写进采购单的最小卡数。跳过任何一道，数字就会失真。

合规口径：把"满足等保"拆成可核对的硬约束

前面两节算的是显存和并发，那是"能不能跑得起来、跑得够不够快"的问题。但在金融、医疗、政务这类强监管行业，还有一道在算账之前就生效的门：方案合规不达标，性能再漂亮也直接出局。这道门的麻烦之处在于，业务方常把它说成一句模糊的"要满足等保"，而工程上根本没法对一句口号做验收。要让它进得了评审、过得了审计，得先把这句话翻译成几条能逐项打勾的硬约束。

先说为什么要单独拎出来谈。显存和并发是连续量，差一点可以靠加卡、降并发、压上下文来补救；合规不是连续量，它是布尔值。一个方案要么满足"数据不出内网"，要么不满足，中间没有"基本满足"这种状态。这意味着合规约束应该放在选型流程的最前面当过滤器用，而不是等架构定型、采购单都画好了，再被安全或法务一票否决——那时候返工的成本是按周算的，前面那半个月的选型纠结，相当一部分就卡在这里。

三条能逐项核对的项

把"满足等保"摊开，对部署架构起决定作用的主要是三条，每一条都能落到具体的核对动作上：

• 数据本地化：训练语料、推理时的输入输出、向量库、日志，这些数据物理上存放在哪。可核对的问法是"列出所有持有业务数据的存储节点，它们的物理位置和归属主体分别是什么"。只要有一份数据落在你不掌控的机房或第三方账户里，这条就不过。
• 不出内网：推理链路上有没有任何一跳穿过公网。这条最容易被忽视的不是主模型调用，而是那些"顺手"接进来的外部能力——联网检索、第三方向量化服务、调用外部 API 做工具增强。可核对的问法是"画出完整调用链，标出每一跳的网络边界"，任何一条出网的箭头都要能解释清楚或被掐断。
• 等保认证：系统按等级保护要求完成定级、备案、测评，并拿到对应等级的结论。金融、政务核心系统通常要求三级。这条核对的是流程证据，不是技术参数，但它会反过来约束你能用什么样的底层设施。

金融、医疗、政务在私有化选型时须满足等保认证、数据本地化且不出内网，这一点在 2024 年的行业实践里已经是默认前提，不再是加分项。把它当硬约束写进需求基线，后面的架构讨论才有共同的边界。

合规如何反向锁死架构

真正影响选型的，是这三条约束的连锁反应。这里换个角度看会更清楚：不要问"我想用什么部署形态"，而是问"在数据不出内网的前提下，哪些形态还活着"。

从这个角度倒推，公有云的按需推理服务第一个出局——它的本质就是把请求送到供应商的机房处理，"不出内网"和"按需调用公有云"在定义上互斥。闭源 SaaS 形态的大模型同理，无论它叫什么名字，只要推理发生在你内网之外，就过不了第一道核对。这一步筛完，桌面上能留下的基本只剩两类：把闭源模型以私有化授权方式装进自己机房，或者干脆用开源模型自行部署。

到这里，"开源还是闭源"这个被反复争论的问题，已经被合规约束削掉了一半的选项空间。剩下的不是站队之争，而是在"私有化的闭源授权"和"自部署的开源"之间，按前几节的显存、并发口径继续算账。合规没有替你做完选择，但它替你划掉了一大片本来要纠结的方案，这是它最实际的价值。

还有两个容易在落地时翻车的细节值得提前盯住。一是混合架构的诱惑：用本地小模型处理日常请求、把难题"兜底"转给公有云大模型，这种设计性能和成本都好看，但只要那条兜底链路携带了真实业务数据出网，整套方案的合规性就被它一票拉低。二是更新通道：私有化部署的模型权重、依赖镜像怎么更新？如果靠从公网直接拉取，那是另一条隐性的出网路径，审计时同样要解释。把这两点想清楚，后面的硬件采购单才不会因为一次安全复核推倒重来。

一句话收口：合规口径不参与"性能好不好"的讨论，它只回答"这个方案有没有资格上桌"。先用数据本地化、不出内网、等保认证这三条把候选方案过一遍，再去和显存、并发算细账——顺序反了，前面算得越细，后面返工越疼。

开源 vs 闭源：用三口径给可算判断，而不是站队

选型讨论里最容易跑偏的环节，就是把开源/闭源当成立场题来辩。工程上这个问题没有阵营，只有在你的显存预算、并发目标和合规边界下，哪条路的 TCO 更低、风险更可控。

先把两条路的成本结构摆清楚

开源模型（Llama 3、DeepSeek、Qwen、GLM 等）的许可证本身不收费，这是事实。但"免费"只是权利金为零，不是部署成本为零。真实账单分三块：

• 硬件资本支出：模型参数决定显存地板，KV Cache 和并发目标决定实际采购量——这笔钱完全在你这边，没有人分担。
• 运维人力：推理框架选型（vLLM / TGI / SGLang）、量化精度取舍、显存碎片治理、版本升级回归——每一项都需要有人长期盯。按行业普遍观察，一个从零搭建到稳定运行的私有化部署项目，算上调优和值班，通常需要若干名有 GPU 集群经验的工程师持续投入，初期尤其密集。
• 机会成本：团队精力有上限。花在基础设施上的人日，就是没有花在业务功能上的人日。

闭源/商业方案的账单结构刚好相反：资本支出低（或转为订阅），运维复杂度转移给供应商，但定制化空间受合同和接口约束，且每月账单是持续刚性支出，业务量越大费用越高，没有"买断"的概念。

三口径下的切换线

与其给结论，不如给判断逻辑。把前几节的三个口径直接套进来：

切换线不是非此即彼的，是加权的。三个口径都指向同一侧，判断就很确定；两个指向开源、一个指向闭源，那个"指向闭源"的口径往往是瓶颈，要单独解决（比如招一个运维工程师，或者把波动并发用弹性云 GPU 承接）。

"开源免费"最常见的误算方式

一个典型的错误决策路径是：看到 Qwen 或 DeepSeek 可以免费下载，就在立项时把模型许可证费用填 0，然后在硬件采购和人力预算上低估，导致项目上线后成本远超预期。

更准确的 TCO 算法应该是：

• 显存采购 = 按第二节的口径算出卡数 × 单卡成本 + 备机冗余
• 运维人力 = 工程师年薪 × 折算到该项目的时间占比，至少按 1 人/年起算
• 机会成本 = 同等人力投入到产品功能的预期产出（这一项很难量化，但不能忽略）
• 对比基准 = 同等调用量下闭源 API 或托管方案的年费

当自采路线的显存利用率长期低于 50%，TCO 拐点通常会倒向托管方案。这个拐点不是固定数字，取决于你的并发分布和硬件折旧周期，但可以用第六节的利用率模型算出来。

开源的真实优势在哪里

去掉"免费"的光环之后，开源的核心价值有两个：

第一是数据主权。权重在本地，推理在内网，日志不出机房——这对金融、医疗、政务场景不是加分项，是准入门槛。闭源 API 在这个约束下根本无法参赛，不存在"哪个更好"的比较。

第二是深度定制空间。微调训练数据、修改推理逻辑、对接私有知识库的方式、调整输出格式——开源模型在这些维度上的自由度，是任何商业 API 的提示词工程都替代不了的。如果你的业务场景需要模型行为高度可控，这个自由度的价值会随时间递增。

闭源的真实优势同样明确：把基础设施风险外包。推理框架升级、模型版本迭代、硬件故障恢复——这些事不是不重要，而是你不需要自己做。对于 AI 不是核心竞争力、只是工具的业务团队，这种外包逻辑完全成立。

可操作的判断流程

在进入具体选型之前，建议按以下顺序回答三个问题：

• 数据和模型能否出内网？——能出，闭源 API 保持候选；不能出，直接锁定私有化，再讨论开源还是商业私有化版本。
• 团队现在有没有人能负责推理框架运维？——有，开源路线可行；没有且短期内无法招募，优先考虑有托管支持的商业方案。
• 并发利用率能否支撑自采回本？——按第六节的拐点模型算，能过线则自采，过不了线则云上按需付费。

这三个问题都有明确答案之后，开源还是闭源的选择基本上已经被约束条件决定了，不需要再做"技术哲学"层面的判断。

成本与回本：云上还是自采，算利用率拐点

到这一步，前面三个口径已经把"需要多少算力"框定了。剩下的问题只有一个：这些卡是租还是买。很多团队在这里凭直觉站队——觉得"自己买才安心"或者"上云才灵活"——但这是一道纯粹的算术题，变量就是利用率。把利用率算清楚，结论会自己浮出来。

先看最常见的 7B 单卡场景，因为它是大多数私有化项目的起点。按目前市场行情粗估，租用云上 GPU 实例跑一整年，费用大致在三到五万元这个量级；如果选择一次性把卡和机器买回来，前期投入大约是十到十五万元。注意这两个数字不在同一维度：前者是每年都要续的运营支出，后者是砸下去一次、之后逐年摊薄的资产。带宽、存储、机房这些配套成本两边都得另算，且自采这边往往被低估——一台服务器进了机房，电费、运维人力、备件的隐性账单会一直挂着。

真正决定结论的是回本周期，而回本周期由利用率倒推。换个更直观的算法：一台配 A100 的本地服务器，把三年的维护成本一起算进去，总投入差不多落在八万美元的量级。同样的算力如果走公有云按需计费，每小时成本大约五美元。把八万美元除以每小时五美元，得到一万六千小时左右的等效使用量。这就是临界点——只要你的真实负载在两年内能消耗掉这么多机时，自采就开始比租用划算；跑得越久、越满，省下的越多。

关键在"真实负载"这四个字。一万六千小时听起来很多，但如果一张卡是 7×24 常驻在线服务，一年就有八千多小时，两年正好覆盖。换句话说，对于一个稳定吃满的推理服务，自采两年回本之后，第三年往后几乎是净赚。但现实里很少有负载能持续打满。如果你的卡平均利用率只有三成，那一万六千小时要拖到五六年才跑得完——而 GPU 三五年就该考虑换代了，回本窗口可能根本等不到。

所以拐点判断可以归纳成两类负载形态：

• 高利用率、长期常驻：典型如面向全员的内部问答、固定批处理管线、生产环境里持续吞吐的在线服务。这类负载吃满卡、跑得久，自采的一次性投入会被时间稀释，长期算下来明显更省，而且数据完全不出域，合规口径也顺带满足。
• 低频、波动、突发：比如季度性的报告生成、不定期的实验性项目、白天忙夜里闲的人机交互场景。为峰值买一堆常年闲置的卡是最贵的浪费，按需租用才能让成本贴着实际用量走，需求降了随手就能缩容。

实际项目里，这两类往往同时存在。一个务实的做法是混合切分：把那部分稳定、可预测、必须本地化的核心负载用自采机器扛住，把弹性的、尝鲜的、峰值的部分甩给云上按需。这样既守住了基线成本，又不为波动买单。

还有两笔账容易在拍板时被漏掉。其一是机会成本：自采的钱压在硬件上，这部分资金本可以投到别处，而 GPU 一旦买定，型号就锁死了，下一代性价比翻倍时你只能干看着。其二是利用率的"虚高"陷阱——很多团队把"卡开着"当成"卡在用"，但空转的显存不产生任何价值，回本算式里要填的是有效推理时长，不是开机时长。建议上线后先用云上按需跑一两个月，把真实的日均请求量、峰谷比、平均利用率压出来，再拿这些实测数字去套上面的临界点公式。

一句话收口：云还是自采，不是偏好问题，是利用率问题。先量出你的负载到底有多满、跑多久，让数字替你做决定，而不是反过来用采购决定去迁就一个拍脑袋的预期。

规模—硬件对照表：把口径落到具体采购单

前几节讲的显存、并发、合规三个口径，最终都要落到一张采购单上。下面按参数规模分三档，给出硬件配置的工程判断，以及每档适合的业务场景。

三档规模对照

7B：验证期的合理起点

7B 模型的权重本体约占 14 GB 显存（FP16），单张 24 GB 卡在加载完权重后还剩约 10 GB 给 KV Cache，支撑十几路并发基本够用。RTX 4090 适合预算敏感的内部测试环境，A10 的 ECC 显存和数据中心散热规格更适合常驻服务。如果团队已有 A100 40G，直接复用即可，不必额外采购。

这一档的核心价值是验证：业务流程跑得通吗？提示词工程有没有卡点？数据管道是否完整？用低成本硬件把这些问题跑清楚，比直接上大集群再推倒重来要划算得多。

14B–40B：精度需求驱动多卡并行

当业务场景对准确率有明确要求——比如法律条款比对、科研文献综述、医疗影像报告生成——7B 的推理深度往往不够。40B 量级的模型在这类任务上有结构性优势，但代价是显存需求超出单卡上限，必须做张量并行或流水线并行。

以放射科报告生成为例：在专科标注数据上对大模型做监督微调，术语准确率相比基线可以有明显提升。这个提升幅度在很多临床场景下是能否上线的分水岭。同样的微调策略用在 7B 上，受限于模型容量，提升空间要窄得多。

硬件侧，更大规模的模型需要相应增加显卡数量做多卡并行。如果预算允许，H20 的显存带宽更高，在长序列推理下吞吐量更好。

70B–72B：中文长文本的上限配置

70B 模型的权重本体接近 140 GB，FP16 加载必须跨卡。多卡集群是目前最常见的生产配置——除去权重和运行时开销，KV Cache 仍有相当余量，在长上下文下能支撑一定规模的并发，延迟维持在秒级。

中文优化的 72B 模型（如 Qwen-72B）在长文档理解、多轮对话连贯性上表现明显好于同规模的非中文优化版本，这对国内企业部署的实际体感影响较大。如果业务里有大量中文长文本处理，这一档是值得认真评估的选项。

值得注意的是：8 卡集群的采购和运维成本相当可观，上这个配置前应当先用前几节的并发口径算清楚实际 QPS 需求。如果峰值并发不高，70B 更多是精度需求而非吞吐需求驱动的决策。

降本路径：蒸馏而非降档

很多团队在 70B 跑通业务后，面临的真实问题是：推理成本太高，但直接换成 7B 精度又掉得难以接受。知识蒸馏是这个矛盾的工程出口——用已经在业务数据上微调好的 70B 模型作为教师，指导 7B 模型的训练过程。行业实践中这条路径在保留约 90% 性能的同时，可以将推理算力压缩到原来的十分之一左右。

蒸馏不是银弹：它需要高质量的教师模型输出作为训练信号，对标注数据和训练流程有额外要求。但对于已经在大模型上跑通业务逻辑、进入降本阶段的团队，这是比重新选型更稳妥的路径。

选型决策顺序

• 先定精度下限：业务对准确率的最低要求决定参数规模的下限，这一步不能靠拍脑袋，要用真实业务数据跑基准测试。
• 再算并发预算：用第二节的显存公式，从目标 QPS 和上下文长度反推所需显卡数量。
• 核对合规约束：数据本地化、等保要求、审计日志等硬约束影响部署架构，在采购前必须明确。
• 评估蒸馏可行性：如果精度需求指向大模型但成本压力明显，把蒸馏路径的工程成本也算进来，再做最终决策。

硬件配置没有通用答案，但三个口径给了一套可以反复代入具体数字的框架。把业务参数填进去，采购单自然就出来了。

FAQ：私有化选型里最常被问到的四个问题

按「7B=20GB」买了卡，为什么一上线就显存爆了？

因为那个估算只算了权重这一块地板，没算上推理时真正吃显存的几个大头。一张卡能不能扛住，得把四笔账加在一起：模型权重、KV Cache、运行时框架本身的占用、以及碎片化导致的浪费。

权重是固定的，FP16 精度下 7B 参数确实在 14GB 上下，加上一些常驻开销凑到 20GB 没错。问题出在后面三笔。KV Cache 随着并发请求数和上下文长度线性增长——同时挂着十几个长上下文会话，这部分能轻松吃掉十几 GB。推理框架自身要预留显存池、缓存编译产物，也要占几个 GB。再加上动态分配带来的碎片,标称剩余和实际可用之间往往差出一截。

所以更稳妥的做法是反过来推：先定下要支撑的并发数和最大上下文长度，按这个算出 KV Cache 的峰值需求，再叠加权重和框架开销，最后留 15% 到 20% 的余量。把上线场景的峰值算清楚，比套用「参数量乘以二」的口诀靠谱得多。如果你发现显存刚好卡在临界点，那基本等于没留余量，第一个流量高峰就会被打穿。

强监管行业是不是只能选开源私有化、不能用商业平台？

不是。这是把「合规」和「开源」两个概念绑在了一起，但它们解决的根本不是同一件事。合规真正要求的是数据不出域、有审计链路、能定责追溯、模型行为可控这几条硬约束。能不能满足这些，取决于部署形态和合同条款，而不取决于模型权重是否公开。

很多商业大模型同样提供私有化或专属部署的交付方式，把推理服务整体放进你自己的机房或专属网络区域里，数据全程不离开边界。这种形态下，它满足数据不出域的能力和开源模型部署没有本质区别。真正要核对的是几个具体问题：服务是否完全在你的网络内运行、有没有任何回传遥测、日志和审计能否对接你现有的安全体系、出了问题厂商能否配合定责。

反过来说，开源模型也不会自动合规。你自己部署一套开源模型，审计、访问控制、数据脱敏这些工程仍然要自己搭。所以正确的问法不是「开源还是商业」，而是「这套交付方案能不能逐条满足我的硬约束」。把合规清单列出来去对照，比按模型出身站队要清醒。

首 Token 延迟小于 1 秒是硬指标吗，内部用也要满足吗？

不是普适硬指标，它完全跟着使用场景走。对外的实时对话、客服问答这类场景，用户盯着屏幕等响应，首 Token 慢一点体验就垮，这时候延迟才算硬约束。但内部场景里有大量任务根本不在乎这个。

典型的反例是批量处理：夜间跑文档摘要、批量生成报告、离线数据标注，这些任务关心的是单位时间能处理多少条，也就是吞吐量，而不是单条请求多快返回。对这类负载，你完全可以把批处理的 batch 开大、把延迟换成吞吐，同样的卡能多干好几倍的活。如果硬套「首 Token 小于 1 秒」去配置，反而是在浪费算力。

所以定指标之前先分清楚负载类型：交互式的看首 Token 延迟和每秒出字速度，批处理的看整体吞吐和单位成本。混合负载最好在调度层面就把两类请求分开，给交互请求留低延迟通道，把批处理塞进空闲时段。用一套延迟标准卡所有场景，要么体验不够，要么钱花冤了。

云上和自采怎么选，有没有简单算法？

有一个够用的近似判断：算利用率。核心是把自采硬件的总持有成本摊到它的生命周期里，折算成每小时的等效成本，再和云上按量计费的单价比。

具体做法是先估你的真实负载曲线——平均每天有多少小时卡是真正在跑的。如果你的业务是全天候高负载、利用率长期压在高位，自采的单位成本通常会明显低于云上租用，前期投入能在一到两年内摊平。如果负载是明显的波峰波谷、白天忙夜里闲，或者总量还不大、需求还在变，那云上的弹性更划算，你不用为闲置的卡持续付钱。

除了这条利用率拐点，还有几个不进公式但要拍板的因素：自采意味着你得自己扛硬件运维、故障替换、机房和电力；云上省心但长期看总账可能更高，还要确认数据合规上能不能接受。一个稳妥的折中是混合——基础稳定负载用自采兜底，峰值溢出用云上弹性顶上。先别急着下单，把未来一年的负载曲线画出来，拐点自然就显现了。