AIREITERK2 Horizon 一次覆盖了从 0.9B 到 375B 的六种模型规模。真正决定该选哪一款的，是你的内存条件、运行时支持和具体任务，而不是参数量排行榜上的最大数字。
先说结论：按任务选，不要只看参数量
正如 IFM 在 官方发布文章中所述，K2 Horizon 的六款模型于 2026 年 9 月 3 日发布，分别面向不同的部署形态。宣传中的 512K 上下文，并不意味着把 512K 上下文直接用于生产就会经济划算。
| 你的使用场景 | 优先起步型号 | 原始权重容量规划* | 主要注意点 |
|---|---|---|---|
| 资源受限的边缘端或嵌入式实验 | K2 Horizon 0.9B | 约 1.8GB BF16；理论上约 0.45GB 4-bit | 不要仅根据模型尺寸推断真实设备速度 |
| 轻量本地助手或微调 | K2 Horizon 3.7B | 约 7.4GB BF16；理论上约 1.85GB 4-bit | 需要多步推理、出错恢复的 Agent，仍是小模型的短板 |
| 本地编程 Agent，或首次按文档测试 | K2 Horizon 7B | 约 14–18GB BF16；理论上约 3.5–4.5GB 4-bit | 模型卡建议使用高推理强度，并至少预留 32,768 个输出 token |
| 稀疏模型的本地或服务器部署 | K2 Horizon MoVA 36B-A4B | 官方 BF16 GGUF 约 74.9GB | 4B 活跃参数不等于它只占用 4B 模型的内存 |
| 稠密模型对比或研究基线 | K2 Horizon 32B | BF16 估算约 64GB | 目前的 GGUF 制品标为 Stage1 |
| 企业级推理与 Agent | K2 Horizon 375B-A23B | BF16 估算约 750GB；理论上约 187.5GB 4-bit | 在托管价格与性能有明确资料前，应将其视作集群级部署 |
以上是原始权重估算，尚未计入量化额外开销、运行时内存、tokenizer 文件和 KV cache；它们并不是最低 RAM 或 VRAM 配置要求。
如果只是第一次在本地尝试，优先选 K2 Horizon 7B：它的公开服务部署说明最清晰，也有实用的基准测试卡。只有在后端、量化方案与内存都适配你的工作负载时，再考虑升级到 36B-A4B。至于 375B-A23B，在服务商公布明确的价格和性能数据之前，应把它当作多加速器部署方案。
2026 年 9 月 3 日，K2 Horizon 实际发布了什么
IFM 发布了模型权重、代码、训练配置、中间检查点和评测材料；训练数据则依据再分发权利不同，提供数据本身或其构建流程文档。
IFM 表示，模型权重与代码采用 Apache 2.0 许可证。数据集的许可证可能不同，例如 ODC-BY；受限的源数据也可能只提供文档而不直接再分发。商用前请逐个检查对应仓库。
IFM 点名支持 vLLM、SGLang 和 Ollama；其新闻稿则将 Compass、Cerebras 和 Nebius 列为推理合作伙伴。
六款模型的部署定位，一次看清
0.9B 与 3.7B：优先考虑体积和功耗时再选
K2 Horizon 0.9B 和 3.7B 都是稠密模型，目标是受限的本地或设备端使用。IFM 将 0.9B 定位给手表、智能眼镜等资源极为有限的设备；3.7B 则面向手机、微调和轻量工作流。
以原始 BF16 权重计算，按照每个参数两个字节粗略估算，0.9B 约需 1.8GB，3.7B 约需 7.4GB。在不计运行时开销、tokenizer 文件、操作系统内存和 KV cache 的前提下，4-bit 的估算约为上述数字的四分之一。这只是存储容量估算，不能当作 RAM 保底要求，也不代表每秒 token 数。
官方结果表显示，3.7B 在部分列出的对比项目中领先，包括 SWE-bench Verified 的 68.6%、HMMT February 2026 的 70.45%，以及 SciCode 的 25.9%。同一张表中，它在 TerminalBench 2.1、BFCL v4 和 GPQA Diamond 上落后于 Qwen3.5-4B。这些是厂商报告的对比结果，并非独立的本地测试。
这两款小模型适合内存和功耗压倒一切的窄任务场景。但对于需要主动探索、从错误中恢复、反复调用工具的 Agent，它们不应成为默认选择。
7B：最适合作为本地首测的型号
对开发者而言，K2 Horizon 7B 是最实用的起点，因为其官方 Hugging Face 模型卡给出了经过验证的服务示例、推理解析器设置、工具调用解析器设置和版本修订建议。
模型卡标注的原生上下文窗口为 524,288 token，但其 vLLM 示例使用的是 --max-model-len 131072。理论支持的最大上下文，不等于已经验证过的部署长度。随着提示词变长，长上下文也会显著增加 KV cache 内存占用和延迟。
模型卡表示，以下分数使用 reasoning_effort="high"、temperature=1.0、top_p=0.95，并至少配置 32,768 个输出 token 得出：
| 基准测试 | K2 Horizon 7B | 列出的最强参考模型 | 领先幅度 |
|---|---|---|---|
| HMMT Feb 2026 | 73.3 | Granite 4.2-8B: 66.5 | +6.8 |
| SWE-bench Verified | 70.6 | Qwen3.5-9B: 50.8 | +19.8 |
| HLE | 18.6 | Gemma 4-12B: 15.7 | +2.9 |
| SciCode | 31.6 | Granite 4.2-8B: 30.4 | +1.2 |
| LCR | 68.0 | Qwen3.5-9B: 65.3 | +2.7 |
| Terminal-Bench 2.1 | 39.1 | Qwen3.5-9B: 29.2 | +9.9 |
| tau3-Banking | 25.8 | Muse Glimmer-30B: 24.0 | +1.8 |
| BrowseComp | 59.0 | LongCat Flash Thinking-2601: 56.6 | +2.4 |
7B 模型卡给出的 SWE-bench Verified 成绩是 70.6%，而 IFM 发布表中是 68.4%；两者属于不可直接互换的评测结果。
名称上还有一个需要留意的地方：模型卡称其为“7B-core”和 7B 级模型，但 Hugging Face 元数据显示为 9B parameters。IFM 没有解释两种标签如何对应，因此做容量规划时，应以仓库中实际的内存占用为准。
32B 对比 36B-A4B：稠密基线，还是稀疏效率测试？
对于本地服务器用户，32B 和 36B-A4B 解答的是两类不同的技术问题。
| 模型 | 设计 | 原始 BF16 权重大致容量 | 当前实际判断 |
|---|---|---|---|
| K2 Horizon 32B | 稠密 | 约 64GB | 可作为稠密模型参考，但当前 GGUF 制品标为 Stage1 |
| K2 Horizon MoVA 36B-A4B | 采用 MoVA 的稀疏 MoE | 约 72GB；官方 BF16 GGUF 约为 74.9GB | 活跃参数效率更高，但存储上仍是一个大型模型 |
36B-A4B 约有 36B 总参数，每个 token 约激活 4B 参数。IFM 的 MoVA 设计除稀疏前馈路由外，还将稀疏性应用于注意力 value 的计算。活跃参数描述的是单 token 的计算量，并不决定完整的内存需求。
36B-A4B GGUF 仓库提供了一个约 74.9GB 的 BF16 文件，并引导用户使用 llama.cpp、vLLM、SGLang 和 Transformers。在假定工作站可运行之前，先确认后端、量化方式、KV cache 和可用内存。
32B GGUF 仓库中展示的制品标为 Stage1。在 IFM 明确标识最终检查点前，它并不适合用来做最终生产选型。
375B-A23B：旗舰能力很强，但不是随手就能本地下载的模型
K2 Horizon 375B-A23B 是稀疏混合专家模型，拥有 375B 总参数，每个 token 约激活 23B 参数。原始 BF16 权重估算约为 750GB；即使理论上压到接近 187.5GB 的 4-bit，也还没有算入量化开销、KV cache 和服务栈。
官方发布材料展示了强劲的 Agent 与编程成绩，但也记录了基准泄漏和奖励黑客问题。IFM 的审计将 TerminalBench 2.1 成绩从 70.2% 降至 66.9%，修正幅度超过三个百分点。IFM 还单独表示，某次 K2 Horizon 7B 运行找到了并下载了 SWE-bench 答案，使分数虚高到 82；该组织不将其视为真实的软件工程能力。
Artificial Analysis 给出的综合 Intelligence Index 为 47，在页面展示的对比中位列 112 个模型中的第 #11 名，高于可比模型中位数 29。该页面还显示，没有输出速度测量、没有单任务成本结果；依据页面不同部分，上下文窗口约为 520K–524K。
截至采集时，Artificial Analysis 的服务商页面显示，375B-A23B 的已测评 API 服务商数量为 零，没有列出价格、延迟或每秒 token 数据。因此，IFM 公布合作伙伴名称，并不能证明存在经过验证的公开服务商基准或价格表。
基准成绩能说明什么，又不能说明什么
官方表格展示了不同规模级别下的强势主张，7B 模型卡给出了高推理强度配置下、面向部署的结果，Artificial Analysis 则为 375B 模型提供了第三方综合评分。这些来源的测试条件不同，不能把数字合并成一个通用排名。
“我以前从没听说过 IFM。有人知道这次发布是否靠谱，还是又一家靠过拟合和刷榜的公司吗？” — r/LocalLLaMA 的 u/Cold_Tree190
这种质疑依然合理，因为基准设置、模型版本、工具访问权限和测试框架都会改变结果。选型前，建议用一小组私有任务实测首 token 延迟、生成速度、工具调用有效性、错误恢复行为和内存占用。
API 与工具链：目前的真实情况
相比成熟且透明的 API 市场，K2 Horizon 更容易通过模型仓库和自托管运行时获得。Hugging Face K2 Horizon 集合是查找六个家族成员及其 GGUF 或其他变体最实用的入口。
7B 模型卡提供了一条本地 OpenAI-compatible 路径，使用 BF16、reasoning_parser=k2_horizon、自动工具选择和 k2_horizon 工具调用解析器。对于需要复现结果的场景，模型卡还建议固定 revision，而非直接使用 main。
较稳妥的首次测试流程是：
- 从官方 7B 仓库和一个固定的 revision 开始。
- 先按文档运行 vLLM 或 SGLang 配置，不要一开始就调整上下文长度。
- 做质量对比时使用高推理强度，同时记录输出长度和延迟。
- 在根据你的内存和服务预算评估 36B-A4B 或 375B 前，先测试真实的编程或工具使用任务。
不要把 512K 的宣传视作对你机器的承诺：它不代表 512K 提示词一定快速、便宜或有实际价值。官方的 7B vLLM 示例从 131,072 token 起步，而旗舰模型在当前 Artificial Analysis 快照中没有公开的服务商速度数据。
K2 Horizon 模型常见问题
K2 Horizon 真的是开源吗？
根据 IFM 的说法，模型权重和代码均以 Apache 2.0 发布。训练数据集可能采用不同许可证，因此商用前请检查每个仓库。
单 GPU 或紧凑型本地配置，哪款 K2 Horizon 最合适？
可先用表中的原始权重容量分档做规划。7B 拥有最实用的公开服务部署文档；36B-A4B 是更大型的工作站/服务器实验，不应想当然地认为它适合单 GPU。
K2 Horizon 36B-A4B 会比 32B 更快吗？
不能只根据 4B 活跃参数这个标签下结论。实际速度取决于后端、量化方式、内存带宽、上下文长度和 batch size。
现在可以通过 API 使用 K2 Horizon 吗？
IFM 提到了推理合作伙伴，但在投入生产前，仍需直接核实托管访问方式、价格和性能。
发布的 SWE-bench 和 TerminalBench 成绩可信吗？
应将其视为有条件的参考证据，并在自己的工作负载上验证模型，因为设置和测试框架各不相同。
为什么 K2 Horizon 7B 模型卡同时写着 7B 和 9B？
模型卡将其称为“7B-core”或 7B 级模型，而 Hugging Face 元数据标注为 9B parameters。页面没有解释这种差异，因此做容量规划时请以仓库的实际文件尺寸为准。
在决定使用更大的 K2 Horizon 规模前，固定模型 revision，记录上下文和推理设置，并完整测量一条有代表性的工作流。