在 14.1 节中，我们对比了闭源 API 与开源私有化部署的路线差异；在 14.2 节中，我们按业务场景给出了模型选型的初步建议。但无论你选择哪条路线、哪个模型，最终都逃不开一个铁三角约束：效果要好、成本要控、上线要快——三者同时最优几乎不可能。
本节把这个“不可能三角”拆开算一笔明账。这里的“成本”不只是买显卡或调 API 花的钱，而是包含显存、人力、时间、机会成本在内的全生命周期开销。掌握这些权衡逻辑，是避免“立项时吹 GPT-4，上线后跑 7B 蒸馏版”这类尴尬局面的关键。
一、模型规模：边际效益递减的“甜蜜点”
参数量是效果最直观的代理指标，但它与收益的关系绝非线性。
Scaling Law 的残酷现实：随着参数量增大，模型在通用基准（如 MMLU、GSM8K）上的得分确实持续提升，但提升斜率不断放缓。一个 70B 模型通常比 7B 强很多，但 700B 相比 70B 的提升往往远小于其 10 倍的资源消耗。具体到业务场景：
| 参数量级 | 典型定位 | 效果边际 | 资源拐点 |
|---------|---------|---------|---------|
| 1B–3B | 端侧/分类任务 | 基础语义理解可用，逻辑弱 | 手机/边缘设备可跑 |
| 7B–13B | 垂直微调主力 | 性价比最陡峭区间，微调后往往可达大模型 80% 效果 | 单卡 A100/L40 可训可推 |
| 30B–70B | 复杂推理/通用中台 | 逻辑、代码、多轮对话显著增强 | 必须多卡并行，工程复杂度陡增 |
| 100B+ | 基座/战略级 | 通用能力天花板，但垂直收益不一定碾压 70B | 千卡训练、专业 Infra 团队兜底 |
实用结论：
- 不要拿通用基准分数直接等同于业务收益。如果你的任务是结构化抽取（如从病历中抽字段），一个经高质量数据微调的 7B 模型，效果可能超过零样本的 GPT-4，且延迟低一个数量级。
- 规模带来的隐性成本被严重低估。70B 模型不仅吃显存，还需要张量并行（TP）、更大的通信带宽、更复杂的故障排查。团队如果没有多卡分布式推理经验，7B 到 70B 的跨度不只是“加几张卡”，而是工程复杂度的质变。
二、推理成本：被低估的“第二座山”
很多团队做预算时只看训练成本，但在绝大多数商业化应用里，推理成本才是真正的长期大山。训练是一次性投入（Sunk Cost），推理是每来一个用户就要烧一次的运营成本（OpEx）。
2.1 训练成本 vs 推理成本的“冰山模型”
- 训练：一次性。全量微调一个 7B 模型，8×A100 跑 3 天，云成本约 1–2 万元人民币；使用 LoRA 则降至几千元。
- 推理：持续性。假设你的客服系统日均处理 100 万次调用，每次平均 2K tokens，使用 GPT-4 Turbo 级别的商业 API，月均账单可能轻松突破数十万元；若用私有化部署的 7B 模型，月运营成本（电费+折旧+人力）可能只有前者的 1/10。
经验法则：如果你的日活用户 > 1 万、每人每天交互 > 10 轮，就必须严肃对比 API 按量计费 vs 私有化固定成本 的盈亏平衡点。
2.2 推理成本的三个量化维度
| 维度 | 计算方式 / 经验值 | 业务影响 |
|------|------------------|---------|
| 显存占用 | FP16/BF16 下约 2 GB / 1B 参数（仅权重）；加上 KV-Cache 和系统开销，70B 模型实际需 140–160 GB+ | 决定最低需要几张什么型号的卡 |
| 单 Token 延迟 | 7B 在 A100 上约 5–15 ms/token；70B 多卡并行约 20–50 ms/token | 决定用户是否感到“卡顿” |
| 并发吞吐 | 受限于显存容量和批处理策略；vLLM 等框架可将 7B 吞吐量提升 5–10 倍 | 决定同样硬件能服务多少在线用户 |
真实案例：某教育公司最初用 GPT-4 做作文批改，效果极佳但单篇成本 0.3 元，日活 10 万时无法盈利。后切换为自研 13B 模型 + 量化（INT4），单篇成本降至 0.02 元，效果下降 8% 但可接受，商业模式立刻跑通。
三、开发周期：时间是最不可再生成本
在模型选型中，开发周期常被技术团队忽略，却被业务方极度敏感。三条典型路径的周期差异巨大：
| 路径 | 代表工作 | 技术周期 | 适用阶段 |
|------|---------|---------|---------|
| 直接调用闭源 API | Prompt 工程、RAG 搭建、输出解析 | 1–3 周 | MVP 验证、黑客松、轻量级应用 |
| 开源模型 + 微调 | 数据标注、LoRA/全参数微调、部署优化 | 1.5–3 个月 | 产品 PMF 验证、垂直领域深耕 |
| 从头预训练 / 深度定制 | 数据清洗、千卡训练、持续对齐、评估迭代 | 6–12 个月+ | 平台级战略、极端数据安全要求、超大用户量 |
关键权衡：
- 用 API 抢时间：如果你的赛道窗口期只有 3 个月，直接调 GPT-4/Claude/Qwen-Max API 是最理性的选择。先验证需求真实存在，再考虑降本。
- 用开源换自主权：如果客户要求数据不出域、或者你需要在特定风格/知识上深度定制（如法律合同审查），必须接受 1–3 个月的工程周期。
- 预训练是极少数人的游戏：除非你是头部云厂商或拥有独特数据飞轮的大厂，否则不要从头预训练基座模型。这个选择在 2024 年已基本失去商业合理性。
机会成本警示：一个团队花 6 个月自研 13B 基座模型，可能错过了用开源 70B 模型 + 2 周微调就能占领市场的窗口。
四、三维权衡框架：一张决策清单
面对具体项目时，建议用以下三个问题自测，快速收敛选型：
问题 1：效果天花板是否可妥协？
- 不可妥协（如医疗诊断辅助、金融合规审核）：优先保效果，选用当前最强模型（GPT-4 / Claude-3.5 / Qwen-72B），通过 RAG 和严格流程控制来弥补成本。
- 可妥协（如营销文案生成、闲聊客服）：果断选用 7B–13B 级模型，投入精力做数据微调和提示工程。
问题 2：单位经济模型是否成立？
计算你的 Cost Per Query（单次查询成本） 与 ARPU（用户平均收入） 的关系：
单次查询成本 = (月推理成本) / (月查询次数)- 如果单次查询成本 > 用户贡献毛利的 10%，必须降规模或上量化/蒸馏。
- 如果单次查询成本 < 用户贡献毛利的 1%，可以暂时不必极致优化，优先保体验。
问题 3：团队工程底子在哪个水位？
- 无专职 AI Infra：上限基本是单卡 7B/13B，或直接使用云 API。
- 有 1–2 名算力工程师：可驾驭多卡 70B 推理 + LoRA 微调。
- 有成熟算法平台团队：才值得考虑全参数微调、MoE 部署、自研模型。
五、降本增效的工程技术手段
如果三者不可兼得，现代工程手段提供了“骑墙”的可能：
| 手段 | 效果损失 | 成本收益 | 适用场景 |
|------|---------|---------|---------|
| LoRA/QLoRA 微调 | 极小（<3%） | 训练显存降 50%+，可消费卡训练 | 绝大多数垂直场景首选 |
| INT8/INT4 量化（GPTQ/AWQ） | 中低（3–8%） | 显存减半或四分之一，吞吐提升 | 高并发推理必备 |
| 模型蒸馏（Distillation） | 中等（5–15%） | 用小模型继承大模型能力，推理快 5–10 倍 | 已有大模型标注数据，需降本 |
| 大小模型级联 | 按需 | 简单 query 走 7B，难的走 70B/API，综合成本降 60%+ | 查询难度分布不均的系统 |
| Prompt 缓存 / KV-Cache 复用 | 无 | 重复前缀计算共享，长对话场景显著降延迟 | 多轮对话、文档批量处理 |
真实组合策略：
某智能客服系统采用“7B 小模型做首轮意图识别 + 13B 模型做标准问答 + GPT-4 API 兜底复杂客诉”的三层架构。结果：80% 流量成本极低，15% 流量成本中等，仅 5% 流量调用高价 API，整体效果与纯 GPT-4 方案接近，但月度 AI 成本下降 85%。
六、小结
模型规模、推理成本、开发周期构成选型的铁三角。没有 universally optimal（放之四海而皆准）的选择，只有给定约束下的帕累托最优：
- 早期验证：闭源 API，小步快跑，别自研；
- 规模扩张：开源 7B–13B + 量化 + LoRA，建立成本护城河；
- 深水区竞争：70B 级模型 + 工程极致优化（投机解码、连续批处理、多级缓存），或采用 MoE 架构平衡总参数量与激活成本。
在做出最终决策前，不要让纸面参数替你做决定。14.4 节将提供一套可落地的模型能力评估与选型测试流程，教你用真实业务数据，在 2 周内跑完“测效果—算成本—定规模”的闭环。