模型选型这件事，表面上看是比拼跑分和榜单，实际上落到工程层面，真正决定选择的往往是账本、延迟曲线、合规红线和团队能力。闭源模型和开源大模型各有清晰的适用边界，搞混了边界，要么把钱花冤枉，要么把项目拖进泥潭。这篇文章把四个关键维度逐一拆开分析，最后给出一套可以直接套用的决策流程。
成本：计费模式和总拥有成本是两回事
闭源API的计费逻辑是按token收费，输入和输出分别计价。这种方式在项目初期非常友好，没有硬件投入，没有运维人力，几行代码就能跑通。但它的成本曲线是非线性的：当调用量爬升到一定规模后，账单会以肉眼可见的速度膨胀。以一个日均千万token调用的中等业务为例，按主流模型的价格估算，一年的API费用轻松超过六位数，而且这个成本会随着业务增长持续上升，完全不受自己控制。
开源模型走的是另一条路：显性的硬件成本加隐性的人力成本。自己部署一个70B级别的模型，至少需要多张高端显卡，推理框架的选型、量化策略的调整、服务的监控扩容，每一项都需要工程投入。这笔一次性投入不低，但它换来的是边际成本趋近于零的推理能力。简单算一笔账：如果调用量稳定且量大，自部署通常在一年左右就能摊平成本；如果业务处于验证期、调用量波动大，API模式的灵活性价值更高。
还要注意一个容易忽略的隐性成本：模型版本迭代。闭源API厂商随时可能下线旧版本或调整价格，业务侧被动跟随；开源模型虽然版本控制在自己手里，但要享受新能力就得自己升级、自己验证，人力成本会周期性出现。所以成本对比不能只看单价，要看总拥有成本，即硬件折旧、人力、电费、以及业务风险折价的总和。
延迟与性能：首token时间和吞吐量的真实差距
衡量推理体验的核心指标有两个：TTFT（首token时间）和吞吐量。闭源API的优势在于基础设施规模效应，厂商的集群通常能把首token时间压到几百毫秒以内，用户体感就是“秒回”。但API的延迟受网络链路和厂商负载影响，高峰期可能出现明显抖动，这对实时性要求高的场景，比如语音助手、实时对话，是实打实的风险。
自部署开源模型，延迟取决于自己的硬件和推理优化水平。下面是一个典型的推理压测参考思路：
import time
from openai import OpenAI
client = OpenAI(base_url="http://127.0.0.1:8000/v1", api_key="none")
# 测量首token时间（TTFT）与整体吞吐
start = time.perf_counter()
stream = client.chat.completions.create(
model="local-model",
messages=[{"role": "user", "content": "解释一下KV Cache的作用"}],
stream=True,
)
first_token = None
token_count = 0
for chunk in stream:
if chunk.choices[0].delta.content:
if first_token is None:
first_token = time.perf_counter() - start # 记录TTFT
token_count += 1
total = time.perf_counter() - start
print(f"TTFT: {first_token:.3f}s, 吞吐: {token_count / total:.1f} token/s")通过这类压测可以量化两个关键数字。一般来说，如果显卡资源充足，自部署模型在长文本生成场景下的吞吐稳定性反而优于API，因为不存在多租户争抢。而模型能力本身，经过合适微调和量化后的开源模型，在垂直任务上完全可以逼近闭源旗舰的效果，但在通用复杂推理、长上下文理解这类需要巨量参数支撑的任务上，闭源大参数模型仍有优势。
一个实用的经验是：先明确业务对延迟的容忍度。聊天类产品对TTFT敏感，离线批处理对吞吐敏感，而RAG场景介于两者之间。延迟要求决定了你能不能接受API的网络抖动，也决定了自部署需要什么规格的硬件。
隐私与合规：数据出域是一条硬边界
这是四个维度里最没有商量余地的一项。金融、医疗、政务等场景中，用户数据不允许离开自有环境，闭源API基本直接出局，哪怕厂商承诺数据不用于训练，传输和存储环节依然存在合规争议。这类场景下，开源模型的私有化部署几乎是唯一解。
需要注意开源不等于无限制。开源模型的许可证分为多种类型：Apache 2.0、MIT这类宽松协议允许商用和修改；有些模型采用自定义协议，对商用规模、月活数量有限制。选型前必须读清许可证条款，否则埋下的法律风险比技术问题难处理得多。此外，即使模型权重开源，训练数据来源的合规性仍需评估，特别是在生成内容可能触达终端用户的产品里。
折中方案也值得考虑：敏感数据脱敏后调用API处理非敏感部分，核心数据走本地小模型，通过路由层按数据敏感度分发请求。这种混合架构在不少企业里已经落地，既控制了成本又守住了合规底线。
一套可落地的选型决策流程
把前面三个维度整合起来，可以按以下顺序做判断：
- 第一步，先过合规红线。数据不能出域就直接走私有化部署，候选范围锁定开源模型。
- 第二步，评估调用规模。日均token量在百万以下且增长不确定，优先API快速验证；稳定在千万级以上，做自部署的成本核算。
- 第三步，匹配任务难度。通用复杂推理选闭源旗舰或超大参数开源模型；垂直任务选中等参数开源模型加微调，性价比通常最高。
- 第四步，盘点团队能力。没有推理优化经验且短期内不打算补齐，自部署的隐性成本会被严重低估。
最后强调一点：选型不是一次性的决定，而是持续校准的过程。推荐从小规模API验证开始，用真实业务数据建立效果基线，再决定是否迁移到自部署方案。同时保留模型切换的抽象层，比如统一用OpenAI兼容接口调用，把供应商和部署方式的变化隔离在基础设施层。这样无论技术风向怎么变，业务代码都不用推倒重来，这才是应对模型快速迭代最稳妥的工程姿势。