开放权重、开源，还是只能调 API？你到底在选什么？
权重、许可证、数据、托管和更新是不同的决定；在本地运行或把模型放进产品前，先用一张清单把它们分开
本页解决的问题
先给结论开放权重、开源，还是只能调 API？你到底在选什么？
权重、许可证、数据、托管和更新是不同的决定；在本地运行或把模型放进产品前，先用一张清单把它们分开
让这个结论先证明自己值得留下。 把这一页当成决策工具，而不是需要背下来的定义。把概念连到一个真实任务、一个可观察结果，以及一个能改变你判断的失败上。
写下一个问题：试完这个方法后，你能用什么证据回答它？
结论听起来很完整，却没有检查最关键的假设。
开放权重让你更能控制模型在哪里、怎么运行；API 让你少操心基础设施。真正的选择取决于许可证、数据、硬件、可靠性和谁负责更新。
开放权重
训练好的参数可以下载，或通过托管服务使用。你可以在具体许可证允许的范围内检查、改造或部署；训练配方和数据可能仍然不公开。
开源
人们经常把这个词用得很宽泛。要追问到底公开了什么：代码、权重、数据、文档，还是全部？公开的代码仓库，不自动等于所有用途都被许可。
只能调 API
你调用托管端点，服务商负责运行模型的整套基础设施。你获得升级和弹性，但要评估访问条件、日志保留、价格变化、速率限制和对服务商的依赖。
| 问题 | 托管 API | 自托管开放权重 | 托管开放权重 |
|---|---|---|---|
| 最快上线？ | 通常是 | 不是——要自己部署、加固和观测 | 如果服务商支持这个权重，通常可以 |
| 数据控制 | 取决于服务商条款和配置 | 你控制服务边界 | 共同负责；要确认线路和区域 |
| 能力上限 | 可以使用服务商当前的前沿模型 | 受所选权重和硬件限制 | 受所选权重和托管方限制 |
| 成本形状 | 按用量变化；固定启动成本低 | 硬件、人力、电力和维护 | 用量费或预留容量，加平台费用 |
| 更新负担 | 服务商改变服务 | 你决定何时升级 | 协调托管方和权重版本 |
| 退出和迁移 | 需要适配器和迁移计划 | 控制更多，但模型和许可证仍然重要 | 取决于服务接口有多容易迁移 |
读准确的许可证
“Llama”“Mistral”“Qwen”“Gemma”等系列，每次发布的条款都可能不同。直接查看当前版本对商业使用、再分发、微调、可接受用途、署名和地域的要求。
计算完整系统成本
权重只是模型本身。还要加上推理硬件、量化、批处理、存储、可观测性、防提示词注入、评测和谁负责值守。
不要把本地等同于私密
本地模型仍可能通过日志、遥测、插件、备份或外部检索服务泄露。画出完整的数据路径，再逐条测试。
提前安排升级路径
固定权重和分词器，保留回归测试集，让提示词和输出格式尽量可迁移。即使 API 不变，模型升级也属于产品变更。
「三个标签，三种不同的说法」要放回选型约束
「开放权重让你更能控制模型在哪里、怎么运行；API 让你少操心基础设施。真正的选择取决于 许可证、数据、硬件、可靠性和谁负责更新」说明，模型、许可证、接入方式和榜单都只是信息，不是脱离场景的答案。真正的选择取决于任务、数据边界、延迟、质量下限和运行成本。
先写淘汰条件，再看最高分
「训练好的参数可以下载，或通过托管服务使用。你可以在 具体许可证 允许的范围内检查、改造或部署；训练配方和数据可能仍然不公开」涉及的比较，至少要使用同一组真实输入，并同时观察正确性、失败方式、响应时间和费用。一个在公开榜单上领先的模型，可能因为许可证、隐私要求或峰值延迟不适合你的任务。
- 控制更多，也意味着责任更多： 托管、安全、更新和事故响应都要有人负责
- 本地运行不自动等于私密； 要检查每一条数据路径
- 分析单位应该是准确的权重版本和许可证， 而不是模型系列的名字
没有测试集，就没有可靠的赢家
以「固定权重和分词器，保留回归测试集，让提示词和输出格式尽量可迁移。即使 API 不变，模型升级也属于产品变更」为起点，选几条真正会影响决策的输入，写下一个会改变选择的反例；这比记住一次排名更能支持下一次判断。
从「三个标签，三种不同的说法」走到「决策矩阵」
「三个标签，三种不同的说法」先把问题落在「训练好的参数可以下载，或通过托管服务使用。你可以在 具体许可证 允许的范围内检查、改造或部署；训练配方和数据可能仍然不公开」上；到了「决策矩阵」，讨论继续推进到「问题 托管 API 自托管开放权重 托管开放权重 最快上线？ 通常是 不是——要自己部署、加固和观测 如果服务商支持这个权重，通常可以 数据控制 取决于服务商条款和配置 你控制服务边界 共同负责；要确认线路和区域 能力上限 可以使用服务商当前的前沿模型 受所选权重和硬件限制 受所选权重和托管方限制 成本形状 按用量变化；固定启动成本低 硬件、人力、电力和维护 用量费或预留容量，加平台费用 更新负担 服务商改变服务 你…」。两段连起来，重点就不只是记住一个结论，而是看清它成立所依赖的条件。
把这条判断带到下一个场景
做模型选择时，先用真实任务写出不能妥协的条件，再用同一组输入比较质量、失败方式、延迟、许可和成本；榜单只适合作为起点。
- 「三个标签，三种不同的说法」：训练好的参数可以下载，或通过托管服务使用。你可以在 具体许可证 允许的范围内检查、改造或部署；训练配方和数据可能仍然不公开
- 「决策矩阵」：问题 托管 API 自托管开放权重 托管开放权重 最快上线？ 通常是 不是——要自己部署、加固和观测 如果服务商支持这个权重，通常可以 数据控制 取决于服务商条款和配置 你控制服务边界 共同负责；要确认线路和区域 能力上限 可以使用服务商当前的前沿模型 受所选权重和硬件限制 受所选权重和托管方限制 成本形状 按用量变化；固定启动成本低 硬件、人力、电力和维护 用量费或预留容量，加平台费用 更新负担 服务商改变服务 你…
- 「最后的要点」：分析单位应该是准确的权重版本和许可证， 而不是模型系列的名字
最后的「最后的要点」把讨论落到「分析单位应该是准确的权重版本和许可证， 而不是模型系列的名字」。回看这条线索时，最值得保留的是：当输入、规模或风险改变，哪些判断需要重新做一遍。
✅ 这页想和你分享的事
- 先问“什么是开放的”，再问“是不是开源”。
- 控制更多，也意味着责任更多：托管、安全、更新和事故响应都要有人负责。
- 本地运行不自动等于私密；要检查每一条数据路径。
- 分析单位应该是准确的权重版本和许可证，而不是模型系列的名字。
我把这篇文章里的一个判断改写成了今天可以验证的小实验。比记住结论更有用的是，知道下一步要观察什么。
读完以后我先回头找它成立的条件，而不是直接把方法搬进项目。这个顺序让后面的取舍清楚很多。
如果把这个判断放到真实工作里，最先需要补的约束是什么？我想知道从阅读到第一次实践之间，哪一步最值得先做。
还没有这篇文章的讨论。