当一个模型可以被下载、放进自己的服务器，甚至在没有供应商网络连接的环境里运行，用户得到的到底是什么？最直观的答案是“控制权”。但控制权取决于能否重建、运行和替换模型，复制模型文件本身不够。数据往哪里走、版本能否固定、模型可否修改、许可证允许怎样使用、供应商停止服务后还能否运行，这些问题各有条件，答案也可能彼此不同。
“开放模型”因此同时涉及资产、部署和治理。权重可得，可能让组织把敏感数据留在指定网络，也可能减少对某个 API 端点的依赖；它并不规定模型一定由谁运行。相同的开放权重既可自行部署，也可交给托管服务商，GPU、内存、监控和补丁是否进入组织自己的工作清单，取决于部署方式。美国国家电信与信息管理局讨论广泛可用的模型权重时，同时列出竞争、创新等潜在收益和安全、隐私、问责风险，并强调未来收益和风险仍有不确定性。[1]
更准确的判断是：开放程度决定用户能取得、修改和转移哪些资产，部署方式决定组织承担多少基础设施、运维和治理责任。开放资产扩大了控制和退出路径的可选范围，却不自动带来低成本、隐私或连续性；实际收益取决于许可证、资产完整度、负载、工具链、更新承诺和组织能力的组合。要看清这组关系，先要拆开“开放”这个词。
1. 模型究竟开放了什么
实际采购中，一个反复出现的误会是把“可以下载”当成“开源”。至少有三种状态需要区分：开放访问、开放权重，以及符合开放源码定义的 AI 系统。
开放访问通常指用户能通过网页或 API 使用模型，服务商并未交付权重。用户获得调用能力，却不能决定模型在哪台机器上执行，也不能在端点关闭后自行恢复。开放权重把训练后的参数交给用户，使本地推理和进一步修改成为可能，但训练代码、数据说明、评测工具、训练脚本或再分发权利仍可能缺失。是否构成开放源码系统，还要看修改系统所需的组件是否齐备，以及许可证是否允许使用、研究、修改和分享。
Open Source Initiative 的《Open Source AI Definition 1.0》把这些自由写得很具体：使用系统、研究其工作方式、修改系统，以及分享原系统或修改后的版本。[2] 这是一套定义，不是自动适用于各国的法律条文，也不能代替对具体许可证的审查。它的实用价值在于提醒采购者：调用权限、文件可得和法律权利不是同一件事。
Model Openness Framework 则从模型生命周期组件出发，把开放度和完整度分开，并列出模型架构、最终检查点、技术报告、评测、数据卡、训练与推理代码等组件。[3] 它只是核对工具，不能给模型颁发法律意义上的“开源证书”；模糊标签不应遮住缺失的资产。
具体发布能说明这种差异。OpenAI 的 gpt-oss-120b 和 gpt-oss-20b 以 Apache 2.0 许可证发布开放权重；官方 README 同时提供推理示例、工具和部署信息，并说明 MXFP4 量化下，120B 版本可在单张 80GB GPU 上运行，20B 版本可在 16GB 内存内运行。[4] 模型卡将两者称为开放权重模型，并分别记录 tokenizer 和代理式工具使用设计。[5] 这些材料支持“用户取得了一套可运行和修改的核心资产”，却不能推出训练数据、数据授权链和完整训练流程已经公开。
许可证会继续收窄或扩大这种控制。Llama 3.1 Community License 的 §1.b.i 对分发时的标识和模型命名作出规定；§2 的另行许可条件只针对一个特定门槛：在 2024 年 7 月 23 日该版本发布日，被许可方或其关联方提供的产品或服务在前一自然月超过 7 亿月活。达到该条件者须向 Meta 申请许可，在 Meta 明示授权前不能行使协议所授权利。[6] 这比一句“月活超过 7 亿要申请”精确，也说明许可判断必须回到版本、主体和适用日期。
DeepSeek-R1 的情况不同。官方 README 的许可证小节写明代码仓库和模型权重采用 MIT，同时逐项指出，基于 Qwen 的蒸馏模型源自 Apache 2.0 基础模型，基于 Llama 的蒸馏模型仍关联相应 Llama 许可证。[7] 因此，不能把一个仓库顶层的许可证概括到所有下游变体；迁移或再分发时要核对实际模型包和基础模型条款。
把差异放进验收表，开放至少涉及四层权利。读取权回答组织能否取得权重、配置和文档；运行权回答能否在指定硬件和地区部署；修改权回答能否微调、量化、剪枝或替换推理代码；转移权回答修改后的资产能否交给关联公司、客户或另一家服务商。一个模型可能在前三层限制较少，却在第四层受到标识、规模或基础模型条款约束。
“能继续推理”和“能复现训练”也必须分开。OSI 把数据说明、处理和训练代码、参数列为机器学习系统的首选修改形式。[2] MOF 进一步把模型组件和开放等级对应起来。[3] 权重、tokenizer 和推理实现是继续推理所需的核心资产，但并非充分保证：模型配置、运行库、转换工具、驱动、量化格式和兼容硬件也必须能够重建。若目标是复现训练，还要补上数据来源、清洗方式、训练代码、超参数和计算环境。
采购评审由此不应只问“有没有权重”。更有用的问题是：哪些组件能取得，许可证是否兼容组织的业务方式，修改后的模型能否合法交付，配置和依赖能否归档，安全修复由谁提供。答案含糊时，开放带来的控制可能只停留在下载文件，而不是可执行的退出能力。
2. 控制权增加，但隐私和连续性不会自动兑现
模型运行在组织控制的网络里，确实可以改变数据流向。客服记录、内部代码或医疗文本无需发送给第三方 API，版本也可固定在一次验收过的提交上。Hugging Face Hub 的下载文档允许通过 branch、tag 或完整 commit hash 指定 revision，部署记录因而能写清“运行的是哪一版权重”。[8] 对需要审计的组织而言，可追溯的版本比随时间变化的别名更容易纳入变更管理。
但“只有自托管才有隐私”仍是过度简化。OpenAI 当前数据文档写明，自 2023 年 3 月 1 日起，API 数据默认不用于训练或改进模型，除非客户主动选择共享；滥用监控日志通常最多保留 30 天，但法律要求或保护服务和第三方所必需时可能延长。符合条件并经批准的客户可申请 Modified Abuse Monitoring 或 Zero Data Retention。[9] 资格、端点、区域和应用状态仍有例外，公共文档也不能替代客户实际适用的合同和设置。
数据控制不能只看推理请求。输入进入模型前，可能经过文档解析、向量检索、缓存和内容过滤；输出离开模型后，又可能写入日志、反馈系统和评测平台。即使权重完全在本地，只要某个组件把文本发送到外部，“数据不出域”就不成立。反过来，托管 API 若能通过合同、网络隔离、访问控制和保留策略约束整条链路，也可能满足业务要求。OpenAI 文档还说明，保留控制须经批准，可按组织或项目配置，不同端点对应用状态和 ZDR 的支持并不相同。[9] 所以最终证据应来自实际数据流图、产品设置和合同，而不是“云端”或“本地”标签。
控制权还可以拆成数据、版本、行为、审计、连续性和责任六个维度。组织可能掌握模型版本，却无法审查训练数据；可能允许微调，却没有权利再分发；可能保留请求日志，却没有记录 tokenizer、量化参数、系统提示和检索语料的版本。每个维度都需要单独验收。
行为控制尤其依赖评测。开放权重允许团队微调模型、改变提示或增加安全层，每次修改也可能影响拒答、事实准确性、工具调用和特定语言表现。NIST 的生成式 AI Profile 在第一页明确说 AI RMF 供自愿使用，不是法律命令；其建议行动 GV-1.2-002 把上线前及持续进行内部、外部评估列为一种治理实践。[10] 把这项建议转成工程做法，可以是修改前保存基线，修改后用固定业务样本回归，无法解释的退化不直接上线。这是本文的实施建议，不是 NIST 对所有部署者设定的强制程序。
审计同样不止于保存输入和输出。若要解释一次行为变化，还需记录权重 revision、tokenizer、推理引擎、量化参数、系统提示和检索语料。Hugging Face 的完整 commit hash 解决的是文件版本标识，不能自动保存其余运行条件。[8] 真正可复查的发布，需要把这些信息放进同一份变更记录，并说明谁批准、何时回滚。
开放权重也不会自动解决安全责任。PyTorch 的安全指南提醒，模型本质上是程序，运行不可信模型等同于运行不可信代码；指南建议把不可信模型放进隔离环境，并仅运行受信任来源的软件和模型。[11] 下载包、序列化格式、转换脚本、第三方算子和暴露在网络上的服务端口，都应进入威胁模型。
版本固定还有另一面。锁定旧提交可以避免未经评估的变化，却也可能错过漏洞修复、依赖更新或新的业务要求。NIST 的自愿 Profile 建议为定期审查和事故监测指定组织责任，并把常规监测纳入持续改进。[10] 对使用者而言，固定版本应配套补丁政策、重新评测触发条件、回滚方案和最长停留期限。
托管模型的连续性风险更容易观察。OpenAI 当前弃用政策通常会提前通知活跃用户并设定关闭日；到关闭日，模型或端点不再可访问。但 preview 模型可能只有更短通知期，安全或合规问题也可能要求加快退出，政策只承诺在这种情况下尽可能通知。[12] 自持权重可以避开某个 API 端点的关闭，前提是配置、依赖、工具和兼容硬件仍可维护。它提供的是另一条连续性路径，不是永久运行保证。
3. 成本取决于部署责任，而不是开放标签
一种容易误导的比较，是把 API 的每百万 token 价格和一台服务器的租用价格并排，然后把差额归因于模型是否开放。开放程度回答组织能否取得和修改资产；成本结构则主要跟随部署模式、负载和责任分配。同一开放权重可以按调用量使用托管服务，也可以占用专用实例；专有服务同样可能采用预留容量。只有当组织选择自行部署或接手更多平台工作时，GPU、闲置容量、人员和值班才会从供应商侧移到自己的总拥有成本里。
三种模式可以先按责任划分。托管 API 由供应商负责 GPU 调度、扩缩容和大部分模型升级，使用者仍管理请求权限、数据政策、应用评测和输出风险。托管开放模型让使用者选择权重和部分运行参数，把基础设施交给云端端点。自行部署则由组织决定硬件、推理引擎和升级节奏，也接手容量、补丁、隔离和事故响应。这是两条轴：开放或专有描述资产与许可，托管或自建描述运行责任。
三种模式的计费单位不相同。按量 API 的费用通常随调用变化，空闲时无需为整台加速器持续付费；专用端点和自有资源则要计算运行时间、峰值余量和闲置。Hugging Face Inference Endpoints 的价格文档按实例规格展示小时价格，实际费用按分钟计算，并只在端点处于初始化或运行状态时计费。[13] 这证明托管开放模型会产生容量型账单，却不证明它在市场上普遍，也不证明它一定比按 token 计费便宜。
请求形态会进一步改变结果。长上下文占用更多 KV cache，突发并发要求更大的瞬时容量，严格的首 token 延迟又限制批处理空间。vLLM 论文把既有系统的内存浪费和 KV cache 管理列为吞吐瓶颈，并说明其缓存管理如何为批处理释放空间。[14] 因而，财务模型不能只有“每小时 GPU 价格”，还要填入上下文长度、并发、延迟、批处理和利用率。
托管开放模型是一种可选的中间方案。Hugging Face 的 Inference Endpoints 文档列出专用和自动扩缩基础设施、安全功能、监控日志以及多种推理引擎。[15] 团队可以更换开放权重，而不必从零搭建发布、扩容和日志系统；同时仍依赖该平台的网络、镜像、权限和计费规则。其价格页说明费用跟随实例规格和运行状态。[13] 这些产品事实只建立了方案存在和如何计费，不能推出其采用率或成本优势。
自行部署的第一步，是确认模型在目标硬件和业务负载下能稳定工作。gpt-oss README 所述单张 80GB GPU 和 16GB 内存，是 MXFP4 量化版本的运行说明，不是对峰值并发、上下文长度、质量或响应时间的保证。[4] NVIDIA 的产品规格显示，H100 SXM 配有 80GB 显存，最大可配置 TDP 为 700W。[16] 这些数字可帮助估算设备数量、供电和散热约束，却不能直接换算电费、碳排放或单位请求成本；实际账单还受利用率、机房价格、量化方式和冗余要求影响。
推理软件也会显著影响账单。vLLM 论文在指定模型、硬件和负载下报告了吞吐改进，摘要给出的范围是相对受测系统提高 2 到 4 倍。[14] 该结果证明 serving 设计可能改变固定硬件的产出，不说明软件比模型规模、质量目标或负载更能决定成本，也不能外推到所有业务。采购者仍要用自己的请求分布压测。
人员成本则跟随组织接手的责任上升，而不是随开放程度单调上升。自行部署或深度管理平台时，需要有人做容量规划、镜像和权重校验、滚动升级、指标告警、备份恢复与事故响应；使用托管开放端点时，其中一部分工作仍由服务商承担。NIST 的自愿 Profile 把上线前与持续评估、上线后监测列为建议行动，说明这些治理活动具有持续性，但它没有为这些工作定价，也没有证明任何部署模式更便宜。[10] 对没有平台团队的组织，只有在选择接手这些责任时，外包、低利用率和故障处置才可能抵消节省的 API 费用。
质量成本也容易漏算。为了让模型适配较小显存，团队可能采用更激进的量化；为了提高吞吐，可能缩短上下文或限制输出。gpt-oss 的内存说明明确对应 MXFP4 量化。[4] “可以装入”不等于“在目标质量和延迟下足够好”。每项成本优化都应回到业务评测：错误率是否上升，工具调用是否稳定，长文本是否被截断，是否增加人工复核。
可执行的比较至少需要三张表。请求表记录平均和峰值请求量、输入输出 token、并发、延迟和失败率；资源表记录 GPU 或 CPU、内存、存储、网络、冗余、闲置和能耗；责任表记录值班、升级、合规审查、漏洞处理、迁移和停机。分别为托管 API、托管开放模型和自行部署填表，再用真实流量压测。只有本地 TCO 试算和负载测试显示某一模式成本较低，组织才能把“更经济”当作自己的结论。
4. 选择增加了，迁移自由仍需工程化
开放权重带来一个明确变化：候选不再完全受某家供应商的产品目录约束。组织可以固定模型版本、选择推理引擎、在内部数据上微调，或把同一权重交给不同运行方。NTIA 报告把竞争、创新和研究、更多参与者列为广泛可用权重的潜在收益。[1] 这里的关键词是“潜在”。候选增加不等于候选可互换，也不保证用户已经拥有退出能力。
应用层依赖模型之外的一整套约定：tokenizer 如何切分文本，chat template 如何排列角色，系统提示放在哪里，工具调用的 JSON schema 如何生成，上下文窗口多大，停止词和采样参数如何解释。vLLM 的在线服务文档提供 OpenAI-compatible HTTP server，可以减少客户端接口改造。[17] 兼容的是接口形状，不是模型能力、参数含义、工具行为或安全边界。
判断接口层的锁定时，还要看模板条件。vLLM 文档单独设置 Chat Template 小节，说明聊天协议需要从 tokenizer 配置取得或由部署者指定模板。[17] 如果模型没有正确模板，兼容端点也不能自动生成正确的消息格式。迁移测试因此要覆盖响应结构、工具调用、停止条件和错误处理，不能只验证端口能够返回 200。
锁定也会出现在基础设施层。模型部署到某家云的专用端点后，应用往往依赖该云的镜像、私网、身份权限、日志指标和扩缩策略。转到另一家服务商时，要迁移的不只是 .safetensors 文件，还包括部署脚本、密钥、告警和性能基线。自建减少了一层托管依赖，却可能形成对量化格式、GPU 驱动或内部平台的依赖。锁定程度取决于替换时必须改动的层数，开放或专有并不能单独决定锁定程度。
评测集是选择权的另一块基础设施。没有稳定的业务样本，团队只能依赖排行榜或主观试用，很难知道替换后哪些客户流程受损。当团队主动纳入更多候选时，筛选成本可能增加；这不是开放模型发布更频繁的事实判断。组织可以把准确性、拒答、延迟、成本和安全测试固定成同一套门槛，只有第二个候选通过，选择才具有操作意义。
许可证决定修改能否被带走。Llama 3.1 的分发标识和特定超大规模使用者条款，意味着新产品或新主体要重新核对适用条件。[6] DeepSeek-R1 的蒸馏模型则要沿着基础模型核对 Qwen 或 Llama 许可证。[7] 如果微调适配器只存在于某个平台、训练数据和评测集没有归组织保存，即使基础权重可下载，实际资产仍难迁移。
开放权重、版本固定和兼容接口可以降低部分迁移门槛，但不会自然变成采购谈判筹码。只有备选模型通过业务评测，权重、配置、tokenizer、提示模板、适配器和部署脚本可以导出，并且第二个引擎或服务商完成过迁移演练，组织才可能用这条备选路径改善谈判位置。没有验证的候选清单，只是更多名字。
5. 按约束条件决定部署方式
三种模式没有一个在所有场景中占优。托管 API 适合需要快速上线、流量波动大或不愿维护 GPU 平台的团队；前提是数据政策、区域、合同和审计能力满足要求。托管开放模型适合希望选择权重，同时保留专用实例或自动扩缩的团队；它减少平台建设工作，但保留云端依赖。自行部署适合数据必须留在特定网络、负载经过验证且组织具备平台和安全能力的场景；它增加版本和数据位置控制，也让组织接手更多容量、补丁和事故责任。这些是待验证的适用条件，不是通用优先级。
决策前可以逐项回答八个问题：
• 哪些数据绝对不能离开组织网络或司法辖区，日志、缓存和备份是否也在范围内？
• 业务是否必须固定某个模型版本，能容忍多长的升级窗口？
• 权重、配置、代码、tokenizer、数据说明和微调结果能否以组织可读的格式带走？
• 许可证是否允许当前产品的商用、标识、修改和再分发？
• 平均流量、峰值并发和延迟目标，能否让专用容量达到经测算可接受的利用率？
• 谁负责 GPU 驱动、推理框架、漏洞补丁、监控、回滚和夜间事故？
• 应用是否有独立评测集和回滚开关，而不是把某一供应商的输出当作唯一基线？
• 供应商或模型维护者停止服务或更新时，组织能否在约定时间内切换到第二条已验证路径？
答案不必导向全自建或全托管。一个组织可以让低敏感、突发流量的功能继续使用托管 API，把需要版本固定的批处理放在托管开放模型端点，再把少数高敏感任务放进隔离环境。也可以先用 API 验证需求，再用同一评测集测试开放权重，只有性能、许可证和 TCO 达到门槛才迁移。分层部署的作用，是把数据、负载和责任逐项验证，而不是一次押注某个标签。
治理上还需要一张责任表。模型维护者发布哪些资产和修复，托管服务商承诺哪一层可用性，企业平台团队负责哪些补丁，业务负责人又对哪些输出和人工决策负责，都应在上线前写清。当模型维护、推理托管和应用运营由不同主体承担，而且合同、升级流程或内部责任人没有覆盖交接点时，责任更容易出现空档；这不是开放模型的必然后果，专有服务的多主体供应链也有同样问题。NIST 的自愿 Profile 建议明确周期审查和监测责任，并指出组织可对开放或专有的第三方模型、数据和服务商采用采购尽调、SLA 等控制。[10] 这项建议可用于检查责任表，但不能替代合同解释、法律意见或行业合规义务。
退出路径还要通过演练。团队可以在试点阶段关闭主端点，让备选模型处理一小批经过授权的真实负载，记录恢复时间、质量变化和人工介入；也可以从托管端点导出配置，在第二个环境重新部署。演练会暴露模型文件、许可证、依赖、密钥、网络和评测数据是否真的可带走。权重可得为退出提供条件，能否按时退出仍取决于整条路径是否被保存和测试。
开放模型改变的是用户可以安排的资产、控制和退出路径，重点不在一张“免费模型”清单。它不直接决定谁承担部署责任，也不保证更便宜、更安全或更私密。较稳妥的做法，是把开放程度写成可核对的组件和条款，把部署责任写到具体主体，把成本结论交给本地 TCO 与负载测试，再把迁移变成定期演练。在配置、依赖、工具和兼容硬件仍可重建的前提下，这些准备能提高继续运行或切换的可行性；它们不能承诺一个模型永久可用。
