链载Ai

标题: 1亿个Token！初创公司Magic与Google达成合作，表演LLM界的大力出奇迹。 [打印本页]

作者: 链载Ai 时间: 1 小时前
标题: 1亿个Token！初创公司Magic与Google达成合作，表演LLM界的大力出奇迹。

LLM 界的大力出奇迹是什么样的？

美国初创公司 Magic 最近发布了一个具有1亿Token 的上下文模型。通俗点说就是你发给 AI 的消息可以写1亿个字，和国产的 Kimi 走的路子有点像。

Magic 为新发布的 LTM 模型则不依赖于传统的模糊记忆训练方法，而是设计了一种新的名为 HashHop 的技术。

基于这种技术的模型可以对推理过程中给予的多达1亿个上下文标记进行推理，Magic还表示：

虽然这些超长上下文模型的商业应用很多，但我们只搞上游模型。

HashHop

回到现实，其实当前的长上下文评估并不理想。

就拿“大海捞针”这个故事来比喻评估，将一个随机事实（针）放在长上下文窗口（大海）中，要求模型检索这件事。

Magic 因此设计了 HashHop 技术，一个新的评估上下文长度和可靠性的体系。

但哈希是随机的，所以导致不可压缩，要求模型能够始终存储和检索给定上下文大小的最大可能信息内容。

先是提出一个使用哈希对进行训练的模型：

然后要求它完成随机选择的哈希对的值：

这里衡量了单步感应头的出现，但实际应用通常需要多跳。

为了实现这一点，让模型完成一个哈希链：

强调保证顺序和位置不变性，将对提示中的哈希对进行打乱：

并提出了一种更有挑战的变体，使其中模型跳过一些步骤。

例如直接从哈希1映射到哈希6：

这就要求模型架构能够一次性关注并跳过潜在空间中整个上下文的多个点。

HashHop技术的代码现在已对全网公开。

LTM-2-mini

Magic 发布的首个1亿个标记上下文模型：LTM-2-mini，相当于约1000万行代码或约750本小说。

对于100M标记上下文窗口， LTM-2-mini 的序列维度算法比 Llama 3.1 405B 中的注意力机制便宜1000 倍。

内存需求方面的对比更夸张。

运行具有 100M 令牌上下文的 Llama 3.1 405B 需要每个用户 638 个 H100才能存储单个 100M 令牌 KV 缓存。

相比之下，LTM 只需要每个用户单个 H100 HBM 的一小部分。

通过上面的思路链式哈希训练，LTM 架构得到以下结果：

团队发现，在没有思路链的情况下尝试3次或更多次跳跃时性能会变差。

但对于一次2次跳跃（哈希1 → 哈希3），在没有思路链的情况下，性能上却提升了不少。

ingFang SC", "Hiragino Sans GB", "Microsoft YaHei UI", "Microsoft YaHei", Arial, sans-serif;font-size: var(--articleFontsize);letter-spacing: 0.034em;width: 562px;height: 117px;"/>

利用超长上下文机制在 text-to-diff 数据上训练了一个原型模型。

虽比前沿模型小几个数量级，但也承认了它的代码合成能力并不是很好，只能偶尔会产生合理的输出。

和Google合作

为了训练这庞大的 token 数，Magic 正式宣布与 Google Cloud合作打造两台新的云端超级计算机

其实全球也将近超过一半的生成式 AI 初创公司都在 Google Cloud 上利用它的 AI 平台。

借助 Google Cloud，Magic 将利用搭载 NVIDIA H100 Tensor Core GPU 的 A3 Mega VM 构建其 G4 超级计算机。

这些计算机能够实现 160 百亿亿次浮点运算，大约相当于1600 亿人每人持有 10 亿台计算器并在同一时刻进行计算。

恐怖的性能指标。

ingFang SC", "Hiragino Sans GB", "Microsoft YaHei UI", "Microsoft YaHei", Arial, sans-serif;letter-spacing: 0.578px;text-align: center;text-wrap: wrap;width: 578px;"/>