这些基础知识可能比紧跟每日新闻更有价值，我们喜欢尽可能地分享这类高质量的建议。

目录

[TOC]

AI Reddit 摘要

涵盖 r/LocalLlama, r/machinelearning, r/openai, r/stablediffusion, r/ArtificialInteligence。评论抓取功能现已上线，但仍有很大改进空间！

待完成

AI Twitter 摘要

所有摘要均由 Claude 3 Opus 完成，取 4 次运行中的最佳结果。我们正在尝试使用 Haiku 进行聚类和流程工程（flow engineering）。

GPT-4 和 Claude 更新

• GPT-4 Turbo 重夺排行榜首位：@lmsysorg 指出 GPT-4-Turbo 已重新夺回 Arena 排行榜第一名，在 Coding（编程）、Longer Query（长查询）和 Multilingual（多语言）等多个领域表现优于其他模型。它在纯英文提示词和包含代码片段的对话中表现更为强劲。
• 发布新版 GPT-4 Turbo 模型：@sama 和 @gdb 宣布在 ChatGPT 中发布了新的 GPT-4 Turbo 模型，该模型显著更智能且使用体验更佳。@miramurati 确认这是最新的 GPT-4 Turbo 版本。
• 新版 GPT-4 Turbo 的评估数据：@polynoamial 和 @owencm 分享了评估数据，与之前的版本相比，MATH 提升了 +8.9%，GPQA 提升了 +7.9%，MGSM 提升了 +4.5%，DROP 提升了 +4.5%，MMLU 提升了 +1.3%，HumanEval 提升了 +1.6%。
• Claude Opus 在某些方面仍优于新版 GPT-4：@abacaj 和 @mbusigin 指出，在他们的使用中，Claude Opus 仍然优于新的 GPT-4 Turbo 模型，表现得更智能且更具创造力。

开源模型与框架

• Mistral 模型：@MistralAI 发布了新的开源模型，包括 Mixtral-8x22B 基础模型，它是微调的利器 (@_lewtun)，以及 Zephyr 141B 模型 (@osanseviero, @osanseviero)。
• Medical mT5 模型：@arankomatsuzaki 分享了 Medical mT5，这是一个针对医学领域的开源多语言 text-to-text LLM。
• LangChain 和 Hugging Face 集成：@LangChainAI 发布了更新以支持跨模型提供商的 tool calling（工具调用），以及一个用于将工具附加到模型的标准 bind_tools 方法。@LangChainAI 还更新了 LangSmith，以支持在各种模型的 trace（追踪）中渲染 Tools 和 Tool Calls。
• Hugging Face Transformer.js：@ClementDelangue 注意到 Transformer.js（一个在浏览器中运行 Transformer 的框架）登上了 Hacker News。

研究与技术

• 从文字到数字 - LLMs 作为回归器：@_akhaliq 分享了一项研究，分析了预训练的 LLMs 在给定 in-context 示例时执行线性及非线性回归的表现，其效果可媲美或超越传统的监督学习方法。
• 高效的无限上下文 Transformers：@_akhaliq 分享了来自 Google 的一篇论文，该论文将压缩内存集成到原生的 attention 层中，使 Transformer LLMs 能够以有限的内存和计算量处理无限长的输入。
• OSWorld 基准测试：@arankomatsuzaki 和 @_akhaliq 分享了 OSWorld，这是首个面向多模态 Agent 的可扩展真实计算机环境基准测试，支持在各种操作系统上进行任务设置、基于执行的评估和交互式学习。
• ControlNet++：@_akhaliq 分享了 ControlNet++，它通过高效的一致性反馈改进了 Diffusion 模型中的条件控制。
• 在有限区间内应用引导：@_akhaliq 分享了一篇论文，表明在有限区间内应用引导可以提高 Diffusion 模型中的样本和分布质量。

行业新闻与观点

• WhatsApp 与 iMessage 之争：@ylecun 将 WhatsApp 与 iMessage 的争论比作公制与英制之争，指出全世界都在使用 WhatsApp，除了部分紧抱 iPhone 的美国人或禁用该应用的国家。
• AI Agents 将无处不在：@bindureddy 预测 AI Agents 将无处不在，通过 Abacus AI，你可以让 AI 在 5 分钟到几小时的简单过程中构建这些 Agents。
• Cohere Rerank 3 模型：@cohere 和 @aidangomez 推出了 Rerank 3，这是一个用于增强企业搜索和 RAG 系统的基座模型，能够以 100 多种语言精确检索多维度和半结构化数据。
• Anthropic 因信息泄露解雇员工：@bindureddy 报道称 Anthropic 解雇了 2 名员工，其中一人是 Ilya Sutskever 的好友，原因是泄露了一个内部项目的信息，该项目可能与 GPT-4 有关。

梗与幽默

• 关于 LLM 模型名称的梗：@far__el 调侃了复杂的模型名称，如 “MoE-8X2A-100BP-25BAP-IA0C-6LM-4MCX-BELT-RLMF-Q32KM”。
• 关于 AI 个人助手模式的梗：@jxnlco 调侃称，每家公司的 AI 个人助手模式都有两种——哲学家和集成地狱，并将其比作认识论与身份验证错误（auth errors）。
• 关于 LLM 幻觉的笑话：@lateinteraction 调侃道，他们担心一旦人们意识到 AGI 并不遥远，且目前还没有可靠的通用 LLMs 或 “Agents”，泡沫就会破裂；并建议更明智的做法是认识到 LLMs 主要为构建解决特定任务的 AI 提供了取得普遍进展的机会。

AI Discord 摘要

摘要之摘要的摘要

• Mixtral 和 Mistral 模型受到关注：Mixtral-8x22B 和 Mistral-22B-v0.1 模型引发了热议，后者标志着首次成功将 Mixture of Experts (MoE) 模型转换为稠密（dense）格式。讨论围绕它们的能力展开，例如 Mistral-22B-v0.1 的 220 亿参数。新发布的 Zephyr 141B-A35B 是 Mixtral-8x22B 的微调版本，也引起了人们的兴趣。

• Rerank 3 与 Cohere 的搜索增强：Rerank 3 是 Cohere 为企业搜索和 RAG 系统推出的新基础模型，支持 100 多种语言，拥有 4k 上下文长度（context length），并提供高达 3 倍的推理速度提升。它与 Elastic 的 Inference API 原生集成，为企业搜索提供动力。

• CUDA 优化与量化探索：工程师们正在优化 CublasLinear 等 CUDA 库以实现更快的模型推理，同时讨论 4-bit、8-bit 等量化策略以及 High Quality Quantization (HQQ) 等新方法。通过修改 NVIDIA 驱动程序，实现了 4090 GPU 上的 P2P 支持，从而带来了显著的加速。

• Scaling Laws 与数据过滤研究发现：一篇新论文 “Scaling Laws for Data Filtering” 认为，数据清洗（data curation）不能脱离计算资源而独立存在，并引入了处理异构网络数据的 Scaling Laws。社区正在思考其影响并试图理解所采用的实证方法。

其他值得关注的讨论包括：

• GPT-4 Turbo 的发布及其在 Coding 和 Reasoning 任务上的表现
• Ella 在动漫图像生成方面的表现不佳
• 对 Stable Diffusion 3 的期待及其解决当前模型局限性的潜力
• Hugging Face 的 Rerank 模型下载量突破 23 万，以及 parler-tts 库的发布
• OpenAI API 关于 Wolfram 集成和 Prompt Engineering 资源的讨论

第一部分：Discord 高层级摘要

Stability.ai (Stable Diffusion) Discord

砥砺前行，不落后于 A1111：Forge 是 Automatic1111 的一个新分支，具有性能增强功能，正广受好评。爱好者们可以在不放弃 A1111 的情况下探索 Forge，并利用 ComfyUI 模型实现更高效的工作流。

Ella 在动漫艺术方面表现不佳：使用 Ella 进行动漫风格图像生成的实验令人失望，即使使用了推荐的 Checkpoints 也未能达到用户预期。尽管寄予厚望，但 Ella 生成的动漫图像质量仍然较低，被认为无法在该领域使用。

Stable Diffusion 3 带来希望与疑虑：社区对 Stable Diffusion 3 (SD3) 充满了期待与怀疑，特别是关于它是否有潜力克服当前模型的局限性，如虚化效果（bokeh effects）、色彩保真度和名人识别。

扩展图像完美工具箱：讨论中提到了几种增强 Stable Diffusion 输出的工具和扩展，包括用于 Outpainting 的 BrushNet，以及改进建筑领域 depth-fm 和 geowizard 的解决方案，还有一个色彩校正扩展。

Cascade 因快速学习而闻名：Cascade 在 Stable Diffusion 模型中因其快速的学习能力和独特的特性而脱颖而出，尽管它的学习曲线较陡峭，被亲切地称为“SD 家族的怪表弟”。

Cohere Discord

CORS 导致 Cohere 连接崩溃：用户遇到了 CORS 策略错误，导致无法访问 Cohere dashboard，问题源于从 https://dashboard.cohere.com 到 https://production.api.os.cohere.ai 的跨域 JavaScript fetch 请求。

关于上下文长度的争论：一场关于 large language models (LLMs) 中扩展上下文长度与 Retrieval-Augmented Generation (RAG) 有效性的激烈讨论展开，辩论焦点在于计算成本和长上下文收益递减的问题。

Rerank 3 的定价与促销：Rerank V3 已发布，定价为每 1k 次搜索 2 美元，并提供 50% 的首发促销折扣。对于需要旧版本的用户，Rerank V2 仍以每 1k 次搜索 1 美元的价格提供。

Cohere 微调与部署指南：出现了关于 Cohere LLMs 的本地化（on-premise）和基于平台的微调可能性的问题，以及在 AWS Bedrock 或类似本地场景下的部署选项。

Rerank 3 增强搜索概览：Rerank 3 推出以增强企业搜索，声称推理速度提高了三倍，并凭借其扩展的 4k 上下文支持 100 多种语言。它与 Elastic’s Inference API 集成以改进企业搜索功能，并提供了 Cohere-Elastic 集成指南和实用的 notebook 示例等资源。

Unsloth AI (Daniel Han) Discord

Ghost 7B 精通多语言：新的 Ghost 7B 模型因其在越南语推理和理解方面的出色表现而引起轰动，受到 AI 社区的热切期待。它被强调为一个更紧凑的多语言替代方案，可以满足专业知识需求。

微调挑战的双重审视：讨论中提到了微调 NLP 模型的困难，指出充满希望的训练评估与令人失望的实际推理性能之间存在差距。特别是，非英语 NLP 环境中缺乏准确性一直是工程师们感到沮丧的点。

寻求高效的模型部署策略：工程师们正在积极分享策略和资源，以简化 Mistral-7B 训练后的部署。对 VRAM 限制的担忧依然存在，促使了关于优化 batch sizes 和嵌入上下文 token 以节省内存的讨论。

Unsloth AI 倡导扩展上下文窗口：Unsloth AI 框架因减少 30% 的内存使用且仅增加 1.9% 的时间开销，同时支持长达 228K 的上下文窗口微调而受到赞誉，其博客中详细介绍了这一点。与之前的基准测试相比，这是一个重大飞跃，为 LLM 开发提供了新途径。

领域特定数据的重要性：大家一致认为需要更精确的领域特定数据集，因为通用数据收集对于需要详细上下文的专业模型来说是不够的。最佳实践仍在讨论中，许多人转向 Hugging Face 等平台寻求高级数据集解决方案。

Nous Research AI Discord

• RNN 复兴指日可待：一篇发表在 arXiv 上的新论文表明，一种新兴的混合架构可能会为用于序列数据处理的循环神经网络 (RNNs) 注入新的活力。据报道，Google 投资了一个新的 70 亿参数的基于 RNN 的模型，这激发了社区对未来应用的兴趣。

• Google 凭借 Gemma 引擎进军 C++：社区注意到 Google 为其 Gemma 模型发布了一个 C++ 推理引擎，引发了广泛好奇。该独立引擎是开源的，可以通过其 GitHub 仓库访问。

• 微调 Hermes 需要雄厚的财力：微调 Nous Hermes 8x22b 似乎非常耗钱，据传需要每周大约 “$80k” 的基础设施成本。详细的基础设施细节尚未披露，但显然，这并非易事。

• 全力挖掘 Apple AI 的潜力：工程师们正密切关注 Apple 的 M 系列芯片，期待 M4 芯片 及其传闻中的 2TB RAM 支持。M2 Ultra 和 M3 Max 的 AI 推理能力，尤其是它们的低功耗，赢得了广泛赞誉。

• LLMs 在医疗领域备受关注但需谨慎：在医疗领域使用大语言模型 (LLMs) 的影响在社区中引发了兴奋与担忧交织的情绪。有讨论指出，法律风险和人为限制阻碍了其在医疗保健领域的开发和应用。

CUDA MODE Discord

• Cublas 线性优化：自定义 CublasLinear 库优化正在加速大矩阵乘法的模型推理，尽管 Attention 机制中的瓶颈可能会削弱 “llama7b” 等模型的整体性能提升。

• 通过 P2P 实现巅峰性能：通过修改 NVIDIA 驱动，在 4090 GPU 上实现了所有 AllReduce 操作 58% 的加速。该修改实现了 14.7 GB/s 的 AllReduce，是增强支持 P2P 的 tinygrad 性能的重要一步。

• 攻克量化目标：围绕量化（如 4-bit 方法）的挑战和策略正受到关注，一种新的 HQQ (High Quality Quantization) 方法正在被讨论，以实现更优的反量化线性度。在张量计算中，发现 8-bit 矩阵乘法的速度是 fp16 的两倍，这突显了 int4 kernels 可能存在的性能问题。

• 速度突破与 CUDA 进展：A4000 GPU 通过 float4 加载实现了 375.7 GB/s 的最大吞吐量，表明了 L1 cache 的高效利用。同时，CUDA 的最新特性（如协作组 cooperative groups 和 kernel fusion）正在推动性能提升和现代 C++ 的采用，以提高可维护性。

• 社区资源共享与组织：成员们建立了共享 CUDA 资料的频道，例如重命名现有频道用于资源分发，并建议组织任务以优化工作流。一个 PMPP UI 学习小组已经启动，欢迎通过 Discord 邀请加入。

• 概念解释与学术贡献：分享了一篇关于 Ring Attention 的解释文章，旨在扩展 LLMs 的上下文窗口，并征求反馈。在学术方面，一本以 GPU 为中心的数值线性代数书籍的第 4 章正在编写中，而 Golub/Van Loan 书籍的现代 CUDA 版本也深入探讨了相关领域，深化了知识储备。一个包含 GPU 编程在内的并行计算机编程实践课程已在线开放。

Perplexity AI Discord

• GPT-4 在 Perplexity 中的热度：工程师们对 GPT-4 在 Perplexity 中的集成感到好奇，询问其功能和 API 可用性。同时，一些用户讨论了 Perplexity 在传统搜索之外的能力，建议将其定位为搜索和图像生成的复合工具。

• 扩展 API 产品：一场热烈的对话探讨了将 Perplexity API 集成到电子商务中，并引导用户查阅 文档 以获取指导。然而，关于 API 中是否提供 Pro Search 功能的咨询得到了明确的否定回答。

• 编写完美的扩展程序：技术讨论集中在通过浏览器扩展增强 Perplexity 的实用性，尽管客户端抓取（client-side fetching）带来了一些限制。GitHub 上的 RepoToText 等工具被提及作为将 LLM 与仓库内容结合的资源。

• 搜索轨迹与技术轨迹：用户积极分享了 Perplexity AI 的搜索链接，标志着在该平台上扩大协作的趋势。搜索内容涵盖了从不明物体到访问日志和 NIST 标准等深度技术问题，反映了人群的多样化兴趣。

• 期待路线图的实现：用户关注着 Perplexity 的未来，有人寻求引用功能的更新，并参考 功能路线图 来明确即将推出的增强功能。路线图似乎计划了多个延伸至 6 月的更新，尽管目前尚未提及备受期待的来源引用（source citations）。

LM Studio Discord

量化探索继续：Mixtral-8x22B 模型现已完成量化并可供下载，但它尚未经过微调（fine-tuned），可能会对无法处理 8x7b 版本的系统产生挑战。模型加载错误可以通过升级到 LM Studio 0.2.19 beta preview 3 来解决。

应对大模型困境：用户分享了在配置不足的硬件上运行大模型的经验，建议使用云解决方案或进行硬件升级，如 NVIDIA 4060ti 16GB。对于处理时间序列数据的用户，建议使用 Temporal Fusion Transformer (TFT)，认为它非常适合该任务。

GPU vs. CPU：性能之谜：运行 AI 模型时，更多的系统内存有助于加载更大的 LLM，但使用像 NVIDIA RTX A6000 这样的显卡进行全 GPU 推理（full GPU inference）才是获得最佳性能的关键。

Linux 中新兴的 ROCm 谜团：对 amd-rocm-tech-preview 支持感到好奇的 Linux 用户仍处于等待状态，而拥有 7800XT 等兼容硬件的用户报告在执行任务时出现电感啸叫（coil whine）。同时，为 Windows 构建 gguf-split 二进制文件是 AMD 硬件测试的一个障碍，需要查阅 GitHub 讨论和 Pull Requests 以获取指导。

BERT 的边界与 Embedding 利用：如果没有针对特定任务的微调，Google BERT models 通常无法直接在 LM Studio 中使用。对于利用 LM Studio 进行文本嵌入（text embeddings），推荐使用参数量更大的模型，如 mxbai-large 和 GIST-large，而非标准的 BERT base 模型。

请注意，虽然此摘要内容详尽，但特定频道可能包含更多与 AI 工程师相关的详细讨论和链接。

Eleuther Discord

BERT 的双向难题：工程师们提出了扩展 BERT 等 encoder models 上下文窗口的复杂性，提到了双向机制的困难，并指向了应用 FlashAttention 的 MosaicBERT，同时质疑尽管有贡献，但为何在流行库中仍缺失该功能。

用 Google 的 Mixture-of-Depths 模型重新思考 Transformer：研究人员正在讨论 Google 创新的 Mixture-of-Depths 方法，该方法在基于 Transformer 的模型中以不同方式分配计算资源。同样引起关注的是 RULER 新开源但最初为空的仓库 此处，旨在揭示长上下文语言模型的真实上下文大小。

明智地扩展数据山：分享了一篇论文，提出 data curation 是必不可少的，且不能忽视计算限制。讨论包括在 scaling laws 中对基于熵的方法的符号搜索，以及对基础研究原则的反思。

大语言模型中的古怪行为困扰分析师：成员们对 NeoX 的 embedding layer 行为表示好奇，质疑训练期间是否省略了 weight decay。他们将 NeoX 的输出与其他模型进行了对比，并确认了独特行为，引发了对技术细节和影响的好奇。

量化探索与数据集困境：社区努力包括尝试进行 2-bit quantization 以减少 Mixtral-8x22B 模型的 VRAM 占用，同时对 The Pile 数据集不一致的大小以及缺乏针对各种存档类型的提取代码感到困惑。

OpenRouter (Alex Atallah) Discord

• Mixtral 的扩张与收缩：发布了一个名为 Mixtral 8x22B:free 的新模型，增强了路由和速率限制的清晰度，并拥有更新至 65,536 的 context size。然而，它很快被禁用，促使用户转向其目前活跃的对应版本 Mixtral 8x22B。

• 新实验模型登场：社区有两个新的实验模型可供试用：Zephyr 141B-A35B（Mixtral 8x22B 的指令微调版本）和 Fireworks: Mixtral-8x22B Instruct (preview)，为 AI 领域增添了色彩。

• 购买流程中的障碍：寻求 token 的购买者遇到了小故障，触发了快照分享，并据推测是要求解决交易流程中的问题。

• 平台困境的自救：一名陷入登录困境的用户发现了一种自救策略，巧妙地完成了账号注销。

• Turbo 故障与个人 AI 愿景：讨论范围从通过 Heroku 重新部署来解决 GPT-4 Turbo 故障，到定制交织了 LibreChat 等工具的 AI 设置。深入探讨 AI 模型的特性和调优平衡点也是热门话题，其中 Opus、Gemini Pro 1.5 和 MoE 结构备受关注。

Modular (Mojo 🔥) Discord

• Mojo 的社区代码贡献：服务器成员对 Mojo 开源其标准库表示赞赏，这促进了社区的贡献和增强。讨论围绕着将 Modular 集成到 BackdropBuild.com 的开发者队列项目中展开，但成员们也被提醒将业务咨询保留在适当的频道中。

• Karpathy 关注 Mojo 移植版：由 Andrej Karpathy 的 llm.c 仓库中的 GitHub issue #28 引发的一场激动人心的讨论，重点关注 Mojo 移植版的基准测试和对比前景，作者本人也表示有兴趣链接到任何由 Mojo 驱动的版本。

• 行与列：矩阵大对决：Modular 博客上的一篇资讯文章详细分析了行优先（row-major）与列优先（column-major）矩阵存储及其在 Mojo 和 NumPy 中的性能表现，启发了社区对编程语言和库的存储偏好的理解。

• Mojo 的终端时尚：成员们展示了使用 Mojo 在终端中进行的高级文本渲染，演示了受 charmbracelet's lipgloss 启发的功能和界面。分享了代码片段和实现示例，预览可在 GitHub 上查看。

• 矩阵博客的小失误：寻求帮助：一位成员指出在执行 “行优先 vs. 列优先矩阵” 博客文章中的 Jupyter notebook 时出现错误，遇到了 ‘mm_col_major’ 声明的问题。这一反馈为社区支持的调试提供了机会，该 notebook 位于 devrel-extras GitHub 仓库。

LangChain AI Discord

• LangChain 的 PDF 摘要速度提升：强调了一种提高 LangChain 的 load_summarization_chain 函数在处理大型 PDF 文档时摘要效率的方法，GitHub 上提供了一个演示 map_reduce 优化方法的代码片段。

• LangChain AI 推出新教程：最近推出的一项教程阐明了 LCEL 以及使用 runnables 组装 chain 的方法，为工程师提供动手学习的机会并征求反馈；详见 Medium。

• GalaxyAI API 正式发布：GalaxyAI 首次推出了与 Langchain 无缝衔接的免费 API 服务，引入了 GPT-4 和 GPT-3.5-turbo 等强大的 AI 模型；集成细节可在 GalaxyAI 查看。

• 警报：垃圾成人内容侵入 Discord：有报告称在多个 LangChain AI 频道中分享了不当内容，这违反了 Discord 社区准则。

• Meeting Reporter 将 AI 与新闻业结合：新工具 Meeting Reporter 利用 AI 生成新闻报道，结合了 Streamlit 和 Langgraph，需要付费的 OpenAI API 密钥。该应用程序可通过 Streamlit 访问，开源代码托管在 GitHub 上。

注意：本摘要中主动忽略了与成人内容推广相关的链接，因为它们显然与该公会的技术和工程讨论无关。

HuggingFace Discord

推文提醒：osanseviero 分享新闻：osanseviero 发布了推文，可能暗示了新的见解或更新；点击此处查看。

RAG 聊天机器人采用嵌入数据集：该 RAG 聊天机器人使用 not-lain/wikipedia-small-3000-embedded 数据集来辅助回答，结合了检索和生成式 AI 以实现准确的信息推理。

RMBG1.4 广受欢迎：RMBG1.4 与 transformers 库的集成引起了极大关注，本月下载量达到 23 万次。

Marimo-Labs 创新模型交互：Marimo-labs 发布了一个 Python 包，允许为 Hugging Face 模型创建交互式 Playground；一个基于 WASM 的 marimo 应用让用户可以使用自己的 token 查询模型。

NLP 社区追求更长上下文的 Encoder：AI 工程师讨论了对 BigBird 和 Longformer 等 Encoder-Decoder 模型的追求，以处理约 10-15k token 的长文本序列，并分享了使用 trainer.train() 的 resume_from_checkpoint 进行训练中断和恢复的策略。

视觉与 Diffusion 成果：通过 nvitop 增强了 GPU 进程管理，同时开发者通过增强和时间维度考量来解决视频修复问题，参考了 NAFNet、BSRGAN、Real-ESRGAN 和 All-In-One-Deflicker 等作品。同时，人们正在寻求对 Google 多模态搜索能力的深入了解，以提高图像和拼写错误品牌的识别率，并对 AI-demos 的识别技术底层原理表现出兴趣。

Latent Space Discord

• 混合搜索重排序（Reranking）再探讨：工程师们讨论了在重排序之前合并词法（lexic）和语义（semantic）搜索结果是否优于同时合并并重排序所有结果。重排序步骤的衔接可以简化流程并降低搜索方法的延迟。

• Rerank 3 彻底改变搜索：Cohere 的 Rerank 3 模型宣称增强了搜索和 RAG 系统，具有 4k 上下文长度和支持 100 多种语言的多语言能力。其发布详情和功能在 Sandra Kublik 的推文中分享。

• AI 市场因创新而升温：创新的基于 AI 的工作自动化工具（如 V7 Go 和 Scarlet AI）的兴起，表明了自动化单调任务和促进 AI 与人类协作执行任务的增长趋势。

• Perplexity 的“在线”模型消失后回归：社区讨论了 Perplexity 的“在线”模型从 LMSYS Arena 消失后又重新出现的情况，这些模型具备联网能力。随着 GPT-4-Turbo 在 Lmsys 聊天机器人排行榜上重夺领先地位，人们的兴趣再次被点燃，这标志着其强大的代码和推理能力。

• Mixtral-8x22B 登场：HuggingFace Transformers 格式的 Mixtral-8x22B 的出现引发了关于其用途以及对 Mixture of Experts (MoEs) 架构影响的讨论。社区探讨了专家特化、MoEs 内部的学习过程以及 semantic router 等话题，关注冗余和专家实现中潜在的差距。

• 播客：AI 的监督角色：新的一期播客节目呈现了与 Elicit 的 Jungwon Byun 和 Andreas Stuhlmüller 关于监督 AI 研究的讨论。可通过 YouTube 链接观看，探讨了以产品为导向的方法相较于传统以研究为导向的方法的优势。

LAION Discord

Draw Things 遭到批评：参与者对 Draw Things 表示失望，指出其缺乏完整的开源方案；提供的版本省略了包括 metal-flash-attention support 在内的关键功能。

TempestV0.1 令人质疑的训练成果：社区成员对 TempestV0.1 Initiative 声称的 300 万次训练步数表示怀疑，同时质疑其包含 600 万张图像的数据集仅占用 200GB 的物理合理性。

LAION 5B Demo 会重新上线吗？：关于 Laion 5B 网络演示，尽管有提到 Christoph 表示其将回归，但目前尚不确定具体时间，也没有给出时间表或进一步信息。

LAION 诈骗警报：有关滥用 LAION 名义的加密货币计划等诈骗行为正在流传，建议保持警惕，并讨论了通过发布公告或增强自动审核（automatic moderation）来应对此问题。

Diffusion 和 LRU 算法的进展：社区正在评估在 Long Range Arena 基准测试中改进的 Least Recently Used (LRUs) 算法，并讨论增强 Diffusion 模型的 guidance-weight 策略，相关的研究（研究论文）和活跃的 GitHub issue（GitHub issue）正被应用于 huggingface 的 diffusers。

LlamaIndex Discord

• Pandas 迁移：PandasQueryEngine 将随 LlamaIndex python v0.10.29 迁移至 llama-index-experimental，安装将通过 pip install llama-index-experimental 进行。需要调整 Python 代码中的 import 语句以反映此更改。

• 提升 GitHub 聊天体验：一个新教程展示了如何创建一个应用，实现与来自 GitHub 仓库的代码进行对话，并将 LLM 与 Ollama 集成。另一个教程详细介绍了如何使用基于 Colbert 的 Agent 为 LlamaIndex 的文档检索引入 memory 功能，从而提升检索过程。

• 动态组合：结合 Auto-Merging 增强的 RAG：一种新颖的 RAG 检索方法包括自动合并，旨在从破碎的上下文中形成更连续的 chunks。相比之下，关于 Q/A 任务的讨论显示，由于 Retriever Augmented Generation (RAG) 在准确性、成本和灵活性之间的平衡，它比微调 LLM 更受青睐。

• 符合 GDPR 的 AI 应用工具包：受 Llama Index 的 create-llama 工具包启发，create-tsi toolkit 是由 T-Systems 和 Marcus Schiesser 推出的一个全新的、符合 GDPR 标准的 AI 应用基础设施。

• 调试 Embeddings 和 Vector Stores：讨论澄清了关于 Embedding 存储的困惑，透露它们驻留在 storage context 内的 vector stores 中。对于某些导致 QdrantVectorStore 崩溃的 ‘fastembed’ 问题，解决方案是降级到 llama-index-vector-stores-qdrant==0.1.6，且从 Embeddings 中排除 metadata 需要在代码中进行显式处理。

OpenInterpreter Discord

安装过程中的麻烦：成员们报告了安装 Poetry 和 litellm 时遇到的问题——前者的成功修复方法包括运行 pip install poetry，而诊断 litellm 问题则涉及使用 interpreter --version 和 pip show litellm。进一步的故障排除指出，安装 Python 和特定的 git commits 对于恢复包是必要的。

对未来科技硬件保持耐心：关于新设备的预订和交付的咨询显示，一些科技硬件仍处于原型阶段，预计将在夏季月份发货。对话强调了初创公司在制造过程中面临的典型延迟，并鼓励热切的科技爱好者保持耐心。

JavaScript 重新定义 Transformers：transformers.js GitHub repository 提供了一种基于 JavaScript 的机器学习解决方案，能够在无需服务器的情况下在浏览器中运行，这引起了 AI 工程师的兴趣。同时，一个指向 https://api.aime.info 的 AI 模型 endpoint 的神秘提及也出现了，但没有更多细节或宣传。

OpenAI 的额度策略：OpenAI 从按月计费转向预付 credits，其中包括一项免费额度推广活动（截止日期为 2024 年 4 月 24 日），这引发了成员们的好奇心，并就不同账户类型的后续影响进行了大量信息交流。

活动与贡献：社区活动 Novus 的邀请函反响热烈，工程师们期待着没有冗余信息的社交机会；同时，关于将 Open Interpreter 作为库使用的成功分享产出了一个包含 Python templates 的仓库，供初学者使用。

OpenAccess AI Collective (axolotl) Discord

讨论 AI 开发的策略与预期：

• 参与者探讨了在神经网络模型中 freezing layers 的影响，认为虽然减少层数可以简化模型，但也可能降低有效性，从而暗示了复杂性与资源效率之间的微妙平衡。关于语言模型 scaling 理论基础的讨论链接，特别是 Meta 关于知识位 scaling 的研究（Physics of Language Models: Part 3.3, Knowledge Capacity Scaling Laws），表明 LLaMA-3 可能会进一步推进这种平衡。

训练挑战与模型修改：

• 将 Mistral-22B 从 Mixture of Experts 转换为 dense model (Vezora/Mistral-22B-v0.1) 一直是焦点，这表明社区对 dense architectures 的兴趣，可能是因为它们与现有基础设施的兼容性。同时，关于以 11 层为增量进行训练的讨论表明，人们正在寻求适应有限 GPU 能力的训练策略。

生态扩展与协助：

• 该集体致力于降低 AI 开发过程的门槛，这从为新成员提供的 Axolotl 入门建议中可见一斑，这些建议体现在一篇富有见地的 blog post 和实用技巧（如使用 --debug 标志）中。此外，维护的 Colab notebook example 协助用户在 Hugging Face 数据集上 fine-tuning Tiny-Llama 等模型。

资源受限下的机智：

• 对话围绕着创新的训练策略展开，例如为硬件配置较低的用户 unfreezing random subsets of weights，证明了对训练方法民主化的关注。共同分享 pretrain configs，以及利用 Docker 和 DeepSpeed 进行 multi-node fine-tuning 的分步干预，展示了社区在受限环境下驾驭高端训练策略的决心。

好奇心驱动数据获取：

• 对形式逻辑推理数据集和大规模 200-billion token 数据集的查询，描绘了对具有挑战性的大规模数据的积极寻找，以突破模型 pretraining 和实验的界限。

OpenAI Discord

API 因 AttributeError 受阻：一位 OpenAI API 用户在 Python 的 client.beta.messages.create 方法中遇到了 AttributeError，这引发了人们对文档可能与库更新不同步的担忧。分享的代码片段在社区讨论中未能得出解决方案。

模型成为焦点：成员们分享了使用 Gemini 1.5 和 Claude 等 AI 模型的不同经验，涉及上下文窗口、内存和代码查询处理方面的差异。针对 Unity 中的 C# 开发，为了保证效率，建议使用 gpt-4-turbo 和 Opus 模型。

GPT-4 Turbo 的效率障碍：一位成员观察到 GPT-4-turbo 模型在函数调用（function calls）方面似乎表现欠佳，而另一位成员则不确定如何访问它；然而，讨论中并未提供详细的示例或解决方案。

使用 LLM 进行大规模文本编辑：关于使用 GPT 编辑大型文档的咨询引发了讨论，内容涉及可能需要第三方服务来绕过标准的上下文窗口限制。

探索提示工程银河：对于那些开始学习提示工程（prompt engineering）的人，Prompting Guide 被推荐为学习资源，而将 Wolfram 与 GPT 集成可以通过 Wolfram GPT 链接和平台内的 @mention 功能来实现。

DiscoResearch Discord

稠密模型的重大胜利：Mistral-22B-V.01 的发布（一个全新的 22B 参数稠密模型）标志着一项显著成就，因为它从压缩的混合专家模型（MoE）转变为稠密形式，为 MoE 到 Dense 模型的转换领域树立了先例。

跨语言难题与语料库对话：虽然工程师们正致力于在 DiscoLM 70b 等模型中平衡英语和德语数据，并计划更新模型，但他们提到需要更好的德语基准测试（benchmarks）。Occiglot-7B-DE-EN-Instruct 展示了潜力，暗示英语和德语训练数据的混合可能是有效的。

筛选 SFT 策略：社区分享了在预训练阶段早期集成有监督微调（SFT）数据的潜在益处，这得到了来自 StableLM 和 MiniCPM 研究的支持，旨在增强模型的泛化能力并防止过拟合。

Zephyr 凭借 ORPO 翱翔：Zephyr 141B-A35B 亮相，它衍生自 Mixtral-8x22B，并通过名为 ORPO 的新算法进行了微调，目前可在 Hugging Face 模型中心进行探索。

MoE 合并带来的挑战：社区使用 Mergekit 通过合并创建自定义 MoE 模型的实验表现平平，这引发了关于在窄领域进行 SFT 与传统 MoE 模型实用性的持续辩论。

Interconnects (Nathan Lambert) Discord

是增量还是进化？：Nathan Lambert 发起了一场辩论，讨论从 Claude 2 到 Claude 3 的跨越是代表了真正的进步，还是仅仅是 “增量式” 的改进，对 AI 版本更新的实质内容提出了质疑。

一砖一瓦构建更好的模型：成员们讨论了预训练、有监督微调 (SFT) 和 RLHF 的混合使用，指出这些技术通常是结合在一起的，尽管这种实践的文档记录很少。一位成员承诺将分享关于在这一系列混合方法中应用退火（annealing）技术的见解。

随意的祝贺演变成幽默：一个 meme 意外地表达了祝贺，引发了幽默时刻，而另一场对话则澄清了该服务器不需要接受即可订阅。

谷歌 CodecLM 备受关注：社区研究了谷歌的 CodecLM（分享于一篇研究论文中），指出这是通过使用定制合成数据实现“向更强模型学习”趋势的又一尝试。

关于 LLaMA 的学术交流：发布了 “LLaMA: Open and Efficient Foundation Language Models” 的链接，表明正在对发布日期为 2023 年 2 月 27 日的开放、高效基础语言模型的进展进行积极讨论。

tinygrad (George Hotz) Discord

• 敏捷的命名技巧大爆发：tinygrad Discord 的成员们选择了极具创意的标签，如 tinyxercises 和 tinyproblems，而俏皮的术语 tinythanks 也作为对话中的感谢表达而出现。
• 缓存层级之争：聊天中的技术交流指出，由于最小化了缓存一致性管理的需求，L1 caches 相比池化共享缓存具有更优越的速度。这次讨论强调了将直接的 L3 to L1 cache transfers 与异构缓存架构进行比较时的性能差异。
• 思考编程语言的可移植性：对话揭示了一种对比观点，即 ANSI C 广泛的硬件支持和易移植性，与对 Rust 安全性的共同审查形成对比，后者通过一个已知 Rust 漏洞链接被揭开了神秘面纱。
• 商标策略引发讨论：针对 Rust Foundation 限制性的商标政策 发表了具有争议的观点，引发了与 Oracle 和 Red Hat 等其他实体及其自身备受争议的许可条款的比较。
• Discord 纪律执行：George Hotz 明确表示，在他的 Discord 中不允许无关痛痒的闲聊，导致一名用户因对专注的技术讨论缺乏贡献而被禁言。

Skunkworks AI Discord

• 寻找逻辑宝库：AI 工程师们分享了一个精选列表，其中充满了旨在增强自然语言中形式逻辑推理的数据集，为逻辑与 AI 交叉领域的项目提供了宝贵资源。
• 文献建议：增强 LLM 中的 Coq 能力：一篇 arXiv 论文 受到关注，该论文解决了提高大语言模型解释和生成 Coq proof assistant 代码能力的挑战——这是推进形式化定理证明能力的关键。
• 将符号能力集成到 LLM 中：工程师们对 Logic-LLM 产生了兴趣，这是一个讨论实现符号求解器以提升语言模型逻辑推理准确性的 GitHub 项目。
• 通过 Lisp 翻译升级推理能力详解：对一个通过将人类文本翻译为可执行的 Lisp 代码来增强 LLM 的项目进行了说明，旨在通过在 LLM 的潜空间（latent space）内进行计算来增强推理，同时保持端到端的可微性。
• 推理仓库内容更丰富了！：awesome-reasoning repo 的 提交历史 更新了新资源，成为了支持推理 AI 开发的更全面的汇编。

LLM Perf Enthusiasts AI Discord

• 对 Haiku 速度炒作的质疑：社区成员正在质疑 Haiku 声称的速度提升，特别关注它是否显著改善了总响应时间，而不仅仅是吞吐量。
• Turbo 成为焦点：讨论中的工程师对新发布的 turbo 在速度和代码处理方面的改进很感兴趣，一些人正在考虑重新激活 ChatGPT Plus 订阅以实验 turbo 的功能。

Alignment Lab AI Discord

代码求助：一名公会成员寻求精通此道的同僚通过私信提供代码帮助。

服务器邀请审查：对服务器上过度分享 Discord 邀请的行为表示担忧，引发了关于可能禁止此类行为的讨论。

OO2 项目状态检查：对 OO2 项目的当前状态进行了简单的询问，质疑其活跃度。

Datasette - LLM (@SimonW) Discord

• Gemini 听取并学习：Gemini 模型已增强，能够回答有关视频中音频的问题，这标志着其从早期只能生成非音频描述的限制中取得了进步。

• Google 的文本粘贴问题依然存在：技术讨论指出，在粘贴到 Google 平台时，其文本格式问题一直令人沮丧，影响了用户效率。

• STORM 项目的巨大影响力：工程师们关注到了 STORM 项目，这是一个由 LLM 驱动的知识策展系统，强调了其自主研究主题并生成带有引用的全面报告的能力。

• macOS Zsh 命令挂起问题已修复：在 macOS zsh shell 上使用 llm 命令时的挂起问题已通过最近的 Pull Request 解决，并已在 M1 Macs 的 Terminal 和 Alacritty 上验证了功能。

Mozilla AI Discord

• Figma 与 Gradio 合作：Mozilla Innovations 发布了 Gradio UI for Figma，受 Hugging Face 的 Gradio 启发，该库为设计师提供了快速原型设计的能力。Figma 用户现在可以访问此工具包以增强设计工作流。

• 加入 Gradio UI 对话：来自 Mozilla Innovation Studio 的 Thomas Lodato 正在主持关于 Gradio UI for Figma 的讨论；对用户界面感兴趣的工程师可以在此加入讨论。

• llamafile OCR 潜力解锁：社区对 llamafile 的 OCR 能力 兴趣日益浓厚，成员们正在探索该功能的各种应用。

• Rust 在 AI 领域的狂热：推荐了一个名为 Burnai 的新项目，它利用 Rust 进行深度学习推理（inference），并具有性能优化；请关注 burn.dev 并考虑 justine.lol/matmul 以获取 Rust 相关的进展。

• Llamafile 获得 McAfee 认可：llamafile 0.7 binary 现已进入 McAfee 白名单，消除了用户的安全疑虑。

AI21 Labs (Jamba) Discord

寻找 Jamba 的起源：一位社区成员表示希望找到 Jamba 的源代码，但未提供 URL 或源代码位置。

渴望掌握模型合并技术：分享了一个 GitHub 仓库链接 moe_merger，该仓库提出了一种模型合并的方法论，尽管目前仍处于实验阶段。

为协作点赞：用户对合并模型的资源表示感谢，表明社区对该贡献有积极的反响。

充满期待：用户对更新充满期待，可能涉及正在进行的项目或之前消息中的讨论。

共享智慧待命：用户正在分享资源并表达感谢，展示了一个积极交换信息和支持的协作环境。

PART 2: Detailed by-Channel summaries and links

Stability.ai (Stable Diffusion) ▷ #general-chat (846 messages🔥🔥🔥):

• 介绍 Forge：Forge 是 Automatic1111（或 A1111）的一个分支（fork），因其相对于 A1111 的性能提升而受到赞誉。鼓励用户尝试，特别是它不需要卸载 A1111，并且可以使用来自 ComfyUI 的模型。

• Ella 的动漫困扰：用户报告称，Ella 虽然前景看好，但会严重降低生成的动漫风格图像的质量，使其无法用于该流派。尽管尝试了各种 Checkpoints（包括 Ella 创作者推荐的），用户仍无法获得满意的结果。

• 对 SD3 的期待：在社区中，对于 Stable Diffusion 3 (SD3) 的发布既有兴奋也有怀疑，讨论围绕着对 SD3 解决当前生成模型局限性的期望，如处理背景虚化（bokeh）效果、色彩准确度和名人识别。

• 工具和扩展琳琅满目：社区讨论了各种改进 Stable Diffusion 输出的工具和模型扩展，例如用于外扩填充（outpainting）的 BrushNet、depth-fm、用于建筑的 geowizard 以及一个用于色彩准确度的扩展。鼓励用户探索并关注最新发布。

• Cascade 的奇特特质：Cascade 以学习速度快和在 SD 模型中的独特特性而著称，尽管它也被描述为使用起来具有挑战性，并被亲切地称为“SD 家族中的怪表亲”。

Cohere ▷ #general (522 条消息🔥🔥🔥):

• CORS 访问故障：用户报告了一个 Cohere dashboard 无法访问的问题，确定是 CORS 策略错误阻止了从 https://dashboard.cohere.com 到 https://production.api.os.cohere.ai 的 JavaScript fetch 请求。

• 关于 Command R+ 和上下文长度的引人入胜的对话：社区就 LLM 中长上下文长度的有效性和实用性与 Retrieval-Augmented Generation (RAG) 等策略展开了激烈辩论。论点包括计算效率以及增加上下文长度带来的收益递减。

• Rerank V3 发布，定价为每 1,000 次搜索 2 美元：针对 Rerank V3 的定价进行了说明，设定为每 1,000 次搜索 2 美元，由于定价变更实施较晚，目前的促销活动提供 50% 的折扣；Rerank V2 仍以每 1,000 次搜索 1 美元的价格提供。

• Cohere 微调和本地部署查询得到解答：在讨论中，有人提出了关于 在本地或通过 Cohere 平台微调 Cohere 的 LLM 的能力，以及在 AWS Bedrock 或本地环境中部署这些模型的问题。

• Cohere 社区涌现大量友好的自我介绍：新成员介绍了自己，包括来自尼日利亚的 Tayo 表达了对 Cohere 的 LLM 的感谢，以及其他表示对 AI 感兴趣或参与其中的个人。

Cohere ▷ #announcements (1 条消息):

• Rerank 3 助力增强型企业搜索：发布 Rerank 3，这是一款旨在提高企业搜索和 RAG 系统效率的基础模型，现在能够处理复杂的半结构化数据，并拥有高达 3 倍的推理速度提升。它支持 100 多种语言和 4k 的长上下文长度，以提高包括代码检索在内的各种文档类型的准确性。
• 通过 Cohere 集成提升您的 Elastic Search：Rerank 3 现在已在 Elastic 的 Inference API 中得到原生支持，从而实现企业搜索功能的无缝增强。感兴趣的开发者可以参考使用 Cohere 进行嵌入的详细指南和实操性的 Cohere-Elastic notebook 示例开始集成。
• 开启最先进的企业搜索：在他们最新的博客文章中，Rerank 3 因其最先进的能力而备受赞誉，包括大幅提升的长文档搜索质量、搜索多维度数据的能力以及多语言支持，同时保持低延迟。

Unsloth AI (Daniel Han) ▷ #general (268 条消息🔥🔥):

• Mixtral 模型困境：几位成员对 Mixtral 和 Perplexity Labs 模型存在的重复问题和行为异常表示担忧，将其行为比作故障。批评意见包括肤浅的指令微调（instruction fine-tuning）以及与基座模型类似的重复输出，一位成员提到 这个 GitHub 仓库 是创建基于搜索的模型的更好替代方案。

• 对即将推出的 Instruct 模型的期待升温：人们对新 Instruct 模型的发布表现出浓厚兴趣，一名来自 Mistral 的管理员 确认预计在一周内发布，引发了对 Llama 和 Mistral 等不同模型之间潜在对决的期待。

• 探索 LLM 中的长上下文窗口：用户深入讨论了利用高达 228K 的长上下文窗口来微调 LLM，Unsloth AI 将内存占用减少了 30%，而时间开销仅增加了 1.9%，更多详情见 Unsloth 博客。

• 寻求特定领域数据：一位成员向社区询问收集特定领域 128k 上下文大小指令数据集的最佳实践。大家提出了多种建议，包括查看 HF 数据集，但对话倾向于需要更专业和特定领域的数据收集方法。

• Unsloth AI 关于微调 LLM 的网络研讨会：Unsloth AI 举办了一场由 Analytics Vidhya 主持的网络研讨会，演示了 Unsloth 的现场 Demo 并分享了微调技巧和窍门，这引起了社区的关注，甚至导致了最后一刻的通知。他们还邀请成员参加旨在分享知识和进行 Q&A 环节的 Zoom 活动。

Unsloth AI (Daniel Han) ▷ #help (244 messages🔥🔥):

• 解决微调难题：用户讨论了微调 NLP 任务模型的挑战；其中一个涉及训练期间良好的评估指标与推理指标不佳之间的差异，另一个与他们在非英语 NLP 环境中努力训练模型以提高准确性有关。

• 模型部署对话：讨论了在使用 Unsloth AI 训练后如何部署模型，提到了可能的合并策略，并提供了 Unsloth AI GitHub wiki 的链接，以指导部署过程，包括 Mistral-7B 等模型。

• VRAM 饥饿游戏：一位成员表示，即使应用了 Unsloth 的 VRAM 效率更新，也很难将模型放入 VRAM 限制内。他们讨论了各种策略，包括微调 Batch Size 以及将上下文 Token 合并到基础模型中以节省 VRAM 使用量。

• GEMMA 微调的数据集格式化：有人寻求在自定义数据集上微调 GEMMA 的帮助，被引导使用 Pandas 将其数据转换并加载为 Hugging Face 兼容格式，并取得了成功。

• 机器学习中的 GPU 限制：在关于 Unsloth AI 多 GPU 支持的辩论中，用户澄清说，虽然 Unsloth 支持多 GPU，但官方支持和文档可能尚未更新，且许可限制旨在防止大型科技公司的滥用。简要提到的与 Llama-Factory 的集成暗示了潜在的多 GPU 解决方案。

Unsloth AI (Daniel Han) ▷ #showcase (7 条消息):

• Ghost 7B 预览: 即将推出的 Ghost 7B 模型被宣传为一款小型、多语言大模型，在推理、越南语理解和专家知识方面表现出色。社区反响热烈，用户们正期待其发布。

• 丰富低资源语言: 分享了增强低资源语言数据集的技巧，包括利用翻译数据或来自 HuggingFace 的资源。成员们对 Ghost X 项目的进展表示支持和热情。

• 社区对 Ghost X 的支持: Ghost 7B 的新版本受到了社区成员的掌声和鼓励。积极的反馈凸显了 Ghost X 项目所做的工作。

提到的链接: ghost-x (Ghost X): 未找到描述

Unsloth AI (Daniel Han) ▷ #suggestions (1 条消息):

starsupernova: 噢是的没错！我也看到了那些推文！

Nous Research AI ▷ #off-topic (15 条消息🔥):

• 分享撒钱 Gif: 一位成员发布了来自 Tenor 的 gif 链接，展示了美剧《硅谷》中 Erlich Bachman 身上撒钱的场景。
• 富有洞察力的朝鲜访谈: 分享了一个名为“Стыдные вопросы про Северную Корею”的 YouTube 视频，内容是对一位朝鲜专家的三小时访谈，配有英语字幕和配音。
• Claude AI 创作歌词: 一位成员提到，udio.com 上列出的一首歌的歌词是由名为 Claude 的 AI 创作的。
• 针对垃圾信息的自动审核: 针对邀请垃圾信息的担忧，一位成员指出已实施自动系统，如果发送者在短时间内发送过多消息，系统将删除消息并禁言该垃圾信息发送者，并向管理员发送通知。
• Claude 与 GPT-4 的对比: 一位成员表示在使用 Anthropic 的 Claude AI 时感到有些迷茫，表示更倾向于 GPT-4 的回答，认为 GPT-4 更符合他们的想法。

Nous Research AI ▷ #interesting-links (8 条消息🔥):

• RNN 的复兴：一篇新论文试图通过一种新兴的混合架构来复兴循环神经网络 (RNN)，承诺对序列数据处理领域进行深入探索。详细论文可以在 arXiv 上找到。

• 混合 RNN 可能是终局：讨论表明，在创新 RNN 架构时，趋势正向混合模型发展，这暗示了创建一个能与当前最先进结果相媲美的纯 RNN 解决方案仍面临持久挑战。

• Google 的新模型：有传言称 Google 将发布一个新的 70 亿参数模型，该模型采用了近期研究中描述的基于 RNN 的架构，表明在该领域有大量投资。

• 初创公司评估 AI 模型：一名成员分享了一篇关于一家专注于测试 AI 模型有效性的新初创公司的 Bloomberg 文章，但链接指向了一个标准的浏览器错误页面，提示 JavaScript 或 cookie 问题。文章链接为 Bloomberg。

• 值得引用的社交媒体帖子：一名成员分享了一个幽默推文的链接，内容是：“感觉很可爱，稍后可能会删。不知道。” 为频道增添了片刻的轻松氛围。推文可在此处查看。

Nous Research AI ▷ #general (369 条消息🔥🔥):

• Google 的 Gemma 引擎迎来 C++ 版本：Google 为 Gemma 推出了自己的 llama.cpp 变体。一个用于 Google Gemma 模型的轻量级、独立 C++ 推理引擎已在其 GitHub 仓库上线。

• Nous Research 雄心勃勃：对话涉及了备受期待的 Nous Hermes 8x22b 及其开发困难。Nous Hermes 的微调如果尝试进行，将需要耗资约“每周 8 万美元”的基础设施，且依赖于不易租赁的技术。

• Mac 的 AI 预测市场：关于 Apple M 系列芯片 及其在 AI 推理方面潜力的讨论引起了小组热议，M2 Ultra 和 M3 Max 因其与 Nvidia GPU 相比具有低功耗和高效率而备受关注。一些人推测未来的 M4 芯片 据传将支持高达 2TB 的 RAM。

• Models on the Move: 讨论中提到了 Mixtral-8x22b 的发布，以及实验性的 Mistral-22b-V.01。这是一个稠密的 22B 参数模型，是从一个 MOE 模型中提取出来的，发布在 Vezora Hugging Face 页面上。人们对即将发布的 V.2 版本充满期待，预计其能力将进一步增强。

• Fine-Tuning the Giants: 成员们讨论了提示工程 (Prompt Engineering) 对模型性能的影响，最近的推文表明，通过精心设计的提示，在 ConceptArc 等基准测试和国际象棋 Elo 评分上取得了显著提升。对于 GPT-4 利用该技术能在国际象棋中达到 3500+ Elo 评分的说法，也存在一些怀疑。

Nous Research AI ▷ #ask-about-llms (25 条消息🔥):

• Quest for 7B Mistral Finetuning Advice: 一位成员咨询了 7B Mistral 微调的逐步指南。建议包括使用 Unsloth 仓库，以及针对小数据集在 Colab GPU 上采用 QLoRA 而非全量微调流程，或者从 Vast 等服务商处租用高性能 GPU。

• Logic Reasoning Dataset Hunt: 一位成员正在寻找用于自然文本命题逻辑和谓词逻辑推理的数据集。另一位成员分享了 GitHub 上的 Logic-LLM 项目，并指出该项目相比标准的思维链 (Chain-of-Thought) 提示能带来 18.4% 的性能提升。

• 自由职业者寻求 Finetuning 协助：一位成员表示有兴趣聘请自由职业者，根据提供的数据集编写脚本或指导他们完成 Finetuning 过程。

• 寻找增强 Genstruct 的 Notebook：一位成员正在寻找 Notebook 或工具，以便输入抓取的数据作为 Genstruct 的引导，并发现了一个 GitHub 仓库 OllamaGenstruct，该仓库非常符合他们的需求。

• 探索 LLM 在医疗保健和医学领域的应用：成员们讨论了 LLM 在医学领域的应用，分享了论文，并提到了通过此类模型提供医疗建议的潜在法律风险。模型的人为限制和其他法律考量被认为是该领域发展的障碍。

Nous Research AI ▷ #world-sim (63 messages🔥🔥):

• Worldsim 的 UI 灵感：一位成员分享了 edex-ui GitHub 仓库的链接，该仓库展示了一个可定制的科幻终端模拟器。虽然另一位用户表示了兴趣，但有人提醒该项目已停止维护，可能存在安全隐患。
• 期待 Worldsim 的回归：频道内表现出极大的热情，多位成员讨论了 Worldsim 何时回归以及可能具备的新功能。一位成员得到确认，Worldsim 平台计划于下周三回归。
• AGI 被比作“火辣但疯狂”：在一个轻松的比喻中，一位成员将危险 UI 的吸引力等同于“火辣但疯狂”的关系。对话随后转向讨论 AGI 的定义，成员们加入了 Claude 3 Opus、AutoGen 和 Figure 01 等不同组件来构思 AGI。
• 关于 Worldsim 回归时间的推测：成员们对 Worldsim 的回归时间进行了业余预测，有人凭空猜测是周六，也有人利用 Claude 3 的预测，估计时间从即将到来的周六到下周末不等。
• 潜在替代方案和资源说明：针对 Worldsim 停机期间替代方案的查询，一位用户提到 sysprompt 是开源的，可以直接发送给 Claude，或者与 Anthropic workbench 及其他 LLM 配合使用。此外，感兴趣尝试 Claude 模型的用户可以将 Anthropic API key 粘贴到 Sillytavern 中。

CUDA MODE ▷ #general (6 messages):

• 新成员加入：一位新成员表达了通过其他成员邀请发现 CUDA MODE Discord 社区的兴奋之情。
• 视频资源库：消息提到，与社区相关的录制视频可以在 CUDA MODE 的 YouTube 频道上找到。
• P2P 增强功能发布：一项关于通过修改 NVIDIA 驱动为 4090 添加 P2P 支持的公告发布，在 tinygrad 的支持下，实现了 tinybox green 上 14.7 GB/s 的 AllReduce。
• CUDA 挑战赛博客文章：一位成员分享了他们使用 CUDA 应对“十亿行挑战”（One Billion Row Challenge）的经验和一篇博客文章，并邀请 CUDA 爱好者提供反馈。
• 资源共享频道重命名：有人建议创建一个新频道用于分享资料。随后，一个现有频道被重命名，作为分享资源的场所。

CUDA MODE ▷ #cuda (168 条消息🔥🔥):

• 探索 CublasLinear 的速度极限：成员们讨论了使用自定义 CUDA 库优化模型推理速度的方法，测试表明自定义的 CublasLinear 在处理大矩阵乘法时速度更快。然而，在 “llama7b” 等完整模型中测试时，加速效果并不显著，这可能是因为瓶颈在于 attention 而非矩阵乘法。

• 追求快速且准确的量化：辩论了各种量化策略，例如 4-bit 量化及其与其他量化方法相比的实现挑战。一位成员正在研究一种名为 HQQ (High Quality Quantization) 的方法，旨在通过使用线性反量化（linear dequantization）来超越现有的量化方法。

• 通过驱动破解实现 P2P 支持：一条消息提到通过修改 NVIDIA 驱动为 RTX 4090 添加了 P2P 支持，并提供了指向详细说明该成果的社交媒体帖子的链接。

• 新语言模型的 CUDA Kernel 愿望清单：分享了一篇介绍 RecurrentGemma（一种利用 Google Griffin 架构的开源语言模型）的论文，并引发了为其构建 CUDA kernel 的兴趣。

• 基准测试与 Kernel 挑战：对话详细描述了让 CUDA kernels 实现最佳性能和准确性的挑战，强调了从孤立测试转向完整模型集成时的性能差异，以及改变精度如何导致错误或速度限制等问题。

CUDA MODE ▷ #torch (16 条消息🔥):

• ViT 模型的量化困境：一位成员在尝试量化 google/vit-base-patch16-224-in21k 时遇到错误，并分享了相关 GitHub issue #74540 的链接。他们正在寻求量化和剪枝（pruning）技术的解决方案和指导。
• 关于 FlashAttention2 异常输出的争议：在尝试将 flashattention2 与 BERT 集成时，一位成员注意到补丁版和未补丁版模型之间的输出差异，后续消息报告相同输入的差异约为 0.03。
• 对 LayerNorm 延迟的抱怨：尽管声称有 3-5 倍的速度提升，一位成员发现来自 Dao-AILab 的 flash-attention 的融合（fused）LayerNorm 和 MLP 模块比预期慢，这与其 GitHub 仓库上的宣传不符。
• 通过硬件黑客手段提升性能：一位用户提到 Tiny Corp 修改了 NVIDIA 的开源 GPU 内核模块，以在 4090 上启用 P2P，使 AllReduce 操作实现了 58% 的加速，更多细节和结果分享在 Pastebin 链接中。
• Bitnet 位深忧郁：为了优化 Bitnet 实现中三值（ternary）权重的存储，一位成员讨论了使用自定义 2-bit 张量代替效率较低的 fp16 方法的可能性，并被引导至 mobiusml/hqq GitHub 仓库中一种潜在的 bitpacking 技术解决方案。

CUDA MODE ▷ #beginner (12 条消息🔥):

• 通过个人节奏缓解 FOMO：一位成员承认在服务器中看到他人的进步会感到压力，强调了按自己的节奏前进的重要性，并以语言学习作为类比。

• CUDA 学习曲线与语言熟练度：在一次轻松的比较中，成员们讨论了学习 CUDA 是否比学习德语更容易。共识似乎表明，这个 Discord 中的许多人认为 CUDA 更简单。

• PMPP UI 学习小组邀请：发布了关于 PMPP UI 视频的观看派对和学习小组公告，安排了第一次会议并发布了 Discord 邀请。发起人愿意在未来的会议中使用现有的语音频道。

• CUDA 是一个持续的学习曲线吗？：辩论范围涉及 CUDA 不断演进的复杂性是否比过去学习的静态语言（如德语）更难保持同步。

• 编程并行计算机免费在线课程：一门大学课程的助教提供了《编程并行计算机》（Programming Parallel Computers）在线课程的公开版本详情，包括 GPU 编程，并提到了练习的自动基准测试功能。

• CUDA 作为现有框架的加速工具：一位成员澄清说，当 Nvidia GPU 可用时，TensorFlow 和 PyTorch 可以调用 CUDA C/C++ 函数，本质上是通过在 GPU 上运行并行计算来充当加速器。

CUDA MODE ▷ #pmpp-book (1 条消息):

• 第 4 章分享：一位成员提供了一个 Google Docs 链接 指向文档的第 4 章，供大家查阅和反馈。文档的内容和使用背景未作讨论。

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

• 数据集交付：一个超大的数据集被幽默地比作特大号披萨，暗示它已准备好可以使用。
• 任务列表建议：一位用户建议创建一个后续任务列表，表明需要组织接下来的活动。
• 在 Mamba 上测试：一位名为 jamesmel 的成员表示，他们需要在名为 Mamba 的系统或组件上进行测试。
• Infini-attention 介绍：一篇 arXiv 论文 介绍了 Infini-attention，这是一种在有限内存和计算量下扩展 Transformers 以处理无限长输入的方法，引发了带有 🔥 反应的热烈讨论。
• Ring Attention 解释器分享：shindeirou 分享了一个关于 Ring Attention 的解释器链接，旨在让更广泛的受众理解这一概念。这是三位同事的作品，强调了 Large Language Models 中上下文窗口的可扩展性。欢迎大家提供反馈，解释器中的动画也受到了称赞。

CUDA MODE ▷ #off-topic (4 条消息):

• 新著作的开始：该频道见证了一项合作的开始，旨在编写一本现代版的 Golub/Van Loan 书籍，重点关注 GPU 和 Tensor Cores 背景下的数值线性代数。

• CUDA 兼容性打击：Nvidia 更新了其 EULA，禁止使用转换层（translation layers）在非 Nvidia 芯片上运行 CUDA 软件，此举似乎针对 ZLUDA 等项目及某些中国 GPU 制造商。这一变更早在 2021 年就在线发布，但直到最近才被添加到 CUDA 11.6 及更高版本的安装过程 EULA 中。

CUDA MODE ▷ #hqq (11 条消息🔥):

• 跨 GPU 的 Kernel 基准测试：基准测试显示 int4mm kernel 与其他后端相比速度慢得多，且对权重进行 padding 处理并不会影响速度。在 NVIDIA 3090, 4090 和 A100 GPU 上进行的测试显示了类似的结果，当前的实现参考了 mobicham 的 GitHub 仓库。

• 更新的速度评估：speed-eval 文件已更新，可用于进一步的测试和优化，可通过 此 GitHub Gist 获取。

• Matmul 操作的速度比较：据报告，8-bit 矩阵乘法比 fp16 快两倍，这表明 int4 kernel 在较大 batch sizes 下可能存在性能问题。

• 将 HQQ 集成到 gpt-fast 分支：gpt-fast 分支现在支持将 HQQ W_q 直接转换为 packed int4 格式。根据 zhxchen17 的 GitHub commit 详情，成功复现的结果显示，在使用 --compile 选项时，每秒处理 200 个 token 的 perplexity (ppl) 为 5.375。

• HQQ Quant Config 中的优化：用户在测试 HQQ 时应确保开启 quant_config 中的 optimize 设置，以潜在地提高性能。正如关于 HQQ 低比特优化的讨论所述，优化对权重质量的影响因 axis 配置而异。

CUDA MODE ▷ #triton-viz (3 条消息):

• 规划下一步：一名成员建议在集成新功能时循序渐进，从添加代码注释开始。

• 开发时间：另一名成员表示打算通过编写代码来开始实现提议的想法。

• 关于 Tensor 操作的 GIF 指引：一名成员指出 GIF 中展示的顺序可能存在错误，解释说通常操作是从一个加载到较小 tensor 中的大 tensor 开始的，并对更复杂的内部代码可能带来的并发症表示担忧。

CUDA MODE ▷ #llmdotc (98 条消息🔥🔥):

• 通过向量化加载实现 A4000 带宽突破：在 A4000 上使用向量化 (float4) 加载和流式加载指令的新方法实现了 375.7 GB/s 的峰值吞吐量，表明在维度达到 8192 之前几乎保持相同的速度。该方法通过在维度翻倍时将线程数翻倍，保持每个 SM 的缓存需求一致，确保 L1 cache 持续有效。

• CUDA 开发从 C 转向 C++：讨论了在 CUDA 编程中 C++ 优于 C 的实用性，强调了利用更现代的 C++ 特性（如 constexpr、函数重载和模板）来潜在提高代码质量的能力。尽管没有列出具体的直接收益，但共识是由于 nvcc 本身就使用 C++ 编译器，为了提高可维护性，这种转变是合理的。

• Cooperative Groups 增强 Softmax 性能：Cooperative Groups 被用于优化 softmax kernel，实现在不使用 shared memory 的情况下在更多线程间进行 reduction，并在必要时利用系统保留的 shared memory。结果显示，引入 cooperative groups 后，某些 kernel 的速度提升了约两倍。

• CUDA 书籍课程大纲过时：讨论指出，CUDA MODE 中使用的 CUDA 编程书籍没有深入涵盖 Cooperative Groups 等关键特性，尽管这些特性进入 CUDA 已经超过 5 年。该书的一位作者承认了这一点，并同意未来的版本可能会使用 CUDA C++。

• 性能提升与 PR 评审：在经过包括 cublasLt、TF32 和 kernel fusion 在内的密集优化后，一位贡献者因在 RTX 4090 上的表现可能超越了 PyTorch 而感到兴奋，详见其 pull request。然而，在 A100 上，PyTorch 仍然更快，对比结果为 PyTorch 23.5ms vs 30.2ms。

Perplexity AI ▷ #general (281 条消息🔥🔥):

• 关于 Perplexity 集成 GPT-4 的咨询：用户询问 Perplexity 是否集成了更新版本的 GPT-4 及其在 API 中的可用性。
• 模型重要性：Perplexity vs. Opus：一位用户认为 Perplexity 不仅仅是一个搜索引擎，而是搜索与图像生成的结合体，建议不应仅局限于搜索功能。
• 关于 API 灵活性的考量：围绕将 Perplexity API 整合到电子商务网站展开了讨论，用户被引导至 Perplexity 文档。
• 图像生成查询与挑战：聊天机器人成员就图像生成、上下文限制以及 GPT-4 Turbo 和 Claude 3 Opus 等 LLM 的有效性交换了意见。
• 在 Perplexity 中使用扩展程序：对话涉及使用浏览器扩展程序增强 Perplexity 功能，并解决客户端获取（client-side fetching）的限制。

• Bloomberg - Are you a robot?: 未找到描述
• pplx-api: 未找到描述
• Reddit - Dive into anything: 未找到描述
• I tested the viral Humane AI Pin - it's a Nightmare: 我花费了大量时间，力求让我的视频尽可能简洁、精炼且对你有用 - 如果你想支持我的这一使命，那么...
• GitHub - JeremiahPetersen/RepoToText: Turn an entire GitHub Repo into a single organized .txt file to use with LLM's (GPT-4, Claude Opus, Gemini, etc): 将整个 GitHub Repo 转换为单个有序的 .txt 文件，以便与 LLM (GPT-4, Claude Opus, Gemini 等) 配合使用 - JeremiahPetersen/RepoToText
• wallabagger/wallabagger/js/options.js at bc9bae830c2f51403b1679efdfab9a497365f05d · wallabag/wallabagger: 适用于 wallabag v2 的 Chrome / Firefox / Opera 插件。通过在 GitHub 上创建账号来为 wallabag/wallabagger 的开发做出贡献。
• GitHub - donoceidon/repo2txt: A helper script collecting contents of a repo and placing it in one text file.: 一个收集仓库内容并将其放入一个文本文件的辅助脚本。 - donoceidon/repo2txt
• GitHub - ollama/ollama: Get up and running with Llama 2, Mistral, Gemma, and other large language models.: 快速上手并运行 Llama 2, Mistral, Gemma 以及其他大语言模型。 - ollama/ollama

</div>

Perplexity AI ▷ #sharing (12 messages🔥):

• 探索未知：用户分享了各种 Perplexity AI 搜索链接，探讨的主题从身份不明的（“What is the Ee0kScAbSrKsblBJxZmtgQ”）到特定查询，如 “what is a PH63Fv40SMCGc7mtNDr2_Q” 以及 “how to build whMjYrciQM.NXoSLpFSDcQ”。
• 增强可分享性：一位用户提醒确保线程是可分享的（Shareable），并提供了一个 Discord 链接 作为参考截图，但由于提供的摘要性质，具体细节无法访问。
• 深入技术概念：几个搜索链接暗示用户正在深入研究技术主题，例如 “rerank3-cohere-1UdMxh5DStirJf028HLA2g”、“Access-logging-should-9h6iZhUOQJ.JYhY8m1.cww” 以及 “Learning NIST 800-161-uu.csfXOSlGt5Xi_lc7TeQ”。
• 关注政策与伦理：成员们分享了对政策考量的兴趣，相关搜索包括 美国政府在 “US-is-considering-lJ9faQytRx.6RItBXyKFSQ” 中的审议，以及在 “Why honesty is-I6x.NhtaQ5K.BycdYIXwrA” 中的伦理思考。
• 探索转型中的持久性：好奇心还延伸到了通过搜索链接 “what is durable-XjhaEk7uSGi7.iVc01E1Nw” 探索持久性（durability）的概念，暗示了关于弹性系统或概念的讨论。

Perplexity AI ▷ #pplx-api (6 messages):

• 通过 API 查询 Pro Search：一位用户询问是否可以在 API 中使用 “Pro Search” 功能，结果被告知无法这样做。
• 通过 API 寻求网页版答案：用户讨论了 API 响应是否能与 PERPLEXITY 网页版匹配；有人建议明确要求 API “提供你的来源 URL” 作为获取类似结果的方法。
• 功能路线图查询：一位用户寻求关于引用功能何时可能实现的信息，并引用了 官方 PERPLEXITY 文档。路线图被指出将持续到 6 月，并有各种计划中的更新，但没有明确提到来源引用。

提到的链接：Feature Roadmap: 未找到描述

LM Studio ▷ #💬-general (173 messages🔥🔥):

• 应对上下文长度 (Context Length)： 用户在使用 Dolphin Mistral 等模型时遇到了问题，持续使用会导致某些单词或句子的重复。为了解决这个问题，他们应该调整 Context Length，因为典型问题通常在达到模型的上下文限制时出现。

• 应对本地模型限制： 大家达成共识，像 CommandR+ 这样复杂的模型对硬件有很高要求，部分用户由于 VRAM 和系统规格的限制无法运行较重的模型，GPU 升级和使用 ngrok 进行服务器访问被认为是可能的解决方案。

• LM Studio 工具讨论： 讨论围绕 LM Studio 的多种功能展开，明确了它不支持模型的互联网访问或拖放文件输入；不过，文中提供了第三方工具和方法的链接来克服这些限制。

• 模型托管与集成查询： 用户询问关于在 Runpod 和 GitPod 等各种平台上托管模型的问题，并咨询将文本生成与 Stable Diffusion 等图像生成工具集成的可能性。

• 技术支持交流： 社区在解决各种系统上的问题方面表现活跃，例如缺少 AVX2 指令和 LM Studio 中的 JavaScript 错误。用户 heyitsyorkie 经常提供建议，包括引导至支持频道，并确认在某些修复中关闭 GPU Offload 的必要性。

LM Studio ▷ #🤖-models-discussion-chat (46 条消息🔥):

• Mixtral-8x22B 已准备好量化 (Quantization)：Mixtral-8x22B 模型已使用 llama.cpp 完成量化，现已开放下载，由于体积庞大，模型被拆分为多个部分。建议用户注意这是一个基础模型 (Base Model)，尚未针对聊天或指令任务进行微调 (Fine-tuned)，在无法运行 8x7b 版本的系统上可能会运行困难。
• LLM 架构加载错误解决方案：在尝试使用 LM Studio 0.2.17 加载 Mixtral-8x22B-v0.1 时，出现了错误消息 “llama.cpp error: ‘error loading model architecture: unknown model architecture: ‘’’“；升级到 0.2.19 beta preview 3 或更高版本可解决此问题。
• 发布新的 Chat2DB SQL 模型：用户 bartowski1182 宣布发布了两个针对 SQL 任务优化的新模型，可在其各自的 Hugging Face 链接下载：Chat2DB-SQL-7B-GGUF 和 Chat2DB-SQL-7B-exl2。
• 大型模型性能讨论：社区成员分享了他们使用大型模型的经验，讨论了 CMDR+ 和 Mixtral 8x22 的资源消耗情况，并建议尝试更小的量化版本或调整 LM Studio 设置，例如关闭 GPU Offload 且不将模型保留在 RAM 中。
• 升级前检查服务器能力：在讨论加载 100B+ 参数模型的硬件升级和配置时，强调了具备 AVX2 指令兼容性的重要性，并指出出于性能考虑，服务器应至少配备 24GB VRAM 的 GPU。

LM Studio ▷ #📝-prompts-discussion-chat (2 条消息):

• LLM 在时间序列中的设计局限：提到除非模型设计发生改变，否则时间序列数据并不适合 Large Language Models (LLM)。
• TFT 作为时间序列数据的解决方案：建议在时间序列数据上训练 Temporal Fusion Transformer (TFT) 是一种可行的方法。

LM Studio ▷ #🎛-hardware-discussion (23 条消息🔥):

• 无云端 GPU，但 HuggingFace Chat 是替代方案：Command-R Plus 不支持云端 GPU 服务，但 HuggingFace Chat 提供了 CohereForAI/c4ai-command-r-plus 模型作为在线选项。
• 本地运行大模型 vs 云端：关于运行 72b 模型的可行性讨论表达了对 VRAM 限制的担忧；替代方案包括云端解决方案或本地硬件升级，如 NVIDIA 4060ti 16GB。
• 期待用于 AI 的 Apple M4：传闻即将发布的 Apple M4 Mac 将专注于人工智能应用，这可能需要潜在买家增加预算。
• AI 应用的内存权衡：关于将非双通道 RAM 从 16GB 增加到 40GB 是否有利于 LLM 性能的辩论得出结论：尽管会牺牲游戏性能，但对于 AI 任务中的 CPU 推理，拥有更多 RAM 即使失去双通道优势也是有益的。
• GPU vs CPU 推理：讨论强调 CPU 推理的速度明显慢于 GPU 推理，虽然拥有更多系统内存可以加载更大的 LLM，但最终目标仍是实现全 GPU 推理以获得最佳性能。

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

• Ubuntu 上的 Mistral 模型加载问题：一位用户在 Ubuntu 22.04 LTS 上尝试使用其服务器加载本地模型时，遇到了 Mistral 模型 的 “Error loading model” 错误。用户分享了系统规格（如可用 RAM 和 GPU 详情），以寻求对模型加载过程中遇到的 Exit code: 0 错误的解释。

• BERT Embedding 查询与指南：一名成员询问是否可以加载 Google BERT Embedding 模型，随后讨论中分享了 LM Studio 文档中关于 文本 Embedding 的链接，解释了如何使用 GGUF 格式的 LM Studio Embedding 服务器为 RAG 应用生成文本 Embedding。

• 关于 Google BERT 和微调的说明：另一位用户澄清说，基础的 Google BERT 模型 无法在 LM Studio 中直接使用，且通常不适合在没有针对下游任务进行微调的情况下直接使用，并引用了来自 Hugging Face 的模型。

• 更好 Embedding 模型的推荐：进一步推荐了具有更大参数的 Embedding 模型，如 mxbai-large、GIST-large 和 LaBSE，以获得优于标准 BERT base 模型的结果。

• Embedding 的计算成本选项：关于适合不同计算能力的各种 Embedding 模型的评论指出，除了 1024 维的 large 版本外，还有 768 维和 384 维的 base 和 small 版本作为替代方案。

LM Studio ▷ #amd-rocm-tech-preview (12 messages🔥):

• Linux 用户询问关于 ROCm 的信息：一位用户询问是否会为 Linux 提供 amd-rocm-tech-preview，另一位用户表示最终会有，但不会很快推出。
• 用户在支持 ROCm 的硬件上的使用体验：多位用户报告了在不同硬件（特别是 7800XT、7900 XTX Nitro+ 和 6800XT）上运行 ROCm 的体验。他们分享说，运行任务时会产生明显的电感啸叫（coil whine），具体情况因游戏或工作负载而异。
• AMD 6750XT 上的技术预览版挑战：一位用户指出，ROCm tech preview 声称在 AMD 6750XT 上使用了 GPU，但最终只利用了 CPU 和 RAM，且没有抛出任何兼容性错误。他们将其与常规 Studio 进行了对比，后者能通过 AMD OpenCL 正确地将任务卸载到 GPU。
• 寻求 Windows 二进制文件编译帮助：一名成员寻求在 Windows 上编译 gguf-split 二进制文件 的帮助，以便在 7900XT 上进行测试，并链接了与该问题相关的 GitHub 讨论和 Pull Request：如何使用 gguf-split / 模型分片演示 以及 添加 Command R Plus 支持。

Eleuther ▷ #general (96 messages🔥🔥):

• 探索 Encoder 模型的上下文窗口扩展：成员们讨论了将用于扩展 Decoder-only 模型上下文窗口的方法适配到 BERT 等 Encoder 模型的挑战，并提到了由于双向注意力机制（bidirectional attention mechanisms）带来的困难。他们还讨论了使用 FlashAttention 的 MosaicBERT，并疑惑为什么在 Hugging Face 的 Transformers 等库中没有更普遍地实现它，尽管已经有了社区贡献。

• Mixtral-8x22B 模型的量化与 VRAM 担忧：一位成员寻求社区支持，希望在 GPU 服务器上运行 Mixtral-8x22B 模型的 2-bit 量化版本，以便在小于 72 GB 的 VRAM 环境下使用。大家对 AQLM 团队的进展 充满期待，这可能需要一周时间。

• 探索 The Pile 数据集大小差异：用户分享了下载和使用 The Pile 数据集的经验，注意到报告的 886GB 未压缩大小与他们 720GB 到 430GB 不等的压缩副本之间存在差异，并讨论了 The Pile 中不同存档类型缺乏提取代码的问题。

• 创建 AI 学习与语言模型开发的阅读清单：一位成员分享了一个 GitHub 仓库，其中包含一份阅读清单，旨在帮助 Elicit 的新人学习语言模型，内容涵盖从基础 Transformer 操作到最新进展。

• EleutherAI 的贡献与公开模型：一位成员强调了 EleutherAI 对 AI 发展的贡献，并提到了 GPT-J 和 NeoX 等公开模型。讨论还涉及了维基页面的一项新功能，即使用 EleutherAI 等来源生成的 AI 内容。

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

• Google 发布 Mixture of Depths 模型：@_akhaliq 的一条 推文 透露，Google 展示了 Mixture-of-Depths，旨在 Transformer 架构的语言模型中动态分配计算资源，而不是在输入序列中均匀分布 FLOPs。
• RULER 的空仓库现已开源：开源社区现在可以访问 RULER 的空仓库，该项目承诺提供关于长上下文语言模型真实上下文大小的见解，详见 GitHub。
• 对抗样本：超越噪声与畸变：讨论涵盖了对抗样本（adversarial examples）并不总是无结构的噪声，有些表现为图像部分的实际畸变。这种复杂性在拥有 1000 次引用的 ImageNet-A 和 ImageNet-O 数据集论文 中有进一步详细说明。
• 微调部分层可以很高效：关于子集微调（subset finetuning）的新兴讨论受到关注，即微调网络层的子集可以达到与全量微调相当的准确度，尤其是在训练数据稀缺的情况下，正如 这篇论文 所指出的。
• 经济且具竞争力的 LLM JetMoE-8B：JetMoE-8B 是一款新型经济实惠的 LLM，训练成本低于 10 万美元，采用稀疏门控 Mixture-of-Experts 架构。据称其性能优于同等规模的其他模型，标志着开源模型迈出了重要一步。详情可见 此处。

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

• 关于大规模运行中浮点精度的查询：一位用户询问了当前最大规模训练运行中使用的浮点格式，想知道 bf16 是否仍是标准，或者实验室是否已转向 fp8。
• 分享了关于数据过滤的 Scaling Laws 论文：CVPR2024 上发表的一篇新 Scaling Laws 论文 探讨了数据清洗（data curation）与计算资源之间的相互作用。它提出数据清洗不能脱离计算资源（compute agnostic），并介绍了处理异构且有限的网络数据的 Scaling Laws。
• 对论文反应平淡：一位成员用一个非语言表情符号回复，似乎暗示对分享的 Scaling Laws 论文缺乏兴奋感或持怀疑态度。
• 在研究方法中寻找熵：讨论继续，一位成员象征性地提到了在 Scaling Laws 背景下寻找基于熵的方法。另一位用户认可了这一主题，并指出所采用的是经验方法，没有明确提到熵。
• 思考新研究的基础：成员们反思了当前的研究（如 Scaling Laws 论文）即使没有直接说明，也可能隐含地基于熵等经典概念。他们讨论了该论文将熵等概念重新定义为“效用（utility）”的方法细微差别，这导致了非传统的分析视角。

提到的链接：Pratyush Maini (@pratyushmaini) 的推文：1/ 🥁数据过滤的 Scaling Laws 🥁 TLDR：数据清洗 不能 脱离计算资源！在我们的 #CVPR2024 论文中，我们为异构和有限的网络数据开发了第一个 Scaling Laws。w/@goyalsach…

Eleuther ▷ #interpretability-general (8 messages🔥):

• 对将 GitHub stars 作为指标感到惊讶：一位成员对使用 GitHub stars 作为衡量标准表示惊讶，提到他们遇到过只有少量 stars 的优秀项目，以及“拥有 10k+ stars 的绝对软件垃圾”。
• 对 Activation to Parameter 的兴趣：AtP(*) 的概念因其潜在用途和价值引起了一位成员的兴趣。
• 利用 AtP 进行异常检测的潜力：人们对利用 AtP* 进行异常检测感到好奇，特别是通过对比单次前向传播与多次其他传播的结果来确定异常。
• AtP 分析的新方法：与论文中平均效果的方法不同，该成员建议通过比较单个前向传播结果来识别离群值（outliers）。

Eleuther ▷ #lm-thunderdome (1 messages):

butanium: 我实验室里也有人想知道那些 chat_template 分支是否可用。

Eleuther ▷ #gpt-neox-dev (10 messages🔥):

• 贡献需要企业级 CLA：一位成员提到，为了推进 TE 的 fused kernels 和 fp8 集成，需要 企业贡献者许可协议（Corporate CLA）。目前的 EleutherAI/GPT-NeoX CLA 仅针对个人。
• 编写自定义企业 CLA：作为回应，另一位成员提出可以 编写自定义 CLA，并询问了具体的需求列表以及相对于当前 CLA 需要进行的更改。
• NeoX Embeddings 引发疑问：一位分析 Embeddings 的成员注意到 NeoX 似乎是一个离群值，并怀疑是否未对其输入 Embeddings 应用 weight decay，或者是否使用了其他特定技巧。
• 比较 Pythia 和 NeoX Embeddings：在询问 NeoX 模型的异常行为是否也存在于 Pythia 中之后，另一位成员决定对两者进行检查。
• 确认 NeoX 的独特行为：经过一些分析，确认 NeoX 在其 Embeddings 方面是一个独特的离群值，其 model.gpt_neox.embed_in.weight[50277:].sum(axis=1) 不接近 0，这与 GPT-J 和 OLMo 等其他模型不同。

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

• Mixtral 8x22B:free 推出并更新：为了与 现有的 :free 模型 保持一致并澄清路由/频率限制（rate-limiting）的混淆，创建了一个新模型 Mixtral 8x22B:free。它还更新了上下文大小，从 64,000 增加到 65,536。

• 需要从已停用的免费模型切换：Mixtral 8x22B:free 已被 停用，建议用户切换到 Mixtral 8x22B。

• 用于测试的新实验模型：两个新的 Mixtral 8x22B instruct 微调版本已开放测试：Zephyr 141B-A35B 和 Fireworks: Mixtral-8x22B Instruct (preview)。

OpenRouter (Alex Atallah) ▷ #app-showcase (1 条消息):

.o.sarge.o.: 尝试购买 token 时似乎出现了问题。这是图片。

OpenRouter (Alex Atallah) ▷ #general (213 条消息🔥🔥):

• 登录问题已自主解决：一位用户错误地登录了平台，随后找到了不仅可以退出登录，还可以彻底注销账户的解决方案。

• GPT 4 Turbo 和 Mistral Large 错误：对 GPT 4 Turbo 和 Mistral Large 的 500 errors 进行排障后发现，重新部署到 Heroku 解决了该问题，这表明部署损坏可能是原因所在。

• 个人 AI 系统搭建讨论：社区成员讨论了使用 OpenRouter 和其他工具（如 LibreChat）搭建个人 AI 系统，并为个性化 AI 体验提供了建议，包括移动端和桌面端的可用性、对话存储以及低延迟的网页搜索结果。

• Firextral-8x22B-Instruct 更新与说明：讨论了 Firextral-8x22B-Instruct 等模型的路由更新，切换到了 Vicuna 1.1 模板，并澄清了 OpenRouter 网站上最大上下文列表显示为 “Max Output” 的情况。

• AI 模型性能与调优经验分享：用户分享了他们对各种模型性能和调优能力的经验与观察。观点各异，有人在某些任务中更青睐 GPT-4 Turbo，有人对 MoE 架构表现出兴趣，并讨论了 Opus、Gemini Pro 1.5 的作用以及模型的涌现行为 (emergent behavior)。

Modular (Mojo 🔥) ▷ #general (9 messages🔥):

• Mojo 回馈社区：Mojo 最近开源了其标准库，现在包含了来自已合并 Pull Request 的社区贡献。此举允许社区参与贡献，并让 Mojo 团队有更多时间专注于编译器。

• 寻求 Modular 合作：来自 BackdropBuild.com 的一位成员正在寻求协助，以将 Modular 集成到他们的大规模开发者队列计划中。他们正在联系 Modular 进行合作，以支持使用其技术的构建者。

• 保持在正确频道：提醒商务和合作咨询应定向到 offtopic 频道，以便在 general 讨论中实现更好的组织和相关性。

提及链接：Backdrop Build：我们共同构建 - 在短短 4 周内与数百名其他出色的构建者一起将疯狂的想法变为现实。

Modular (Mojo 🔥) ▷ #💬︱twitter (1 messages):

ModularBot: 来自 Modular: https://twitter.com/Modular/status/1778482233957101869

Modular (Mojo 🔥) ▷ #✍︱blog (1 messages):

• Mojo 解决矩阵存储问题：Modular 官网上的一篇新博客文章深入探讨了矩阵在内存中的存储方式，探索了行优先（row-major）和列优先（column-major）排序的区别和性能影响。这项调查旨在阐明为什么不同的编程语言和库对存储顺序有不同的偏好。

提及链接：Modular: Row-major vs. column-major matrices: a performance analysis in Mojo and NumPy：我们正在为世界构建下一代 AI 开发者平台。查看我们的最新文章：Mojo 和 NumPy 中的行优先与列优先矩阵性能分析。

Modular (Mojo 🔥) ▷ #🔥mojo (125 messages🔥🔥):

• Mojo 中讨论 Karpathy 的 llm.c：关于 Andrej Karpathy 的 llm.c 仓库为何不使用 Mojo 的 GitHub issue 引起了关注。Andrej Karpathy 表示，他很乐意在 readme 中链接任何 Mojo 移植版本，以便进行基准测试和对比。

• Mojo 中的二进制文件读取：成员们讨论了如何在 Mojo 中实现类似于 Python struct.unpack 的二进制文件读取器。提供的一个解决方案是使用 Mojo 的 read 而不是 read_bytes，这似乎解决了问题，正如 GitHub 文件 中所示。

• GUI 设计理念的冲突：围绕 GUI 框架的对话引发了对设计方法的不同意见，重点是 model/view 范式。一些成员表现出对 SwiftUI 等声明式 GUI 的偏好，而另一些成员则捍卫 Tk 等命令式框架提供的灵活性和控制力。

• Mojo 增强 Python 性能的潜力：社区对 Mojo 的未来表达了热情，特别是它增强 Python 性能以及可能允许直接进行 Python 代码编译的潜力。分享了一个相关的播客链接，其中 Chris Lattner 讨论了 Mojo 的目标。

• 比较 Mojo 和 C 之间的功能：讨论了关于 Mojo 模拟 C 语言功能（如位操作）能力的问题，成员们分享了翻译示例，并确认了 Mojo 中移位（shifts）和按位异或（bitwise XOR）等操作的功能。

Modular (Mojo 🔥) ▷ #community-projects (2 messages):

• Mojo 终端文本渲染预览：一位成员展示了 使用 Mojo 进行终端文本渲染 并分享了代码，灵感来自 charmbracelet’s lipgloss 包。预览代码可在 GitHub 上找到，其中一个小的状态栏问题很快将得到修复。
• 为 Basalt 集成喝彩：另一位社区成员称赞了 Basalt 的集成，认为终端渲染效果令人印象深刻。

提及的链接：mog/examples/readme/layout.mojo at main · thatstoasty/mog：通过在 GitHub 上创建账号来为 thatstoasty/mog 的开发做贡献。

Modular (Mojo 🔥) ▷ #community-blogs-vids (1 messages):

• 探索矩阵中的内存存储：一篇题为 “Row-major vs. Column-major matrices: A performance analysis in Mojo and Numpy” 的博客文章深入探讨了行优先（row-major）和列优先（column-major）排序。它讨论了性能影响以及不同语言和库对矩阵内存存储的偏好。

• Matrix Memory Order Notebook 错误：一位成员在尝试按照博客文章操作时，运行 GitHub 上相关 Jupyter notebook 的第二个单元格时遇到错误，该 notebook 位于 devrel-extras/blogs/mojo-row-major-column-major。错误涉及在创建 MojoMatrix 并将其转换为列优先（column-major）格式时，与 ‘mm_col_major’ 相关的未知声明。

LangChain AI ▷ #general (107 messages🔥🔥):

• 在 AIAssistant 中追踪 Token 使用情况：一位成员正在通过接收 Token 计数、乘以价格并保存数据来追踪他们自己来自 OpenAI API 的 Token 使用情况，因为 LangSmith 不为 AIAssistant 提供 Token 使用情况。

• 总结速度瓶颈：成员们讨论了 LangChain 的 load_summarization_chain 函数，指出其在总结大型 PDF 时速度较慢。一位成员分享了一个代码片段，演示了如何使用 map_reduce 链来提高速度。

• Instructor 与 LangChain 的集成与使用：讨论包括了将 Instructor（它可以促进 LLM 输出 JSON 等结构化数据）与 LangChain 结合使用的可能性。一位成员表示，他们想要一个能生成有效的 pydantic 对象并通过 LLM 处理验证错误的工具。

• 在 LangChain Tool Calling Agent 中确保有效的工具参数：一位成员就如何自修复无效的工具参数寻求建议，这些参数是由 LangChain 的 Tool Calling Agent 中的 LLM 生成的，并提到了 Groq Mixtral 的问题。

• 使用 LangChain 高效读取 CSV 文件：一位成员寻求最有效的方法来使用 Agent 读取 .csv 文件，另一位成员建议使用 ChatOpenAI 配合 openai-tools Agent 类型。随后还讨论了模型在处理不同数量的 .csv 文件时的性能。

• 在 LangChain 中处理 FAISS-GPU 的内存释放：一位用户询问在 LangChain 中使用 FAISS-GPU 和 Hugging Face embeddings 遇到 [torch.cuda.OutOfMemoryError](https://pytorch.org/docs/stable/cuda.html#memory-management) 时如何释放内存，因为无法通过提供的封装器手动释放 GPU 内存。

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

• 不当内容警报：频道中的一条消息通过链接推广成人内容，将其伪装成加入 Discord 服务器的邀请。
• 寻求关于 LangFuse Callbacks 的信息：一位成员请求协助利用 langfuse callback handler 通过 langserve 进行追踪，并正在寻找关于如何记录输入（如问题、会话 ID 和用户 ID）的来源或示例。

提到的链接：加入 Teen Content 18+ 🍑🔞 Discord 服务器！：查看 Discord 上的 Teen Content 18+ 🍑🔞 社区 - 与其他 441 名成员一起交流，享受免费的语音和文字聊天。

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

• 不当内容警报：一条消息包含推广成人内容的链接；已被标记为垃圾信息。此类内容通常违反 Discord 的社区准则。

提到的链接：加入 Teen Content 18+ 🍑🔞 Discord 服务器！：查看 Discord 上的 Teen Content 18+ 🍑🔞 社区 - 与其他 441 名成员一起交流，享受免费的语音和文字聊天。

LangChain AI ▷ #share-your-work (8 条消息🔥):

• Galaxy AI 发布：GalaxyAI 推出了一项免费 API 服务，包含 GPT-4、GPT-4-1106-PREVIEW、GPT-3.5-turbo-1106 和 Claude-3-haiku 等 AI 模型，并支持 Langchain 集成。可在 Galaxy AI 获取，这些 API 采用 OpenAI 格式，便于集成到项目中。

• Appstorm v1.6.0 提升应用构建体验：Appstorm 的新版本 1.6.0 已在 Appstorm beta 发布，包含移动端注册、音乐和地图 GPT、数据探索与可视化、更便捷的应用分享、改进的并发应用管理以及增强应用构建体验的错误修复。

• 寻求 AI 助手开发建议：一位成员正在开发一个虚拟 AI 助手，需要解析数千份 PDF 以生成基于 RAG (Retriever-Answer Generator) 的功能，并通过阅读数据手册为 IoT 边缘平台设置配置参数，正在寻求处理该项目的建议。

• 不当内容警示：警告：识别到一名成员发布了包含露骨内容和色情材料链接的帖子；这些内容对 AI 讨论没有任何建设性贡献。

• 通过 AI 增强 Meeting Reporter：一款名为 Meeting Reporter 的新应用将 Streamlit 与 Langgraph 结合，通过人机协作（human-AI collaboration）创作新闻故事，该应用需要付费的 OpenAI API key。它已在 Streamlit App 上展示，开源代码可在 GitHub 获取，更多详情和会议转录文本见相关的 博客文章。

LangChain AI ▷ #tutorials (4 messages):

• LangChain 教程警示：发布了一篇关于 LCEL (LangChain Execution Language) 以及使用 runnables 创建链的新教程。感兴趣的人员可以阅读并提供反馈：LangChain Tutorial: LCEL and Composing Chains from Runnables。

• 垃圾信息警示：tutorials 频道收到了多条推广成人内容的垃圾信息。这些消息包含露骨内容，与本频道的目的无关。

提到的链接：加入 Teen Content 18+ 🍑🔞 Discord 服务器！：查看 Discord 上的 Teen Content 18+ 🍑🔞 社区 - 与其他 441 名成员一起交流，享受免费的语音和文字聊天。

HuggingFace ▷ #announcements (9 messages🔥):

<ul>
  <li><strong>Osanseviero 的推文推送</strong>：osanseviero 分享了一条新推文，预计会有令人兴奋的消息或见解。点击<a href="https://twitter.com/osanseviero/status/1778430866718421198">此处</a>查看推文。</li>
  <li><strong>亮点回顾</strong>：Community Highlights #53 带来了多样化的认证用户内容，包括 Hugging Face 的葡萄牙语介绍、时尚试穿空间以及各种有趣的 GitHub 仓库。</li>
  <li><strong>嵌入助力成功</strong>：该 RAG 聊天机器人由通过 <a href="https://huggingface.co/datasets/not-lain/wikipedia-small-3000-embedded">not-lain/wikipedia-small-3000-embedded</a> 嵌入的数据集驱动，作为生成用户知情响应的检索源。</li>
  <li><strong>检索与生成双重奏</strong>：通过将嵌入数据集的检索与生成式 AI 相结合，该 RAG 聊天机器人创新地寻求提供准确的信息推断。</li>
  <li><strong>RMBG1.4 下载量飙升</strong>：与 transformers 库集成的 RMBG1.4 本月下载量达到了 23 万次的新里程碑，显示出社区浓厚的兴趣和使用量。</li>
</ul>

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

• 数据集基础 (Basics of Datasets): 一位用户询问了学习数据集的起点。他们被引导至 HuggingFace 文档，其中包含解释器、模板、创建数据集的指南等，可以在 HuggingFace’s Datasets Library 找到。

• 辅助人工帮助的问答机器人: 有人建议在 #help 频道中使用问答机器人，通过建议相关信息或指向类似的已解决问题来协助用户。启用机器人建议的按钮可能会增加其可见性和使用率。

• 训练用于 GUI 导航的模型: 有一段关于训练用于操作系统 GUI 导航的模型可行性的详细对话。讨论了使用辅助功能模式和应用接口，而不是基于像素完美的视觉控制的替代方案。

• 在单个 GPU 上运行多个模型: 出现了一场关于在单个 GPU 上同时运行多个模型的讨论。用户分享了经验和技术，例如使用信号量（semaphores）创建 Web 服务器以优化 GPU 吞吐量。

• 使用 Datasets 处理大型数据集和进度跟踪: 用户讨论了处理和上传超大型数据集（特别是音频和图像）的最佳方法，重点是实现流式传输（streaming）和高效的元数据更新。还有关于在对数据集执行映射函数（mapping functions）时如何提取进度信息以进行 UI 集成的查询。

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

• Docker 替代方案深度解析: 一段名为 “Contain Your Composure: On Podman-Compose, Code Cleanup, and Tiny Llamas” 的视频教程提供了使用 Podman-Compose 构建微服务的演练，重点介绍了 Yet Another Markup Language (YAML) 文件并介绍了 Small Langu。描述暗示该视频关注整洁代码实践，并可能以有趣的方式提炼复杂主题。

提到的链接: Contain Your Composure: On Podman-Compose, Code Cleanup, and Tiny Llamas: 本视频教程将带你了解使用 Podman-Compose、YAML 文件、Small Langu 构建微服务的全过程…

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

• Karpathy 的极简 CUDA 实现: Andrej Karpathy 实现了一种使用 原生 C/CUDA 进行 LLM 训练 的直观方法。代码可以在 GitHub 上的 llm.c 仓库 中获取。

• Mistral 7B vs. Llama 模型: 一个基准测试网站对比了 Mistral 7B 与 Llama 2 系列，指出 Mistral 7B 在所有指标上都优于 Llama 2 13B，并能与 Llama 34B 媲美。他们的发现称赞了 Mistral 7B 在代码和推理方面的卓越表现，Mistral 7B 详情见此。

• 等待进一步信息: 一位成员提到收到了来自 Google Cloud Next ’24 的文档，但未提供更多细节或链接。

• Parler TTS 介绍: HuggingFace 推出了 parler-tts，这是一个用于高质量 TTS 模型 推理和训练的库，可在其 GitHub 仓库中获取。感兴趣的人可以通过 parler-tts GitHub 页面 进行探索和贡献。

• AI 书籍推荐: 一位成员发现《The age of AI》是一本非常有趣的读物，但未提供额外信息或链接。

• 增强记忆的文档检索指南: 发布了一篇关于通过记忆增强文档检索的教程，详细介绍了如何使用带有 基于 Colbert 的 Agent 的 LlamaIndex。该教程可在 Medium 上找到，提供了对文档检索进展的见解：增强文档检索教程。

HuggingFace ▷ #i-made-this (8 条消息🔥):

• Marimo 提供的 Hugging Face Model Playground：一位成员介绍了 marimo-labs，这是一个与 Hugging Face 集成的新 Python 包，使用户能够为文本、图像和音频模型创建交互式 Playground。这由 marimo 的响应式执行结合 Hugging Face 的免费推理 API 提供支持。
• Marimo Playground 交互式链接：分享了一个 交互式 marimo 应用程序，用户可以使用自己的 token 交互式地查询 Hugging Face 上的模型；该应用通过 WASM 在本地运行。
• 葡萄牙语的 AI 概念：一位成员发布了一篇葡萄牙语的文章和视频，介绍了 Hugging Face 的基础知识，为讲葡萄牙语的 AI 初学者提供了宝贵的资源。该内容是名为 “de IA a Z” 系列的一部分，还有涵盖各种 AI 主题的其他文章。
• Mergekit 的即将推出的功能：宣布了 Mergekit 即将推出的新方法，包括已经添加的 rescaled TIES。
• 分享了 Vimeo 视频：分享了一个来自 Vimeo 的视频链接 https://vimeo.com/933289700，但未提供背景或描述。

HuggingFace ▷ #reading-group (1 条消息):

• Blenderbot 微调建议：一位成员建议微调 FAIR 的 Blenderbot，该模型可在 HuggingFace 上获得，并指出需要为该任务寻找合适的数据集。

HuggingFace ▷ #computer-vision (14 条消息🔥):

• 推荐 GPU 进程管理工具：推荐了一个名为 nvitop 的 GPU 进程查看器，作为管理 GPU 进程的实用工具，更多详情见 GitHub - XuehaiPan/nvitop。

• 视频修复技术的入门步骤：一位寻求视频修复技术（如去噪和去除伪影）建议的用户被引导至一篇图像修复论文作为起点，并建议通过添加时间维度将其视为视频的扩展，详见 arXiv 上的 NAFNet 论文。

• 数据增强在图像修复中的重要性：针对在没有真值 (ground truth) 的情况下训练视频修复数据集的担忧，强调了数据增强是关键，并提供了两篇论文的链接：BSRGAN 和 Real-ESRGAN，它们详细介绍了对训练修复模型非常有用的增强流水线。

• 了解视频去闪烁：针对视频噪声和伪影问题，用户被推荐至 GitHub 上的一个特定项目 All-In-One-Deflicker，该项目处理盲视频去闪烁 (blind video deflickering)。

• 探索多模态和向量数据库的集成：讨论了将 Google 的 Vertex 多模态嵌入 (embeddings) 与 Pinecone 向量数据库集成，包括它们如何通过嵌入处理拼写错误和品牌识别，并附带了 Google 的演示链接 AI Demos Dev。

• AI Demos: 未找到描述
• Designing a Practical Degradation Model for Deep Blind Image Super-Resolution: 众所周知，如果假设的退化模型与真实图像中的模型不符，单图像超分辨率 (SISR) 方法的表现将不尽如人意。尽管已经有几种退化模型...
• Real-ESRGAN: Training Real-World Blind Super-Resolution with Pure Synthetic Data: 尽管在盲超分辨率领域已经进行了许多尝试，以恢复具有未知且复杂退化的低分辨率图像，但它们距离解决通用的真实世界退化图像仍有很大差距...
• GitHub - ChenyangLEI/All-In-One-Deflicker: [CVPR2023] Blind Video Deflickering by Neural Filtering with a Flawed Atlas: [CVPR2023] 通过带有缺陷图谱的神经滤波进行盲视频去闪烁 - ChenyangLEI/All-In-One-Deflicker
• Grounding DINO: 未找到描述
• Transformers-Tutorials/Grounding DINO/Inference_with_Grounding_DINO_for_zero_shot_object_detection.ipynb at master · NielsRogge/Transformers-Tutorials: 此仓库包含我使用 HuggingFace 的 Transformers 库制作的演示。 - NielsRogge/Transformers-Tutorials
• GitHub - XuehaiPan/nvitop: An interactive NVIDIA-GPU process viewer and beyond, the one-stop solution for GPU process management.: 一个交互式的 NVIDIA-GPU 进程查看器及更多功能，GPU 进程管理的一站式解决方案。 - XuehaiPan/nvitop
• Simple Baselines for Image Restoration: 尽管最近在图像恢复领域取得了显著进展，但最先进 (SOTA) 方法的系统复杂性也在增加，这可能会阻碍其便利性...

</div>

HuggingFace ▷ #NLP (12 messages🔥):

• 寻求更长上下文模型: 一位成员询问了能够处理 10-15k token 左右更长上下文的 encoder-decoder models。建议包括研究 BigBird 和 Longformer 等模型。

• 使用 Checkpoints 进行训练: 有人询问关于使用 HuggingFace 的 trainer 来暂停和恢复训练的问题。确认 trainer.train() 中的 resume_from_checkpoint 选项可以实现此目的。

• 脚本协助请求: 一位成员分享了一个详细的脚本 train_ddp.py，该脚本利用 transformers、TRL、PeFT 和 Accelerate 来训练模型，并请求帮助以确保其正确性以及训练模型的正确保存。

• 平衡评分与指导: 参与者讨论了评估自动化辅导响应的方法，考虑使用加权平均来优先处理评分方案而非指导原则，并建议使用适用于语义含义的 embedding 模型，例如 sentence-transformers/all-MiniLM-L6-v2。

• 下载大型分块模型: 有一个关于下载和组装像 Mixtral-8x22B 这样被分割成多个 GGUF 文件的大型模型的问题。该成员询问文件是否需要手动合并，或者在加载时是否会自动组装。

HuggingFace ▷ #diffusion-discussions (5 messages):

• Fastai 和 Diffusers 深度探索: 一位成员建议学习 fastai 的第二部分课程 以进行深入理解，然后探索 HuggingFace diffusers 的 GitHub issues 和 相关的 HuggingFace 博客文章。他们还建议关注 GitHub 上关于 diffusers 的热门讨论 以获取最新见解。

• PixArt-Alpha Pipeline 使用: 在一条简短的笔记中，一位成员建议查看利用了上述技术的 PixArt-Alpha pipeline。

• 消费级 GPU 的限制：一位成员讨论了在使用 SDPA 和 torch.compile() 等现代技术时消费级 GPU 的局限性，认为这些技术在最新的 GPU 上更有益。对于那些使用性能较低 GPU 的用户，他们分享了来自 GitHub 讨论 的建议，关于如何加速 diffusion。

• 理解多模态搜索能力：一位成员询问 Google 的多模态 embeddings 如何不仅能匹配图像，还能识别带有拼写错误的品牌名称，这是基于 AI-demos 的演示。他们表示打算构建一个功能类似的 Web 应用程序，并寻求对其底层机制的深入了解。

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

• 混合搜索方法论辩论：一位用户就使用 Cohere 的 rerank 策略寻求建议，并询问在 reranking 之前合并词法（lexic）和语义（semantic）搜索结果，是否比将它们全部放在一个列表中进行一次性 reranking 更有效。其他成员建议第二种方法可能更高效，因为它只涉及单个 reranking 步骤，并且可以节省延迟。

• 模型崛起：Sandra Kublik 的一条推文链接宣布发布了 Rerank 3，这是来自 Cohere 的新模型，它增强了搜索和 RAG 系统，包括 4k 上下文长度、最先进的 (SOTA) 搜索准确度、代码检索以及跨 100 多种语言的多语言能力。包含更多细节的原始推文可以在这里找到。

• AI 初创公司与创新：关于 Alberto Rizzoli 介绍的名为 V7 Go 的多模态 AI 时代工作自动化工具的讨论引起了人们的兴趣，该工具旨在利用 GenAI 处理单调任务。另一个竞争产品 Scarlet AI 由其创建者提出，宣传其通过 AI 与人类协作进行任务规划和执行的能力。

• Perplexity 的 “Online” 模型：用户讨论了 Perplexity 的 “online” 模型从 LMSYS Arena 中消失的情况，推测其含义及背后的技术。Perplexity 博客文章的链接显示它指的是可以访问互联网的模型，链接在这里。

• AI 聊天机器人竞技场领导者：分享了关于 GPT-4-Turbo 重新夺回 Lmsys 盲测聊天机器人排行榜榜首的更新，强调了其强大的代码编写和推理能力，这已通过各个领域的 8000 多张用户投票得到证实。公告推文可以在这里访问。

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

• 新播客提醒：查看最新一期播客，内容包括与 Elicit 的 Jungwon Byun 和 Andreas Stuhlmüller 的讨论。本期节目深入探讨了 AI 研究的监督，可在 Twitter 上收听。
• YouTube 上的 Elicit：您也可以在 YouTube 上观看 Elicit 播客集，包括深入探讨为什么产品可能优于研究以及 Elicit 的演变。别忘了点赞并订阅以获取更多内容！

提到的链接：监督 AI 研究的过程 —— 与 Elicit 的 Jungwon Byun 和 Andreas Stuhlmüller：时间戳：00:00:00 介绍 00:07:45 Johan 和 Andreas 如何联手创建 Elicit 00:10:26 为什么产品优于研究 00:15:49 演变…

Latent Space ▷ #llm-paper-club-west (26 条消息🔥):

• Mixtral-8x22B 首次亮相：Mixtral-8x22B 模型已转换为 HuggingFace Transformers 格式并可供使用，对负责转换的用户表示感谢。提供了使用 transformers 运行该模型的说明，以及模型链接和 Twitter 公告。
• DeepSeekMoE 挑战 Google 的 GShard：据报道，具有共享专家和细粒度专家分割特征的 DeepSeekMoE 性能足以媲美或超越 Google 的 GShard 模型，并提供了论文链接以了解架构详情。
• Mixture of Experts 教育资源：HuggingFace 的一篇博客文章讨论了 Mixture of Experts (MoEs) 以及最近发布的 Mixtral 8x7B，被推荐为 MoE 概念初学者的入门资源。
• MoE 中专家专业化的探索：社区讨论了 Mixtral 的 MoE 性能和专家专业化（expert specialization）的概念，将 MoE 与在推理时进行专业化的 semantic router 进行对比，并思考这些模型是如何实现专家专业化的。
• 关于 MoE 模型冗余和专业性的疑问：围绕 MoE 模型专家内部的实际学习和专业化过程展开了对话，并提供了 semantic router 的 GitHub 仓库作为参考，同时对 device loss 的实现及其在报告的源代码中明显缺失感到好奇。

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

• Draw Things 因闭源受到批评：成员们对 Draw Things 表示不满，提到它不是开源的，也没有对社区做出实质性回馈。还指出所谓的开源版本缺少 metal-flash-attention support 等核心功能。
• 对 TempestV0.1 声明的怀疑：讨论了 TempestV0.1 Initiative 并持怀疑态度，特别是关于其 300 万步训练的声明以及其数据集大小的可信度——据称 600 万张图像仅占用 200GB。
• 对 Laion 5B 演示的关注：用户询问了 Laion 5B Web 演示的状态，一些人预计它不会恢复。然而，提到 Christoph 曾表示它会回归，但未提供具体细节或时间表。
• 防范潜在诈骗的警告：对与加密货币和虚假关联 LAION 的代币相关的诈骗表示显著担忧。警告用户保持警惕，讨论表明此类活动正在利用 LAION 的名义。
• 对误导性信息和解决方案的不满：指出了误导性信息的持续问题，特别是 Twitter 等平台上虚假声明的流传。建议置顶公告或添加到自动审核系统中以帮助防止这些诈骗。

LAION ▷ #announcements (1 条消息):

• 警惕虚假 LAION NFT 声明：针对一个发布 LAION 将发行 NFT 虚假广告的虚假 Twitter 账号，官方已发布警告。LAION 郑重澄清，其不销售任何产品，没有雇员，是开源社区的一部分，提供开放、透明且免费的 AI 资源。

LAION ▷ #research (19 messages🔥):

• Intel 与 AMD 及 Nvidia 的制造对比：会议指出，Intel 自行制造芯片，而 AMD 和 Nvidia 则使用 TSMC 进行半导体代工。
• LRUs 在 LRA 上展现潜力：改进的最近最少使用（LRUs）算法被认为在 Long Range Arena (LRA) 长上下文性能基准测试中表现良好。
• Guidance 权重策略提升 Diffusion Models：一项研究强调了将 guidance 限制在特定噪声水平对 Diffusion Models 的益处；通过这种方式，可以提高推理速度并提升图像质量（研究论文）。
• 将研究应用于实际工具：关于动态管理 classifier-free guidance (CFG) 的信息已关联到现有的 GitHub issue 以供参考，表明此类研究成果正被积极整合到工具实现中，例如 huggingface 的 diffusers（GitHub issue）。
• 动态 Guidance 调度作为一个学习过程：一位成员建议将 CFG 的动态调度视为一个更细粒度且可能通过学习获得的过程，并参考了为每个时间步设置独立缩放值的方法，甚至借鉴了 EDM2 中连续时间步的技术。

LAION ▷ #learning-ml (1 messages):

• 寻找 HowTo100M 数据集：一位成员询问是否有人可以访问 HowTo100M 数据集，并对该请求的合适频道表示不确定。HowTo100M 是一个包含教学视频的大规模数据集。

LlamaIndex ▷ #announcements (1 messages):

• LlamaIndex PandasQueryEngine 移至 Experimental：即将发布的 LlamaIndex (python) v0.10.29 将把 PandasQueryEngine 移动到 llama-index-experimental。用户应使用 from llama_index.experimental.query_engine import PandasQueryEngine 调整代码，并通过 pip install llama-index-experimental 进行更新。

LlamaIndex ▷ #blog (4 messages):

• 与你的代码对话：由 @helloiamleonie 编写的新教程展示了如何创建一个允许你与 GitHub 仓库代码对话的应用。该教程详细介绍了使用 Ollama 等工具设置本地 LLM 和 embedding 模型的过程。

• 通过自动合并增强 RAG 检索：针对 RAG 中由于朴素分块导致的上下文“断裂”问题，提出了一种解决方案，涉及通过自动合并检索动态创建更连续的数据块。

• Create-tsi 工具包发布：与 T-Systems、Marcus Schiesser 合作，并受 Llama Index 的 create-llama 工具包启发，发布了一个全新的符合 GDPR 的全栈 AI 应用工具包 create-tsi。

• 复杂 LLM 查询的自动抽象：由 Silin Gao 等人提出的新 Chain of Abstraction 技术旨在克服当前框架在不同 LLM 之间进行结合工具使用的多步查询规划时面临的挑战。

LlamaIndex ▷ #general (101 messages🔥🔥):

• 微调 (Fine-Tuning) 与检索增强生成 (Retriever Augmented Generation)：成员们讨论了 fine-tuning 在问答任务中的缺点，强调了知识保留效率低下和对数据集要求极高的问题。在这种情况下，Retriever Augmented Generation (RAG) 因其准确性、成本和灵活性而更受青睐。

• Embedding 存储困惑已解决：关于 embedding 存储的问题得到了澄清；它们存储在 storage context 内的向量存储（vector store）中。会议还提到了即将推出的 knowledge graph 改进，可能会简化这一过程。

• Embedding 中元数据 (Metadata) 的澄清：解释了在生成 embedding 和 LLM 处理过程中，默认情况下不会排除 metadata，但如果需要可以手动删除。用户讨论了如何通过提供的代码片段在代码中实现此类排除。

• Ollama 中的 LLMs 参数设置：一位用户询问了在使用 Ollama 加载模型 时如何设置 temperature 和 top_p 等 LLM 参数。提供了一个 GitHub 代码引用，展示了如何传递额外参数。

• 使用 Fastembed 排除向量存储问题：讨论了 ‘fastembed’ 导致 QdrantVectorStore 崩溃的问题，成员们建议这可能是由于混合搜索（hybrid search）的可选依赖项引起的。据报告，降级到特定版本 (‘llama-index-vector-stores-qdrant==0.1.6’) 为一位用户解决了该问题。

LlamaIndex ▷ #ai-discussion (1 条消息):

• LlamaIndex 获得记忆增强：一位成员分享了一篇关于使用基于 Colbert 的 Agent 为 LlamaIndex 增强文档检索记忆功能的教程。它概述了将记忆功能集成到检索过程中的步骤，以提高性能。

OpenInterpreter ▷ #general (80 messages🔥🔥):

• Discord 中的 Litellm 问题：成员们正在讨论 litellm 的问题，包括功能的突然中断；有人建议通过检查 interpreter --version 并运行 pip show litellm 命令来进行诊断。还有建议在 issues 频道继续讨论该问题，该问题随后在那里得到了解决。
• OpenAI 额度方案及变更：OpenAI 正在转向预付额度并停止按月计费；他们提供了一个免费额度促销，用户在 2024 年 4 月 24 日前购买最低金额即可获得。成员们询问并分享了他们对这一变化如何影响不同 OpenAI 账户类型的理解。
• 社区活动邀请与回顾：分享了一个名为 Novus 的温哥华初创企业建设者社区活动，强调务实的网络交流和建设。此外，还提供了关于过去一次成功使用 Open Interpreter 作为库的会议信息，并附带了一个包含入门模板的 GitHub 仓库链接。
• Open-Interpreter 的故障排除与修复：一位在使用 Open-Interpreter 时遇到困难的成员收到了建议，包括从特定的 git commit 重新安装包以解决问题的命令。讨论还揭示了依赖项之间潜在的兼容性问题，并建议设置环境变量以顺利使用 Open-Interpreter。
• 通过 YouTube 和 ChatGPT 学习 Python：有人咨询学习 Python 的最佳课程，建议了各种方法，包括 YouTube 教程、在 ChatGPT 辅助下进行基于项目的学习，以及一个针对 Tina Huang 的 YouTube 频道的特定推荐。

OpenInterpreter ▷ #O1 (24 messages🔥):

• Poetry 安装小故障：一位成员在安装 Poetry 时，由于 poetry 和 pip 都出现“未找到命令”错误，导致执行 poetry install 失败。建议尝试 pip install poetry 并在特定频道寻求进一步帮助，后来发现是 Python 本身未安装。

• 设备配置困惑：有人在 M5 Atom 设备的 WiFi 设置过程中遇到困难，手机上没有收到输入服务器地址的提示。该问题已得到确认，并提议进行进一步测试以寻找解决方案。

• 增强文档的建议：一位成员详细的教学内容受到了称赞，并有人提议将其纳入官方文档，该成员对此表示感谢并同意。

• 询问设备预订等待时间：有人询问了预订设备的交付状态，得到的澄清是这些设备仍处于预生产阶段，预计在夏季发货。

• 预见制造延迟：关于设备制造延迟的讨论强调了初创公司面临的常见挑战，指出产品仍处于原型阶段，并鼓励保持耐心，因为即使是“优秀的初创公司”通常也需要比预期更长的时间。

OpenInterpreter ▷ #ai-content (2 messages):

• Transformers 进军 JavaScript: 分享了 transformers.js GitHub 仓库，允许最先进的机器学习直接在浏览器中运行，无需服务器。这是 HuggingFace Transformers 库的 JavaScript 移植版本。
• AI 模型端点揭晓: 一名成员发布了 https://api.aime.info 的链接，推测是一个与 AI 模型相关的 API 端点，但未提供进一步的信息或背景。

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

• 新人寻求指导: 一名成员表达了尽管编程经验和时间有限，但仍渴望为 Axolotl 做出贡献。其他人的建议包括在 GitHub 上复现并确认问题、专注于文档工作，以及使用简单的 “print” 语句来调试代码。

• 期待 LLaMA-3: 成员们就由于期待 Meta 的新 LLaMA-3 而推迟微调工作展开了辩论，一些人引用了 Meta 合作发表的一项关于语言模型中知识位缩放的研究，认为这可能是 LLaMA-3 的“秘密武器”。

• Mistral-22B 稠密模型转换: 分享了关于 Mistral-22B-V.01 发布的公告，该模型代表了首次将混合专家模型 (MoE) 转换为稠密模型格式。

• 讨论层冻结的价值: 一名成员提到最近的一篇论文，建议可以移除模型一半的层而不损失性能；然而，其他人认为这可能导致过度训练，且即使移除一层也可能对模型产生重大影响。

• 开源 GPU 内核模块引发关注: 关于 GitHub 上支持 P2P 的开源 GPU 内核模块 的公告引发了讨论，表明 NVIDIA 4090s 在模型训练方面可能变得更加可行。

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

• 建议的 Axolotl 配置最佳实践：一名成员指出，将最佳实践和社区见解纳入 Axolotl 配置 非常重要，并引用了一个 Reddit 帖子 作为例子，该帖子详细介绍了 LORA 模型中层训练（layer training）的选项。
• Flash Attention 2.0 的 GPU 初始化错误：一位用户遇到了一个错误，提示 “You are attempting to use Flash Attention 2.0 with a model not initialized on GPU.”（你正尝试在未于 GPU 上初始化的模型上使用 Flash Attention 2.0）。他们表示，仅针对 11 层进行处理的解决方案奏效了。
• 逐层训练的考量：有一场关于一次训练 11 层的讨论，推测是为了管理计算资源或内存限制。
• Bigstral 训练查询：一位用户确认正在训练一个名为 Bigstral 的模型，另一位用户则开玩笑地质疑了这个名字。
• 解冻权重子集的概念：讨论了在训练的每一步中解冻随机权重子集的可能性，这被设计为一种适应低 GPU 资源用户的策略。有人指出，目前的实现通常仅支持在开始时冻结模型的部分。

提到的链接：Reddit - Dive into anything：未找到描述

OpenAccess AI Collective (axolotl) ▷ #datasets (3 条消息):

• 寻求逻辑数据集：一位用户询问了专注于自然文本中命题逻辑和谓词逻辑推理的数据集，旨在对语言数据执行形式化推理方法。
• 寻找大规模数据集：另一名成员表示需要一个 2000 亿 token 的数据集 来预训练一个新的实验性架构。针对这一需求，一位用户建议考虑 slimpajama 数据集并提取合适的子集。

OpenAccess AI Collective (axolotl) ▷ #community-showcase (3 条消息):

• 面向初学者的 Axolotl：分享了一篇新的博客文章，旨在帮助初学者开始使用 axolotl。作者在微调 encoder LLM 方面经验丰富，现在开始尝试训练 decoder LLM，并计划继续构建和分享关于开发“有用”模型的见解。
• 共同跨越学习曲线：针对关于 axolotl 的博客文章，一位成员表示感谢，指出它可以作为该工具初学者的良好入门指南，并可能对其他新手有所帮助。
• 使用 Axolotl 调试数据：一位成员提供了使用 axolotl 的技巧：在预处理期间应用 --debug 标志，以确保数据记录正确。这有助于避免在模型训练或评估的后期阶段出现问题。

OpenAccess AI Collective (axolotl) ▷ #axolotl-help-bot (18 条消息🔥):

• Colab Notebook 创建请求：一位用户寻求帮助，希望使用预装版本的 PyTorch 创建 Google Colab notebook，旨在指定推理的 prompt。他们需要一个框架，结合 axolotl 对来自 Hugging Face 的数据集进行基础模型 (Tiny-Llama) 的 finetune，并针对原始模型和 finetuned 模型执行查询。
• Axolotl Colab Notebook 可用性：提到在 此 GitHub 链接 提供了一个 Colab notebook，可以引导其使用 TinyLlama config 进行模型操作。
• Continued Pretraining 配置：一名成员请求一个示例 config，以便在 Hugging Face 数据集上继续预训练 TinyLlama。共享了一个详细的 pretrain 配置，用于设置和启动 pretraining 过程，其中包含针对用户任务的优化选项和环境设置。
• 使用 Docker 进行基于 DeepSpeed 的多节点 Fine-Tuning：一位用户询问了使用 Docker 进行 DeepSpeed 多节点 finetuning 的步骤。提供了详细步骤，涵盖 Docker 镜像准备、DeepSpeed 配置、节点准备、Docker 容器启动以及集成 DeepSpeed 的训练脚本运行。

OpenAI ▷ #ai-discussions (54 messages🔥):

• 报告 OpenAI API 问题：一名成员在使用 OpenAI Assistant API 时遇到问题，在 Python 中调用 client.beta.messages.create 方法时出现 AttributeError。他们怀疑文档相对于新版本的 OpenAI 库可能已经过时，并分享了有问题的 代码片段。

• AI 模型的混合体验：讨论强调了对 Gemini 1.5 和 Claude 等各种 AI 模型的个人体验，比较了它们的 context windows、记忆召回能力以及处理代码相关查询的方式。大家认识到 API 配额的限制以及不同模型根据任务复杂度表现出的不同有效性。

• 寻求 C# 开发的最佳模型：一名成员询问用于为 Unity 游戏引擎开发 C# 脚本的最佳 AI 模型，寻求能够一次性成功的模型。建议尝试最新的 gpt-4-turbo 和可能的 Opus，并建议直接将文档提供给 ChatGPT 以获得更好的 context。

• 处理 LLM 的大量函数：一名成员就如何在无法传递所有函数 schemas 的情况下，让 LLM 处理 300 个函数寻求建议。对话演变为讨论使用 embeddings 作为解决方案，以及为每个函数创建简明摘要或可能将其分布在多个 Agents 之间的策略。

• ChatGPT 知识更新的局限性：一名成员关于当前足球队的查询得到了来自 ChatGPT 的过时信息，另一名成员解释说，由于 ChatGPT 不会实时更新其知识库，除非它被编程为浏览互联网获取更新，否则可能会提供过时信息，而这一功能在 GPT-3.5 中并不可用。

OpenAI ▷ #gpt-4-discussions (8 messages🔥):

• GPT-4 速度不一致的报告：一位用户对 GPT-4 变慢表示担忧，而其他人则认为可能是 Wi-Fi 问题，尽管原用户声称其网络运行正常。
• GPT-4 Turbo 在 Function Calls 方面能力较弱：有消息指出，新的 GPT-4-turbo 模型在 Function Calling 方面的效率显著降低，但未提供进一步的背景或支持证据。
• 访问 GPT-4 Turbo：一位用户询问如何验证他们是否可以在网站上访问 GPT-4-turbo 模型，但未提供更多细节或说明。
• 使用 GPT 编辑大型文档：一位成员询问使用 GPT 处理大型文档的可行性，质疑是否可能超出正常的 Context Window，以及如何启用文档编辑（这可能需要第三方服务）。

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

• Wolfram GPT 宇宙指南：一位成员提供了使用 Wolfram 与 GPT 配合的直接解决方案，引导通过 Wolfram GPT 链接 进行访问，并提到一旦访问过，就可以使用 @mention 功能。
• Prompt Engineering 入门：一位新成员请求学习 Prompt Engineering 的资源，并被推荐了一个名为 Prompting Guide 的网站，该网站提供有关该主题的全面信息。

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

• Wolfram GPT 集成说明：用户询问如何让 GPT 与 Wolfram 配合工作。说明指出可以通过使用 Wolfram GPT 并在对话中使用 @mention 功能来实现。

• 开始学习 Prompt Engineering：一位社区新成员寻求 prompt-engineering 的资源。他们被引导至一个名为 promptingguide.ai 的实用网站。

DiscoResearch ▷ #mixtral_implementation (13 messages🔥):

• Mistral 扩展至 22B：一个名为 Mistral-22b-V.01 的全新 22B 参数 Dense 模型已经发布，这一里程碑引发了热烈讨论。该模型是一个压缩的 MoE，被转换为 Dense 形式，被誉为第一个成功的 MoE 到 Dense 模型的转换。

• 讨论 Mergekit 的挑战：社区关于使用 Mergekit 将模型转换为 MoE 模型并进行后续微调的实验报告了令人失望的结果；通常，这些自定义的 MoE 合并模型表现不如原始模型，且目前尚未发布任何优越的 MoE 合并模型。

• 介绍 Zephyr 141B-A35B：新的 Zephyr 141B-A35B 模型已发布，这是一个使用名为 ORPO 的新型算法训练的助手模型，是 Mixtral-8x22B 的微调版本，在强大的硬件上仅用 1 小时多一点的时间完成了 7k 实例 的训练。该模型可以在 HuggingFace 的模型库 中找到。

• Mixtral vs. SFT 性能之争：关于 Supervised Fine-Tuning (SFT) Mixtral 模型与原始 Mixtral Instruct 性能的讨论，一些成员断言在特定领域进行 SFT 的效果优于通过 Mergekit 创建的 MoE 模型。

• 关于微调 22b 模型的疑问：社区成员很好奇并询问是否有人成功微调了 22b 模型，特别是考虑到官方 Mixtral 模型在 Routing 方面可能拥有的“秘密配方”，这可能导致 Mixtral Instruct 的性能优于微调变体。

DiscoResearch ▷ #general (4 messages):

• 关于德语语言 Benchmark 的咨询：一位用户表示有兴趣看到模型在“德语语言 Benchmark”上运行。随后讨论了德语 Benchmark 的相关性，并提到了 lm eval harness 的常用性。

• 获取完整模型评估输出：一个包含 Open LLM Leaderboard 完整评估输出的数据集已发布。对于 Mixtral-8x22B-v0.1 模型，可以通过 Hugging Face 访问该数据集。

提到的链接：open-llm-leaderboard/details_mistral-community__Mixtral-8x22B-v0.1 · Hugging Face 数据集：未找到描述

DiscoResearch ▷ #discolm_german (22 条消息🔥):

• DiscoLM 70b 德语能力受到质疑：一位用户询问是否对 DiscoLM 70b 进行了消融实验（Ablations），这是一个具有 700 亿参数、经过 650 亿 Token 德语预训练的模型。回复提到由于其他优先级，目前尚未进行消融实验，但计划很快推出带有改进数据集的新模型。
• 英语+德语微调（Finetuning）平衡：成员们讨论了在微调像 DiscoLM 70b 这样的模型时，英语和德语数据之间的理想平衡。有人担心在英语微调后，可能会削弱模型之前加强的德语能力。
• 通过微调探索语言细微差别：一位用户提供了一篇论文链接，讨论了多语言模型微调，但对该过程中语言不平衡的影响表示不确定。另一篇论文提出了一个评估大型语言模型内跨语言知识对齐的框架，可在此处查看。
• Occiglot-7B-DE-EN-Instruct 的成就：一位用户展示了他们在 Occiglot-7B-DE-EN-Instruct 上的工作，表明其在基准测试中表现良好，这暗示英语和德语数据的混合可能是有效的。然而，他们警告说，目前的德语基准测试不足以进行深入分析，并分享了 Occiglot Research 页面。
• 在语言模型预训练中利用 SFT 数据：讨论了在预训练阶段（而非仅在标准 SFT 期间）加入有监督微调（SFT）数据的好处。这次讨论是由 StableLM 的技术报告和 MiniCPM 的发现引发的，表明在预训练阶段包含 SFT 数据可能有助于防止过拟合（Overfitting）并增强泛化（Generalization）能力。

Interconnects (Nathan Lambert) ▷ #news (12 条消息🔥):

• 提及 Claude 的演进：Nathan Lambert 强调了从 Claude 2 到 Claude 3 的转变，质疑了这种变化的意义，并将其描述为“渐进式的 (INCREMENTAL)”。
• 质疑 Hard Fork：Lambert 表达了沮丧，认为本周的 hard fork 似乎与当前的 AI 发展不一致，并觉得这“让他感到不安 (triggering me)”。
• 寻求 Open Data 细节：Lambert 注意到 AI 社区内似乎缺乏关于 open data 的详细讨论，并用一声“咳咳 (AHEM)”可能暗示呼吁更多的关注。
• 审视对 AI 的新闻观点：Eugene Vinitsky 观察到，大众科技记者可能对技术怀有厌恶感，他认为这是“最奇怪的事情”。

提到的链接：rohan anil (@arohan) 的推文：有趣！“回答以下多选题。你回答的最后一行应采用以下格式：’ANSWER: $LETTER’（不带引号），其中 LETTER 是 ABCD 之一。…

Interconnects (Nathan Lambert) ▷ #ml-questions (6 messages):

• 模型训练中的混合方法：一位成员指出，在实践中，pretraining、Supervised Fine-Tuning (SFT) 数据集和 Reinforcement Learning from Human Feedback (RLHF) 提示词在训练过程中经常被混合在一起，但也承认这一点并没有被清晰地记录在文档中。
• 关于“混合 (Blend)”的澄清：该成员澄清说，他们所说的“混合”是指使用 curriculums、schedulers 或 annealing 等机制来结合不同的训练方法，尽管缺乏明确的文档说明。
• 文档与知识共享：该成员承诺很快会分享更多专门关于 annealing 的信息，暗示了即将发布的流程见解。

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

• 作为祝贺的 Meme：讨论显示有人可能输入了一个祝贺短语作为 meme，这被认为很有趣。
• 订阅困惑已消除：当被问及订阅是否需要接受时，澄清了接受功能已关闭，使订阅过程自动完成。
• 潜在的新服务器成员：有人猜测 Satya 可能会加入服务器，有人暗示已经推荐了他，随后是确认以及关于需要进行一些招募的说明。

Interconnects (Nathan Lambert) ▷ #reads (1 messages):

• 考察 Google 的 CodecLM：一位成员分享了一篇关于 CodecLM 的论文，这是 Google 使用定制合成数据对齐语言模型的方法。该成员观察到，这似乎是“向更强大的模型学习 (learn-from-a-stronger-model)”策略的又一个案例。

Interconnects (Nathan Lambert) ▷ #sp2024-history-of-open-alignment (1 messages):

• LLaMA 研究分享：分享了一个指向 “LLaMA: Open and Efficient Foundation Language Models” 论文的链接，该论文已发布并可在 Hugging Face 上访问。该论文发表于 2023 年 2 月 27 日。

提到的链接：aligning open language models - a natolambert Collection：未找到描述

tinygrad (George Hotz) ▷ #general (18 messages🔥):

• 缓存一致性与性能：在讨论缓存层级时，一条消息强调了像 L1 这样的低级缓存由于一致性管理较少而速度更快。异构共享缓存池虽然比从 RAM 传输数据到 VRAM 快，但仍无法与具有专用 CCX 缓存的 CPU 上直接从 L3 到 L1 的缓存传输速度相媲美。

• 编程语言的可移植性与安全性：一位成员认为 ANSI C 默认在所有硬件上都受支持，且易于移植到硬件描述语言。相反，另一位成员分享了一个指向 Rust 漏洞详情的链接，批评了将 Rust 视为编程安全“银弹 (magic bullet)”的看法。

• 关于 Rust Foundation 政策的争议：一位用户指出了 Rust Foundation 针对使用 “Rust” 一词以及修改 Rust 徽标的限制性政策，并将其与 Oracle 和 Red Hat 等组织进行比较，由于“政治不安全性”和许可限制，他们避开了这些组织。

• AI 律师项目愿景：一位个人表示拒绝接受任何会让外部控制其项目的许可，特别提到了构建 AI 律师的愿景，并希望避免因法律战（lawfare）导致被收购或破产。

• 因离题讨论而被 Discord 封禁：针对用户关于编程语言的离题言论，George Hotz 澄清说，进一步的无关讨论将导致封禁，随后一名名为 endomorphosis 的用户因发布无贡献消息而被封禁。

tinygrad (George Hotz) ▷ #learn-tinygrad (6 messages):

• Tiny 命名难题：Discord 聊天参与者幽默地集思广益，为潜在的项目名称建议了 tinyxercises 和 tinyproblems。
• 名称认可：一位参与者对集思广益的名称做出了积极回应，用简洁的 “ayyy” 表示偏好。
• Tiny 形式的感谢：另一条回复以创意的方式表达了感谢，在聊天中创造了 tinythanks 一词。

Skunkworks AI ▷ #datasets (7 messages):

• 寻求逻辑推理数据集：一位用户询问了关于对自然文本进行形式逻辑推理的数据集。另一位用户提供了一个精选列表，其中包含数学、逻辑和推理数据集的资源。
• 符号求解器和 LLM 的资源共享：用户交换了链接，包括名为 Logic-LLM 的 GitHub 仓库，这是一个旨在为语言模型赋能符号求解器的项目。
• 关于大语言模型 Coq 的学术工作：分享了一个 arXiv 论文链接，该论文讨论了一个旨在提高 LLM 理解和生成 Coq 代码能力的数据集。
• 关于推理项目的澄清：
  • 一位用户寻求关于一个项目的澄清，该项目旨在通过将人类文本翻译成 Lisp 并执行，来增强现有的 LLM 架构以实现更好的推理。
  • 解释强调了利用预设 LLM 并通过在潜空间（latent space）中进行计算并保持端到端可微性来增强推理能力的目标。
• 推理资源汇编更新：确认已将推荐资源添加到 awesome-reasoning 仓库，该仓库是一个旨在辅助推理 AI 开发的集合。更新已通过 commit history 确认。

LLM Perf Enthusiasts AI ▷ #claude (3 条消息):

• Haiku 速度受到质疑：一位成员对 Haiku 提出了担忧，质疑其速度提升，而这曾被认为是该模型的主要优势。

• 吞吐量 vs. 响应时间：另一位成员强调，他们最关心的不是 throughput（吞吐量），而是使用 Haiku 时的 total response time（总响应时间）。

LLM Perf Enthusiasts AI ▷ #openai (4 条消息):

• 对 Turbo 的热烈反应：一位成员询问了社区对新版 turbo 的看法。
• 代码熟练度提升：另一位参与者确认，新版 turbo 在处理代码方面确实表现更好。
• 增强的速度性能：还有人提到新版 turbo 具有更快的性能表现。
• 重新激活 Plus 以探索 Turbo：针对这些反馈，一位成员考虑重新激活他们的 ChatGPT Plus 来测试新版 turbo。

Alignment Lab AI ▷ #ai-and-ml-discussion (1 条消息):

fredipy: <@748528982034612226>

Alignment Lab AI ▷ #general-chat (4 条消息):

• 代码协助请求：一位成员寻求代码方面的帮助，并直接请求私信（DM）。
• 对服务器邀请的担忧：另一位成员对服务器上普遍存在的 Discord 邀请感到沮丧，并提议禁止这些邀请以防止此类问题。

Alignment Lab AI ▷ #oo2 (1 条消息):

aslawliet: 这个项目还活跃吗？

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

• Gemini 升级 - 视频音频处理能力：Gemini 在视频中回答音频相关问题的能力已在 AI 课程中进行了测试，显示出显著改进（此前仅能生成不含音频的描述）。
• Google 粘贴痛点：成员们分享了在将文本粘贴到 Google Playground 时遇到的文本格式问题，希望能有解决方案。
• STORM 带来震撼：重点介绍了 GitHub 上的 STORM 项目，展示了一个 LLM 驱动的知识策展系统，它可以研究某个主题并生成带有引用的完整报告。

提到的链接：GitHub - stanford-oval/storm: An LLM-powered knowledge curation system that researches a topic and generates a full-length report with citations.：一个 LLM 驱动的知识策展系统，可以研究某个主题并生成带有引用的完整报告。 - stanford-oval/storm

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

• Pull Request 修复 macOS Zsh 命令挂起问题：MacOS 上 llm-cmd 的一个导致终端挂起的问题已通过新的 Pull Request 解决。已确认可在 M1 MacOS Terminal 和使用 zsh 的 Alacritty 上运行。

提到的链接: fix: macos zsh llm cmd hangs by nkkko · Pull Request #12 · simonw/llm-cmd: 修复了 #11，已在 M1 MacOs (14.3.) 的 Terminal 和 Alacritty (zsh) 中测试，现在运行正常。

Mozilla AI ▷ #announcements (1 条消息):

<ul>
  <li><strong>Gradio UI for Figma 发布：</strong> Mozilla Innovations 推出了 <strong>Gradio UI for Figma</strong>，这是一个基于 Hugging Face 的 Gradio 的库，旨在促进设计阶段的快速原型设计。在 <a href="https://www.figma.com/@futureatmozilla">Figma 此处</a>访问工具包。</li>
  <li><strong>加入 Gradio UI 讨论：</strong> 关于 <strong>Gradio UI for Figma</strong> 与来自 Mozilla’s Innovation Studio 的 Thomas Lodato 的对话线程已开启，供有兴趣进一步讨论该工具的人员使用。通过 <a href="https://discord.com/channels/1089876418936180786/1091372086477459557/1228056720132280461">此线程</a>加入 Discord。</li>
</ul>

提到的链接: Figma (@futureatmozilla) | Figma: 来自 Mozilla Innovation Projects (@futureatmozilla) 的最新文件和插件 —— 我们正在构建专注于创建更加个性化、私密和开源互联网的产品。

Mozilla AI ▷ #llamafile (4 条消息):

• 在 Llamafile 中探索 OCR: 一位成员询问了 llamafile 的 OCR 能力，引发了对其潜在用途的兴趣。
• 深度学习中的 Rust - 探索 Burnai 的呼吁: 一位成员称赞了他们发现的一个项目 Burnai，该项目使用 Rust 进行深度学习推理，并建议社区调查其在跨平台推理方面极具前景的优化。他们欣赏 justine.lol/matmul 上的相关工作，并在 burn.dev 分享了关于 Burnai 的信息，强调了其对性能的关注。
• Llamafile 已通过 Mcaffee 认证: llamafile 0.7 binary 已被 Mcaffee 列入白名单，一位成员用庆祝表情符号指出。
• 热烈欢迎新成员: 一位新成员在频道中打招呼，对富有成效的合作和讨论表示热忱。

提到的链接: Burn: 未找到描述

AI21 Labs (Jamba) ▷ #jamba (4 条消息):

• 寻找 Jamba 代码: 一位用户表示有兴趣寻找 Jamba 的源代码。
• 等待更新: 一位用户询问是否有任何更新，暗示是对之前消息或正在进行的讨论的后续跟进。
• 分享模型合并仓库: 一位用户分享了一个 GitHub 仓库链接 (moe_merger)，详细介绍了他们合并模型的过程。他们指出该方法尚未经过彻底测试。
• 对分享资源的感谢: 另一位用户对分享的模型合并仓库表示感谢。