本地大模型常见问题

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

在 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 显卡能从容运行本索引 112 个模型中的 64 个。

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

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

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

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

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

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

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

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

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

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

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

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

可靠的答案是 GGUF，走 llama.cpp 的 ROCm 或 Vulkan 后端，所有 Radeon 都适用。AWQ 和 GPTQ 可以通过 vLLM 的官方 ROCm 构建运行 —— 但仅限 vLLM 支持的显卡：RX 7700 XT 及以上、RX 9000 系列和 Instinct MI200 及更新型号。RX 6000 系列、RX 7600 XT 和 MI100 不在名单上，本站不会在这些卡上推荐这两种格式。EXL2 只支持 CUDA。格式之外，真正决定一套 A 卡环境能不能用的，是你的内核和显卡有没有可用的 ROCm 构建，这是配置问题，不是硬件天花板。

GGUF。llama.cpp 通过 SYCL 后端在 Arc 上运行它（文档把 A770、A750、B580 列为已验证），Ollama 则通过 Vulkan 运行，无需编译。本站在 Arc 上不推荐其他格式：EXL2 只支持 CUDA，而 vLLM 的英特尔后端在消费级 Arc 上支持哪些量化格式，本站尚未核实。本索引收录了 5 张 Arc 显卡，其中最大的消费级卡 Arc A770 16G 能在 4K 上下文下从容运行 112 个模型中的 60 个。

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

显存决定了大部分，但不是全部：各家软件能加载的格式也会让清单变短。同为 16 GB，Arc A770 16G 在 4K 下能从容运行 112 个模型中的 60 个，RTX 5080 是 64 个，因为有些模型只有用 Arc 加载不了的 4-bit AWQ 体积才装得下。本索引里各家最大的零售卡是 RTX 5090（32 GB，4K 下可从容运行 112 个模型中的 90 个）、Radeon RX 7900 XTX（24 GB，86 个）和 Arc A770 16G（16 GB，60 个）。NVIDIA 能跑本站跟踪的所有格式（AWQ、EXL2、GGUF、GPTQ）；Radeon 能跑 AWQ、GGUF、GPTQ —— 其中 AWQ 和 GPTQ 只能通过 vLLM，且限 vLLM 支持的显卡；Intel Arc 只能跑 GGUF。如果你只用 llama.cpp 或 Ollama 跑 GGUF，那就在预算内买显存最大的，哪家都行。

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

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

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

论容量可以 —— 本站 112 个模型里有 88 个能从容装进 32 GB，跟装进一张 32 GB 显卡的算法完全一样，毕竟显存计算只看字节数。给不了的是速度数字：CPU 推理的快慢取决于你自己的内存条数量和通道配置，而不是「32 GB」这个数字本身，所以本站不像给显卡那样给系统内存标一个带宽。预期生成速度会明显慢于同一个模型跑在独显上，决定纯 CPU 方案之前先算清楚这个落差。

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

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

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

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

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