从一封公开信到 70 多家签署方：开放权重模型为何成为 AI 产业共识

7 月 24 日，黄仁勋发布了自己的第一条推文，内容不是产品宣传，而是 NVIDIA 参与签署的一封公开信：开放权重模型对 AI 生态至关重要，产业界应共同支持。公开信最初列出 25 家签署方，48 小时内扩展到 70 多家；微软 CEO 萨提亚·纳德拉公开表态支持，OpenAI 也出现在签署名单中。

这件事的价值不只在于名单有多长。它把一个长期存在的技术选择推到了产业治理层面：开发者是否能够下载模型权重，在自己的基础设施上运行、评测、微调和审计模型，将直接影响 AI 生态的竞争方式。

开放权重到底开放了什么

开放权重模型通常允许开发者获取训练完成后的参数文件，并在许可范围内自行部署。它给团队带来的核心能力，是把推理过程从单一供应商的远程 API 中移出来。

拿到权重后，开发团队通常可以完成几类工作：

• 在本地服务器、工作站或私有云中运行推理，减少敏感数据离开组织边界的机会。
• 使用内部数据进行微调、量化或蒸馏，使模型适应特定业务和硬件。
• 固定模型版本和推理环境，降低远程服务升级造成的行为漂移。
• 对延迟、吞吐量、显存占用和输出质量进行独立测试。
• 检查模型在安全性、偏见和特定领域任务上的表现，而不只依赖供应商报告。

但“开放权重”不能直接等同于“开源软件”。有些模型只发布参数，不公开训练数据、训练代码或完整的数据治理过程；许可证也可能限制商业用途、再分发方式或特定应用场景。因此，判断一个模型有多开放，不能只看权重能否下载，还要检查许可证、训练透明度、修改权和分发权。

为什么产业公司愿意共同签署

公开信在 48 小时内从 25 家签署方增长到 70 多家，说明开放权重已经不只是研究社区的话题。对云厂商、芯片厂商、模型公司和应用开发者而言，它分别对应着不同但可以兼容的利益。

硬件和云平台希望更多模型能够运行在不同算力环境中；企业用户希望保留部署位置、成本结构和数据边界的选择权；应用团队则需要可复现的模型版本，以便持续测试和控制上线风险。开放权重为这些参与者提供了一种共同的技术接口：模型文件可以被部署、测量和改造。

这并不意味着托管 API 会失去价值。API 仍然适合快速接入、弹性扩容和使用高能力闭源模型。更现实的架构往往是混合模式：低延迟、隐私敏感或调用量稳定的任务使用自托管模型，复杂推理和峰值流量交给托管服务。

可以这样实践：建立一个可替换的本地模型基线

公开信本身并未规定具体模型或工具。团队可以从一个小型、许可条款清晰的开放权重模型开始，建立本地评测基线。下面是一个可改造的 Python 示例，使用 Hugging Face Transformers 加载文本生成模型。

运行前安装依赖：

python -m venv .venv
source .venv/bin/activate
pip install --upgrade torch transformers accelerate

将 MODEL_ID 替换成已经完成许可证审查、且机器资源能够承载的模型标识。示例默认值仅用于演示代码结构，不代表公开信推荐了该模型。

import os
import time

import torch
from transformers import AutoModelForCausalLM, AutoTokenizer

MODEL_ID = os.getenv("MODEL_ID", "HuggingFaceTB/SmolLM2-360M-Instruct")


def main() -> None:
    tokenizer = AutoTokenizer.from_pretrained(MODEL_ID)
    model = AutoModelForCausalLM.from_pretrained(
        MODEL_ID,
        torch_dtype="auto",
        device_map="auto",
    )

    messages = [
        {
            "role": "user",
            "content": "用三点说明企业部署开放权重模型时应检查什么。",
        }
    ]
    prompt = tokenizer.apply_chat_template(
        messages,
        tokenize=False,
        add_generation_prompt=True,
    )
    inputs = tokenizer(prompt, return_tensors="pt").to(model.device)

    started = time.perf_counter()
    with torch.inference_mode():
        outputs = model.generate(
            **inputs,
            max_new_tokens=160,
            do_sample=False,
        )

    generated = outputs[0, inputs["input_ids"].shape[1] :]
    elapsed = time.perf_counter() - started
    print(tokenizer.decode(generated, skip_special_tokens=True))
    print(f"\nLatency: {elapsed:.2f}s")


if __name__ == "__main__":
    main()

执行方式如下：

MODEL_ID=HuggingFaceTB/SmolLM2-360M-Instruct python local_model.py

这个基线不要只测试“能不能回答”。至少应记录模型版本、依赖版本、硬件、首字延迟、总生成时间、峰值显存和一组固定问题的质量评分。涉及中文、代码生成或行业术语时，还应单独构造对应测试集。

从下载模型走向可治理部署

开放权重扩大了团队的控制权，也把更多责任交给了部署者。远程 API 通常由供应商承担一部分安全更新、滥用检测和基础设施运维；自托管后，这些工作需要企业自己补齐。

正式采用前，可以用以下清单做一次评审：

• 确认许可证允许目标商业场景、微调方式和输出用途。
• 记录权重来源、文件哈希、模型版本和依赖锁文件，避免构建结果不可复现。
• 使用业务数据评测准确性、幻觉、安全拒答和提示注入风险。
• 评估量化对质量的影响，不要只比较显存和吞吐量。
• 为模型输入、输出和访问权限建立审计机制，同时避免日志泄露敏感数据。
• 准备版本回滚、漏洞响应和模型替换方案。

这封公开信释放出的信号很明确：开放权重正在成为 AI 基础设施的重要组成部分。不过，签署倡议只是立场，许可证、评测体系、部署能力和治理流程才决定开放权重能否真正转化为工程价值。对开发团队而言，合适的起点不是追逐最大的模型，而是选择一个能被审查、能被复现、也能被替换的模型，先把完整链路跑通。