首先，我们频繁获得很棒的模型发布，这很棒，现在似乎每天都有。Inception labs发布了Mercury Coder，（经我测试）是一个比较有能力的模型，它能按照一到两年前的最先进水平（SOTA）进行编码（和一到两年前的最佳模型一样好），看到其扩散过程是很酷的一件事。真的很令人满意（也许是可解释性方面的一个优点？）。承诺每秒700 - 1000次事务处理（t/s）。我之所以说时间周期而不是模型，是因为它存在很多我记得GPT - 4（和GPT - 4 Turbo）也存在的问题。无论如何你都应该去看看。而且，由于某种原因，在同一天（至少模型权重已上传，预印本更早），我们得到了LLaDA，一个开源的扩散模型，它似乎在基准测试方面可以与llama 3 8b竞争，并且在引导（不是强制，有时不起作用）第n个单词为指定单词方面有一定的自由度。我发现演示中的质量比任何近期的模型都要差很多，但我也注意到当我操作并调整某些提示（以及单词目标，真的很酷）时，它有了很大的改进。也看看这个 - 它和Mercury不一样。简而言之；两个很酷的基于扩散的新大语言模型，一个闭源的与GPT - 4相当（基于我的直观判断）承诺每秒700 - 1000 t/s（从技术上讲是两种不同大小的模型），一个开源的据报道类似Llama3.1 - 8b，但测试（再次，只是我的测试）表明还需要更多的测试，哈哈。不要让开源模型被忽视。
讨论总结
这个讨论围绕着同一天发布的两个扩散LLMs展开。部分评论者对其持否定态度，认为相关内容令人失望、不可用，甚至是对GPU资源的浪费；而另一部分人则表现出积极态度，认为闭源和开源模型同日发布很酷，期望能推动深度语言模型快速创新。此外，还有评论者探讨模型性能比较、分享试用体验、提及模型发展方向以及在评估模型时遇到的困难等内容。
主要观点
- 👎 对新发布的LLMs感到失望、认为不可用且浪费资源
- 支持理由：评论者在使用过程中遇到连接错误、感觉不可用等情况，所以认为是对GPU资源的浪费。
- 反对声音：无明确反对声音。
- 👍 对同一天发布闭源和开源模型表示肯定并期待推动创新
- 正方观点：同一天看到两种模型发布很酷，从听到的信息看这些模型很有前景，希望能促使深度语言模型快速创新。
- 反方观点：无明确反对声音。
- 🤔 探讨扩散模型在CPU上运行与Transformer模型在GPU上运行的性能比较
- 解释：考虑到扩散模型吞吐率、硬件成本等因素，探讨其在CPU运行时与Transformer模型在GPU运行时的性能差异。
- 💡 对相关内容试用体验较好并寻求其他托管提供商
- 解释：试用者感觉不错，所以想寻找除Hugging Face之外符合OpenAI API兼容规范的托管提供商。
- 😕 对新模型的评估存在困难，需要更多时间考量
- 解释：表述很隐晦地表达了新模型存在难以评估或发现价值之处，所以需要更多时间。
金句与有趣评论
- “😂 Not pettable :()”
- 亮点：用一种诙谐的方式表达对相关内容的失望情绪。
- “🤔 It’s very cool to see an open - weights model release the same day as a closed one.”
- 亮点：积极看待两种不同类型模型在同一天发布这一现象。
- “👀 我在句子末尾给出了一个提示，它根据末尾的上下文生成了开头，这真的很酷。”
- 亮点：指出模型根据句子结尾语境生成开头内容这一有趣现象。
- “😏 Lambda slaps. Costs a hair more than Vast but it’s nice when the rentals actually work lol”
- 亮点：以一种幽默的方式推荐Lambda，强调其租用效果较好。
- “🧐 Can’t count r in strawberry. I’ll give them another year.”
- 亮点：非常隐晦且抽象地表达对新模型评估困难，需要更多时间的观点。
情感分析
总体情感倾向较为复杂，既有消极情感，如对新发布模型感到失望、认为不可用等；也有积极情感，如对模型发布表示肯定、期待创新等。主要分歧点在于对新发布模型的评价，可能是因为不同评论者的使用体验、对模型发展的期望以及对技术理解程度的不同导致的。
趋势与预测
- 新兴话题：扩散模型在不同硬件上运行的性能比较以及借助正则表达式控制生成输出可能会引发后续讨论。
- 潜在影响：如果这些模型如预期发展，可能会对自然语言处理领域在性能提升、准确性提高等方面产生积极影响。
详细内容：
标题：一日内两款扩散模型LLMs引发热议
在Reddit上，一篇关于“2 diffusion LLMs in one day -> don’t undermine the underdog”的帖子引起了广泛关注。该帖子介绍了一日内发布的两款新的扩散模型LLMs，分别是Inception labs发布的[mercury coder]（https://www.inceptionlabs.ai/news）和开源的[LLaDA]（https://arxiv.org/pdf/2502.09992）。帖子称[mercury coder]表现不错，承诺每秒处理 700 - 1000 个标记，而[LLaDA]在某些方面有待改进。此贴获得了众多的点赞和评论，引发了大家对这两款模型的热烈讨论。
讨论的焦点主要集中在模型的性能、应用场景以及发展前景等方面。有人认为：“[mercury coder]虽然表现出色，但仍存在一些与GPT 4类似的问题。”也有人表示：“[LLaDA]在演示中的质量远逊于近期其他模型，但通过调整提示和目标词，效果有了很大提升。”
在性能方面，有人提出：“假设我们有一个 32B 的扩散模型，其性能类似于 13B 的 Transformer 模型。由于吞吐量更高且 RAM 便宜，是否能在仅使用 CPU 的模式下运行这个 32B 模型，并获得与购买昂贵 GPU 用于 Transformer LLM 类似的结果？”对此，有人回应：“不行，因为在 CPU 上进行提示处理需要大量时间，仍然需要 GPU。而且与普通的自回归模型相反，在仅使用 CPU 时，扩散模型可能只会带来 3 - 4 倍的性能提升，并且扩散模型可能无法制成 MoE。”但也有人反驳：“我看过很多关于 MOE 扩散模型的论文，比如[https://arxiv.org/abs/2407.11633]。”
还有人分享了自己的见解和观点：“扩散模型有一个秘密武器。如果能正确进行多次迭代，可能会获得更好的每秒令牌性能和更好的输出。比如 1000 个令牌分 50 次处理，而不是 1000 次每次处理一个令牌。但它需要一种更好的迭代方式，不过这种可能性是存在的。”有人说：“哇，看，我在句子末尾给出提示，它能根据上下文生成开头。这真的很酷，因为它不是从左到右生成，而是一次性考虑整个上下文。”并且认为：“如果此类模型继续发展，我们不仅能获得前所未有的性能，还能提高生成的准确性和可控性。比如，在翻译漫画的任务中，可以让模型一次性观察所有句子的上下文进行翻译。”
不过，也有一些无价值的内容，比如“Can’t count r in strawberry. I’ll give them another year.”
总之，这次关于两款新的扩散模型LLMs的讨论展现了大家对技术发展的关注和期待，同时也反映出在模型的发展和应用方面仍存在许多有待探索和解决的问题。
感谢您的耐心阅读！来选个表情，或者留个评论吧！