量化模型库

Meta Llama 3.1

Meta 旗舰 8B 模型，128K 上下文，端侧部署最优选择之一。

可用格式

Meta Llama 3.1

Meta 前沿 70B 模型，需要 40GB+ 显存，适合双 3090 或 M2 Ultra。

可用格式

Meta Llama 3.2

小巧而实用，4GB 显存或 8GB 内存即可运行，甚至可在手机端通过 llama.cpp 运行。

可用格式

Alibaba Qwen2.5

阿里 Qwen 系列 7B，性能远超同级，代码能力尤其突出。

可用格式

Alibaba Qwen2.5

性能与资源消耗的最佳平衡点，Q4 量化仅需 16GB 显存。

可用格式

Alibaba Qwen2.5

24GB 显存单卡可运行 Q4_K_S，推理能力接近 GPT-4，性价比极高。

可用格式

DeepSeek

MoE 架构代码模型，激活参数约 2.4B，代码能力卓越。注意力采用 MLA：用当前 llama.cpp 转换的 GGUF（含 attn_k_b / attn_v_b 张量）在 32K 下约缓存 1 GB，本站估算即按此计算；只有单个 attn_kv_b 张量的旧版转换会缓存完整的 K 和 V，32K 下约 8.4 GB。

可用格式

Microsoft Phi

Microsoft 的小巧精悍之作，端侧部署最佳 4B 模型之一。

可用格式

Mistral AI

Mistral 与 NVIDIA 合作推出，128K 上下文，多语言能力出色。

可用格式

Alibaba Qwen2.5

Qwen2.5 旗舰模型，需双 4090 或 A100 80G，大规模推理能力卓越。

可用格式

DeepSeek

R1 推理能力蒸馏至 14B，社区热度极高，思维链能力出色。

可用格式

Meta Llama 3.3

Meta 最新 70B，多语言能力提升，可无缝替换 Llama 3.1 70B。

可用格式

Mistral AI

Mistral 高效 24B 模型，多语言能力强，Q4 量化可装入 24GB 显存。

可用格式

Alibaba Qwen2.5

顶级开源代码模型，HumanEval 在 32B 规模可与 GPT-4o 竞争。

可用格式

Alibaba Qwen2.5

最佳 7B 代码模型，适合 8–16GB 显存的本地开发助手。

可用格式

Alibaba Qwen2.5

Qwen2.5 迷你版，适合边缘设备，4GB 显存或树莓派级别硬件即可运行。

可用格式

Meta Llama 3.2

超轻量 Llama，适合移动端和嵌入式，Q4 量化仅需不到 2GB 显存。

可用格式

DeepSeek

R1 推理能力注入 Llama 70B 架构，双卡部署的顶级开源推理模型。

可用格式

Mistral AI

Mistral 专用代码模型，支持 80+ 编程语言，支持 Fill-in-the-Middle。

可用格式

Meta Llama 3.2

多模态 Llama，支持图像理解。视觉编码器额外增加约 2GB 显存开销。

可用格式

NousResearch

基于 Llama 3.1 8B 微调，角色扮演和指令遵循能力增强。

可用格式

IBM Granite

IBM 企业级 8B 模型，RAG 和工具调用能力强，Apache 2.0 许可。

可用格式

Alibaba Qwen2.5

最小 Qwen2.5，适合树莓派、手机端和超低延迟演示。

可用格式

Alibaba Qwen2.5

支持 128K 上下文的微型 Qwen，摘要和对话能力出人意料。

可用格式

Microsoft Phi

Microsoft 中型 Phi-3，16GB 显卡上质量/显存比极佳。

可用格式

Microsoft Phi

最新 Phi mini，数学和代码能力提升，4B 级性能强者。

可用格式

DeepSeek

MoE 通用模型（激活约 2.4B），长上下文，多语言对话能力强。注意力采用 MLA：用当前 llama.cpp 转换的 GGUF（含 attn_k_b / attn_v_b 张量）在 32K 下约缓存 1 GB，本站估算即按此计算；只有单个 attn_kv_b 张量的旧版转换会缓存完整的 K 和 V，32K 下约 8.4 GB。

可用格式

DeepSeek

7B 体量的 R1 推理能力，8–12GB 显存思维链实验性价比最高。

可用格式

DeepSeek

R1 蒸馏至 32B，单卡 24GB（Q3/Q4）即可接近前沿推理能力。

可用格式

Meta Llama 3.2

旗舰多模态 Llama，需双 4090 或 A100；视觉模块额外约 3GB 显存。

可用格式

TII UAE

TII 最新 Falcon，多语言与代码能力均衡。

可用格式

Alibaba Qwen3

最新 Qwen3 稠密 8B，支持思考模式，本地部署比 Qwen2.5 7B 全面升级。

可用格式

Alibaba Qwen3

Qwen3 14B — 2026 Qwen 系列中推理能力与显存占用的最佳平衡点。

可用格式

Google Gemma 3

Google Gemma 3 多模态 4B，128K 上下文，8GB 显卡可跑图文理解。

可用格式

Google Gemma 3

中型 Gemma 3 视觉模型，Q4 可装入 16GB，多语言对话表现优秀。

可用格式

Meta Llama 4

Meta Llama 4 Scout MoE（激活 17B / 总 109B），多模态，Q4_K_M 约需 68GB 显存。

可用格式

Meta Llama 4

Llama 4 Maverick 旗舰 MoE（激活 17B / 总 400B），需多卡或 H100 集群。

可用格式

Meta Llama 3.1

Meta 前沿稠密 405B，Q4 约需 230GB+ 显存；双 H100 80G 或 8 卡消费级方案。

可用格式

Alibaba Qwen3

Qwen3 稠密 32B — Qwen2.5-32B 继任者，推理与思考模式全面升级。

可用格式

Alibaba Qwen3

Qwen3 MoE，仅 3B 激活参数。Q4 约 19GB，16GB 显卡上超越 QwQ-32B。

可用格式

Alibaba Qwen3

Qwen3 旗舰 MoE（激活 22B / 总 235B）。Q4_K_M 约 142GB，对标 DeepSeek-R1 级模型。

可用格式

DeepSeek

DeepSeek-V3 前沿 MoE（激活约 37B / 总 671B）。MLA + FP8；Q4 需多节点 GPU 集群。MLA 缓存：用当前 llama.cpp 转换的 GGUF（含 attn_k_b / attn_v_b）在 32K 下约 2 GB，本站估算即按此计算；只有单个 attn_kv_b 张量的旧版转换会缓存完整的 K 和 V，32K 下约 150 GB。

可用格式

DeepSeek

基于 V3 MoE 的 DeepSeek-R1 推理模型。前沿级思维链 — 本地 GPU 请用蒸馏版。MLA 缓存：用当前 llama.cpp 转换的 GGUF（含 attn_k_b / attn_v_b）在 32K 下约 2 GB，本站估算即按此计算；只有单个 attn_kv_b 张量的旧版转换会缓存完整的 K 和 V，32K 下约 150 GB。

可用格式

Alibaba Qwen3

最小 Qwen3 稠密模型，支持思考模式。Q4 约 3.2GB，适合 8GB 显卡与边缘设备。

可用格式

Alibaba Qwen3

Agentic 代码 MoE，3.3B 激活参数，原生 256K 上下文。16–24GB 显卡上最强开源代码模型之一。

可用格式

Mistral AI

Mistral 3 旗舰 MoE（激活 41B / 总 675B），含视觉编码器。FP8 需 8×H200；GGUF 量化仅供研究集群。注意力为 DeepSeek 式 MLA，实际 KV 缓存比下方按常规结构（未核实）估算的数字小。32K 下相对约 390 GB 权重可忽略；用满 256K 时，请把缓存数字当作上限。

可用格式

Zhipu GLM-4

智谱 GLM-4 开源 9B，128K 上下文，支持工具调用，中英双语表现突出。

可用格式

Google Gemma 3

Gemma 3 大杯指令版，长上下文 + 多模态。Q4 约 16GB，适合 24GB 卡或双卡短上下文。

可用格式

DeepSeek

R1 推理蒸馏到 Llama 3.1 8B。8–12GB 显卡上最佳思维链之一，社区 GGUF 极丰富。

可用格式

Microsoft Phi

微软 Phi-4 稠密 14B，同尺寸推理能力突出。Q4 约 9GB，12GB 卡中等上下文可跑。

可用格式

Alibaba Qwen3

迷你 Qwen3，支持思考模式。Q4 约 1.4GB，适合手机旁路、NUC 与常驻本地 Agent。

可用格式

OpenAI GPT-OSS

OpenAI 开放权重 MoE（总 21B / 激活 3.6B），原生以 MXFP4 发布 —— 约 12.8GB，16GB 显卡即可跑且无额外精度损失。激活仅 3.6B，CPU 卸载也还能用。

可用格式

OpenAI GPT-OSS

GPT-OSS 大杯（总 117B / 激活 5.1B）。原生 MXFP4 权重约 61GB —— 单张 80GB 卡或 128GB 统一内存 Mac 可跑。24GB 消费卡部分卸载虽慢但可用。

可用格式

Zhipu GLM-4.5

智谱 Agent/推理向 MoE（总 106B / 激活 12B）。Q4 约 64GB —— 96GB+ 统一内存 Mac 或双 48GB 卡最合适。同级别中工具调用能力突出。

可用格式

Mistral Devstral

Mistral 与 All Hands 合作的 Agent 编码模型，基于 Mistral Small 3.1。面向仓库级工具调用而非单文件补全。Q4 约 14GB，16GB 显卡可跑。

可用格式

Alibaba Qwen3-VL

当代视觉语言模型,Q4 约 5.9GB,单张 8–12GB 卡仍可跑。没有 24GB 显卡的人做多模态的现实选择 —— 注意视觉编码器会额外占用显存,下方 KV cache 计算并未包含这部分。

可用格式

Alibaba Qwen3-VL

多模态 MoE,激活参数仅约 3B,因此在苹果统一内存上依然跟手,CPU 卸载的表现也远好于稠密 30B。Q4 约 19GB,24GB 显卡可完整放下。

可用格式

Mistral Magistral

Mistral 基于 Mistral Small 3.2 的推理模型,思维链包在 [THINK] 标签内。Q4 约 14GB,让显式思维链落到 16GB 显卡上 —— 比多数教程默认的 70B 级推理模型低一档。

可用格式

ByteDance Seed

稠密 36B,原生 512K 上下文。Q4 权重约 22GB,单张 24GB 卡或 2×16GB 拆分即可 —— 但真正的开销是上下文:512K 的 KV cache 单独就约 128GB,所以要先规划上下文再考虑权重。

可用格式

Mistral Ministral 3

Mistral 官方直接发布 GGUF，分 3B / 8B / 14B 与 Instruct、Reasoning 两种变体；其中 8B 在 Q4 下能装进 8GB 显卡并留出可用的上下文余量。34 层全部是标准全注意力，因此下方的显存估算与计算器的假设完全一致。各档位的质量损失官方未公布。

可用格式

Alibaba Qwen3.8

混合注意力：64 层中只有 16 层保留 KV 缓存，所以这个 27B 模型在 262K 上下文下的缓存约 16GB，而不是 64GB。按常规架构计算会把缓存高估四倍 —— 这里的估算只计入那 16 层，并与 8K、32K、262K 三个已公开实测值吻合。各档位的质量损失官方未公布。

可用格式

Zhipu GLM-4.7

智谱 GLM-4.7 系列的轻量款：总参数 30B，每 token 激活约 3B，MIT 许可。注意力采用 MLA，每层每个 token 只缓存一个 576 维的压缩向量，而不是完整的 K 和 V——所以 32K 上下文下缓存不到 2 GB，常规 47 层模型需要的是它的好几倍。llama.cpp 按 DeepSeek-2 类模型运行它。下方体积使用计算器通用的 Q4_K_M / Q8_0 比特率：未能核对到 GGUF 文件大小，各档位的质量损失也未公布。

可用格式

Moonshot Kimi Linear

月之暗面的混合线性注意力模型：总参数 48B，激活 3B，上下文窗口 100 万 token。27 层中只有 7 层保留会增长的缓存，而且存的是 MLA 压缩向量，所以即使用满 100 万 token，缓存也只要约 8 GB——决定它能在什么硬件上跑的是权重，不是上下文。Q4 下，48 GB 及以上的 Mac 可以从容运行；32 GB 显卡只能勉强装下、几乎不剩余量。下方体积使用计算器通用的比特率：未能核对到 GGUF 文件大小，各档位的质量损失也未公布。

可用格式

Google Gemma 4

Google Gemma 4 的混合专家模型：文本部分约 25B 参数，每 token 激活约 4B，256K 上下文，支持图像输入。30 层中只有 5 层的缓存随上下文增长，而且这些层用的是更少、更宽的注意力头，所以缓存很小——32K 下约 0.9 GB，用满 256K 也只要约 5.3 GB。Q4 下 32K 上下文约 17 GB：24 GB 显卡可以从容运行，甚至能加载完整窗口（偏紧）。16 GB 显卡差一点装不下。下方体积使用计算器通用比特率——未能核对到 GGUF 文件大小，各档位的质量损失也未公布。

可用格式

Google Gemma 4

Google Gemma 4 的稠密旗舰：约 31B 参数，256K 上下文，支持图像输入。60 层中只有 10 层缓存完整上下文，而且这些层只用 4 个宽 KV 头，所以 128K 上下文只增加约 11 GB 缓存，常规的 60 层结构则要约 120 GB。Q4 下 4K 上下文约 21 GB——在 24 GB 显卡上刚好压在"从容"的边缘，32K 起就偏紧；32 GB 显卡跑 32K 很从容。下方体积使用计算器通用比特率——未能核对到 GGUF 文件大小，各档位的质量损失也未公布。

可用格式

Google Gemma 4

Google 面向端侧的 Gemma 4：实际参与计算的约 4.7B 参数，外加一张 2.8B 的逐层嵌入表，128K 上下文，支持图像和音频输入。42 层中只有 4 层的缓存随上下文增长，所以用满 128K 也只要约 2.0 GB 缓存。Q4 下 4K 上下文约 4.9 GB，用满窗口约 7.0 GB——日常上下文长度下 8 GB 显卡可以从容运行。这里的体积按整个模型都放进 GPU 内存计算，也就是 Mac 或整模型上 GPU 时的占用；llama.cpp 会把嵌入表留在系统内存，所以在独立显卡上，Q4 实际显存占用比这里少约 1.6 GB。体积使用计算器通用比特率——未能核对到 GGUF 文件大小。

可用格式

Google Gemma 4

最小的 Gemma 4：实际参与计算的约 2.3B 参数，外加一张 2.3B 的逐层嵌入表，128K 上下文，支持图像和音频输入。它的缓存几乎不增长——35 层中只有 3 层跟踪完整上下文，128K 下约 0.8 GB。Q4 下 4K 上下文约 3.0 GB，用满窗口约 3.8 GB——本索引中任何一张卡、以及 8 GB 的 Mac 都能从容运行。体积按整个模型都放进 GPU 内存计算；llama.cpp 会把嵌入表留在系统内存，所以在独立显卡上，Q4 实际显存占用比这里少约 1.3 GB。体积使用计算器通用比特率——未能核对到 GGUF 文件大小。

可用格式

Hugging Face SmolLM

Hugging Face 完全开源的 3B 模型，训练数据和训练方法随权重一起公开。它带一个可开关的推理模式，实际训练到的上下文窗口是 64K，128K 要靠 YaRN 外推。只有 4 个 KV 头，缓存很小，所以长窗口也负担得起：Q4_K_M 下短上下文能放进 4 GB 显卡，用满训练窗口也能放进 8 GB 显卡。这也让它成为本站少数在纯 CPU 机器上也现实可用的模型之一。下方体积使用计算器的通用比特率，因为未能核对到 GGUF 文件大小，各档位的质量损失也未公布。

可用格式

Baidu ERNIE 4.5

百度开源的混合专家模型：总参数约 21.8B，每个 token 约激活 3B，由 64 个路由专家（每个 token 选 6 个）加 2 个共享专家组成。总参数决定显存，激活参数决定速度，所以它需要 20B 级模型的显存，每个 token 读取的数据量却和 3B 模型差不多。Q4_K_M 在 4K 上下文下约需 14.1 GB，在 16 GB 显卡上正好处于“宽裕”的边缘，到 32K 就偏紧了；24 GB 显卡，或 24 GB 的 Mac（靠 GPU 可用的那部分统一内存）才有真正的上下文余量。下方体积使用计算器的通用比特率，因为未能核对到 GGUF 文件大小，各档位的质量损失也未公布。

可用格式

Allen AI OLMo

Allen AI 完全开源的 7B 模型，训练数据、代码和中间检查点一并公开。上一代只有 4K 上下文，OLMo 3 达到 64K（由 8K 基础通过 YaRN 扩展而来）。每四层中有三层使用 4K 滑动窗口，这正是长上下文负担得起的原因。不过它仍是完整的多头注意力，没有共享 KV 头，所以长上下文的代价比大多数 7B–8B 模型高。Q4_K_M 在 4K 上下文下约需 6.8 GB，32K 下约 10.9 GB；如果没有滑动窗口，32K 需要约 22 GB。下方体积使用计算器的通用比特率，因为未能核对到 GGUF 文件大小，各档位的质量损失也未公布。

可用格式

Meta Muse

Meta 自 Llama 4 以来第一个开放权重模型，8 月以 Apache 2.0 发布，目标就是单卡运行。它是稠密模型：28B 的文本解码器，通过单独的视觉编码器读取图像，输出文本。每四层中有三层使用 2K 滑动窗口，其余层只有 2 个 KV 头，所以长上下文格外便宜。Q4_K_M 在 4K 上下文下约需 17.7 GB，用满 128K 窗口也只要 19.4 GB，两种情况在 24 GB 显卡上都很宽裕。Q5_K_M 在 24 GB 上偏紧，Q8_0 需要 32 GB 显卡。视觉编码器（GGUF mmproj 文件约 1.4 GB）和 Meta 可选的投机解码草稿模型会额外占用显存，不含在上述数字内。体积按已公布的 GGUF 文件大小计算，Q4_K_M 一行是 Meta 官方发布的版本。基准成绩是 Meta 自己报的，各档位的质量损失也未公布。

可用格式

Qwen3.8

Qwen 下一代架构的预览版，8 月发布：125B 的混合专家模型，每个 token 约激活 6B 参数，另带一张 51B 的 n-gram 查找表。llama.cpp 从内存或磁盘按需读取这张表，它从不占用显存，但要占磁盘空间，而且打包在 GGUF 文件里，所以文件比下面的数字大得多。48 层中只有 12 层保留会增长的 KV 缓存，即使用满 256K 窗口也只多约 7.5 GB。Q4_K_M 在 4K 上下文下约需 79 GB，256K 下约 87 GB，128 GB 的 Mac 或 DGX Spark 能从容运行。单张 24 或 32 GB 显卡只有把专家卸载到系统内存才能跑。llama.cpp 以 `qwen4exp` 架构支持它。下方体积使用计算器的通用比特率（没有哪个文件大小能把模型本身和查找表分开），各档位的质量损失也未公布。

可用格式

Alibaba Qwen3.6

今年被推荐最多的 24 GB 显卡模型之一：总参数 35.6B，每个 token 约激活 3B，每个 token 读取的数据量和 3B 模型差不多。40 层中只有 10 层保留会增长的 KV 缓存，所以上下文很便宜：Q4_K_M 在 4K 下约需 23.4 GB，32K 下约 24.0 GB。按本站的规则，这在 24 GB 显卡上属于「勉强」而不是「宽裕」，因为本站计入了多数指南忽略的运行缓冲；32 GB 显卡，或 48 GB 的 Mac（靠 GPU 可用的那部分统一内存）才有真正的余量。它通过单独的视觉编码器读取图像。体积按已公布的 GGUF 文件大小计算，各档位的质量损失未公布。

可用格式

Alibaba Qwen3.6

Qwen3.6 这一代的稠密模型，也是很受欢迎的本地写代码模型。它和更新的 Qwen3.8 27B 结构相同：64 层中只有 16 层保留会增长的 KV 缓存。Q4_K_M 在 4K 上下文下约需 19.1 GB，32K 下约 21.0 GB，两种情况在 24 GB 显卡上都很宽裕。Q5_K_M 在 24 GB 上偏紧；16 GB 显卡在这里列出的任何档位都装不下。体积按 bartowski 发布的 GGUF 文件计算，Unsloth 的同档位文件约小 1 GB。各档位的质量损失未公布。

可用格式

Alibaba Qwen3.5

Qwen 最新的小尺寸模型，8 到 16 GB 显卡的常见选择。32 层中只有 8 层保留会增长的 KV 缓存，所以在普通硬件上也能用长上下文。Q4_K_M 在 4K 下约需 6.6 GB，32K 下约 7.5 GB，8 GB 显卡就能从容运行；用满 256K 窗口约需 15.2 GB。Q8_0 约需 10.4 GB，12 GB 起就很宽裕。Qwen3.5 的小尺寸默认关闭推理模式；它通过单独的视觉编码器读取图像。体积按已公布的 GGUF 文件大小计算，各档位的质量损失未公布。

可用格式

Alibaba Qwen3.5

Qwen3.5 的 4B 尺寸，适合 4 到 8 GB 显卡、基础款 Mac 和纯 CPU 机器。32 层中只有 8 层保留会增长的 KV 缓存。Q4_K_M 在 4K 上下文下约需 3.3 GB，32K 下约 4.3 GB，所以 6 GB 显卡就够长对话使用；用满 256K 窗口约需 12 GB。Qwen3.5 的小尺寸默认关闭推理模式；它通过单独的视觉编码器读取图像。体积按已公布的 GGUF 文件大小计算，各档位的质量损失未公布。

可用格式

Alibaba Qwen3.5

Qwen3.5 的 2B 尺寸，几乎什么硬件都能跑：老显卡、基础款 Mac、迷你主机和纯 CPU 服务器。24 层中只有 6 层保留会增长的 KV 缓存，每层只有 2 个 KV 头。Q4_K_M 在 4K 上下文下约需 1.5 GB，32K 下约 1.9 GB，用满 256K 窗口约 4.8 GB；即使 Q8_0，4K 下也只要约 2.2 GB。Qwen3.5 的小尺寸默认关闭推理模式。体积按已公布的 GGUF 文件大小计算，各档位的质量损失未公布。

可用格式

Alibaba Qwen3.5

最小的 Qwen3.5，适合手机、单板电脑，或者在大模型旁边当快速草稿/路由模型。Q4_K_M 在 4K 上下文下约需 0.6 GB，32K 下不到 1 GB。用满 256K 窗口约需 3.8 GB，几乎全是缓存，所以在这里超长上下文比权重本身更占内存。下方体积使用计算器的通用比特率，因为未能核对到 GGUF 文件大小，各档位的质量损失也未公布。

可用格式

Xiaomi MiMo

小米的开放权重旗舰，今年秋天位列开源模型排行榜前列：约 1.02 万亿参数，每个 token 激活约 42B，MIT 许可。发布的权重本身就是 4 比特（专家层为 MXFP4），GGUF 版本只是重新打包、没有再次量化。在这个档位下 4K 上下文约需 604 GB，超过本索引里任何一台单机：最大的 Mac Studio 给 GPU 的约 384 GB，四张 80 GB 的 H100 合计 320 GB。八张 80 GB 显卡（640 GB）大约是能装下它的最小服务器，按本站规则也只算「勉强」。收录它是为了让计算器能把这一点说清楚。70 层中只有 10 层保留会增长的缓存，所以即使 100 万 token 也只多约 50 GB。llama.cpp 以 `mimo2` 架构运行它，视觉通过单独的编码器加载。体积按已公布的 GGUF 文件计算，各档位的质量损失未公布。

可用格式

JetBrains Mellum

JetBrains 面向编程智能体和快速子智能体的开源代码模型，10 月以 Apache 2.0 发布。它是 12B 的混合专家模型，每个 token 约激活 2.5B 参数，生成速度大致相当于 3B 模型。Q4_K_M 在 4K 上下文下约需 8.6 GB，用满 128K 窗口也只要 10.5 GB，因为 28 层中只有 7 层保留会增长的缓存。10 GB 或 12 GB 显卡可以从容运行，8 GB 显卡装不下；Q8_0 适合 16 GB 显卡。llama.cpp 以 `mellum` 架构支持它。体积按 JetBrains 官方 GGUF 文件计算；官方公布的是 KL 散度而不是困惑度，所以不显示质量损失。

可用格式

IBM Granite

IBM Granite 4.2 系列（3B、8B、30B）中的 8B 稠密推理模型，8 月以 Apache 2.0 发布。默认开启思考，可通过聊天模板切换为不思考或低强度模式。它不是 Granite 4.0 那种混合架构，而是普通 Transformer，llama.cpp 以 `granite` 架构运行，40 层全部保留完整缓存：Q4_K_M 在 4K 上下文下约 6.3 GB，32K 约 11.1 GB，用满 128K 窗口约 27.6 GB。所以短上下文用 8 GB 显卡就够，处理长文档需要 16 GB。Q4_K_M 体积按已发布的 GGUF 文件计算；IBM 没有公布各量化档位的困惑度，所以不显示质量损失。

可用格式

IBM Granite

IBM Granite 4.2 系列中最大的模型，8 月以 Apache 2.0 发布。和 8B 一样是普通的稠密 Transformer，不是 Granite 4.0 的混合架构，64 层全部保留完整缓存，所以上下文并不便宜：Q4_K_M 在 4K 下约需 19.6 GB，32K 约 27.3 GB，用满 128K 窗口约 53.7 GB。24 GB 显卡到 8K 都很宽裕，16K 偏紧；32K 需要 32 GB 显卡，用满窗口需要 80 GB 显卡或 96 GB 的 Mac。Q8_0（4K 下约 33.6 GB）需要 48 GB 显卡或 64 GB 的 Mac。体积按 IBM 官方 GGUF 文件计算；IBM 没有公布各量化档位的困惑度，所以不显示质量损失。

可用格式

IBM Granite

IBM Granite 4.2 系列中最小的模型，8 月以 Apache 2.0 发布：3.7B 稠密 Transformer，面向笔记本、小显存显卡和 CPU 服务器。Q4_K_M 在 4K 上下文下约需 2.7 GB，32K 约 5.1 GB，用满 128K 窗口约 13.3 GB，所以 8 GB 显卡到 32K 都很宽裕，64K 偏紧。Q8_0 在 4K 下也只要 4.4 GB，在显卡上几乎没有理由再往下压。体积按 IBM 官方 GGUF 文件计算；IBM 没有公布各量化档位的困惑度，所以不显示质量损失。

可用格式

Liquid AI LFM2.5

Liquid AI 在 10 月发布的 LFM2.5 系列中最大的模型：24B 混合专家推理模型，每个 token 约激活 2.45B 参数，面向端侧智能体和工具调用，回答前总会先思考。40 层中只有 10 层保留会增长的 KV 缓存，所以长上下文很便宜：Q4_K_M 在 4K 下约需 15.3 GB，32K 约 15.9 GB，用满 128K 窗口约 17.9 GB。在 16 GB 显卡上偏紧，24 GB 显卡在任何上下文下都很宽裕；Q8_0（约 26.7 GB）需要 32 GB 显卡。仅支持文本。体积按 Liquid 官方发布的 GGUF 文件计算，各档位的质量损失未公布。

可用格式

Meta Muse

Meta 目前最大的开放权重模型，10 月以 Muse Model License 发布：816B 混合专家模型，每个 token 约激活 42B 参数，面向编程和智能体任务，支持图像和音频输入。只有最小的量化版本能在单台机器上运行。Q2_K（ggml-org 发布的 304 GB 文件）在 4K 上下文下约需 319 GB，到 128K 也只要 327 GB，因为 62 层中只有 16 层的缓存会随上下文增长——512 GB 的 Mac Studio 可以从容运行，四张 80 GB 的 H100 则偏紧。用满 100 万上下文约需 389 GB。Q4_K_S（470 GB）和 Q8_0（872 GB）在本站收录的任何单台机器上都装不下。视觉和音频编码器是另外 2–4 GB 的文件，未计入。体积按已发布的 GGUF 文件计算；基准成绩是 Meta 自己报的，各档位的质量损失未公布。它的许可证不是常规开源许可：Meta 的仓库需要申请访问才能下载；基于它的产品须注明"Built with Muse Spark Open"；年收入超过 2000 万美元的公司若要把它作为 API 服务提供，须先与 Meta 另签协议。

可用格式

NVIDIA Nemotron

NVIDIA 的 Nemotron 3.5 Bolt 是 74B 混合专家模型，每个 token 约激活 9B 参数，目标是装进 24 GB 显卡。它由 Nemotron 3.5 Super VL 压缩而来，只有一个版本，即 NVIDIA 官方原生 2-bit 文件，22.0 GB。88 层中只有 8 层的缓存随上下文增长，所以上下文很便宜：4K 约 23.1 GB，128K 约 24.1 GB，用满 256K 约 25.2 GB。这正是 NVIDIA 设计的 24 GB，但超过了本站的宽裕线，所以 24 GB 显卡判定为偏紧；32 GB 显卡或 48 GB 的 Mac 可以从容运行。图像编码器是另外 1.7 GB 的文件。基准成绩是 NVIDIA 自己报的，2-bit 版本的质量损失未公布。

可用格式

NVIDIA Nemotron

NVIDIA 的 Nemotron 3.5 Super VL 是 120B 混合专家视觉语言模型，每个 token 约激活 12B 参数，面向编程、工具调用和文档处理，上下文最长 100 万 token。88 层中只有 8 层的缓存随上下文增长，所以即使用满窗口也不贵：Q4_0（ggml-org 发布的 71.8 GB 文件）在 4K 下约需 75 GB，100 万上下文约 84 GB。128 GB 的 Mac 或 DGX Spark 128G 可以从容运行，单张 80 GB 显卡偏紧。Q8_0（128 GB）需要 256 GB 的 Mac。视觉编码器是另外 1–1.7 GB 的文件。体积按已发布的 GGUF 文件计算；基准成绩是 NVIDIA 自己报的，各档位的质量损失未公布。

可用格式

NVIDIA Nemotron

NVIDIA Nemotron 3.5 系列中的小尺寸成员：30B 纯文本混合专家模型，每个 token 约激活 3B 参数，生成速度大致相当于 3B 模型。52 层中只有 6 层的缓存随上下文增长，所以长上下文几乎不占额外显存：Q4_0（ggml-org 发布的 18.9 GB 文件）在 4K 下约需 19.8 GB，128K 约 20.6 GB，用满 256K 约 21.4 GB。24 GB 显卡到 128K 都很宽裕，只有用满窗口时偏紧；16 GB 显卡装不下。Q8_0（约 35 GB）需要 48 GB 显卡或 64 GB 的 Mac。另有一个可选的 1.2 GB 草稿文件用于投机解码，单独下载。体积按已发布的 GGUF 文件计算；基准成绩是 NVIDIA 自己报的，各档位的质量损失未公布。

可用格式

inclusionAI Ling

inclusionAI（蚂蚁集团）的 Ling-3.1-flash，10 月以 MIT 许可发布：560B 混合专家推理模型，每个 token 激活 25B 参数。它面向智能体、编程和长时间的办公任务。72 层中只有 9 层保留会增长的缓存，而且存的是 MLA 压缩向量，所以即使用满 256K 窗口，缓存也只多约 3 GB——决定它能在什么硬件上跑的是权重。Q4_K_M 在 4K 上下文下约需 371 GB，超过本索引里任何一张单卡。512 GB 的 Mac Studio 能分给 GPU 约 384 GB，按本站规则只能算「勉强」装下；服务器上，官方的参考配置是 8 张 H200 或 4 张 GB300 跑 FP8。Q8_0 约需 628 GB。官方称上下文窗口为 100 万 token，但发布的 config 设定为 262,144 个位置且没有缩放配置，所以这里按这个上限计算。llama.cpp 从 b11571 版起以 `bailingmoe3` 架构运行它。体积按已公布的 GGUF 文件计算，制作者给出的是 KL 散度而非困惑度，所以不显示质量损失。

可用格式

Reflection Beam

Reflection AI 的首个开放权重模型，10 月以 Apache 2.0 发布：501B 纯文本混合专家模型，每个 token 约激活 23B 参数，面向编程和智能体任务。上下文窗口 100 万 token；52 层中只有 9 层的缓存随上下文增长，所以上下文很便宜：Q2_K（DevQuasar 发布的 182 GB 文件）在 4K 下约需 191 GB，128K 约 196 GB，用满 100 万上下文约 230 GB。512 GB 的 Mac Studio 在任何上下文下都能从容运行，256 GB 的到 128K 为止偏紧。Unsloth 的动态 4-bit 文件 UD-Q4_K_XL（307 GB）在 4K 下约需 321 GB，512 GB 的 Mac 仍然装得下；Q8_0（533 GB）在本站收录的任何单台机器上都装不下。体积按已发布的 GGUF 文件计算；基准成绩是 Reflection 自己报的，各档位的质量损失未公布。

可用格式