Hugging Face 上每隔几天就有一个“开源最强”的模型挂出来，下载按钮很显眼，硬件要求写在页面角落里的小字里。等真把权重拖下来，才发现机器装不下——这种经历，今年在站长圈里不算少见。
开源权重解决的是“能不能拿到”，不解决“能不能跑”。中间隔着三笔账，算完再决定要不要动手。
图片由 AI 生成
第一笔账：权重文件有多大
粗算公式很简单：参数量 × 每个参数占的字节数。FP16 是 2 字节，FP8 是 1 字节，4bit 量化大约 0.5 字节。
拿最近引发讨论的 Reflection Beam 举例。它是混合专家结构，总参数 5010 亿，每个 token 激活约 230 亿，Apache 2.0 协议，支持 100 万 token 上下文，主打代码和 Agent 任务。BF16 的权重文件接近 1TB，官方给出的 NVFP4 版本压到约 280GB，但依然建议四张 B200 起步。
这里有个特别容易误解的点：激活参数少，不等于显存占用小。MoE 每次只算一部分专家，省的是计算量，不是存储量——所有专家的权重还是得全部装进显存或者内存里。看到“501B 只激活 23B”就以为能塞进单卡，是最常见的误判。
第二笔账：显存不只装权重
权重只是地板。真正吃显存的是这几项加起来：
- KV Cache：上下文越长、并发越多，这块越大。100 万 token 的上下文能力，意味着满载时这部分可以轻松超过权重本身。
- 激活值与临时缓冲：推理过程中产生的中间结果，batch 越大越明显。
- 框架开销：vLLM 这类框架会预分配显存做管理，看起来“没跑东西就占了一半”，其实是正常现象。
实际规划时，在权重之外至少留出 20% 到 30% 的余量。要跑长上下文或者多并发，余量还得往上加。显存不够的后果不是变慢，是直接 OOM 起不来。
第三笔账：量化省下的和失去的
4bit 量化能把权重压到原来的四分之一，这也是为什么一张 24GB 的消费级显卡能跑起 300 亿参数的模型。代价有两块：
一是质量。常规对话和摘要任务，4bit 和 FP16 的差距肉眼难辨；但长上下文检索、严格的格式输出、多步工具调用这些任务，量化带来的偏差会被放大，表现为“偶尔漏掉一句话”“JSON 少一个括号”。
二是速度。反量化本身要花时间，低比特在某些框架上的实际吞吐不一定比 FP8 高。想省显存就用，但别指望同时省时间。
图片由 AI 生成
框架怎么选，看你要的是什么
本地试玩、单人使用，Ollama 或者 LM Studio 最省事，装完拉模型就能对话，缺点是并发能力弱，不适合对外提供服务。
要对外提供接口，vLLM 和 SGLang 是主流。连续批处理、PagedAttention 这些机制能把吞吐拉起来，代价是配置复杂、对显卡型号和驱动版本挑剔。Beam 这类新模型发布时通常会同步给出 Transformers、vLLM、SGLang 的部署配方，照着跑能少走弯路。
还有一点得记住：厂商公布的跑分是在他们自己的环境下测的。SWE-bench 之类的分数再高，也要拿你真实的业务任务复测一遍，尤其是中文场景和你们的特殊格式要求。
站长该不该自建
| 场景 | 建议 |
|---|---|
| 每天几百次调用、任务简单 | 直接用 API，比自己搭便宜得多 |
| 数据不能出内网 | 自建小模型，70 亿到 300 亿级别够用 |
| 需要微调成自己的风格 | 自建或租用 GPU，先小规模验证 |
| 只是偶尔试用 | 用托管服务，别买卡 |
算成本的时候别只算卡钱。一台能跑大模型的机器，还要算电费、机房散热、运维时间，以及最容易被忽略的一项——你花在这上面的时间，本来可以用来写内容。
“开源”和“易用”是两件不同的事。权重放出来，代表你可以审计、可以微调、可以自己部署；不代表它能跑在你的服务器上。
对绝大多数资源站来说，现阶段更划算的做法是：内容侧用 API，把省下来的精力放在选题和结构上；真要做与 AI 相关的功能，先用小模型加量化验证需求，跑通了再考虑升级硬件。别为了“技术先进”先买卡，最后卡在机房里吃灰。
