① 直接调 API
零运维、按量付费、能力上限最高。代价是数据出域，长期用量大时单价不会下降。
适合：验证阶段、用量波动大、闭源模型刚需
② 私有化部署
开放权重模型跑在自己机房或专有云，数据不出内网。要算显存、并发与运维人力。
适合：数据合规硬约束、用量稳定且大
③ 单机 / 工作站
个人用一张卡或一台整机跑量化模型，离线可用、没有 token 账单，能力上限受显存限制。
适合：隐私敏感、断网环境、学习与内测
显存估算器
权重 + KV 缓存 + 框架开销config.json 改层数、KV 头数与头维度 —— 这三项对 KV 缓存的影响是线性的。
KV = 2 × 层数 × KV头数 × 头维度 × 上下文 × 并发 × 2 字节
合计 = 权重 + KV + 权重 × 15%（框架 / 激活 / CUDA graph 余量）
单 token KV 开销 –（）。KV 缓存随上下文长度和并发线性增长，是唯一能靠调度策略直接压下来的部分。
需要几张卡
硬件从哪买
品牌整机 / 一体机
预装好推理环境，开箱可用，有整机保修与上门服务。代价是溢价明显，配置组合也受厂商限制。企业采购走这条最省事。
自组 / 服务器整机
按显存需求自选卡与主板，性价比最高。但要自己解决散热、电源余量与 PCIe 通道分配，保修也是分部件走的。
租卡（云上 GPU）
先租后买：用真实负载验证吞吐，再决定要不要采购硬件。适合用量还没过平衡点、或想先验证模型的场景，按小时计费。
推理引擎怎么选 · 并发怎么估
推理引擎怎么选
先看并发，再看硬件| 引擎 | 强在哪 | 什么时候别选 |
|---|---|---|
vLLM 高并发服务 |
PagedAttention 做显存分页，连续批处理成熟，是「多并发 + 高吞吐」的默认起点。生态与文档最全。 | 单卡跑小模型、追求极简部署时偏重；极端低延迟场景要另做调优。 |
SGLang 结构化与 Agent 场景 |
前缀复用和结构化输出优化明显，多轮对话、Agent 工具调用这类「共享长前缀」的负载优势大。 | 单轮短请求为主时优势发挥不出来，收益取决于你的前缀复用率。 |
llama.cpp / Ollama 单机与量化 |
CPU + GPU 混合、量化格式支持最广，一张消费卡甚至纯 CPU 都能跑。Ollama 把部署门槛压到最低。 | 要扛并发服务时不是它的战场；多人同时用会明显受限。 |
选型顺序建议：先定并发量级，再定硬件，最后选引擎。反过来做（先挑引擎再补硬件）几乎一定会返工。
并发怎么估：装得下不等于跑得动
显存之外，第二个容易翻车的地方并发需求不是拍脑袋定的，它由流量和延迟共同决定：
例：峰值 5 QPS、平均响应 4 秒 → 需要稳定支撑约 20 个并发
算出这个数之后，再去乘 KV 缓存的单并发占用 —— 上面估算器里的「并发数」填的就是它。很多人只按「权重装得下」买卡，结果并发一上来就 OOM 或排队到超时。
KV 缓存才是并发杀手
每多一个并发就多一份 KV 缓存，且随上下文长度线性增长。同样一张卡，8K 上下文能扛的并发可能是 128K 上下文的十几倍。先想清楚真实上下文需求，再决定要不要为峰值买单。
排队往往比加速更划算
吞吐不够时，先考虑连续批处理（vLLM / SGLang 都默认开启）与请求排队，而不是立刻加卡。把峰值削平，通常比堆硬件便宜得多。
量化 · 运维 · 私有化的隐性成本
量化：省下来的显存，代价要用你自己的数据验证
通用榜单不能替你做这个判断量化能把显存需求砍掉一半到四分之三（FP16 → INT8 → INT4），代价是模型能力有损。但「损失多少」这件事没有通用答案 —— 它高度依赖你的任务类型：分类、抽取这类任务往往几乎无损，长链推理、代码生成、数学证明对量化敏感得多。
所以本站不列所谓的「量化折损百分比」—— 那些数字换个模型和任务就不成立，列出来就是误导。正确的做法是：
② 分别跑 FP16 与你要用的量化档，同一份样本、同一套 prompt
③ 比较的不是「感觉差不多」，而是失败率与返工率
④ 只有当量化后的失败率仍在你可接受范围，才算省对了钱
一个实用提醒：如果量化后你得靠重试、人工复核来兜底，那点省下来的显存很可能被运维成本吃掉。
运维到底要干哪些活
自建的持续成本，多半藏在这里模型版本跟进
上游出新版本、修复 tokenizer 或工具调用问题时，你得决定跟不跟、什么时候跟、跟完要不要重新验证一遍业务效果。
故障排查
OOM、显存碎片、请求堆积、某张卡掉线 —— 这类问题没有值班的人就只能等你自己发现，通常还是用户先发现。
容量规划
业务量涨了要不要扩容、扩多少、什么时候扩。硬件有采购周期，临时抱佛脚往往要多花钱。
安全与合规
模型权重与推理服务的访问控制、日志留存、数据不出内网的证明。企业场景里这一项常常要写进材料。
这四项的共同点：它们不出现在任何一张报价单上，但都会以人力或加班的形式付出来。估算自建成本时，先问一句「谁来干这些」。
私有化的隐性成本清单
这些都不出现在任何一张报价单上| 成本项 | 为什么容易被漏掉 | 怎么应对 |
|---|---|---|
并发与显存碎片 装得下 ≠ 跑得动 |
按「权重装得下」买卡是最常见的失误。KV 缓存、请求排队、显存碎片会一起把可用并发压下来，而上面的估算器只算了 KV 一项。 | 先用估算器算出真实并发需求，再给显存留 10–15% 余量；上线后用真实流量压一遍再定扩容。 |
量化质量损失 省的是显存，付的是准确率 |
「INT4 只掉一点点」是个没有依据的说法 —— 损失幅度取决于任务类型，长链推理与代码生成对量化要敏感得多。 | 用你自己的测试集做 FP16 与量化档的对照，比失败率和返工率，而不是比感觉。 |
运维人力 是持续支出，不是一次性 |
模型版本跟进、故障排查、容量规划、安全合规四类活都没人报价，但它们真实存在，且往往由你自己的加班消化。 | 在成本测算里如实填「运维 / 人力月摊销」那一栏 —— 哪怕先估一个数，也比当它不存在强。 |
能力上限被锁住 最容易被低估的一项 |
只有开放权重模型能自建 —— 闭源旗舰的能力根本不在你的选项里。这不是成本问题，是选择空间问题。 | 先想清楚「闭源旗舰的能力是不是刚需」。如果是，私有化这条路一开始就不成立。 |