K2 Horizon 375B-A23B
375B-A23BMBZUAI K2 Horizon
MBZUAI IFM 的 K2 Horizon 系列中最大的型号,Apache 2.0 许可,训练数据一并公开:按配置算出 379B 参数,每个 token 约激活 23B。61 层每一层都保留普通缓存。Q2_K(bartowski 的 146 GB,分 4 卷)在 4K 下约需 154 GB,256 GB 的 Mac Studio 宽裕;Q4_K_M(238 GB,分 7 卷)约需 250 GB,只有 512 GB 的才宽裕。IFM 没有为这个尺寸发布 GGUF;这里的体积按 bartowski 的文件计算,各档位的质量损失未公布。
524K
最大上下文
4
量化变体
GGUF Q8_0
最佳质量
—
困惑度增幅(最佳档位)
量化变体对比
各量化级别的显存、质量损失及 RTX 4090 推理速度
实测 = 本站跑过 · 估算 = 本站未跑过:推算所得,或本站未核实的数字 · 社区 = 公开报告
| 格式 | 级别 | BPW | 显存 | PPL 损失 | 速度 | 来源 | 操作 |
|---|---|---|---|---|---|---|---|
| GGUF | Q2_K | 3.09 | 154.1 GB | — | — | 估算 | |
| GGUF | Q3_K_M | 3.85 | 191.7 GB | — | — | 估算 | |
| GGUF | Q4_K_M | 5.02 | 249.7 GB | — | — | 估算 | |
| GGUF | Q8_0 | 8.5 | 422.0 GB | — | — | 估算 |
每个体积对应哪个文件
文件大小不等于显存:显存一栏是计算器在 4K 上下文下的总量 —— 权重加 KV 缓存,再加 10% 的激活缓冲。两边的单位是有意不同的:文件大小用十进制 GB,和 Hugging Face 列表一致;显存一栏用 GiB(1024³ 字节),并在权重上多算 2%,所以 7.12 GB 的文件在那一栏里约是 6.8 GiB。仓库若带视觉投影(mmproj),它是另外下载的文件,两个数字都不含它。
- GGUF Q2_Kbartowski/K2-Horizon-375B-A23B-GGUF · K2-Horizon-375B-A23B-Q2_K-00001-of-00004.gguf · 146.25 GB (146,249,929,920 字节) · 分 4 卷 · 2026-10-23 核对
- GGUF Q3_K_Mbartowski/K2-Horizon-375B-A23B-GGUF · K2-Horizon-375B-A23B-Q3_K_M-00001-of-00005.gguf · 182.54 GB (182,537,573,664 字节) · 分 5 卷 · 2026-10-23 核对
- GGUF Q4_K_Mbartowski/K2-Horizon-375B-A23B-GGUF · K2-Horizon-375B-A23B-Q4_K_M-00001-of-00007.gguf · 237.80 GB (237,797,004,832 字节) · 分 7 卷 · 2026-10-23 核对
- GGUF Q8_0bartowski/K2-Horizon-375B-A23B-GGUF · K2-Horizon-375B-A23B-Q8_0-00001-of-00011.gguf · 403.08 GB (403,079,845,472 字节) · 分 11 卷 · 2026-10-23 核对
相似模型
与 K2 Horizon 对比K2 Horizon MoVA 36B-A4B
MBZUAI K2 Horizon
MBZUAI IFM 的 K2 Horizon 系列中的混合专家型号:37.5B 参数,每个 token 约激活 4B,Apache 2.0 许可,训练数据一并公开。48 层每层都保留普通 KV 缓存,所以上下文不便宜:Q4_K_M 在 4K 上下文约需 24.2 GB,24 GB 显卡上偏紧,32 GB 显卡到 16K 都宽裕;用满 512K 窗口约需 129 GB。llama.cpp 以 `k2-horizon` 架构运行它。体积按 IFM 官方 GGUF 文件计算(bartowski 的 Q4_K_M 约大 0.3 GB),各档位的质量损失未公布。
K2 Horizon 32B
MBZUAI K2 Horizon
MBZUAI IFM 的 K2 Horizon 系列中的 32B 稠密型号(实际 34.8B 参数,Apache 2.0 许可,训练数据一并公开)。64 层每层都保留 8 个 KV 头的普通缓存:Q4_K_M 在 4K 上下文约需 23.1 GB,24 GB 显卡上偏紧,32 GB 显卡到 16K 都宽裕;上下文每多 32K 约多 8.8 GB。llama.cpp 以 `k2-horizon` 架构运行它。体积按 IFM 官方 GGUF 文件计算(bartowski 的 Q4_K_M 约大 1 GB),各档位的质量损失未公布。
K2 Horizon 7B
MBZUAI K2 Horizon
MBZUAI IFM 的 K2 Horizon 系列中的小号稠密型号,Apache 2.0 许可,训练数据一并公开。名字叫 7B,实际有 9.0B 参数:25 万词表的输入、输出两张表多出约 2B。Q4_K_M 在 4K 上下文约需 6.5 GB,8 GB 显卡在这个长度下宽裕;16 GB 显卡到 32K(10.8 GB)都宽裕,128K 则约需 25.6 GB,因为每层都保留普通 KV 缓存。llama.cpp 以 `k2-horizon` 架构运行它。体积按 IFM 官方 GGUF 文件计算(bartowski 的 Q4_K_M 约大 0.2 GB),各档位的质量损失未公布。
K2 Horizon 0.9B
MBZUAI K2 Horizon
MBZUAI IFM 的 K2 Horizon 系列中最小的型号,Apache 2.0 许可,训练数据一并公开。名字叫 0.9B,实际是 1.08B 参数。Q4_K_M 在 4K 下约需 1.0 GB,32K 下约 2.6 GB,几乎什么硬件都能跑,包括纯 CPU。它每一层都保留普通缓存,所以用满 128K 窗口约需 8.4 GB。IFM 自己的 GGUF 仓库把这些文件命名为 1B;这里的体积按 bartowski 的文件计算,各档位的质量损失未公布。
在本地运行 K2 Horizon 375B-A23B
在 Q4_K_M、4K 上下文下,K2 Horizon 375B-A23B 约需 249.7 GB —— 权重 226.0 GB、KV 缓存 0.95 GB、激活缓冲 22.7 GB。本索引中能宽裕跑它的最小显卡是 512 GB 的 Mac M5 Ultra 512G,78 张卡中有 1 张可以。这些是计算值而非实测值:估算把「宽裕」的界线画在显存的 88%,大致就是桌面环境需要留出的余量。
上下文变长会多花多少
从 4K 提到 32K 约多占 6.68 GB,总量来到 257.0 GB。权重不随上下文变化,只有 KV 缓存会,而且是线性增长 —— 规划长文档场景时要盯的就是这个数字。该模型的原生上下文是 512K;在 Q4_K_M 下把它全部撑满约需 383 GB。
该下载哪个版本
本索引只收录了 K2 Horizon 375B-A23B 的 GGUF 格式,共 4 个档位(Q2_K、Q3_K_M、Q4_K_M、Q8_0)。 该模型没有公开的逐档困惑度数据,因此质量一列留空而不是填估算值 —— 在同一个模型内部,位数越多越忠实是数据唯一支持的排序。本站硬件上没有该模型的吞吐实测数据。GGUF 可在 NVIDIA、AMD 与苹果芯片上通过 llama.cpp 和 Ollama 运行;AWQ 与 GPTQ 面向 CUDA 和 ROCm 上的 vLLM;EXL2 是 ExLlamaV2 —— 仅限 CUDA,而且已经归档,适合本机使用而不适合提供服务。
常见问题
- K2 Horizon 375B-A23B 需要多少显存?
- 在 Q4_K_M、4K 上下文、batch 1 下约 249.7 GB,到 32K 时约 257.0 GB。这个数字是权重加 KV 缓存再加 10% 激活缓冲,由模型架构计算得出,不是在显卡上实测的。
- K2 Horizon 375B-A23B 能在 512GB 显卡上跑吗?
- 可以 —— 在 Q4_K_M、4K 上下文下约需 249.7 GB,在 Mac M5 Ultra 512G 上还剩 134.3 GB。这是本索引中能宽裕跑它的最小显卡;78 张中有 1 张可以。
- K2 Horizon 375B-A23B 该用哪个量化档位?
- 该模型没有公开的质量对比数据,所以按体积来选:Q4_K_M 是多数人使用的档位,bits-per-weight 越高越忠实。索引中的 4 个档位是 Q2_K、Q3_K_M、Q4_K_M、Q8_0。 注意这是 MoE 模型 —— 尽管每个 token 只激活一部分参数,全部参数仍需驻留显存,因此显存开销按总参数量算,而不是激活参数量。
这个模型能跑在哪
按 Q4_K_M、4K 上下文估算,显存从小到大排列。「从容」指估算占用不超过显存的 88%。
- 提供格式
- GGUF
怎么把它跑起来
针对本模型及同类硬件的部署指南。
本页数字会随模型数据或运行时版本的变化而更新。最近更新 2026-10-23 RSS → /zh/feed.xml