本地大模型常见问题

这里每一个答案都由驱动计算器和模型页的同一份索引实算得出 —— 81 个模型、61 张显卡 —— 并附上可以自己核对的链接。所有数字都标注了实测还是估算;索引回答不了的问题,本站会直说,而不是猜一个。

显存与体积

跑一个 7B 模型需要多少显存?

在 Q4_K_M、4K 上下文下约 5.1 GB —— 权重 4.2 GB、KV 缓存 0.5 GB、激活缓冲 0.5 GB,以 Mistral 7B Instruct v0.3(7B)实算。本索引中每一张 8 GB 显卡都能从容跑下,还有余量。这个数字随上下文增长,而不是随你用得多不多:同一个文件在 32K 下约需 9.0 GB,因为 KV 缓存涨到了 4.0 GB。

算你自己的组合

16G 显卡能跑 24B 的模型吗?

在 4-bit、短上下文下可以 —— Mistral Small 24B Instruct 在 AWQ INT4 下约需 16 GB 中的 13.2 GB,还剩 2.8 GB。档位比参数量更关键:同一个模型在 Q4_K_M 下是 15.9 GB,占这张卡的 99% —— 在显卡完全空闲时能加载,但没有余量留给更长的窗口。16 GB 显卡能从容运行本索引 81 个模型中的 52 个。

看 16G 显卡能跑的全部模型

系统和显示会占掉显存吗?

会。如果这张卡同时还在驱动桌面,请先减去约 0.5–1.5 GB 再和本站的数字比较 —— 开着浏览器还要更多。这也是计算器把「从容运行」的界线划在显存的 88% 而不是 100% 的原因:最后这八分之一,正是让模型在你同时还在用的机器上不至于分配失败的余量。更宽松的 105% 规则单独显示,而且每次都会写明。

判定是怎么算的

为什么同一个量化档位,不同模型的体积差很多?

因为 Q4_K_M 这类档位是一套「配方」,不是固定位宽 —— 它把不同的张量量化到不同精度,具体配比取决于模型结构。在本站提供 Q4_K_M 的 81 个模型中,实际每权重比特从 4.1 到 4.9 不等。本站记录的是每个模型自己的实测值,而不是查表的统一数字 —— 这就是两个同为 8B、同一档位的模型体积能差几百 MB 的原因。

本索引收录的 GGUF 档位

上下文拉长到底多吃多少显存?

取决于模型的注意力结构,而不是参数量。Mistral 7B Instruct v0.3 的 KV 缓存从 4K 时的 0.5 GB 涨到 32K 时的 4.0 GB —— 基本是线性的,因为每一层都维护一份随窗口增长的缓存。2026 年的混合注意力模型打破了这一点:只有一部分层跑完整注意力,其余层保持固定大小的循环状态,缓存几乎不涨。计算器对两种情况都做了处理。

试试更长的窗口

量化掉点

Q4 量化掉点严重吗?

在 Q4_K_M 下,本站有公开困惑度数据的 79 个模型,损失中位数为 2.9% —— 即保留 97.1% —— 区间从 1.4% 到 5.2%。有两点比中位数更重要:同一档位下,小模型掉得比大模型多;而且困惑度衡量的是语言建模能力,不等于「它还能不能做好你的任务」。没有公开数据的模型在本站显示为短横线,而不是当作零损失。

逐个模型的数据

Q4_K_M 这个名字是什么意思?

Q4 是名义位宽,K 指 llama.cpp 的 k-quant 家族,M 是其中的中档(还有 S 和 L 两个兄弟)。K 家族不会对所有张量一视同仁 —— 注意力和前馈张量处理方式不同,有些还保持更高精度 —— 这就是实际每权重比特会高于 4 的原因。在本索引中,81 个 GGUF 模型全部提供 Q4_K_M,所以本站的质量指标也统一以这个档位为准。

本站收录的全部 GGUF 档位

Q5 比 Q4 多吃的显存值得吗?

在本站同时公布两个档位数据的 16 个模型上,从 Q4_K_M 升到 Q5_K_M 可以挽回的困惑度损失中位数为 1.5 个百分点,代价是体积增加约 17%。这里刻意做了配对:公布 Q5 数据的模型和公布 Q4 的并不是同一批,分别取中位数比较的是两组模型而不是两个档位。实际上这个选择通常由「装不装得下」决定 —— 显存有余量就取更高档位,而在没有实际对比过之前,不要为了塞进更大的模型而降到 Q4 以下。

对比两个配置

量化对写代码的影响比聊天更大吗?

本索引回答不了这个问题。本站所有质量数字都是 WikiText-2 上的困惑度,衡量的是通用文本上的下一个 token 预测 —— 它不是代码基准,而一个跑不了任务评测的站点,不该把一种指标换算成另一种结论。业界普遍观察到「只有唯一正确答案的任务」比开放式任务退化得更明显,但那不是本站测出来的,所以本站不把它写成数字。

本站到底测了什么

官方 QAT 量化比社区量化更好吗?

在相同位宽下通常是的,原因是机制上的:量化感知训练(QAT)在微调时就把量化放进前向计算,权重会去适应它;而社区的训练后量化(PTQ)是把一个已经训练完的模型压下来,只能尽量减少损伤。本站目前还回答不了的是「你看到的是哪一种」—— 索引记录了每个量化的格式和档位,但没有记录发布者,所以本站任何一行都没有「官方」标记。这是一个已知的缺口,而不是认为它不重要。

本索引确实跟踪的内容

格式与运行时

GGUF 和 AWQ 有什么区别,该用哪个?

除非你是在跑服务端,否则选 GGUF。GGUF 什么硬件都能跑 —— CPU、NVIDIA、AMD、Apple —— 本站 81 个模型中有 81 个提供它,而 AWQ 是 53 个。AWQ 的价值在于 NVIDIA 显卡上用 vLLM 做批量请求时的吞吐;如果只是你一个人和一个模型对话,它给不了 GGUF 给不了的东西。本站有 53 个模型同时提供两种格式,那也是唯一能在同一份权重上比较它们的集合。

在同时提供两者的模型上对比

GGUF 能转成 AWQ 吗?

没有实际意义。两者都是对原始 FP16 权重的有损压缩,把一个转成另一个等于在第一次损失之上再叠一次 —— 你是在量化一个已经量化过的模型。正确的路径是回到原始权重再做量化,而这正是各个格式的发布者已经做过的事。如果某个模型没有你需要的格式,那是一个真实的缺口,不是转换能补上的。

看你的环境该用哪种格式

MXFP4 的模型为什么不要再量化一次?

因为它本来就是 4-bit —— 发布出来的检查点本身就是量化后的。本站提供 MXFP4 的 2 个模型是直接以 4-bit 发布的,不是从高精度转换下来的,背后没有一个 FP16 原版可以回溯。再量化成 Q4_K_M 会掉质量而省不下东西:两者体积接近,你只是白白多加了一道有损步骤。

本地跑 MXFP4 权重

Mac 上用哪种格式?

用 GGUF,通过 llama.cpp 或 Ollama 的 Metal 后端 —— 本站 81 个模型中有 81 个提供。AWQ、EXL2、GPTQ 都需要 CUDA,在 Apple 芯片上根本跑不起来 —— 本索引跟踪的四种格式里,有三种在你开始之前就已经不可用。Mac 上真正的限制不是格式,而是 GPU 能锁定多少统一内存 —— 那个数字低于机器标称的内存容量。

Mac 实际能跑什么

A 卡(AMD)能用哪种格式?

可靠的答案是 GGUF,走 llama.cpp 的 ROCm 或 Vulkan 后端。vLLM 也有官方 ROCm 构建,所以 AWQ 不像在 Mac 上那样完全无解 —— 但 EXL2 和 GPTQ 只支持 CUDA。真正决定一套 A 卡环境能不能用的不是格式,而是你的内核和显卡有没有可用的 ROCm 构建,这是配置问题,不是硬件天花板。

AMD + llama.cpp 实操

硬件

2026 年本地跑大模型该买什么显卡?

预算内显存最大的那张 —— 能不能跑得起来完全由容量决定,别的都不决定。本索引的 61 张卡里,消费级容量最大的是 RTX 5090,32 GB、1,792 GB/s,能从容运行本站 81 个模型中的 66 个,而 8 GB 的卡是 35 个。带宽是第二个问题而不是第一个:它决定已经装得下的模型生成有多快,同样显存的两张卡在这一项上可以差 2.5 倍以上。

对比全部 61 张卡

8G 显存够用吗?

对大多数人实际会跑的东西来说,够 —— 本索引 81 个模型中有 35 个能在 4K 上下文下从容装进 8 GB,包括 Q4_K_M 的 7B 级模型(5.1 GB)。8 GB 给不了的是余量:长上下文、第二个进程,或者 13B 以上的模型。升到 16 GB 能把可跑数量从 35 个提到 52 个。

8G 显卡入门指南

Mac 的统一内存算显存吗?

大部分算,但不是全部。GPU 和 CPU 共享同一块内存池,所以 64 GB 的 Mac 能装下 24 GB 独显装不下的模型 —— 这部分是真的。不真的是把标称数字当成可用量:macOS 会为系统保留一部分,并限制单个进程能锁定多少。请按明显低于标称的容量来规划,另外记住不同档位之间带宽的差距比容量看起来的差距大得多。

Mac 的内存实际是怎么用的

两张 16G 还是一张 32G?

跑单个模型的话,选一张 32 GB。把模型拆到两张卡上意味着每个 token 都要跨卡传输,第二张卡上的层要等第一张算完 —— 容量拿到了,吞吐没拿到,而且配置明显更麻烦。两张卡真正有价值的场景是你要同时跑两个东西,或者 32 GB 的卡超出预算。一张 32 GB 的卡能从容运行本站 81 个模型中的 66 个,单张 16 GB 是 52 个。

什么时候双卡才划算

消费级硬件到底能不能跑 70B?

用消费级显卡的话,不能。Llama 3.1 70B Instruct 在 Q4_K_M 下约需 46.1 GB,本索引中没有任何一张消费级显卡有这么大显存 —— 真正装得下的是 13 个数据中心卡、Mac 和纯 CPU 条目。它在本站最小的构建 EXL2 3.5bpw 也要 33.6 GB。现实的路径是大内存 Mac、用系统内存跑 CPU 推理(并接受相应的速度),或者双卡。

本站全部 70B 级模型

关于这些数据

这些数字是哪来的?

三个来源,彼此分开。模型架构(层数、KV 头数、head 维度)来自各模型自己公布的 config,是显存计算的输入。困惑度是量化发布者公布的数字;没有公布的模型显示短横线,而不是猜一个。速度数据是在指定软件栈上、以 Meta Llama 3.1 8B Instruct 跑 WikiText-2 的实测记录 —— 而且只记录那套软件栈真正跑过的硬件。站上其余内容,包括每一个显存数字,都是计算出来的而非实测,并且都有标注。

完整方法说明

本站的「实测」和「估算」差在哪?

「实测」是指有人在指定硬件、指定运行时版本上跑过并记录了数字。「估算」是指用计算器同一套公式、从模型架构和量化档位算出来的。本站在每一个展示数字的界面上都标注属于哪一种;没有实测记录的硬件页面会直接说明,而不是让估算值看起来像实测。宁可删掉一行也不修改数值 —— 曾有三条基准数据在算完后发现它们所标的显卡物理上达不到那个速度,于是被删除而非调整。

改了什么、什么时候改的

索引多久更新一次?

数据自带日期 —— 当前是 2026-09-11 —— 而每一次改变站点说法的改动,都会在同一天写进变更记录。节奏大致是每周做一次数据刷新,每两周补一批新模型,选择上偏向「受限配置真的跑得动」的模型,而不是发布声量最大的那些。

完整变更记录

这里的数字和我机器上的对不上怎么办?

先检查三件事:上下文长度(本站默认 4K,KV 缓存随它增长)、你的显卡是不是同时还在驱动显示器、以及你下载的构建是不是同一个量化档位(而不只是同一个名义位宽)。如果仍然对不上,那值得反馈 —— 一个经不起真实硬件检验的数字,本站宁愿改掉也不愿辩护,此前已经有三条基准数据正是因此被删除。

怎么反馈