数据更新日志

共 185 条记录，最新的在前。

最后更新 2026-10-20

RSS

2026-10-20AMD ROCm 指南现在覆盖 Radeon RX 9000 系列和 AMD 核显。RX 9070 系列已在 AMD 官方 ROCm 支持列表中，需要 ROCm 7；指南给出了它们的编译目标，并说明 Ryzen AI 和较老的核显如何用系统内存跑模型。编译命令已按 llama.cpp 当前文档重新核对，没有变化。
2026-10-20Gemma 4 12B 现在按已发布的 GGUF 文件计算体积，不再用通用比特率。Q4_K_M 在 32K 上下文下约需 8.5 GB；各显卡的判定都没有变化。页面也注明了 bartowski 的 Q4_K_M 文件比 unsloth 的大约 0.5 GB。
2026-10-20新增 North Mini Code 1.0——Cohere 的开源编程模型。它是 30B 混合专家，每个 token 约激活 3B 参数，49 层中只有 13 层的缓存随上下文增长：Q4_K_M 在 4K 下约需 20 GB，32K 约 21 GB，24 GB 显卡很从容。16 GB 显卡可以跑 Q3_K_M，但只是勉强装下。
2026-10-20整个索引现在可以 JSON 形式下载。所有模型及其架构、量化档位和文件体积在 /data/v1/models.json，所有显卡及其可用显存和带宽在 /data/v1/gpus.json——每次更新时重新生成，与其他数据一样采用 CC BY 4.0 许可。
2026-10-20模型对比现在支持到 256K 上下文，并按 Mac 实际可用的内存判定。上下文档位为 4K 到 256K，可以看到混合注意力模型在长上下文下反超常规模型；超出模型自身窗口时会直接说明，而不是给出一个体积。"能否装进显卡"一行现在按 Mac 实际可用的内存来算（以前 16 GB 的 Mac 按满 16 GB 判定），每个模型也按它自己模型页所用的档位计算。
2026-10-19在中文模型库里筛选不会再跳到英文版了。以前在中文模型库点显卡、尺寸或格式筛选，整页会切成英文；现在会留在中文页。模型卡片的速度数字下方也直接标明是 RTX 4090 的数据；手机上卡片不再显示硬件标签，列表更短。
2026-10-19显存计算器现在把估算画成一根铺满你显卡的条：模型权重、KV 缓存和激活缓冲各占一段，剩下的是空闲，虚线标出判定变黄的位置，拉长上下文时能直接看到它吃掉多少显存。超出显卡的部分用斜纹标出，并注明是溢出到系统内存还是装不下。
2026-10-19新增 Gemma 4 12B——Google 6 月发布、本站此前漏收的中等尺寸 Gemma 4。它是 12B 稠密模型，256K 上下文，文本、图像、音频都不需要单独的编码器；48 层中只有 8 层的缓存随上下文增长，所以 Q4 下 32K 约 8.6 GB，12 GB 显卡很从容，16 GB 显卡能加载完整窗口。在核对到 GGUF 文件大小之前，体积为估算值。
2026-10-19运行时版本更新：llama.cpp b11721、vLLM v0.32.0。vLLM 现在要求 Python 3.11 及以上（本站的安装命令本来就建 3.12 环境），并且默认不再允许其他来源的浏览器请求，除非传 --allowed-origins。
2026-10-18Muse Spark Open 页面现在写明了它的许可证条款：Meta 的仓库需要申请访问，基于它的产品须注明"Built with Muse Spark Open"，大公司要把它作为 API 提供须另签协议。
2026-10-18Nous Hermes 3 Llama 3.1 8B 不再显示 Llama 3.1 8B 的实测速度。两者名字里有相同的片段，但本站从未实测过 Hermes 3；它在显卡页上的速度现在和其他未实测的模型一样，按每张卡的校准范围给出。
2026-10-18现在可以在买之前先"听"速度了。计算器的每个结果都能直接跳到速度播放页，带上同样的模型、档位、上下文和显卡；显卡页也能和同显存档位的卡、以及升级一档的卡并排播放，用的是这张卡能从容运行的最大模型。只有两张卡都有实测或校准过的速度时才会出现这个链接。
2026-10-18重新核对了运行时版本：llama.cpp 更新到 b11716，Ollama 更新到 v0.40.6，ExLlamaV3 更新到 v1.6.3；vLLM（v0.31.0）没有变化。这个 Ollama 版本能读取使用新 Q2_0 类型的 GGUF 文件。本周没有本站漏收的新开源权重模型。
2026-10-18显卡页不再把 RTX 4090 的速度印成你打开的这张卡自己的实测。这一列现在是这张卡自己的数字：实测、按它的 Llama 2 7B 跑分缩放出来的范围，或带宽天花板。混合专家模型的天花板按激活参数计算，不是整个文件。新工具 /tools/feel/ 把一句话按这个速度在两张卡上并排流出，并且拒绝拿天花板来播。
2026-10-17超大模型的下载命令现在能处理分卷文件了。约 48 GB 以上的版本常常拆成多个文件放在一个文件夹里，以前的命令只请求一个并不存在的完整文件名，结果什么都没下载。现在会下载全部分卷，并让 llama.cpp 指向第一个分卷。Ling-3.1-flash 的文件另有命名方式，现在显示需要填写的占位符，而不是一个错误的文件名。
2026-10-17Reflection AI 的 Beam 已收录。它是 501B 混合专家模型，每个 token 约激活 23B 参数，以 Apache 2.0 开放权重发布。52 层中只有 9 层的缓存随上下文增长，所以 Q2_K 在 4K 下约需 191 GB，用满 100 万上下文约 230 GB：512 GB 的 Mac Studio 可以从容运行，256 GB 的到 128K 为止偏紧。
2026-10-17inclusionAI 的 Ling-3.1-flash 已收录：560B 混合专家推理模型（每个 token 激活 25B，MIT 许可），面向智能体和编程。72 层中只有 9 层保留会增长的缓存，所以上下文很便宜，但光是权重就超出任何单张显卡：Q4_K_M 约 371 GB，512 GB 的 Mac Studio 也只能勉强装下。收录它是为了让计算器能把这一点说清楚。
2026-10-17重新核对了运行时版本：llama.cpp 更新到 b11703；Ollama（v0.40.5）、vLLM（v0.31.0）和 ExLlamaV3（v1.6.2）没有变化。最近几天发布的开源权重模型，本站都已收录。
2026-10-16Nemotron 3.5 Lightning 和 IBM Granite 4.2 系列的其余两个尺寸已收录。Lightning 是 30B 混合专家模型，每个 token 约激活 3B 参数；52 层中只有 6 层的缓存随上下文增长，所以 Q4_0 在 4K 下约需 19.8 GB，到 128K 也只要 20.6 GB，24 GB 显卡可以从容运行。Granite 4.2 30B 是稠密模型，4K 下约需 19.6 GB，24 GB 显卡在短上下文下从容运行。Granite 4.2 3B 只要 2.7 GB，本站收录的任何显卡都能跑。
2026-10-16NVIDIA 的 Nemotron 3.5 Bolt 和 Super VL 已收录。Bolt 是为 24 GB 显卡打造的 74B 混合专家模型：NVIDIA 官方 2-bit 文件在 4K 下约需 23.1 GB，128K 约 24.1 GB，24 GB 显卡偏紧，32 GB 从容。Super VL 是它压缩前的 120B 视觉语言模型，Q4_0 约需 75 GB，128 GB 的 Mac 或 DGX Spark 128G 可以从容运行。两者 88 层中只有 8 层的缓存会随上下文增长，所以长上下文很便宜。
2026-10-16Meta 的 Muse Spark Open 已收录：816B 混合专家模型，每个 token 约激活 42B 参数，支持图像和音频输入。最小的 304 GB Q2_K 版本在 4K 上下文下约需 319 GB，128K 约 327 GB，所以 512 GB 的 Mac Studio 能跑，四张 80 GB H100 也能勉强装下。更大的版本在本站收录的任何单台机器上都装不下。
2026-10-16llama.cpp 的服务端现在默认监听 9931 端口，不再是 8080。这是它 v0.7.0 版本（构建 b11671）改的默认值；本站所有 llama-server 命令都显式写了 --port，照抄仍然可用，但不带 --port 启动的服务不会再在 8080 上响应。Ollama 更新到 v0.40.5；vLLM 和 ExLlamaV3 没有变化。
2026-10-15重新核对了运行时版本：llama.cpp 更新到 b11632，Ollama 更新到 v0.40.4，ExLlamaV3 更新到 v1.6.2；vLLM（v0.31.0）没有变化。这个 Ollama 版本可以在终端里直接运行决策模型，并复用已加载的模型以加快启动。本周没有既已放出权重、又适合本地硬件的新开源模型。
2026-10-14计算器现在会按每张卡自己在 llama.cpp 上的实测速度估算生成速度，为结果给出可直接复制的 llama.cpp、Ollama 和 vLLM 命令，还能把结果保存为图片。速度估算只对 7B–33B 的稠密模型显示，这是它经过核对的范围；「我有这张卡」模式默认每个模型只列最佳档位，并按你所选显卡的速度排序。
2026-10-14Liquid AI 的 LFM2.5 24B-A2B 已收录：24B 混合专家推理模型，每个 token 约激活 2.45B 参数，面向端侧智能体。40 层中只有 10 层保留会增长的 KV 缓存，所以 Q4_K_M 在 4K 上下文下约需 15.3 GB，用满 128K 窗口也只需约 17.9 GB：16 GB 显卡偏紧，24 GB 显卡在任何上下文下都很宽裕。
2026-10-14IBM 的 Granite 4.2 8B 已收录：Apache 2.0 许可的稠密推理模型，128K 上下文。Q4_K_M 在 4K 上下文下约需 6.3 GB，8 GB 显卡可以从容运行；32K 约需 11.1 GB，处理长文档需要 16 GB 显卡。默认开启思考，可通过聊天模板关闭。
2026-10-13计算器又多了三个便利功能。多模态模型现在可以把视觉编码器算进去：手动填写大小，或一键从模型的 GGUF 仓库读取。可以把一个结果固定为 A，改设置后直接看差多少；还可以保存常用的机器，点一下就能切回你那一张或几张卡。
2026-10-13计算器现在会估算长提示词要等多久才出第一个字。对 59 张显卡和 Mac，它以 llama.cpp 社区跑分里各自实测的提示词处理速度为起点，按所选模型和上下文换算。例如 Mac M3 Pro 给 Llama 3.1 8B 读入 8K 提示词约 41 秒，RTX 4090 读入 32K 约 5 秒。没有公开跑分的卡不给数字。
2026-10-13计算器现在支持混搭显卡、多人同时使用估算，并显示下载大小。再加一张不同型号的卡（比如 3090 旁边插一张 3060），显存按 llama.cpp 和 Ollama 的按层拆分方式相加，速度上限会跟着较慢的那张卡走。每个结果还会按本站 vLLM 命令使用的显存占比，给出 4K、8K、32K 上下文下能同时容纳几个满长度请求。
2026-10-13计算器现在可以估算微调显存。选择 QLoRA、LoRA 或全参数微调，设好 LoRA 秩、序列长度、批大小和梯度检查点，它会把基座权重、可训练适配器及其优化器状态、激活值和损失计算加起来，并在你的显卡上对比三种方法。估算对应标准的 transformers + PEFT 训练；Unsloth 等工具公布的最低显存更低。
2026-10-13显存计算器现在可以估算 Hugging Face 上的任意模型。粘贴仓库名或链接（GGUF 仓库也行），它会读取模型自己的配置：层数、KV 头、滑动窗口和混合注意力，以及参数量。由你的浏览器直接请求 Hugging Face。如果本站已收录该模型，它会推荐收录版本，那里的体积按实际文件计算。
2026-10-13显存计算器更好用了。现在可以按名称、大小或用途搜索模型，中英文都行（"qwen 27b"、"千问"、"写代码"），常见显卡一键就能选。选好显卡后，它会推荐和首页相同的三个模型。显卡列表按厂商分组；在手机上，调整设置时底部会一直显示总显存和能否装下。
2026-10-13JetBrains 的 Mellum2.1 已收录：适合 10 GB 和 12 GB 显卡的开源代码模型。它是 12B 的混合专家模型，每个 token 约激活 2.5B，Apache 2.0 许可。Q4_K_M 在 4K 上下文下约需 8.6 GB，用满 128K 窗口约 10.5 GB，所以 12 GB 显卡用满 128K 也能从容运行，10 GB 显卡适合较短的上下文，8 GB 不行。几篇指南里的模型数量也一并更正了，其中 RTX 4060 Ti 16G 指南落后得最多。
2026-10-12搜索结果里的页面摘要现在完整了。Bing 提示本站很多摘要太短，主要是中文页面。模型、显卡和指南页的摘要现在会补上页面本身给出的事实：4K 下的体积、能运行它的最小显卡、指南涉及的显卡和模型。中文格式页的硬件要求也不再显示英文。
2026-10-12MiMo-V2.6-Pro 已收录，这是读者问得最多的开源模型。小米的 1 万亿参数 MoE（每 token 激活约 42B，MIT 许可）发布时就是 4 比特，即便如此，4K 上下文也约需 604 GB，超过这里列出的任何一台单机：512 GB 的 Mac Studio 给 GPU 的约 384 GB，四张 80 GB 显卡合计 320 GB。它的页面和计算器现在会直接说明这一点；8 张 80 GB 的服务器大约是能装下它的最小配置。
2026-10-12重新核对了运行时版本：Ollama 更新到 v0.40.3，llama.cpp 更新到 b11559。这个 Ollama 版本只暂停了嵌入模型的后台升级，对话模型仍会在后台升级。vLLM（v0.31.0）和 ExLlamaV3（v1.6.1）没有变化；本周的新开源模型都还不能在 llama.cpp 里运行。
2026-10-11重新核对了运行时版本：llama.cpp 更新到 b11552，ExLlamaV3 更新到 v1.6.1；Ollama（v0.40.2）和 vLLM（v0.31.0）没有变化。本周还没有适合本站硬件的新开源模型。
2026-10-11Qwen3.5 的小尺寸已收录：4B、2B 和 0.8B，适合 4 到 8 GB 显卡、基础款 Mac、迷你主机和纯 CPU 机器。Q4_K_M、4K 上下文下分别约需 3.3 GB、1.5 GB 和 0.6 GB；即使用满 256K 窗口也分别只要约 12 GB、4.8 GB 和 3.8 GB，因为只有四分之一的层保留 KV 缓存。0.8B 的体积为估算，4B 和 2B 按已公布的文件计算。
2026-10-10补上了三个被漏掉的常用 Qwen 模型：Qwen3.6 35B-A3B、Qwen3.6 27B 和 Qwen3.5 9B。Qwen3.6 35B-A3B 在 Q4_K_M、4K 上下文下约需 23.4 GB，24 GB 显卡上偏紧，32 GB 上宽裕；Qwen3.6 27B 约需 19.1 GB，24 GB 上宽裕；Qwen3.5 9B 约需 6.6 GB，8 GB 显卡就能从容运行，用满 256K 窗口也只要约 15 GB。三者都只在四分之一的层保留 KV 缓存，所以长上下文很便宜。体积按已公布的 GGUF 文件计算。
2026-10-10新增 Qwen3.8-Flash-Next：125B 的混合专家模型，每个 token 约激活 6B 参数，是 Qwen 下一代架构的预览版。Q4_K_M 在 4K 上下文下约需 79 GB，用满 256K 窗口也只要 87 GB，128 GB 的 Mac 或 DGX Spark 能从容运行。它额外的 51B n-gram 查找表从内存或磁盘读取，不占显存；这张表打包在下载文件里，所以文件会比这些数字大得多。体积为估算值。
2026-10-10Ollama v0.40.2 会在你首次运行旧模型时在后台升级它，并把原文件留作备份，所以这些模型暂时会多占磁盘空间，直到后续版本自动清理备份。SSD 小的电脑或基础款 Mac 值得留意。运行时版本已更新为 Ollama v0.40.2、llama.cpp b11539。
2026-10-09新增 Muse Glimmer 30B：Meta 自 Llama 4 以来第一个开放权重模型，目标是单卡运行。它是 28B 的稠密文本模型，也能读图，8 月以 Apache 2.0 发布。它的长上下文格外便宜：Q4_K_M 在 4K 下约需 17.7 GB，用满 128K 窗口也只要 19.4 GB，两种情况在 24 GB 显卡上都很宽裕。体积按已公布的 GGUF 文件计算，视觉编码器另外占用、不含在内。llama.cpp 更新到 b11514，Ollama 更新到 v0.40.1。
2026-10-08内存计算器现在能处理比你显卡还大的模型。可以选 2 到 4 张同型号显卡，按 llama.cpp 默认的拆分方式合并计算，并明确告诉你：多卡换来的是空间，不是速度。模型仍然装不下时，它会估算 GPU 上能留多少层、其余部分需要多少系统内存，以及三种常见内存配置下的速度上限。混合专家模型现在也有近似的速度上限，只按每个 token 实际激活的参数计算。
2026-10-08内存计算器现在不止回答第一个问题，还会接着回答后面三个。选好模型和你的显卡后，它会列出该模型提供的全部量化档位（按你的上下文计算大小），并标出能从容装进你显卡的最高质量版本；给出这张卡最长能开多少上下文；以及按显存带宽算出的生成速度上限。KV 缓存现在可以选 q8_0 或 q4_0——这是 llama.cpp 和 Ollama 的设置，长上下文时大约能把缓存减半或减到四分之一，页面会给出具体参数。显卡也可以直接在计算器里选了。
2026-10-08内存计算器「GPU → 模型」模式里的「计算」链接现在能用了：以前点了只是地址变了，页面还停在列表上；现在会直接打开该模型，并按你正在看的那张卡给出结论。链接里带了一张本站不认识的卡时，不再谎称「没有模型装得下」。所选上下文超过模型本身上限时会给出提示；自定义模型的分享链接会带上参数量和层数。「最小的卡」现在指同容量里的零售卡，纯 CPU 内存档位也不再被算作显卡。
2026-10-08「页面不存在」页上的语言切换现在会带你去另一种语言的首页，之前它指向的也是一个不存在的页面。另外，现在只会把内容真正变化了的页面报给搜索引擎，而不是每次更新都把大半个网站报一遍。
2026-10-08新增两张 32 GB 工作站显卡：AMD Radeon AI PRO R9700 和 Intel Arc Pro B70。两者显存与 RTX 5090 相同，带宽却只有它的一小部分。R9700（640 GB/s）在 4K 下可从容运行 90 个模型中的 74 个，并能在 ROCm 上通过 vLLM 跑 AWQ 和 GPTQ；B70（608 GB/s）可从容运行 72 个，与所有 Arc 显卡一样只能跑 GGUF。规格取自 AMD 和 Intel 官方产品页。ExLlamaV3 更新到 v1.6.0，llama.cpp 更新到 b11480。
2026-10-07Ollama v0.40.0 现已成为其最新正式版，在 Apple 芯片上会默认用 MLX 运行部分模型系列，Ollama 点名了 Qwen3.8、Gemma 4、Qwen3.6 和 Qwen3.5。本站计算的是 GGUF 版本的体积，而 Ollama 没有公布其 MLX 版本有多大，三篇 Mac 指南现已注明这一点。llama.cpp 更新到 b11458；vLLM v0.31.0 和 ExLlamaV3 v1.5.4 未变。
2026-10-06基准测试页上的当前运行时版本更新为 vLLM v0.31.0 和 llama.cpp b11434，均取自各项目自己的发布页；Ollama（v0.35.1）和 ExLlamaV3（v1.5.4）未变。llama.cpp 还发布了 v0.6.0，这是本站记录中它的第一个带版本号的正式发布。网站上的模型和显存数字均不受影响。
2026-10-05本站的基准和显存数据现采用 CC BY 4.0 许可。可以复制和再利用，包括商业用途，只需注明出自 quantized.uk 并附上链接。条款页新增了相应一节；模型权重和第三方名称仍受各自条款约束。
2026-10-05新模型和新硬件现在一起显示在首页靠上的位置。「最近收录」原来要往下翻好几屏才能看到，而且只列模型，像 DGX Spark 这样新加的硬件在首页上没有入口。现在它就放在「你的卡能跑什么」选择器下方。
2026-10-05新增 NVIDIA DGX Spark，包括 64GB 和 128GB 两个版本。两者芯片相同，内存带宽同为 273 GB/s，内存由 CPU、GPU 和操作系统共用，所以本站按整块内存判断能否装下，超出的一律视为无法加载。在 4K 上下文下，64GB 版可宽裕运行 90 个模型中的 82 个，128GB 版为 84 个。64GB 版装不下 GPT-OSS 120B：它的原生版本约 66 GB。新指南讲清楚该买哪一版、各能跑什么以及如何配置。两台设备的对比问答在装得下的模型数量不同时，不再声称它们装得下相同的模型。
2026-10-05新增 OLMo 3 7B，OLMo 2 7B 现在指向它。这是 Allen AI 完全开源的 7B 模型，训练数据、代码和检查点一并公开。它的上下文达到 64K，而 OLMo 2 只有 4K；短上下文下的显存需求与 OLMo 2 相同。每四层中有三层使用短滑动窗口，所以 Q4_K_M 在 4K 下约需 6.8 GB，32K 下约 10.9 GB；如果没有滑动窗口，32K 需要约 22 GB。体积为估算值，因为未能核对到文件大小。各指南中统计索引模型数量的数字已更新为新的总数。
2026-10-04已在各项目自己的发布页上重新核对当前运行时版本：llama.cpp b11390、Ollama v0.35.1、vLLM v0.30.0（未变）、ExLlamaV3 v1.5.4。ExLlamaV2 仍停留在 2025 年 7 月的 v0.3.2，其 README 依然写明项目已归档。常见问题页还新增了两个问答：Intel Arc 显卡能用哪种格式，以及该选 NVIDIA、AMD 还是 Intel —— 数字均由索引计算，包括为什么 16GB 的 Arc 卡比 16GB 的 NVIDIA 卡少装下四个模型。
2026-10-04新增 RTX 5090 指南，这是此前唯一没有指南的消费级显卡。实话实说：在短上下文下，32GB 只比 24GB 多装下本索引的两个模型；它真正换来的是 27B–32B 模型的长上下文和更高的速度上限。指南给出 8K 到 128K 的显存占用、Blackwell 显卡对软件栈的要求，以及如何确认模型真的跑在 GPU 上。
2026-10-04新增 12GB 显卡指南 —— RTX 3060 12G、RTX 4070 系列、RTX 5070 以及 12GB 版 RTX 3080，此前它们没有专门的指南。内容包括：8K、16K、32K 上下文下能装下哪些模型，14B 模型从哪里开始装不下（4K 宽裕、8K 偏紧、16K 装不下），如何用 Ollama 或 llama.cpp 运行，以及如何确认真的跑在显卡上。
2026-10-04新指南：在 Intel Arc 显卡上跑模型。内容包括两条路线 —— 用英特尔 SYCL 后端编译的 llama.cpp，以及无需编译、通过 Vulkan 使用 Arc 的 Ollama —— 如何确认显卡真的在干活，以及 B580、B570、A770、A750 各能装下什么。其中的速度数字是根据显存带宽推算的上限，不是实测：本站还没有人在 Arc 上跑过。另外，每个显卡页面现在都会链接适用于该卡运行时或显存容量的部署指南 —— 此前没有一个显卡页面链接任何指南。
2026-10-03Intel Arc 显卡已加入硬件列表：Arc B580 12G、B570 10G、A770 16G 和 A750 8G，显存容量与带宽取自英特尔官方规格页。每张卡都有自己的页面，显存计算器、格式向导和命令生成器也都认得它们。本站在 Arc 上推荐 GGUF，通过 llama.cpp 的 SYCL 后端或 Ollama 的 Vulkan 后端运行。命令生成器里 llama.cpp 的 Linux 本机编译命令现在也会跟随你的显卡：以前它对所有人都输出 NVIDIA（CUDA）编译方式，在 AMD 显卡上会直接失败，在纯 CPU 机器上也不对。
2026-10-03四个较老的模型已标为“旧版”，各自指向同一厂商、能在同样硬件上运行的新模型：Gemma 2 2B → Gemma 4 E2B，Gemma 2 9B → Gemma 4 E4B，Gemma 2 27B → Gemma 3 27B，Mistral 7B v0.3 → Ministral 3 8B。新模型的上下文为 128K–256K，旧模型只有 8K–32K；在 Q4_K_M 下显存占用相当或更少，只有 Gemma 4 E2B 多约 0.8 GB。旧页面继续保留；模型库默认隐藏旧版模型，可手动显示。
2026-10-03新增两个模型，都是为普通硬件挑选的。SmolLM3 3B 是 Hugging Face 完全开源的 3B 模型，训练数据一并公开；Q4_K_M 在 4K 上下文下约 2.3 GB，即使用满 64K 窗口也能放进 8 GB 显卡，在 CPU 上也现实可用。ERNIE 4.5 21B-A3B 是百度的混合专家模型，总参数约 21.8B，每个 token 约激活 3B；Q4_K_M 约 14.1 GB，在 16 GB 显卡上正好处于“宽裕”的边缘，在 24 GB 上则很宽裕。两者现已列入首页精选。两者的体积都是估算值：未能核对到文件大小，质量数据也未公布。RSS 订阅源也重新开始列出最新的模型：自 8 月以来，它一直显示同一批 20 个较早的模型。订阅源里的每条更新现在有简短标题，不再把整段文字当标题，并链接到更新日志页面。
2026-10-03格式页面不再说 AWQ 的 4-bit 精度最高。在本索引中同时提供两者的每个模型上，AWQ INT4 的文件更小，但质量损失比 GGUF Q4_K_M 更大 —— 页面现在照实这么写，也不再声称 AWQ 只能用于 NVIDIA。六维格式雷达图已移除：它的分数是手工填写的，不是实测，其中一项还与本索引自己的数据相矛盾。GPTQ 和 HQQ 的介绍现在只保留可以核实的说法。
2026-10-03Nginx 反向代理指南用了一个只有较新版本 Nginx 才认识的 HTTP/2 写法，Ubuntu 22.04 和 24.04 自带的 Nginx 加载这份配置会直接报错。现在改成了所有版本都能用的写法。指南还注明了每段配置该放在哪里，并更正了“llama.cpp 和 vLLM 没有 API 密钥”的说法：两者都能设置密钥，只是默认不要求；Ollama 则完全没有密钥选项。
2026-10-03“单卡 RTX 4090 运行 Qwen2.5-Coder 32B”指南现在给出每种上下文长度下的判定，而不只是 4K：GGUF 版本到 16K 就放不下，AWQ 版本 8K 以内宽裕、32K 放不下。需要在 24GB 显卡上做长上下文编程时，指南指向 Qwen3-Coder 30B-A3B —— 它的 AWQ 版本在 32K 下仍然宽裕。指南也不再称任何一个模型为“最佳”，因为本站不评测代码能力。
2026-10-03llama.cpp 的 VPS 指南一边让读者用物理核心数，一边又把所有 vCPU 都交给了服务端 —— 在很多套餐上，这些 vCPU 是超线程，反而会变慢。现在命令不再指定线程数，交给 llama.cpp 自己选物理核心。指南还给出了真实的内存数字（8K 上下文约 6.2 GB，32K 约 9.5 GB；该模型完整的上下文窗口放不进 16 GB），加了测速步骤，并删掉了本站无法核实的服务商价格和套餐名称。
2026-10-03“自己量化 GGUF”和“CPU 推理优化”两篇指南已对照 llama.cpp 当前的工具核对。llama-cli 现在是聊天程序，原来的一次性测试命令执行后会停在那里等你继续输入。量化指南现在加上了“回答一次就退出”的参数；CPU 指南改用 llama-bench 测速，它会把提示词处理和生成速度分开报告。量化指南还改成按 llama.cpp 官方示例用 BF16 转换，并用当前格式保存重要性矩阵。CPU 指南则注明了 llama.cpp 默认就会自动使用物理核心数。
2026-10-03两篇 vLLM 指南和命令生成器已对照 vLLM 当前的代码和文档核对。安装步骤现在会先建虚拟环境，因为没有虚拟环境时安装命令会直接中止。指南里还描述了一条现在的 vLLM 已经不再打印的警告：当在途请求的显存不够用时，vLLM 现在会在定期打印的状态行和监控指标里显示 "Preemptions" 计数，指南已说明去哪里看。另外注明了大多数 AWQ 版本所用的 AutoAWQ 工具已被弃用，但已有的 AWQ 模型仍可正常加载。
2026-10-03Docker + Ollama 指南现在除了 NVIDIA，也讲了 AMD 显卡。补上了原来漏掉的一步 —— 把 NVIDIA 运行时注册给 Docker，不做这一步容器就看不到 GPU。同时更正了一处速度说法：指南里当作 Ollama 实测引用的 218 tok/s，其实来自另一种运行时和格式。现在改为给出理论上限和 llama.cpp 的实测数字，并明确说明本站没有实测过容器与原生运行的对比。
2026-10-03Windows 版 Ollama 指南原先说 AMD 显卡只能用 CPU，这是错的：Ollama 的 Windows 应用能用 Radeon 显卡 —— RX 7600 到 7900 系列走 ROCm，RX 6000 等其他型号走默认开启的 Vulkan。指南现在把 AMD 和 NVIDIA 一起讲清楚，写明 Windows 10 22H2 就够用，并把在 Windows PowerShell 里会出错的 curl 示例换成了能直接运行的命令。
2026-10-03本站现在只有一个联系邮箱：zjy@quantized.uk，可直接联系到维护者。反馈、纠错或其他事情都请发到这里 —— 每一页的页脚和“关于”页面都有这个地址。
2026-10-03AMD ROCm 指南文末新增三个常见问答：Radeon 上该用 ROCm 还是 Vulkan；哪些 Radeon 能跑 AWQ 和 GPTQ 模型（以及没有一张能跑 EXL2）；24GB 的 RX 7900 XTX 比 16GB 显卡能多装下多少。同时更正了一处编译说明：旧的 LLAMA_HIPBLAS 开关并不是被静默忽略 —— CMake 会把它列为未使用变量 —— 但结果仍然是只能在 CPU 上运行的构建。
2026-10-03GPT-OSS 指南已对照 llama.cpp 官方的 gpt-oss 指南核对。现在指南说明了如何把一部分专家留在系统内存、让 20B 在 8GB 或 12GB 显卡上运行，给出了 llama.cpp 文档里设置推理强度的写法，补充了 OpenAI 推荐的采样参数（temperature 1.0、top_p 1.0、不用重复惩罚），并删掉了一条本站没有实测过的 120B 速度说法。文末新增三个常见问答。
2026-10-03GPT-OSS 的体积已更正。我们此前按"所有权重都是 MXFP4 的 4.25 bit"来估算 GPT-OSS 20B 和 120B，但实际上只有专家层是 —— 按 llama.cpp 官方指南，真实文件是 11.3 GiB 和 59 GiB。GPT-OSS 20B 在 4K 上下文下现在约需 12.8GB，而不是 11.7GB，因此不再算作能装进 12GB 显卡或 16GB 的 Mac，在 18GB 的 M3 Pro 上也属于偏紧。GPT-OSS 指南还在本站数字旁边列出了 llama.cpp 自己给出的、更高的总量。四篇印着旧数字的指南已更正；此后每次构建，网站都会把指南里印出的每个体积和计算器重新核对一遍。
2026-10-038GB 显卡入门指南按计算器重新核对了一遍。早先修正模型数据后，有三个数字发生了变化，其中一个结论也变了：Llama 3.1 8B 在 16K 上下文下是 7.3GB，占 8GB 显卡的 91% —— 偏紧，而不是从容运行。指南现在列出了两个能看图、仍然装得下的模型（Gemma 4 E4B 和 Qwen3-VL 8B），注明 AWQ 路线需要 Linux 或 WSL2（vLLM 不能直接在 Windows 上运行），反映了 llama.cpp 默认会自行决定放多少层到 GPU，并新增三个常见问答。
2026-10-03Mac M3 Pro 指南改正了一处错误说法：它说超出 Mac GPU 内存的模型会加载失败或触发换页。实际上 Ollama 会把它拆开，放不下的层跑在 CPU 上，状态里会显示 CPU/GPU 百分比 —— 这才是超限的真正信号。指南还新增了 M3 Pro 内存带宽决定的速度上限（4-bit 的 32B 约每秒 8 个 token，明确标注为上限而非实测），并新增三个问答。
2026-10-02EXL2 相关建议已更新到当前状态。EXL2 格式背后的运行时 ExLlamaV2 已经归档，TabbyAPI 和 text-generation-webui 改为加载更新的 EXL3 格式 —— 所以 EXL2 仍能在本机运行，但已经没有仍在维护的工具把它作为 API 提供。命令生成器的 ExLlamaV2 选项此前给出的服务端命令和 Docker 镜像根本不存在；现在给出的是这个库真实的本机聊天命令，并按模型选对聊天模板。TabbyAPI 指南按它现在的样子重写，格式向导不再为 API 场景推荐 EXL2，ExLlamaV2 指南也改用了 Llama 3 的正确模板。站内所有下载命令改用 hf 命令；旧的 huggingface-cli 已经从当前版本的 Hugging Face 工具中移除。
2026-10-02双卡 70B 指南现在反映了 llama.cpp 当前的行为：它的自动显存适配默认开启，会在每张卡上留出 1 GB，可能悄悄把 70B 的一部分挪到 CPU 上，所以指南改为显式指定 GPU 层数和上下文长度。指南还补充了两张不同显卡混用的情况、新的实验性切分模式，并新增三个问答。另外，我们此前一直说 llama.cpp 的旧编译开关名会被静默忽略，其实不是 —— 一个仍然有效、只是附带警告，另一个会让构建直接报错 —— 所有页面上的这条说法都已更正。命令生成器给出的 Docker 和 Compose 命令现在只把端口发布在本机（127.0.0.1）上，不再暴露到所有网卡；vLLM 和 Ollama 命令默认也不再监听整个网络。
2026-10-02WSL2 + Ollama 指南按微软、NVIDIA 和 Ollama 当前的文档重新核对了一遍。有两处说错了：在 WSL 默认的网络模式下，局域网根本访问不到这个服务（真正有暴露风险的是镜像模式）；示例里的状态输出少了一列。现在还补上了读者最常碰到的两个故障 —— "cuda" 包悄悄装上 Linux 驱动、把 GPU 透传弄坏，以及 systemd 没开导致 Ollama 根本没启动 —— 文末新增三个问答。
2026-10-02新增两个模型：Gemma 4 E2B 和 E4B，Google 面向端侧的两个尺寸，支持图像和音频输入，128K 上下文。它们大部分层复用前面层的缓存，所以长上下文很便宜：Q4 下 E2B 在 4K 时约 3.0 GB、用满窗口约 3.8 GB，E4B 约 4.9 GB 和 7.0 GB——8 GB 显卡或 8 GB 的 Mac 都能从容运行。格式向导给 AMD 的建议现在会写明 vLLM 支持哪些显卡。
2026-10-02AMD 显卡的推荐现在与每张 Radeon 卡的实际能力一致。AMD 上的 AWQ 和 GPTQ 构建靠 vLLM 运行，而 vLLM 支持的是 RX 7700 XT 及以上、RX 9000 系列和 Instinct MI200 及更新型号——所以 RX 6000 系列、RX 7600 XT 和 MI100 不再收到它们加载不了的 AWQ 推荐，「可从容运行」的数量最多减少 4 个。GPTQ 此前被我们误称为只能在 NVIDIA 上跑，现在会在受支持的 AMD 卡上提供。GPU 页面里「这张卡能跑……吗」的回答，也不再在模型其实有可用 GGUF 构建时说「格式跑不了」——现在会按那个 GGUF 构建计算大小。
2026-10-02命令生成器的 vLLM 输出现在覆盖 AMD 显卡，并与 vLLM 当前文档一致。AMD 用户会拿到 vLLM 官方的 ROCm Docker 镜像、文档列出的运行参数，以及 ROCm 版的安装命令；不在 vLLM 支持名单上的 Radeon 显卡（如 RX 6000 系列和 RX 7600 XT）会看到提示，建议改用 llama.cpp 或 Ollama。非 Docker 命令现在用 uv 安装、用 "vllm serve" 启动服务，与 vLLM 文档一致——此前它仍显示旧的安装方式和入口，和本站自己的 vLLM 指南相矛盾。
2026-10-02命令生成器的 Docker 和 Docker Compose 输出现在会跟随你选择的显卡。以前所有人拿到的都是 NVIDIA 的命令：AMD 显卡拿到的是它用不了的 CUDA 镜像；Ollama 的 Compose 文件里 GPU 配置还是被注释掉的，所以连 NVIDIA 用户也在不知情的情况下跑在 CPU 上。现在 NVIDIA 用户拿到 CUDA 镜像并透传 GPU，AMD 用户拿到 ROCm 镜像和 ROCm 所需的设备，Mac 用户会看到明确提示：Docker 用不了苹果 GPU，请直接在本机运行。每条命令下方的说明在中文站也已改为中文。
2026-10-02对照 llama.cpp 当前的构建文档重新核对了 AMD ROCm 指南。构建命令改为文档中的写法；指南注明需要 ROCm 6.1 或更新版本（更旧的版本会在构建时被拒绝）；关于 Windows 的说法也改为实际情况：文档里有 Windows 上的 HIP 构建方法，但针对未列入支持名单显卡的变通办法在 Windows 上无效。确认模型跑在 GPU 上的那行日志现在是 "load_tensors: offloaded …"——AMD 和双卡指南此前让你找的旧名称已经不会出现了。另外修正了命令生成器：它的 Docker 命令用的是纯 CPU 版本的 llama.cpp 镜像，却又要求使用 GPU，结果全程在 CPU 上运行且不报错。现在改用 CUDA 镜像。
2026-10-02新增六款热门 Mac，各有自己的页面，计算器里也能选择：M4 的 16 GB 和 24 GB 版本（Mac mini 基础款和常见的升级款）、M2 16 GB、M1 的 8 GB 和 16 GB 版本，以及 M1 Max 64 GB。和本站所有 Mac 一样，只按约四分之三的内存计为模型可用。苹果没有直接列出初代 M1 的内存带宽，所以它的页面给出的是由苹果官方对比推算的数字，并注明了这一点。8 GB M1 Mac 的指南现在直接使用 M1 自己的条目，不再借用 M3 的。
2026-10-02五张热门入门显卡现在有了自己的页面，计算器里也能选择：GeForce RTX 3060 12G、GeForce RTX 5050、Radeon RX 7600 XT，以及 Radeon RX 9060 XT 的 16 GB 和 8 GB 两个版本。显存容量和速率取自 NVIDIA、AMD 官方规格页。NVIDIA 官方页面没有给出 RTX 5050 的显存速率，所以它的页面只显示容量、不显示带宽，而不是填一个猜测的数字。
2026-10-01新增 Google 的 Gemma 4 26B-A4B 和 Gemma 4 31B，这是 Gemma 4 中能在单张 16–32 GB 显卡或一台 Mac 上运行的两个尺寸。两者都支持 256K 上下文，但每六层中只有一层的缓存随上下文增长，而且这些层用的是更少、更宽的注意力头——所以计算器现在对两种层分开计算。结果是：26B-A4B 在 Q4、32K 上下文下约需 17 GB，24 GB 显卡可以从容运行；31B 短上下文下约 21 GB，24 GB 显卡只能跑短上下文，32 GB 显卡才是从容的选择。更小的 E2B 和 E4B 在层与层之间共享缓存，计算器暂时还无法准确描述，所以暂未收录。
2026-09-30速度数字现在在所有出现的地方都注明来源。本站只实测过 10 个模型，其余模型的速度从未在本站跑过，但模型卡片、首页推荐、计算器列表和 GPU 页面把它们和实测数字显示得一模一样。现在每个未实测的速度都带"估算"标签。对比工具中，没有速度数据的模型此前按 0 计算，另一方就在这一行默认"胜出"，而且所有速度都被标为"已发布"；现在这一行标注"本站实测"或"未核实"，只有双方都是实测数字时才判定谁更快。模型卡片的上下文长度此前按千位显示（131K、1049K），与全站其他地方的 128K、1M 不一致，现已统一。
2026-09-30本站此前写"覆盖 63 张显卡"，其中 4 项其实是纯 CPU 的内存规格（16、32、64、128 GB），保留它们是为了让计算器能回答"没有显卡"的情况。现在凡是写"显卡"的地方都只统计 59 张显卡和 Mac，CPU 规格单独说明。Command R 35B 页面现在注明：体积按 8 个 KV 头计算，而 2024 年 3 月的原版缓存约为 8 倍（32K 下约 40 GB）——该条目对应的是哪个版本没有记录。
2026-09-30Llama 4 Scout 和 Maverick 每四层中有三层只在 8192 token 的分块内做注意力，llama.cpp 对这些层只保存一个分块大小的缓存。计算器此前把 48 层全部按完整上下文计算。现在 Scout 在 128K 上下文、Q4 下约需 77 GB，而不是约 95 GB；用满 1000 万 token 窗口时，缓存估算从约 1.9 TB 降到约 480 GB。索引中其他模型都已对照 llama.cpp 自己的滑动窗口架构清单核查过，没有受影响的。
2026-09-30把每个模型的层数和注意力头参数与公开配置逐一核对，修正了错误的条目。Gemma 2（2B、9B、27B）、Gemma 3（4B、12B、27B）和 GPT-OSS（20B、120B）这八个模型只有部分层保留完整缓存，其余层使用较短的滑动窗口，llama.cpp 只按窗口大小存储这部分缓存。计算器此前把所有层都按完整上下文计算，所以长上下文下的数字严重偏高：Gemma 3 27B 在 32K 下从约 34 GB 降到约 21 GB，现在能装进 24 GB 显卡；用满 128K 时从约 86 GB 降到约 29 GB。Qwen2.5 3B 的层数和头数有误（缓存高估约 1.6 倍），Phi-4-mini 的缓存低估了四分之一，Gemma 3 12B 的 head 维度有误，WizardLM-2 7B 此前被填成了另一个模型的规模和结构——它其实是基于 Mistral 7B 微调的。GPT-OSS、RTX 4060 Ti 和 Mac M3 Pro 三篇指南已同步更新。
2026-09-30删除了 47 个不可能是 RTX 4090 实际表现的"RTX 4090 tok/s"数字。其中 43 个属于超出该卡 24 GB 显存的版本（70B 模型 Q4 约 43 GB，却标着 38 tok/s）；另外 4 个是稠密模型，速度超过了该卡显存带宽所允许的上限。这些模型现在不显示速度，而不是显示一个不可能的数字；今后构建会直接拒绝这两类错误。模型页此前对所有模型都写"本站实测最快的档位"，实际上本站只实测过 10 个模型，其余页面现在注明速度为估算值。Jamba 1.5 Mini 此前按 12B 模型计算体积；它实际总参数 52B、激活 12B，Q4 约需 31 GB 而不是 8.5 GB，不再显示为能在 10–16 GB 显卡上运行。Mistral Large 3 与 DeepSeek 一样采用压缩注意力，但具体结构参数无法核实，页面现在注明长上下文下的缓存数字是上限。
2026-09-30修正了 DeepSeek-V3、DeepSeek-R1、DeepSeek-V2-Lite 和 DeepSeek-Coder-V2-Lite 的显存估算。四者都采用 MLA 注意力，当前的 llama.cpp 每层每个 token 只存一个压缩向量，但本站此前按常规注意力计算——对当前的 GGUF 文件偏高，对旧文件又严重偏低。现在的估算按当前文件计算：DeepSeek-V2-Lite 用满 16 万上下文所需显存从约 47 GB 降到约 15 GB，两个 Lite 模型现在都能在 10 GB 和 16 GB 级别的硬件上从容运行。由于差别很大（DeepSeek-V3 在 32K 下旧版转换的缓存约 150 GB），每个页面也写明了旧版转换的代价以及如何区分两者。
2026-09-30新增两个模型，激活参数都在 3B 左右，单卡或一台 Mac 就能跑：GLM-4.7-Flash（智谱，总参数 30B，128K 上下文——Q4 下 24 GB 显卡可以从容运行）和 Kimi Linear 48B-A3B（月之暗面，100 万上下文——Q4 下 48 GB 的 Mac 可以从容运行，32 GB 显卡只能勉强装下）。两者都使用压缩的注意力缓存，显存估算按 llama.cpp 实际的存储方式计算，而不是当作常规的 K 和 V。这一批未能核对到 GGUF 文件大小，所以体积使用计算器的通用比特率，并标为估算。同期的几个更大的发布（780B、744B 模型）超出单机硬件的范围，没有收录。
2026-09-30对照各项目自己的发布列表，重新核对了基准测试页上各运行时的当前版本：llama.cpp b11277、vLLM v0.30.0、Ollama v0.35.0（取最新的正式版，跳过了预发布版）。ExLlamaV2 仍停在 2025 年 7 月的 0.3.2；其维护者现在工作的 ExLlamaV3 已到 v1.5.3。基准测试数字本身没有重测，仍然对应当初测试时的旧软件栈。
2026-09-29每个工具页的面包屑现在是「首页 › 工具 › 当前工具」，从任一工具都能一键回到列出全部四个工具的页面——此前工具页内部没有任何地方链接回去。
2026-09-29有 31 个中文页面标题长到会在搜索结果里被截断——英文名较长的模型页、「按显存推荐」各页以及几个栏目页。这些标题都已缩短；仍会超长的标题，现在会先去掉网站名，而不是截掉自己的字。今后只要有标题超长或两个页面标题重复，构建就会失败。
2026-09-29网站现在每次构建都会自检。本月修掉的很多错误，要么是两个手写文件彼此走样——推荐里写了一个模型并不提供的量化档位、指南链接了一个已不存在的模型、一个过时模型指向的「继任者」本身也已过时——要么是页面悄悄超出了某个限制。这些情况现在都会让构建直接失败，并准确说明哪里出了错，而不是发布一个看起来正常、其实有问题的页面。今天读者看到的内容没有变化；这是为了让最近的修正保持修正。
2026-09-26显存计算器页面新增了一张按模型规模的速查表——4K 与 32K 上下文下的显存，以及能装下整个规模档位的最小显卡——这样即使不运行 JavaScript（交互式计算器需要它），也能直接读到答案。表中每个数字都是计算器自己的算法。32K 一列只统计上下文窗口真正达到 32K 的模型；其中 Phi-3.5 Mini 在 32K 下约需 15.6 GB，因为它为每个注意力头都保留完整的缓存——这是模型本身的特性，不是计算错误。
2026-09-26搜索结果里的页面摘要，现在都控制在结果页能完整显示的长度内。此前有 92 个英文页面和十几个中文页面的摘要长到会被从句子中间截断——所有显卡页都在其中——另有几个模型页正好相反，只有一句很短的话。过长的摘要现在会在限度内保留完整句子，或已改写得更短；过短的模型摘要会补上一句计算出的显存体积。顺带发现两处错误：一个显卡页的摘要把一个已标为过时的模型说成是「能装下的最大模型」；AWQ 格式被描述成只支持 NVIDIA，而本站自己的说明和装载计算都允许它通过 vLLM 在 AMD 上运行。
2026-09-26每篇指南现在都会显示发布日期，以及（如果之后有改动）最近更新日期——这些日期此前只写在页面的搜索元数据里，读者看不到。站点地图现在也会报告指南真实的最近改动时间：它此前忽略内容更新，导致本月重写的十七篇指南对搜索引擎声称自己自 2025 年发布以来从未改动。
2026-09-26/formats/ 页上的「格式热度指数」不再显示百分比，格式对比页也去掉了「采用率估算」这一行。那些数字（GGUF 89%、AWQ 45% 等）是编辑判断，没有任何人能复核的来源；在对比页上，它们就摆在「本索引中有多少模型提供该格式」这个真实计数旁边，看起来像是同一类事实。排序保留，并注明是判断；实测的部分是每种格式的模型数。
2026-09-26首页「编辑推荐」里每一项旁边的体积和显卡，现在和模型页一样由计算得出，不再是手写的文字。手写版本已经走样：Magistral Small 1.2 标的是一张只能勉强装下它的 16 GB 显卡，Seed-OSS 36B 标的是两张 RTX 3090，其实一张 32 GB 显卡就能装下，还有好几张写到的显卡根本不在本站的显卡列表里。现在每一项都显示 4K 上下文下的体积，以及能从容运行它的最小显卡。
2026-09-26每张卡「能跑多少模型」的数字，现在都写明了统计口径。本站对一张卡给出两个数字——能从容运行的模型数（占用不超过显存的 88%）和勉强能加载的模型数——显卡页会同时显示两者，但首页的显卡列表只写了「52 个模型可跑」，显卡索引页只写了「52/81」，读起来像是更宽松的那个数。两处现在都标明「可从容运行」。这些数字本身在全站早已一致，缺的只是标注。
2026-09-26速度数字现在会写明来自哪张卡。本索引里每个模型的速度都是在 RTX 4090 上报告的，但每个显卡页的模型表格里，这一列的表头只写了「tok/s」——于是 RTX 4060 的页面、Mac 的页面，都把 RTX 4090 的速度当成了这张卡自己的速度来展示。现在这一列标为「RTX 4090 上的 tok/s」，除 4090 之外的每个显卡页都会说明这一列只是参考、不是这张卡的速度，计算器里按显卡列出的结果也同样标注。真正在某张卡上实测的速度，仍然列在「在这张卡上的实测数据」里。
2026-09-26模型页现在按模型的发布形态来估算显存。GPT-OSS 20B 和 120B 原生以 MXFP4 发布，但页面介绍的是这个版本，估算却全部按 Q4_K_M ——一个会损失精度的社区二次量化——来算，于是介绍、表格和「能跑在哪些卡上」三处给出的数字对不上。每个模型页上「最小显卡」那句话也有误导：当多张卡同为能跑的最小容量时，它直接报出数据库里排在最前的那张（一个任何 16 GB 卡都能跑的模型，写的却是 RTX 5080）；现在改为写明容量、这个容量有几张卡、以及其中的入门型号。它也不会再把系统内存那一行当成显卡——此前 4 个 70B 级模型的页面上，本该是显卡的位置写着「64 GB RAM (CPU)」。「差一点」现在列出的是差得最少的卡，而不是差 5.4 GB 的 8 GB Mac；「MoE 模型所有专家都得驻留显存」的提示，现在出现在全部 13 个 MoE 模型上，而不是只有 4 个。
2026-09-23中文页面：页脚的「Navigate」「Ecosystem」两个标题此前在每个页面上都还是英文；每篇中文教程末尾「接着看」里的教程链接，显示的也是目标教程的英文标题——而每篇教程其实都有中文标题。两处都已修复，顺带修了计算器里的两个标签（「Batch Size」，以及「Full」精度选项，现为「全精度」）。
2026-09-23首页原来叫「本周更新」的那一块，现在改叫「最近收录」：列出索引里最新加入的 6 个模型，按收录日期从新到旧排，每个都标了收录日期。它原先只显示 45 天窗口内的模型，而且按文件顺序而不是日期排，已经只剩两个，再过几周就会变空，标题却还写着「本周」。模型卡片上的「新」标记，现在从最近一次数据更新往前算 45 天，而不是从你打开页面那一刻算——这样卡片标记、首页和 Hub 的「最近新增」筛选始终一致，页面也不会出现 HTML 里是一组标记、浏览器接管后又变成另一组的情况。
2026-09-21又有两个较老的模型标注了更新的替代选择：Mixtral 8x7B Instruct → Qwen3 30B-A3B（上下文更长，Q4 下约 19 GB 而不是 28.5 GB，速度也更快）；Stable LM 2 12B Chat → Falcon 3 10B Instruct（上下文 32K 而不是 4K，更小也更快）。它们的页面和全部数据都保留，只是不再被优先推荐。DeepSeek-V2-Lite Chat 也考虑过，但没有标注：同体量里没有别的模型能比得上它 16 万的上下文和 11 GB 的占用。
2026-09-21推荐现在会检查你的硬件能不能运行某个格式，Mac 也按 macOS 实际允许 GPU 使用的内存来计算。此前 Mac、纯 CPU 或 AMD 的页面可能推荐 AWQ、GPTQ 或 EXL2 版本，而这些系统根本加载不了（AMD 仍可使用 AWQ，因为 vLLM 在 ROCm 上支持它）。Mac 的统一内存此前也是按全部容量计算的；macOS 默认只让 GPU 使用约 75%，现在按这个比例计算。修正覆盖 GPU 页、/best/、FAQ、格式页和显存计算器；计算器在格式不被支持时会直接说明。16 GB 的 Mac M3 上，能从容运行的模型从 52 个变为 81 个中的 44 个。
2026-09-21一批小修正：首页有两处推荐写了一张并不存在的显卡（"RTX 4070 Ti 16G"——16 GB 的型号是 Ti Super）；关于页还写着"79+ 个模型"；页脚里 llama.cpp 和 ExLlamaV2 的链接还指向这两个项目旧的 GitHub 组织。联系邮箱现在做了标记，让 Cloudflare 的邮箱保护不再改写它——这很可能是偶发页面报错的原因，但尚未在线上确认。
2026-09-15首页现在直接回答大多数访客带着来的问题——"这张显卡，到底能跑多大模型？"——主按钮改为通往按显卡分类的页面（"看我的显卡能跑什么"），不再是完整的模型列表，并为第一次来的读者加了 8 GB 显卡入门指南的链接。基准测试页上的运行时版本已更新（llama.cpp b10978、Ollama v0.34.1；vLLM v0.29.0 不变）。ExLlamaV2 自 2025 年 7 月以来没有新版本，维护者已转向 ExLlamaV3，它使用新的 EXL3 格式。基准测试页注明了这一点；目前本站没有模型提供 EXL3，所以暂不列为格式。
2026-09-14对照中文读者实际会搜的问题检查了一遍中文站。有一个常见问题没有答案——32 GB 内存纯 CPU 跑大模型现实吗——现在 FAQ 用索引里的"32 GB 内存"条目回答了它：能装下哪些模型是确定的，速度则不确定，因为取决于你的内存配置。新增两张热门二手卡，规格取自 NVIDIA 官方：Tesla P40 24G 和 Tesla P100 16G。改装版"2080 Ti 22G"没有收录，因为它没有官方规格。
2026-09-14GPU、模型、指南、/best/ 和格式页面现在各有自己的分享图片，不再全站共用一张通用图。顺带修正了一个问题：从任何页面（包括首页）分享到 Twitter/X 的链接，此前显示的都是网站的通用标语，而不是该页面自己的标题和简介。
2026-09-14排查了"移动端首页滚动卡住"的反馈。问题无法复现：在干净的移动端浏览器里，滚动和页内跳转都能正常到达页面底部，说明问题更可能出在反馈所用的预览工具，而不是网站本身。尚未在真实的 iPhone 或 Android 手机上确认。
2026-09-14基准测试页现在说明了自己的覆盖范围：61 张卡中的 4 张，共 16 次运行。新增的板块列出了实测过哪些卡、其余 57 张依赖什么（计算器的公式），以及本站从未测过的内容——双 3090 指南之外的多卡、大于 1 的 batch、提示词处理速度。方法说明现在默认展开，从未记录过的内容（测量工具、机器配置、日期）都标为"未记录"。页面简介也不再提及早先已删除的 RTX 4060 Ti 数据。
2026-09-14网站的结构化数据现在说明了 quantized.uk 涵盖的内容（GGUF、AWQ、EXL2、GPTQ 以及加载它们的运行时）、联系方式和创建时间。它刻意不写创始人，也不链接任何社交账号：本站由一位不具名的维护者运营，没有公开账号，也不会编造。
2026-09-13"页面不存在"页现在能帮你找到方向：显示出错的地址，推荐最接近的真实模型、显卡或指南（/quant-hub/qwen3-8/ 会推荐 Qwen3 8B Instruct），提供搜索框，并列出各板块入口和当前数量。它返回真正的 404 状态码，中文地址会显示中文版。
2026-09-1312 个较老的模型（Zephyr 7B Beta、WizardLM-2 7B、OpenChat 3.6 8B、Aya 23 8B、SOLAR 10.7B、InternLM2 两个尺寸、DBRX Instruct、Jamba 1.5 Mini、StarCoder2 15B、Command R 35B、Yi 1.5 34B）现在会注明建议改用哪个当前模型及原因——上下文更长、量化选择更多，或者仍有人在维护新版本——并可一键对比。模型库默认隐藏这 13 个旧模型，打开开关即可显示，它们的页面也都保留。顺带修正：首页和 /best/ 此前会推荐旧模型——Qwen2-VL-7B 几乎在每张显卡上都占着多模态推荐位。
2026-09-13站点地图现在会告诉搜索引擎每个页面真正更新的时间——模型页用收录日期，指南用各自的日期——而不是给所有页面都打上最近一次构建的日期。robots.txt 现在明确欢迎各家 AI 搜索爬虫（OpenAI、Anthropic、Perplexity、Google、Apple），并指向 /llms.txt；可分享的筛选链接仍然允许抓取。
2026-09-12整理了页面标题：有 63 个长到会在搜索结果里被截断，主要是带着多余后缀的模型页和指南。现在全部控制在长度内，没有重复，也没有用"…"截断。关于页的标题现在也说明了这一页是做什么的。
2026-09-12本站唯一的回访机制是一个反馈用的 mailto 链接，而这是一个每隔几周就有新数据的站点。Footer 现在在每一页都新增了「保持关注」一栏，指向 /feed.xml 与 /changelog/，并各自说明是什么（不收邮箱、不追踪）；模型页与 GPU 页在页尾加了一行提醒——本页数字会随数据变化——旁边就是 RSS 链接。真正的问题在底层：四个模板——两个动态模型页路由及其 /zh 镜像——是手写 <head> 元数据的，从未包含 RSS 自动发现标签，导致站上访问量最大的约 200 个页面里，有一个能用的订阅源却没有任何方式能被发现，除非读者记得完整网址。/feed.xml 本身已经在 changelog 与模型两类条目里带着真实的 pubDate/guid/link/description——这是核实过的，不是想当然。没有做邮件订阅：站点的隐私立场（不追踪、不建账号）写在 /privacy/ 与 /about/ 里，对这批读者而言邮件列表会与之矛盾，而 RSS 已经够用
2026-09-12最后七篇单薄的指南已重写，至此整个 cookbook 完工：现在全部 23 篇正文都在 1,464 到 1,824 词之间，没有一篇还挂着编造的「1 分钟阅读」，也没有一篇带着并未赚到的验证日期。核对而不是凭记忆写作，这次揪出的是实质内容问题，不只是篇幅问题：此前 OpenBLAS 被当作能提升 CPU 速度的东西来讲，而 llama.cpp 自己的构建文档写明它只在批大小超过 32 的提示词处理阶段有用，对生成速度毫无帮助——旧版本里那些「某低价 VPS 能跑多少 tok/s」的数字是编的，已经删掉。一个 32B 编程模型被说成能从容装进 24GB 显卡，用的量化档位在本站自己的计算器里其实占了显卡的 90%——是「勉强」，不是「从容」——现在两种构建给出的是诚实的对比。8GB 的 Mac 指南则直说本索引没有 M1 或 M2 基础版芯片的条目，并说明具体用什么代替、这种替代在哪里会高估真实速度
2026-09-12五篇服务端指南已重写，其中两篇教的命令已经不存在了。两篇 vLLM 指南仍在用 'python -m vllm.entrypoints.openai.api_server'，安装也还钉在 CUDA 12.1 的 wheel 源上；现在官方文档的形式是 'vllm serve'，安装用 uv 并根据你的驱动自动选择 torch 构建。ExLlamaV2 的仓库已经换了组织名。而 TabbyAPI 自己的 README 写明它是一个业余项目、不适合跑在生产服务器上 —— 这句话现在放在该指南的开头，因为维护者自己的判断比本站能补充的任何话都更有分量。还揪出一个编造的数字：一处「batch 8 时约 1400 tok/s」的说法，本站从未测过。现在这些指南引用的是本索引真正持有的实测记录 —— 4090 上 ExLlamaV2 的 235 tok/s、同一张卡上 vLLM 的 218 tok/s —— 并且直说批量吞吐不是本站测过的东西
2026-09-12五篇单薄的指南已重写，这是三批中的第一批。23 篇指南里有 17 篇正文不足 365 词，标题却承诺了完整教程 —— 其中一篇叫《Windows 上用 CUDA 编译 llama.cpp》的正文只有 18 个词。入门意图最广的这五篇现在采用了此前六篇重写稿建立的结构：开始之前要准备什么、具体步骤、如何确认模型真的跑在 GPU 上而不是静默回落到 CPU、在该硬件上数字大概该是什么样，以及出问题时怎么办。每篇都带三个问题，页面上和结构化数据里都有。所有显存数字都取自计算器对该模型自身数据行的计算，命令则对照各项目当前的官方文档核对过 —— 这是文档核对，不是实机运行，所以这 17 篇从七月起一直挂着的、并未真正赚到的「已验证」日期是被移除，而不是被刷新
2026-09-11本站四个板块现在互相链接了。先做了测量：站内链接几乎全部走页头和页脚 —— 十四个枢纽地址出现在每一个页面上，而四个格式页各自只有一条入站链接，八个硬件页不足三条，模型页指向相似模型和指南，却从不指向格式、显卡或推荐。现在模型页会说明这个模型能跑在哪 —— 能从容装下它的最便宜的几张卡、差一点装不下的是哪几张以及差多少、它提供哪些格式 —— 指南页则会说明自己用到了什么：硬件、模型、所用运行时对应的格式，以及接着该读什么。所有关系都由站点已有的数据算出，因此不会随时间失效。现在没有任何一个内容页的入站链接少于三条，格式页则从一条入站链接提升到中位数 25 条
2026-09-11本站终于开始回答「我该跑哪个」，而不只是「哪些装得下」。显卡页给你一份清单，Hub 给你另一份清单，但搜「16G 显卡最好的模型」的人要的不是清单，是一个推荐。现在有七个页面，从 8G 到 32G 每个显存档位一个，外加 Apple 芯片，各自给出通用、写代码、图像三种用途下该跑的模型，附显存占用、剩余余量和已公开的质量损失。这些推荐全部由索引算出，用的是首页 hero 背后的同一个函数 —— 所以档位页和首页不可能对同一张卡给出不同推荐，而新增一个模型会让七个页面同时更新，无需改动任何一行文案。每页还会点名**装不下**的那个最接近的模型以及差多少，因为「边界在哪」正是清单从来不会告诉你的那一半
2026-09-11模型搜索框现在是真正的搜索框了。全站每个页面都声明了 /quant-hub/?q=… 这个搜索接口，而这个网址确实能正确筛选 —— 但产生它的那个控件是一个没有 name、也没有表单包裹的输入框，所以没有 JavaScript 就无法提交，读取页面代码的程序也发现不了这个接口。现在它是一个规范的搜索表单，按下回车就会得到站点一直在对外声明的那个网址。搜索也不再在最常见的词上失灵：此前输入「coding」「vision」「gguf」「7b」都是零结果，因为搜索只看模型名 —— 现在它覆盖参数量、用途、硬件和格式，也知道人们打的是「coding」而数据里写的是「code」。搜索无结果时会给出四个来自索引、点了一定有结果的建议，而不是一片空白；带筛选参数的网址会声明不要被收录但仍可被抓取，这样一条可分享的筛选链接不会变成成千上万个近乎重复的页面
2026-09-11现在有了常见问题页，而且每个答案都是算出来的，不是写出来的。「7B 要多少显存」这个问题，本站一直有计算器，却没有答案 —— 现在围绕体积与显存、量化掉点、格式与运行时、硬件、数据来源五个主题的 24 个问题，全部由同一份索引作答，每条末尾都带一个可以自己核对的站内链接。因为是算出来的，它们不会像当初的指南那样与计算器脱节：改动一行模型数据，依赖它的答案就会跟着变。有三个索引确实回答不了的问题 —— 量化对写代码的影响是否更大、官方 QAT 是否优于社区量化、以及只公布了单一档位数据的模型上 Q5 比 Q4 值不值 —— 页面会直说，而不是猜一个
2026-09-11本索引收录的每种格式现在都有了自己的页面。「AWQ 是什么」此前在一个以量化命名的站点上无处可落 —— 有格式之间的两两对比，却没有一个页面单纯讲清楚一种格式，而提供 AWQ 的 53 个模型也没有共同的归属页。GGUF、AWQ、EXL2、GPTQ 现在各有：这个格式是什么、哪些运行时能读它、一个真实模型在 4K 下要多少显存、本索引实际收录了哪些量化档位及其公开损失中位数，以及提供该格式的全部模型 —— 从格式指向模型的新增内链共 159 条。MXFP4 放在 GGUF 页面里讲，而没有被单列为第五种格式，因为它本来就是这样：GPT-OSS 的原生 4-bit 权重是以 GGUF 文件分发的，不是另一种容器
2026-09-11两个无从比起的对比页已经下线。「AWQ vs GPTQ」与「EXL2 vs GPTQ」的交集恰好为零 —— 本站 81 个模型中没有任何一个同时提供这两种格式 —— 所以这两个页面连一行「同一份权重的两种格式」都摆不出来，只能用约 650 词把两段说明并排放着。现在，没有共同模型的格式组合根本不会生成页面；这个问题改由 GGUF vs GPTQ 页面回答，它直白地说明了没有人会为同一个模型在 GPTQ 与 AWQ 之间做选择，以及该用什么替代。旧网址会永久重定向到那里，而不是变成 404
2026-09-11硬件页现在真的在讲硬件。此前 61 个页面只是换了名字的同一个页面 —— 因为能装下什么完全由显存决定，每张 16 GB 的卡返回的清单一模一样。现在每页开头都会给出该卡的显存带宽、能装下的最大模型、一个留有余量的选择，以及一个由规格推算出的速度上限：生成一个 token 就要把每个权重读一遍，所以 8B 的 Q4_K_M 在 288 GB/s 的 RTX 4060 Ti 上约 62 tok/s 封顶，在 736 GB/s 的 RTX 4080 Super 上约 159 —— 同样 16 GB、同样的模型，却是两台很不一样的机器。这个上限是公开数字的算术结果，不是跑分，页面上也如实说明。做这个算术的同时还发现本站自己有三条基准数据，其速度是所标显卡在物理上达不到的；这些行已被删除，而不是调整数值
2026-09-11格式页终于有内容了。此前它只有 65 词 —— 一个以量化命名的站点上最单薄的页面，却是六个格式对比页唯一的入口。现在页面开头是一张由索引统计出来的表：81 个模型中有多少个提供该格式、4-bit 档位已公布困惑度损失的中位数及其样本量，以及本索引实际收录的量化档位。HQQ 在表中显示为 0 / 81，并附有说明 —— 它作为参考资料收录，Hub 里找不到它。没有公开困惑度数据的格式显示为短横线，而不是估算值
2026-09-11模型页现在会自己讲清楚。此前 81 个页面几乎只有表格 —— 约 220 词，人扫一眼看不出「我的卡跑不跑得动」，AI 助手也无从引用。现在每页都有三段简短说明和三个由该模型自身数字回答的问题：4K 下要多少显存、上下文变长会多花多少、该下载哪个版本。这些文字全部由数据生成，因此不会与数据脱节 —— 混合注意力的模型得到的文案与常规模型明显不同。部署指南也开始声明最近一次修改时间，以及它们实际讲的是哪些模型和硬件
2026-09-11硬件数据库更新到当代。Blackwell（RTX 5090 到 5060）、RDNA 4（RX 9070 XT 与 9070），以及 M4、M5 系列 Mac（含 256GB 与 512GB 的 Mac Studio 配置）现在都有了独立页面，共 18 张卡。在今天之前，站内最新的 NVIDIA 消费级显卡还是 2022 年的 RTX 4090 —— 而「RTX 5090 能跑什么」恰恰是本站存在的理由。这些卡都没有在本站实测过，每个页面都会如实说明，而不是让估算值看起来像实测值
2026-09-11可发现性与标签诚实度。每个硬件页面的描述现在会写明具体显卡和它能跑的最大模型 —— 此前 43 个页面中有 36 个只共用九条描述，因为模板里只有显存大小这一个变量。工具索引与数据更新日志从 404 变成了真实页面，导航里终于有了 43 个硬件页和格式对比的入口，首页也不再把同一条更新印三遍。模型数量改为从索引实时计算，而不是在六个地方手写；NEW 徽章旁的日期现在标注为「收录」—— 那是本索引收录它的时间，不是模型的发布时间
2026-09-11计算器现在知道 2026 年的模型并非都用同一种方式缓存注意力，首批两个模型也已入库。Qwen3.8 27B 的 64 层里只有 16 层是全注意力、其余保留固定大小的循环状态，旧算法把它的 KV 缓存高估了四倍 —— 在 32K 上下文下算出 8GB，而实测是 2GB。现在按模型真实的注意力结构计算，并与 8K、32K、262K 三个公开实测值吻合。同批加入的还有 Ministral 3 8B，其体积来自 Mistral 官方发布的 GGUF。凡是没有人公布过逐档质量损失的，该列现在显示一个破折号，而不是一个数字
2026-09-11修掉两处抓取层面的缺陷。凡是名字里带版本号的模型 —— llama-3.1-8b、qwen2.5-7b、phi-3.5-mini —— 指向它们的站内链接都会丢掉尾部斜杠并触发跳转：涉及 46 个 URL、2,101 条链接，其中 27 个模型页在自己的规范地址上没有任何直接内链。另外语言切换器是按钮而不是链接，导致 164 个中文页面在全站没有任何可抓取的入口。两处现在都由构建检查把关，不会再悄悄回退
2026-09-08搜索与反馈的基础工作。硬件页面现在会说明这张卡是否有真实实测记录（43 张里有 4 张），并列出显存预算相同的其他显卡 —— 因为能跑哪些模型由显存决定，否则这些页面彼此几乎是副本。结构化数据此前在只列出 30 个模型的页面上声称有 73 个；现在全部 329 个页面都与页面实际内容一致。另外，指南和命令生成器会问你「它真的跑起来了吗」：复制命令不等于它能用；而勘误邮件在打开你的邮件应用之前，会先把要发送的原文完整展示给你
2026-09-08两处修复，来自实际跑验证矩阵而不是读代码。在显存计算器里切换模型时会保留上一个模型的量化档位 —— 选中 Llama 3.1 8B 的 EXL2 再切到 GPT-OSS 20B，它会一本正经地给出一个并不存在的文件的体积；现在档位会自动切到该模型确实提供的一档，而索引中没有对应构建的档位会被标注为「仅为通用表估算」。另外计算器在正向模式下会把显卡从自己的地址栏里删掉，导致分享出去的链接丢失了这个结论所针对的硬件
2026-09-08教程与可读性。8GB 入门指南的显存数字比本站计算器高出约 2GB，还告诉读者 14B「需要 36GB 以上」（实际 11GB）—— 该指南连同 Mac 与双卡指南已按索引重写，补上前置条件、如何确认模型真的跑在 GPU 上，以及装不下时该怎么办。阅读时长改为从正文推算而不再手写（23 篇里有 22 篇是虚构的）；最近修改后未重新实机运行的指南改为标注「面向的技术栈」，不再声称验证日期；站内所有文字颜色现已达到 WCAG AA 对比度下限 —— 实测 3,175 个文本节点，无一不达标。图表在静态 HTML 中附带同数据的表格，筛选按钮会播报是否选中，上下文长度会标出精确 token 数
2026-09-08首页现在从你的硬件开始。选好显卡和用途，它会给出装得下的最大模型、留有余量的一个，以及实测最快的一个 —— 每个都附显存算法和进入计算器的链接。下方是常见显卡、真机基准的样本行，以及反馈数字错误的入口；格式热度与雷达图移到了格式页，完整更新日志仍在本页，默认折叠
2026-09-08工具之间现在会记住你的选择。在显存计算器里选好模型再去命令生成器，不必重新输入一遍 —— 模型、量化档位与上下文长度会带过去，而分享链接始终优先于你本地保存的配置。计算器还能直接跳到当前配置对应的命令；当模型装不进你的显卡时，它会说明该改什么、以及改完是多少
2026-09-08数字现在会交代自己的来源。对比工具此前有一行 "Q4_K_M 显存" 在切换上下文时纹丝不动，而旁边的说明却声称它会随之变化 —— 现在拆成会跟随控件的预估行和固定的已发布行，各自标注。6:1 "8B 胜出" 的比分已移除：它把内存算了两次、把本站收录了多少变体也算进去，还把参数更少当成优势
2026-09-08模型卡片不再拼接不同配置。统计行此前把某个档位的最低显存与另一个档位的最快速度并排展示，仿佛两者可以同时获得；现在统一为一套具名配置（Q4_K_M · RTX 4090 · batch 1）。显卡快捷筛选与硬件页的计数仍然不同 —— 4060 Ti 16G 上是 60 与 51 —— 但两者现在共用同一个函数，且各自说明了所用规则
2026-09-08生成命令的修正：本机 llama.cpp 服务改为绑定 127.0.0.1，不再把未鉴权的端点暴露在所有网卡上；下载步骤会先安装它所需的 CLI；此前"vLLM 仅支持 CUDA"的说法是错的 —— 它提供官方 ROCm 构建。中文首页的编辑推荐不再夹带英文，其 RSS 链接也指向页面头部早已声明的中文订阅源
2026-09-01新增：格式对比页。GGUF 与 AWQ、GGUF 与 EXL2 等六组，对比硬件支持、运行时与采用率，并列出同时发布两种格式权重的模型 —— 此时两行描述的是同一个模型，对比不再只是编辑判断。若没有模型同时提供两种格式，页面会如实说明，而不是含糊带过
2026-09-01计算器改为给结论，而不是罗列。硬件面板此前平铺 43 根柱子且大多为绿色 —— 占了大量篇幅却几乎没有回答问题。现在它先给出你真正想要的事实（"43 张卡中 16 张可从容运行 —— 最小的是 Instinct MI100 32G"），如果你设置了自己的显卡还会单独给出裁决，完整列表则收在一次点击之后。三个工具里 79 项的模型下拉也改为按尺寸分组，不再按录入顺序排列
2026-09-01新增：每张显卡一个页面。数据库中全部 43 张卡都已覆盖 —— "RTX 4060 Ti 16G 能跑哪些大模型？"给出 79 个索引模型中的 51 个，各自取 4K 上下文下仍留有余量的最佳量化档位，并按尺寸分组。这些数据一直都在，只是此前仅作为筛选参数存在，从未成为页面。中英合计新增 88 个页面
2026-09-01四个工具页现在会自我说明。此前每页只有一个标题、没有任何正文 —— 一个孤立的交互控件，读者无从校准。现在它们分别说明显存估算如何得出、为何上下文长度主导结果、CLI 命令里的标识符从哪来、以及为什么有些命令是占位符，并各配一组常见问题，中英双语
2026-09-01推理速度图恢复可读：18 根柱子里有 13 根标签都是 "RTX 4090"，屏幕上没有任何信息表明每根对应哪个模型。现在每根柱子都标注模型与硬件，并新增图例说明颜色含义（颜色一直代表推理框架，但此前从未说明）。手机端点击目标达到 44px 下限
2026-09-01首页的质量数字现在会说明自己描述的是哪一档：Q4_K_M 下保留 97.1%，取全部 79 个模型的中位数，并在旁标注 1.4–5.2% 的区间。旧的"98.4% 平均精度"是对每个模型各自最好的那一档求平均，因此往数据里补一个档位就会让它变动。中文版基准表格也已完整翻译 —— 此前备注列整列是英文
2026-09-01模型索引进入 HTML。此前 /quant-hub/ 完全由浏览器渲染，静态页面里没有任何标题、也没有 79 个模型名 —— 全站最核心的页面对搜索引擎和无 JavaScript 环境等于空白。现在 79 张卡片直接写入 HTML，筛选在其之上叠加
2026-09-01显存计算器不再回答你没问的问题：此前未选模型时会回落到通用 7B，给出 4.98 GB 并对全部 43 张显卡打绿灯。中文读者现在有独立的 /zh/feed.xml 订阅源，每个页面都声明了自己的 feed，/rss.xml 也不再 404
2026-09-01首页无需等待 JavaScript 即可绘制：此前标题以 opacity:0 发出，要等 bundle 加载后才可见，导致预渲染站点的真实用户 LCP P75 达 3.1 秒。入场动画改为纯 CSS，framer-motion 已移除 —— 首屏 JavaScript 减少 33 kB
2026-08-23格式相关的展示与索引对齐：首页徽章、"格式追踪"统计与 Hub 筛选均改为从实际有模型的格式推导（4 种）。HQQ 仍保留在格式科普中作为参考，但不再引导到没有结果的浏览路径
2026-08-23格式向导：量化档位改为按格式区分 —— 此前选择"最易上手"会给出 EXL2 · Q4_K_M、AWQ · Q4_K_M 这类两种格式里都不存在的档位。框架推荐也改为跟随格式，AMD 读者不会再看到 EXL2 配 ROCm 运行时，却在旁边读到"EXL2 无法在 ROCm 上运行"
2026-08-23首页排版：统计条自 job path 卡片引入后就一直盖在卡片上，遮住全部三行说明；Hero 在手机上被裁切，显存计算器按钮与格式徽章有一部分点不到。导航栏在平板宽度下不再溢出
2026-08-20CLI 生成器现在给出真能跑的命令：用真实 GGUF 仓库与文件名替代占位符，Ollama 改用 `ollama run hf.co/…`（原先生成的 tag 会 404），vLLM 传仓库 id 而非模型展示名。llama.cpp 编译参数改为 GGML_* 新命名（旧的 LLAMA_* 会被忽略，静默编出纯 CPU 版本）
2026-08-20显存计算器：正向模式改用模型自身实测 bpw，而非通用档位表（反向模式一直如此）。GPT-OSS 20B 的 Q8_0 此前被高估 67%（21.1GB → 12.7GB）。EXL2 3.5bpw 档位恢复可选
2026-08-18中文站修正：/zh 页面的 HTML 现在自身声明 zh-Hans；/zh/cookbook 上 23 个指南链接不再把读者弹回英文站；102 个中文页面的结构化数据改为描述中文页本身
2026-08-18中文站现已可被索引：/zh/** 镜像全部 113 个页面并配对 hreflang，中文文本直接写入静态 HTML，而非加载后再替换
2026-08-08模型索引 +4 → 79：Qwen3-VL 8B / 30B-A3B、Magistral Small 1.2、Seed-OSS 36B —— 面向受限硬件挑选（12GB 卡上的多模态、适合统一内存的小激活 MoE、双卡尺寸的 512K 上下文）。Qwen2-VL 7B 标记为过时
2026-08-08新增 Cookbook：本地运行 GPT-OSS 20B/120B 且不重新量化（共 23 篇）。显存计算器新增 MXFP4 档 —— 此前给 GPT-OSS 选 Q4_K_M 会把权重高估约 14%
2026-08-07模型索引 +4 → 75：GPT-OSS 20B/120B（原生 MXFP4）、GLM-4.5-Air 106B-A12B、Devstral Small 1.1 —— 面向 16GB 显卡与统一内存 Mac 的 MoE 批次
2026-07-22打磨：重渲 og.png（71+ 模型文案），全部 22 篇 Cookbook 已加验证技术栈条
2026-07-22保鲜组合：+4 模型（Gemma 3 27B、R1-Llama-8B、Phi-4、Qwen3 1.7B）、过时标注、实测/估算、Hub「最近新增」、本周更新、RSS、Cookbook 验证栈（共 71 个）
2026-06-26面向真实访问：任务入口、移动端 GPU 档案、OG/图标、格式热度诚实标注、反馈邮箱
2026-06-26模型库 +4：Qwen3 4B、Qwen3-Coder 30B-A3B、Mistral Large 3、GLM-4-9B（共 67 个）
2026-06-26QA 修复：HF 统计合并、≤3B 筛选、CLI/VRAM 工具 bug、i18n 优化
2026-06-26模型库 +5：Qwen3 32B、30B-A3B MoE、235B-A22B、DeepSeek-V3、DeepSeek-R1（共 63 个）
2026-06-26模型库 +7：Qwen3 8B/14B、Gemma 3 4B/12B、Llama 4 Scout/Maverick、Llama 3.1 405B（共 58 个）
2026-06-25Cookbook 目录滚动高亮、代码块一键复制、Quant Hub Markdown 导出
2026-06-25Cookbook 阅读进度条、模型 HF 链接复制、Quant Hub 可分享筛选 URL
2026-06-25面包屑导航 + JSON-LD、Cookbook 文章目录锚点、Quant Hub GPU 一键筛选芯片
2026-06-25Cookbook 相关指南推荐、模型详情页相似模型卡片、首页 Hero 最新更新徽章
2026-06-25首页探索区块、404 页面、多模型基准测试（Qwen 7B/32B、DeepSeek-R1 14B）、AI 爬虫 llms.txt
2026-06-24新增关于页面（/about）— 维护者介绍、更新频率、参与贡献方式
2026-06-24Quant Hub：默认显示全部 51 个模型；规模统计条；GPU 筛选提示更清晰
2026-06-24SEO：canonical URL、JSON-LD 结构化数据、页面级 metadata、Google/Bing 验证环境变量
2026-06-24Quant Hub：GPU 档案筛选时可一键显示全部模型；Cookbook 新增 7 篇（8GB 显卡、WSL2、Docker GPU、Nginx、AMD ROCm）
2026-06-24隐私政策 + Plausible 分析、Cookbook 独立文章页（/cookbook/[slug]）、模型库扩展至 51 个
2026-06-24新增使用条款与免责声明页面（/legal），含商标声明和责任限制
2026-06-24Phase 3：HF 实时数据管道、模型 A vs B 对比工具、Cookbook 扩展至 15 篇
2026-06-24模型库扩展至 30+；新增格式向导、硬件档案、ExLlamaV2 CLI、SEO（sitemap/OG）、数据透明度改进
2026-06-24模型详情页、GPU 反向查询、可分享显存计算器 URL、真实首页统计
2025-06-10首次上线：模型库、显存计算器、CLI 生成器、基准测试、部署指南

所有数据均经人工整理并对照社区来源验证。部署前请务必交叉核对 Hugging Face 官方模型卡。

Hugging Face 模型卡、社区量化发布（bartowski、turboderp、unsloth、city96）、WikiText-2 PPL 基准

浏览最近模型 →