选型会上常见的僵局是：有人说开源能省钱、数据不出门，有人说商用模型效果稳、不用养人。两边说的都对，但都缺一个判断口径。这篇不讲榜单也不评谁强，只给你一套从许可、硬件、并发到合规的排查顺序，以及每一步该去站内哪页核对当时的数字，让你在自己的场景里把账算明白再拍板。
选型会上的僵局往往不是因为哪边更好，而是两边各说各的维度。有人讲开源能省调用费、数据不出内网，有人讲商用模型稳定、不用养人。这两句话都没错，只是放在一起比就像拿月租和房贷比总价，口径根本不一样。下面这套顺序不是评谁强，是帮你按自己场景把不合适的选项先筛掉，剩下的再谈效果。
判断顺序很重要，先看那些"一票否决"的项——数据能不能出内网、许可能不能商用，这两步就能砍掉一半候选。然后再算硬件和人力这类长期支出，最后才轮到手感层面的效果对比。反过来做的话，你会花很多时间测一个根本没法合规落地的模型。每一步涉及的数字都建议到站内对应页面核对当时的版本，别用记忆里的旧数据拍板。
先看许可与数据控制权，这一步就能筛掉一半选项
很多人把"权重能下载"直接等同于"开源可商用"，这是个常见的坑。仓库首页写着 open，条款里可能对月活用户数、转售、衍生模型命名都有额外要求。真正要确认的是：你的使用方式有没有踩到这些限制。如果是内部工具、不对外提供服务，限制通常宽松些；如果要做成产品卖给别人，就得逐条读。
- 分清"权重开放"和"真开源"：能下载不代表能商用，转售、衍生命名、用户规模这些条款要逐条读，别只看仓库首页那句话
- 数据能不能出内网是硬门槛：涉及客户数据、医疗、金融、政务场景时，商用 API 往往第一条就被否掉，这时讨论效果没有意义
- 商用模型的隐性约束在别处：调用条款、内容审核口径、账号封禁与额度限制都是风险点，签合同前让法务过一遍，而不是工程同学自己看
- 拿不准边界时先到 /open-weight-license-basics 对照术语，再到 /safety 看合规口径，别用搜索引擎的二手解读做决策
再算硬件与支出结构：开源省的是单价，不是总账
开源路线的账不是"免费"，而是把调用费换成了三块支出：硬件或租卡、运维人力、推理优化的时间。商用路线看起来是单价乘以用量，但加上预付、最低消费、超额阶梯之后，结构又不一样。拿单价直接对比会得出错误结论，得把两条路放在同一个使用周期里算。
| 成本项 | 开源自建 | 商用 API |
|---|---|---|
| 前期投入 | 买卡或长期租卡，一次性或包月 | 通常无，按量起算 |
| 运维人力 | 要有人盯服务、扩容、排障 | 供应商承担，你只写调用代码 |
| 优化时间 | 量化、推理框架、批处理都要自己调 | 多数由供应商迭代 |
| 用量弹性 | 峰值来了要提前扩容，闲时资源闲置 | 按量伸缩，但可能有限流 |
| 合计口径 | 固定成本为主，用得越多越摊得薄 | 变动成本为主，用得少更划算 |
显存和并发是开源自建的第一道坎。参数量、量化档位、上下文长度这三个变量一起决定要几张卡，单机跑通的感受不能直接拿来估生产环境。先用 /models/deploy 和 /compute/sizing 按自己的峰值并发算一遍，差距往往比想象的大。
什么情况下不适用：调用量很小、或者流量波动极大，自建的固定成本摊不开，这时商用按量付费反而更划算。反过来，如果日均调用量稳定且高，开源的边际成本优势才会显现。
效果比对要按自己的任务做，不能靠榜单排名
榜单和跑分只能告诉你大致水平，具体差多少得用自己的任务测。做法是把场景拆成可验证的样例集，几十条就够看出方向：同一批提示词跑候选模型，人工打分或写规则判分。别等积了几千条评测数据才发现方向选错，那时候迁移成本已经很高了。
- 收集真实样例从线上日志或业务方那里拿几十条真实输入，覆盖常见和边界情况，不要用自己编的干净句子
- 固定提示词和参数同一套提示词、同样的温度等参数跑所有候选，避免变量混在一起
- 定义判分方式能自动判分的写规则，不能的人工双盲打分，记下分歧大的样本回头分析
- 看分布不看均值重点看差样本长什么样，均值差不多但错误类型不同的模型，落地体验差很远
开源侧的天花板在于可微调、可蒸馏、可换量化档位，场景需要深度定制时这条路更宽；商用侧省心在版本迭代，但更新节奏不由你控制，行为可能悄悄变，接入前要想好怎么监测和回退。榜单和跑分只作参考，具体差距要自己测，站内的 /benchmarks 和 /crowd-radar 给的是方法口径，不是替你下结论。
一页决策清单：按顺序回答完就能定
下面五步按顺序走，前面的答案会直接影响后面还要不要比。每一步给出的是判断标准，不是标准答案，因为同一个问题在不同公司权重不同。走完还拿不准的，把不确定项标出来，去站内对应页面找当时的数字补上。
- 数据能不能出内网不能就直接走本地或私有化路线，后面的效果比较基本不用做，省下大量评测时间
- 有没有人能长期维护推理服务没有或人手紧张就优先托管或商用 API，别高估团队的运维余量，出事时没人兜底代价很大
- 峰值并发和日均调用量是多少用 /tools/model-cost-calculator 把两条路按三年周期各算一遍，看总账而不是单价
- 需不需要微调、换量化、离线跑需要就是开源侧加分，不需要就别为用不上的自由度付费和承担运维
- 留一条退路模型换代、供应商调价、条款变更都可能发生，迁移和验证的清单提前写好，别等出事再想
常见问题
开源大模型是不是一定比商用模型便宜？
不一定。开源省的是按次调用的单价，但硬件、运维、优化时间都是真金白银，小流量场景下固定成本摊不开，反而比按量付费贵。判断标准是看日均调用量和波峰波谷，用量越大、越稳定，自建才越划算。
商用大模型能不能私有化部署？
少数厂商提供私有化或专属实例，但通常有最低采购门槛，且模型权重不归你，升级和运维仍受对方节奏影响。真要把数据和权重都握在自己手里，基本只有开源权重这条路，具体条款要到 /safety 这类站内页面核对当时的说明。
先选开源还是先选商用，有没有更省事的顺序？
建议先用商用 API 快速验证业务能不能跑通，把提示词和评测集沉淀下来，再评估要不要迁到开源。反过来先自建，很容易在硬件和运维上花掉时间，结果业务方向还没验证。
