七个档位：1.5b 只要 0.9 GB，7b 是 4.6 GB，70b 是 42.4 GB，
671b 是 402.6 GB——10 MB/s 下要下 11.2 小时。
下载前先算两个数：体积乘 2 要小于剩余空间，显存要装得下体积。
上一节把 Ollama 服务装起来了，但它里面是空的。 这一节下模型，并且说清楚标签里那些数字到底是什么。
一、标签里的数字是参数量，不是字节
deepseek-r1:7b 这个写法分两段：冒号前面是模型名，后面是标签。
标签里的 b 是 billion（十亿），指的是参数量，不是 byte。
所以 7b 是 76 亿参数，不是 7 字节，也不是 7 GB。
这个误会每年都有人犯——看到「7b」以为是个小文件，下下来发现好几个 G。
同一个模型名下面挂多个尺寸，是蒸馏出来的小版本：用大模型的输出当老师，教一个小模型。
不是把大模型「剪小」，所以小版本的表现通常比同参数量的原生小模型好。
参数量同时决定两件事：下载体积和运行时占用。
这两件事都跟它成正比，所以「下哪个档」这一个决定，同时确定了你要等多久和要多少内存。
二、体积怎么算出来
公式很短：参数量 × 每参数占几位 ÷ 8。76 亿参数、每参数 4.8 位，就是 4.6 GB。 为什么不是整 4 位（那算出来是 3.8 GB）？ 因为量化不是把所有参数都压到 4 位：一部分关键层保留更高精度，另外还有缩放因子之类的元数据。 统称 q4_K_M，实测下来约 4.8 位每参数。 档位差在哪：fp16 是原样，q8 几乎无损，q4_K_M 是「体积和效果都过得去」的常用档， q2 只在极端受限时才考虑。体积翻倍，效果不一定翻倍，但速度一定减半。 一个规律值得记住：体积和参数量严格成正比。1.5B 到 7B 差 5 倍，7B 到 70B 差 9 倍。 所以看一个模型要下多久，拿参数量对比就够了，不用等它下完。
三、下载前要算的三个数
磁盘剩余：要大于体积乘 2。 理由是下载时先写临时文件、校验、再合并进模型库，峰值占用接近两倍。 这一条最容易被忽略，结果是下到 99% 报「磁盘空间不足」。 下载时间：体积 ÷ 网速。4.6 GB 在 10 MB/s 下是 8 分钟，在 100 MB/s 下不到 1 分钟。 这个数决定你什么时候回来。 显存／内存：见 2.1.1 那张表。权重加 KV 才是真实占用，而 KV 随上下文长度变。 三个数里只要有一个不满足，就不该开始下。先算再下，是这一节唯一要养成的习惯。
四、第一次装，选哪个档
第一次装：1.5B 或 7B。 目的不是效果，是把「下载—加载—对话」这条链路走通。 链路不通的时候，下一个 40 GB 的模型只会更痛苦。 有效果要求：14B 或 32B。 这两个档在消费级硬件上是性价比区间，再往上就开始考验钱包和耐心了。 70B：需要 48 GB 以上显存，或者在 CPU 上忍着 0.6 tok/s。 后者基本等于不能用——比人打字慢一个数量级。 671B：普通机器放弃。不是「慢」，是权重 402.6 GB 根本装不下。
五、动手 Demo：七个档位从 0.9 GB 到 402.6 GB，671B 下载要 11.2 小时
按 q4_K_M 的 4.8 位每参数，算七个档位的下载体积；再按 10 MB/s 和 100 MB/s 两档网速算下载时间； 最后读一次当前磁盘剩余，判断这台机器能塞下哪个档。
bits = 4.8 # q4_K_M 大约每参数 4.8 位
tiers = [(u'deepseek-r1:1.5b', 1.5e9), (u'deepseek-r1:7b', 7.6e9),
(u'deepseek-r1:8b', 8.0e9), (u'deepseek-r1:14b', 14.8e9),
(u'deepseek-r1:32b', 32.5e9), (u'deepseek-r1:70b', 70.6e9),
(u'deepseek-r1:671b', 671e9)]
for tag, npar in tiers:
gb = npar * bits / 8 / 1e9
t10 = gb * 1000 / 10 / 60.0 # 10 MB/s，分钟
print(tag, gb, t10)
du = shutil.disk_usage(os.path.abspath(os.sep))
print(du.free / 1e9) # 剩余空间
实跑输出：
--------------------------------------------------------------------
下载模型：先看体积，再看磁盘和网速够不够
--------------------------------------------------------------------
模型标签 下载体积 显存下限 10 MB/s 100 MB/s
------------------------------------------------------------
deepseek-r1:1.5b 0.9 GB 1 GB 2 分钟 <1 分钟
deepseek-r1:7b 4.6 GB 5 GB 8 分钟 <1 分钟
deepseek-r1:8b 4.8 GB 5 GB 8 分钟 <1 分钟
deepseek-r1:14b 8.9 GB 9 GB 15 分钟 1 分钟
deepseek-r1:32b 19.5 GB 20 GB 32 分钟 3 分钟
deepseek-r1:70b 42.4 GB 43 GB 71 分钟 7 分钟
deepseek-r1:671b 402.6 GB 403 GB 11.2 小时 67 分钟
两个规律：**体积随参数量线性涨，下载时间随体积线性涨。**
7B 的 q4 是 4.6 GB，1.5B 只有 0.9 GB——差 5 倍。
而 671B 要 403 GB，光是下载就要 11.2 小时（10 MB/s）。
系统盘剩余 285 GB
能塞下的最大档 deepseek-r1:70b
**下载之前先看这一行**：模型体积乘 2 要小于剩余空间——
因为下载时是「先写临时文件、再合并」，峰值占用接近两倍。
最后一个提醒：模型标签里那个 b 是十亿参数（billion），不是字节。
1.5b 指 15 亿参数，下载下来约 0.9 GB。
表里七个档，体积从 0.9 GB 一路涨到 402.6 GB。
注意 1.5b 和 7b 之间是 5 倍，7b 和 70b 之间是 9 倍——参数量翻几倍，体积就翻几倍，没有意外。
下载时间那一列更能说明问题：7B 在 10 MB/s 下 8 分钟，70B 要 71 分钟，671B 要 11.2 小时。
这还是理论值，实际会因为断流、重试更长。
磁盘那段读出来是 285 GB。
按「体积乘 2 小于剩余」的规则，能塞下的最大档是 70b（42.4 GB，峰值 84.8 GB）。
671B 那 402.6 GB 在这台机器上直接出局。
但「塞得下」不等于「该下」。按 2.1.1 那张表，70B 在这台机器上出字 0.6 tok/s，下了也白下。
两个判据都过，才算选对档。
最后那句提醒值得单独写一遍：标签里的 b 是十亿参数，不是字节。
1.5b 下下来是 0.9 GB——比很多人预期的大，也比很多人预期的小。
30 秒实验
- 把 bits 改成 2.6（q2_K），看 7B 的体积从 4.6 掉到 2.5 GB。 再想想：省下的 2 GB 换来多少精度损失？这个交换值不值？
- 把网速从 10 MB/s 改成 1 MB/s（很多公司内网的实际情况），看 70B 要下多久。 这一行是决定「在公司还是在家下」的依据。
- 把磁盘剩余手动改成 20 GB，看程序判断出「能塞下的最大档」变成哪个。 这就是那段判断逻辑在真实场景里的用法。
常见误区
- 「b 是字节」。b 是十亿参数。
7b是 76 亿参数，体积 4.6 GB。 把这两个搞混，会得出完全错误的容量判断。 - 「参数量越大效果越好」。同一家族里大致成立，但跨家族不一定。 而且参数量翻倍，速度减半、显存翻倍——收益是效果，代价是可用性。
- 「q4 一定比 q8 差很多」。 多数日常任务差别很小，但代码和数学这类要精确的任务上，q4 的错误率明显更高。档位要按任务选。
自测三问（点开对答案）
1. 为什么下载前要按「体积乘 2」判断磁盘空间？ —— 因为下载时先写临时文件、校验、再合并进模型库，峰值占用接近两倍。 按体积判断，会在 99% 的时候报磁盘空间不足。 2. `deepseek-r1:7b` 里的 7b 是什么意思？ —— 76 亿参数（billion）。它决定了下载体积（4.6 GB）和运行时占用，不是字节数，也不是文件大小。 3. 为什么第一次装建议只下 1.5B 或 7B？ —— 因为第一次的目标是走通「下载—加载—对话」这条链路，不是效果。 链路不通的时候，下 40 GB 的模型只会让等待和排查都变长。模型下完了，接下来跑起来看看。下一节先量一把本机算力，再反推它到底能跑多快。
- ☐ （本节完，下一节 2.1.5 试运行DeepSeek模型）