AIREITER从 0.9B 一路覆盖到 375B，六款模型看起来像是完整的部署阶梯；但一旦开始算账，情况并没有这么简单。K2 Horizon 的 Apache 2.0 许可证免除了模型授权费用，MoVA 能减少活跃计算量，但存储、KV 缓存、运行时和硬件成本依然存在。
六款 Apache 2.0 模型，具体发布了什么
IFM 于2026 年 9 月 3 日发布 K2 Horizon，将其定位为一组协同工作的六模型阵列：375B-A23B、36B-A4B、32B、7B、3.7B 和 0.9B。公告称模型及代码均以 Apache 2.0 发布，数据集则遵循各自适用的许可证（IFM 公告）。
同属一个系列，发布成熟度却不完全一致
这一系列的六个成员如下：
| 模型 | 架构 | 官方定位 | 官方资料标注的上下文 |
|---|---|---|---|
| K2 Horizon 0.9B | 稠密模型 | 手表、眼镜和受限边缘设备 | 128K / 131,072 tokens |
| K2 Horizon 3.7B | 稠密模型 | 手机、微调和轻量本地任务 | 512K / 524,288 tokens |
| K2 Horizon 7B | 稠密模型 | 手机、本地助手、编程与智能体 | 512K / 524,288 tokens |
| K2 Horizon 32B | 稠密模型 | 工作站和本地服务器 | 512K / 524,288 tokens |
| K2 Horizon MoVA 36B-A4B | 稀疏 MoE + MoVA | 本地高效推理 | 512K / 524,288 tokens |
| K2 Horizon 375B-A23B | 稀疏 MoE | 企业级和多加速器部署 | 512K / 524,288 tokens |
除了 0.9B 使用了更小的词表，这个系列共享架构与部署工具链。统一基础的目的，是让不同尺寸之间的迁移或路由更简单（IFM 新闻稿）。
不过，发布状态有一个重要差别：官方 K2-Horizon-32B 卡片明确表示，目前可见的检查点是Stage1，最终检查点仍待发布。相比之下，MoVA 36B-A4B 和 375B-A23B 的卡片均称最终检查点已经发布。因此，说“公布了六款模型”没有问题；但不能把它理解为“六个成熟度完全相同的最终生产检查点”（32B 模型卡、375B 模型卡）。
Apache 2.0 能为自托管团队省下什么，省不下什么
Apache 2.0 允许团队修改、再分发，并在商业产品中集成模型和代码，无需支付按 token 计费的授权费。IFM 表示，数据集遵循各自条款，例如 ODC-BY；受限来源的数据也未必可以直接再分发（IFM 公告）。
它免除的是许可费，不是运维账单。GPU 租用或折旧、模型存储、KV 缓存容量、运行时工程、监控和安全审查都仍然要花钱；36B 服务配方和375B 模型卡的示例还都使用了 trust_remote_code=True。
先按内存算账：六种尺寸的部署门槛
参数量标签适合横向比较模型能力，但自托管时，第一个硬约束往往是原始权重存储。下列估算按 BF16 每参数 2 字节、理想化 4-bit 每参数 0.5 字节计算；不包括元数据、运行时缓冲区、KV 缓存、tokenizer 文件和操作系统内存。
| 模型 | 用于规划的总参数量 | 每 token 活跃参数量 | 原始 BF16 规划下限 | 理想化 4-bit 下限 | 实际部署级别 |
|---|---|---|---|---|---|
| K2 Horizon 0.9B | 0.9B | 0.9B | ~1.8 GB | ~0.45 GB | 边缘与嵌入式实验 |
| K2 Horizon 3.7B | 3.7B | 3.7B | ~7.4 GB | ~1.85 GB | 紧凑型本地或移动端任务 |
| K2 Horizon 7B | 7B-class | 7B-class | ~14 GB* | ~3.5 GB* | 首个严肃的本地测试选择 |
| K2 Horizon 32B | 32B | 32B | ~64 GB | ~16 GB | 工作站或服务器 |
| K2 Horizon MoVA 36B-A4B | 36B | ~4B | ~72 GB | ~18 GB | 量化工作站或多 GPU 服务 |
| K2 Horizon 375B-A23B | 375B | ~23B | ~750 GB | ~187.5 GB | 企业级或集群级 |
\*7B 模型卡将其称为“7B-core”，但 Hugging Face 元数据显示为 9B 参数。做容量规划时，应以仓库中的实际文件为准，不能只看系列名称（7B 模型卡）。
具体仓库文件也说明了，以上只能算下限，不能当作承诺值。0.9B 的 BF16 GGUF 标注为2.16 GB，3.7B BF16 GGUF 为10.1 GB，32B Stage1 BF16 GGUF 为69.6 GB，MoVA 36B BF16 GGUF 则为74.9 GB（0.9B GGUF、3.7B GGUF、32B GGUF、36B GGUF）。
边缘端档位：0.9B、3.7B 与 7B
0.9B 和 3.7B 的存储负担最低，更适合资源受限且任务目标明确的工作负载，而非需要频繁恢复和纠错能力的智能体（0.9B 模型卡、3.7B GGUF 卡）。
如果要做第一次本地实验，7B 是系列中资料最完整的选择：模型卡覆盖推理与工具调用解析器、单设备 tensor parallel 配置以及量化变体。其展示的基准表中，SWE-bench Verified 为 70.6%、Terminal-Bench 2.1 为 39.1%、tau3-Banking 为 25.8%；但全部结果均使用高推理强度，且模型卡也提示评测协议细节可能存在差异（7B 模型卡）。
7B 模型卡建议采用高推理强度，并至少设置32,768 个输出 tokens。更长的推理会增加生成时间，因此即便模型装得进内存，按实际耗时计算也可能不便宜。
本地与服务器档位：32B 和 36B-A4B
32B 是全稠密模型，理解和评估都更直观；不过真正影响规划的是它仍处于 Stage1 状态，以及官方 GGUF 文件达到69.6 GB这一事实（32B Stage1 GGUF）。
MoVA 36B-A4B 提出了另一种取舍：能否以远低于稠密模型的活跃计算量，在保持更大总容量的同时接近稠密模型能力？IFM 的 GGUF 基准表显示，它在 tau3-Banking 上为 26.8%，在 Terminal-Bench 2.1 上为 58.6%，后者领先列出的对比模型；但在所有科学、事实性或长上下文指标上，它并非都领先（36B GGUF 基准卡）。
权重加载完成后，较少的活跃参数可能改善持续吞吐；不过实际结果仍取决于后端、批处理方式、互连和量化方案。
旗舰档位：375B-A23B
官方模型卡给出了 K2 Horizon 375B-A23B 经验证的 SGLang 配置：使用八张 H200 GPU、tensor parallelism 为 8、expert parallelism 为 8、BF16 与 FlashAttention-3（375B 模型卡）。
总参数量与活跃参数量的差异，能够降低其相较于稠密 375B 模型的计算量；但约 750GB 的 BF16 规划下限依旧划定了基础设施边界。Artificial Analysis 给出的信息是47 的 Intelligence Index 得分，以及其显示类别中112 个模型排名第 #11；不过该页面并未提供输出速度或单任务成本数据（Artificial Analysis 页面）。
基于目前已文档化且经验证的八张 H200 配置，应将它视为集群级部署。
MoVA 改变的是计算账，不是存储下限
MoVA 是 Mixture-of-Value Attention 的缩写。传统混合专家架构通常在前馈层引入稀疏路由；IFM 对 MoVA 的描述是，它将专家路由扩展到了注意力机制的 value 组件中，同时仍兼容 FlashAttention 和 grouped-query attention 等技术（IFM 架构说明）。
36B-A4B 这个名称到底表达了什么
“36B-A4B”包含两种不同的数字：模型总共约有 36B 参数可用，但每个 token 约只激活 4B 参数。对于持续生成类负载，这有望减少乘加运算和活跃路径的内存流量。
但这不代表未被选中的专家就不占空间。官方 BF16 GGUF 文件为74.9 GB；vLLM 配方则将模型描述为包含嵌入层在内37.44B 个存储参数，每 token 有5.95B 个活跃参数。这些数字是同一架构在打包和统计口径上的不同呈现，并不意味着另有一个独立的 37B 模型（vLLM 配方）。
可以用下面这个框架来理解：
- 常驻容量：存储和内存必须容纳所有可能被选中的权重。
- 活跃计算：每个 token 只会执行经路由选出的部分参数。
- 运行时状态：KV 缓存、临时缓冲区、批处理和框架开销依然存在。
- 系统成本：互连、电力、主机 RAM 与运维时间共同决定最终账单。
512K 上下文的宣传数字，不等于部署预算
较大 K2 Horizon 模型卡标注的原生上下文为524,288 tokens。但 MoVA 36B-A4B 和 375B-A23B 已公布的 vLLM 配方都配置了 --max-model-len 131072，仅为宣传最大值的四分之一（36B vLLM 配方、375B 模型卡）。
这些 131K 配置说明，原生 512K 上下文并不是免费可用的默认服务能力：更长上下文会消耗 KV 缓存、降低并发，并增加提示词延迟。
带成本视角的自托管场景
K2 Horizon 没有一套透明、通用的 API 定价可作为基准。官方 MoVA GGUF 页面称目前没有推理服务商部署该模型；Artificial Analysis 的 375B 页面虽然显示输入和输出价格均为 $0.00，但也将速度和单任务成本标为不可用。这不能证明存在免费的生产 API 端点（MoVA GGUF 卡、Artificial Analysis）。
| 场景 | 你能获得什么 | 主要经济风险 | 结论 |
|---|---|---|---|
| 24GB 级 GPU，搭配合适的 4-bit 36B 量化版本 | 低成本实验与隐私性 | 上下文和并发余量很小；量化与运行时支持可能尚不成熟 | 最适合试点，而非有保证的生产目标 |
| 32B BF16 或 36B BF16 工作站 | 更高保真度，质量对比也更直接 | 尚未计入缓存和运行时内存前，权重已占 64–75GB | 通常需要多 GPU 或高内存系统 |
| 双 H200 级别的 36B 服务 | 匹配已文档化的 MoVA 服务形态 | 租用、主机、存储和利用率成本 | 适合持续服务或受控评估 |
| 八张 H200 的 375B 服务 | 旗舰能力和企业级吞吐 | 高额资本投入或按小时计费的基础设施承诺 | 仅限集群级部署 |
24GB 级显卡实验
36B 模型理想化的 4-bit 权重下限约为18GB，在 24GB 显卡上，留给量化元数据、运行时缓冲区和 KV 缓存的空间不足 6GB。从这个算术关系看，24GB 级显卡在中等上下文长度下进行测试是可行的；但它并不构成通用最低配置。实际采用的量化方式、后端、卸载策略与提示词长度，都会决定运行是否真正可用。
引用的官方 MoVA GGUF 制品是 BF16，而不是小型消费级量化版本。Hugging Face 集合中列出了该系列的 GGUF 和 FP8 变体，但首发阶段的转换与兼容性工作，仍应计入部署预算（K2 Horizon 集合）。
“I assume they are still uploading other GGUFs--all I see is a BF16 GGUF so far” — u/apoptosist in r/LocalLLaMA.
遵循官方 36B 路径的双 H200 配置
IFM 的 MoVA vLLM 配方使用 tensor parallelism 2、expert parallelism、BF16，以及 131,072-token 的服务上限。其 SGLang 文档称该配置已在2× H200上验证；相比模型名称本身，这提供了更有力的硬件参考信号（vLLM 配方、官方 GGUF 卡）。
公开的服务商定价也说明了为何利用率如此关键。DigitalOcean 标注专用NVIDIA H200 为每 GPU 小时 $4.47，8× H200 配置为每小时 $35.78；Google Cloud 则标注 8× H200 A3 Ultra 机器为每小时 $84.806908493，该机器类型的价格包含附带的 vCPU、内存和 SSD（DigitalOcean 定价、Google Cloud 定价）。
按所列单 GPU 价格计算，两张 H200 约为每小时 $8.94，或按每月 730 小时计算$6,526，尚未包含主机和存储成本；这只能作为对利用率敏感的参考值，不能当成双 GPU 的正式报价。
375B-A23B 的八张 H200 配置
旗舰模型的官方服务配方采用八张 H200、TP=8、EP=8 和 BF16。该配置与模型约 750GB 的原始 BF16 规划下限相符，也明确划出了企业级基础设施边界（375B 模型卡）。
Google 标注的 8× H200 机器价格为每小时 $84.81，按 730 小时计算约为$61,909，这还未计入税费、数据传输、持久化存储和应用运维。它是基础设施价格参考，并不是 K2 Horizon 的定价，也不保证公开配方能达到某个特定的每秒 token 速度。
早期自托管反馈，能证明什么、不能证明什么
早期报告说明 K2 Horizon 已能运行，但不同量化方案和运行时的结果，还不足以建立一条通用的成本性能曲线。
一份较详细的 X 报告很好地展示了后端选择的影响：
“36B-A4B MoVA does 131-142 tok/s on 2x 5090 with llama.cpp (IFM's fork, Q8_0, 131K ctx) vs 52 on vLLM...” — @abtraore_.
这份有价值但未经控制变量验证的报告表明，只说“MoVA 更快”并不完整，必须同时说明后端和配置。
Reddit 讨论中仍可看到量化、小显存、对比评测和工具调用等未解问题，而不是已验证的性能结论（r/LocalLLaMA 讨论帖）。
如果要为采购做严肃决策，仍缺少以下测量数据：不同量化下的常驻内存、不同上下文长度下 KV 缓存的增长、提示词和生成速度、工具调用可靠性、功耗，以及在同一受控工作负载下每个成功任务的成本。
别只看活跃参数：按利用率选模型
K2 Horizon 哪一款更合适，取决于它的运行频率、所需上下文长度，以及输出质量是否足以支撑基础设施投入。短期试点应优先保证可逆性；全天候的私有服务则应优先考虑利用率和运维稳定性。
| 你的工作负载 | 建议起步模型 | 原因 | 何时停止或升级 |
|---|---|---|---|
| 可穿戴、嵌入式，或范围狭窄的分类器式任务 | 0.9B | 占用最小，并提供 128K 上下文声明 | 工具深度或领域覆盖成为瓶颈时 |
| 紧凑型本地助手或微调实验 | 3.7B | 存储负担较低，推理覆盖强于 0.9B | 编程失败和恢复失败成为主要问题时 |
| 第一个严肃的本地编程/智能体试点 | 7B | 已有解析器、tensor parallelism 与量化变体文档 | 长任务需要更可靠的规划或工具使用能力时 |
| 希望以稠密模型作为基线的高能力工作站 | 谨慎选择 32B Stage1 | 稠密模型行为更容易比较，但当前检查点尚未最终发布 | 最终检查点和实测结果足以证明内存投入合理时 |
| 反复进行本地或服务器推理，且活跃计算量很关键 | MoVA 36B-A4B | 活跃参数更少，并有已文档化的 TP=2/EP 路径 | 上下文、并发或运行时摩擦抵消效率优势时 |
| 企业级推理和长周期智能体 | 375B-A23B | 系列中容量最高，且有已文档化的 8× H200 路径 | 单任务成本或利用率无法通过商业论证时 |
第一次试点时，在更换模型前先记录五个值：峰值 VRAM/RAM、提示词长度、首 token 时间、每秒生成 token 数，以及每个完成任务的成本。在工作负载证明更长上下文值得承担缓存和延迟成本前，将上下文上限维持在已文档化的131,072 tokens。
如果你的问题只是某台机器适合哪一款系列模型，另一篇K2 Horizon 模型尺寸选择指南专门讨论这一更聚焦的选择问题。本文则优先关注利用率和实测任务成本，而不是活跃参数标签。
K2 Horizon 模型常见问题
Apache 2.0 是否意味着每个 K2 Horizon 数据集也都采用 Apache 2.0？
不是。IFM 表示模型和代码采用 Apache 2.0，数据集则遵循适用的许可证，例如 ODC-BY。再分发或将其用于商业训练前，应检查每个仓库和数据集的具体条款（IFM 公告）。
4B 活跃参数是否意味着 K2 Horizon MoVA 36B-A4B 只需要 4B 模型级别的内存？
不是。该模型每个 token 大约激活 4B 参数，但官方 BF16 GGUF 约为 74.9GB。权重存储、KV 缓存、运行时缓冲、量化开销和并发量，共同决定实际内存需求。
一张 24GB GPU 能运行 K2 Horizon MoVA 36B-A4B 吗？
合适的 4-bit 量化可能让中等上下文实验成为可行方案，因为理想化的 36B 权重下限约为 18GB。但官方 BF16 制品及已验证的双 H200 服务路径都需要大得多的余量，因此 24GB 的结果应视为试点配置，而非通用的生产保证。
宣传中的 512K 上下文适合经济地提供服务吗？
不一定。模型卡标注原生上下文为 524,288 tokens，而已文档化的 vLLM 示例使用 131,072 tokens；更长的上下文会增加 KV 缓存需求和延迟，并且通常会降低并发。
K2 Horizon 375B-A23B 算是常规的自托管模型吗？
不是。IFM 文档中给出的是八张 H200 的 SGLang 配置，原始 BF16 规划下限在运行时开销之前就已约为 750GB。除非有服务商发布更小且经过验证的配置，否则应将它视为企业级或集群级部署。
K2 Horizon 375B 显示的 $0.00 价格，是否意味着有真正免费的 API？
没有证据支持这一结论。Artificial Analysis 显示输入和输出价格为 $0.00，但速度和单任务成本均为不可用；官方模型页面也没有 Hugging Face 推理服务商。在将这个数字纳入预算前，应核实具名服务商的合同和价目表。