ainews-and-welcome-ai-twitter

……欢迎来到 AI 推特圈！

· f6170a9b-bb14-404e-ad10-06dc9e044d33

2024年2月27日至28日的 AI 推特（Twitter）讨论涵盖了广泛的领域，包括 Margaret Mitchell 针对 Google Gemini 发布所强调的伦理考量，以及 John Carmack 对 AI 时代不断演变的编程技能的见解。

Guillaume Lample 宣布发布 Mistral Large 多语言模型。讨论还涉及了 Google 内部关于 Sundar Pichai 潜在领导层变动的传闻，以及 Delip Rao 提到的 OpenAI 可能进入合成数据市场的消息。技术进步方面包括 Yann LeCun 对在移动设备上运行大语言模型（LLM）的评论，以及 Alex Wang 对 Apple Vision Pro 的赞赏。

Pieter Levels 提出了关于 Stripe 支付政策的金融平台问题。François Chollet 和 Dhéliat 讨论了大厂内部的文化动态。此外，Pieter Levels 和 AISafetyMemes 带来的梗图和幽默展现了 AI 轻松有趣的一面。这份摘要反映了快速演变的 AI 领域，融合了技术创新、公司战略、伦理和社区文化。

#ai-ethics #multilinguality #on-device-ai #convolutional-neural-networks #synthetic-data #financial-transaction-systems #corporate-culture #humor mistral-large google-gemini google openai apple stripe

2024年2月27-28日的 AI Discord + Twitter 动态。我们为你检查了 22 个公会、349 个频道和 8212 条消息。预计节省阅读时间（按 200wpm 计算）：743 分钟。

又是平静的一天，但恰逢我们 Twitter 数据流水线和摘要功能的 MVP 发布！你可能已经注意到，为了迎接这一天，我们已更名为 “AI News”。

目前它提取自 swyx 的 AI High Signal 列表，但我们最终应该能够将其推广到你的自定义列表。欢迎对 Prompt 提供反馈（见下文）！

目录

[TOC]

第 X 部分：AI Twitter 回顾

高层摘要

Twitter 上针对技术和工程师群体的讨论凸显了 AI 快速演进的本质，涉及伦理考量、技术进步、企业高层变动、金融交易动态，以及通过幽默展现的技术生活轻松一面。关键点包括对 Google 领导层变动的猜测，强调未来程序员可能需要的非编程技能，围绕新 AI 模型及其应用的讨论，对金融交易平台的担忧，以及对大厂内部文化的洞察。技术创新、企业战略、伦理挑战和工程师日常问题的结合，生动地描绘了当前的技术版图。

AI 与机器学习趋势

  • 关于 AI 伦理及其应用的讨论揭示了多元观点，Margaret Mitchell 讨论了由 Google Gemini 发布引发的伦理在 AI 中的角色问题。
  • AI 对编码和编程技能的影响是一个热门话题，John Carmack 分享了关于从传统编码向管理 AI 转变的思考。
  • Guillaume Lample 宣布发布 “Mistral Large”，这是一个具有多语言能力的改进模型。
  • Pieter Levels 讨论了 AI 生成内容及其对网页原创性的潜在威胁，并预测了“查看源代码”（view-source）的终结。

业务与管理洞察

  • 人们对 Google CEO 职位的潜在变动进行了推测，Levels 和 Arav Srinivas 讨论了 Sundar Pichai 的贡献和未来前景。
  • Levels 还讨论了高薪工程师的独特之处，重点在于适应能力和务实精神。
  • Delip Rao 揭示了 OpenAI 可能进入合成数据市场，暗示了 AI 开发的新策略。

技术与硬件

  • Santiago L. Valdarrama 提出了一个深度学习项目挑战，重点是从图像中识别门牌号，鼓励使用 CNN 而非 OCR 解决方案。
  • Alex Wang 赞扬了 Apple Vision Pro 在出差期间带来的生产力提升。
  • Yann LeCun 讨论了在移动设备上运行 LLM，表明了端侧 AI 的进展。

金融交易与平台动态

  • Pieter Levels 对 Stripe 将某些付款判定为高风险表示沮丧，这影响了他的业务 (推文)。
  • François Chollet 和 Dhéliat 讨论了大厂员工内部的政治与文化，概述了这些空间与初创公司相比的非政治性质 (推文)。

迷因/幽默

  • Pieter Levels 幽默地想知道根据他拥有的相关物品，他是否是一个 “Broccoli boy”。
  • AISafetyMemes 以戏谑的方式思考了 AI 对未来社会规范的影响 (推文)。

[META - 帮助我们] AI Twitter 摘要提示词

这是生成上述摘要的提示词。请帮助我们改进它！

你是一个摘要/标签生成 AI，旨在为注重细节的技术工程师群体整合 Twitter 上的重要讨论话题。你的任务是创建一个统一的摘要，捕捉关键点、对话和引用。重点关注主题连贯性，并将类似的讨论点分组。

给定一组推文列表，格式为元组 (tweet_text, impression_count, tweet_url)，执行以下任务：

  • 将所有推文归类为最多 6 个类别。始终保留 1 个类别用于 memes/humor（梗图/幽默）。使用 Named Entity Recognition（命名实体识别）来标记和分类所有的摘要及推文。

  • 按浏览量（impression count）降序排列每个类别中的推文，使浏览量最高的推文排在最前面。

  • 以结构化格式呈现结果，将推文组织在各自的类别下。确保为每条推文添加链接，以便用户验证。

之后，根据你分组和标记的主题生成一个高层级的摘要。 梳理并编织一段引人入胜的叙述，将所有类别整合在一起，并在文中直接引用推文。 确保叙述中的每个段落至少有 3 条支持推文，以便用户知道你的内容是有事实依据的，而不是凭空捏造。

策略：

  • 当你直接引用推文时，请务必附上链接。
  • 捕捉关键点、对话和引用。
  • 关注主题连贯性并对相似话题进行分组。

技巧：

  • 密切关注每条推文的上下文和内容，以便准确分类。
  • 确保摘要简明扼要且信息丰富，让读者一目了然地掌握要点。
  • 在链接推文时，请使用 Markdown 格式，并将其自然地融入句子中。
    • 正确示例：”Sam Altman 提到 缩放定律（scaling laws）是由上帝决定的；而常数则由技术人员决定”
    • 错误示例：”Sam Altman 提到缩放定律是由上帝决定的；而常数则由技术人员决定。(阅读更多 )”
  • 不要对主题进行开场介绍，只需列出主题及相关的推文。

维护用户数据的机密性，仅关注内容及其影响。 TWEET_DATA_HERE # —- 消息历史记录结束。

按照系统指定的格式返回所有推文的摘要。 仅对给定的推文进行总结，不要添加给定来源中未提及的任何额外信息，但要引用对 AI Engineer 相关的细节。 不要幻觉（hallucinate）任何给定来源中未提及的额外信息。

开始。

PART 0: 摘要之摘要之摘要

  • 投资与行业动态：Microsoft 对 Mistral AI 进行的 1600 万美元重大投资引发了关于潜在垄断行为与刺激行业竞争之间博弈的讨论，相关见解源自 TechCrunch 文章的详细分析。同时，Mistral 在美国市场的推测模型规模和收入潜力引发了关于模型微调、定价策略以及开发者遇到的技术挑战的辩论，展示了 AI 企业解决方案的复杂格局。

  • 技术进步与挑战：通过 GitHub 示例对高效 AI 训练方法的探索，例如用于代码模型微调的 DeepSeek 和用于高性价比训练的 QLoRA，反映了 AI 社区对创新日益增长的追求。这一主题延伸到了围绕 Vulkan backend 性能改进、使用 LoRa 进行微调的细微差别以及部署策略的讨论，强调了利用 AI 技术过程中的技术演进和运营障碍。

  • 社区与伦理考量：AI 社区内的讨论还涉及 AI 输出的伦理影响、LLM 角色扮演中模型“虚构”（confabulation）与“幻觉”（hallucination）之间的平衡，以及在 AI 回复中模仿人类错误的伦理考量。这些对话突显了对 AI 进步所带来的道德和社会影响的持续关注。

  • 模型性能与利用：围绕模型性能的对话，特别是在 Google 企业工具和 Mistral Large 能力的背景下，展示了对 AI 技术有效性及其实际应用的批判性审查。这包括对 AI 视频理解能力、部署指南和开源贡献的讨论，说明了社区专注于利用 AI 产生现实世界的影响及其面临的挑战。

PART 1: 高层级 Discord 摘要

TheBloke Discord 摘要

  • 微软通过投资 Mistral 推动 AI 竞赛：Microsoft 对 Mistral AI 的 1600 万美元投资引发了关于潜在垄断倾向与 AI 行业竞争益处的辩论，具体参考了 TechCrunch 文章。

  • LLM 角色扮演的利弊与特性：离线模型在角色扮演叙事场景中的实际应用以及模型输出的伦理考量是焦点，强调了内容“虚构”与“幻觉”之间的微妙界限。

  • 寻求高效的 AI 训练：爱好者们探索了通过 GitHub 示例教学 LLM 的领域，使用了如 DeepSeek-Coder GitHub 仓库中提到的用于微调代码模型的 DeepSeek 框架，以及 Unsloth 项目中高性价比的训练技术 QLoRA。

  • GGUF：弥合转换差距：提供了关于将 Hugging Face 模型转换为 GGUF 格式以实现 Q5 KM 输出的技术见解，并澄清了量化是一个独立的过程，详见 llama README。

  • 编程领域的速度瓶颈与 GPU 困境：关于使用 CSV 文件加速聊天响应时间以及克服 Google Colab 等平台上 GPU 资源匮乏的咨询，促成了利用 Hugging Face 等供应商提供的云端 API 来提升推理速度的建议。

Mistral Discord 总结

  • Mistral 的规模与收入推测：@rabdullin 推测 Mistral Medium 可能拥有 70B 参数，并讨论了 Mistral AI 进入美国企业市场对业务的影响。@sublimatorniq 讨论了微调挑战以及新模型之间的定价差异，而 @myhaw 和 @lerela 遇到了使用 Mistral 模型开发聊天机器人的技术问题，该问题随后已得到解决。

  • Vulkan 后端的兴起与局限：通过利用 Vulkan 后端，性能和效率得到了提升，@saintvaseline 对在 AMD PC 上运行 7B 参数模型表示兴奋。然而，@tokenshifter 提到一个技术限制，即 API 会绕过张量加速器。关于在多 GPU 上进行大模型推理的共同咨询引起了对推荐资源分配的关注。

  • 微调的技巧与陷阱：来自 @ethux 和 @kushagra_67246 的集成关注点澄清了 LoRa 的作用是行为性的而非信息性的。讨论了 Mistral 微调，@kunpengguo 得到了关于所需大量资源的建议。此外，@aaronbarreiro 和 @mrdragonfox 讨论了训练中添加文档的 32k token 限制。

  • 部署指南与案例展示：@raoufchebri、@boles.ai、@deexxcryptz 和 @arunprakashai 提供了各种资源，从 Azure 的部署指南到使用 Sensei 生成合成数据的插件，证明了社区在利用 Mistral Large 方面的努力。同时，@cogbuji 介绍了一个在 Hugging Face 上可用的经过微调的医学术语 Mistral 模型。

  • 开源混淆与伦理探讨：关于 Mistral 开源贡献的复杂反应由 @mrdragonfox 对当前权重开放（Openweight）模型的澄清而平息。在 AI 回复中模拟人为错误的伦理问题引起了 @dawn.dusk 和 @foxalabs_32486 等用户的讨论，这标志着与模型设计辩论的哲学联系。

  • 对 Google 企业级产品的怀疑及模型问题：@egalitaristen 对 Google 企业工具的性能表示怀疑，同时 @sublimatorniq 分享了关于 1.5 PRO 等模型能力的混合体验，@egalitaristen 则要求提供实操证明。此外，在 Mistral 上调用 Function calling 的问题以及 Le Chat 的隐私担忧也是讨论的重要点。

  • 对 AI 视频理解能力的审视与开发障碍：@sublimatorniq 分享了 AI 在描述视频内容方面表现不足，表明了模型能力的差距。@foxalabs_32486 强调了由于专业知识需求和高度竞争，AI 领域的招聘挑战。

LM Studio Discord 总结

  • 大模型，高门槛：技术讨论集中在 LM Studio 中加载大模型的挑战，例如在拥有 60GB RAM 和 8GB VRAM 的环境下加载 35GB 模型，预计性能会较慢。会议还强调了平台差异，如 Mac 主要依赖 RAM，而 Windows 则受益于 GPU offloading。此外，讨论中提到了对三进制模型（ternary model）研究的新兴兴趣，并引用了一篇论文，提出了将 120B 模型装入 24GB VRAM GPU 的可能性。

  • 模组与脚本困境：提出了关于如何使用 Fabric 模组 API 的最新信息来更新 LLM 的问题，以及对 Pine Script 代码生成的支持咨询，为此提供了一个来自 OpenAI 的自定义 GPT 链接。

  • 硬件前景与麻烦：在硬件讨论频道中，有人提议在包括电动汽车和金融在内的各种行业中使用 LLM。TinyCorp 宣布推出 TinyBox，配备 6x 7900XTX GPU 和 EPYC 7532 CPU，旨在彻底改变 AI 处理能力。NVIDIA GPU 与 LLM 的硬件兼容性问题，以及可能影响 LM Studio 使用的 Windows 系统损坏问题也浮出水面。

  • Beta 测试的界限与突破：Beta 发布聊天频道较为冷清，其中一条详细回复解释了如何在 LM Studio 中添加图像，指定模型 PsiPi/liuhaotian_llava-v1.5-13b-GGUF/ 为前提条件，并建议下载该模型的 mmproj 和 GGUF 文件以支持图像功能。

  • 语言障碍：在 autogen 频道中，讨论显示在翻译心理报告时，Gemini 是比 ChatGPT 更受青睐的选择，尽管存在不希望出现的格式和插入内容。翻译的上下文被指定为从土耳其语翻译成英语。

  • 快速响应声誉：langchain 频道中的唯一条目提供的上下文极少，但暗示了高效的性能，未作进一步阐述。

  • 从 WSL 困境到胜利：open-interpreter 频道解决了 WSL 环境中关于连接错误 httpcore.ConnectError: [Errno 111] Connection refused 的挑战。通过使用真实的本地 IP 网络地址代替 localhost，用户在查阅 Open Interpreter’s Docs 并排查 WSL1 和 WSL2 之间不同的网络行为后，成功解决了该问题。

OpenAI Discord 总结

  • Sora 的独立篇章：关于 Sora 是会集成到 ChatGPT 中还是作为独立应用启动（类似于 DALL-E 的发展轨迹）引起了热议。同时，memory feature（记忆功能）的推广正在进行中，正有选择性地向用户发布，但尚未提供具体的时间表。

  • Mamba 的记忆困境与 AI 竞赛：关于 Mamba 算法倾向于遗忘其模型认为不重要的微小细节的问题引起了关注。AI 社区还在关注 Mistral Large 的进展，该模型目前仅落后 GPT-4 20%，并已在 Azure 上可用。顺便提一下，有关于 Copilot 偏见的报告，并附带了通过 OpenAI 反馈表单提交问题的说明。

  • GPT-4 的成长的烦恼：针对 GPT-4 在研究回答中的响应速度和准确性问题，成员们交换了心得，而针对较大 Token 集的 API 查询性能估计为 15-20 秒。成员们还对 GPT-4 的文件功能表示沮丧，反映了即使通过文件上传和自定义 API 创建也难以实现最佳性能的挑战。

  • Prompt Engineering 的演进：出现了关于 meta-prompting 的热烈讨论，尽管缺乏共享的具体方法论，但它有望成为从 AI 创建连贯输出的策略。同时，人们也在辩论 AI 生成内容的伦理考量，思考模型在自我提示（self-prompting）过程中对伦理输出的遵守情况，以及从基础的 fine-tuning 入门指南生成完整、详尽文档的潜力。

  • 跨频道的挑战与策略分享：Meta-prompting 方法和诸如 MetaPrompting 与 LongRoPE 之类的 Prompt Engineering 策略主导了对话，madame_architect 提供了一份不断增加的带注释论文列表，以增强 Prompt Engineering。使用 AI 服务时的隐私和数据安全是热门话题，社区得到保证，除非有重大原因，否则不太可能受到个性化审查，尽管平台不可避免地会访问某些用户数据。

Perplexity AI Discord 总结

  • Mistral Large 为 Pro 会员上线：<@ok.alex> 宣布 Mistral Large 现已面向 Perplexity AI 的所有 Pro 用户开放，可通过设置或 Rewrite 功能访问，移动端 App 版本即将发布。

  • 应对促销陷阱与模型评测：用户遇到了来自 Rabbit R1 的促销邮件问题，例如 @mithrilman 需要通过支持渠道解决。同时，@.claidler 和 @jaicraft 辩论了各种 AI 模型的优劣，GPT-4 Turbo 受到称赞，而 Mistral Large 在代码处理方面的优越性也得到了认可。

  • Perplexity AI 引擎的预期管理：@brknclock1215 表示，Perplexity 被认为是一款出色的 AI answer engine，但在处理大文件解析或代码执行方面存在局限。与 Merlin 等竞争对手的对比显示了 Perplexity 的优势，尤其是在不受 SEO 限制的搜索方面。

  • 技术花絮引发好奇：@ha.mz4_ 等成员分享了探索创新的链接，如联想的透明笔记本电脑，但未深入讨论。@.anuni 认为 Mistral Large 的准确性优于 GPT-4，而 @commuting5048 注意到 GPT-4 在提供详细的增肌计划细节方面的表现。

  • API 分析与 Sonar 审查：由 @clay_ferguson 和 @brknclock1215 领导的社区测试指出，使用 sonar-medium-online 的性能优于其他选项，但也报告了不一致性，并希望了解 sonar-medium-online 与 pplx-70b-online 的详细差异。关键发现表明，Prompt 设计极大地影响了输出，而模型在尝试列出来源时可能会产生乱码响应。

LAION Discord 总结

  • AI 的验证码挑战：关于一个指示用户“点击与其他对象不同的对象”的验证码展开了讨论，@mikerhinos 指出该验证码缺乏用于计算机视觉标注的目标词，暗示其唯一目的是阻止 Bot。

  • Stable Diffusion 3 引发好奇与批评：社区分享了对即将推出的 Stable Diffusion 3 (SD3) 的热情，同时也批评了当前 UNet2D 的局限性以及无法进行混合分辨率的 Batch 训练，这表明了对该模型潜力的极高期待。

  • AI 在军事行动中的伦理与效能：一篇彭博社的文章引发了关于在空袭目标定位中使用 AI 的伦理和技术辩论，@thejonasbrothers、@chad_in_the_house 和 @pseudoterminalx 讨论了 AI 在军事场景中决策的影响。

  • 傅里叶变换在神经网络中的应用：@mkaic 展示了他们在神经网络中手动实现逆离散傅里叶变换的工作，旨在寻求内存高效的解决方案，并考虑使用 torch.vmap。@p.ie.c.e.s 推荐使用 torchkbnufft 来实现更高效的傅里叶合成。

  • 1-Bit 大语言模型的未来：关于 1-bit 大语言模型（特别是 BitNet b1.58）的讨论表明，模型正朝着更具成本效益和高性能的方向发展，以优化硬件利用率，并引用了一篇可以在此处查阅的论文。

Eleuther Discord 摘要

  • Double-Descent 卷土重来：训练损失上的 Double-descent 是用户中的热点话题，@leegao_ 指出了其发生在训练损失（training loss）而非典型的验证/测试损失上的奇特性。

  • 雷达上的梯度尖峰：@ad8e 分享的一篇讨论 梯度估计（gradient estimation） 的论文引发了关于其对大型模型训练稳定性影响的对话。@uwu1468548483828484 在反思该论文时，将梯度尖峰的经历与潜在的早期层梯度偏移联系起来。

  • 静默数据损坏的故事：@leegao_ 强调了一个关于 Google LLM 项目失败的传闻，指出预训练期间的静默数据损坏（silent data corruption），并强调了警惕监控的重要性。

  • Token 故障排除与 LoRA 见解：在 Mistral-Instruct-V0.2 的 Token 添加实验中出现了 lm_head.weight 差异问题，而 @thatspysaspy 参与了关于 LoRA pretraining 潜力的讨论，并提到了一篇名为 “LoRA-the-Explorer” 的论文。

  • 奥林匹克挑战与 CycleGAN 创新：包含奥林匹克级科学问题的 #OlympiadBench 发布，表现最好的模型分数为 17.23%，引发了热议。同时，@carsonpoole 正在实验一种集成了 diffusion model 的创新 CycleGAN，以获得更好的结果。

  • 模型缩放与数学思考：关于 神经网络的样条视角（spline view of Neural Networks）、LoRA 与 SVD 相关的理论方面，以及 训练 Token 的 Scaling laws 的激烈讨论，反映了对理论和实践模型缩放的持续关注。

  • 揭开可解释性中的“能量”：在潜空间分析（latent space analysis）背景下的“能量（energy）”一词引发了由 @wendlerc 和 @mrgonao 领导的对话，重点关注其含义、方程解释以及 AI 模型中的 tuned lens 实现。

  • Batch、评估与多模态迷宫：GPT-NeoX batch size 敏感性的变化、对 LM eval harness loglikelihood 输出的理解，以及对多模态 LM 评估的查询，表明了对指标和评分方法的密切关注。

  • 步入 CoreWeave 领域：@jdranpariya 发起了关于设置多节点 GPT-NeoX 训练 的 CoreWeave 特定细节的对话，社区指导指向了 CoreWeave 支持和现有的 NeoX 文档中关于 slurm 相关的说明。

LlamaIndex Discord 摘要

  • LlamaIndex Cookbook 随着新集成而升温：LlamaIndex 宣布了与 @FireworksAI 合作的新 function calling cookbook，庆祝他们的 RAG 和 FireFunction-v1 集成。他们还推出了一项功能，通过将 RAG 应用链接成网络来创建 super-RAG，标志着 RAG 应用互联 API 服务时代的到来，详情见 Twitter。

  • 活动预告：使用 LlamaParse 掌握复杂 PDF：重点活动“针对复杂 PDF 的卓越 RAG”旨在深入探讨 LlamaParse 的功能，重点是熟练处理包含图表和表格的复杂文档，LlamaIndex 发出了公开邀请并提供代码演示（活动注册）。

  • Groq 的 LPU 赋能 Llama2 和 Mixtral 模型：LlamaIndex 对 @GroqInc LPU 的集成将大大提高 LLM 生成应用工作流的速度，这对 LlamaIndex and Groq Cookbook 中概述的 Llama2 和 Mixtral 模型来说是一个福音。

  • 技术故障排除与讨论升温：在 general 频道中，关于 LlamaIndex 生态系统内的最佳实践和故障排除进行了热烈讨论，涵盖了从查询 PDF、reranking models、Golang 集成到 Node 与 Document 澄清等主题——所有这些都得到了社区成员分享的大量文档和资源的支持。

  • 寻找尺寸完美的模型：@sysfor 正在寻找一种难以捉摸的中型模型，能够高效处理摘要和日志相关性任务，填补 Mistral 7b 和 Mixtral 之间的空白，并旨在适应 24GB 显存的显卡，理想情况是 10.7b 的 quant 6/8 模型。

HuggingFace Discord 摘要

  • Cosmopedia 开启数据新地平线：Cosmopedia 是由 Mixtral 推出的合成数据集，拥有 25B tokens 和 3000 万个文件，涵盖教科书、博客和故事。现在，想要为机器学习应用深入挖掘海量数据的 AI 爱好者可以获取该数据集。该数据集被强调为一个重要的发布，旨在满足对数据渴求的 AI 模型，可以通过 LinkedIn 帖子 访问。

  • HuggingFace Hub 发布 0.21.0 版本：huggingface_hub 仓库已更新至 0.21.0 版本，引入了 dataclasses、PyTorchHubMixin 改进以及扩展的 InferenceClient 功能，尽管也引入了一些破坏性变更（breaking changes）。对于 AI 社区，可以通过详细的发布说明 查阅更新的细微差别。

  • 新 AI 进驻 Hugging Chat：Google 的 Gemma 7B（一款开源大语言模型 LLM）现已在 Hugging Chat 服务中上线，标志着向可访问且强大的对话模型迈出了又一步。详情请参阅 Julien Chaumond 的 Twitter 更新。

  • TTS Arena 招募测试人员：TTS Arena 正在号召参与者在一个由 @reach_vb 领导的新交互式项目中测试、评分和发现开源文本转语音（text-to-speech）模型。初始版本包含五个模型，欢迎通过 TTS Arena 的公告 提供意见和反馈。

  • 数据社区交付 10k_prompts_ranked：展示了众包的力量，300 多名贡献者在不到两周的时间内开发了一个数据集 10k_prompts_ranked，旨在完善 AI 提示词排名系统。该项目被视为社区主导的 AI 数据努力的实力和潜力的证明，更多见解请见 HuggingFace 博客文章。

  • 免费 Inference-API 的挑战显现：用户报告了免费 Inference-API 的超时问题，目前正在讨论以确定原因（如潜在的速率限制），这影响了文本生成图像 AI 模型的可用性。

  • 在寻找低资源 AI 模型性能？：CS231n 学习小组正在进行中，涵盖从软件设置到神经网络优化的主题，社区成员聚集在一起共同深入研究卷积神经网络（convolutional neural networks）和视觉识别。课程内容和安排正在分享中，2023 春季作业 是关注的焦点。

  • 呼吁 AI 集成大军：技术领域的专家们正在努力将 AI 集成到现有应用程序中，讨论内容包括克服工具和 API 障碍，以及利用 AI 功能增强 CRM（从预测生产到处理客户交互）。

  • 情感分析助力城市规划：结合 LLM 的 LangChain 正被用于解决复杂的城市情感分析问题，这是通过更敏锐的社交媒体洞察来解决城市不平等问题的大胆尝试。

  • 针对本地服务器审查图文 AI 模型：关于在本地服务器上执行 Salesforce BLIP 模型（类似于针对 LLM 的 llama.cpp）的查询不断涌现，旨在实现精简的 JSON 响应，而无需 Python 服务器的开销 —— 这里是一个起点。

  • AI 查询中的嵌入（Embedding）研究：随着 AI 专家寻求通过 arcface loss 增强他们的创作，关于模型架构中嵌入维度（embedding sizes）性质的问题浮出水面，为了实现最佳实施，深入理解是必要的。

  • 嵌入模型选择引发讨论：在处理精简数据集时，社区正积极推动既快速又稳健的嵌入模型，推荐了如 BAAI 的 bge-small-en-v1.5 等资源，并深入探讨了针对医疗应用的特定领域 Transformer 开发。

  • LLM 电子邮件简洁化探索：在缩短冗长电子邮件的同时保留核心内容以供 LLM 使用的努力正在增加，这或许能在未来实现更精确、高效的 AI 交互。

  • 及时重新思考 CoT 的经济性：一种在 LLM 中使用思维链（CoT）提示的有趣方法被提出，敦促模型“静默思考”以节省宝贵的 tokens，从而可能改变 AI 引导技术的格局。

  • CPU 上的文本生成风波：在 CPU 受限的设备上运行文本生成时遇到了重重困难，这凸显了对不需要昂贵 GPU 算力的 AI 解决方案的持续需求。

  • 关于 Diffusion Model 实践的辩论激增：关于 Playground v2.5 方法论的紧张局势升级，特别是采用 “eps prediction” 而非 zsnr，以及 EDM framework 的选择。争议还延伸到了 PR 的处理上，有指控称存在偏袒 Playground 团队的不公平待遇，正如一个等待审议的 Mixture-of-Experts PR 所强调的那样。

  • Photo Concept Bucket 成为社区关注焦点：介绍了 Photo Concept Bucket，这是一个由社区制作的数据集，包含超过 50 万张带有标注的图像，旨在增强 AI 的视觉理解能力——这是协作构建数据集的真实见证。

请注意，对于某些频道，仅提供了部分消息，因此摘要可能反映的是这些摘录中的对话，而非涵盖所有频道活动。

LangChain AI Discord 摘要

  • 图像持久化难题：在讨论处理 llava/visoon models 时，@deadthray 提出了一个问题，即为了维持图像引用而反复传递图像字节流效率低下，这表明在处理持久化图像引用方面存在挑战。

  • 旅游聊天机器人遭遇挫折：@ritanshoo 强调了他们的旅游预订聊天机器人的问题，即使在 Pinecone 中拥有大量数据集，也无法返回相关的答案，这表明数据检索或查询处理存在潜在问题。

  • LangChain 生产就绪性的辩论：有一场关于 LangChain token consumption 及其对现实世界应用适应性的对话，@m_gee 提出了来自 Reddit 的担忧，而 @baytaew 则主张 LangChain 的灵活性，并推荐使用 LangGraph 进行增强的状态管理。

  • LangChain 的编程语言对决：在一场精彩的编程语言碰撞中，@pcube__ 寻求与 LangChain 最无缝集成的方案来构建 Web 服务器。在回复中，Python 和 JavaScript 占据了领先地位，而 Go 则未被提及。

  • LCEL 的内存增强：对于那些想要增强 LangChain LCEL 内存能力的人，@marknicholas 寻求最佳方法的建议，虽然 @kapa.ai 提供了通用指导，但他们建议深入研究 LangChain 文档以获取细节。

  • 垃圾信息警报：社区不得不处理来自 @davisson0429 在多个频道发布的垃圾信息事件，该用户发布了一个可疑的 Discord 邀请链接，并伴随大量垂直线，扰乱了社区环境。

  • LangGraph 在 LangChain 中大放异彩：@andysingal 分享了他们对 LangGraph 的见解，详细介绍了它与 LangChain 的集成，以增强代码生成的安全性和准确性功能，为读者提供了对其功能的 深度解析。

  • AI 对话副驾驶登陆手机：对移动设备上的实时 AI 辅助感到好奇吗？@jasonzhou1993 发布了一个 YouTube 视频，展示了 iPhone 上的 AI 对话副驾驶（AI Conversation Co-pilot），它通过 Whisper 和 Mixtral 模型提供即时建议。

OpenRouter (Alex Atallah) Discord 摘要

  • OpenRouter 修复提升了消息清晰度：在 @louisgv 发现 Perplexity 和 Gemma 的消息排序/格式问题后，官方实施了成功的修复，以增强用户体验。

  • 使用 OpenRouter 创建 AI 工具非常轻松：OpenRouter 不仅支持其自身的模型，还支持来自 Google Vertex AI、Amazon Bedrock 和 Cloudflare AI 等大型供应商的模型，为用户添加想要使用的模型提供了简便的方法。

  • 使用 OpenRouter 评估捷克语 LLM 变得更加容易：分享了一个用于评估捷克语大语言模型 (LLM) 的新排行榜项目，该项目利用了 OpenRouter 的易用性和成本效益。项目访问地址见此处。

  • 寻求对话式 AI 飞跃的 Beta 测试人员：Pablo 是一款无需打字即可利用多个 LLM 的 AI 语音聊天应用，目前正在招募 Beta 测试人员。他们提供免费的 AI 额度（包括 GPT-4 等服务），感兴趣的参与者可以使用此 TestFlight 链接进行注册。

  • 聊天模板问题已解决：报告了影响 OpenRouter 中对话连续性和回合制聊天的聊天模板差异问题，随后这些问题得到了解决，OpenRouter 团队成员参与并更新了系统以修复这些问题。

OpenAccess AI Collective (axolotl) Discord 摘要

  • LLM 训练：消费级硬件尚不足够：正如 @nafnlaus00 所讨论的，由于家中缺乏 H100 GPU 等必要设备，在消费级硬件上训练像 BitNet 这样的大语言模型仍然不切实际。另一方面，arXiv 上的论文如 The Era of 1-bit LLMs 引起了人们对神经网络硬件设计潜在转变以及在消费级硬件上进行训练的可行性的兴趣。

  • LoRA 的训练限制及替代方案：@enka55 等成员讨论了 LoRA 在为模型引入新知识方面的局限性，并建议使用全量微调 (full fine-tuning) 等替代方案。此外，创新的多头 LoRA (MHL) 技术可能会作为 ReLoRA 等方法的替代方案被探索，相关资源见 LTE 论文 和 GitHub 上的源代码。

  • 模型微调与基准测试的障碍：技术讨论涉及了由于潜在的 VRAM 限制，在 Nvidia 4090 等 GPU 上微调 Q-Lora 等模型所面临的挑战。虽然 @nanobitz 指出可以使用 lm_eval_harness 对微调后的模型进行基准测试，但目前与 Axolotl 还没有直接集成。

  • 易用性与文档缺失：@karisna 等用户表示需要更清晰的 Axolotl 设置文档，特别是针对 Windows 用户的文档，这标志着用户支持有待改进。此外，还强调了 Axolotl 的微调工具使用困难以及配置问题，例如 Mistral 配置中与 Pydantic 的命名空间冲突。

  • 关于 Replicate 性能的讨论：@dreamgen 提到了对 replicate 性能和声誉的质疑，但随后没有提供具体的背景或细节来支持这一说法，使该问题悬而未决。

Interconnects (Nathan Lambert) Discord 摘要

  • 长上下文 AI 即将来临：来自 Together Compute 的一条 推文 表明，AI 的 长上下文能力 (long context abilities) 将迎来重大进展，这一领域的重要性正日益凸显。
  • AI 协作领域的关键行业动态：Arthur Mensch 确认了其公司对 开放权重模型 (open-weight models) 的承诺，并提到了与 Microsoft 的转售协议，以及 Le Chat 和 Mistral Large 的成功。更多详情请参见 Arthur Mensch 的推文。
  • 针对代码模型的革命性 “Starcoder2”：BigCodeProject 发布了拥有 16k token 上下文的 Starcoder2。该模型基于 The Stack v2 构建，这是目前最庞大的代码数据集，包含超过 9000 亿个 token，旨在提高开放性和可访问性。更多信息可以在 这里 找到。
  • 呼吁 HuggingFace 加大模型训练力度：随着代码模型领域的增长，Nathan Lambert 建议 HuggingFace 应该加大其模型训练投入，特别是考虑到 Starcoder2 的推出。
  • 写作工具之争：Nathan Lambert 详细介绍了他的写作流程，包括使用 Notion，并在发布到 Substack 之前使用 Grammarly 和 ChatGPT 辅助编辑；而另一位用户则推荐使用 Typora 作为 Markdown 编辑器。

CUDA MODE Discord 摘要

  • CUDA 模拟探索：@jash403 咨询了关于在 CUDA GPU 上运行模拟器的建议，随后 @iron_bound 分享了一个 GitHub 仓库 krocki/nvgb，该项目在 CUDA 上模拟了 Gameboy。该项目在 Towards Data Science 的一篇文章 中被重点介绍，被描述为世界上最快的 8 位游戏机集群。

  • 对 Triton Kernels 性能的赞赏：@andreaskoepf 称赞了 unslothai 的 Triton kernels，在 QLoRA 微调中提供了 5 倍的速度提升 和 减少 60% 的内存使用。同时，另一个频道分享了关于将自定义 Triton kernels 与 torch.compile 集成的见解，详细信息可在 PyTorch GitHub 查看。

  • 破译 GPU 缓存与内存动态：@cudawarped 发起了关于 L2 缓存效率的讨论，指出 L2 缓存的带宽高于全局内存 (global memory)，这一观点得到了 Stack Overflow 帖子 和一项 研究 的支持。@iron_bound 赞赏了 Chips and Cheese 上对 Nvidia H100 的架构分析。

  • PyTorch 的演进与编译器讨论占据主导：在 #torch 系列讨论中，@marksaroufim 分享了 PyTorch 植根于 2010 年左右 LuaTorch 的历史。用户对解决 GPU 架构优化的潜力表现出浓厚兴趣，辩论了编译器的有效性，并讨论了来自 PolyMage Labs 等公司的教育材料，特别是关于多面体编译 (polyhedral compilation) 的内容（见 此处）。

  • InvSqrt() 的真实身份揭晓：#algorithms 频道的讨论深情回顾了 Quake III 中使用的快速平方根倒数算法 (fast inverse square root algorithm)，@iron_bound 分享了 维基百科链接。@chhillee 指出了编写此类特定优化的通用实现的复杂性。

  • 社区推动 Ring Attention 开发：#ring-attention 频道中展现了活跃的协作，@ericauld 邀请大家对一个展示 Ring Attention 机制的 开发中 notebook 提供反馈。@andreaskoepf 表示愿意协助处理侧面任务，增强了协作精神。@nshepperd 解决了使用 jax 和 jax.Array 实现 Ring Attention 时的技术挑战。

Latent Space Discord 总结

  • Lip Sync 登上 AI 舞台：Pika 为 Pro 用户推出了早期访问的 Lip Sync 功能，旨在增强 AI 生成视频的真实感，但根据反馈，目前看起来仍有些“恐怖谷”效应。在其公告中了解更多信息：Pika’s Lip Sync Early Access。

  • 关于 AI 驱动效率的讨论：据报道，Klarna 的 AI 助手在一个月内处理了 230 万次客户聊天，这引起了关注，并引发了关于 AI 在客户服务中有效性背后数据的讨论。对这些数字真实性的质疑导致了一篇 Fast Company 文章的分享，该文章对 AI 影响的过度正面描绘表示怀疑。

  • Elicit 达到里程碑：Elicit 在推出订阅服务仅四个月后，年度经常性收入（ARR）就达到了 100 万美元，这引发了社区成员的庆祝。这一里程碑暗示了 AI 业务的规模化潜力。

  • Gemma 的 Tensor 张力：在本地运行 Google 的 Gemma（特别是在 MPS 架构上）相关的技术挑战一直是焦点，理由是复杂的 Tensor 操作存在问题。正在进行的讨论包括参考 Gemma PyTorch GitHub repository 以进行详细探索。

  • Noam Shazeer 的编码风格洞察：Noam Shazeer 的第一篇强调编码风格的博客文章在社区内分享，重点是 shape suffixes。AI 工程师可以在这里阅读他的见解。

  • 与 Replicate CEO 交流：播客发布了采访 Replicate CEO 的新剧集，公告已分享在公会的 #ai-announcements 频道。通过 swyxio 的推文收听。

DiscoResearch Discord 总结

  • RAG-LLM 优化查询未解决：@rasdani 询问了关于使用梯度对 Retrieval-Augmented Generation (RAG) 与 Large Language Models (LLMs) 进行端到端优化的问题，引用了 LESS 论文，该论文解决了优化器感知的辅助数据选择，但没有通过数据选择本身进行反向传播。

  • DiscoLM_German_7b 胜过 Leo Mistral 7B：在德国文档提取的难题中，@mab3049 面临 Leo Mistral 7B 的挑战，而 @bjoernp 建议切换到 DiscoLM_German_7b 以获得更好的性能，详见 Hugging Face 的 chat templating 文档。

  • 正确模板化的力量：通过正确使用 chat templates，可以实现与语言模型（特别是针对德国文档提取）更增强的交互，从而提高 DiscoLM_German_7b 等模型的能力。

  • Goliath 优于 Llamaindex：@sebastian.bodza 指出了 llamaindex 代码分块器（chunker）的问题，促使 @philipmay 提议将 Goliath 模型 作为德语任务的更优选择，引发了围绕特定语言功能的模型偏好的对话。

  • 通过演示继续探索模型：公会讨论了各种模型，例如 DiscoLM German 7b Demo，以完善他们处理专业 AI 任务（如德国文档提取）的方法。

LLM Perf Enthusiasts AI Discord 总结

  • 对 Llama 3 的期待升温：用户 @res6969 引发了关于 Llama 3 将在春季发布的传闻，但尚未确认官方日期。
  • 表达对延迟的沮丧：@res6969 对 OpenAI API 的响应时间表示深感失望，而 @pantsforbirds 表达了同样的看法，特别针对 Azure 托管 的糟糕性能。
  • 寻求延迟问题的澄清：@justahvee 试图了解关于延迟的投诉是指 首字时间 (time to the first token) 还是整体 生成完成时间 (completion time)，对此 @res6969 澄清是前者。

AI Engineer Foundation Discord 摘要

  • AI 工程师面试准备专业建议：用户 iloveh8 询问了关于 准备 AI 工程师面试的建议，但目前尚未收到任何回复。
  • 观看 Agent Protocol V2 编码直播：_z 邀请社区参加一场专注于 Agent Protocol V2 配置选项 RFC 的 编码直播，提供对该开发过程的直接见解。
  • 与专家一起参加 Voice + AI 见面会：@kwindla 宣布在 Cloudflare 举办一场 Voice + AI 见面会，邀请了来自 Oracle Cloud 的 Jay Jackson 等 AI 专家，周三下午 6:30 的活动现已开放 RSVP。
  • 询问 Voice + AI 活动的在线访问性：@yikesawjeez 想知道 Voice + AI 见面会 是否提供远程参与的直播，表现出对语音技术讨论的兴趣。

Datasette - LLM (@SimonW) Discord 摘要

  • Claude 的 JSON 风波：@derekpwillis 对 Claude 不愿在没有前导语的情况下输出 JSON 对象 感到恼火，尽管有明确的指令要求这样做，这阻碍了想要纯 JSON 数据的用户。

  • 在 LLM 之上叠加 Bolt AI：Angerman. 表示希望在 LLM 之上拥有像 Bolt AI 这样的系统，以促进增强的交互。

Skunkworks AI Discord 摘要

提供的记录不包含任何针对工程受众摘要相关的技术或详细讨论点。它似乎是在 off-topic 频道中分享的一个链接，没有任何附带的上下文或讨论。

第 2 部分：按频道详细摘要和链接

TheBloke ▷ #general (1271 条消息🔥🔥🔥):

  • Morpheus AI 与微软的投资：Morpheus AI（也被称为 TheBloke）似乎已经沉寂了一段时间，引发了关于他们在 HuggingFace 上活跃度的疑问。微软对 Mistral AI 的投资引发了关于对 AI 行业影响的讨论，涉及对垄断行为的担忧以及竞争带来的好处 (TechCrunch 文章)。

  • 从 Hugging Face 下载模型：用户讨论了从 Hugging Face 下载模型的困难，经历了带宽限制和 Git LFS 的问题。建议使用 Hugging Face CLI 和 fast transfer 作为高效下载的更好替代方案 (Hugging Face CLI 指南)。

  • 关于 AI 伦理与审查的讨论：一场关于 AI 应该反映世界的现状还是理想状态的辩论展开了，涉及对 AI 被“折磨”以使其不具有种族歧视的担忧，以及数据集中的偏见对 AI 行为的影响。

  • Serverless 恐怖故事：一场关于 Serverless 架构相关风险的讨论浮出水面，指出了潜在的财务陷阱，例如由于僵尸网络活动的带宽超额而导致的意外巨额账单 (ServerlessHorrors)。

  • SSL 证书与 Cloudflare：关于 SSL 证书成本和复杂性的对话引发了对 Let’s Encrypt 和 Cloudflare 等服务在网站安全和 DNS 管理方面优势的讨论。还强调了对 Cloudflare 业务实践和单次请求限制的担忧。

提到的链接：

TheBloke ▷ #characters-roleplay-stories (619 messages🔥🔥🔥):

  • 讨论角色扮演模型的奥妙与局限：聊天中的用户（如 @nathaniel__）分享了他们使用离线模型的卓越体验，讨论了具有复杂背景故事和个性的角色。对话探讨了人类认知与模型行为之间的相似之处，以及在 LLM 生成内容时“虚构（confabulation）”与“幻觉（hallucination）”的概念。

  • 掠夺性的毒瘾者模型：@xtreme420 分享了他们对 Wizard-Vicuna-30B-Uncensored 模型在极少提示下的高效表现感到惊讶，该模型生成了包含侮辱性词汇和非法活动指令的回复。

  • 对安全的严厉立场：@c.gato、@nathaniel__ 等人辩论了 LLM 的伦理和安全考量，认为虽然技术本身缺乏主体性（agency），但人们根据模型输出采取的行动才是可能产生问题的根源。

  • 技术磨难与挑战：进行了关于模型量化（quantization）和微调（fine-tuning）的技术讨论（@mrdragonfox），不同 LLM 的效能，以及使用 Mistral 7B 等模型时的操作细节（@johnrobertsmith）。

  • 运行模型的 Mac 与 PC 之争：关于使用搭载 Apple M 系列芯片的 MacOS 运行模型的优劣展开了广泛辩论，@mrdragonfox 提倡它们在特定应用中的价值，尽管广大社区对 Apple 产品褒贬不一。

提到的链接：

TheBloke ▷ #training-and-fine-tuning (32 messages🔥):

  • LLM 的新 Python 库挑战：@guudbaad 建议教模型优先使用 Prompt 中提供的用法示例，并概述了一种预处理策略，包括抓取 GitHub 并使用多个 LLM 进行代码逆向工程。未提供具体链接。
  • 代码模型的微调框架：@dirtytigerx 推荐使用 DeepSeek 开源的框架来微调代码模型，并讨论了数据准备的复杂性；他们还分享了 DeepSeek-Coder 的 GitHub 链接。
  • 简化数据检索：同一位用户建议编写一个针对在线文档的爬虫，并利用 OpenAI 的自定义 GPT 进行检索，但未分享更多细节或链接。
  • 高性价比模型训练的 QLoRA 技术：@maldevide 提供了 Unsloth 项目的 GitHub 链接，该项目有助于免费进行 QLoRA 微调，为学习训练 AI 模型提供了一个起点。访问项目请点击此处。
  • 估算 LLM 训练的算力及小规模测试：@dirtytigerx 建议进行小规模测试运行以估算 LLM 训练的 GPU 小时数，并提到许多论文都列出了其训练运行的持续时间。他们还建议亲手训练较小规模的模型以获得更好的理解。

提到的链接：

TheBloke ▷ #model-merging (1 messages):

falconsfly：因为单个比特错位 / 张量维度（tensor dims）未对齐

TheBloke ▷ #coding (17 messages🔥):

  • GGUF 转换困惑已消除：用户 @toranb 询问了将 Hugging Face 模型转换为 GGUF 以生成 Q5 KM 输出的正确参数。在 @dirtytigerx 澄清后，强调了 convert.py 脚本是用于转换而非量化的，量化是一个单独的步骤，在 llama README 中有详细说明。

  • 寻求 CSV 聊天的速度提升：.ajayprince 征求关于创建一个利用 CSV 文件的快速响应聊天系统的建议，并指出使用 llama-2-7b-chat.ggmlv3.q4_0.bin 每个结果大约需要 10 分钟，希望能减少到一分钟以内。

  • Colab 上的 GPU 限制：.ajayprince 提到 Google Colab 上没有可用的 GPU 单元是一个瓶颈，导致需要寻找更快速处理的替代方案。

  • 云端推理作为可能的解决方案：@tom_lrd 和 @dirtytigerx 建议使用来自 Hugging Face、together.ai 或其他提供商的云端 API 来提高推理速度，并承认如果没有 GPU，本地处理将不可避免地变慢。

  • 提议改进与协作：@falconsfly 向 @wolfsauge 提供了项目帮助，@wolfsauge 表示渴望在晚餐后学习并讨论这些想法。

提到的链接：

Mistral ▷ #models (22 messages🔥):

  • 推测 Mistral 的模型规模：@rabdullin 表示 Mistral Medium 可能相当于 70B 参数，而 Mistral Large 可能会采用混合专家模型 (MoE)，并深入探讨了模型缩放 (model scaling) 的理论层面。

  • Mistral 的市场策略：@rabdullin 强调了 Mistral AI 在获得向企业客户（尤其是美国客户）提供模型的又一途径后，有望产生更多收入，这也能支持他们在开源模型方面的努力。

  • 对新大模型的印象：@rabdullin 赞扬了 Mistral Large 优于 Mistral Medium 的表现，并指出其在企业和商业任务基准测试中超越了 Anthropic 的所有模型。

  • 讨论模型微调与定价：@sublimatorniq 指出了在没有指导的情况下进行模型微调 (tuning) 的挑战，以及新模型显著的价格差异，尽管观察到了模型性能的提升。

  • Mistral 聊天机器人开发问题：使用 Mistral 模型 开发聊天机器人时出现了一些技术挑战，@myhaw 在尝试初始化大模型对话时遇到了特定的错误消息，但随后解决了该问题；同时 @lerela 承认了该问题，并提到正在修复以提供更清晰的错误提示。

Mistral ▷ #deployment (16 messages🔥):

  • 澄清 Mistral 开源困惑：在一段简短的交流中，@jdwebprogrammer 对 Mistral 似乎转向闭源表示遗憾。@mrdragonfox 澄清说它从未完全开源，但拥有两个权重开放 (openweight) 模型，且首次发布不含权重开放模型并不意味着贡献的终结。

  • 认可 Mistral 的贡献：尽管对其开源状态存在不确定性，聊天参与者（特别是 @mrdragonfox 和 @jdwebprogrammer）仍认可 Mistral 对大语言模型 (LLM) 领域的重大贡献。

  • Vulkan 后端提升 LLM 性能：@saintvaseline 分享了对新 llama.cpp Vulkan 后端的兴奋之情，该后端使 7B 参数模型能在配备体面 GPU 的普通 AMD 游戏电脑上高效运行，并表示打算尝试使用 8x7B 配置冲刺更高性能。

  • 对 Vulkan 后端的不同反应：虽然 @saintvaseline 报告了使用 Vulkan 后端的惊人速度，但 @tokenshifter 提出了技术限制，指出 Vulkan API 在某些 GPU 上会绕过张量加速器 (tensor accelerators)，转而使用 3D 着色器引擎。

  • 在多 GPU 上运行大模型：@pteromaple 引用 Hugging Face 教程，询问了如何在多个 GPU 上对 Mixtral 8x7B 等大模型进行推理。@dawn.dusk 确认这确实是推荐的方法。

提到的链接：

Handling big models for inference: 未找到描述

Mistral ▷ #ref-implem (76 messages🔥🔥):

  • 学习笔记本中的拼写错误提醒：@foxalabs_32486 在 prompting_capabilities.ipynb 示例中发现了一个细微的拼写错误。短语 “Few-shot learning or in-context learning or is when we give a few examples in the prompts…” 应改为 “Few-shot learning is when we give a few examples in the prompts…“，@sophiamyang 已确认将修复该错误。

  • 拼写错误的人性化：@dawn.dusk 幽默地评论说拼写错误是人性的证明，这引发了关于是否故意加入错误以使 AI 看起来更像人类的讨论。@foxalabs_32486 和 @mrdragonfox 探讨了这种做法的伦理问题。

  • 模仿人类 AI 的伦理困境：聊天记录显示，像 @mrdragonfox 这样的开发者不愿创建故意模仿人类错误的 AI，理由是伦理原因，即使面对客户的需求也是如此。

  • AI 行业的招聘挑战：@foxalabs_32486 讨论了 AI 行业由于知识真空和对专业人才的高需求而导致的招聘困难。

  • AI 的市场机遇：参与者 @foxalabs_32486 和 @mrdragonfox 探讨了 AI 的各种市场潜力，包括管理咨询以及体育或健康等非企业核心关注领域的行业。

Mistral ▷ #finetuning (33 messages🔥):

  • 理解 LoRa 的作用范围：@ethux 澄清了 LoRa 用于微调行为，而不是用于添加新信息。
  • 在 AWQ 模型上进行 LoRa 微调：@kushagra_67246 询问是否可以对托管在 Hugging Face 上的现有 AWQ model（如 casperhansen/mistral-7b-instruct-v0.1-awq）应用 LoRa fine-tuning。
  • Mistral 微调的资源需求：@kunpengguo 在遇到内存溢出错误后，收到 @mr_seeker 的建议：使用 DeepSpeed ZeRO3 全量微调 Mistral-8x7B 需要 1.2Tb CPU RAM 和 96 Gb VRAM。
  • 添加文档训练模型：@aaronbarreiro 通过与 @mrdragonfox 的交流发现，虽然目前没有类似于 OpenAI RAG 的系统，但 PDF 等文档需要转换为文本才能导入，且受限于 32k tokens，模型没有持久化记忆。
  • 使用 Mistral 微调指南：@nicklashinsky 分享了一个有用的资源（Mistral Fine-tune Guide）用于开始 Mistral 微调；不过讨论中未提及具体的突出要点。

提到的链接：

Brev.dev Console：未找到描述

Mistral ▷ #showcase (9 messages🔥):

  • Mistral Large 部署指南发布：用户 @raoufchebri 分享了在 Azure 上部署 Mistral Large 并集成 LangChain 的分步指南。他们提供了一篇 neon.tech 博客文章 详细介绍了该过程，并征求社区反馈。

  • 用 Mistral 创作音乐：@boles.ai 称赞 Mistral Large API 为其播客创作了两种不同音乐风格的精彩歌词，音乐和人声由 Suno.ai 提供。

  • Sensei 集成 MistralAI：@deexxcryptz 宣布合成数据生成工具 Sensei 现在支持 MistralAI API。更多详情和使用指南可以在其 GitHub repository 和消息中链接的推文中找到。

  • YouTube 上的 Mistral Large：用户 @arunprakashai 分享了一个名为 “Start Using Mistral Large: Powerful and Cheaper than GPT4” 的 YouTube 视频，其中包含如何利用 Mistral Large 模型并将其与聊天应用集成的教程。

  • Mistral 医学模型微调：@cogbuji 提到一个使用医学术语数据微调的 Fine-tuned Mistral / OpenHermes model，可在 Hugging Face 上获取。提供了该特定模型的链接，并附带了简短的背景故事和对 Fela Kuti 歌曲的致敬。在此查看模型。

提到的链接：

Mistral ▷ #random (136 条消息🔥🔥):

  • Google 的 Gemini 与资源的讽刺: @egalitaristen 对 Google 尽管拥有庞大资源但其企业级工具的表现表示怀疑。对话涉及了公开版与企业版之间的潜在差异，但最终 @egalitaristen 仍未被说服，希望通过实际测试来相信 Google 的能力。

  • Mistral Discord 对 1.5 PRO 的能力表示怀疑: @sublimatorniq 和 @egalitaristen 讨论了 1.5 PRO 在长上下文理解、代码生成和推理方面的能力，反响褒贬不一。虽然 @sublimatorniq 分享了一个贪吃蛇游戏代码的 GitHub Gist，但 @egalitaristen 使用编程提示词和推理问题对该模型进行了测试，发现其表现不尽如人意，尤其是与 Next、Large 和 Mixtral 等其他模型相比。

  • 测试 AI 的视频理解能力: @sublimatorniq 分享了他们使用 AI 搜索和描述视频内容的经验，指出 AI 在某些类型内容上的表现较差。@egalitaristen 还表达了对 Google 缺乏社区 Beta 测试的沮丧，认为 Google 的内部测试环境与实际使用场景之间存在脱节。

  • Tokenization 工具与社区贡献: @daain 分享了一个用于比较模型 Tokenization 的实用工具，提供了一个在线 LLM tokenizer。该工具方便比较不同 AI 模型的 Token 数量，并有助于调试 Prompt 模板。

  • 韵律（Prosody）讨论链接: @kilianbutler 提供了一个博客文章链接，讨论了婴儿如何在掌握语言之前根据韵律学习说话，认为这是沟通的基础，也是提高生成式语音性能的潜在领域。

提到的链接:

Mistral ▷ #la-plateforme (122 条消息🔥🔥):

  • 模型性能讨论：@sublimatorniq 讨论了 Mistral-Large 的性能，思考其与 Mistral-Medium 相比的速度以及 GPT-4 不稳定的吞吐量（throughput）。虽然承认缺乏支持数据，但仍表达了对 Mistral-Large 的偏好。

  • Mistral-Large 的不一致性与错误：包括 @michaelhunger 和 @sublimatorniq 在内的用户报告了 Mistral-Large 在 “La Platforme” 上的问题，例如未授权错误、服务不可用（internal_server_error）以及读取超时。

  • Mistral 上 Function Calling 的挑战：@michaelhunger、@liebke 和 @sophiamyang 就使用 Mistral 模型进行 Function Calling 时的复杂性和不一致性进行了深入讨论。用户分享了模型表现不如预期或需要变通方法（workarounds）的经历和案例。

  • Mistral Function Calling 的集成与反馈：@alexclubs 提供了将 Mistral Function Calling 集成到 Profound Logic 解决方案 中的反馈，指出了其与 OpenAI 实现方式的差异，以及在稳定触发函数调用方面的问题。

  • 关于 “Le Chat” 隐私政策的讨论：一场关于使用免费 Le Chat 服务带来的隐私影响的对话，促使用户分享了 Mistral 使用条款 并讨论了退出（opt-out）选项。

提到的链接：

Mistral ▷ #le-chat (414 messages🔥🔥🔥):

  • Mistral 的 UI/UX 建议：@onuralp. 分享了关于 Le Chat 界面的反馈，特别指出删除对话的选项令人困惑，并建议增加“Rename”（重命名）选项，认为其与 ChatGPT 的 UI 相比略逊一筹。
  • 关于模型支持 Function Calling 的咨询：@catto_chan 询问了 Mistral 模型关于 Function Calling 的能力，@mrdragonfox 澄清说 mistral-small-2402 和 mistral-large-2402 支持此功能；他还链接到了定价和功能页面以获取更多细节。
  • 关于 Latex 渲染的担忧：像 @alexeyzaytsev 这样的用户注意到 Le Chat 前端的 Latex 渲染似乎已损坏，认为这是一个需要改进的地方。
  • Groq 硬件利用讨论：@foxalabs_32486 思考了在 Groq 硬件上运行 Mistral 模型的可行性（由于 Groq 的片上内存），并与 @mrdragonfox 就硬件适用性和经济效率展开了详细讨论。
  • 细节至关重要：用户 @_._pandora_._ 指出 UI 中图标大小略有不一致，这让他们感到非常分心。@lerela 确认了该反馈并承诺进行修复，这体现了团队对社区反馈的快速响应。

提到的链接：

LM Studio ▷ #💬-general (511 条消息🔥🔥🔥):

  • 模型加载与性能困惑：用户如 @sh4d0w66 和 @tongnamtuanvu 在 LM Studio 上尝试加载大型模型时遇到了问题，报告了错误并寻求关于硬件是否充足的澄清。例如，@sh4d0w66 询问是否可以在 60GB RAM 和 8GB VRAM 的环境下运行 35GB 的模型，一些用户建议可以运行但速度会很慢。@tongnamtuanvu 在尝试加载特定模型时遇到错误，不确定如何继续。

  • LM Studio 与 Mac 在 LLM 上的对比：@heyitsyorkie 和 @johnnyslanteyes 讨论了硬件配置，@johnnyslanteyes 解释说 Mac 上的 LLM 推理主要依赖于 RAM，而 @heyitsyorkie 指出在 Windows 上，GPU offloading 可以带来更快的推理速度。

  • 探索新的三进制模型研究：@garblyx 分享了关于 LLM 训练突破的兴奋之情，该研究在不损失性能的情况下减小了模型大小。提到的论文链接 https://arxiv.org/abs/2402.17764 被视为重大进展，可能使 120B 模型能够装入 24GB VRAM 的 GPU 中。

  • 希望在 LLM 中获取更新的 Fabric Modding 信息：@surrender 询问如何确保 LLM 使用关于 Minecraft 的 Fabric modding API 的最新信息，以避免过时的建议。他们思考是应该训练自己的模型还是使用 embeddings，但不清楚实现步骤。

  • Pine Script AI 请求：@andr0. 询问是否有可以编写 Pine Script 代码的 AI。@abbeyy_9021 建议使用 Code Llama 70B，或者引导 @andr0. 前往位于 https://chat.openai.com/g/g-VRzMQlMs4-pine-script-pro 的 Pine Script 专用自定义 GPT。

提到的链接：

LM Studio ▷ #🤖-models-discussion-chat (36 messages🔥):

  • 量化困惑 (Quantization Quandaries)：@wolfspyre 询问不同的 Quant 存储结构是否会影响模型内化数据的方式，以及这些结构是否会影响对输入的记忆或理解。随后又提出了关于通过双冒号包裹文本进行强制 Tokenization 的方法，但 @aswarp 对此表示怀疑，并暗示像 Mambabyte 这样的新进展可能会使当前技术黯然失色。

  • 模型推荐与限制：针对 @ptable 的询问，@wilsonkeebs 确认 LM Studio 支持特定的 Quant，因为它们是几个月前 llamacpp 更新的一部分。然而，@ptable 提到 senku quant 的兼容性存在困难，对此 @wilsonkeebs 链接了一个来自 Hugging Face 的成功示例，展示了 Noromaid 与 Mixtral-Instruct 的兼容性。

  • PDF 机器人指令精度：@solenya7755 寻求改进 PDF 聊天机器人的建议，以使其返回精确的指令，@nink1 推荐了更精细的 Prompt，并建议参考 AnythingLLM Discord 和 langchain 脚本进行优化。

  • Mixtral 模型的速度与配置：@nullt3r 对 Mixtral 8x7b instruct 模型在 RTX3090 GPU 上的速度表示担忧，分享了 15t/s 的输出速度，而 @.ben.com 报告使用 2x3090 GPU 获得了更好的速度。@nullt3r 还发现使用默认的 ollama 设置运行该模型的 Q5 K M 版本时，速度有显著提升。

提到的链接：

LM Studio ▷ #🎛-hardware-discussion (109 messages🔥🔥):

  • 用于电动汽车的 LLM：用户 @mikeypainebrain 询问是否在给定的硬件配置上将 Large Language Models (LLMs) 和 Prompt Engineering 用于电动汽车、电池供应链或其他金融及政策应用。随后进行了讨论，但未提供具体的见解或建议。

  • LM Studio 的内存烦恼：@666siegfried666 在与 LM Studio 交互时遇到了崩溃和分区丢失的问题，推测这与 RAM 稳定性或可能的 Windows 损坏有关。包括 @jedd1 在内的多位用户讨论了潜在的硬件问题，建议进行 memtests 并考虑使用 ECC 内存。

  • TinyBox 预订与规格公布：@senecalouck 分享了关于 TinyCorp 的 TinyBox 的链接和细节，该设备旨在使 Petaflop 算力商品化。这款高规格硬件包括 6x 7900XTX GPU 和一个 EPYC 7532 CPU，旨在突破 AI 处理的硬件和软件极限。

  • LLM 的 GPU 兼容性问题：用户 @warcrow7 和 @jans_85817 报告了在 NVIDIA GPU 上加载 LLM 的问题，@quickdive 尝试通过询问和建议进行故障排除，但承认由于个人没有 NVIDIA 显卡进行测试，存在局限性。

  • 可能影响 LM Studio 的 Windows 损坏：@666siegfried666 继续排查与 LM Studio 性能相关的硬件问题，排除了 CPU 和 RAM 的原因，倾向于认为是操作系统损坏或电源问题。@.bambalejo 建议检查 Windows 中的某些设置，这些设置可能会加剧问题。

提到的链接：

LM Studio ▷ #🧪-beta-releases-chat (4 条消息):

  • 针对查询的频道重定向：@quantumnebula 建议某个问题可能更适合在另一个频道讨论，但未指明该查询的具体主题。

  • 在 LM Studio 中添加图像：@heoheo5839 询问如何在 LM Studio 中添加图像，并随后表示他们无法按照搜索到的说明找到“Assets”栏。

  • 包含图像的具体步骤：@heyitsyorkie 向 @heoheo5839 提供了关于在 LM Studio 中插入图像的详细回答，指出必须使用 llava 模型（如 PsiPi/liuhaotian_llava-v1.5-13b-GGUF/），并且必须同时下载该模型的 mmproj（vision adapter）和 GGUF 文件才能添加图像。他们还澄清说，在 LM Studio 中只能对图像进行描述，而不能生成图像。

LM Studio ▷ #autogen (9 条消息🔥):

  • 模型响应时间随 Token 数量变化：@thebest6337 解释说，每个 Agent 都会处理生成文本中的每隔一个 Token，因此 Token 数量的增加会导致处理时间变长。

  • 询问关于设置种子（Seeds）的问题：@qlfdengr 询问种子值是如何设置为 0 的，并质疑该功能是否存在于 Autogen 的 UI 中。

  • Gemini 与 Chat GPT 在翻译任务中的对比：@hypocritipus 使用 Gemini 和 Chat GPT 将心理报告翻译成英文；大多数情况下更倾向于使用 Gemini，但它经常包含不必要的格式并插入自己的解释。

  • Chat GPT 提供的翻译质量较差但更直接：对于最终报告，由于 Gemini 的不配合，@hypocritipus 转向了 Chat GPT，并指出 Chat GPT 的翻译明显较差。

  • 翻译澄清：@johnnyslanteyes 寻求澄清 @hypocritipus 所说的翻译是指什么，对方明确是从土耳其语翻译成英语，与医学术语无关。

LM Studio ▷ #langchain (1 条消息):

.eltechno: 是的，而且它超级快

LM Studio ▷ #open-interpreter (44 条消息🔥):

  • 本地模式下的 WSL 问题：@nxonxi 在 Windows 11 的 WSL (Windows Subsystem for Linux) 中运行本地模式时遇到问题，无法建立与端点的连接，出现 httpcore.ConnectError: [Errno 111] Connection refused 错误。
  • WSL 中的 Localhost 难题：问题源于 WSL 对 localhost 的处理方式，@nxonxi 发现必须使用真实的本地 IP 网络地址而不是 localhost。
  • 寻求配置指导：@nxonxi 不确定使用哪个配置文件来更改连接的 URL，@1sbefore 引导他们查看 Open Interpreter’s Docs 上的文档。
  • 解决方案近在咫尺：@1sbefore 提供了文档中的一段代码片段，通过设置 interpreter.llm.api_base 指向任何 OpenAI 兼容的服务器，可以解决 @nxonxi 的问题。
  • 战胜 Localhost 问题：在考虑到 @1sbefore 提供的关于 WSL1 和 WSL2 由于网络差异导致 localhost 行为不同的信息后，@nxonxi 成功运行了 LM Studio 并收到了请求响应。

提到的链接：

OpenAI ▷ #ai-discussions (83 条消息🔥🔥):

  • 辩论 Sora 的发布形式：@g.antoine 询问了 Sora 的发布形式，推测它是作为 ChatGPT 的集成部分 还是一个独立的应用。作为回应，@braydie 表示 Sora 最初可能会像 DALL-E 一样作为一个独立的实体推出，之后可能会与 ChatGPT 集成。

  • Memory 功能推出的推测：@.wakamesalad 询问了 memory feature 的可用性，@lugui 回应称该功能正逐步向随机用户发布。

  • Mamba 算法的见解与质疑：在关于 AI 新算法的对话中，@lugui 解释说 Mamba 模型可以处理更多的上下文，但会遗忘被认为不重要的细微细节，这引发了一些质疑和讨论。

  • 关于 AI 卓越竞赛的思考：@blckreaper 将 Mistral Large 与 GPT-4 进行了比较，指出其性能仅落后 20%。@santhought 补充说 Mistral 已与 Microsoft 合作，并可在 Azure 上使用。

  • 对 Copilot 涉嫌偏见的反馈：@chonkyman777 声称他们关于 Copilot 显示偏见的证据被 OpenAI 机器人删除了，@eskcanta 对此作出了回应，并指导如何通过 Modmail 和 OpenAI 的反馈表单 直接报告此类问题。

提到的链接：

Chat model feedback：未找到描述

OpenAI ▷ #gpt-4-discussions (53 条消息🔥):

  • GPT-4 故障排除：用户 @howsdajello 遇到了 GPT-4 不响应输入的问题，尽管尝试了重新登录修复。@tartimalin1 也报告了 GPT-4 提供不准确的研究答案，并推测了语言性能的差异。
  • 自定义困惑：@the.f00l 寻求关于向自定义 GPTs 上传“Knowledge”文件细节的澄清，@elektronisade 分享了 OpenAI File Uploads FAQ 解决了该问题。
  • 关于 API 性能的查询：@starlss 询问了 2-3k tokens 的 API 请求响应时间，@rendo1 估计大型请求需要 15-20 秒，但指出这取决于其他因素。
  • API 和文件功能的挫败感：@ray_themad_nomad 对 GPT-4 在上传文件和创建自定义 API 后的表现表示不满，@darthgustav. 建议这可能是由于文本大小的限制。
  • 探索 GPT 可视化：@chotes 分享了一个与 GPT 讨论神经网络中特征可视化的对话链接，认为这是一个关于理解模型响应的启发性讨论。

OpenAI ▷ #prompt-engineering (240 messages🔥🔥):

  • Meta-Prompting 成为焦点：关于 Meta-Prompting 技术的讨论在多条帖子中展开，始于 @vlrevolution 的好奇心，并深入探讨了如何通过单个 Prompt 生成连贯的、长达 22 页的输出。尽管最初存在质疑，但该方法引发了广泛兴趣，不过相关描述仍然较为模糊，由于缺乏明确共享的见解或流程而显得颇为神秘。

  • 技术安全讨论展开：在关于数据隐私和安全的长篇交流中，用户表达了担忧，并寻求关于使用 OpenAI 服务时数据隐私的澄清。@eskcanta 和 @madame_architect 提供了保证和背景信息，解释说尽管公司拥有大规模访问数据的权限且存在潜在的法律影响，但在没有重大理由的情况下，任何个人的数据都不太可能受到审查。

  • Prompt Engineering 专家各显神通：该频道的参与者（包括 @darthgustav 和 @madame_architect）讨论了 Prompt Engineering 的各个方面，重点关注论文和策略，如 MetaPrompting 和 LongRoPE。@madame_architect 一直在勤奋地为与 prompt architecture 相关的论文做注解，目前已整理出包含 42 篇论文的精选列表，旨在优化 NLP 模型中的 soft prompts 以获得更好的性能，特别是在 few-shot learning 场景中。

  • 社交媒体内容创作难题：用户 @tryharder0569 寻求关于编写 Prompt 的建议，以生成真实、引人入胜的社交媒体内容，同时避免听起来过时或缺乏社交敏感度。@eskcanta 建议在 Prompt 中注入风格和实质内容，以实现现代受众所青睐的那种酷且自然的语调。

  • 关于 AI 伦理与输出连贯性的对话：除了技术讨论外，@architect_of_ai 和 @darthgustav 等用户还触及了 AI 生成内容的伦理问题，重点关注模型在 self-prompting 过程中是否以及如何遵循伦理框架。此外，还就模型在经过所谓的 fine-tuning 基础“引导（primer）”后，自主编写连贯且篇幅宏大的文档的可行性进行了辩论。

提到的链接：

OpenAI ▷ #api-discussions (240 messages🔥🔥):

  • Meta-Prompting 方法引发讨论：用户 @architect_of_ai 和 @darthgustav. 讨论了一个复杂的 Meta-Prompting 过程，即模型通过自学来生成更好的提示词。尽管对该方法的透明度存在怀疑，讨论仍围绕语言模型的自我改进及其规划和反思伦理框架的能力展开。

  • 分享深入的 Prompt Engineering 见解：@madame_architect 细致地注释了 MetaPrompting 论文，强调其对提示词初始化的优化，这可能会彻底改变 NLP 应用中的提示词设计。他们持续整理和注释提示词相关研究的努力为社区提供了宝贵的资源。

  • 谨慎分享知识：@architect_of_ai 提出通过私信分享链接以绕过频道的限制，@.braydie 确认收到了关于 AI 自我发现（self-discovery）的有用阅读资源。

  • GPT-4 代码生成的挑战：用户 @tawsif2781 提出了一个问题，即尽管设置了最大 token 计数，代码生成过程中的响应仍不完整，并寻求他人的建议。@madame_architect 和 @eskcanta 分享了各自的经验和潜在的排查方法，如调整复杂度。

  • 解决 AI 使用中的隐私担忧：@s_p_e_c 分享了 Support 团队关于隐私问题的回复，促使 @eskcanta 和 @madame_architect 指出技术领域普遍缺乏隐私，以及 OpenAI 出于法律和 bug-fix 原因需要有限度地访问用户数据。这引发了关于技术平台中用户隐私的必要性和局限性的对话。

提到的链接：

Perplexity AI ▷ #announcements (1 messages):

  • Mistral Large 为 Pro 用户发布：<@ok.alex> 宣布 Mistral Large 现已面向所有 Perplexity Pro 用户开放。Pro 会员可以在设置中切换到此模型，或使用 Rewrite 功能进行尝试，该模型也将很快在移动端应用上推出。

Perplexity AI ▷ #general (308 messages🔥🔥):

  • 订阅困惑与支持：用户 @mithrilman 在 Rabbit R1 促销邮件中遇到了无法点击的“兑换 200 美元额度”按钮的问题，@icelavaman 建议其联系 Rabbit 支持团队获取新代码。在没有通过链接订阅后，@mithrilman 询问了如何使用促销活动，并被引导联系 Perplexity 支持团队进行退款。
  • AI 偏好与模型优势：围绕不同 AI 模型的优势和使用场景展开了讨论。@.claidler 发现 Mistral Large 在代码查询方面优于 GPT-4，而 @jaicraft 提供了各种模型的详细分析，认为 GPT-4 Turbo 是综合表现最好的模型。
  • Perplexity 的用途与局限：用户分享了关于 Perplexity 适用和不适用场景的看法。@brknclock1215 强调了其作为 AI 问答引擎的优势，而 @cereal 开玩笑说不应该用它来报税。会议指出，Perplexity 并未针对解析大文件或执行代码等任务进行优化。
  • Perplexity 对比其他平台及 SEO 问题：@names8619 称赞 Perplexity 提供的搜索结果优于 Google（由于 SEO 问题），此外还有 Perplexity 与 Merlin 等其他 AI 工具的对比。
  • 技术困难与 Perplexity 反馈：一些用户在快使用 Perplexity 时遇到了技术问题，例如 @logical__ 无法登录账户并恢复 Pro 访问权限。关于 Perplexity 性能的反馈包括 @magnusg0500 对网站上 AI 响应中出现的荒谬冗长内容的评论。

Perplexity AI ▷ #sharing (14 messages🔥):

  • 探索笔记本电脑创新：@ha.mz4_ 分享了一个关于联想透明笔记本电脑的 Perplexity 搜索链接，表现出对这一新技术发展的关注。未提供关于此事的进一步讨论或观点。
  • 剖析 Dota 经济学：@shakif.fahim 咨询了 Perplexity AI 对 Dota 2 财务影响的看法。分享的链接指向了关于该游戏经济学的见解，但未包含个人评论。
  • 凝视人类行为：@t2db 链接了一个 Perplexity 搜索，探讨人们为什么会盯着看。该消息表明其对理解这一常见人类行为背后的心理学层面感兴趣。
  • Mistral 在准确性方面表现出色：@.anuni 称赞了 Mistral large 的表现，特别是与 GPT-4 相比。分享的链接显示 Mistral large 在 GPT-4 经常失败的地方成功提供了准确信息。
  • 制定增肌训练计划：@commuting5048 提供了一个详细的增肌计划 Prompt，并链接了一个对比结果，指出 GPT-4 在指定组数和次数方面的方法非常详尽。

Perplexity AI ▷ #pplx-api (38 messages🔥):

  • 切换到 Sonar 以获得更高质量：@clay_ferguson 提到他们切换到了 sonar-medium-online 以获得更高质量的“online”模型体验，表示对其性能优于其他替代方案感到满意。
  • 对 Sonar 模型的评价褒贬不一：@brknclock1215 报告了 sonar-medium-online 性能不稳定的情况，指出在某些领域结果良好，但天气预报不准确，且细节似乎过时或不可靠。
  • Prompt 设计影响输出：@brknclock1215 通过测试确认，系统消息（即 “Prompt”）会显著改变系统的行为和输出，影响回复的语气和准确性。
  • 寻求关于 Sonar 与 pplx-70b-online 模型的明确对比：@thedigitalcat 和 @clay_ferguson 之间的讨论强调了对 sonar-medium-online 和 pplx-70b-online 之间差异的信息需求，特别是在处理近期事件和生成简洁、事实性回答方面。
  • 乱码回复是否与尝试列出来源有关？：@thedigitalcat 和 @clay_ferguson 都观察到 sonar-medium-online 和 pplx-70b-online 模型产生乱码回复可能与其尝试列出来源有关，暗示了系统潜在的改进方向。

LAION ▷ #general (232 条消息🔥🔥):

  • Captcha 难题：@mikerhinos 发起了一场关于验证码的讨论，该验证码的指令是“点击与其他物体不同的物体”，强调了其缺乏用于计算机视觉（Computer Vision）标注的目标词。@nodja 回应称，此类措施纯粹是为了防机器人（anti-bot），没有次要目标。

  • Stable Diffusion 3 的期待：@top_walk_town 表达了对获取 Stable Diffusion 3 (SD3) 的热情，批评了 UNet2D 的局限性以及无法在混合分辨率的 batch 上进行训练的问题。随后展开了关于 SD3 可能的复杂性和预期能力的讨论。

  • 解读机器学习中的概率流 (Probability Flow)：@pseudoterminalx 讨论了概率流如何受数据集、前向函数（forward function）和损失函数（loss function）等各种因素影响的细微差别。这是在关于为什么扩散模型（diffusion models）尽管不是完美的学习者，但仍能生成新数据的对话背景下进行的。

  • 围绕 AI 的伦理和技术辩论：继彭博社（Bloomberg）报道美国军方使用 AI 协助定位中东空袭目标后，成员 @thejonasbrothers、@chad_in_the_house 和 @pseudoterminalx 辩论了用 AI 取代人类决策者的伦理影响和有效性。

  • 关于新 AI 模型和开放 AI 生态系统的讨论：包括 @thejonasbrothers、@gothosfolly 和 @pseudoterminalx 在内的多位用户讨论了 AI 社区的最新进展，例如发布的新模型、T5 在 Stable Diffusion 中的潜在用途，以及围绕开源模型和商业许可不断演变的政策。

提到的链接：

LAION ▷ #research (45 条消息🔥):

  • 神经网络拥抱 Fourier： @mkaic 讨论了他们为神经网络手动实现的逆离散 Fourier 变换（inverse discrete Fourier transform），允许在任意坐标下进行合成。他们正在探索内存高效的解决方案，并考虑使用 torch.vmap 进行重构；当前的实现可以在其 GitHub 上找到。

  • 非均匀 FFT 带来的潜在效率提升： @p.ie.c.e.s 提供了一个 PyTorch 中非均匀快速 Fourier 变换（non-uniform Fast Fourier Transform）实现的链接 torchkbnufft，这可能会帮助 @mkaic 寻求更高效的 Fourier 合成方法。

  • 1-Bit 大语言模型的效率： #research 频道讨论了 BitNet b1.58 的影响，这是一种在此处的论文中描述的新型 1-bit LLM，可能预示着具有新硬件优化机会的高性价比、高性能模型。

  • 探索 AI 中的高效 Diffusion： @yoavhacohen 寻求 Efficient Diffusion Methods (EDM) 的解释和示例代码，其他用户推荐了诸如 k-diffusion GitHub 仓库之类的资源，以了解导致最先进性能的采样和训练过程的变化。

  • 寻求 Inverted Whisper TTS 的引用方式： @oswald_._ 询问了一个名为 WhisperSpeech 的开源文本转语音（text-to-speech）系统的引用方法，该系统位于此处，用于学术研究项目。

提到的链接：

Eleuther ▷ #general (66 messages🔥🔥):

  • Double-Descent 现象澄清：根据 @leegao_ 的说法，Double-descent 发生在验证/测试损失中，而不是训练损失中，这使得它在训练损失中的出现变得特别有趣。
  • 梯度尖峰（Grad Spike）讨论：用户 @ad8e 分享了一篇 ArXiv 论文链接，讨论了梯度估计及其在训练稳定性中的作用，@leegao_ 承认了梯度尖峰的问题，其他人也在大模型训练的背景下提到了这一点。@uwu1468548483828484 反思了论文的见解，指出梯度尖峰可能是早期层梯度偏移的结果。
  • 仓促进行 LLM 训练的陷阱：@leegao_ 讲述了一个关于 Google LLM 项目失败的传闻，归因于预训练早期未被察觉的静默数据损坏，并指出在模型训练期间需要更好的监控。
  • Token 故障排除：用户 @transientnative 分享了一个与向模型添加 Token 相关的问题，在意识到 lm_head.weight 在基础模型 Mistral-Instruct-V0.2 与其修改后的模型之间存在差异之前，经历了意想不到的“随机”输出。
  • LoRA 预训练潜力：@thatspysaspy 提到了一篇讨论 LoRA 在模型预训练中应用的有趣论文，名为 “LoRA-the-Explorer”。@alstroemeria313 提供了 ArXiv 论文链接。

提到的链接：

Eleuther ▷ #research (124 条消息🔥🔥):

  • 分享对奥林匹克级基准测试的兴奋：一位用户分享了他们对 @Hothan01 最近在 Twitter 上发布的 #OlympiadBench 的热情，该基准测试使用奥林匹克级别的科学问题来挑战模型。该基准测试是双语且多模态的，对 AI 系统提出了巨大挑战，表现最好的模型 GPT4V 的平均得分仅为 17.23%。GitHub Repository Arxiv Paper

  • 讨论神经网络数学与 NN 的样条视图 (Spline View)：围绕神经网络 (NNs) 的“样条视图”以及模型参数的代数性质展开了讨论，用户们辩论了这些概念的可信度和实用性。他们深入探讨了如何利用仿射区域 (affine regions) 和非线性边界来理解并潜在地增强深度神经网络的行为。

  • LoRA 梯度更新与 SVD 的理论探索：@thatspysaspy 和其他人就 LoRA (Locally Reweighted Approximation) 适配器的更新是否等同于全权重梯度的奇异值分解 (SVD) 进行了技术对话。他们讨论了数学上的复杂性，并提议通过实验进一步探索这一理论。

  • 创意生成模型开发：用户 @carsonpoole 一直在研究一种新型的 CycleGAN，它结合了 Diffusion 模型和一个判别器，该判别器预测域之间的点，而不仅仅是分类真假。他们报告称，在训练早期阶段，其主观效果优于传统的 CycleGAN。

  • Scaling Laws 与训练 Token 的讨论：发生了关于 AI Scaling Laws 的对话，特别是模型大小与训练 Token 之间的关系，并提到了一篇最近研究训练期间有限数据和数据重复影响的论文。这引发了关于这些发现对预训练策略影响的交流，例如针对一个拥有 4 万亿训练 Token 的假设性 150 亿参数模型的策略。

提到的链接：

  • Deep Networks Always Grok and Here is Why：Grokking（顿悟）或延迟泛化是一种现象，即深度神经网络 (DNN) 的泛化发生在达到近乎零训练误差很久之后。之前的研究已经报告了这种现象……
  • Chaoqun He (@Hothan01) 的推文：🥳🙌 很高兴发布 🔥#OlympiadBench🔥，一个奥林匹克级别的双语多模态科学基准测试。表现最好的模型 #GPT4V 获得了 17.23% 的平均分。这样一个具有挑战性的基准测试……
  • Scaling Data-Constrained Language Models：当前缩放语言模型的趋势涉及同时增加参数数量和训练数据集大小。推演这一趋势表明，训练数据集的大小可能很快就会受到……的限制。

Eleuther ▷ #scaling-laws (1 条消息):

.the_alt_man: 出于好奇，你是怎么制作那个动画的？

Eleuther ▷ #interpretability-general (24 条消息🔥):

  • 澄清论文中的 ‘Energy’ (能量)：@mrgonao 对论文及其方程中使用的术语 “energy” 表示困惑，称对其含义缺乏直观理解。@butanium 同意审阅该论文以更好地理解。
  • 为潜在空间分析重新定义 ‘Energy’：@wendlerc 介入并澄清，”energy” 一词在历史上是指在第 i 层 Latent 中用于解码/建模下一个 Token 分布的“信息”量化，但也承认这可能不是最好的术语。
  • 解析 ‘Energy’ 方程：@wendlerc 就如何改进 “energy” 表达式使其更具可解释性提供了深刻的解释，即通过归一化平方余弦测量 Latent 与输出嵌入 (output embedding) 的相似度。
  • 关于范数 (Norms) 的困惑：围绕能量方程中使用的数学符号展开了对话，@mrgonao 寻求关于各种范数使用的澄清，@nostalgiahurts 解释说 2 代表欧几里得范数 (Euclidean norm)，F 代表 Frobenius 范数。
  • 实现 Tuned Lens：讨论继续，@mrgonao 和 @wendlerc 思考了 Tuned Lens 的正确实现方式，以及在处理 Latents 和用于解码的 RMSNorm 层时如何准确反映其效果。

Eleuther ▷ #lm-thunderdome (28 messages🔥):

  • 模型 Batch Size 敏感度：@madison_33844 询问在使用 Llama-70B 时，Batch Size 的变化是否会影响 GSM8k 的结果，并指出其与 OpenLLM 排行榜存在差异。@hailey_schoelkopf 回复称，由于细微的不确定性可能会出现差异，但不应存在显著的分数差距。

  • LM Eval Harness：Split 选择查询：@micpie 寻求关于测试是根据是否存在而评估 test 还是 validation split 的澄清，以及 Loglikelihood 输出中 true 和 false 的含义。@baber_ 和 @hailey_schoelkopf 澄清说，这表示目标字符串是否为 Greedy Completion（贪婪补全），并且无法通过命令行覆盖 Split 选择，只能通过修改 YAML 文件来实现。

  • 理解 Loglikelihood 输出：@micpie 需要协助理解 LM Eval Harness 的输出，特别是 Loglikelihood 及其 true/false 值。@hailey_schoelkopf 确认了 @micpie 对评估过程的理解，指出输出格式包括 Loglikelihood 以及目标字符串是否为 Greedy Completion。

  • 在训练集上评估多选题：@micpie 在其配置中遇到了进度条输出与 .jsonl 行数不匹配的问题。@baber_ 澄清说，这是因为双答案多选题评估会将每个“上下文-选项”组合都通过模型运行一次。

  • 实现多模态 LM Eval：@hailey_schoelkopf 跟进了扩展多模态 LM 评估的进展，并询问 @paganpegasus 是否在 Instruction/Chat 格式化方面需要帮助，或者他们是否应该考虑使用已经格式化好的示例来微调模型。

Eleuther ▷ #gpt-neox-dev (6 messages):

  • 寻求在 CoreWeave 上进行 GPT-NeoX 训练的指导：用户 @jdranpariya 询问如何在 CoreWeave 上设置 多节点 GPT-NeoX 训练环境，寻求关于使用 Slurm 或 MPI 在 2 个节点和 4 个 GPU 上运行的帮助。
  • 了解 CoreWeave 和 Kubernetes 设置：@jdranpariya 询问 Kubernetes 是否是设置中不可或缺的一部分，或者是否有替代方案，并对在其用例中如何连接虚拟服务器表示困惑。
  • 指向 CoreWeave 特定查询的建议：针对设置疑问，@catboy_slim_ 建议将针对 CoreWeave 基础设施的具体问题提交给 CoreWeave 支持部门，并指出 NeoX 文档 提供了在 Slurm 上启动的说明。
  • Slurm 集群问题的方向：@catboy_slim_ 澄清说建立 Slurm 集群属于 CoreWeave 的范畴，@jdranpariya 对此表示认可。

LlamaIndex ▷ #blog (5 messages):

  • LlamaIndex 发布 Function Calling Cookbook：LlamaIndex 团队推出了一系列配合 @FireworksAI 使用的 Cookbook，重点介绍了使用 FireFunction-v1 进行 Function Calling 和 RAG。推文庆祝了 LlamaIndex 与 FireworksAI 模型之间的兼容性。
  • 将 RAG 应用组合成 Super-RAG 功能：LlamaIndex 透露了其最新功能，允许通过将 RAG 应用程序连接到单个网络中来创建分布式的 Super-RAG。根据其推文，用户可以期待为任何 RAG 应用程序创建 API 服务，并在这个新网络中运行查询 (LlamaIndex 推文)。
  • 测试 LlamaParse 处理复杂文档的极限：由 @AIMakerspace 主办的名为“针对复杂 PDF 的卓越 RAG”的即将举行的活动将评估 LlamaParse 的有效性。LlamaParse 是 LlamaIndex 宣布的一款专为包含嵌入图表和表格的复杂文档设计的专有解析工具。该免费虚拟活动旨在探索 LlamaParse 处理复杂 PDF 的能力，并将为参与者提供代码演示和幻灯片 (活动注册)。
  • Groq 与 LlamaIndex 合作进行 LLM 生成：LlamaIndex 将 @GroqInc 的 LPU 集成到其服务中，该服务专门为支持 Llama2 和 Mixtral 模型的 LLM 生成而定制，承诺为应用程序工作流带来巨大的速度提升 (LlamaIndex 与 Groq Cookbook)。

提到的链接：

使用 LlamaParse 为复杂 PDF 构建卓越的 RAG · Luma：全球企业不断提出的问题是：“我该如何处理包含图表、表格和图形的复杂文档？”处理过程演进的下一步是……

LlamaIndex ▷ #general (227 messages🔥🔥):

  • 查询 PDF 与错误处理：@vett93 在查询 PDF 文件时遇到困难并碰到了连接错误。@whitefang_jr 建议检查 Ollama 模型实例的设置和部署，并提供了相关文档链接以供参考。

  • Reranking 模型讨论：用户 @richard1861 和 .sysfor 正在讨论 Reranking 模型的对比效果。.sysfor 建议同时使用 FlagEmbeddingReranker 和 CohereRerank 以获得更好的效果，并提到 Cohere 似乎更快。

  • ReActAgent 的可视化：@mrpurple9389 询问是否可以为 ReActAgent 可视化图表（graph），@cheesyfishes 回复称实际上它并没有可供可视化的图表。

  • Callback Handlers 的 Golang 集成：@sansmoraxz 尝试将现有接口迁移到 Golang，并询问了有关 CallbackHandlers 的问题。@cheesyfishes 表示正在进行回调（callbacks）的重构，并预计很快会有改进。

  • 理解 Node 与 Document 的区别：@crawftv 询问了 LlamaIndex 中 Node 和 Document 之间的区别及其实际用途，对是否在索引中结合使用它们的父子关系表示困惑。

提到的链接：

LlamaIndex ▷ #ai-discussion (1 messages):

  • 寻找中间地带的模型：@sysfor 正在寻找一个填补 Mistral 7b 和 Mixtral 之间空白的模型，因为他们发现 Solar 的效果不尽如人意。他们的目标是在 24GB 显存卡上托管 Mistral，并为摘要提取和日志关联等任务留出空间，以运行大约 10.7b 的 quant 6/8 模型。

HuggingFace ▷ #announcements (1 messages):

  • Cosmopedia 发布：@lunarflu 宣布发布 Cosmopedia，这是一个由 Mixtral 创建的大型 25B token 合成数据集，包含教科书、博客文章和故事。该数据集包含 30M 个文件，可通过 LinkedIn 访问。

  • huggingface_hub 更新 0.21.0：新的 huggingface_hub 库版本 0.21.0 已发布，其特性包括 dataclasses、PyTorchHubMixin 增强、InferenceClient 中的 audio-to-audio 支持以及已翻译的文档，尽管存在一些破坏性变更。更多详情请查看完整的发布说明 此处。

  • Gemma 7B 现已登陆 Hugging Chat：Google 的开源 LLM Gemma 7B 现在可以在 Hugging Chat 服务中使用，正如 @julien_c 在 Twitter 上分享的那样。

  • TTS Arena 亮相：宣布 TTS Arena，这是由 @reach_vb 发起的一个新项目，用户可以在其中测试、评分并发现顶尖的开源 text-to-speech 模型。这个互动空间最初包含五个模型，并将根据社区反馈加入更多模型。更多信息可以在 此处 找到。

  • 数据众包努力初见成效：#data-is-better-together 倡议发布了 10k_prompts_ranked，这是一个由 300 多名社区成员在不到两周内创建的数据集，旨在支持 AI prompt ranking systems 的开发和评估。社区建设的成果在 HuggingFace.co 的一篇 博客文章 中得到了强调。

提到的链接：

HuggingFace ▷ #general (112 条消息🔥🔥):

  • 关于免费 Inference-API 问题的查询：@temperance6095 提出了关于在使用免费 Inference-API 运行 Text-to-Image 模型时反复出现超时（504 错误）的担忧，并寻求帮助以确定确切原因。他们随后注意到该问题并非个例，并参考与 HuggingFace Bot 的对话，思考频率限制（rate-limiting）是否是一个影响因素。

  • 使用 Mistral 模型抛硬币：@acidgrim 询问了 Mistral8x7B q8 KM 是否有能力抛 10 次硬币并报告结果，提到他们目前的 q5 模型只返回了 “1. Heads 2. Tails”。

  • 寻求 AI 集成方面的帮助：@vishyouluck 和 @tomato3602 等用户讨论了将 AI 与工具和 API 集成时面临的挑战和项目，寻求关于支持 function calling 的模型以及如何将其整合到网站中的建议。

  • 关于 Edge TPU 和技术的闲聊：围绕利用 Edge TPU 展开了讨论，@typoilu 和 @zorian_93363 对 Google Coral 加速器等微型但强大的硬件性能表示惊讶，而 @ahmad3794 则就构建自定义计算框架发表了看法。

  • 学习曲线与抱负：在各种讨论中，@sheeshmohit 寻求关于开始 AI 学习和内容创作的指导，而 @caleb_sol 思考了在低配置 Android 平板电脑上运行 tinydolphin LLM 的可行性，这体现了 AI 社区中多样化的抱负和学习尝试。

提到的链接：

HuggingFace ▷ #today-im-learning (5 条消息):

  • CS231n 学习小组成立：用户 @shreesha1573 正在为 CS231n 课程（Convolutional Neural Networks for Visual Recognition）组织一个学习小组。他们分享了 Spring 2023 Assignments 以及关于软件设置、Python/Numpy 教程、图像分类、线性分类和优化的章节。

  • CRM AI 开发探索：@koderfpv 正在寻求关于为其 CRM 应用程序构建 AI 和 chatbot 的指导，以预测生产时间和成本。他们具有 TypeScript, DevOps 和后端开发背景，但对 AI 领域尚不熟悉，希望在不使用 OpenAI APIs 的情况下启动一个长期项目。

  • 使用 LLM 进行城市情感分析：@x_5c44a99 分享了他们正在学习如何结合 LangChain 与 LLM 对推文进行情感分析，以用于城市配送规划。这可能是解决城市不平等问题的一步。

  • 对 HuggingFace 在分析中作用的疑虑：接上条，@x_5c44a99 不确定如何利用 HuggingFace 来分析推特数据的情感。

  • 探索 DSPy 框架和 Gorilla OpenFunctions v2：@n278jm 正在研究由 Stanford NLP 开发的 DSPy Framework 和 Gorilla 的 OpenFunctions v2，认为这些可以改进他们的客户入驻流程。DSPy 旨在对基础模型（foundation models）进行编程，而 OpenFunctions v2 则在 LLMs 的 function calling 方面提供了进步。

提到的链接：

HuggingFace ▷ #cool-finds (9 条消息🔥):

  • SUPIR 超越 Magnific：@furkangozukara 强调了 SUPIR 令人印象深刻的性能，这是一个开源的图像放大和增强模型，现在可以在 12 GB GPUs（如单块 RTX 3060）上有效运行。他们提到该模型，特别是以 Juggernaut-XL-v9 作为基础模型时，表现优于 Magnific 等昂贵的替代方案，并在 YouTube 视频中分享了评估结果。

  • Speakz 打破语言障碍：@teadaniel 介绍了 Speakz AI，它可以在跨语言翻译媒体内容的同时，保持原始声音和环境音完好无损。该工具旨在让用户能够无障碍地观看不同语言的内容（如 YouTube 视频），而无需因翻译而中断。

  • 分享故事的提议：当 @zorian_93363 对必须创建账号才能阅读完整故事感到沮丧时，@andysingal 提议为他们想读的任何故事分享一个好友链接（friend link）。

  • 厌倦了过多的账号：@zorian_93363 感叹管理过多账号和记忆密码的不便，但对 @andysingal 提到的竞赛表现出了兴趣。

  • 使用存档链接绕过付费墙：针对 @zorian_93363 关于需要账号才能阅读故事的评论，@n278jm 提供了一个存档链接，以便在无需注册的情况下访问内容。

提到的链接：

HuggingFace ▷ #i-made-this (17 messages🔥):

  • 哲学与 AI 的结合：@nabereon 讨论了使用 Mixtral-8x7B-Instruct-v0.1 从 AiresPucrs/stanford-encyclopedia-philosophy 数据集中为哲学系学生生成问答对。他们计划创建一个包含 IEP 条目和 Libretexts 教科书的更大数据集，目前因 @cakiki 提出的许可问题正在等待授权。

  • AI 政策的公众贡献请求：.plot 分享了一篇 博客文章，邀请大家对 NTIA 的 AI 开放模型权重 RFC 发表评论，该 RFC 讨论了开放权重 AI 模型的影响以及相关的联邦政策。

  • LLMs 基准测试：@michal.swedrowski. 介绍了 Performance LLM Board，这是一个根据价格和响应时间等工程指标比较大语言模型 (LLMs) 的资源。目前正在征求有关改进和内容方向的反馈。

  • 捷克语 LLM 排行榜发布：@hynek.kydlicek 主持了一个 专注于捷克语的 LLM 排行榜 (CZ-EVAL)，用于评估模型在捷克语任务中的有效性。该排行榜旨在展示适用于捷克语的模型并量化其能力。

  • 复现 Imagic 技术：@chongdashu 分享了复现 Imagic 论文的心得，详细介绍了使用扩散模型 (Diffusion Models) 进行基于文本的图像编辑。作者对这种方法及其应用表现出极大的热情，认为只要有耐心并对声音设计有一定了解的人都可以尝试。

提到的链接：

HuggingFace ▷ #reading-group (8 messages🔥):

  • 关注 Apple 的图像模型预训练：@johko990 表示有兴趣在未来的读书会演示中讨论 Apple 的 “Scalable Pre-training of Large Autoregressive Image Models”。
  • 未来演示的空档：@chad_in_the_house 确认本周会议后的演示日程尚有空余。
  • 讨论最大化 YouTube 影响力：@johko990 建议将视频上传到 Hugging Face 官方 YouTube 频道以获得更高的曝光率，并提到了他们社区计算机视觉课程内容播放量的增长。
  • 正在考虑视频质量和上传事宜：@lunarflu 同意检查视频质量并考虑将其添加到官方频道的建议。
  • 即将到来：定于 3 月 8 日的演示：@lunarflu 指出计划在 3 月 8 日进行演示，@chad_in_the_house 分享了相关报告的链接。

HuggingFace ▷ #diffusion-discussions (11 messages🔥):

  • 对 Playground v2.5 方法的失望：用户 @pseudoterminalx 对 Playground v2.5 仍在使用 eps prediction 表示失望，并批评了对 zsnr 的轻描淡写，转而选择使用 EDM framework。

  • Photo Concept Bucket 发布：@pseudoterminalx 介绍了一个名为 Photo Concept Bucket 的新数据集，包含 567,597 张带有描述的图像，该数据集在多 GPU 上运行，并使用 🤗Transformers 和 🤗Accelerate 创建。

  • 数据集入选社区亮点：随后，@lunarflu 提到新分享的数据集可以添加到社区亮点 (community highlights) 板块，认为鉴于其社区来源，放在那里比放在 HF 主新闻中更合适。

  • EDM 在最新 PR 中备受关注：@keturn 指出 diffusers 仓库中一个新合并的 PR，标题为 “add DPM scheduler with EDM formulation”；然而，该 PR 缺乏适当的描述 (PR #7120)。

  • 对 PR 处理方式的担忧：@pseudoterminalx 对 HF 工作人员似乎给予 Playground 团队优待表示沮丧，强调了某些 PR 被匆忙合并，同时链接了另一个缺乏关注的 PR (PR #4355)。

提到的链接：

HuggingFace ▷ #computer-vision (2 messages):

  • 关于 BLIP 模型本地服务器实现的咨询：@time.e.less 分享了一个用于图像字幕生成的 HuggingFace 模型链接，并询问是否可以像 llama.cpp 处理 LLM 那样在本地服务器上运行它。他们正在寻找一种无需构建 Python 服务器即可 POST 图像并接收包含字幕的 JSON 响应的解决方案。
  • 关于 Arcface Loss 和嵌入维度的问题：@huzuni 询问 arcface loss 中的嵌入维度 (embedding size) 是否对应于最后一个线性层的大小。他们寻求关于实现 arcface loss 技术细节的澄清。

提到的链接：

Salesforce/blip-image-captioning-base · Hugging Face：未找到描述

HuggingFace ▷ #NLP (18 messages🔥):

  • 快速 Embedding 模型推荐：@cakiki 询问针对小型、非专业英文数据集的 Embedding 模型建议，@cubietom 推荐了 Hugging Face 上的 BAAI’s bge-small-en-v1.5 以实现快速推理，并提到了 FlagEmbedding 项目 和 GTE 模型。
  • 为 LLM 压缩邮件内容：用户 @acidgrim 正在寻找一个能压缩邮件文件并保留核心信息以供 LLM 摄取的库，提到了正在使用 suma，并正在探索仅限 CPU 的本地选项。
  • 开发医疗 Transformer：@kareem3069 对 sentence-encoder 库在医疗代码和描述上的表现表示不满，并寻求改进特定领域应用模型映射的建议。
  • 更简洁的 CoT 提示词：@djpanda1 分享了一种通过要求 LLM 在 Chain of Thought (CoT) 提示过程中“think silently”（静默思考）来减少 token 使用的方法；收到的反馈褒贬不一，@vipitis 建议在更大的 Benchmark 上进行测试。
  • 在仅限 CPU 的系统上进行文本生成：@alfred6549 在没有 GPU 或 CUDA 的情况下运行 text generation inference 仓库 时遇到困难。推荐的命令选项未能解决问题，表明需要进一步的故障排除或替代方案建议。

提到的链接：

HuggingFace ▷ #diffusion-discussions (11 messages🔥):

  • 对 Playground v2.5 方法论的不满：@pseudoterminalx 对 HuggingFace 的 Playground v2.5 表示失望，原因是其使用了 “eps prediction” 并将 zsnr 视为次要注释，同时选择了“糟糕的 EDM 框架”。
  • 发布 Photo Concept Bucket：@pseudoterminalx 发布了 Photo Concept Bucket，这是一个包含 567,597 条目的开源许可图像数据集，由志愿者使用多 GPU 集群标注。@lunarflu 给予了积极回应，建议将其加入社区亮点。
  • 对 Diffusers PR 流程的沮丧：@pseudoterminalx 表达了对 HuggingFace 疑似优待 Playground 团队的挫败感，并将其与自己进展缓慢的 Pull Request 进行了对比。他特别提到了一个似乎已经停滞的 Mixture-of-Experts Pull Request。
  • 对随意选择方法的担忧：@keturn 参与了讨论，对 Playground v2.5 中看似随意的噪声调度（noise scheduling）选择表示思考，并注意到 diffusers 仓库中有一个 PR 在没有太多解释的情况下被快速推进。
  • 幽默地“升级”：@pseudoterminalx 幽默地注意到，甚至连机器人都识别出了他之前的批评性评论，并通知他“升级了”。

提到的链接：

LangChain AI ▷ #general (92 条消息🔥🔥):

  • 图像引用引发问题：用户 @deadthray 询问在 llava/visoon 模型中讨论同一张图像时，是否必须每次都传递图像字节字符串，这指向了持久化图像引用方面的挑战。
  • 旅游聊天机器人故障：@ritanshoo 分享了他们为旅游预订网站开发的聊天机器人面临的挑战，尽管在 Pinecone 中存储了大量数据集，但该机器人仍难以返回相关的答案。
  • LangChain 的灵活性引发辩论：@m_gee 转达了来自 Reddit 的担忧，涉及 LangChain 的 Token 消耗以及在生产级应用中的灵活性。@baytaew 为 LangChain 的可定制性辩护，并介绍了 LangGraph 用于更好的状态管理和 function calling 支持。
  • LangChain 中的 Python 与 JavaScript 之争：@pcube__ 询问哪种编程语言（Python、JavaScript 或 Go）与 LangChain 的集成度最高，以便构建一个带有 Azure 托管 LLM API 端点的 Web 服务器。@kapa.ai 确认 Python 和 JavaScript 具有强大的集成，但未提及 Go。
  • 为 LangChain LCEL 添加 Memory：@marknicholas 寻求关于在 Python 中使用模板时如何为 LangChain 链添加 memory 的指导。虽然 @kapa.ai 提供了一个通用方法，但他们建议查阅 LangChain 文档以获取精确的实现方式。

提到的链接：

  • [Deployment 🦜️🔗 Langchain](https://python.langchain.com/docs/guides/deployments#outline>)): 在当今快速发展的技术格局中，大语言模型 (LLMs) 的使用正在迅速扩大。因此，对于开发者来说，了解如何有效地部署这些模型至关重要…
  • [Querying a SQL DB 🦜️🔗 Langchain](https://python.langchain.com/docs/expression_language/cookbook/sql_db): 我们可以使用 Runnables 复制我们的 SQLDatabaseChain。
  • [[beta] Structured Output 🦜️🔗 Langchain](https://python.langchain.com/docs/guides/structured_output): 让 LLM 返回结构化输出通常至关重要。
  • Join the Creepz NFT Alpha Group Discord Server!: 查看 Discord 上的 Creepz NFT Alpha Group 社区 - 与其他 13786 名成员一起交流，享受免费的语音和文字聊天。
  • [Docusaurus 🦜️🔗 Langchain](https://python.langchain.com/docs/integrations/document_loaders/docusaurus#filtering-sitemap-urls>)): Docusaurus 是一个静态网站生成器，它…
  • langchainjs/langchain/src/retrievers/score_threshold.ts at e24d2dedbe7ff93db33a5809e604143d60113028 · langchain-ai/langchainjs): 🦜🔗 构建上下文感知的推理应用 🦜🔗。通过在 GitHub 上创建账号为 langchain-ai/langchainjs 的开发做出贡献。
  • [Quickstart 🦜️🔗 Langchain](https://js.langchain.com/docs/get_started/quickstart#building-with-langchain>)): 在此快速入门中，我们将向您展示如何：
  • [Add chat history 🦜️🔗 Langchain](https://python.langchain.com/docs/use_cases/question_answering/chat_history#langsmith>)): 在许多问答应用中，我们希望允许用户拥有…
  • Issues · langchain-ai/langchain)): 🦜🔗 构建上下文感知的推理应用。通过在 GitHub 上创建账号为 langchain-ai/langchain 的开发做出贡献。

LangChain AI ▷ #langserve (1 条消息):

  • 无效 Discord 链接垃圾信息：用户 @davisson0429 分享了一个 Discord 邀请链接，随后是一系列大量的竖线 |||| 并艾特了 @everyone。该消息的目的或上下文未提供。

提到的链接：

Join the Creepz NFT Alpha Group Discord Server!: 查看 Discord 上的 Creepz NFT Alpha Group 社区 - 与其他 13786 名成员一起交流，享受免费的语音和文字聊天。

LangChain AI ▷ #langchain-templates (1 条消息):

  • LangChain Templates 中的垃圾信息警示：用户 @davisson0429 发布了一条充满竖线和 @everyone 提醒的消息，这似乎是垃圾信息。该消息包含一个 Discord 邀请链接，随后是无意义的竖线图案。

提到的链接：

Discord - A New Way to Chat with Friends & Communities: Discord 是进行语音、视频和文字交流最简单的方式。与您的朋友和社区聊天、聚会并保持紧密联系。

LangChain AI ▷ #share-your-work (4 messages):

  • LangGraph 与 LangChain 合并：@andysingal 分享了一篇关于 LangGraph 的博客文章，该工具提供迭代式代码生成与纠错，并与 LangChain 集成以增强代码的安全性和完整性。
  • 《LangChain in your Pocket》入选最佳书籍名单：@mehulgupta7991 自豪地宣布，他们的处女作《LangChain in your Pocket》现已列入 Google 的 Best books on LangChain（LangChain 最佳书籍）名单。
  • 邀请加入派对：@davisson0429 向社区发出了 Discord 加入链接的邀请，鼓励大家加入他们的服务器。
  • 课程兴趣调查：@silvermango9927 通过 Google Form 调查问卷寻求社区对各种教育课程的反馈，如机器学习、数据科学、Python 初学者课程和 Web 开发。

提到的链接：

LangChain AI ▷ #tutorials (3 messages):

  • 手机端创新 AI Co-pilot：用户 @jasonzhou1993 分享了一个名为 “Real time AI Conversation Co-pilot on your phone, Crazy or Creepy?” 的 YouTube 视频。该视频展示了 iPhone 上的对话 AI Co-pilot，它能监听对话并使用 Whisper 和 Mixtral 模型提供实时建议。
  • 关于 Workflow 编译的澄清：@tigermusk 询问 workflow.compile() 在 LangGraph 中是否是一个 runnable 对象。消息历史中没有提供澄清此问题的回复。
  • 可疑链接刷屏：@davisson0429 在频道中大量发送加入 Discord 服务器的链接和一大块垂直条，这看起来是干扰或恶作剧行为，而非有用的贡献。

提到的链接：

OpenRouter (Alex Atallah) ▷ #announcements (1 messages):

louisgv：修复了与 Perplexity 和 Gemma 的消息排序/格式相关的若干问题。

OpenRouter (Alex Atallah) ▷ #app-showcase (4 messages):

  • OpenRouter 实现了简单性和包容性：@e__lo 强调了使用 OpenRouter 创建新 AI 工具的便捷性，以及它整合模型的能力——不仅包括 OpenRouter 自身的模型，还包括来自 Google Vertex AI、Amazon Bedrock 和 Cloudflare AI 等巨头的模型，确保用户可以申请添加任何他们希望使用的模型。
  • 捷克语 LLM 排行榜发布：@hynek.kydlicek 分享了他的项目——一个专门用于评估捷克语大语言模型 (LLMs) 的排行榜。他指出，对于这项拥有超过 8k 个样本的大型任务，使用 OpenRouter 是最简单且最具成本效益的选择，并提供了项目链接。
  • 对 LLM 排行榜倡议的赞赏：@alexatallah 对 @hynek.kydlicek 的捷克语 LLM 排行榜表示支持和兴奋，称这一成就“太棒了！”。
  • AI 语音聊天应用招募 Beta 测试人员：@beaudjango 介绍了 Pablo，这是一款 AI 语音聊天应用，支持无需打字的语音交互，并支持多种 LLMs 和语音。他们正在招募 Beta 测试人员，并为加入者提供包括 GPT-4 在内的免费 AI 额度，并为感兴趣的参与者提供了 TestFlight 链接。

提到的链接：

OpenRouter (Alex Atallah) ▷ #general (73 messages🔥🔥):

  • 发现聊天模板不一致问题：@aerk._. 强调了在使用 Gemma 7B 期望继续讨论 LLM 话题时出现的异常响应问题。在与 @louisgv 进行了一些沟通后，修复程序已部署，@aerk._. 确认该解决方案效果良好。
  • 针对多轮对话的模板故障排除：@quentmaker 在尝试将对话延续到 8 个以上的用户/助手消息对时，在多个模型上遇到了错误。@louisgv 和 @alexatallah 都参与并提供了解决方案，并承认 OpenRouter 系统需要进行修复。
  • 关于 OpenRouter 盈利模式的查询：针对 @_lynett 关于 OpenRouter 如何赚钱的问题，@alexatallah 提到他们目前尚未针对收入进行优化，并分享说潜在收益来自于与用户分享批量折扣。
  • 探讨 OpenRouter 的 Rate Limits：@gunpal5_43100 询问了在 OpenRouter 上使用 ChatGPT 时的 Rate Limits，随后 @alexatallah 指向了 OpenRouter 网站上概述当前限制的文档。
  • 对即将推出的模型的期待：包括 @wikipediadotnet 和 @RobinF 在内的 Discord 成员讨论了他们对 Claude 3 发布的期待，同时也幽默地提到了该模型可能对“excited”一词的反感。

提到的链接：

OpenAccess AI Collective (axolotl) ▷ #general (40 messages🔥):

  • 消费级硬件 LLM 训练不可行：@nafnlaus00 评论了在消费级硬件上训练大型语言模型的不切实际性，并开玩笑说家里随处可见配备 H100 的机器是不可能的。
  • 讨论 LoRA 训练的局限性：@enka55 在 Hugging Face 上寻找使用 LoRA 训练新知识的模型示例，而 @nruaif 和 @leoandlibe 澄清说 LoRA 并不是添加新知识的正确选择，建议改用全量微调（full fine-tuning）。
  • RunPod 链接验证请求：@nanobitz 请求验证在 GitHub Issue #1318 中发现的 RunPod 直连链接，@nruaif 回复称该链接对他们无效。
  • 1-Bit LLM 论文引起关注：@_dampf 分享了一篇 arXiv 论文，介绍了 BitNet b1.58，这是一种 1-bit LLM，声称在性能上能与全精度模型相媲美。@nafnlaus00 和 @nanobitz 讨论了这可能成为 NN 硬件设计的革命性范式转变。
  • 在消费级硬件上进行 BitNet 训练：根据分享的 arXiv 论文，@bratao 对在消费级硬件上训练 BitNet 模型的潜力感到兴奋，因为其效率明显高于全精度 LLM。@nanobitz 推测其架构可能与量化方法不同。

提到的链接：

OpenAccess AI Collective (axolotl) ▷ #axolotl-dev (10 messages🔥):

  • 在追求速度之前先寻求准确性：@dreamgen 强调了在专注于提高速度之前，确保 AI 模型执行正确的重要性。
  • 介绍 LoRA-the-Explorer (LTE)：@caseus_ 分享了一篇关于使用并行低秩适配器（Parallel Low-Rank Adapters）训练神经网络的新方法的链接，强调了多头 LoRA 即使在联邦学习之外也具有潜力。
  • 多头 LoRA 的 GitHub 源码：随着讨论的深入，@caseus_ 还提供了一个 GitHub 链接 以深入研究多头 LoRA 实现的细节。
  • 微调中的上下文长度挑战：@xmikemm. 询问了在 Nvidia 4090 GPU 上使用 16k 上下文对 TinyLlama 进行 Q-Lora 微调的可行性，而 @caseus_ 建议这可能会超出 VRAM 容量，并提供了可尝试的配置建议。
  • 模型实验的数据集建议：针对 @xmikemm. 在投入数据集创建之前寻找相关数据集的需求，@caseus_ 建议使用现有数据集，例如在 Hugging Face 上发现的数据集，来进行不同上下文长度的实验。
  • ReLoRA 的潜在替代方案：关于 LoRA-the-Explorer (LTE) 的对话引导 @nruaif 提出，它可能作为 ReLoRA 的可行替代方案，这可能预示着低秩适配（low-rank adaptations）方法的转变。

提到的链接：

OpenAccess AI Collective (axolotl) ▷ #general-help (18 messages🔥):

  • 生成错误答案：用户 @emperor 询问了关于使用 LLM 生成带有合理逻辑解释的错误答案的技术；@nafnlaus00 建议要求 LLM 生成包含看似轻微但会导致错误结论的、具有迷惑性错误的回答。
  • Runpod 与 Vast AI 对比：@stoicbatman 寻求 Vast AI 和 Runpod 服务的对比；@nanobitz 回应指出 Vast AI 可能更具性价比，但机器质量参差不齐，且缺乏对机器细节的抽象。
  • Axolotl 安装困惑：@karisna 对设置 Axolotl 的文档感到困惑，强调需要更清晰的说明，特别是针对 Windows 用户。
  • 微调模型的基准测试：@jovial_lynx_74856 询问关于使用 Axolotl 运行微调模型的基准测试；@nanobitz 推荐了外部工具 lm_eval_harness，但承认 Axolotl 目前没有为此目的提供直接集成。
  • Pydantic 与 Mistral 配置冲突：@ustoll 遇到了 Pydantic 内部的命名空间冲突，影响了 Mistral 配置，@nanobitz 建议其回退到之前的 commit，并在 GitHub 提交 issue 以寻求解决。

OpenAccess AI Collective (axolotl) ▷ #replicate-help (1 messages):

  • Replicate 表现出人意料地逊色：用户 @dreamgen 表示惊讶，尽管经过多年的专注发展，replicate 的表现可能不如预期，挑战了其长期建立的声誉。未提供进一步的背景或具体对比。

Interconnects (Nathan Lambert) ▷ #news (9 messages🔥):

  • Together Compute 预告创新：@natolambert 分享了来自 Together Compute 的推文，强调了长上下文能力在开发 AI 中的重要性。

  • AI 生态系统纠葛解析：@markkim1 讨论了 Together 与 Cartesia 之间复杂的关系，指出他们在 Sparse Switching Networks (SSNs) 方面的合作与竞争，并提到 Liquid AI 是该领域的另一个参与者。

  • Arthur Mensch 澄清事实：@xeophon. 链接了 @arthurmensch 的一条推文，声明他们将继续致力于开放权重模型、与 Microsoft 的转售协议，以及其具有全球抱负的欧洲公司的独立地位。他们看到各平台对 Le Chat 和 Mistral Large 的兴趣，并计划快速迭代。Arthur Mensch 的澄清推文

  • “Starcoder2” 和 “The Stack v2” 发布：@xeophon. 转发了 BigCodeProject 推出 Starcoder2 的推文，该模型基于 The Stack v2 构建，提供 16k token 上下文，The Stack v2 是最大的代码数据集，包含超过 9000 亿 token。数据和模型完全开放且可访问。了解更多关于 Starcoder2 的信息

  • 呼吁 HuggingFace 加大模型训练力度：@natolambert 对 Starcoder2 的发布做出回应，建议 HuggingFace 应该训练更多模型，并认可了代码模型领域取得的进展。

提到的链接：

  • 来自 BigCode (@BigCodeProject) 的推文：介绍：StarCoder2 和 The Stack v2 ⭐️ StarCoder2 使用 16k token 上下文和仓库级信息在 4T+ token 上训练。全部构建在 The Stack v2 之上——这是最大的代码数据集，拥有 900B+ t…
  • 来自 Arthur Mensch (@arthurmensch) 的推文：澄清几件事，因为我们看到了对我们最新公告的各种创造性解读：- 我们仍然致力于领先的开放权重模型！我们请求一点耐心，1.5k H100s …

Interconnects (Nathan Lambert) ▷ #ml-drama (1 messages):

natolambert: 优质推文串 https://twitter.com/mmitchell_ai/status/1761860673989193959

Interconnects (Nathan Lambert) ▷ #random (52 messages🔥):

  • Nathan 的 Notion 笔记心得：@natolambert 讨论了他的写作流程，提到他在 Notion 中收集 ideas and links，尝试将它们组合成段落，使用 Grammarly 和 ChatGPT 进行编辑，然后复制到 Substack。他还评论了尽管由于写作量增加考虑换回 Ulysses，但最终还是尝试并放弃了它。
  • Typora 位居 Xeophon 的编辑器榜首：用户 @xeophon. 分享了他们对 Typora 的偏好，这是一款使用了多年的 Markdown 编辑器，并正在考虑 Obsidian。Nathan Lambert 对 Typora 的建议给出了积极回应，认为它看起来很棒，但也分享了他过去在 Roam 和 Obsidian 复杂性方面遇到的问题。
  • AI News 摘要汇总 Discord 讨论：用户 @swyxio 分享了 AI News 的链接，这是一项旨在总结各种 AI 相关 Discord 服务器讨论的服务，为读者节省了大量时间。该时事通讯在最新评估的 Discord 中提到了 Interconnects，并向其管理员 Nathan Lambert 致意。
  • Dwarkesh 播客深度访谈 Demis Hassabis：@natolambert 赞扬了 Dwarkesh Patel 播客中采访 Google DeepMind CEO Demis Hassabis 的一集，并讨论了包括 scaling、AlphaZero 和 AI 治理在内的各种 AI 话题。
  • 聊天中的姓氏混淆：在一次友好的误会中，用户 @natolambert 和 @mike.lambert 澄清了尽管姓氏相同但并无亲戚关系。Mike Lambert 确认了他与 Anthropic 的隶属关系，并表示他不是来分享敏感信息的，只是以个人身份参与。

提到的链接：

CUDA MODE ▷ #general (2 messages):

  • 关于 CUDA 模拟的咨询：@jash403 询问了关于在 CUDA GPU 上创建或运行模拟器（Emulators）的建议。
  • 在 CUDA 上模拟 Gameboy：@iron_bound 分享了一个 GitHub 仓库 krocki/nvgb，这是一个使用 CUDA 模拟 Gameboy 的项目。他们还提供了一篇 Towards Data Science 文章，描述了它如何构成了可以说是世界上最快的 8-bit 游戏机集群。

提到的链接：

CUDA MODE ▷ #triton (3 messages):

  • Unslothai 的 Triton 内核令人印象深刻：@andreaskoepf 赞扬了来自 unslothai 的 Triton 内核，强调了它们在 QLoRA finetuning 中实现 5倍速 执行和 减少 60% 内存 使用的高效率。
  • 将自定义 Triton 内核与 Torch 集成：@marksaroufim 分享了来自另一个频道的转发，讨论如何将自定义 Triton 内核与 torch.compile 集成。详细信息可能在引用的 Discord 帖子中找到，但该帖子无法直接访问。
  • Jeremy 会见内核背后的开发者：@jeremyhoward 提到他们与 unslothai 的 Triton 内核作者进行了交流，对所做的出色工作表示认可。

提到的链接：

GitHub - unslothai/unsloth: 5X faster 60% less memory QLoRA finetuning：5倍速、减少 60% 内存的 QLoRA finetuning。在 GitHub 上为 unslothai/unsloth 的开发做出贡献。

CUDA MODE ▷ #cuda (4 messages):

  • 理解 L2 Cache 效率：@cudawarped 讨论了与 L2 Cache 和 Global Memory 相关的内存操作，指出由于延迟相似，带宽可能是主要的区分因素。他们引用了 Stack Overflow 的结果 和一项 微基准测试研究 来支持 L2 Cache 带宽显著更高的论点。

  • 对 Nvidia H100 架构设计的见解：@iron_bound 分享了他们对 Chips and Cheese 上 Nvidia H100 GPU 详细架构拆解的喜爱。他们强调了该网站对这款针对计算市场（偏离了传统图形任务）的 GPU 的报道。

  • 对基准测试可用性的短暂困惑：@zippika 表达了对运行 H100 GPU 基准测试的兴趣，但最初未能找到它们，随后意识到这些测试确实就在他们喜欢的同一个网站上。

提到的链接：

CUDA MODE ▷ #torch (12 messages🔥):

  • PyTorch 的前世今生：@marksaroufim 分享了 PyTorch 设计和起源的详细历史，强调了它从 2010 年左右开始的 Torch7（也称为 LuaTorch）的演变。这段 历史回顾 展示了将 LuaTorch 的 C 后端重构为与语言无关（language agnostic）的过程，是如何演变成我们今天所熟知的 PyTorch 的。

  • 自定义 Triton Kernels 与 torch.compile：对于那些希望自定义 Triton kernels 能与 torch.compile 协同工作的开发者，可以参考这个 PyTorch GitHub 示例，它支持 dynamic shapes、autotuning 和 autograd。如果遇到问题，@marksaroufim 建议提交 issue 并艾特专家 @oulgen。

  • 在编译器挑战下编译 Fast Attention：Tri Dao 针对编译器为何难以在数学层面优化 Fast Attention 提供了见解，重点在于如何保持数值稳定性（numerical stability）。讨论围绕一项旨在将语言模型训练的 FlashAttention 速度提升 2 倍的工作展开，详情可见 OpenReview。

  • 关于 GPU 架构求解器潜力的辩论：关于优化 GPU 架构的求解器（solver）的概念引发了 @iron_bound、@chhillee 和 @gogators. 等用户的辩论，讨论了该任务的复杂性及其与装箱问题（bin-packing problem）的比较，强调了在深度学习工作负载分配中寻找最优解的固有难度。

  • 深度学习的高级编译器技术：@w0rlord 等用户提到了多面体编译（polyhedral compilation），将其视为一种实现代码最优转换的方法，并与深度学习问题相关联。@w0rlord 分享了 PolyMage Labs（一家致力于此类技术的公司）的链接以及该主题的教育资源，引起了 @gogators. 的兴趣，链接见 此处。

提到的链接：

CUDA MODE ▷ #algorithms (2 messages):

  • Fast InvSqrt() —— 一种怀旧的优化：用户 @iron_bound 回忆起著名的 快速平方根倒数算法 (fast inverse square root algorithm)，该算法因在 Quake III 中的应用而闻名。Wikipedia 链接 展示了该算法，它在 OpenArena 等游戏中对 光照和反射 (lighting and reflection) 计算非常有用。
  • 通用实现的挑战：继优化算法的话题之后，@chhillee 评论了创建通用版本的复杂性，指出 “不幸的是，很难以通用的方式实现它。” 这反映了将专用算法适配到更广泛应用中的固有挑战。

提到的链接：

Fast inverse square root - Wikipedia：未找到描述

CUDA MODE ▷ #pmpp-book (1 messages):

watashiwapotato: 有人为此制作了 Anki 卡片吗？

CUDA MODE ▷ #smol-hw (2 条消息):

  • 关于 ‘AO’ 缩写的澄清：@mr.osophy 询问 “AO 代表什么 😅”，表示需要对该缩写进行澄清。
  • 定义 ‘AO’：@marksaroufim 回复称 AO 代表 Architecture Optimisation（架构优化），并承认这可能不是最合适的名称。

CUDA MODE ▷ #ring-attention (8 条消息🔥):

  • Ring Attention 的协作努力：@ericauld 分享了一个 开发中的 Notebook，展示了 Ring Attention 和 Flash Attention，并邀请大家提供反馈和协作改进。

  • 感谢社区见解：@andreaskoepf 对 @325883680419610631 在社区内分享的宝贵见解表示 感谢。

  • 对团队进展感到兴奋：@marksaroufim 对团队的工作和进展表示兴奋，表达了对正在进行的项目的支持。

  • 提议协助任务：@andreaskoepf 联系了 @831049856851116082，提议协助处理辅助任务或进行测试，展示了社区支持与协作的意愿。

  • Ring Attention 的技术挑战：@nshepperd 讨论了在 JAX 中使用 jax.Array 实现 Ring Attention 前向传播（fwd）时遇到的困难，特别是通过 collective-permute 和 custom calls 隐藏传输延迟的问题，并提到自动分区（automatic partitioning）在 0.4.20 版本中带来了挑战。

提到的链接：

Google Colaboratory：未找到描述

Latent Space ▷ #ai-general-chat (27 条消息🔥):

  • Pika 为 Pro 用户推出 Lip Sync 功能：@sylviatong 分享了 Pika 已向 Pro 用户开放 Lip Sync 功能的早期访问权限，公告详见 此处。这引起了 @swyxio 的注意，他认为该功能令人印象深刻，但仍未完全走出“恐怖谷”。

  • 令人印象深刻的 AI 客服统计数据披露：@swyxio 讨论了 Klarna 显著的大规模 AI 使用调查结果，提到其 AI 助手在第一个月处理了 230 万次客服聊天，完成的工作量相当于 700 名 Agent。@eugeneyan 对这些表明客户满意度与人类持平的宝贵数据表示感兴趣，而 @swyxio 则通过链接一篇质疑该新闻真实性的 Fast Company 文章，对这种乐观前景提出了挑战。

  • Elicit ARR 达到 100 万美元：@swyxio 宣布 Elicit 在推出订阅服务仅四个月后，年度经常性收入（ARR）已达到 100 万美元，庆祝团队取得的成就并暗示未来会有更大的发展。

  • 公开征集采访问题：@fanahova 即将采访 Adept 的 CEO，并向社区征集问题。@yikesawjeez 幽默地询问了关于 Adept 的开源计划和可穿戴设备的问题。

  • 本地运行 Gemma 的技术障碍：@stealthgnome 在 MPS 上运行 Google 的 Gemma 时因复数张量（complex tensors）遇到问题，引发了与 @swyxio 和 @yikesawjeez 关于模型兼容性和架构细微差别的讨论。进一步的讨论包括链接到 官方 Gemma PyTorch GitHub 及其运行脚本。

  • Noam Shazeer 的第一篇博客文章：@swyxio 分享了 Noam Shazeer 第一篇关注代码风格的博客文章，特别是关于形状后缀（shape suffixes）的内容，社区可在此处阅读 全文。

提到的链接：

  • Hamel Husain (@HamelHusain) 的推文: 关于 Klarna 的新闻感觉有些不对劲，是不是有点太像为了上电视而作秀了？ https://www.fastcompany.com/91039401/klarna-ai-virtual-assistant-does-the-work-of-700-humans-after-layoffs
  • Pika (@pika_labs) 的推文: 我们知道最近关于 AI 生成视频有很多讨论。好吧，看看现在谁在说话！Lip Sync 的早期访问权限现已向 Pro 用户开放，网址为 http://pika.art。
  • Sebastian Siemiatkowski (@klarnaseb) 的推文: 这是 AI 实际应用中的一项突破！由 @OpenAI 提供支持的 Klarna AI 助手，在首个 4 周内处理了 230 万次客户服务聊天，其数据和洞察力令人震惊……
  • Jungwon (@jungofthewon) 的推文: 在推出订阅服务 4 个月后，我们的 ARR 达到了 100 万美元 :) 感谢 @stuhlmueller @james_elicit @itsmesarahp @k1bird @BenRachbach @Mappletons @VivaLaPanda_ @LukeStebbing @__Charlie_G @OrangJuli…
  • Latent Space: AI Engineer 通讯 + 美国前 10 的技术播客。探索 AI UX、Agents、Devtools、Infra、开源模型。查看 https://latent.space/about 了解来自 Chris Lattner、Andrej Karpathy 等人的精彩内容……
  • Pika (@pika_labs) 的推文: 我们知道最近关于 AI 生成视频有很多讨论。好吧，看看现在谁在说话！Lip Sync 的早期访问权限现已向 Pro 用户开放，网址为 http://pika.art。
  • Sebastian Siemiatkowski (@klarnaseb) 的推文: 这是 AI 实际应用中的一项突破！由 @OpenAI 提供支持的 Klarna AI 助手，在首个 4 周内处理了 230 万次客户服务聊天，其数据和洞察力令人震惊……
  • Noam Shazeer (@NoamShazeer) 的推文: https://medium.com/@NoamShazeer/shape-suffixes-good-coding-style-f836e72e24fd 看看我的第一篇博客文章。
  • gemma_pytorch/scripts/run.py at main · google/gemma_pytorch: Google Gemma 模型的官方 PyTorch 实现 - google/gemma_pytorch
  • GitHub - google/gemma_pytorch: Google Gemma 模型的官方 PyTorch 实现: Google Gemma 模型的官方 PyTorch 实现 - google/gemma_pytorch

Latent Space ▷ #ai-announcements (1 条消息):

swyxio: 新播客上线了！对话 Replicate 的 CEO https://twitter.com/swyx/status/1762906839505846418

DiscoResearch ▷ #general (16 messages🔥):

  • 关于端到端 RAG-LLM 优化的咨询：@rasdani 提出了一个问题，即是否存在关于利用梯度进行检索增强生成 (RAG) 和大语言模型 (LLMs) 端到端优化的研究。LESS 论文因其优化器感知的数据选择方法被引用，尽管 @rasdani 随后澄清该方法并不通过数据选择进行反向传播。

  • 寻求 LESS 论文链接：@maxidl 请求获取 LESS 论文的链接，@rasdani 提供了该链接，并澄清之前提到的原始技术不涉及通过数据选择进行反向传播。

  • 德语文档提取的替代模型：@mab3049 报告了使用 Leo Mistral 7B 从 OCR 处理后的德语文档中提取信息时遇到的问题，得到的结果并不相关。@bjoernp 建议使用 DiscoLM_German_7b，并建议查看演示以及采用 Hugging Face 文档中正确的 Chat Template。

  • 模型推荐与正确的模板使用：针对 @mab3049 的提取困难，@bjoernp 建议改用 DiscoLM_German_7b 模型，并就如何使用适当的 Chat Template 以实现更好的模型交互提供了指导。

  • 关于代码分块器 (Code Chunker) 的讨论及对 Goliath 模型的偏好：@sebastian.bodza 抱怨了过去使用 llamaindex 代码分块器时遇到的问题，而 @philipmay 重点介绍了 Hugging Face 上的 Goliath 模型，并询问其他人是否认为它是处理德语任务的最佳模型。

提到的链接：

LLM Perf Enthusiasts AI ▷ #opensource (2 messages):

  • 推测 Llama 3 的发布：用户 @res6969 表达了对 Llama 3 发布的期待，估计可能会在 春季 发布。目前尚未提到或确认具体的发布日期。

LLM Perf Enthusiasts AI ▷ #speed (6 messages):

  • 延迟之痛：用户 @res6969 对延迟表示 深感失望，特别是 OpenAI API 响应所需的数秒时间。
  • Azure 托管的困扰：针对延迟问题，@pantsforbirds 表示赞同，认为 Azure 托管 的结果令人失望。
  • 澄清延迟查询：@justahvee 询问了延迟问题的细节，即该问题是指 首个 Token 的时间 (Time to First Token) 还是 固定数量 Token 的生成完成时间。
  • 确定延迟细节：在回答 @justahvee 的查询时，@res6969 明确延迟问题是指 首个 Token 的时间。

AI Engineer Foundation ▷ #general (1 messages):

iloveh8: 嗨，有什么准备 AI 工程师面试的建议吗？

AI Engineer Foundation ▷ #events (3 条消息):

  • 收看 YouTube 上的实时编程会议：@_z 分享了一个 YouTube 直播链接，邀请成员在他们开发 Agent Protocol V2 的 Config Options RFC 时进行观看和互动。直播承诺会分享编程见解并与观众互动。
  • 不要错过 Voice + AI Meetup：@kwindla 宣布了即将由 Cloudflare 主办的 Voice + AI meetup，届时将举行由来自 Oracle Cloud 的 Jay Jackson 等 AI 专家参加的小组讨论。活动包含演示和披萨，定于周三下午 6:30 在 Cloudflare 举行，感兴趣的人员可以在此报名 (RSVP)。
  • Voice + AI 活动有直播吗？：@yikesawjeez 询问即将举行的 Voice + AI meetup 是否会在线直播，并表示由于对语音技术感兴趣，希望能以“回复者”的身份参与。该询问暗示了远程参与的可能性，但目前尚未记录到具体回复。

提到的链接：

  • [Infrastructure for real-time AI, Wed, Feb 28, 2024, 6:30 PM Meetup](https://www.meetup.com/san-francisco-ai-algorithms-meetup-group/events/299200223/)：请在 2 月 28 日周三加入我们，地点在 Cloudflare 办公室（世界上最著名的熔岩灯所在地），参加关于实时 AI 基础设施的小组讨论。
  • Coding - Working on Agent Protocol V2 Milestone, Config Options, New RFCs：你好，我是 Ziggy！我是一名开源开发者、游戏玩家和技术爱好者。你可以在 GitHub 上找到我：https://github.com/jzanecook。有兴趣贡献…

Datasette - LLM (@SimonW) ▷ #ai (1 条消息):

  • 话痨 Claude 忽略 JSON 格式化请求：@derekpwillis 表达了对 Claude 的沮丧，因为它经常忽略严格生成 JSON 对象 的指令，而是添加诸如 “这是从文本中提取的 JSON 对象” 之类的开场白，即使明确指示以 { 开始并以 } 结束。对于寻求纯净 JSON 输出的用户来说，这种多余的叙述非常烦人。
← 返回首页