K2 Horizon：一个由六个开源模型组成的互联舰队

原文 ↗ Hacker News 讨论 ↗

一组新的“激进开放”K2 Horizon 语言模型引起了关注：它们既发布了权重和大量训练数据，也试图提供一个完全透明的训练流水线。评论者欢迎又一个认真的开源全栈参与者——尤其是一个在普通硬件上也能在编码基准上有竞争力的 7B 模型——但也指出，更大的变体仍落后于 Qwen 等顶级开源模型，而且一些仓库和配方仍不完整。此次发布还重新点燃了更广泛的争论：完全开源的模型是否应该、也是否能够包含训练数据，版权与合理使用如何适用，以及新 LLM 的迅速涌现是否正在导致“模型疲劳”。

模型疲劳、炒作与对过去技术周期的类比

  • 几位评论者表达了对不断发布新模型的“模型疲劳”。
  • 有人将其与早期 CPU 和智能手机的炒作时代作比较：最初的发布是大事件，如今只有专家会追踪每一款新芯片/手机。
  • 预期 LLM 也会走上类似路径：大多数用户只会挑选“够好用”的模型。
  • 有人指出，“你不必一直关注”；用模型做了什么比追逐前沿发布更重要。

开放性、训练数据与“激进开放”主张

  • 强烈支持完整开放的技术栈：权重、代码、训练数据和配方，以减少黑箱操控。
  • 在训练数据和完整配方真正发布之前，对“激进开放”式营销持怀疑态度。
  • 有人指出，K2 的训练数据集已经在 Hugging Face 上了，但预训练/后训练仓库仍然只是占位符。
  • 同一生态中之前的工作（例如更早的 K2 模型）让一些人预期最终会给出完整配方，但他们仍保留判断。

性能与基准测试

  • 根据他们自己的图表，Dense 32B 被认为落后于更强的开源竞争者，如 Qwen 3.8 27B；Gemma 4 31B 不在对比范围内。
  • 有人认为 32B 被标注为“stage 1”且尚未完成，因此提前发布主要是为了展示开放流水线。
  • 7B 模型多次被称赞令人印象深刻，可能是“10B 以下最佳”，并且在编码基准上具有竞争力（例如，SWE-bench-verified 分数可与大得多的模型相当）。
  • 也有人强调，对比中遗漏了更新且强劲的开源模型，而且量化类别/变体并没有始终一一对应。

编码能力与小模型

  • 少数用户用较小的模型（3.7B、7B）测试面试风格的编程题。
  • 反馈称：3.7B 无法完成基础任务，会幻觉出 API，并卡住；7B 给出的答案则好坏参半，或只有部分正确。
  • 围绕子 10B 模型是否适合严肃编码，还是只适合自动补全/总结展开争论。
  • 有人将其与其他已经能很好处理此类任务的小型编码模型作比较。

工具链、部署与实际可用性

  • 有人对在本地运行 K2 很感兴趣；用户提到 vLLM 支持，以及其他模型近期获得的 dflash2 支持。
  • 让人沮丧的是，新发布的模型通常很快支持 vLLM，但在 llama.cpp 上却滞后，而后者对老旧/低端硬件至关重要。
  • 观察到托管的 K2 演示在正常工作时速度极快，尽管起初有些模型不可用。

更广泛的知识产权、版权与合成数据争论

  • 有一段很长的子线程讨论，在现行版权法下，完全开源的模型是否真的可能。
  • 讨论的思路包括：
    • 用 LLM 从不可授权来源生成合成训练数据。
    • 完全合成或仅使用公有领域语料。
    • 去中心化训练与存储。
  • 有人提出将所有可公开访问的互联网数据都视为公有领域，这一争议性提议遭到强烈批评，被认为不切实际且反乌托邦。
  • 也有人提到现有项目（例如 OLMo/Dolma 及类似项目）作为透明流水线的部分概念验证，尽管底层抓取内容并不能完全再分发。

杂项

  • 有人抱怨博客图表缺失/被锁，以及图表很小、难以阅读。
  • 对命名感到困惑（“K2” 已在别处使用）。
  • 也有人表示欣赏这次发布恰逢闭源 LLM 的重大故障期，这进一步强化了开源模型的价值感。