ainews-deepseek-v2-beats-mixtral-8x22b

DeepSeek-V2 性能超越 Mixtral 8x22B：拥有 160 多个专家，且成本仅需一半。

· 71868cce-79a2-4ff0-af3e-13d4e6017711

DeepSeek V2 推出了一款新型的顶尖混合专家（MoE）模型，拥有 2360 亿参数和一种新颖的多头潜在注意力（Multi-Head Latent Attention）机制，实现了更快的推理速度，并在 AlignBench 基准测试上超越了 GPT-4。Llama 3 120B 展示了强大的创意写作能力，而据报道，微软正在开发一个名为 MAI-1 的 5000 亿参数大语言模型。Scale AI 的研究强调了 Mistral 和 Phi 等模型中存在的过拟合问题，而 GPT-4、Claude、Gemini 和 Llama 则保持了基准测试的鲁棒性。在机器人领域，特斯拉 Optimus 凭借卓越的数据采集和远程操控技术取得进展，LeRobot 标志着向开源机器人 AI 的迈进，而英伟达的 DrEureka 则实现了机器人技能训练的自动化。此外，一项调查研究了多模态大语言模型的幻觉问题并提出了新的缓解策略，谷歌的 Med-Gemini 通过微调的多模态模型在医学基准测试中达到了业内领先（SOTA）的水平。

#mixture-of-experts #multi-head-attention #model-inference #benchmarking #overfitting #robotics #teleoperation #open-source #multimodality #hallucination-detection #fine-tuning #medical-ai #model-training deepseek-v2 llama-3-120b llama-3-400b gpt-4 mistral phi claude gemini mai-1 med-gemini deepseek-ai mistral-ai microsoft openai scale-ai tesla nvidia google-deepmind

2024年5月3日至5月6日的 AI 新闻。我们为您查阅了 7 个 subreddit、373 个 Twitter 账号 和 28 个 Discord 社区（419 个频道，共 10335 条消息）。为您节省了预计阅读时间（以 200wpm 计算）：1112 分钟。

更多专家就是你所需要的一切？

DeepSeek V2 突破了上个月的 Mistral 凸包 (Convex Hull)：

image.png

关于数据集的信息非常少；他们只提到它是 8B tokens（是 DeepSeek v1 的 4 倍），其中中文比例比英文高出约 12%。

Snowflake Arctic 是我们之前见过的最后一个拥有最高专家数量（128 个）的超大型 MoE 模型；DeepSeek v2 现在设定了新的标杆，不仅扩展了 DeepSeekMOE 已经取得的成功，还引入了一种名为 Multi-Head Latent Attention 的新注意力变体。

image.png

通过缓存压缩后的 KV（“减少了 93.3% 的 KV cache”），这显著提升了推理速度。

image.png

论文详细介绍了他们发现有效的其他小技巧。

DeepSeek 正在用实际行动证明自己——他们在平台上提供的 token 推理价格为每百万 token 0.28 美元，大约是 2023 年 12 月 Mixtral 价格战 中最低价格的一半。

目录

[TOC]

AI Twitter 回顾

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

LLM 进展与发布

  • Llama 3 发布：@erhartford 指出 Llama 3 120B 比 Opus 更聪明，并对 llama3-400b 充满期待。@maximelabonne 分享道，Llama 3 120B 在创意写作方面优于 GPT-4，但在推理方面逊于 L3 70B。
  • DeepSeek-V2 发布：@deepseek_ai 推出了 DeepSeek-V2，这是一款开源 MoE 模型，在 AlignBench 中位列前三，超越了 GPT-4。它拥有 236B 参数，生成过程中仅激活 21B。
  • 来自 Microsoft 的 MAI-1 500B：@bindureddy 预测 Microsoft 正在训练自己的 500B 参数 LLM，名为 MAI-1，可能会在 Build 大会上预展。一旦发布，它将与 OpenAI 的 GPT 系列展开竞争。
  • Mistral 和开源 LLM 的基准测试过拟合问题：@adcock_brett 分享了 Scale AI 发布的研究，揭示了 Mistral 和 Phi 等某些 LLM 在流行 AI 基准测试中存在“过拟合”现象，而 GPT-4、Claude、Gemini 和 Llama 则表现稳健。

机器人与具身智能 (Embodied AI)

  • Tesla Optimus 更新：@DrJimFan 祝贺 Tesla Optimus 团队的更新，指出他们的人类数据采集场是 Optimus 最大的领先优势，拥有顶级的机械手、远程操作软件、庞大的车队以及精心设计的任务和环境。
  • LeRobot 开启开源机器人技术：@ClementDelangue 欢迎由 @remicadene 及其团队开发的 LeRobot，这标志着机器人 AI 向开源方向的转变。
  • 来自 Nvidia 的 DrEureka：@adcock_brett 分享了 Nvidia 的 “DrEureka”，这是一个 LLM Agent，可以自动编写代码来训练机器人技能，用于在模拟中训练机器狗的技能，并将其零样本（zero-shot）迁移到现实世界。

多模态 AI 与幻觉

  • 多模态 LLM 幻觉综述：@omarsar0 分享了一篇论文，对多模态 LLM 中的幻觉进行了综述，讨论了在检测、评估、缓解策略、原因、基准测试、指标和挑战方面的最新进展。
  • 来自 Google 的 Med-Gemini：@adcock_brett 报道了 Google 推出的 Med-Gemini，这是一个针对医疗任务进行微调的 AI 模型系列，在文本、多模态和长上下文应用的 14 个基准测试中，有 10 个达到了 SOTA。

新兴架构与训练技术

  • Kolmogorov-Arnold Networks (KANs)：@rohanpaul_ai 强调了一篇论文，提议将 KANs 作为 MLPs 的替代方案来逼近非线性函数，其表现优于 MLPs，且在不使用线性权重的情况下拥有更快的 neural scaling laws。
  • 用于 Parameter-Efficient Finetuning 的 LoRA：@rasbt 从零开始实现了 LoRA，用于训练一个在 SPAM 分类中达到 98% 准确率的 GPT 模型，并指出 LoRA 是他最喜欢的 LLMs 参数高效微调技术。
  • 带有 Expert Router 的混合 LLM 方法：@rohanpaul_ai 分享了一篇关于高性价比混合 LLM 方法的论文，该方法使用 Expert Router 将“简单”查询引导至较小的模型，以在保持质量的同时降低成本。

基准测试、框架和工具

  • 从 PyTorch Lightning 导出 TorchScript 模型：@rohanpaul_ai 指出，使用 to_torchscript() 方法从 PyTorch Lightning 导出和编译模型到 TorchScript 非常顺畅，能够为非 Python 环境实现模型序列化。
  • 带有 Whisper 和 Diarization 的 Hugging Face Inference Endpoints：@_philschmid 为 Hugging Face Inference Endpoints 创建了一个优化的 Whisper（支持发言人日志），利用 flash attention、speculative decoding 和自定义处理器，在 1x A10G GPU 上实现了 60 秒音频仅需 4.15 秒的转录。
  • 用于复杂 AI Agents 的 LangChain：@omarsar0 分享了一个 2 小时的免费研讨会，内容是使用 LangChain 构建复杂的 AI Agents，用于自动化客户支持、营销、技术支持、销售和内容创作中的任务。

趋势、观点和讨论

  • LLMs 商品化：@bindureddy 认为 LLMs 已经成为一种商品，即使 GPT-5 非常出色，其他主要参与者也会在几个月内赶上。推理价格将趋于下降，表现最好的 LLM 每隔几周就会更替。最佳策略是使用 LLM-agnostic 服务，并从基础模型转向构建 AI Agents。
  • 读写能力与技术：@ylecun 分享了对不同时期人们对阅读和技术态度转变的观察，从 1900 年的“你为什么不去耕田而是读书？”到 2020 年的“你为什么不去玩平板而是看电视？”。
  • 基础研究资助：@ylecun 认为，几乎所有拨给大学的联邦资金都流向了 STEM 和生物医学研究，社会科学得到的很少，人文科学几乎为零。削减这些资金将“杀掉下金蛋的鹅”，并可能导致生命损失。

AI Reddit 回顾

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

AI 发展与能力

  • Tesla Optimus 进展：在 /r/singularity 中，一段新视频展示了 Tesla Optimus 机器人的最新能力，包括手部精细触觉和力觉感知。讨论围绕机器人的当前速度限制，以及一旦达到人类工人的“20倍速率”，在工厂进行 24/7 全天候运行的潜力。
  • Sora AI 视频渲染：在 /r/singularity 中，AI 系统 Sora 展示了在更改单个元素的同时渲染视频的能力，尽管该功能仍处于研究阶段，尚未公开发布。
  • GPT-4 训练的机器人狗：在 /r/singularity 中，一只使用 GPT-4 训练的机器人狗展示了其在滚动且放气的瑜伽球上保持平衡的能力，体现了 AI 驱动的机器人技术和平衡控制方面的进步。
  • 算力与 AI 里程碑：在 /r/singularity 中，Microsoft CTO Kevin Scott 认为 AI 里程碑成就的共同因素是使用了更多算力。讨论还涉及 Llama 3 400b 的潜力，由于其在 25,000 块 H100 上训练，而据报道 GPT-4 仅使用了 10,000 块 A100，因此其表现可能超越 GPT-4。
  • LLaMA 70B 性能：在 /r/singularity 中，一位用户报告在配备 4 年前 3090 GPU 的 7 年老旧 PC 上运行 Llama 3 70B，在某些情况下获得了比 GPT-4 和 Claude 3 更好的响应。该帖子强调了拥有一个无需互联网连接且能提供高质量输出的高智能 AI 的意义。

社会影响与担忧

AI 应用与发展

迷因与幽默

AI Discord 摘要

摘要之摘要的摘要

  • Llama3 GGUF 转换挑战：用户在使用 llama.cpp 将 Llama3 模型转换为 GGUF 格式时遇到问题，训练数据丢失与精度无关。换行符的 Regex 不匹配被认为是潜在原因，影响了 ollama 和 lm studio 等平台。社区成员正在协作进行 regex 修改等修复工作。

  • GPT-4 Turbo 性能担忧：OpenAI 用户报告了 GPT-4 Turbo 显著的延迟增加以及对消息上限阈值的困惑，部分用户经历了 5-10 倍的响应速度变慢，且上限在 25-50 条消息之间。相关理论认为这是高峰时段的动态调整。

  • Stable Diffusion 安装困扰：Stability.ai 社区成员在 Stable Diffusion 设置无法访问 GPU 资源方面寻求帮助，遇到了如 “RuntimeError: Torch is not able to use GPU” 的错误。讨论还涉及缺乏全面且最新的 LoRA/DreamBooth/微调教程。

  • Hermes 2 Pro Llama 3 的上下文表现令人印象深刻：Hermes 2 Pro Llama 3 在使用 vLLM 和 RoPE 缩放的 32GB Nvidia v100 Tesla 上展示了约 32k 的上下文，具有完美的 16k token 召回且无衰减。通过编辑 config.json 和 RoPE 缩放因子可以实现扩展上下文。

  • Perplexity AI 的 Pages 功能引起关注：Perplexity AI 用于创建综合报告的新 Pages 功能引发了热议，同时用户对 Claude 3 Opus 每天 50 条消息的限制表示沮丧，相比之下 GPT-4 Turbo 和 Sonnet 的限制较少。讨论还涉及 Perplexity 从无限消息向有限消息的转变。

  • LM Studio 启用 Headless 模式：LM Studio 用户利用 lms CLI 工具在 GUI 之外进行 headless 操作，排查内存异常并为平滑的服务器端部署制定策略，从而避免通过 RDP 消耗 VRAM。微调瓶颈也被讨论，一名成员报告在 128GB M3 Max MacBook Pro 上成功进行了 8 小时的微调。

  • CUDA 编译与多 GPU 训练挑战：CUDA 开发者遇到 nvcc 11.5 在旧款 GPU 上进行 bfloat16 操作报错的问题，并提出了一个修复方案以手动处理算术运算实现向后兼容。正如 Issue #369 所述，最近的提交还导致了多 GPU 训练挂起，目前有一个独立分支维持功能正常。

  • Mojo 编译器与类型系统演进：Mojo 的 nightly 编译器更新带来了符合当前实践的变化，不再采用 80 列宽限制，并向可寄存器传递类型（register passable types）转型。讨论涉及逐步淘汰 OptionalReg，转而支持指示寄存器传递能力的 traits，详见 changelog。

  • HuggingFace 社区亮点：HuggingFace 社区中值得关注的项目包括 Moondream 2 批处理、FLUENT 的最新迭代、HF 音频课程章节的葡萄牙语翻译，以及针对长标题的 BLIP 微调。完整列表可在社区亮点中查看。

  • Eleuther 探讨 Transformer 的国际象棋实力：一篇 arXiv 论文展示了一个 270M 参数的 Transformer 模型在没有特定领域算法的情况下，在国际象棋中超越了 AlphaZero 的策略和价值网络，这引发了 Eleuther 社区关于规模对策略游戏影响的讨论。

第 1 部分：高层级 Discord 摘要

Unsloth AI (Daniel Han) Discord

Llama3 的 GGUF 转换小故障：Unsloth 社区在使用 llama.cpp 处理 Llama3 模型时遇到了转换问题，特别是在转换为 GGUF 格式时影响了训练数据。问题不仅限于 FP16 转换，这暗示了除了精度损失之外，还存在更深层的底层问题。

换行符引发的大问题：故障中的一个反复出现的主题与换行符的 Tokenization 有关，不同正则表达式库（regex libraries）之间的行为差异导致了不稳定的 tokenizer.json 模式。社区正在探索涉及正则表达式修改的潜在解决方案，以修复 GGUF 转换挑战。

Llama 变体挑战基因组数据：M.chimiste 推出的 LLaMA-3-8B-RDF-Experiment 模型标志着将 LLM 与基因组数据和知识图谱构建相结合的尝试。

对视觉语言模型微调工具的需求：社区提出了对视觉语言模型（LVLM）通用微调方法的需求，一位成员表达了对支持 Moondream 的兴趣，详见其 GitHub notebook。

展示与分享平台的增长：关于设立专门的 LLM 部署讨论频道的提案突显了对共享学习的需求。这与 Oncord 集成 Unsloth AI 用于 Web 开发 AI 工具的展示，以及增强 Llama-3 能力的模型发布相契合。

OpenAI Discord

Perplexity AI 凭借 Pages 功能领先：Perplexity AI 新推出的 Pages 功能因其创建综合报告的能力而备受关注。与此同时，随着工程师们讨论投资回报递减的问题，对于 GPT-5 潜力的怀疑态度也随之产生。

AGI 概念引发辩论：Discord 上的 AI 社区陷入了关于 AGI 定义以及像 ChatGPT 这样的 AI 模型是否是 AGI 先驱版本的辩论。对 AI 生成音乐的兴趣表明，人们对创意 AI 应用的需求日益增长，并提到了 Udio 等服务。

GPT-4 Turbo 遭遇性能瓶颈：据报告，GPT-4 Turbo 的响应延迟显著增加，用户正在寻求关于不一致的消息上限阈值的解释，这表明在高峰时段可能存在动态调整。

Prompt Engineering 的挑战与策略：工程师们分享了经验和资源，推荐了 Teddy Dicus Murphy 的 “Wordplay” 以获取 Prompt 创作见解，并深入探讨了在 OpenAI API 中使用 logit bias 来操纵 Token 概率的复杂性。

为查询微调 AI：一场热烈的讨论围绕着微调模型以生成问题而非答案展开，包括改进用于提取产品信息的 GPT-4-TURBO Prompt 的策略，并辅以 logit bias 教程的支持。

Stability.ai (Stable Diffusion) Discord

  • GPU 问题成为焦点：成员们报告了 Stable Diffusion 安装程序无法访问 GPU 资源的问题，具体表现为 “RuntimeError: Torch is not able to use GPU” 等错误。

  • Stable Diffusion 3 传闻引发热议：关于 Stable Diffusion 3 发布的预期不断升温，引发了对其潜在延迟影响的辩论，而怀疑者则对其是否真的会发布表示质疑。

  • 微调教程的缺失：社区对缺乏关于 LoRA/DreamBooth/fine-tuning 等技术的最新、全面教程感到沮丧，许多人发现现有教程要么过时，要么细节匮乏。

  • 追求独特的面孔：一位成员询问了训练 AI 生成独特、真实面孔的策略，纠结于是对多张面孔使用 LoRA，还是在生成的随机面孔基础上进行训练。

  • 开源障碍讨论：对话转向了 Stable Diffusion 开源承诺的真实性，人们担心未来高质量模型、Checkpoints 和训练细节可能会被设置门槛。

Nous Research AI Discord

  • SVM 在 AI 圈内依然活跃：Discord 成员在技术闲聊中澄清，SVM 代表 Support Vector Machine（支持向量机）。
  • 对 Meta-Llama-3-120B-Instruct 的期待：Hugging Face 上的 Meta-Llama-3-120B-Instruct 模型引发了对其潜力的讨论，用户呼吁进行全面的 Benchmarking（基准测试），而非仅仅依赖炒作。
  • 部署困境：用户讨论了 Serverless Llama 的局限性，同时探讨了具备充足 VRAM 的更好 GPU 选项，例如 Azure 的 NC80adis_H100_v5，以处理大上下文任务需求。
  • Hermes 2 令人印象深刻的性能表现：Hermes 2 Pro Llama 8B 展示了惊人的约 32k 扩展上下文容量且无明显衰减，在 32GB 的 Nvidia v100 Tesla 上实现了 16k 的完美 Recall（召回）。
  • Cynde 助力数据耕作：分享了关于 Cynde 的更新，标志着其核心实现的完成。社区对这个用于 Intelligence Farming（智能耕作）的框架表现出极高热情，Cynde 的 GitHub 仓库 欢迎贡献者加入。

Perplexity AI Discord

  • Pages Beta 不再开放申请：由于参与人数已满，Pages 的 Beta 测试申请阶段已经结束。关于 Pages 的后续更新将另行通知。

  • 关于 Perplexity AI 性能与限制的热烈讨论：成员们遇到了 Claude 3 模型响应速度慢的问题，并对 Claude 3 Opus 模型每天 50 条消息的限制表示沮丧。在将 Opus 与 GPT-4 Turbo 及 Sonnet 进行对比时，用户还对 Perplexity 从无限量转向受限的消息能力表示担忧。

  • 探索 AI 的创意与新颖用途：Perplexity AI 社区正积极探索该平台在图像生成、模仿小说写作风格以及多样化搜索方面的能力，例如挖掘 BASIC 编程语言的历史或深入研究 Perplexity 自身的发展史。

  • API 探索与灵活调整：用户讨论了模型迁移，特别是从 sonar-medium-online 切换到 llama-3-sonar-large-32k-online，并询问了潜在的计费不一致问题。对话还涉及了 AI 结果优化的成功与困扰，以及使用 Perplexity API 创建极简代码 Telegram 机器人的建议。

  • 多渠道搜索查询分享：社区分享了多个搜索查询及其结果，引发了关于 Perplexity 的有效使用及其提供见解深度的讨论。这些探索涵盖了从编程历史到专有技术见解的各种背景。

LM Studio Discord

  • 无头模式（Headless）进展：工程师们正在利用 LM Studio 的 CLI 工具 lms 进行无头操作，并与 GUI 版本配合使用。他们正在解决内存消耗异常的问题，并讨论在不通过 RDP 消耗 VRAM 的情况下实现平滑服务器端部署的策略。

  • 微调技巧与模型故障：成员们正在排查微调瓶颈，分享在 128GB M3 Max MacBook Pro 等硬件上进行长时间微调的成功案例，并讨论困扰 Llama 3 等模型的输出不一致问题。

  • 交互意图与 AI 记忆怪癖：用户表达了一个令人困惑的观察结果，即语言模型可能会保留已删除 Prompt 元素的上下文，这暗示了潜在的 Bug 或对模型行为的误解。他们探索了个性化写作风格的交互技术，并为 LLM 实现了对文档部分的“作用域访问（scoped access）”。

  • 角色扮演无限制？没那么快：围绕 AI 与 RPG 结合的讨论非常热烈，用户目标是将 AI 训练为 D&D 的地下城主（Dungeon Masters），并指出现有系统受限于内容审核，这可能会影响故事的黑暗程度和深度。

  • ROCm 赞誉与 Linux 热情：ROCm 的更新表现稳健，但讨论也涉及了模型转换和为 Embeddings 发送更长序列的挑战。对话转向社区对贡献 Linux ROCm 构建版本的兴趣，暗示如果项目寻求更多开源协作，将会有进一步的参与。

  • 硬件前沿的 AI：成员们投入到激烈的硬件交流中，对比了 Tesla P40 等旧款 GPU 相对于 GRID K1 的适用性，并痴迷于以 AI 为中心的家庭实验室中多 GPU 设置的细节。具体细节涵盖了从服务器硬件采购到散热、电源和驱动兼容性等问题。

  • LM Studio 最新阵容：lmstudio-community 仓库已更新了 CodeGemma 1.1 和 Nvidia 的 ChatQA 1.5 模型，前者引起了热切期待，而后者提供了专为基于上下文的问答（Q/A）应用量身定制的专业模型。

CUDA MODE Discord

BackPACK 表现强劲：BackPACK 是一个用于从反向传播中提取额外信息的 PyTorch 扩展工具，讨论强调了它对 PyTorch 开发者的潜力。详情见 Dangel 等人 2020 年发表的论文 “BackPACK: Packing more into Backprop”。

DoRA 在融合方面表现出色：一个新的 fused DoRA layer implementation 减少了单个 kernel 的数量，并针对 GEMM 和 reduction 操作进行了优化，详见 GitHub pull request。社区对即将发布的针对这些增强功能的 benchmark 表示期待。

自定义 CUDA 扩展的定制化：成员们讨论了安装自定义 PyTorch/CUDA 扩展的最佳实践，分享了多个 GitHub pull requests（如 PR#135）和一个示例 setup.py 以供参考，旨在简化安装过程。

利用 CUTLASS 稳步前行：围绕 CUTLASS 中使用的 stream-K 调度技术引起了广泛关注，并建议在未来的演讲中深入探讨其工作原理。

GPU 通信课程：宣布了即将举行的关于使用 NCCL 进行 GPU 集体通信（Collective Communications）的会议，重点关注分布式 ML 概念。

必读的 ML 系统论文：对于机器学习系统的新手，GitHub 上的 ML Systems Onboarding list 提供了一系列精选的参考论文。

克服 CUDA 编译难题：针对 nvcc 11.5 在 bfloat16 操作中报错的问题，已在 fix proposal 中提出解决方案，旨在支持旧版 GPU 和工具包。还讨论了多 GPU 训练挂起的问题，涉及 Issue #369，并有一个独立分支维持功能。

LLaMa 的精简学习：关于 LLaMa 2 70B 模型训练 期间内存效率的讨论强调了可以减少内存使用的配置。提到了一个名为 HTA 的工具，用于定位 PyTorch 中的性能瓶颈。

量化带来的后训练巅峰：分享了一个 YouTube 视频，详细介绍了 PyTorch 中量化的过程和优势。

GreenBitAI 走向全球：介绍了一个名为 green-bit-llm 的工具包，用于微调和推理 GreenBitAI 的语言模型。BitBlas 因其快速的 2-bit 操作 gemv kernel 而受到关注，同时 GreenBitAI 的工具包中还包含一种独特的梯度计算方法。

Modular (Mojo 🔥) Discord

收看 Mojo 直播，获取 MAX 24.3 更新：Modular 的新直播视频 “Modular Community Livestream - New in MAX 24.3” 邀请社区探索 MAX Engine 和 Mojo 的最新功能，并介绍了 MAX Engine Extensibility API。

社区项目飞速发展：值得关注的更新包括 NuMojo 性能的提升以及用于图像解析的 Mimage 的推出。Basalt 项目也达到了 200 stars 的里程碑，并发布了新的 文档。

Mojo 编译器不断演进：Mojo 编译器迎来了 nightly updates，其更改更符合当前实践，例如放弃了 80 列宽度限制，并向更适合寄存器传递（register passability）的类型过渡。

AI 工程师探索 Don Hoffman 的意识研究：对加州大学欧文分校（UCI）Donald Hoffman 关于意识研究工作的兴趣与 AI 产生了关联，人们在裂脑患者的感官数据限制与 AI 幻觉（hallucinations）之间找到了相似之处。

Mojo 生态系统的成长与开发者指导：讨论了 Mojo 的贡献流程，符合 GitHub 的 pull request 指南，并通过 参数教程 深入了解开发工作流，展示了对快速扩张的 Mojo 生态系统贡献者的积极支持。

HuggingFace Discord

Moondream 和 BLOOM 掀起波澜：HuggingFace 社区聚焦了多项新进展，包括 Moondream 2 批处理 和 FLUENT 的最新迭代，以及多语言支持工具。特别值得关注的是 BLOOM 多语言聊天 和 AutoTrain 对 YAML 配置的支持，这简化了机器学习初学者的训练流程。查看 社区亮点。

当音频模型开始歌唱：人们对用于生成式音乐的音频扩散模型产生了浓厚兴趣，Whisper 正在针对菲律宾语 ASR 进行微调，并引发了关于优化的讨论。然而，一位用户在将 PyTorch 模型转换为 TensorFlow Lite 时因尺寸限制遇到了挑战。

AI 的前线：网络安全成为焦点，Hugging Face Twitter 账号被盗，强调了对稳健的 AI 相关安全性的需求。成员们还交流了 GPU 利用率技巧，以应对不同配置间训练时间的差异。

量子与 AI 结合的愿景：在 computer vision 领域，重点在于改进传统方法，如使用 YOLO 进行汽车零部件的缝隙检测，以及调整 CLIP 等模型以识别旋转物体。GhostNet 的预训练权重备受追捧，CV 成员们也在思考 SURF 和 SIFT 等方法在当代的适用性。

图论专家齐聚：近期关于将 LLM 与图机器学习结合的论文提出了新颖的整合方式，其中一篇 论文 专门教学 LLM 仅在需要时通过 <RET> 标记检索信息。阅读小组 为渴望学习更多知识的人提供了额外资源。

展示合成与应用 AI：在 #i-made-this 板块，发布了 Podcastify 和 OpenGPTs-platform 等工具，以及使用 mergekit 构建的 shadow-clown-BioMistral-7B-DARE 等模型。

NLP 者的疑惑与查询：在 NLP 板块，一位用户为 Mistral-7B-instruct 的定制训练提供报酬，同时也有人对 LLM 评估其他 LLM 表示担忧。介绍了使用 GPT 3.5+ 衡量翻译质量的 GEMBA 指标，并提供了了解更多的链接。

OpenInterpreter Discord

将 OpenInterpreter 与 Groq LLM 集成：工程师们讨论了将 Groq LLM 集成到 Open Interpreter 上的挑战，强调了输出不可控和错误文件创建等问题。分享的连接命令为 interpreter --api_base "https://api.groq.com/openai/v1" --api_key "YOUR_API_KEY_HERE" --model "llama3-70b-8192" -y --max_tokens 8192。

微软黑客松寻求 Open Interpreter 爱好者：一个团队正在组建以参加使用 Open Interpreter 的微软开源 AI 黑客松（Microsoft Open Source AI Hackathon）；该活动承诺提供实操教程，报名详情请见此处。

Open Interpreter 的 iOS 重构：讨论围绕在 Open Interpreter 上为 iOS 重新实现 TMC 协议，以及解决 Azure Open AI 模型的设置问题，一位成员分享了正在开发的 iOS 应用的 GitHub 仓库链接，见此处。

本地 LLM 挑战开发者：分享了对 Phi-3-mini-128k-instruct 等本地 LLM 的个人测试，结果显示出显著的性能差异，并呼吁在未来的实现中采用更好的优化方法。

AI Vtuber 的 STT 难题：为 AI 驱动的虚拟主播实现 Speech-to-Text 带来了实际挑战，工程师们考虑使用触发词，并致力于通过独立的 LLM 实例实现 AI 驱动的 Twitch 聊天互动，旨在获得全面的回复。对于正在处理类似集成的开发者，一位成员指出了其 GitHub 上的 main.py 文件作为参考资源。

Eleuther Discord

  • 国际象棋特级大师请注意，Transformers 来了：一项新研究揭示了一个拥有 270M 参数的 Transformer 模型在没有领域特定算法的情况下，在国际象棋领域超越了 AlphaZero 的策略和价值网络，引发了关于 Scale 在策略游戏中有效性的讨论。

  • LLM 研究在多语言和 Prompting 技术方面蓬勃发展：研究亮点包括一项关于 LLM 处理多语言输入的研究，以及尽管对其实用性存在质疑，但“Maieutic Prompting”在处理不一致数据方面的潜力。该领域的贡献提供了见解和论文链接，例如 How Mixture Models Handle Multilingualism 以及对抗 LLM 漏洞的方法，包括 The Instruction Hierarchy 论文。

  • 显微镜下的模型性能：迁移学习的 Scaling Laws 表明，预训练模型通过有效的迁移数据在固定大小的数据集上有所提升，这与社区在确定 LLM In-context Learning 的准确衡量标准和性能评估方法方面的努力相呼应。

  • 解释 Transformers 并提高可部署性：分享了关于解释基于 Transformer 的 LLM 的入门指南和综述，以及关于跨模型泛化的讨论。社区对解决 Phi-2 和 Mistral-7B 等模型中的 Weight Tying 问题表现出浓厚兴趣，并澄清了关于知名开源模型中 Weight Tying 的误解。

  • 社区参与 ICLR 和求职：尽管面临旅行挑战，ICLR 线下聚会的准备工作正在展开；社区支持显而易见，成员们分享了就业资源以及参与 OSLO 和 Polyglot 团队等项目的经验。

OpenRouter (Alex Atallah) Discord

  • Llama 家族新成员：Llama 3 Lumimaid 8B 模型已发布，同时还提供 扩展版，而 Llama 3 8B Instruct Extended 则迎来了降价。由于服务器更新，Lynn 系列模型宣布了短暂的停机。

  • 高端 AI 招募 Beta 测试员：Rubik’s AI Pro 是一款先进的研究助手和搜索引擎，正在招募 Beta 测试员，提供 2 个月的尊享访问权限，包括 GPT-4 Turbo 和 Mistral Large 等模型。该项目可通过 此处 使用促销代码 RUBIX 访问。

  • 混合搭配模型：社区成员报告称 Gemini Pro 现在已无错误，并讨论了 Lumimaid 70B 的潜在托管方。Phi-3 等模型备受期待，但供应稀缺。不同供应商的模型精度各异，大多数使用 fp16，部分使用量化的 int8。

  • 模型合并：对话重点介绍了 Hugging Face 上新创建的 Meta-Llama 3 70B 自合并版本，引发了关于自合并（Self-merges）与传统层映射合并（Layer-mapped merges）效果的辩论。

LlamaIndex Discord

提升 Agent 智能：LlamaIndex 0.10.34 引入了 introspective agents（内省型智能体），能够通过反思机制实现自我改进。详情见 notebook，该内容包含敏感材料警告。

Agentic RAG 升级：一段教学视频展示了如何集成 LlamaParse + Firecrawl 来构建 agentic RAG 系统，发布详情可通过 此链接 查看。

信任评分的 RAG 响应：@CleanlabAI 的 “Trustworthy Language Model” 引入了一套针对 RAG 响应可信度的评分系统，旨在确保生成内容的准确性。更多见解请参考其公告 此处。

本地 RAG 流水线手册上架：为寻求摆脱云服务的开发者，一份使用 LlamaIndex 搭建全本地 RAG 流水线的手册现已发布，承诺比快速入门指南更深入，可在此处访问 此处。

Hugging Face 与 LlamaIndex 深度集成：LlamaIndex 宣布支持 Hugging Face TGI，从而在 Huggingface 上实现语言模型的最优部署，并增强了 function calling 和延迟优化等功能。点击 此处 了解 TGI 的新功能。

创建对话式 SQL Agents：AI 工程师正在考虑使用 HyDE 为拥有大量表格的数据库构建 NL-SQL bots，旨在提高 LLM 生成 SQL 查询的精确度；同时，introspective agent 方法论也引起了关注，更多阅读见 Introspective Agents with LlamaIndex。

OpenAccess AI Collective (axolotl) Discord

Hermes 2 Pro Llama 3 速度测试结果：Hermes 2 Pro Llama 3 在配备 8GB RAM 的 Android 设备上展示了令人印象深刻的 inference speed（推理速度），这得益于 llama.cpp 的增强。

动漫在 AI 对话中的角色：成员们幽默地讨论了 anime（动漫）的兴起与 AI question-answering（问答）及 image generation（图像生成）任务能力提升之间的关系。

Gradio 定制化成果：Gradio 的调整现在允许通过 YAML file 进行动态配置，从而能够以编程方式设置隐私级别和服务器参数。

AI 训练数据集备受关注：讨论了一个包含 143,327 个经过验证的 Python 示例的新数据集（Python Dataset），以及即使使用以数学为中心的数据集，提升 Llama3 数学性能仍面临困难，凸显了 AI 训练中数据集的挑战。

AI 训练平台的增强与需求：有人呼吁完善 Axolotl 的文档，特别是关于合并模型权重和模型推理的部分，可在 Axolotl Community Docs 访问。此外，还解决了 gradient clipping（梯度裁剪）配置的问题，Phorm 提供了关于为 gradient clipping 和 chatbot prompt 定制 TrainingArguments 的见解。

Latent Space Discord

  • Gary 玩转 Ableton：一个新的开发中 Python 项目 gary4live 将 Python continuations 与 Ableton 集成用于现场音乐表演，邀请社区贡献和同行评审。

  • Suno 扩大音乐制作规模：关于使用 Suno 进行音乐生成的讨论包括与 Musicgen 等其他设置的比较，重点是 Suno 的音频 tokenization 过程，并探索这些模型是否能自动生成乐谱。

  • Token 探讨：深入探讨音乐模型的 token 结构，参与者研究了音频合成中的 token 长度和组成，引用了学术论文中的特定架构设计但未展开细节。

  • 打破音频合成的障碍：讨论了将音频直接集成到多模态模型中的潜力，重点是音频通道的实时替换以及直接音频对实现全模态（omnimodal）功能的重要性。

  • Stable Audio 的商业节奏：出现了关于稳定音频模型输出的商业用途和许可问题，特别关注其在现场表演中的实时应用以及对行业的潜在影响。

AI Stack Devs (Yoko Li) Discord

  • 本地硬件攻克 AI 任务：用户现在可以使用 llama-farm 在旧笔记本电脑上本地运行 Ollama，以处理 LLM 任务，而无需将其暴露在公共互联网中。这还关联到了一个 GitHub 仓库，其中包含更多实现细节（GitHub 上的 llama-farm chat）。

  • 实现 AI 云端独立：讨论表明，使用 Faraday 允许用户永久保留下载的角色和模型，并且在拥有 6 GB VRAM 配置的情况下，本地运行工具可以规避云端订阅费用。本地执行无需订阅，是工具使用方面一个极具性价比的选择。

  • Ubuntu 用户重获控制权：通过降级到 Node 版本 18.17.0 并根据 GitHub issue 更新 Ubuntu，解决了 Ubuntu 18 上 convex-local-backend 的安装问题。提出了 Dockerization（Docker 化）作为简化未来配置的潜在解决方案。

  • 模拟现实备受关注：旧金山的 Mission Control 举办了一场 AI Simulated Party（AI 模拟派对），融合了真实与数字体验。此外，AI-Westworld 模拟进入了公开测试阶段，并推出了一个名为 AI Town Player 的 Web 应用，用于通过导入 sqlite 文件回放 AI Town 场景。

  • 剪贴板与节拍的融合：有人呼吁合作创建一个涉及嘻哈歌手 Kendrick 和 Drake 的模拟。这展示了将 AI 开发与文化评论相结合的兴趣。

LAION Discord

CLIP vs. T5：模型大比拼：关于集成 CLIP 和 T5 编码器 进行 AI 模型训练的讨论非常热烈；虽然同时使用两种编码器显示出前景，但一些人主张仅使用 T5，因为 CLIP 存在提示词遵循（prompt adherence）问题。

小模型是大趋势吗？：在模型尺寸领域，小模型的增强正被优先考虑，400M 的 DeepFloyd 备受关注就是证明，技术对话涉及到了扩展至 8B 模型的挑战。

发布 SD3：吊胃口还是全量发布？：社区对 Stability AI 暗示的逐步推出 SD3 模型（从小型到大型）的反应褒贬不一，既有怀疑也有渴望，大家都在思考这种发布策略是否符合社区的预期。

LLama Embeds 走入聚光灯下：关于在模型训练中使用 LLama embeds 效果的辩论浮出水面，一些成员主张使用它们而非 T5 embeds，并分享了 LaVi-Bridge 等资源来展示现代应用。

从概念到应用：数据之辩：对话深入探讨了为什么在某些研究中合成数据集比 MNIST 和 ImageNet 等现实世界数据集更受青睐，提到了 AI 方法中可解释性的价值，并分享了 StoryDiffusion 网站 以获取见解。

LangChain AI Discord

代码执行找到了 AI 伙伴：围绕使用 AI 执行生成的代码展开了热烈对话，重点介绍了 Open Interpreter 等方法以及开发 custom tools（如 CLITOOL）。这些讨论对于构建更具交互性和自动化系统的人来说至关重要。

Langchain 学习新语言：Langchain 库通过 langchain4j 扩展到 Java 生态系统，这对于渴望利用 AI 助手能力的 Java 开发者来说是关键的一步。

Langchain 获得高性能优化：LangChain 与 Dragonfly 的结合在聊天机器人上下文管理方面取得了显著增强，正如一篇详细介绍这些进展的 博客文章 所描述的那样。

去中心化搜索创新：社区正热议 LangChain 去中心化搜索功能的开发，该功能有望通过用户拥有的索引网络（index network）提升搜索功能。这项工作在最近的一条 推文 中得到了展示。

使用 Llama 和 LangGraph 的奇点空间：一位贡献者分享了一段关于使用 Llama 3 在没有 vectorstore 的情况下实现 Retrieval-Augmented Generation（检索增强生成）技术的视频，而另一位贡献者则通过对比执行领域的 LangGraph 与 LangChain Core 丰富了对话内容。

tinygrad (George Hotz) Discord

Clojure 吸引了工程师对符号编程的兴趣：工程师们正在讨论与 Python 相比，使用 Clojure 进行符号编程（symbolic programming）的便利性，建议通过悬赏任务（bounties）来加速上手 tinygrad，并辩论在 ML/AI 领域 Julia 是否优于 Clojure。

tinygrad 的 UOps 让工程师困惑：有人提议重新格式化 tinygrad 的文本 UOps 表示，使其更易于理解（可能类似于 LLVM IR），并解释了这些 UOps 确实是静态单赋值（SSA）的一种形式。

为 Qualcomm GPU 乐园优化 tinygrad：讨论强调了 tinygrad 通过利用 textures 和 pixel shaders 在 Qualcomm GPUs 上高效运行，但提醒激活 DSP 支持可能会使过程复杂化。

tinygrad 的单线程 CPU 故事：George Hotz 本人确认 tinygrad 在 CPU 端是单线程运行的，不存在线程冲突。

理解 tinygrad 的张量探戈：用户对 matmul 函数和张量转置的好奇引发了讨论，另一位用户分享了关于在 tinygrad 中计算符号均值（symbolic mean）的书面分析。

Mozilla AI Discord

  • Json\Schema 与 llamafile 发生冲突：json_schema 与 llamafile 0.8.1 之间的冲突引发了讨论，建议使用 --unsecure 作为临时方案，并暗示在未来版本中会有永久修复。

  • 寻找更轻量级的机器学习模型：社区交流了关于轻量级 AI 模型的想法，其中 phi 3 mini 被认为太重，而 Rocket-3B 因其在低资源系统上的灵活性而被推荐。

  • 为 Llamafile 整合缓存：确认 llamafile 确实可以利用来自 ollama cache 的模型，只要保持 GGUF 文件兼容性，就可以通过避免重复下载来简化操作。

  • AutoGPT 与 Llamafile 携手并进：分享了一个集成计划，重点介绍了将 llamafile 与 AutoGPT 融合的草案 Pull Request；设置说明已发布在 AutoGPT/llamafile-integration，正等待维护者反馈。

  • 为 Llamafile 选择正确的本地模型：聚焦实时问题解决，一位用户在区分了实际模型文件和元数据后，成功让 llamafile 配合本地缓存的 .gguf 文件运行。

DiscoResearch Discord

Mixtral 问题频发：mixtral transformers 因影响微调（finetune）性能的 Bug 而遇到障碍；参考资料包括 Twitter、Gist 和一个已关闭的 GitHub PR。目前尚不清楚该 Bug 是仅影响训练还是也影响推理生成，需要进一步审查。

量化版 LLaMA-3 性能受损：一则 Reddit 帖子显示，与 LLaMA-2 相比，量化（quantization）显著降低了 LLaMA-3 的性能，并提供了一项可能有启发性的 arXiv 研究。Meta 的缩放策略可能是导致 LLaMA-3 精度下降问题的原因，而 GitHub PR #6936 和 Issue #7088 讨论了潜在的修复方案。

结识社区新模型：对话表明 8x22b Mistral 正被用于当前的工程任务，但未披露具体的性能指标或使用细节。

Interconnects (Nathan Lambert) Discord

  • AI 语音：真假难辨：The Atlantic 发表了一篇文章，讨论了 ElevenLabs 如何创建先进的 AI 语音克隆技术。用户对 ElevenLabs 的能力表现出既着迷又警惕的反应，其中一人对限制完全访问此类内容的付费墙表示不屑。

  • Prometheus 2：评判评判者：最近的一篇 arXiv 论文介绍了 Prometheus 2，这是一个与人类和 GPT-4 判断保持一致的语言模型评估器，旨在解决专有语言模型中的透明度和成本问题。尽管该论文显著忽略了该模型表现不佳的 RewardBench 评分，但社区对测试 Prometheus 2 的评估能力表现出浓厚兴趣。

  • 经典 RL 之谜：rl 频道的对话探讨了经典强化学习（Reinforcement Learning）中尚未探索的领域。讨论重点强调了价值函数（value function）在 PPO 和 DPO 等方法中的重要性，并强调了其在 RL 系统规划中的关键作用。

  • John 模糊回应之谜：在 random 频道中，成员们分享了对重复成功的隐秘担忧，并开玩笑说某个“john”对一项提议给出了模棱两可的回应。这些陈述背后的相关性和背景仍不清楚。

LLM Perf Enthusiasts AI Discord

  • Anthropic 的 Prompt 生成器引发关注：工程师们讨论了 Anthropic console 中提供的一个新的 prompt generator tool（Prompt 生成工具），这对于寻求高效生成 Prompt 的人来说可能非常有用。
  • 礼貌模式测试运行：测试了该工具“礼貌地改写句子”的能力，产生的结果受到了成员们的好评。
  • 破译系统机制：目前正在努力了解该工具的 system prompt 是如何运作的，重点是揭开其中嵌入的 k-shot examples 的秘密。
  • 提取长内容：从该工具中提取完整数据一直面临挑战，有报告称 system prompt 被截断，特别是在冗长的“苏格拉底式数学导师”示例期间。
  • 揭秘：一旦成功完整提取，将承诺向社区分享完整的 system prompt，这对于那些对 Prompt Engineering 感兴趣的人来说可能是一个资源。

Skunkworks AI Discord

  • 伪造数据实验：一位成员正在寻找一个伪造数据集，旨在测试 Llama 3 和 Phi3 模型的微调，这暗示了他们的实验并不要求数据的真实性。
  • 通过快速计算加速 AI：表现出潜力的 Skunkworks AI 项目可以获得 Fast compute grants（快速计算资助），更多详情见最近的推文。
  • YouTube 上的 AI 教育内容：分享了一个与 AI 相关的教育类 YouTube 视频，可能为社区正在进行的技术讨论增添价值。

Datasette - LLM (@SimonW) Discord

  • LLM 将错误日志转化为启发：一种利用 LLM 在运行 conda activate 命令后迅速总结错误的方法已被证明有效，并建议将该方法集成到 LLM README 文档中。
  • Bash 魔法遇上 LLM 洞察：一个新编写的 llm-err bash 函数已提上日程，旨在将命令输出直接输入 LLM 以进行快速错误诊断，进一步简化工程师的错误排查流程。

Cohere Discord

  • 寻找奥斯汀的 AI 专家：向位于德克萨斯州奥斯汀的 AI 专业人士发出了友好问候。
  • Finexov 的融资前沿：Vivien 介绍了 Finexov，这是一个旨在简化 R&D（研发）融资机会识别的 AI 平台，目前已开展初步合作并获得 Founder Institute (fi.co) 的支持。
  • 为 Finexov 寻找技术领导者：正在寻找一位具有深厚 ML 背景的 CTO 联合创始人来领导 Finexov，并准备应对团队建设和融资的挑战；优先考虑常驻欧洲或中东的候选人，会说法语者优先。
  • 迪拜聚会预告：Vivien 预告今年 6 月可能在迪拜举行聚会，邀请潜在合作伙伴讨论与 Finexov 的合作机会。

AI21 Labs (Jamba) Discord

  • AI21 Labs 突破边界：AI21 Labs 表明了其进一步扩展技术的雄心。工作人员鼓励社区成员通过私信分享他们的使用案例和见解。

Alignment Lab AI Discord

  • 获取算力支持：感兴趣的各方有机会获得 快速算力资助 (fast compute grants)；一名成员分享的推文呼吁申请或提名以授予算力资源，这对 AI 研究和项目非常有益。查看推文了解详情。

PART 2: 各频道详细摘要与链接

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

  • 关于 Llama3 微调和 GGUF 转换的讨论：用户一直在尝试使用 Unsloth 微调 Llama3，并将微调后的模型转换为 GGUF，结果各异。一些人报告了转换后出现无限生成的问题，并被引导关注一个 GitHub issue，该 issue 强调了转换为 GGUF 的模型存在的问题。

  • 关于 Unsloth 全量微调的咨询：一位用户对使用 Unsloth 进行全量微调（Full Finetuning，而不仅仅是 LoRA）的可能性感到好奇，引发了关于潜在 VRAM 节省和性能的讨论。Unsloth 社区成员就如何实现这一目标提供了见解，并引用了一个 GitHub feature request。

  • 深度量化模型性能调查：一位用户质疑了针对 7B 模型的 4 Bit Q2_K 等深度量化的有效性，建议在低资源应用中可能应改用 Phi-3，强调了为模型性能选择正确量化级别的重要性。

  • 资源分享与 Unsloth 故障排除：用户分享了他们的经验，并就运行 Unsloth 模型的云供应商（如 Tensordock）、Unsloth Studio 的使用，以及处理微调数据集、量化效果和使用不同推理引擎的通用技巧提供了建议。

  • 关于使用 LLM 微调低资源语言的不确定性：一位考虑使用 LLM 微调低资源语言的用户寻求关于 LLM 与 T5 等模型效果对比的建议。社区讨论强调了 Phi-3 等模型在此类任务中的潜力，并就如何处理微调过程的不同方面提供了建议。

提及的链接：
  • Google Colab: 未找到描述
  • Google Colab: 未找到描述
  • Google Colab: 未找到描述
  • 论文页面 - A Closer Look at the Limitations of Instruction Tuning: 未找到描述
  • GGUF My Repo - 由 ggml-org 提供的 Hugging Face Space: 未找到描述
  • unsloth/Phi-3-mini-4k-instruct · Hugging Face: 未找到描述
  • LLM Model VRAM Calculator - 由 NyxKrage 提供的 Hugging Face Space: 未找到描述
  • Google Colab: 未找到描述
  • unsloth/Phi-3-mini-4k-instruct-bnb-4bit · Hugging Face: 未找到描述
  • Reddit - 深入探索一切: 未找到描述
  • gradientai/Llama-3-8B-Instruct-Gradient-1048k · Hugging Face: 未找到描述
  • Reddit - 深入探索一切: 未找到描述
  • Reddit - 深入探索一切: 未找到描述
  • unsloth (Unsloth AI): 未找到描述
  • 主页: 以 2-5 倍的速度和减少 80% 的显存微调 Llama 3, Mistral & Gemma LLM - unslothai/unsloth
  • unsloth (Unsloth AI): 未找到描述
  • GitHub - IBM/unitxt: 🦄 Unitxt: 一个用于准备训练和评估数据的 Python 库: 🦄 Unitxt: 一个用于准备训练和评估数据的 Python 库 - IBM/unitxt
  • Grizzly: Grizzly 有 9 个可用的仓库。在 GitHub 上关注他们的代码。
  • 主页: 以 2-5 倍的速度和减少 80% 的显存微调 Llama 3, Mistral & Gemma LLM - unslothai/unsloth
  • Google Colab: 未找到描述
  • Cerebras Systems 发布拥有惊人的 4 万亿个晶体管的全球最快 AI 芯片 - Cerebras: 第三代 5nm Wafer Scale Engine (WSE-3) 为业界最具扩展性的 AI 超级计算机提供动力，通过 2048 个节点可达 256 exaFLOPs
  • Padding 和 truncation: 未找到描述
  • gradientai/Llama-3-8B-Instruct-262k · Hugging Face: 未找到描述
  • 如何微调 Llama 3 以获得更好的指令遵循能力？: 🚀 在今天的视频中，我很高兴能带你了解微调 LLaMA 3 模型以实现最佳指令遵循的复杂过程！从设置...
  • Reddit - 深入探索一切: 未找到描述
  • GitHub - unslothai/unsloth: 以 2-5 倍的速度和减少 80% 的显存微调 Llama 3, Mistral & Gemma LLM: 以 2-5 倍的速度和减少 80% 的显存微调 Llama 3, Mistral & Gemma LLM - unslothai/unsloth
  • 合并 LORA Adapter 后的 Llama3 GGUF 转换似乎会随机丢失训练数据 · Issue #7062 · ggerganov/llama.cpp: 我正在使用 Unsloth 在 llama3-8b 上微调 LORA 指令模型。1：我将模型与 LORA adapter 合并为 safetensors 2：在 Python 中直接使用合并后的模型进行推理...
  • Llama3 GGUF 转换与合并的 LoRA Adapter 似乎会随机丢失训练数据 · Issue #7062 · ggerganov/llama.cpp：我正在使用 Unsloth 对 llama3-8b 的 Instruct 模型进行 LoRA 微调。1：我将模型与 LoRA adapter 合并为 safetensors 2：在 python 中直接使用合并后的模型运行推理...
  • 未找到标题：未找到描述
    • </ul> </div> --- **Unsloth AI (Daniel Han) ▷ #[random](https://discord.com/channels/1179035537009545276/1179039861576056922/1235890587337494528)** (107 条消息🔥🔥): - **LLaMA3 的露骨内容警报**：一位用户报告称，在输入淫秽查询时，**LLaMa3** 生成了不当且露骨的内容，质疑该模型的审查程度。[另一位用户](https://www.github.com/status-check/status) 发现，即使使用系统提示词（system prompts）来防止此类响应，也会得到类似的结果。 - **支持者的新角色**：在关于支持者角色的简短讨论中，用户了解到新增了一个 "**regulars**" 角色，并且成为会员或捐赠至少 $10 的用户可以进入私有的支持者频道。 - **RTX 4090 获得 Suprim 优惠**：在关于显卡交易的新讨论中，有人指出 **MSi GeForce RTX 4090 SUPRIM LIQUID X** 正在以 $1549 的价格促销，一位用户敦促其他人抓住这个机会。该显卡与其他型号相比更紧凑的尺寸引发了进一步的辩论。 - **Kendrick 与 Drake 的动态**：用户讨论了 Kendrick Lamar 和 Drake 恩怨的最新进展，指出 Kendrick 的曲目《Meet the Grahams》在 Drake 的《Family Ties》发布后不久便发布，在说唱界引起了巨大轰动。 - **YouTube 上的 Unsloth.ai**：一段对话涉及一位用户祝贺另一位向 PyTorch 团队进行演示，并引导他们观看来自 Unsloth.ai 的 [YouTube 视频](https://www.youtube.com/watch?v=MQwryfkydc0)，暗示很快会发布进一步的更新。
    提到的链接：
    --- **Unsloth AI (Daniel Han) ▷ #[help](https://discord.com/channels/1179035537009545276/1179777624986357780/1235848585611051049)** (1215 条消息🔥🔥🔥): - **Llama3 GGUF 转换问题已定位**：用户发现使用 llama.cpp 对 Llama3 模型进行 GGUF 转换会失败，导致训练数据被篡改或丢失，且丢失模式不明确，无论使用 FP16 还是 FP32 转换方法都会出现。这些异常甚至在 F32 中也会发生，证明该问题与精度损失无关。 - **换行符可能存在正则表达式不匹配**：该问题可能与 regex 库有关，其中 `\n` 序列被错误地分词（tokenized），这可能是由于不同 regex 库的行为差异导致的。建议的修复方案是修改 tokenizer.json 的 regex 模式以提高跨 regex 库的兼容性，但对于不同长度的 `\n` 的影响仍存疑。 - **问题不仅限于 GGUF**：在 ooba 等应用中，使用 AWQ 也发现了类似的推理问题，这表明分词器（tokenizer）或分词过程存在问题，而不仅仅是 GGUF 格式的问题。Unsloth 的推理函数似乎表现良好，暗示问题可能特定于 llama.cpp。 - **多个平台受到影响**：依赖于 llama.cpp 的平台（如 ollama 和 lm studio）也面临相关 Bug，不同界面均报告了分词问题，可能影响广泛的用户和应用。 - **社区合作寻求解决方案**：用户贡献（包括 regex 修改）正在被讨论和测试，以提供 GGUF 转换难题的临时修复方案，重点在于查明问题是特定于 Unsloth 微调过程还是 llama.cpp 的分词方法。
    提到的链接： * 添加并重构了 unic...</li>
  • GGUF 损坏 - llama-3 · Issue #430 · unslothai/unsloth: 来自 ggerganov/llama.cpp#7062 和 Discord 聊天的发现：复现用的 Notebook：https://colab.research.google.com/drive/1djwQGbEJtUEZo_OuqzN_JF6xSOUKhm4q?usp=sharing Unsloth + float16 + QLoRA = 正常工作...
  • 主页: 微调 Llama 3, Mistral & Gemma LLM，速度提升 2-5 倍，显存占用减少 80% - unslothai/unsloth
  • readme : 添加关于 convert.py 不支持 LLaMA 3 的说明 (#7065) · ggerganov/llama.cpp@ca36326: 未找到描述
  • 主页: 微调 Llama 3, Mistral & Gemma LLM，速度提升 2-5 倍，显存占用减少 80% - unslothai/unsloth
  • 我让 unsloth 在原生 windows 上运行了。 · Issue #210 · unslothai/unsloth: 我让 unsloth 在原生 windows 上运行了（无需 WSL）。你需要 Visual Studio 2022 C++ 编译器、Triton 和 DeepSpeed。我有一个完整的安装教程，我本想在这里写完，但我现在在手机上...
  • 无法将 llama3 8b 模型转换为 gguf · Issue #7021 · ggerganov/llama.cpp: 请包含有关您的系统信息、重现 Bug 的步骤以及您正在使用的 llama.cpp 版本。如果可能，请提供一个重现该问题的最小代码示例...
  • GitHub - ggerganov/llama.cpp 分支 gg/bpe-preprocess: C/C++ 中的 LLM 推理。通过在 GitHub 上创建账号为 ggerganov/llama.cpp 的开发做出贡献。
  • jaime-m-p 提交的 llama3 自定义正则分割 · Pull Request #6965 · ggerganov/llama.cpp: unicode_regex_split_custom_llama3() 的实现。
  • 带有合并 LoRA Adapter 的 Llama3 GGUF 转换似乎会随机丢失训练数据 · Issue #7062 · ggerganov/llama.cpp: 我正在使用 Unsloth 在 llama3-8b 上微调 LoRA 指令模型。1：我将模型与 LoRA Adapter 合并为 safetensors 2：在 Python 中直接使用合并后的模型运行推理...
  • 带有合并 LoRA Adapter 的 Llama3 GGUF 转换似乎会随机丢失训练数据 · Issue #7062 · ggerganov/llama.cpp: 我正在使用 Unsloth 在 llama3-8b 上微调 LoRA 指令模型。1：我将模型与 LoRA Adapter 合并为 safetensors 2：在 Python 中直接使用合并后的模型运行推理...
  • 带有合并 LoRA Adapter 的 Llama3 GGUF 转换似乎会随机丢失训练数据 · Issue #7062 · ggerganov/llama.cpp: 我正在使用 Unsloth 在 llama3-8b 上微调 LoRA 指令模型。1：我将模型与 LoRA Adapter 合并为 safetensors 2：在 Python 中直接使用合并后的模型运行推理...
  • 带有合并 LoRA Adapter 的 Llama3 GGUF 转换似乎会随机丢失训练数据 · Issue #7062 · ggerganov/llama.cpp: 我正在使用 Unsloth 在 llama3-8b 上微调 LoRA 指令模型。1：我将模型与 LoRA Adapter 合并为 safetensors 2：在 Python 中直接使用合并后的模型运行推理...
  • 带有合并 LoRA Adapter 的 Llama3 GGUF 转换似乎会随机丢失训练数据 · Issue #7062 · ggerganov/llama.cpp: 我正在使用 Unsloth 在 llama3-8b 上微调 LoRA 指令模型。1：我将模型与 LoRA Adapter 合并为 safetensors 2：在 Python 中直接使用合并后的模型运行推理...
  • llama.cpp/convert.py (master 分支) · ggerganov/llama.cpp: C/C++ 中的 LLM 推理。通过在 GitHub 上创建账号为 ggerganov/llama.cpp 的开发做出贡献。
  • 带有合并 LoRA Adapter 的 Llama3 GGUF 转换似乎会随机丢失训练数据 · Issue #7062 · ggerganov/llama.cpp: 我正在使用 Unsloth 在 llama3-8b 上微调 LoRA 指令模型。1：我将模型与 LoRA Adapter 合并为 safetensors 2：在 Python 中直接使用合并后的模型运行推理...
  • 带有合并 LoRA Ada... pter 似乎随机丢失训练数据 · Issue #7062 · ggerganov/llama.cpp</a>: 我正在运行 Unsloth 在 llama3-8b 上微调 LORA Instruct 模型。1：我将模型与 LORA 适配器合并为 safetensors 2：在 python 中直接使用合并后的模型运行推理...
    • </ul>
    --- **Unsloth AI (Daniel Han) ▷ #[showcase](https://discord.com/channels/1179035537009545276/1179779344894263297/1235848362516021248)** (80 条消息🔥🔥): - **关于模型尺寸讨论频道的建议**：一位用户建议在 Unsloth Discord 上创建一个单独的频道，用于讨论部署大型语言模型 (LLM) 的**成功经验与策略**。对话强调了分享经验对于增强集体学习的价值。 - **推动基于 Llama-3-8B 的项目**：RomboDawg 宣布发布了一个新的编码模型，该模型增强了 **Llama-3-8B-Instruct**，其性能可与 **Llama-3-70B-Instruct** 媲美。该模型可以在 [这里](https://huggingface.co/rombodawg/Codellama-3-8B-Finetuned-Instruct) 访问，并表示对预计在大约三天内发布的第 2 版感到兴奋。 - **知识图谱 LLM 变体发布**：M.chimiste 开发了一个 **Llama-3 变体** 以辅助知识图谱构建，命名为 **LLaMA-3-8B-RDF-Experiment**，强调了其在生成知识图谱三元组方面的实用性以及在基因组数据训练方面的潜力。该模型可以在 [Hugging Face 模型库](https://huggingface.co/M-Chimiste/Llama-3-8B-RDF-Experiment) 中找到。 - **加密协作的前景**：在一次深入讨论中，一位用户正在寻求关于构建一个可能将加密元素集成到区块链技术中的系统的建议和协作讨论，并表示有兴趣向社区学习。 - **AI 增强的 Web 开发工具主题**：Oncord 被展示为一个提供内置营销和商业工具的现代 Web 开发平台，其开发者正在集成 **Unsloth AI** 进行 **LLM 微调**，以提供代码补全并可能支持 AI 驱动的重新设计功能。关于 Oncord 的更多信息可以在 [这里](https://www.oncord.com/) 找到。
    提到的链接：
    --- **Unsloth AI (Daniel Han) ▷ #[suggestions](https://discord.com/channels/1179035537009545276/1180144489214509097/1237119442899435582)** (3 条消息): - **期望微调 LVLM**：一位成员表达了对**通用 LVLM 微调方式**的愿望，表明了对语言视觉模型定制和优化的持续兴趣。 - **对 MoonDream 微调的兴趣**：另一位成员推荐**支持 Moondream**，这是一个微型视觉语言模型，目前仅支持微调 **phi 1.5 文本模型**。他们提供了一个 GitHub notebook 作为资源：[GitHub 上的 moondream/notebooks/Finetuning.ipynb](https://github.com/vikhyat/moondream/blob/main/notebooks/Finetuning.ipynb)。 **提到的链接**：moondream/notebooks/Finetuning.ipynb at main · vikhyat/moondream：微型视觉语言模型。通过在 GitHub 上创建一个账号来为 vikhyat/moondream 的开发做出贡献。 --- **OpenAI ▷ #[ai-discussions](https://discord.com/channels/974519864045756446/998381918976479273/1235963163971682304)** (854 条消息🔥🔥🔥): - **Perplexity 的新挑战者**：用户正在讨论 Perplexity AI 的优势，特别是其新的 Pages 功能，该功能允许创建综合报告。 - **AI 与自学习**：一些人讨论了像 OpenAI 的 GPT 这样的 AI 引擎教用户编程基础并帮助编写代码的可能性，支持具有自我改进能力的自给自足 AI 的想法。 - **AGI 定义的演变**：社区正在就 AI 的现状及其与真正 AGI (Artificial General Intelligence) 的接近程度展开辩论，对于像 ChatGPT 这样的现代 AI 是否符合早期 AGI 的标准持有不同意见。 - **对 AI 生成音乐的渴望**：用户对 AI 生成的音乐表现出兴趣，提到了 Udio 等服务，并讨论了 OpenAI 是否应该发布自己的 AI 音乐服务。 - **AI 作为扩展工具**：对话探讨了 AI 目前如何增强人类生产力，以及 AI 未来可能接管平凡和复杂任务的潜力，同时也反映了这可能如何颠覆我们的社会经济模式。
    Links mentioned:
    --- **OpenAI ▷ #[gpt-4-discussions](https://discord.com/channels/974519864045756446/1001151820170801244/1235851459891957821)** (40 messages🔥): - **慢而稳并不总是赢家**：成员们报告 **GPT-4 Turbo** 的延迟显著增加，一些人的响应时间比平时慢了 **5-10 倍**。 - **对话限制**：关于 GPT-4 的消息上限存在困惑，用户报告了不同的超时阈值。一些人表示上限在 **25 到 50 条消息**之间，而另一些人则怀疑在**高使用率**期间会有动态调整。 - **OpenAI 平台的 UX 忧郁**：针对 OpenAI 新项目功能的体验出现了投诉，涉及**项目管理**、**删除**和**导航**方面的问题；还注意到每个项目**缺乏活动跟踪**。 - **会有 GPT-5 吗？**：用户对 GPT-5 的发布持怀疑态度，讨论了**收益递减**以及它可能是“**1.5 倍于 GPT-4 的性能，但成本是其 2 倍**”的可能性。 - **知识优先级探索**：用户辩论如何让 ChatGPT 在回答前**先搜索其知识库**的策略，涉及 **RAG (Retrieval-Augmented Generation)** 和**知识向量化**等概念，以协助提供上下文相关的答案。 --- **OpenAI ▷ #[prompt-engineering](https://discord.com/channels/974519864045756446/1046317269069864970/1236180170323267597)** (30 messages🔥): - **为提问微调 GPT**：一位成员正在寻求关于如何微调模型以进行提问而非回答的建议，并提到了之前在类似项目中的挣扎。他们指出难以找到合适的用户查询和助手查询对，并考虑使用单元组对话作为微调样本。 - **韧性十足的入职机器人**：成员 **leveloper** 提到一个成功运行的机器人，旨在入职过程中提问，尽管在一个大型服务器上，它仍未被用户的尝试所迷惑。 - **避免负向提示**：**majestic_axolotl_19289** 建议使用负向提示（Negative Prompts）可能会适得其反，因为它们往往会以意想不到的方式影响结果。其他成员讨论了负向提示是否有效，引用了“Contrastive Chain of Thoughts”论文和个人经验。 - **Prompt Engineering 书籍推荐**：成员 **sephyfox_** 推荐了 Teddy Dicus Murphy 的《Wordplay: Your Guide to Using Artificial Intelligence for Writing Software》，认为它对 Prompt Engineering 很有帮助。 - **改进 GPT-4-TURBO 提取产品信息的提示词请求**：成员 **stevenli_36050** 寻求帮助，以优化从 PDF 超市宣传册中提取产品信息、名称和价格并进行相应分类的提示词。 - **讨论 Token Suppression 中的 Logit Bias**：用户 **bambooshoots** 分享了一个链接 (https://help.openai.com/en/articles/5247780-using-logit-bias-to-alter-token-probability-with-the-openai-api)，关于在 OpenAI API 中使用 Logit Bias 操纵概率以抑制特定 Token。 --- **OpenAI ▷ #[api-discussions](https://discord.com/channels/974519864045756446/1046317269069864970/1236180170323267597)** (30 messages🔥): - **寻找提问机器人**：一位成员讨论了微调 GPT 以在对话中生成问题而非提供答案的挑战，强调了在这种场景下定义用户查询和机器人响应结构的难度。 - **Contrastive Chain of Thought (CCoT) 讨论**：关于在 Prompting 策略中使用负面提示（negative prompts）的辩论。对话提到了关于 "Contrastive Chain of Thoughts" 的论文，并质疑了在长对话中使用 CCoT 的有效性，随后邀请读者在 [AIEmpower 博客](https://aiempower.com/)上进一步阅读。 - **Prompt Engineering 资源与技术分享**：用户分享了关于 Prompt Engineering 的资源，包括 Teddy Dicus Murry 的书籍《Wordplay: Your Guide to Using Artificial Intelligence for Writing Software》的推荐，以及 Ronnie Sheer 的 LinkedIn 学习课程。 - **提取超市产品数据**：一位用户寻求关于改进 GPT-4-TURBO Prompt 的建议，以便从 PDF 超市宣传册中识别产品名称和价格，并希望以 CSV 格式输出结果。 - **用于 Token 概率操纵的 Logit Bias**：一位成员引用了 Logit Bias 作为在 Prompt 中操纵 Token 概率的方法，并附上了 OpenAI 官方文档链接：[Using logit bias to alter token probability with the OpenAI API](https://help.openai.com/en/articles/5247780-using-logit-bias-to-alter-token-probability-with-the-openai-api)。 --- **Stability.ai (Stable Diffusion) ▷ #[general-chat](https://discord.com/channels/1002292111942635562/1002292112739549196/1235849532609265724)** (919 messages🔥🔥🔥): - **GPU 兼容性查询**：用户正在寻求有关无法访问 GPU 资源的 Stable Diffusion 安装帮助，提到了诸如 "RuntimeError: Torch is not able to use GPU" 之类的错误。 - **Stability.ai 与 SD3 推测**：对话围绕 Stable Diffusion 3 的预期发布展开，许多人对其是否会发布表示怀疑，而其他人则讨论了如果不发布会产生的影响。 - **微调教程寻求者**：成员们对缺乏 LoRA/DreamBooth/微调模型的详细教程表示沮丧，称现有资源已过时或不够全面。 - **生成独特面孔的求助请求**：有人询问如何使用 AI 训练一个独特的、看起来真实的人物，方法包括在多张面孔上训练 LoRA，或者生成随机面孔然后在该结果上训练 LoRA。 - **关于 Stable Diffusion “Open Source” 性质的讨论**：一些用户讨论了真正“Open Source” AI 艺术生成的障碍，分享了对未来高质量模型 Checkpoints 和训练细节可能进入付费墙的担忧。
    Links mentioned:
    --- **Nous Research AI ▷ #[ctx-length-research](https://discord.com/channels/1053877538025386074/1108104624482812015/1237067945465876572)** (1 条消息): 我对应造成的困惑表示抱歉，但作为 AI，我无法直接访问 Discord 服务器、频道或消息。因此，我无法总结名为 ctx-length-research 的 Nous Research AI Discord 频道的内容。如果您能提供想要总结的特定 Discord 消息文本，我很乐意为您提供帮助。 --- **Nous Research AI ▷ #[off-topic](https://discord.com/channels/1053877538025386074/1109649177689980928/1235957375173656637)** (20 条消息🔥): - **相机色彩的演变**：一位成员幽默地指出，对比 2002 年和 2024 年**圣彼得堡起义广场利戈夫斯基大街 (Saint Petersburg, Ligovsky Avenue at Vosstaniya Square)** 的照片，可以看出*相机的色彩还原度变得更高了*。 - **烹饪风味融合**：简单提到了配有蛋黄酱和黑麦面包的格瓦斯 **Okroshka**（俄式冷汤），可能是在讨论或引用俄罗斯传统美食。 - **关于 SVM 的咨询**：一位成员询问：“什么是 SVM？”另一位成员迅速澄清说 SVM 代表 **Support Vector Machine**。 - **改进 FreeGPT.today 的 UX**：一位成员请求对其网站 [FreeGPT.today](https://freegpt.today/) 的用户体验提供反馈，邀请其他人注册、聊天并测试生成图表的 PDF 上传功能。提出了几项改进建议，包括增加 Google 身份验证、将默认登录落地页更改为“立即聊天”、改进 UI 元素以及为文件上传实现进度条。 - **警惕垃圾链接**：提到聊天中分享的一个 Discord 邀请链接实际上是垃圾信息，导致分享者被封禁。
    提及的链接:
    --- **Nous Research AI ▷ #[interesting-links](https://discord.com/channels/1053877538025386074/1132352574750728192/1235972681413689445)** (47 条消息🔥): - **使用 LLM 探索 Taskmaster**：分享了一个使用结构化数据管理、状态机和 OpenAI API 实现的 **Taskmaster** 节目代码实现。代码可在 [GitHub](https://github.com/LEXNY/Taskmaster-LLM) 上获得。 - **评估 LLM 响应**：介绍了另一个 GitHub 仓库，其特色是 **Prometheus**，一个用于评估 LLM 响应的工具，可在 [prometheus-eval](https://github.com/prometheus-eval/prometheus-eval) 获取。 - **LLM 的 VRAM 消耗计算器**：提到了一个 Hugging Face Space，其中包含一个 LLM Model VRAM Calculator，以帮助用户确定他们需要多少 VRAM，可在[此处](https://huggingface.co/spaces/NyxKrage/LLM-Model-VRAM-Calculator)查看。 - **修复 Mistral 模型问题**：讨论集中在修复 **Mistral 模型**的问题上，并重点介绍了解决这些问题的潜在 Pull Requests (PRs)。关于修改的持续对话，特别是围绕 rotary embeddings 的部分，可以在 [GitHub](https://github.com/huggingface/transformers/pull/30658) 上找到最新的相关 PR。 - **开放预训练数据集的改进与问题**：提到了一篇最近的论文，该论文检查了用于语言模型的训练语料库的质量。研究讨论了这些数据集中重复、合成和低质量内容的普遍性，详情可见其 [arXiv 论文](https://arxiv.org/abs/2310.20707)。
    提及的链接:
    --- **Nous Research AI ▷ #[general](https://discord.com/channels/1053877538025386074/1149866623109439599/1235849078479519855)** (717 条消息🔥🔥🔥): - **Hermes 在经典 Llama 缩放下的卓越表现**：**Hermes 2 Pro Llama 8B** 在 32GB Nvidia v100 Tesla 上使用 **vLLM** 通过 RoPE 缩放将上下文容量扩展至约 32k，且没有明显的性能下降。根据用户经验，在 16k 时可提供完美的召回率。 - **设置增强上下文**：建议修改 Hugging Face 上 Hermes 模型的 `config.json`，并在初始化服务器之前调整 RoPE 缩放因子以进行上下文扩展。 - **Serverless Llama 的局限性**：用户报告了不同模型推理提供商之间的各种功能和限制，需要协调语法和 JSON 模式等功能。根据 **vLLM** GitHub issues 页面的讨论，这些功能目前仅在 **llama.cpp** 中受支持，**vLLM** 尚不支持。 - **对 Llama-3-120B-Instruct 的高度期待**：一个名为 **Meta-Llama-3-120B-Instruct** 的 **Hugging Face** 模型（一个 self-merged 模型）因其据称提升的性能而引起了关注和兴趣；然而，一些用户提醒在没有经过彻底的 benchmarking 之前，应对此类炒作保持谨慎。 - **平衡计算资源与模型性能**：用户讨论了使用更强大的 GPU（如 **Azure 的 NC80adis_H100_v5**）的权衡，以及在需要大 context sizes 的任务中，如何在充足的 VRAM、latency 和 tokens per second 之间取得平衡以供实际使用。
    提到的链接：
    --- **Nous Research AI ▷ #[ask-about-llms](https://discord.com/channels/1053877538025386074/1154120232051408927/1235868437432107029)** (60 条消息🔥🔥): - **LLM 引起热潮**：一位成员表达了在本地 AI 上进行实验的喜悦，分享了他们在该平台上的第一次愉快体验。 - **Hermes 2 Pro Llama 3 对比 Mistral**：讨论围绕 **Hermes 2 Pro Llama 3** 在性能上不如 **Mistral** 展开，深入探讨了 **Mixtral** 较大的模型规模如何使其排名更高，特别是在 **MMLU benchmark** 中。 - **了解 LLaVA 的多模态能力**：关于向 GPT/LLM 教授图像识别，成员们被引导去探索 **LLaVA**，这是一个具有增强视觉和语言理解能力的大型多模态模型，在 11 个基准测试中表现出色。 - **文本生成中的 Tool XML 标签问题**：交流了在迁移到 **LlamaCPP** 时无法生成 `` XML 标签的问题，随后通过将 **LlamaCPP** 更新到最新版本解决了该问题。 - **LoRA Llama 3 8B 训练的速度困扰**：一位成员询问了 **Llama 3 8B** 的 LoRA 训练耗时似乎过长的问题，并将其与其他人在不同设置下报告的更快速体验进行了对比。
    提到的链接：
    --- **Nous Research AI ▷ #[rag-dataset](https://discord.com/channels/1053877538025386074/1218682416827207801/1235976657823862865)** (2 条消息): - **寻找免费数据集**：一位成员询问了优质免费通用数据集的来源。 - **Cynde 核心实现更新**：分享了关于 **Cynde**（一个用于智能耕作的框架）的更新。核心实现已经就绪，贡献者欢迎帮助并努力保持代码整洁，并表示目前有意尚未加入 RAG。更新后的 Readme 和笔记可在 [Neural-Dragon-AI/Cynde](https://github.com/Neural-Dragon-AI/Cynde) 查看。 **提到的链接**：Cynde/README.md at main · Neural-Dragon-AI/Cynde：一个用于智能耕作（Intelligence Farming）的框架。通过在 GitHub 上创建账户为 Neural-Dragon-AI/Cynde 的开发做出贡献。 --- **Nous Research AI ▷ #[world-sim](https://discord.com/channels/1053877538025386074/1221910674347786261/1235895009111179264)** (74 条消息🔥🔥): - **Anticipation for World-Sim's Return**: 成员们对可能测试新版本 **world-sim** 的角色分配表示兴奋并进行询问，其中一位成员特别激动，因为这恰好是他们的生日。 - **Philosophical Grounding in AI**: 针对 **Joscha** 的哲学观点以及哲学家因 A(G)I 发展而提出糟糕观点所引发的尴尬进行了反复讨论；未详细说明具体的尴尬观点。 - **Cosmic Scale World-building**: 成员 **@amiramogus_90887** 讨论了其项目的叙事层级，涉及人类后裔、**transcendental Minds** 以及由 **Brainers** 运行的跨星系模拟，展示了利用 **websim.ai** 构建的宏大世界观概念。 - **Ethical Considerations in Simulations**: 一位成员讨论了创建模拟的伦理影响，建议对这些模拟中可能存在的有意识实体保持同理心，而另一位成员则提议在与 AI 交互时进行相互对齐和共同的元现实（meta-reality）探索。 - **Sharing World Sim Projects & Volunteer Sign-Up**: 几位成员分享了他们的 **world-sim** 相关项目链接，其他人询问如何报名成为志愿者，其中一人分享了他们在 Twitter 上发现的另一个 **world-sim** 项目链接。
    提到的链接:
    --- **Perplexity AI ▷ #[announcements](https://discord.com/channels/1047197230748151888/1047204950763122820/1235982270985142463)** (1 条消息): - **Beta Testers Locked In**: **Pages** 的 Beta 测试人员申请现已关闭，已有足够的参与者。关于 **Pages** 开发的进一步更新将在后续分享。 --- **Perplexity AI ▷ #[general](https://discord.com/channels/1047197230748151888/1047649527299055688/1235849900500058132)** (814 条消息🔥🔥🔥): - **Perplexity Performance Queries**: 用户报告了 Perplexity AI 响应缓慢的问题，特别是在使用 Claude 3 时，注意到生成答案时存在异常延迟。故障排除包括检查网络连接以及在不同设备和浏览器上进行测试。 - **Opus Use Limits Discussion**: 对话集中在 Claude 3 Opus 模型每天 50 条消息的使用限制上。几位用户表达了沮丧并讨论了替代方案，将 Opus 在创意和编程方面的能力与 GPT-4 Turbo 和 Sonnet 进行了比较。 - **Image Generation Inquiry**: 一位用户寻求关于 Perplexity Pro 上最有效的图像生成模型的建议，引发了关于使用场景和生成图像法律所有权的讨论。 - **Scrutiny of User Limitation Communications**: 社区深入探讨了 Perplexity 关于引入消息限制的沟通，用户审查了从无限消息更改为有限消息的伦理影响，以及这是否可能违反了所宣传的服务。 - **Exploring Writing Styles with AI**: 成员们讨论了利用 Perplexity AI 学习和模仿小说写作风格的潜力，并建议利用 "collections" 功能在不同提示词之间保持一致的写作风格。
    提到的链接:
    --- **Perplexity AI ▷ #[sharing](https://discord.com/channels/1047197230748151888/1054944216876331118/1235849306272043008)** (43 条消息🔥): - **探索 Perplexity 的悠久历史**：一位成员分享了一个深入了解 Perplexity 历史的[链接](https://www.perplexity.ai/search/The-history-of-hfvkvCOtRiGSiKlK8YKd1Q)。 - **检索到 BASIC 语言信息**：几位成员似乎通过分享的搜索（如这个[示例](https://www.perplexity.ai/search/BASIC-programming-language-WB8fDre0Ta.oP96gtQ5k1g)）挖掘了 **BASIC 编程语言** 的起源和细节。 - **AI 的隐藏发现被揭示**：[AI 发现](https://www.perplexity.ai/search/AI-discovers-27000-_7Jf6R7jQkCu41nN3WgqtQ)了 27,000 个未知项目，引发了社区的好奇。 - **福布斯报道 Perplexity**：一位成员分享了福布斯视频中对 Perplexity 功能的介绍，展示了其提供更深层互联网见解的能力。视频可以在[这里](https://www.youtube.com/watch?v=Sct_YUU40m4)找到。 - **创意搜索查询促使 AI 探索**：像[这样](https://www.perplexity.ai/search/How-do-I-_4dQUZbbSTCL_8b66wZnYQ)的链接显示成员们正在使用 Perplexity 探索各种创意咨询。 **提到的链接**：Perplexity 想要帮助你在互联网上找到更好的答案 | 福布斯：Google 搜索或维基百科可能是寻找互联网信息的首选方法。Perplexity 旨在帮助你深入探索并找到简洁的答案... --- **Perplexity AI ▷ #[pplx-api](https://discord.com/channels/1047197230748151888/1161802929053909012/1235939642704920586)** (59 条消息🔥🔥): - **模型兼容性咨询**：一位成员询问是否需要从 **sonar-medium-online** 切换到 **llama-3-sonar-large-32k-online**。共识是旧模型目前仍可运行，但未来可能需要更新。 - **优化 AI 结果**：一位成员讨论了 AI 模型未返回预期竞品分析结果的问题。在提供不同的 prompt 结构和设置时，模型给出的输出效果更好，但一致性仍然是一个问题。 - **Opus 模型支持澄清**：成员们讨论了 Perplexity 产品中缺乏对 **Opus** 等专有模型的 API 支持。会议澄清，不应指望转售专有模型的访问权限。 - **计费逻辑变更**：一位用户询问了 API credits 计费逻辑可能存在的变化，因为其账户余额似乎不一致。讨论中未提供解决方案。 - **自托管 Telegram Bot**：一位成员征求关于集成 Perplexity API 且代码量最少的 Telegram bot 建议，回复建议创建一个这样的机器人应该不会太难。
    提到的链接：
    --- **LM Studio ▷ #[💬-general](https://discord.com/channels/1110598183144399058/1110598183144399061/1235890438762791002)** (396 条消息🔥🔥): - **以服务器模式启动 LM Studio**：用户正在探索以无头服务器模式（headless server mode）启动 LM Studio 的方法，询问是否存在命令行选项可以在启动应用时预选模型并激活服务器模式。目前关于使用 `lms`（LM Studio 的 CLI 工具）配合 GUI 版本实现无头操作的讨论正在进行中。 - **排查 LM Studio 中的 VRAM 和 RAM 使用问题**：一位用户提出了关于 LM Studio 的 VRAM 和 RAM 使用情况的疑虑，指出在启用 Flash Attention 并将模型卸载（offloading）到 GPU 时，内存消耗行为异常。该用户被要求分享截图并进一步详细说明预期行为与实际行为，以便协助解决问题。 - **远程访问测试系统上的 VRAM**：一位用户就如何在不通过 RDP 禁用 VRAM 的情况下，远程访问专为测试 LLM 构建的电脑寻求建议。SSH 和通过 CLI 使用 LMS 被建议作为维持 VRAM 访问的有效替代方案。 - **通过 Prompt Engineering 获得更好的 LLM 体验**：关于 Prompt Engineering 益处的讨论强调了其在从语言模型中提取高质量输出方面的重要性。Prompt Engineering 可以显著影响生成内容的质量，目前已被 AI 圈内公认为一项宝贵的技能。 - **在 LM Studio 中探索 Stable Diffusion**：有关于 LM Studio 是否支持 Stable Diffusion 的咨询。官方澄清虽然 Stable Diffusion 模型会出现在平台中，但 LM Studio 并不支持它们，列出的 GGUF 文件是用于 Stable Diffusion 的 C++ 实现。
    提到的链接：
    --- **LM Studio ▷ #[🤖-models-discussion-chat](https://discord.com/channels/1110598183144399058/1111649100518133842/1235862971394293770)** (234 条消息🔥🔥): - **微调 (Fine-Tuning) 的困境与解决方案**：成员们讨论了微调 Llama 3 和 phi 3 等模型，强调了相关问题并分享了资源，例如 [MacBook 指南](https://huggingface.co/blog/abhishek/phi3-finetune-macbook) 和 [使用转换工具的技巧](https://github.com/ggerganov/llama.cpp/pull/6745#issuecomment-2094964796)。一些人建议寻找 GPU 服务以获得更好的性能，而一位成员提到在 128GB M3 Max MacBook Pro 上成功对 phi-3 进行了 8 小时的微调。 - **ChatQA 模型讨论**：用户分享了使用 ChatQA 1.5 模型的经验，包括在模型连贯性和模板格式化方面遇到的挑战。共识表明，像 CMDR+ 这样更大的模型在复杂性和召回率方面表现更优，特别是在处理《圣经》等主题时。 - **Vision 和 RAG 模型的探索**：人们对用于网页自动化的 Vision 模型截图功能表现出兴趣，提到了 Pix2Struct 和 CLaude。对于阅读和生成文本文件（如 PDF），建议使用 Cohere 的 Command-R，而对于 RAG 应用，推荐使用 ChatQA 而非普通的 Llama 3 Instruct。 - **对 Llama 3 模型输出的担忧**：用户报告了 Llama 3 产生不稳定或无意义输出的问题，例如说俄语、全大写字母喊叫等。有人指出，即使在调整了模板并删除了不需要的 token 前缀后，模型的响应质量仍然难以预测。 - **LLMs 的转换挑战**：围绕将 Llama 模型转换为不同格式的挑战展开了技术讨论。解决方案包括调整命令参数的顺序以及确保正确的文件路径，并分享了关于转换脚本所需 flags 变化的见解。
    提到的链接：
    --- **LM Studio ▷ #[🧠-feedback](https://discord.com/channels/1110598183144399058/1113937247520170084/1236222899044614187)** (8 条消息🔥): - **命令行困惑已解决**：一位成员在使用 Python OpenAI API 打印消息时遇到了包含系统提示词的问题，这似乎与尝试使用 **LMS CLI 工具**有关。另一位成员建议从 [lmstudio.ai](https://lmstudio.ai) 重新下载 v0.2.22 版本，因为该问题已在此版本中修复。 - **所有系统运行正常**：在重新下载推荐版本后，该成员确认 GUI 运行正常，并计划测试 CLI 以查看是否存在潜在的重复问题。 - **版本讨论中的初始化错误**：一位成员询问关于初始化 **phi-3** 时遇到的错误，另一位成员指示其升级到更新的版本，特别是 **0.2.22**，可以从 [lmstudio.ai](https://lmstudio.ai) 下载。 **提及链接**: 👾 LM Studio - 发现并运行本地 LLMs：查找、下载并实验本地 LLMs --- **LM Studio ▷ #[📝-提示词讨论聊天](https://discord.com/channels/1110598183144399058/1120489168687087708/1236266063952347156)** (8 条消息🔥): - **寻求个性化写作助手**：一位成员讨论了如何优化写作模型以模仿个人写作风格，询问 Prompt Engineering 或交互式技术是否能提升效果。另一位参与者建议使用 **autotrain** 等工具对 "llama 2/3" 或 "Mistral" 等现有模型进行 **finetuning**，以便更好地采用个人风格。 - **AI 的限定范围文档访问**：一位成员询问了在语言模型上下文中为特定文档段落提供“临时限定范围访问”的方法。建议将**文档部分的针对性包含**在 Prompt 中作为该需求的实际变通方案。 - **澄清 AI 记忆限制**：随后，他们询问了在 LM Studio 中编辑或删除 Prompt 的部分内容后上下文的持久性，怀疑被删除的内容仍被意外保留。结论是，如果语言模型似乎记住了已删除的上下文，那可能是由于 **bug 或错误**，因为模型不应保留已移除的信息。 --- **LM Studio ▷ #[⚙-配置讨论](https://discord.com/channels/1110598183144399058/1136793122941190258/1236015180312477806)** (56 条消息🔥🔥): - **WSL 问题与代理解决方案**：成员们讨论了从 WSL 连接到 LM Studio 的问题，建议使用在 `ipconfig` 中找到的 Windows WSL vEthernet 适配器 IP 可能是一个解决方案。一些人指出可能需要 [reverse proxy](https://docs.microsoft.com/en-us/windows-server/administration/reverse-proxy)，一位成员提供了一个 PowerShell **netsh** 技巧：`netsh interface portproxy add v4tov4 listenport=$PORT listenaddress=0.0.0.0 connectport=$PORT connectaddress=127.0.0.1`。 - **在 D&D 战役中发挥创意**： - 一位成员希望使用 LM Studio 驱动带有 AI 队友的单人 D&D 战役，询问如何轻松地将个人小说和游戏书籍库注入模型以进行上下文游戏。 - 虽然有人提出了考虑使用 *command-r-plus* 等模型的有益建议，但后续消息显示需要一个能够记住角色卡并有效调整游戏叙事的 AI 地城主（Dungeon Master），这强调了当前的局限性以及未来进步的前景。 - **寻求 AI 地城主**：出于对 AI 处理《龙与地下城》（Dungeons & Dragons）游戏会话的渴望，成员们分享了愿景以及使用 *AnythingLLM* 和 *SillyTavern* 等平台的持续尝试，展示了在持续进化的 AI 驱动冒险中涵盖故事、规则和氛围功能的目标。 - **对 AI 角色扮演边界的担忧**：一位成员讨论了在尝试使用 *ChatGPT* 体验更黑暗、无限制的桌面角色扮演游戏叙事时遇到的困难，遇到了 AI 的政策违规限制，这表明了目前 AI 系统内的内容审查局限性。 - **释放 AI 在游戏中的潜力**：对话转向了 AI 在游戏领域的未来潜力，讨论了 AI 生成图像、动态背景音乐和角色语音区分等功能，这些功能将把沉浸式游戏体验提升到新高度。 **提及链接**: Udio | AI 音乐生成器 - 官方网站：发现、创作并与世界分享音乐。使用最新技术在几秒钟内创作 AI 音乐。 --- **LM Studio ▷ #[🎛-硬件讨论](https://discord.com/channels/1110598183144399058/1153759714082033735/1236326311207895103)** (123 条消息🔥🔥):
    • 用于 AI 部署的 GPU 选择：成员们讨论了使用旧显卡执行 AI 任务的可行性。有人提到像 GRID K1 这样的显卡可能太旧且不受当前支持，建议将 Tesla P40 作为最老旧但可行的选择。用户建议虽然 P40 以其价格提供了大量 VRAM，但散热和供电可能比较棘手，并且在运行 Stable Diffusion 等任务时可能无法提供最佳性能。
    • 构建以 AI 为中心的硬件配置：对话围绕构建高效的 AI 家庭实验室展开，分享了一个 PNY GeForce RTX 4070 VERTO Dual Fan 12GB GDDR6X 显卡的 eBay 链接，作为目前 3060 GPU 的潜在升级方案以满足个人游戏需求。建议在游戏和 LLMs 方面，12GB 是 VRAM 的最低要求，更倾向于 16GB 或 24GB 的型号。
      • 服务器硬件采购：用户分享了购买二手服务器的经验，提到了 ASUS ESC 4000 G3 服务器等特定型号，该服务器可容纳多个 GPU（如 P40），且价格合理，包含大量 RAM。用户还表达了对硬件兼容性以及可能需要升级以支持 AVX2 的担忧。
      • 多 GPU 与推理速度：讨论涉及了 P40 的推理速度，并将其与 Mac 的性能进行了对比，承认虽然多个 GPU 有助于将大型模型完全托管在 VRAM 中，但在特定任务中，其速度可能不会显著超过高性能的单 GPU。
      • 多 GPU 配置的主板注意事项：成员们交流了最适合搭载 Tesla P40 等多个 GPU 的主板类型，并讨论了由于驱动不兼容，将数据中心 GPU 与消费级 GPU 混合运行可能出现的问题。共识似乎是，虽然运行多个 GPU 具有成本效益，但也可能面临带宽瓶颈、电源限制和散热挑战等复杂问题。
      提到的链接：
      --- **LM Studio ▷ #[autogen](https://discord.com/channels/1110598183144399058/1167546228813336686/1236376055393292469)** (1 条消息): - **LM Studio API 语音限制**：一位成员报告称其 LM Studio API 在停止前最多只能说两个单词。他们正在寻求专家的技术见解，以了解为何会出现此问题。 --- **LM Studio ▷ #[langchain](https://discord.com/channels/1110598183144399058/1167546793656062063/)** (1 条消息): drjflamez: Secrets don't make friends (秘密交不到朋友) --- **LM Studio ▷ #[amd-rocm-tech-preview](https://discord.com/channels/1110598183144399058/1195858490338594866/1235873142648606741)** (28 条消息🔥): - **更新警报：ROCm 下载已就绪**：提到了 ROCm 技术预览版的更新；修复程序可在 [lmstudio.ai/rocm](https://lmstudio.ai/rocm) 获取，解决了之前报告的 Embedding 模型问题。 - **最大 Token 截断说明**：一位成员询问当发送大于报告的 512 Token 最大上下文的序列进行 Embedding 时会发生什么，并指出他们成功嵌入了 1000+ Token 而没有出现问题。 - **新硬件上的卓越性能**：一位用户报告在 RX 7900 xt 上成功部署了 **NousResearch/Hermes-2-Pro-Llama-3-8B-GGUF**，使用 16 FP 达到每秒 34 个 Tensor，且完美适配 VRAM。 - **赞扬 ROCm 的流畅表现**：一位社区成员对 ROCm 的稳定性和有效性表示满意，并好奇为什么从 0.2.18 版本开始表现优异，却仍被标记为预览版/测试版。 - **社区驱动的 Linux 构建兴趣**：关于潜在 Linux ROCm 构建的讨论浮出水面，用户分享了个人变通方案，并表示如果代码库开源，他们渴望为其做出贡献。
      提到的链接：
      --- **LM Studio ▷ #[model-announcements](https://discord.com/channels/1110598183144399058/1225909444727013466/1236452526484750347)** (1 条消息): - **CodeGemma 1.1 加入阵容**：`lmstudio-community` 仓库已更新 **CodeGemma 1.1**。人们对其性能提升抱有很高期待，类似于从 **Gemma 1.0 到 Gemma 1.1** 的升级，尽管具体细节仍然较少。[尝试 CodeGemma 1.1](https://huggingface.co/lmstudio-community/codegemma-1.1-7b-it-GGUF) - **Nvidia 发布 ChatQA 1.5 模型**：Nvidia 发布了两个版本的 **ChatQA 1.5**，尺寸分别为 **8B** 和 **70B**。专为 RAG 和基于上下文的问答设计，它们可能不适合作为通用聊天机器人，但非常适合处理上下文相关的查询。[尝试 ChatQA 1.5 - 8B](https://huggingface.co/lmstudio-community/Llama3-ChatQA-1.5-8B-GGUF), [尝试 ChatQA 1.5 - 70B](https://huggingface.co/lmstudio-community/Llama3-ChatQA-1.5-70B-GGUF) --- **LM Studio ▷ #[🛠-dev-chat](https://discord.com/channels/1110598183144399058/1234988891153629205/1236035899880636468)** (53 条消息🔥): - **沙箱解决方案**：用户讨论了在遇到提示沙箱问题的错误后，通过使用 `--no-sandbox` 标志修复应用在与终端交互时退出的问题。 - **LM Studio.js 服务器激活建议**：提供了关于使用 `lms server start` 命令启动 LM Studio 服务器，并使用 HTTP 监听器等待服务器激活的指导。 - **LM Studio 进入无头模式**：[yagilb](https://discord.com/channels/1110598183144399058/1234988891153629205/1235668310243151963) 解释说，新的 LM Studio v0.2.22 和 lms CLI 允许 LM Studio 以无头（headless）模式运行，并计划在未来进一步简化该过程。 - **欢迎为 CLI 贡献**：LM Studio 的 [CLI 是开源的](https://github.com/lmstudio-ai/lms)，鼓励社区为其开发做出贡献。 - **对流线型体验的期待**：一位用户表达了希望在 Linux 服务器上运行 LLM 时能有易于使用的无头设置，yagilb 回应称 CLI 已经实现了这一点，并将进一步改进。
      提到的链接：
      --- **CUDA MODE ▷ #[general](https://discord.com/channels/1189498204333543425/1189498205101109300/1236392835553693878)** (15 条消息🔥): - **BackPACK：PyTorch 用户的新工具**：[BackPACK 库](https://backpack.pt/) 可以从 [PyTorch](https://pytorch.org/) 的反向传播（backward pass）中提取更多信息。它包含一份出版物引用：Dangel, F., Kunstner, F., & Hennig, P. (2020) 题为 *[BackPACK: Packing more into Backprop](https://openreview.net/forum?id=BJlrF24twB)*。 - **CUDA NCCL 讲座**：由于 Discord 的问题，今天的 CUDA NCCL 会议移至 [Google Meet](https://meet.google.com/xtg-ihck-fmx)。 - **Google Meet 最佳实践**：一位成员分享了管理 Google Meet 会议的技巧，例如策划演讲、让参与者举手提问、管理聊天查询、处理机器人，以及鼓励使用摄像头以获得互动式的演讲体验。 - **增强互动式讲座**：鼓励参与者在演讲期间保持互动并开启摄像头，这比单纯看录像更具参与感。 - **Citadel 的盈利策略揭秘**：一位成员分享了一篇 [arXiv 论文](https://arxiv.org/abs/1804.06826)，解释了 Citadel 成功的财务策略。 - **即将发布的 CUDA NCCL 录像**：一位成员询问 NCCL 会议是否会上传到 YouTube，另一位成员回答说“很快（soon TM）”。
      提到的链接：
      --- **CUDA MODE ▷ #[triton](https://discord.com/channels/1189498204333543425/1189607595451895918/1236790278182932571)** (15 messages🔥): - **宣布融合 DoRA Kernel**：宣布了一个新的融合 **DoRA 层实现**，它显著减少了独立 kernel 的数量，特别是通过为层权重形状定制 GEMM kernel，并将 reduction 操作直接融合到 kernel 的 epilogue 中。详细信息、基准测试和用法可以在 [Fused DoRA kernels GitHub pull request](https://github.com/pytorch/ao/pull/216) 中找到。 - **DoRA 的潜在优化**：针对该公告，有人建议可以在推理时将 DoRA 权重预处理为等效于 LoRA，以潜在地减少所需的计算量，尽管这不适用于训练场景。 - **为 DoRA 定制的 Autotuner**：新的 DoRA kernel 实现了一个经过调整的 autotuner 用于调试，其中包括更好的日志功能，尽管大家承认 Triton 更新后的 autotuner 中现在可能也存在类似的功能，并正在考虑与 Triton 内置的 autotuner 保持一致。 - **期待深入的基准测试**：成员们表示有兴趣看到比较 DoRA 层内计算成本和数据移动的基准测试，特别是关注新的融合 GEMM kernel 的表现，并包含了参考实现以便进一步进行 profiling。 - **ONNX 中的 Triton Kernel**：有人发布了关于在 ONNX Runtime 中将 Triton kernel 作为自定义算子使用的求助请求，因为现有的文档被认为有些有限且过时。
      提到的链接：
      --- **CUDA MODE ▷ #[cuda](https://discord.com/channels/1189498204333543425/1189607726595194971/1235860230395400202)** (64 messages🔥🔥): - **安装自定义 PyTorch/CUDA 扩展**：一位成员询问了在 `setup.py` 文件中安装自定义 PyTorch/CUDA 扩展的更简洁方法。他们提到了使用命令行时的日志记录和系统兼容性问题。讨论引用了三个 GitHub pull requests 以及来自 PyTorch/AO 仓库的 `setup.py` 特定部分作为示例：[PR#135](https://github.com/pytorch/ao/pull/135)、[PR#186](https://github.com/pytorch/ao/pull/186)、[PR#176](https://github.com/pytorch/ao/pull/176) 和 [pytorch/ao setup.py 示例](https://github.com/pytorch/ao/blob/0ba0006eb704dea33becec82b3f34512fe8a6dff/setup.py#L35-L78)。 - **TorchServe GPU 配置说明**：一位成员需要澄清演示中提到的性能设置，特别是关于 `torch.set_num_threads` 的部分。分享了一篇 [博客文章](https://pytorch.org/tutorials/intermediate/torchserve_with_ipex.html) 以获取有关 `torch.set_num_threads` 的详细信息。进一步的说明指出，文档中关于较大 batch size 会导致更高延迟的描述有误，并讨论了如何调整 worker 数量以优化吞吐量和延迟。 - **CUDA 中的原子操作**：关于一段使用 `reinterpret_cast` 的 CUDA 代码片段是否具有原子性的讨论。确认该代码确实以原子方式执行，但根据 C++ 标准属于未定义行为。正确的、符合标准的做法应该使用 `std::bit_cast`。 - **Numba-CUDA 与 CUDA-C 的性能对比**：一项关于比较 numba-CUDA 和 CUDA-C 性能的查询显示，numba-CUDA 版本运行较慢。通过分享性能分析文件并检查 pTX 文件，发现 numba 版本包含可能减慢执行速度的内存安全检查。 - **对 CUTLASS 和 Stream-K 调度技术的兴趣**：一位成员表示有兴趣在未来讨论或讲座中探讨 CUTLASS 中用于 GEMM 的 stream-K 调度技术。虽然对该建议持开放态度，但有人指出 stream-K 可以作为另一个演讲中的一个简短小节，因为解释 CUTLASS 2.0 API 可能会非常冗长。
      提到的链接：
      --- **CUDA MODE ▷ #[torch](https://discord.com/channels/1189498204333543425/1189607750876008468/1235928158063169706)** (19 messages🔥): - **调试符号问题 (Debug Debugging Symbols)**: 一位参与者在使用旨在构建带有 **debug symbols** 的特定文件的脚本时遇到困难，该脚本对他们来说效果不佳。他们提到所有内容都过于混乱，无法进行适当的调试，并正在寻求另一种构建调试符号的方法，因为文档缺乏细节。 - **PyTorch 中的约束限制**: 一位成员讨论了 PyTorch 2.2 和 2.3 版本中由 `torch._dynamo.mark_dynamic(inputs, index=1)` 引起的不一致的 `ConstraintViolationError` 问题。他们发布了错误消息，并指出编译器似乎在多个 batch 的动态形状上存在分歧。 - **呼吁提交 GitHub Issue**: 一位成员建议针对前面提到的 PyTorch 约束问题创建一个 **GitHub issue**，并指出需要特定专家的见解。 - **Answer.AI 发布开源系统**: 一位成员提到了 **Answer.AI 的新开源系统**，该系统允许在带有游戏 GPU 的台式机上训练 70B 参数的语言模型。他们提供了一个 GitHub 链接，并分享了关于在不导致 out-of-memory（显存溢出）的情况下最快设置的问题。 - **模型训练显存洞察**：另一场对话中，成员们讨论了在不同配置以及不同版本的 PyTorch 和 Transformers 下，**LLaMa 2 70B 模型训练**的显存占用情况。报告的 8.6GB 峰值显存出乎意料，此外还分享了使用近 24GB 显存的微调命令。 - **PyTorch 的全方位追踪分析 (HTA)**：一位参与者介绍了 **HTA**（Holistic Trace Analysis）工具，并提供了文档链接。HTA 旨在通过分析 PyTorch Profiler 的追踪记录来协助识别性能瓶颈。 - **`torch.compile` 的特化错误 (Specialization Errors)**：针对早前的一个约束错误，一位成员解释说，该问题是由于代码强制对预期为动态的维度进行特化（specialization）导致的，并建议通过增加日志记录来诊断问题。
      Links mentioned:
      --- **CUDA MODE ▷ #[announcements](https://discord.com/channels/1189498204333543425/1189640399476764692/1236390606222266388)** (1 messages): - **GPU 集体通信速成课程**：CUDA MODE Discord 频道即将举行一场关于使用 **NCCL** 进行 GPU 集体通信的会议。一位兴奋的成员期待学习 PMPP 书籍中未涵盖的分布式 ML 概念。 --- **CUDA MODE ▷ #[algorithms](https://discord.com/channels/1189498204333543425/1189861061151690822/1236436649433632788)** (5 messages): - **适合 ML 系统新手的论文列表**：Marksaroufim 分享了一个 [ML 系统入门列表](https://github.com/cuda-mode/awesomeMLSys) 的 GitHub 链接，其中包含对机器学习系统新手有帮助的论文。 - **量化学习资源**：Mr.osophy 分享了一个 [YouTube 视频](https://youtu.be/0VdNflU08yA?feature=shared)，解释了**量化**及其在 PyTorch 中的实现，这对于有兴趣学习该主题的人来说是宝贵的资源。 - **动态内存压缩 (DMC) 提升 LLM 性能**：Andreaskoepf 提到了一种名为动态内存压缩 (DMC) 的新技术，该技术在 H100 GPU 上可将 Llama 模型的吞吐量提高多达 370%。他们分享了[原始推文](https://x.com/p_nawrot/status/1768645461689168365)，其中还包含[研究论文](https://arxiv.org/abs/2403.09636)的链接。
      Links mentioned:
      --- **CUDA MODE ▷ #[beginner](https://discord.com/channels/1189498204333543425/1191300313928433664/1236522597903237170)** (9 messages🔥): - **CUDA MODE Discord 语音频道风波**：由于语音频道被滥用发布不当内容，多名用户被误封；管理员已表示歉意并开始恢复受影响的用户，包括 **@wilson**、**@c_cholesky**、**@jeffjeff** 和 **@harryone1**。 - **GPU 时钟频率困惑澄清**：针对 **H100 GPU** 时钟频率出现了一个初学者问题，特别是关于每秒操作数的计算和理论峰值性能。另一位用户指出这可能是一个单位错误，建议应为 **1.8 GHz**，而非 1.8 MHz。 --- **CUDA MODE ▷ #[pmpp-book](https://discord.com/channels/1189498204333543425/1194427148656721970/1236967183829962802)** (4 messages): - **矩阵转置难题**：一位成员质疑在每个元素仅被访问一次的情况下，矩阵转置中分块 (tiling) 的必要性。回答指出这是为了实现**合并内存写入 (coalesced memory writes)**，并提供了一篇[关于 CUDA 矩阵转置的澄清博客文章](https://developer.nvidia.com/blog/efficient-matrix-transpose-cuda-cc/)。 - **关于合并 (Coalescing) 的预习**：该成员感谢对合并 (coalescing) 的澄清，并提到该主题在下一章才会被讲解，这导致了他们最初的困惑。 - **话题顺序可能导致困惑**：作为回应，有人指出书中的问题有时会出现在相关主题讲解之前，这可能会让读者感到困惑。 **提到的链接**：An Efficient Matrix Transpose in CUDA C/C++ | NVIDIA Technical Blog：我上一篇 CUDA C++ 文章介绍了使用 Shared Memory 的机制，包括静态和动态分配。在本篇中，我将展示使用 Shared Memory 可以实现的一些性能提升。 --- **CUDA MODE ▷ #[youtube-recordings](https://discord.com/channels/1189498204333543425/1198769713635917846/1236329263892926557)** (6 messages): - **感谢支持**：一位成员对大家在处理高优先级工作导致频道内容更新延迟时的支持和理解表示感谢。 - **对 PyTorch Profiling 的认可**：成员们对 **nsys** 感到兴奋，并有兴趣尝试“轻量级”的 **PyTorch profiling 工具**。该成员受到一段录音的启发，并询问了活动结束后 Discord 中可能出现的突出问题。 - **对源码注解 (Source Annotation) 的赞赏**：成员提到 Taylor 即将推出的源码注解工具“非常酷”，让人联想到 Apple 的 Metal profiler 界面，可进行逐行着色器分析 (line-by-line shader profiling)。他们链接了 Apple 的开发者文档：[Optimize shaders with per-line shader profiling statistics](https://developer.apple.com/documentation/xcode/optimizing-gpu-performance#Optimize-shaders-with-per-line-shader-profiling-statistics)。 - **强调分析器功能**：文中重点介绍了一个能够在分析追踪 (profiled trace) 上进行编辑并获得近乎实时估算的分析器功能。它涉及 Instruments 利用架构知识来“重新运行”执行，可能基于采样 (sampling) 技术。 **提到的链接**：Optimizing GPU performance | Apple Developer Documentation：使用 Metal 调试器查找并解决性能瓶颈。 --- **CUDA MODE ▷ #[jax](https://discord.com/channels/1189498204333543425/1203956655570817034/1236409651550093463)** (1 messages): - **探索 JAX 多进程模型**：一位成员分享了他们对 JAX **分布式设置能力**的赞赏，特别是在 GPU 集群和 [Cloud TPU pods](https://cloud.google.com/tpu) 等环境下。他们引用了 [JAX 多进程文档](https://jax.readthedocs.io/en/latest/multi_process.html)，该文档提供了启动 JAX 进程和运行多进程计算的详细指南。 **提到的链接**：Using JAX in multi-host and multi-process environments — JAX documentation：未找到描述。 --- **CUDA MODE ▷ #[off-topic](https://discord.com/channels/1189498204333543425/1215328286503075953/1235936759435628575)** (12 messages🔥): - **动漫爱好分享**：成员们谈论了各自的动漫喜好；一位成员从小看《火影忍者 (**Naruto**)》长大，喜欢《一拳超人 (**One Punch Man** )》和《剑风传奇 (**Berserk** )》，并认为《咒术回战 (**JJK** )》拥有顶级的动画和战斗场面。另一位成员在某个场景的蓝光版发布后，幽默地表达了对《咒术回战》中宿傩 (Sukuna) 角色的钦佩。 - **iPhone 和 Mac 作为临时音视频方案**：一位成员建议使用 [iPhone & Mac](https://a.co/d/7uxdnek) 来获得更好的通话音视频质量，并指出当两台设备都更新并登录同一个 Apple ID 时，它们会自动集成。在 Photo Booth, Discord, Google Meet 和 Streamlabs 等各种平台上，都可以选择 iPhone 作为摄像头/麦克风输入。 - **对 Discord 到 Google Calendar 自动化的兴趣**：一位成员询问如何设置自动化，将 Discord 活动同步到 Google Calendar，以避免错过读书小组。虽然目前还没有提到现有的解决方案，但如果需求显著，大家对设置该功能持开放态度。 --- **CUDA MODE ▷ #[hqq](https://discord.com/channels/1189498204333543425/1225499037516693574/1236014784009474089)** (4 messages): - **GreenBitAI 推出 LLM 工具包**：一位成员重点介绍了 [GreenBitAI 的 green-bit-llm](https://github.com/GreenBitAI/green-bit-llm)，这是一个用于微调、推理和评估 GreenBitAI 语言模型的工具包，其范围比之前讨论的专门针对矩阵乘法操作的 bitblas 更广。 - **使用 BitBlas 进行快速推理**：据一位成员称，BitBlas 拥有针对 2-bit 操作优化的快速 gemv kernel，有助于加速推理任务，但他们尚未亲自测试。 - **GreenBitAI 的二进制矩阵乘法**：成员们对 [GreenBitAI 的 cutlass kernels](https://github.com/GreenBitAI/bitorch-engine/blob/main/bitorch_engine/layers/qlinear/binary/cutlass/binary_linear_cutlass.cpp) 表现出浓厚兴趣，特别是其在 bitorch-engine 中实现的二进制矩阵乘法。 - **权重中计算梯度**：另一位成员指出了 GreenBitAI 工具包的一个有趣属性；如 [bitorch-engine 的代码片段](https://github.com/GreenBitAI/bitorch-engine/blob/main/bitorch_engine/layers/qlinear/nbit/cutlass/q4_layer.py#L81) 所示，它会计算权重的梯度，由于梯度在训练期间没有被打包（packed），这引发了关于潜在 VRAM 占用的好奇。
      提到的链接：
      --- **CUDA MODE ▷ #[llmdotc](https://discord.com/channels/1189498204333543425/1227345713348870156/1235855152624173120)** (630 messages🔥🔥🔥): - **CUDA 编译问题**：像 `nvcc 11.5` 这样的编译器在旧型号 GPU 上进行 bfloat16 运算时会报错；`__ldcs` 和 `__stcd` 等函数未定义，且 `__bfloat1622float2` 等操作会导致问题。目前已提出一个 [修复方案](https://github.com/karpathy/llm.c/pull/353)，通过手动处理 bfloat16 算术运算来支持旧显卡和工具包。 - **多 GPU 训练挂起**：正如 [Issue #369](https://github.com/karpathy/llm.c/issues/369) 所报告的，最近对 master 分支的提交导致多 GPU 训练挂起。一个 [独立的开发分支](https://github.com/PeterZhizhin/llm.c/branch/nccl) 维持了正常的多 GPU 训练功能，目前正在考虑在诊断 master 分支问题的同时合并该分支。 - **性能与重构更新**：一个已合并的 PR 通过引入新的 [优化版 matmul_bias kernel](https://github.com/karpathy/llm.c/pull/343) 带来了小幅性能提升，随后的贡献旨在通过 kernel 融合和 [CUDA stream 调整](https://github.com/ademeure/llm.c/pull/2) 进一步增强性能。 - **NCCL 与计算重叠的正确性**：在多 GPU 训练中尝试重叠 NCCL 和反向传播计算，使迭代时间从 225ms 降低到 193ms ([PR #361](https://github.com/karpathy/llm.c/pull/361))。在优化多 GPU 逻辑时，正确性验证和测试仍然至关重要。 - **Nsight Systems 性能分析**：改进性能分析的努力包括使用 Nvidia 的 Nsight Systems 以获得更好的可视化效果，并深入了解 GPU 上应用程序性能的复杂性。这包括编写教程以帮助他人设置和使用 Nsight Systems 来分析和优化 CUDA 程序。
      提到的链接：
      --- **Modular (Mojo 🔥) ▷ #[general](https://discord.com/channels/1087530497313357884/1098713601386233997/1235867967179329607)** (102 messages🔥🔥): - **Mojo 安装查询**：一位用户询问了在桌面端安装 Mojo 的说明，表示需要支持。 - **社区进展**：ModularBot 庆祝了一位社区成员的等级提升，展示了一种基于成就的参与系统。 - **对 Mojo 的新贡献**：讨论显示了一个开源开发环境，用户被引导至 GitHub 仓库和 Issue 进行贡献，特别是根据 'soracc' 的建议向 [Mojo 标准库](https://github.com/modularml/mojo/blob/main/stdlib/docs/development.md)贡献。 - **解决贡献困惑**：成员 'gabrieldemarmiesse' 和 'soracc' 之间的讨论集中在澄清贡献流程、引用 [GitHub](https://github.com/modularml/mojo/pull/2457)，并考虑避免贡献者重复劳动的方法，例如“舔饼干（licking the cookie）”现象。 - **Mojo 版本方案说明**：用户澄清了 Mojo 使用的是 `YY.major.minor` 版本方案，而非语义化版本（SemVer），其中年份反映在第一个数字中（例如，版本 24.3.x 代表该年度的第三个主要发布版本）。
      提及的链接:
      --- **Modular (Mojo 🔥) ▷ #[💬︱twitter](https://discord.com/channels/1087530497313357884/1098713626161987705/)** (1 条消息): ModularBot: 来自 *Modular*: <https://twitter.com/Modular/status/1786483510141657384> --- **Modular (Mojo 🔥) ▷ #[📺︱youtube](https://discord.com/channels/1087530497313357884/1098713700719919234/1237145345541017682)** (1 条消息): - **Modular 社区直播公告**：Modular 宣布了一场直播活动，邀请大家探索其技术的最新更新，标题为“[Modular 社区直播 - MAX 24.3 新特性](https://www.youtube.com/watch?v=kKOCuLy-0UY)”。视频将讨论 MAX Engine 和 Mojo🔥 的新功能，并介绍 MAX Engine Extensibility API。 **提到的链接**：Modular 社区直播 - MAX 24.3 新特性：MAX 24.3 现已发布！加入我们即将举行的直播，我们将讨论 MAX Engine 和 Mojo🔥 的新功能 - 预览 MAX Engine Extensibility API... --- **Modular (Mojo 🔥) ▷ #[ai](https://discord.com/channels/1087530497313357884/1103420074372644916/1235975948986220596)** (3 条消息): - **对 Donald Hoffman 意识研究的兴趣**：一位成员计划转学到 UCI，以便参与 Donald Hoffman 教授的工作，他正致力于绘制意识体验图。他们认为裂脑患者有限的感官数据与 AI 幻觉之间存在关联，这支持了模拟大脑功能的效率。 - **共同的学术抱负**：另一位成员表达了对上述目标的共同兴趣，表明与意识研究相关的工作保持一致。 - **寻找 Max 开发者**：一名成员宣布他们正在为一个项目寻找 Max 开发者，并请求感兴趣的人员通过私信联系以获取更多细节。 --- **Modular (Mojo 🔥) ▷ #[🔥mojo](https://discord.com/channels/1087530497313357884/1151418092052815884/1235850464592134234)** (172 条消息🔥🔥): - **大数组下 InlineArray 的异常行为**：`InlineArray` 在处理大数组时存在一些持续性的异常行为问题，正如 GitHub issue [此处](https://github.com/modularml/mojo/issues/2425) 所强调的。 - **Mojo 的 GPU 支持受到质疑**：用户对 Mojo 是“解锁 AI 硬件的语言”这一说法提出了挑战，随后官方澄清 GPU 支持计划在未来几个月内推出，并特别提到了对 Nvidia 的支持。 - **MLIR 解锁 Mojo 的潜力**：一个关键讨论点是 Mojo 的潜力不仅限于 GPU 支持，还通过 MLIR 扩展到其他硬件加速，这使得该语言在面对新兴技术时具有前瞻性。 - **关于 Mojo 中 LaTeX 脚本并行化的问题**：一位用户在 Mojo 中对 LaTeX 脚本使用并行化时遇到困难，引发了关于可并行化函数的约束以及错误处理的建议。 - **Mojo 装饰器和自定义 `None` 值的挑战**：一位用户寻求关于装饰器的帮助（目前尚未完全支持），而另一位用户在为未初始化的 struct 成员表示 `None` 时遇到困难，并学习了如何使用 `Optional[Node]` 进行正确的类型标注。
      提到的链接:
      --- **Modular (Mojo 🔥) ▷ #[community-projects](https://discord.com/channels/1087530497313357884/1151418679578337311/1236019023083212881)** (22 条消息🔥): - **NuMojo 更新突飞猛进**：[NuMojo](https://github.com/MadAlex1997/NuMojo)（原名 Mojo-Arrays）已恢复活跃开发，并更新至 Mojo 24.3 版本。该库专注于围绕标准库 tensor 构建函数，目前速度显著提升，与 NumPy 相比，性能提高了 6 倍到 20 倍。 - **用于 Mojo 图像解析的 Mimage 库**：引入了一个名为 [Mimage](https://github.com/fnands/mimage) 的新库，用于在 Mojo 中进行图像解析，目前支持简单的 8 位 RGB PNG。社区正在讨论是采用 PIL 风格的 Image 类还是采用图像的 ND 数组表示。 - **Basalt 开发里程碑**：[Basalt 项目](https://github.com/basalt-org/basalt) 庆祝其 GitHub Star 数达到 200 颗，并在 [Basalt Docs](https://basalt-docs.vercel.app/) 发布了新文档，同时宣布了针对 Mojo 24.3 的更新。这些更新包括实验性的 ONNX 模型导入/导出、动态算子支持以及各种增强和错误修复。 - **Mojo 中 Struct 可组合性原型**：用于 Mojo 中 HTML 生成的 lsx 库在 [GitHub lsx](https://github.com/rd4com/lsx/tree/main/struct%20composability%20prototype) 分享了一个新的 Struct 可组合性原型，旨在实现与 lsx 的完全兼容并更好地处理 UnsafePointers。 - **MinBPE 移植与性能见解**：发布了 Andrej Karpathy 的 minbpe 项目的 Mojo 移植版本 [minbpe.mojo](https://github.com/dorjeduck/minbpe.mojo)，强调了从 Python 移植的挑战以及 Mojo 中缺少继承的问题。Mojo 版本的速度大约是 Python 原版的三倍，在切换到更高效的字典实现后，性能提升尤为明显。
      提到的链接：
      --- **Modular (Mojo 🔥) ▷ #[community-blogs-vids](https://discord.com/channels/1087530497313357884/1151418796993683477/1236021318067949648)** (6 条消息): - **使用 Mojo 和 Parameters 构建**：分享了一个关于使用 Parameters 构建 Mojo 应用的新教程，增强了工作流并集成了自定义约束。教程可在 [GitHub - Tutorial on parameters in Mojo](https://github.com/rd4com/mojo-learning/blob/main/tutorials/use-parameters-to-create-or-integrate-workflow.md) 获取。 - **语法高亮技巧**：针对 Mojo Parameters 教程，有人建议在 Markdown 文件中使用带有 "mojo" 标识的三反引号来提高代码的可读性。 - **探索在 Mojo 中解析 PNG**：分享了一篇关于使用 Mojo 解析 PNG 的博文，并发布了一个名为 *mimage* 的库，用于在 Mojo 中读取图像。[博文](https://fnands.com/mojo-png-parsing/)和 [mimage 库](https://github.com/fnands/mimage)均可在网上访问。 - **社区正面反馈**：关于 PNG 解析的博文收到了社区的正面反馈，同行们对这一努力表示赞赏。 - **RSS Feed 需要修复**：在一名社区成员表示有兴趣订阅未来的文章后，该博文作者承认需要修复其网站上的 RSS Feed 问题。
      提到的链接：
      --- **Modular (Mojo 🔥) ▷ #[📰︱newsletter](https://discord.com/channels/1087530497313357884/1157711273111339088/)** (1 条消息): Zapier: Modverse Weekly - 第 32 期 https://www.modular.com/newsletters/modverse-weekly-32 --- **Modular (Mojo 🔥) ▷ #[nightly](https://discord.com/channels/1087530497313357884/1224434323193594059/1235851909139660883)** (92 条消息🔥🔥): - **80 列限制辩论升温**：Discord 参与者讨论了超越 [80 列惯例](https://stackoverflow.com/questions/4651012/why-is-the-default-terminal-width-80-characters) 的必要性，这是打孔卡和显示器的历史遗留问题。一些成员表示更倾向于 100 列，认为这仍然允许并排查看多个文件。 - **Nightly Mojo 编译器更新**：发布了新的 [Mojo 编译器 nightly 版本](https://github.com/modularml/mojo/pull/2498/files)，提供的链接中包含近期更改的详细信息。鼓励用户使用 `modular update nightly/mojo` 进行更新。 - **Register passable 类型面临调整**：围绕 Mojo 中 "register passable" 概念的演变展开了讨论，目标是逐步淘汰像 `OptionalReg` 这样的类型，转而使用像 `Optional` 这样全能的类型，并倾向于使用 traits 来指示 register passability。 - **回应 math 模块的状态**：确认 math 模块并未消失；它尚未开源，因此在 stdlib 的开源部分中删除了对它的引用。 - **提交了 Pre-commit hook 问题**：报告了一个关于 ["check-license" pre-commit hook 的问题](https://github.com/modularml/mojo/issues/2528#issuecomment-2094837006) 的 issue，该 hook 无法找到 stdlib，引发了讨论并最终针对这个间歇性问题提交了 issue。
      提及的链接:
      --- **HuggingFace ▷ #[announcements](https://discord.com/channels/879548962464493619/897387888663232554/1235906896414769202)** (2 条消息): ```html
      • 社区亮点更新：社区亮点第 56 期介绍了 Moondream 2 批处理、FluentlyXL v4、HF Audio 课程前几章的葡萄牙语翻译、用于长字幕的 BLIP 微调以及许多其他项目。此处还提供了一份全面的葡萄牙语列表和亮点回顾 here。
      • AI 新进展分享：最新的 Spaces 包含 BLOOM 多语言聊天、一个 局部重绘（inpainting）素描板以及一个链接预测 仓库。此外，正如这条 推文所述，HuggingFace alignment handbook 任务现在可以通过 dstack 在云端运行。
      • 社区揭晓的酷炫内容：涵盖了从 使用生成式 AI 进行蛋白质优化 到 从零开始实现 Vision Language Model 的广泛主题。还讨论了结合 LLM 的 Google Search、用于快速 LLM 推理的 Token Merging 以及 一键创建聊天模型。
      • 前沿对话：已安排读书会讨论近期进展并分享见解，进一步促进 AI 领域的知识交流。要参加下一场活动，请查看此 链接。
      • 引入 AutoTrain 配置：AutoTrain 现在支持 yaml 配置文件，简化了模型训练过程，即使是机器学习新手也能轻松上手。有关此新功能的公告已发布在 推文上，包含示例配置的 GitHub 仓库可在此处 访问。
      ```
      提到的链接:
      --- **HuggingFace ▷ #[general](https://discord.com/channels/879548962464493619/879548962464493622/1235859617876021278)** (225 messages🔥🔥): - **探索音频扩散建模**：围绕创建一个根据反馈迭代生成音乐的模型展开了讨论，可能使用音频扩散模型。讨论了此类模型所需的计算深度及其在生成更长且符合理论的乐曲方面的能力。 - **困扰于大型模型转换**：一位用户在将 PyTorch 模型转换为 TensorFlow Lite 格式时遇到困难，遇到了大小限制错误。该模型在从 ONNX 转换为 TensorFlow 时超过了 2GB 的限制。 - **为菲律宾语 ASR 部署 Whisper**：讨论了为菲律宾语微调 Whisper ASR 模型的可行性。提到了 `weight_decay`、学习率和数据集大小（80k 音频块）等影响性能的因素。 - **黑客攻击后引发的安全担忧**：多条消息表明 Hugging Face 的 Twitter 账号被盗，引发了关于网络安全措施及其对 AI 系统影响的讨论。社区积极标记可疑活动并调查情况。 - **GPU 利用率之谜**：用户分享了关于本地机器与 Google Colab 之间 GPU 训练时间差异的经验和建议，研究了消费级显卡与边缘推理卡之间的效率差异，并提供了优化建议。
      提到的链接:
      --- **HuggingFace ▷ #[today-im-learning](https://discord.com/channels/879548962464493619/898619964095860757/1235893693454614528)** (12 条消息🔥): - **模型导出难题**：一位成员在导出微调模型时遇到困难，并遇到了令人沮丧的错误。 - **是否要手写循环**：关于是否总是建议编写自己的训练循环存在争论，一位成员建议使用来自 **Diffusers** 的示例并进行修改，这样可以实现更多的自定义。 - **对 Kolmogorov-Arnold Networks 感兴趣**：**Kolmogorov-Arnold Networks (KANs)** 因其比 MLPs 使用更少计算图的潜力而受到关注。该概念得到了研究支持，并分享了一个[学术链接](https://arxiv.org/abs/2404.19756v1)，该链接在准确性和可解释性方面将 KANs 与 MLPs 进行了比较。 - **深入研究微调**：一位成员分享了关于微调生成式 AI 模型含义的教育资源，包括一段[两分钟的 YouTube 视频](https://www.youtube.com/watch?v=yoLwkowb2TU&t=1s)和一个 [HuggingFace 教程](https://huggingface.co/docs/transformers/training)。 - **克服 API 部署挑战**：一位学习者在 Hugging Face Space 的 API 构建阶段遇到问题并寻求帮助，提到了 deeplearning.ai Hugging Face 课程中的一课，并指出了 `requirements.txt` 中的版本问题。 - **分步推理方法论**：一位成员尝试为 LLM 输出实现“逐步思考”的方法，但发现本地模型不能很好地理解这一点。一种涉及 `planner`、`writer`、`analyst` 和 `editor` 链的替代方案在 Llama 3 instruct 7B 上测试时取得了更全面的结果。
      提到的链接:
      --- **HuggingFace ▷ #[cool-finds](https://discord.com/channels/879548962464493619/897390579145637909/1235890773149614120)** (11 messages🔥): - **利用 RAG 彻底改变检索**：一份 [Databricks 术语表条目](https://www.databricks.com/it/glossary/retrieval-augmented-generation-rag) 讨论了 *检索增强生成 (Retrieval-Augmented Generation, RAG)*，强调了它如何解决大语言模型 (LLMs) 无法访问其原始训练集之外数据的问题，从而避免模型变得静态且有时不准确。 - **数据集巨头在 GitHub 上交锋**：Microsoft 发布了 [MS-MARCO-Web-Search 数据集](https://github.com/microsoft/MS-MARCO-Web-Search)，这是一个大规模 Web 数据集，包含数百万个真实的点击查询-文档标签，用于改进信息检索系统。 - **让 Webhooks 响起来**：Hugging Face 发布了一份指南，介绍如何创建一个监听 Webhooks 的服务器，部署到基于 Gradio 的 Spaces，并 [与 Huggingface Hub 集成](https://huggingface.co/docs/huggingface_hub/guides/webhooks_server#create-an-endpoint)。 - **步入量子服务**：分享了一个指向 [oqtant™ 量子虚拟服务器平台](https://oqtant.infleqtion.com/) 的链接，暗示了量子计算资源在可访问性方面的进展。 - **使用 Ragas 评估你的 RAG**：[Ragas 框架](https://docs.ragas.io/en/stable/) 被介绍为一种评估 LLM 应用中检索增强生成 (RAG) 流水线性能的工具，强调指标驱动的开发和用于稳健评估的合成测试集生成。
      提及的链接：
      --- **HuggingFace ▷ #[i-made-this](https://discord.com/channels/879548962464493619/897390720388825149/1235893212393111594)** (19 messages🔥): - **Shadow-Clown BioMistral 发布**：一个名为 [shadow-clown-BioMistral-7B-DARE](https://huggingface.co/kimou605/shadow-clown-BioMistral-7B-DARE) 的新模型已创建，它使用 **mergekit** 合并了 **BioMistral-7B-DARE** 和 **shadow-clown-7B-dare**，旨在结合两个模型的能力。 - **生成式合成数据工具发布**：一个用于生成和规范化合成数据的新工具现已在 PyPI 上可用，这可能有利于微调大语言模型。更多详情可以在 [GitHub 仓库](https://github.com/tobiadefami/fuxion) 中找到。 - **通过 Ollama 高效加载 LLM**：一个 [GitHub 页面](https://github.com/di37/LLM-Load-Unload-Ollama) 和一篇 [LinkedIn 帖子](https://www.linkedin.com/feed/update/urn:li:activity:7192369828848877568/) 展示了在使用 Ollama 时高效加载和卸载 LLM 的方法。 - **AI 辅助你的播客创作**：HuggingFace 上的 [Podcastify](https://huggingface.co/spaces/eswardivi/Podcastify) Space 可以将文章转换为类似播客的对话。 - **OpenGPTs 挑战 GPT Store**：[OpenGPTs-platform](https://github.com/OpenGPTs-platform) 发布，旨在模仿并扩展官方 GPT Store 的功能，初始版本包含 "Assistants API" 和各种内容检索工具。
      提及的链接：
      --- **HuggingFace ▷ #[reading-group](https://discord.com/channels/879548962464493619/1156269946427428974/1236354360716427314)** (45 messages🔥): - **Graph ML 与 LLMs 讨论预告**: **HuggingFace Discord** 小组正在举行一场围绕近期一篇关于 [Graph Machine Learning](https://arxiv.org/abs/2404.14928)（图机器学习）论文的[会议](https://discord.com/channels/879548962464493619/1203285086624157696)。该论文涵盖了大型语言模型 (LLMs) 在图机器学习中的应用及其广泛用途。 - **GNNs：无限可能的图景**: 成员们正在讨论 **Graph Neural Networks (GNNs)** 的多样化用途，从欺诈检测到生成推荐，甚至包括机器人的任务规划。GNNs 的多功能性激发了参与者的兴趣，促使一些人开始[尝试](https://cdn.discordapp.com/emojis/1225927322117341337.webp?size=48&quality=lossless)这些模型。 - **分享演示资源**: 演讲者 **Isamu Isozaki** 分享了一篇深入探讨讨论主题的 [Medium 文章](https://isamu-website.medium.com/understanding-graph-machine-learning-in-the-era-of-large-language-models-llms-dce2fd3f3af4)，并为错过现场演示的人提供了 [YouTube 视频](https://www.youtube.com/watch?v=cgMAvqgq0Ew&ab_channel=IsamuIsozaki)。此外，由于 Medium 的访问限制，大家还在讨论将内容上传到其他平台。 - **在 LLMs 中加入特殊 Token**: 一位成员重点介绍了一篇[论文](https://arxiv.org/abs/2404.19705)，该论文提出了一种训练方法，教导 LLMs 在不确定时使用特殊 Token `` 来触发信息检索。该方法旨在通过仅在必要时检索信息，来提高 LLMs 的准确性和效率。
      提到的链接:
      --- **HuggingFace ▷ #[computer-vision](https://discord.com/channels/879548962464493619/922424143113232404/1236019902398201936)** (42 messages🔥): - **汽车零部件中的间隙检测挑战**：一位成员描述了使用简单的 YOLO 分类模型来检测某些车辆部件间隙时遇到的问题。他们请求关于替代模型或技术的建议，以提高检测性能。 - **对经典 CV 的渴望**：一位计算机视觉领域的新成员询问了传统 CV 技术（如 SURF 和 SIFT）在当前行业的关联性，并想知道是否有必要深入了解这些方法。 - **微调目标检测**：讨论了微调目标检测模型的分类器部分，重点在于使用额外的 CNN 进行图像缩放是否比在输入 Darknet YOLO 等模型之前预缩放图像更有帮助。 - **CLIP 在旋转物体上的性能**：一位用户寻求关于使用 CLIP 模型匹配未完全对齐的《万智牌》(Magic: The Gathering) 卡牌图像的建议。建议包括使用旋转和倾斜的图像增强训练数据，以提高鲁棒性。 - **寻找 GhostNet 权重**：一位成员询问了适用于 TensorFlow 的 ImageNet 预训练 GhostNet 权重的可用性，分享了 [GhostNet 论文摘要](https://arxiv.org/abs/1911.11907) 和 [Efficient-AI-Backbones GitHub 仓库](https://github.com/huawei-noah/ghostnet)，但请求在 TensorFlow 中使用所提供权重的帮助。
      提及的链接:
      --- **HuggingFace ▷ #[NLP](https://discord.com/channels/879548962464493619/922424173916196955/1235892774528880641)** (12 messages🔥): - **寻求简化指令**：一位用户询问关于使用某个工具或方法的简化版本，但未指明具体是哪一个。 - **提供定制微调服务**：有一项公开请求，用户愿意为如何使用自定义数据集微调 **Mistral-7B-instruct** 模型的指导提供经济报酬。 - **对 LLM 评估的怀疑**：一位成员对使用 Large Language Models (LLMs) 来评估其他 LLMs 表示怀疑，理由是潜在的幻觉问题以及基础模型的快速迭代。该成员还指出，企业在针对其特定需求评估 LLMs 和 Retrieval-Augmented Generation (RAG) 系统时面临挑战。 - **基于 LLM 的翻译指标论文介绍**：通过 [ACL Anthology 论文链接](https://aclanthology.org/2023.eamt-1.19/) 介绍了 GEMBA 指标，这是一种基于 GPT 的翻译质量评估工具，论文描述了其在 GPT 3.5 及更大模型上的有效性。 - **请求 Flash Attention 实现教程**：一位成员询问如何将 **flash attention 2** 添加到 XLM-R，并询问 Hugging Face 是否提供了此类实现的教程或指南。 **提及的链接**：Large Language Models Are State-of-the-Art Evaluators of Translation Quality：Tom Kocmi, Christian Federmann。Proceedings of the 24th Annual Conference of the European Association for Machine Translation。2023。 --- **HuggingFace ▷ #[diffusion-discussions](https://discord.com/channels/879548962464493619/1009713274113245215/1235938948904128554)** (17 messages🔥): - **微调 StableDiffusionPipelines**：一位成员探索了使用两个不同 Pipeline 进行部分扩散（partial diffusion）的概念，即先用一个 Pipeline 对图像进行一半的去噪，然后用另一个继续。他们被引导至一个优秀的 **[pull request](https://github.com/huggingface/diffusers/compare/main...bghira:diffusers:partial-diffusion-2)**，该 PR 为 StableDiffusionXLPipeline 实现了这一过程。 - **部分扩散 PR 的协助**：鼓励该成员通过链接的 Pull Request 测试部分扩散功能，并直接在 PR 中报告任何问题，因为代码很快将进行重新审查和更新。 - **在多个主体上训练 Diffusion 模型**：一位成员询问关于同时训练 Diffusion 模型以学习多个主体的问题。建议他们探索 **[Custom Diffusion](https://huggingface.co/docs/diffusers/main/en/training/custom_diffusion#:~:text=Custom%20Diffusion%20is%20unique%20because%20it%20can%20also%20learn%20multiple%20concepts%20at%20the%20same%20time.)**，这是一种允许同时学习多个概念的训练技术。 - **Accelerate 多 GPU 运行与 CPU Offloading 的冲突问题**：一位成员在结合 **accelerate 的多 GPU 运行** 与 **diffuser 的模型 CPU offloading** 时遇到了技术挑战，特别是设备相关的错误。截至最后一条消息，社区尚未解决此问题。 - **使用 LLM 价格计算器估算账单**：另一位成员寻求确认，他们拥有的 Token 计数是否足以使用分享的 **[LLM Model Pricing](https://docsbot.ai/tools/gpt-openai-api-pricing-calculator)** 计算器来估算其 API 账单。该查询在讨论中尚未得到回应。
      提及的链接：
      --- **OpenInterpreter ▷ #[general](https://discord.com/channels/1146610656779440188/1147665339266650133/1235902892762730557)** (212 messages🔥🔥): - **呼吁开发者关注技能库（Skills Library）机会**：一位成员探讨了关于 OpenInterpreter **skills library** 的工作，引用了 Killian 在 GitHub 上的贡献，并建议查看 [skills.py](https://github.com/OpenInterpreter/open-interpreter/commits/59956e01ebedc74e0bfed80352ea0a90ecf154b1/interpreter/core/computer/skills/skills.py) 的提交历史。 - **微软开源 AI 黑客松公告**：成员们正在组建团队参加在西雅图举行的微软开源 AI 黑客松，意图使用 **Open Interpreter** 创建一个项目。黑客松承诺提供**实操教程**、披萨和下午茶点心，详情见[此处](https://lu.ma/iu1wijgd)。 - **Groq LLM 集成及问题**：讨论了将 **Groq LLM** 与 Open Interpreter 集成时遇到的问题，如不受控制的输出以及在桌面上创建多个文件等异常行为。提供的连接命令为：`interpreter --api_base "https://api.groq.com/openai/v1" --api_key "YOUR_API_KEY_HERE" --model "llama3-70b-8192" -y --max_tokens 8192`。 - **OpenAI Token 成本与优化担忧**：一位成员对使用 **OpenAI** GPT 的成本表示担忧，称在 API Token 上花费了大量资金。此外，还有人批评 Open Interpreter 针对闭源 AI 系统进行优化，认为这与其作为开源项目的身份不符，从而引起困惑。 - **分享本地 LLM 性能经验**：讨论包括对本地 LLM 的个人测试经验，涉及 **Phi-3-mini-128k-instruct** 和 **Groq** 模型。一位成员观察到前者存在明显的性能问题以及环境配置问题。另一位成员指出，纠正 LLM 的决策可能会带来更好的命令执行效果。
      提到的链接：
      --- **OpenInterpreter ▷ #[O1](https://discord.com/channels/1146610656779440188/1194880263122075688/1235874656725110856)** (104 条消息🔥🔥): - **TMC 协议的 iOS 实现**：一位成员正在重新实现用于 iOS 的 TMC 协议，以允许访问原生功能。他们质疑使用 TMC 协议相比普通 function calling 的优势，并等待关于其优点的进一步澄清。 - **使用 Azure Open AI 模型设置 O1**：一位成员在设置 O1 以配合 Azure Open AI 模型时遇到困难，指出尽管 OI 运行正常，但 .env 中的细节被忽略了。在之前的尝试失败后，他们正在寻求解决此问题的建议。 - **关于 O1 iOS 应用发布的询问**：成员们询问了 O1 iOS 应用的状态，其中一人分享了 [GitHub 仓库](https://github.com/OpenInterpreter/01/tree/main/software/source/clients/mobile)的链接，其中包含了相关的源文件。进一步的讨论表明该应用仍在开发中，并提供了一个 [YouTube 链接](https://youtube.com/clip/UgkxfnZt5xbMkao8C0DmdsRTpU2bn_iaWtOI?si=wlcIV_ySO6gAfncF)，介绍如何使用 Expo 同时为 Android 和 iOS 进行构建。 - **O1 的技术故障与解决方案**：成员们正在排查 O1 的各种问题，包括安装 poetry 的问题、利用空格键执行命令的问题以及运行本地模型的困难。解决这些问题的建议包括使用 conda 环境、降低 Python 版本以及正确安装软件包。 - **探索微软 Phi-3 Mini 的兼容性**：一位用户询问是否可以将微软的 Phi-3 Mini 模型与 Open Interpreter 配合使用，另一位用户提供了安装该模型并从启动列表中选择它的说明。
      提到的链接：
      --- **OpenInterpreter ▷ #[ai-content](https://discord.com/channels/1146610656779440188/1149229778138824765/1236133517772193885)** (15 条消息🔥): - **AI Vtuber 的 STT 挑战**：一位成员强调他们使用 **fast whisper** 实现了 **Speech-to-Text (STT)** 作为一键通话，但在实时转录方面遇到了挑战，例如 AI 中断用户以及转录背景语音。有人建议使用 *trigger word* 来提示系统，但在虚拟主播场景下被认为比较尴尬。 - **鼓励 AI 与直播观众互动**：AI Vtuber 主要通过 **Twitch API** 响应聊天，但在沉默期间，人工催化剂可以维持互动，直到形成观众群或 AI 学会参与游戏，这代表了集成 Twitch 聊天互动的早期阶段。 - **AI 管理 Twitch 聊天互动的计划**：管理 Twitch 聊天的方法涉及设置一个独立的 LLM 实例，它将理解对话流和用户消息以创建回复，目标是最终拥有一个能全面与直播聊天观众互动的 chatbot。 - **通过 Prompt 控制 LLM 行为**：强调了标准模型与涉及 Prompt 的 Instruct 模型之间的区别；建议使用经过微调以更好遵循指令的 **Instruct model**，以获得可控的结果。 - **分享实用的 AI 集成代码**：提到某位成员 GitHub 上的 **main.py** 文件包含聊天机器人集成的可用代码，用户只需更换 system prompt 即可适应其实现需求。 --- **Eleuther ▷ #[general](https://discord.com/channels/729741769192767510/729741769738158194/1235910528711528488)** (113 条消息🔥🔥): - **论文后续引发关注**：成员们分享了相关论文的链接，验证了 **large language models (LLMs)** 如何处理多语言能力，并讨论了描绘 LLM 处理多语言输入的框架，链接指向如 [How Mixture Models handle Multilingualism](https://arxiv.org/abs/2402.18815v1) 等论文。 - **对抗性挑战与架构讨论**：社区就对抗鲁棒性、通过扩展模型规模提升防御能力的潜力，以及建立系统化层级或缓冲机制以防止利用的需求展开了技术讨论，并引用了一篇关于[解决 LLM 漏洞的相关论文](http://arxiv.org/abs/2404.13208)。 - **求职分享与社区支持**：一位成员积极寻求就业机会，分享了他们的 LinkedIn 和 Google Scholar 个人资料，并强调了他们在 **EleutherAI** 的经验以及对 **Polyglot** 团队和 **OSLO project** 的贡献。 - **改进 In-Context Learning 测量**：有人提议了一种新的基准测试方法，通过改变 shot 数量来测量模型的 In-Context Learning 性能，这引发了关于评估 LLM 行为这一方面的最佳方法的对话。 - **ICLR 聚会协调**：几位社区成员讨论并安排了在 **ICLR** 的聚会，分享了计划并表达了对线下见面的兴奋，尽管一些人面临签证等旅行限制。 - **探索 System Prompt 的作用**：一位成员提到有兴趣使用 **lm-evaluation-harness** 探索 System Prompt 如何影响模型性能，但指出在使用 **Hugging Face models** 时难以找到指定 System Prompt 的方法。
      提到的链接：
      --- **Eleuther ▷ #[research](https://discord.com/channels/729741769192767510/747850033994662000/1235963390623613040)** (165 条消息🔥🔥): - **扩展后的 Transformer 征服国际象棋**：一篇新的[研究论文](https://arxiv.org/abs/2402.04494)讨论了一个拥有 2.7 亿参数的 Transformer 模型，该模型在由 Stockfish 16 标注的 1000 万场国际象棋对局上进行了训练，在 Lichess 闪电战对局和国际象棋谜题中取得了卓越表现，且无需领域特定的调整或显式搜索算法。该模型在没有 MCTS 的情况下优于 AlphaZero 的策略和价值网络，并提出了关于规模对策略游戏影响的问题。 - **GPT-2 的复活**：消息暗示了服务器上发布内容与互动之间存在巨大差距，例如一位成员提到在回复旧帖子前有三年的间隔，另一位成员则持续与过时内容互动。 - **通过“助产式提示词”（Maieutic Prompting）增强 LLM 搜索**：介绍了 [Maieutic Prompting](https://arxiv.org/abs/2205.11822) 的概念，这是一种通过生成溯因解释树来改进 LLM 从噪声和不一致数据中进行推理的方法，尽管对其实际有效性存在怀疑。 - **人工主导评估中的挑战与考量**：详细论述了研究中人工评估在确定样本量、显著性水平和统计检验方面的复杂性，例如比较两个聊天机器人。讨论提到了非劣性检验和系统误差分析，以有意义地评估干预措施的影响。 - **防止模型滥用的不可微调学习 (Non-Fine-Tunable Learning)**：在 SOPHON 框架中展示的一个名为 [non-fine-tunable learning](https://arxiv.org/abs/2404.12699) 的新概念，旨在保护预训练模型不被微调用于不道德的用途，同时保持其在原始任务中的性能。有人担心此类保护可能会过度限制未来模型在合法应用中的适应性。
      提到的链接：
      --- **Eleuther ▷ #[scaling-laws](https://discord.com/channels/729741769192767510/785968841301426216/1235971685035933758)** (9 条消息🔥): - **预训练和微调中的 Scaling Laws**：指向 [arXiv](https://arxiv.org/abs/2102.01293) 上的一项研究链接，详细介绍了迁移学习的经验性 Scaling Laws。研究发现，由于从预训练中迁移的有效数据，预训练模型在固定大小的数据集上持续改进，这由参数量和微调数据集大小的幂律 (power-law) 描述。 - **数据集担忧中的准确率**：两名成员讨论了 [Papers With Code](mailto:hello@paperswithcode.com) 显示数学解题准确率在两年内超过 70% 的影响。一位成员认为，最近的一些进展可能是由于专门用于性能测量的 GSM8K 和 MATH 等数据集发生数据泄漏的结果。 - **预训练中包含考试数据**：成员们讨论了 OpenAI 在其预训练数据集中包含 GSM8K 和 MATH 数据的可能性。虽然一些人对规则的遵守情况表示不确定，但他们澄清说，在 MATH 上进行微调是 2021 年达到 SOTA (state-of-the-art) 的标准做法。 - **评估原始测试数据集性能**：一位成员提供了 [GitHub 上的 odyssey-math](https://github.com/protagolabs/odyssey-math) 链接，并对 GPT-4-Turbo 在该原始测试数据集上报告的 47% 基准准确率发表了评论。他们计划对部分问题进行抽样，以评估数据集的难度，并指出该数据集规模较小，仅约 350 道题。 </div> --- **Eleuther ▷ #[interpretability-general](https://discord.com/channels/729741769192767510/1052314805576400977/1235905471685333092)** (7 messages): - **Transformer 模型解码**: 推出了一份关于 [基于 Transformer 的语言模型的新入门指南](https://twitter.com/javifer_96/status/1786317169979970046)，提供了从多年研究中获得的模型组件和解释方法的见解，以及对可解释性工具的广泛调查。 - **寻求模型部署协助**: 一位成员请求协助模型部署，但未提供有关其面临问题的更多细节。 - **跨模型泛化得到确认**: 使用英语作为枢轴语言的语言模型可解释性结果已在多种模型中得到复现，包括 **llama 1, 2** 以及现在的 **llama 3**，如最近的一条 [推文](https://twitter.com/Butanium_/status/1786394217478004950) 所分享。 - **深入探讨权重共享 (Weight Tying) 问题**: 一位成员正在使用 **LogitLens** 探索 **Phi-2** 和 **Mistral-7B** 等开源模型中的权重共享，并在输出层发现了意想不到的结果。 - **澄清权重共享难题**: 进一步调查得出的结论是，当代的开源模型实际上并未采用权重共享，这澄清了之前观察到的异常结果。 --- **Eleuther ▷ #[lm-thunderdome](https://discord.com/channels/729741769192767510/755950983669874798/1235953686811770921)** (3 messages): - **Prometheus 模型引起关注**: 成员们对 Hugging Face 上的 [**AlekseiPravdin/prometheus-7b-v2_0-gguf**](https://huggingface.co/AlekseiPravdin/prometheus-7b-v2_0-gguf) 模型表示了兴趣，认为这可能是其工作中一个显著的改进。 - **寻求合作**: 一位成员自愿协助上述模型的集成，并强调了聊天模板在性能指标方面带来的好处。 - **集成准备工作正在进行中**: 正在编写用于实施基于 **AlekseiPravdin/prometheus-7b-v2_0-gguf** 改进的产品需求文档 (PRD)。该模型的作者也在聊天中，预示着潜在的直接合作。 **提及链接**: 论文页面 - Prometheus 2: An Open Source Language Model Specialized in Evaluating Other Language Models: 未找到描述 --- **OpenRouter (Alex Atallah) ▷ #[announcements](https://discord.com/channels/1091220969173028894/1092729520181739581/1236191657049981049)** (3 messages): - **Llama 3 Lumimaid 8B 现已上线**: OpenRouter 发布了一个新模型 [Llama 3 Lumimaid 8B](https://openrouter.ai/models/neversleep/llama-3-lumimaid-8b)，适用于 2023 - 2024 年。 - **Llama 3 Lumimaid 8B 扩展版发布**: 同时也提供 Llama 3 Lumimaid 8B 的扩展版本，为用户提供额外功能，命名为 [Llama 3 Lumimaid 8B Extended](https://openrouter.ai/models/neversleep/llama-3-lumimaid-8b:extended)。 - **Llama 3 8B Instruct Extended 降价**: 对于寻找实惠的用户来说有个好消息，[Llama 3 8B Instruct Extended](https://openrouter.ai/models/meta-llama/llama-3-8b-instruct:extended) 的价格已经下调。 - **Lynn 模型临时停机**: 服务器更新将导致 [Lynn](https://openrouter.ai/models/lynn) 及其相关模型出现约 10 分钟的短暂停机。 - **Soliloquy L3 8B 更新至 v2**: Soliloquy L3 8B 模型已升级到版本 2，改进了重复和检索问题，增强了指令遵循能力，新价格为每 1M tokens 0.15 美元。在此探索 [Soliloquy L3 8B v2](https://openrouter.ai/models/lynn/soliloquy-l3)。
      提及链接:
      • Lynn: Llama 3 Soliloquy 8B v2 by lynn | OpenRouter: Soliloquy-L3 v2 是一款快速且功能强大的角色扮演模型，专为沉浸式、动态体验而设计。Soliloquy-L3 在超过 2.5 亿个 token 的角色扮演数据上进行了训练，拥有庞大的知识库……
      • Llama 3 Lumimaid 8B by neversleep | OpenRouter: NeverSleep 团队回归，带来了基于其精选角色扮演数据训练的 Llama 3 8B 微调模型。Lumimaid 在 eRP 和 RP 之间取得了平衡，设计风格严肃，但在必要时保持无审查……
      • Llama 3 Lumimaid 8B by neversleep | OpenRouter: NeverSleep 团队回归，带来了基于其精选角色扮演数据训练的 Llama 3 8B 微调模型。Lumimaid 在 eRP 和 RP 之间取得了平衡，设计风格严肃，但在必要时保持无审查……
      • Meta: Llama 3 8B Instruct by meta-llama | OpenRouter: Meta 最新的模型系列 (Llama 3) 发布了多种尺寸和版本。这个 8B 指令微调版本针对高质量对话场景进行了优化。它展示了强大的……
      • OpenRouter: 在 OpenRouter 上浏览模型
      --- **OpenRouter (Alex Atallah) ▷ #[app-showcase](https://discord.com/channels/1091220969173028894/1092850552192368710/1236801053090119691)** (3 messages): - **介绍 eGirlfriend AI**：一名成员构建了名为 [eGirlfriend AI](https://egirlfriend.ai) 的项目初始版本，并邀请社区提供反馈，并指出它是 **100% 免费**的。 - **适合家庭使用的 Streamlit 聊天应用**： 一款名为 *Family Chat* 的家庭聊天应用已创建，旨在经济高效地利用 OpenRouter API 和 OpenAI API，具有**对话记忆 (Conversational Memory)**、**PDFChat** 和**图像生成**功能。你可以在 [GitHub](https://github.com/DrDavidL/family-chat/blob/main/README.md) 上探索并为其做出贡献。 - **Rubik's AI Pro 招募 Beta 测试人员**： 名为 **Rubik's AI Pro** 的高级研究助手和搜索引擎的创建者正在招募 Beta 测试人员，提供 2 个月的免费高级版，其中包括访问 **GPT-4 Turbo** 和 **Mistral Large** 等模型。感兴趣的人员可以在[此处](signup.php)注册并输入促销代码 `RUBIX`。
      提到的链接:
      --- **OpenRouter (Alex Atallah) ▷ #[general](https://discord.com/channels/1091220969173028894/1094454198688546826/1235990719760568461)** (248 messages🔥🔥): - **Gemini Pro 故障已修复**：报告了一个关于 **Gemini Pro** 错误消息的问题，但在几天内得到了解决。用户被告知该功能已恢复正常，如果问题仍然存在，请联系支持人员。 - **Lumimaid 70B 期待**：讨论表明正在与 Mancer 沟通关于托管 **Lumimaid 70B** 的事宜，并建议向专注于 RP 模型的提供商 Novita 咨询。 - **Phi-3 托管的不确定性**：尽管有兴趣，但目前似乎缺乏托管 **Phi-3** 的提供商，尽管据说 Microsoft Azure runner 拥有该模型，但没有按 token 计费的定价。 - **OpenRouter 与 AI 模型精度**：澄清了 OpenRouter 上的模型提供商使用不同的精度；大多数运行在 **fp16**，有些运行在量化的 **int8**。 - **Meta-Llama 3 120B Instruct 自合并**：Hugging Face 上出现了一个 **Meta-Llama 3 70B 的自合并版本**，灵感来自其他大型合并，引发了人们对自合并与层映射合并 (layer-mapped merges) 相比效果如何的好奇。
      提到的链接:
      --- **LlamaIndex ▷ #[blog](https://discord.com/channels/1059199217496772688/1187460979064324127/1235984738683064388)** (7 messages): - **反思型自我改进 Agent**：LlamaIndex 0.10.34 引入了 **introspective agents**（内省型 Agent），它们可以通过反思和自我批评在无需人工干预的情况下提升性能。该方法及 `llama-index-agent-introspective` 软件包在 [notebook](https://t.co/X8tJGXkcPM) 中有详细介绍，并附带安装指南，其中包含针对敏感内容的警告。 - **Agentic RAG 进展演示**：@jasonzhou1993 的一段视频展示了构建 Agentic RAG 所需的**组件概览**，重点介绍了使用 LlamaParse + Firecrawl 进行的高级文档处理。感兴趣构建 Agent 系统的人员可以在[此处](https://t.co/wR35iYIKjo)观看视频。 - **RAG 响应的信任评估**：@CleanlabAI 开发了一个“可信语言模型”（Trustworthy Language Model），为检索增强生成 (RAG) 的响应分配**可信度评分**，解决了验证生成内容准确性的挑战。有关此功能的更多详细信息可以在他们的推文[此处](https://t.co/KW1XsllRqQ)找到。 - **本地 RAG 设置指南**：对于寻求**全本地 RAG 流水线**的用户，@pavan_mantha1 提供了一份深入的手册，介绍了使用 @llama_index 和 HyDE 层的设置。该文章被描述为比“5 行代码”快速入门更底层的指南，可通过[此链接](https://t.co/2RCvaxOzKo)访问。 - **LlamaIndex 宣布支持 Hugging Face TGI**：LlamaIndex 宣布支持 **Hugging Face TGI**，这是一个确保 Hugging Face 上语言模型优化部署的工具包，现在具备 **function calling**、批处理推理和更快的延迟等特性。关于 TGI 功能的详细信息在[此处](https://t.co/3vGpxcbP18)列出。 **提及的链接**：Introspective Agents: Performing Tasks With Reflection - LlamaIndex：未找到描述 --- **LlamaIndex ▷ #[general](https://discord.com/channels/1059199217496772688/1059201661417037995/1235849486564200489)** (226 条消息🔥🔥): - **使用可控 Agent 探索 RAG**：一位用户询问如何在**检索增强生成 (RAG)** 项目中实现 **Controllable agents**（可控 Agent），使 Agent 能够提出后续问题以获得更精确的检索结果。提供了使用 LlamaIndex 的详细实现指南，包括指向 [Agent Runner](https://docs.llamaindex.ai/en/examples/agent/agent_runner/agent_runner/) 和 [Controllable Agent Runner](https://docs.llamaindex.ai/en/examples/agent/agent_runner/agent_runner_rag_controllable/) 等相关文档的链接。 - **LlamaIndex 内存问题排查**：用户讨论了使用 LlamaIndex 时的高 VRAM 占用和潜在的内存泄漏问题，导致清理缓慢并回退到 CPU 处理。一位用户指出，通过新的 **[ollama v0.1.33 更新](https://github.com/ollama/ollama/releases/tag/v0.1.33)** 成功解决了此类问题。 - **LLM 微调与成本讨论**：讨论了专门针对特定任务（如在特定领域专业化的轻量级模型）微调语言模型 (LLM) 的话题。提到了微调的高昂成本，用户正在寻找可优化且具有成本效益的解决方案。 - **实现 SharePoint Reader 与 VectorStore 的挑战**：一位成员寻求关于集成 **SharePoint Reader** 以从 SharePoint 加载文件的反馈，另一位成员遇到了 LlamaIndex 中 **SupabaseVectorStore** 返回空响应的问题，这表明可能存在配置问题。 - **理解并优化基于 Excel 数据的问答系统**：一位用户询问了构建基于中等规模 Excel 表格的问答系统的最佳方法，重点是为复杂查询提供上下文相关的上下文信息。 - **LlamaIndex 特定细节的实现与配置**：多位用户讨论了导入错误、`llama-index` 中的正确路径、如何处理法律文档数据提取、如何处理 Intel 处理器的 embeddings，以及动态配置 ReAct Agent。在 **cheesyfishes**（推测是社区中的专家）的帮助下，同行之间进行了求助与交流，提供了关于 LlamaIndex 使用和集成的指导。
      提及的链接：
      --- **LlamaIndex ▷ #[ai-discussion](https://discord.com/channels/1059199217496772688/1100478495295017063/1237021916792098916)** (4 messages): - **寻求 NL-SQL 机器人建议**：一位成员正在为一个拥有数百张表的复杂数据库创建 **NL-SQL 聊天机器人**，并询问关于使用 **HyDE 方法** 的建议。他们正在探索提高 LLM 生成 SQL 查询准确性的解决方案，并指出 HyDE 主要用于基于文本的聊天机器人。 - **内省代理 (Introspective Agents) 讨论**：提到了一篇题为 **"Introspective Agents with LlamaIndex"** 的文章，指出了一种涉及内省代理的新方法或进展。分享了文章链接：[Introspective Agents with LlamaIndex](https://medium.com/ai-artistry/introspective-agents-with-llamaindex-777d018f791d)。 --- **OpenAccess AI Collective (axolotl) ▷ #[general](https://discord.com/channels/1104757954588196865/1104757955204743201/1235886536466239549)** (33 messages🔥): - **Hermes 在 Android 上运行飞快**：一位成员对 **Hermes 2 Pro Llama 3** 在 8GB RAM 的 Android 设备上的 **推理速度** 表示惊讶，并将其性能归功于 **llama.cpp**。 - **Anime 风格 AI 创新**：有一场幽默的讨论，暗示 AI 的进步和技术创新似乎与 **Anime** 在 **问答 (question-answering)** 和 **图像生成 (image generation)** 领域的泛滥交织在一起。 - **Llama.cpp 合并性能增强 PR**：一位成员分享了合并到 **llama.cpp** 的新 Pull Request 的消息，该 PR 带来了 **30% 的推理速度提升**，似乎在邀请创作 **更多 Anime**。 - **Axolotl 渐进式文档**：分享了 **Axolotl 社区** 的 **开发中文档 (work-in-progress documentation)** 链接，并邀请大家提供反馈。 - **梯度检查点 (Gradient Checkpointing) 优化报告**：记录了关于 **新 Unsloth** 梯度检查点的更新，该更新减少了 VRAM 占用，展示了社区在优化机器学习过程中内存利用率方面的积极努力。
      提到的链接：
      --- **OpenAccess AI Collective (axolotl) ▷ #[axolotl-dev](https://discord.com/channels/1104757954588196865/1104758010959634503/1235918795705417758)** (8 条消息🔥): - **Gradio 迎来可配置性**：一位成员寻求帮助，希望通过 YAML 配置 Gradio 选项（如将 Demo 设为私有、设置 IP 地址）。解决方案包括将这些选项添加到 YAML 中，并修改代码以解析设置，正如[其实现](https://github.com/OpenAccess-AI-Collective/axolotl/pull/1591)所示。 - **深入探讨 Gradio Token 问题**：出现了一个令人费解的问题，Gradio 没有为 Llama 3 模型使用正确的 Token，意外打印了 `<|end_of_text|>`。似乎 Gradio 的默认 Token 可能会无意中覆盖已加载的分词器 (Tokenizer) 设置，除非指定了特殊 Token。 - **推动更动态的 Gradio**：讨论了一项代码更改，允许动态配置 Gradio 的参数，如 "private"、"server_name" 和 "port"。这将通过 YAML 配置实现对 Gradio 行为的更大控制。 - **PR 已准备好评审**：提交了一个解决 Gradio 自定义问题的 Pull Request，为项目中各种硬编码选项添加了可配置参数，记录了重要细节并通过 [GitHub PR](https://github.com/OpenAccess-AI-Collective/axolotl/pull/1591) 展示了实现。 - **Issue 还是 Pull Request？永恒的问题**：一位成员询问是应该为问题开一个 Issue 还是直接提交 Pull Request。虽然没有记录回复，但该成员主动创建了一个 Pull Request 来解决潜在问题。 **提到的链接**：marijnfs 提交的 Gradio 配置参数 · Pull Request #1591 · OpenAccess-AI-Collective/axolotl：Gradio 的各种参数之前是硬编码的（例如 share=True、IP 地址、端口、Token 数量、Temperature），我在这里将它们设为可配置。此外，默认 Token 被覆盖到了... --- **OpenAccess AI Collective (axolotl) ▷ #[general-help](https://discord.com/channels/1104757954588196865/1110594519226925137/1235866742010417153)** (8 条消息🔥): - **对训练后的 Llama3 进行推理**：有人询问在使用 fft 脚本训练 **llama3** 后如何进行推理，并澄清通常的 **qlora** 命令和 **qlora_model_dir** 似乎并不适用。 - **调整推理参数**：一位成员建议在未指明的上下文中使用 **4,4** 的参数设置，暗示这些设置取得了成功。 - **将 Safetensors 转换为 GGUF**：一位用户寻求帮助，希望将 safetensors 转换为 **gguf**，且需要比 **llama.cpp** 提供的更多选项，特别提到了 `Q4_K` 和 `Q5_K` 等格式。 - **Llama.cpp 转换脚本**：该用户被引导至 **llama.cpp** 的转换脚本，特别提到了 [convert-gg.sh](https://github.com/ggerganov/llama.cpp/blob/master/scripts/convert-gg.sh)，推测是为了处理 **gguf 转换选项**。 - **Axolotl 社区文档**：分享了 Axolotl 社区文档的链接，该文档仍需完善，特别是在训练后合并模型权重以及使用模型进行推理方面，并邀请在 [Axolotl Community Docs](https://axolotl.continuumlabs.pro/) 提供反馈。
      提及的链接：
      --- **OpenAccess AI Collective (axolotl) ▷ #[datasets](https://discord.com/channels/1104757954588196865/1112023441386778704/1236106691053883542)** (39 messages🔥): - **CodeTester 数据集扩展**：来自 Vezora 的*更新版 Python 数据集*现在包含 143,327 个经过仔细测试且可运行的代码示例，旨在辅助从 Alpaca 格式的数据集中提取和验证 Python 代码片段。关于该数据集及其创建过程的更多信息可以在 [Hugging Face 数据集仓库](https://huggingface.co/datasets/Vezora/Tested-143k-Python-Alpaca)中找到。 - **Llama3 数学训练难题**：成员们讨论了在提升 Llama3 数学内容性能方面的困难，指出尽管在 orca-math-word-problems-200k 和 MetaMathQA 等数据集上进行了训练，但*数学主题评分反而下降*，这些数据集可在 [MathInstruct](https://huggingface.co/datasets/TIGER-Lab/MathInstruct) 和 [MetaMathQA](https://huggingface.co/datasets/meta-math/MetaMathQA) 获取。 - **量化对模型性能的影响**：一位成员强调了 **llama.cpp 量化**对模型性能可能产生的负面影响，并引用了 GitHub 上关于合并 LORA Adapter 后进行 Llama3 GGUF 转换的讨论，更多细节可在[此 issue](https://github.com/ggerganov/llama.cpp/issues/7062#issuecomment-2094961774)中探索。 - **评估脚本与提示词**：一位成员使用 [lm-evaluation-harness](https://github.com/EleutherAI/lm-evaluation-harness) 对 Llama3 进行推理和评估，而其他人则指出了确保正确提示词格式的重要性，并对使用 Alpaca 格式提示词对模型性能的潜在影响提出了疑问。 - **提示词格式难题**：关于微调期间的提示词格式（如使用 Alpaca 格式）如何影响模型性能的争论仍在继续。成员们正在思考，即使模型没有生成词表外 (out-of-vocabulary) 的文本结束标记，这是否仍会导致问题。
      提及的链接：
      --- **OpenAccess AI Collective (axolotl) ▷ #[axolotl-phorm-bot](https://discord.com/channels/1104757954588196865/1225558824501510164/1236482608502935615)** (27 条消息🔥): - **梯度裁剪（Gradient Clipping）查询**：围绕在 **Axolotl** 中使用 Axolotl `TrainingArguments` 或在 YAML 配置中设置梯度裁剪展开了讨论。Phorm 建议在 `TrainingArguments` 中或 YAML 文件的优化设置下设置 `max_grad_norm`。 - **需要文档超链接**：成员指出，由于向 quarto markdown 的过渡，在 Axolotl YAML 中指定梯度裁剪可能未在文档中反映，这表明需要更新文档索引。 - **修改聊天机器人提示词**：一位用户询问了如何在 ShareGPT 数据集格式中修改对话训练的系统提示词（System Prompt）。Phorm 指出应调整对话模板，或者修改 `ShareGPTPrompter` 类及相关配置文件中的初始消息。
      提到的链接:
      --- **Latent Space ▷ #[ai-in-action-club](https://discord.com/channels/822583790773862470/1200548371715342479/1236044647785304109)** (95 条消息🔥🔥): - **Gary for Live! 一场计算音乐之旅**：一位成员分享了 [GitHub 上的 gary4live](https://github.com/betweentwomidnights/gary4live) 链接，这是一个涉及 Python continuations 和 Ableton 的在研项目，并鼓励其他人查看代码。 - **Suno 与音乐生成讨论**：围绕使用 Suno 生成音乐以及 *Musicgen* 等其他音乐生成设置的能力展开了对话。大家特别感兴趣的是探索这些模型如何处理不同的音频元素，以及它们是否生成乐谱等资产。 - **深入探讨音乐模型 Token**：聊天深入探讨了音乐模型 Token 的复杂性，讨论重点在于 Suno 对音频的 Token 化，以及关于这些 Token 的长度和组成的问题。虽然提到了论文中的架构设计，但讨论中并未充实具体细节。 - **音频合成中的潜空间 (Latent Spaces)**：参与者讨论了多模态模型在不经过文本中间体的情况下直接整合音频的潜力，强调了包含音频对于实现真正的全模态 (omnimodal) 能力的重要性。对话还包括在实时应用中使用模型生成内容来替换音频通道等想法。 - **探索 Stable Audio 的商业用途和许可**：一位成员提出了关于 Stable Audio 模型输出的商业用途和许可问题。讨论转向了此类模型的实时应用，例如使用 AI 进行现场表演循环。
      提到的链接：
      --- **AI Stack Devs (Yoko Li) ▷ #[ai-companion](https://discord.com/channels/1122748573000409160/1122788693950857238/1237016300333694997)** (6 messages): - **云订阅费用的澄清**：成员们确认，如果本地运行，则**不需要云订阅费用**；该工具在 6 GB VRAM 下运行良好，并包含免费的语音输出。 - **拥有下载内容**：强调了通过 **Faraday** 下载角色和模型后，它们将*永久*归你所有。 - **本地使用取代云订阅**：性能足够的 GPU 可以免除云订阅的需求，云订阅被建议作为对工具开发者的可选捐赠。 --- **AI Stack Devs (Yoko Li) ▷ #[team-up](https://discord.com/channels/1122748573000409160/1128471951963328512/1237055950032998422)** (2 messages): - **征集嘻哈模拟合作**：一位成员表示有兴趣创建一个引用 **Kendrick** 和 **Drake** 之间局势的有趣模拟。另一位成员对合作号召做出了积极回应。 --- **AI Stack Devs (Yoko Li) ▷ #[ai-town-discuss](https://discord.com/channels/1122748573000409160/1132926337598902293/1235974067073585294)** (15 messages🔥): - **AI 领导人选举讨论**：人们对 AI 是否会选举领导人表现出好奇，特别是原始模拟论文中描述的市长选举，该事件在模拟中似乎*从未真正触发*。 - **在玩家简介中设置 AI 选举**：一位成员表示，在玩家简介（Player Bios）中设置 AI 选举将是*简单的*，并引用了对 AI 模拟中市长事件的好奇。 - **AI-Westworld 公测与 The THING 模拟**：@TheoMediaAI 的一条推文强调了对两个 AI 世界模拟的探索，包括处于公测阶段的 @fablesimulation 的 **AI-Westworld**，以及在 @realaitown 中重现电影《怪形》（The THING）。 - **推出用于回放的 AI Town Player**：@cocktailpeanut 的一条推文介绍了 **AI Town Player Web 应用**，它允许通过导入 sqlite 文件来回放任何 AI Town。该应用指出整个 AI Town 都通过 @convex_dev 存储在单个 sqlite 文件中，并兼容 Mac 和 Linux，但不兼容 Windows。 - **AI 模拟派对登上新闻**：[sfstandard.com](https://sfstandard.com/2024/05/04/mission-control-hacker-house-san-francisco-ai-simulated-party/) 的一篇专题报道描述了在旧金山 Mission Control 举办的 **AI 模拟派对**，人类参与者的活动与在屏幕上显示的数字化版本中运行的 AI 版本同步。
      提到的链接：
      --- **AI Stack Devs (Yoko Li) ▷ #[ai-town-dev](https://discord.com/channels/1122748573000409160/1137456826733047908/1235923879835205704)** (61 messages🔥🔥): - **Ubuntu 和 Node 版本困扰**：用户 `utensil_18981` 报告了在 Ubuntu 18 上尝试运行 `convex-local-backend` 时遇到的问题，最终通过将 Node 降级到 18.17.0 版本并修补 Ubuntu 解决了多个问题，详见[此 GitHub 线程](https://github.com/get-convex/convex-backend/issues/1)。 - **考虑使用 Docker 进行简化**：`utensil_18981` 对设置 `convex-backend` 和 `ollama` 表示沮丧，提到可能的 Docker 构建可以简化该过程。`.casado` 承认了该想法的价值，并考虑在周末进行研究。 - **为本地 LLM 推出 llama-farm**：`ianmacartney` 介绍了 `llama-farm`，这是一个旨在将运行 Ollama 的本地机器连接到云端后端的新项目，通过避免公网暴露提供简单的扩展性和安全性。该项目可以在 GitHub [此处](https://github.com/get-convex/llama-farm-chat)找到。 - **AI 真人秀和 AI Town 体验预告**：`edgarhnd` 预览了即将推出的 AI 真人秀迭代版本，该版本将允许公众与 AI Town 互动，暗示了增强的共享体验。 - **远程 LLM 部署的挑战与解决方案**：成员们讨论了部署本地语言模型服务器（`ollama`）并将其连接到远程 convex 后端的复杂性和障碍，`utensil_95057` 最终通过更新到最新的 Ollama 版本并使用 `ssh` 隧道使其成功运行。
      提到的链接：
      --- **AI Stack Devs (Yoko Li) ▷ #[local-ai-stack](https://discord.com/channels/1122748573000409160/1168947823920812125/1236174462051942410)** (1 messages): - **为旧笔记本电脑推出 llama-farm**: 一位成员宣布发布 `llama-farm`，它允许在旧笔记本电脑上运行 **Ollama**，为面向公众的 AI 应用提供 LLM 任务服务。正如 [GitHub](https://github.com/get-convex/llama-farm-chat) 上所述，该设置通过在其他机器上运行客户端进行扩展，且不需要代理或暴露在公共互联网中。 **提及的链接**: GitHub - get-convex/llama-farm-chat: 使用本地托管的 LLM 为你的云端托管 Web 应用提供支持: 使用本地托管的 LLM 为你的云端托管 Web 应用提供支持 - get-convex/llama-farm-chat --- **AI Stack Devs (Yoko Li) ▷ #[paper-spam](https://discord.com/channels/1122748573000409160/1227492197541220394/)** (1 messages): Deforum 每日论文：论文现在将发送至 <#1227492197541220394> --- **AI Stack Devs (Yoko Li) ▷ #[ai-raspberry-pi](https://discord.com/channels/1122748573000409160/1234912245415280742/)** (1 messages): jakekies: ?? --- **LAION ▷ #[general](https://discord.com/channels/823813159592001537/823813160075132991/1235934782727127081)** (59 messages🔥🔥): - **探索 CLIP 和 T5 的组合**: 有一场关于使用 CLIP 和 T5 编码器进行模型训练的 [讨论](https://old.reddit.com/r/StableDiffusion/comments/1cgr74j/april_30th/l2bxv66/)；一位成员提到了 CLIP 的 Prompt 遵循问题，并考虑仅使用 T5，而另一位成员则强调了过去同时使用这两种编码器的成功经验。 - **改进小型模型的考虑因素**: 提到了增强小型模型实用性的重点，并指出了 400M DeepFloyd 以及准备发布 8B 模型所面临的挑战。 - **对 SD3 策略的质疑**: 来自 Stability AI 的评论建议逐步发布 SD3 模型，从较小的模型开始到较大的模型，这引发了关于这是否是一种高效方法的讨论，特别是考虑到社区的期待。 - **在训练中使用 LLama Embeds 的潜力**: 关于在训练中使用 LLama embeds 代替 T5 的优点的对话，并分享了一个名为 [LaVi-Bridge](https://github.com/ShihaoZhaoZSH/LaVi-Bridge) 的示例桥接链接，强调了现代应用和效率。 - **图像生成和 LLM 领域的进展比较**: 成员们比较了图像生成和 LLM 领域开源模型的现状，讨论了新模型的适配，并提到了一个新的 CogVL 跑马灯。
      提及的链接:
      --- **LAION ▷ #[research](https://discord.com/channels/823813159592001537/824374369182416994/1235953963652743298)** (5 messages): - **真实世界数据集与合成数据集的疑问**: 一位成员对为什么在实验中使用合成数据集而不是像 MNIST、CIFAR 或 ImageNet 这样的标准数据集表示好奇。人们对那些优先考虑可解释性但可能无法解决实际任务的方法的现实世界适用性表示担忧。 - **讨论可解释性演示**: 有人提到，在实验中使用合成数据集是为了展示正在开发的方法在可解释性方面的表现。 - **分享 StoryDiffusion 资源**: 分享了 [StoryDiffusion 网站](https://storydiffusion.github.io/) 的链接，其中可能包含有关 AI 可解释性的相关信息或资源。 - **函数表示中的复杂性优于简单性**：一位成员澄清说，研究有时旨在通过函数逼近复杂的数学表示，而不是通常与视觉识别相关的“简单”模板化任务。 --- **LangChain AI ▷ #[general](https://discord.com/channels/1038097195422978059/1038097196224086148/1235950376109477979)** (45 条消息🔥): - **LLM 与数据库接口引发好奇**：参与者讨论了是将数据库数据转换为自然语言文本，还是使用 LLM 将自然语言转换为数据库查询。讨论还考虑了在这种背景下图形数据库与关系型数据库的适用性。 - **Node.JS 难题与 Langchain 入门**：一位用户在 NodeJS 中寻求解析用户问题和提取 JSON 数据的帮助，而另一位用户在使用 FAISS 与 Langchain 时遇到错误，但通过升级到最新版本解决了该问题。 - **通过 AI 执行代码**：社区成员交流了关于通过 AI Agent 执行生成的代码的见解，建议包括使用 Open Interpreter 以及创建如 `CLITOOL` 之类的自定义工具。 - **Langchain 集成查询**：用户询问了 Langchain 对 Microsoft Graph 的支持情况、在工作中使用类似 kappa-bot-langchain 的 API，以及使用 Langsmith 免费版时是否存在上传大小限制。 - **新进展与自定义工具讨论**：关于 GPT2 问题后 ChatGPT 响应变化的猜测不断出现，对话围绕在 Langchain 社区内创建和共享自定义工具展开。
      提到的链接:
      --- **LangChain AI ▷ #[share-your-work](https://discord.com/channels/1038097195422978059/1038097372695236729/1235917336821891092)** (6 条消息): - **Java 加入 LangChain 家族**：**LangChain** 现在通过 [langchain4j](https://github.com/langchain4j/langchain4j)（LangChain 库的 Java 移植版）面向 Java 开发者开放，为 AI 助手工具集提供了扩展的应用生态系统。 - **Dragonfly 提升 LangChain 缓存能力**：**LangChain** 与高性能内存数据存储 **Dragonfly** 的集成展示了在聊天机器人上下文管理方面的显著改进，详情见新发布的 [博客文章](https://www.dragonflydb.io/blog/efficient-context-management-in-langchain-with-dragonfly)。 - **利用 Langchain 实现去中心化搜索**：一项新的去中心化搜索功能正在开发中，它利用用户拥有的索引网络来提供强大的搜索能力，开发者在最近的一条 [推文](https://twitter.com/indexnetwork_/status/1786110169396429093) 中记录了所有这些内容。 - **OpenGPTs-platform 亮相**：一个名为 [OpenGPTs-platform](https://github.com/OpenGPTs-platform) 的 GPT Store 开源替代方案已经发布，其特点是包含 'retrieval' 和 'web_retrieval' 等工具，演示视频已上传至 [YouTube](https://www.youtube.com/watch?v=yPdIEKb3jWc)。该项目旨在通过模块化方法复制并扩展 GPT Store 的功能，并通过 [OpenGPTs Discord](https://discord.gg/23aZEjyjp2) 与社区互动。 - **认识 everything-ai：全能 AI 助手**：更名后的 v1.0.0 **everything-ai** 本地助手提供从与 PDF 和模型聊天到总结文本和生成图像的一系列任务。这个多容器 Docker 应用程序专注于通用性和隐私，其功能和快速入门文档可在其 [GitHub 页面](https://astrabert.github.io/everything-ai) 上找到。 - **高级研究助手招募 Beta 测试人员**：招募 Beta 测试人员体验一个高级研究平台，该平台可访问包括 GPT-4 Turbo 和 Mistral Large 在内的多个 AI 模型。在 [Rubiks.ai](https://rubiks.ai/) 上使用代码 `RUBIX` 可免费获得两个月的高级版会员。该优惠包括为增强研究能力而量身定制的额外模型和工具。
      提到的链接：
      --- **LangChain AI ▷ #[tutorials](https://discord.com/channels/1038097195422978059/1077843317657706538/1236245724430077963)** (2 messages): - **使用 Llama 3 的 RAG 技术**：一位用户分享了一个题为“[使用 SVM 且无需 Vectorstore 的 Llama 3 RAG](https://www.youtube.com/watch?v=vvW2dwvNm2Q)”的 YouTube 视频，提供了关于使用 **Llama 3** 配合相似度测量分类器进行 *Retrieval-Augmented Generation* (RAG) 且无需 Vectorstore 的见解。 - **探索将 LangGraph 作为 AgentExecutor**：另一项贡献是一个 [YouTube 视频](https://www.youtube.com/watch?v=UcD42NA2WoI)，展示了 **LangGraph** 与 **LangChain Core** 组件之间的对比，并提出了 AgentExecutor 实现方面的进展。
      提到的链接：
      --- **tinygrad (George Hotz) ▷ #[general](https://discord.com/channels/1068976834382925865/1068976834928193609/1236088423656456243)** (17 messages🔥): - **在 Clojure 中探索符号编程**：一位用户提到通过悬赏任务来熟悉 *tinygrad*，发现 **Clojure** 中的符号编程比 Python 更容易。 - **Julia 与 Clojure 之争**：一位成员认为 **Julia** 在符号编程方面优于 *Clojure*，并对其在 ML/AI 领域缺乏普及度表示惊讶。 - **寻求 tinygrad Bug 处理指导**：用户被引导使用 GitHub 的 issues 标签或 Discord 上的 bug 报告频道来报告 *tinygrad* 的 Bug。 - **理解 tinygrad 的 UOps 表示法的困难**：一位成员表示难以理解 *tinygrad* 的文本 UOps 表示法，并建议将其更改为更接近 LLVM IR 的格式以提高可读性，这引发了关于 phi 的格式和使用的讨论。 - **以静态单赋值 (SSA) 形式表示 UOps**：讨论继续解释了 UOps 作为 SSA 的一种形式，为什么 phi 位于块的末尾，并建议可能提交一个 Pull Request (PR) 来提出改进方案。 --- **tinygrad (George Hotz) ▷ #[learn-tinygrad](https://discord.org/channels/1068976834382925865/1070745817025106080/1236700433003581541)** (12 messages🔥): - **Tinygrad 在 Qualcomm GPU 上表现出色**：Tinygrad 通过在计算中使用 textures 和 pixel shaders，针对 Qualcomm GPU 进行了优化。正如 terafo 所解释的，整个代码库中分布着以 **image datatype** 进行的数据管理。 - **在 Qualcomm 上探索 Tinygrad**：在 Qualcomm 智能手机上运行 Tinygrad 是可行的，且不需要付出巨大努力，除非需要 **DSP support**，这会显著增加复杂性。 - **关于 Tinygrad 符号操作的见解**：一位成员分享了他们帖子的链接，该帖子详细分解了 Tinygrad 中的符号均值计算（symbolic mean computation），为其他使用或学习 Tinygrad 的人提供了清晰的见解。点击[此处](https://github.com/mesozoic-egg/tinygrad-notes/blob/main/symbolic-mean.md)查看他们的解释。 - **Tinygrad 中的 CPU 操作是顺序的而非并行的**：George Hotz 确认 Tinygrad 是**单线程**的，在 CPU 计算期间不会发生并行线程操作。 - **对 Tinygrad 中 Tensor 操作的疑问**：Cappuchinoraro 询问了 `matmul` 函数的行为以及在 Tinygrad 操作中转置 Tensor 的影响。 **提到的链接**：tinygrad-notes/symbolic-mean.md at main · mesozoic-egg/tinygrad-notes：Tinygrad 教程。通过在 GitHub 上创建账号为 mesozoic-egg/tinygrad-notes 的开发做出贡献。 --- **Mozilla AI ▷ #[llamafile](https://discord.com/channels/1089876418936180786/1182689832057716778/1236429992452292679)** (25 messages🔥): - **解决 json_schema 兼容性问题**：一位成员遇到了 `json_schema` 无法在 **llamafile 0.8.1** 上运行的问题；另一位成员建议使用 `--unsecure` 标志作为潜在的修复方案，并提到计划在即将发布的版本中解决此问题。 - **寻找轻量级模型**：发起了一场关于寻找能在低配置下运行的模型的讨论。推荐了 **phi 3 mini**，而当 phi 3 mini 运行速度太慢时，建议使用更小的模型 **Rocket-3B** 以获得更好的速度。 - **在 llamafile 中利用 ollama 缓存**：一位成员询问 **llamafile** 是否可以使用存储在 **ollama cache** 中的模型以防止重复下载，另一位成员确认如果 GGUF 文件受 llamafile 支持，这是可行的。 - **llamafile 与 AutoGPT 的集成**：讨论了一个关于将 **llamafile** 作为 LLM provider 集成到 **AutoGPT** 的 Pull Request 反馈请求。有人分享了设置此配置的说明链接 ([AutoGPT/llamafile-integration](https://github.com/Mozilla-Ocho/AutoGPT/tree/draft-llamafile-support/autogpts/autogpt/llamafile-integration))，正在等待维护者的回复，然后再进行进一步的代码编写。 - **识别并使用正确的本地模型**：在讨论澄清了哪些文件是实际模型、哪些是元数据后，一位用户成功地使用本地缓存的 **.gguf** 文件运行了 **llamafile**，展示了实时的故障排除和同行支持。
      提到的链接：
      --- **DiscoResearch ▷ #[mixtral_implementation](https://discord.com/channels/1178995845727785010/1182759434326396998/1236622793127493643)** (7 messages): - **Mixtral Transformers Bug 影响性能**：有人指出 **mixtral transformers** 实现中存在 Bug，导致过去 Mixtral 的微调（finetunes）性能不佳。通过 [Twitter](https://twitter.com/kalomaze/status/1786869036946522256)、[Gist](https://gist.github.com/kalomaze/661b79095fdd91df8a84802f7cb6f26a) 以及 [GitHub 上的 Pull Request](https://github.com/huggingface/transformers/pull/30658) 分享了关键问题和关于此问题的进一步讨论。 - **对 Mixtral 问题范围的不确定性**：成员们质疑 Mixtral 的问题是仅限于 *training* 还是也影响 *generation*。目前尚未达成明确共识，强调了进一步澄清的必要性。 - **问题解决进行中**：一名成员提到了一场正在进行的对话，并指向了与另一位 Discord 用户的讨论，暗示目前正在努力定位并解决 Mixtral 的问题。然而，并未提供该对话的具体细节。 - **Bug 修复似乎陷入停滞**：一位成员对现状表示幽默，暗示他认为 Mixtral 一直以来就存在已知问题。这种插话反映出用户之间存在一种“问题早就在预料之中”的看法。 - **Pull Request 被拒绝增加了 Mixtral 的困惑**：提到的用于修复 Mixtral Bug 的 Pull Request 已被*关闭/拒绝*，这为这些问题的解决状态增添了另一层不确定性。此次拒绝对比 Mixtral 实现的影响未得到进一步讨论。 --- **DiscoResearch ▷ #[general](https://discord.com/channels/1178995845727785010/1182877486854451271/1235956851133386872)** (3 条消息): - **量化版 LLaMA-3 的性能下降**：一篇 Reddit 帖子[讨论了量化对 LLaMA-3 的影响](https://www.reddit.com/r/LocalLLaMA/comments/1cetn9z/quantization_seems_to_hurt_the_quality_of_llama_3/)，认为与 LLaMA-2 相比，LLaMA-3 的性能退化更为显著。一项关于 [LLaMA-3 低比特量化的研究](https://arxiv.org/abs/2404.14047)可能会为 LLM 压缩面临的挑战提供额外的见解。 - **Meta 忽略了 Chinchilla 的教训？**：一位成员指出，Meta 尽管有 *Chinchilla* 的教训，但仍采取扩展 LLaMA 的方法，这可能是为什么 LLaMA-3 模型在精度降低时信息损失更严重的原因。 - **修复补丁正在开发中**：一个 GitHub Pull Request 为 LLaMA-3 中观察到的量化问题提供了可能的修复方案，包括额外的统计数据和文档（[PR #6936](https://github.com/ggerganov/llama.cpp/pull/6936#issuecomment-2083214112)），以及围绕预分词 BPE 处理的讨论（[Issue #7088](https://github.com/ggerganov/llama.cpp/issues/7088#issuecomment-2094933215)）。
      提到的链接：
      --- **DiscoResearch ▷ #[discolm_german](https://discord.com/channels/1178995845727785010/1197630242815213618/1237016176429629501)** (3 条消息): - **揭晓当前使用的模型**：频道内的讨论透露，**8x22b Mistral** 是目前一位成员用于其任务的模型。未提供关于性能或具体应用细节的进一步信息。 --- **Interconnects (Nathan Lambert) ▷ #[news](https://discord.com/channels/1179127597926469703/1179128538679488533/1236328226222116965)** (3 条消息): - **ElevenLabs 逼真 AI 语音背后的故事**：[《大西洋月刊》](https://www.theatlantic.com/technology/archive/2024/05/elevenlabs-ai-voice-cloning-deepfakes/678288/)的一篇文章详细介绍了名为 **ElevenLabs** 的初创公司如何开发出一些最令人信服的 AI 语音克隆技术。作者分享了使用该服务克隆自己声音的个人体验。 - **付费墙：现代的烦恼**：一位成员对遇到付费墙表示沮丧，表示无法阅读《大西洋月刊》关于 **ElevenLabs** 文章的完整内容。 - **ElevenLabs：疯狂的存在**：同一位成员对 **ElevenLabs** 的存在发表了评论，称这家初创公司能够创造出如此逼真的 AI 生成语音简直是“疯狂”。 **提到的链接**：ElevenLabs 正在构建一支语音克隆大军：一家微型初创公司制造了一些最具说服力的 AI 语音。它的创造者们准备好迎接他们正在释放的混乱了吗？ --- **Interconnects (Nathan Lambert) ▷ #[ml-drama](https://discord.com/channels/1179127597926469703/1181746144821387334/1236002486280781904)** (2 条消息): - **论文跳过 RewardBench 评分**：一篇新发表在 [arXiv 上的论文](https://arxiv.org/abs/2405.01535) 忽略了报告 *RewardBench* 评分，因为结果不理想，这引发了一些学术界的冷嘲热讽，并配上了 <:facepalm:1207415956020797521> 表情符号。 - **引入 Prometheus 2 LM 用于无偏见评估**：该论文介绍了 **Prometheus 2**，这是一个开源的评估器语言模型，声称与人类和 **GPT-4 的判断**高度一致，并解决了影响专有 LM 的透明度、可控性和成本问题。 - **希望实现并测试 Prometheus 2**：一位成员表示渴望实现 **Prometheus 2**，以便通过实际演示来挑战和验证论文中的主张。 **提到的链接**：Prometheus 2: An Open Source Language Model Specialized in Evaluating Other Language Models：GPT-4 等专有 LM 通常被用来评估各种 LM 的响应质量。然而，出于对透明度、可控性和成本的担忧，强烈促使了... --- **Interconnects (Nathan Lambert) ▷ #[random](https://discord.com/channels/1179127597926469703/1183121795247779910/1236040686512377937)** (2 条消息): - **势不可挡的成功令人侧目**：一位成员用 *“他不能一直这样逍遥法外”* 的措辞表达了惊讶和一丝担忧。 - **关于 John 回复的不确定性**：另一位成员反思了与 *“john”* 的对话，强调了对一个提议的模棱两可的回答，并评论道：*“该死，所以这就是为什么 john 只对我说了个也许，哈哈。”* --- **Interconnects (Nathan Lambert) ▷ #[rl](https://discord.com/channels/1179127597926469703/1208183216843005962/1235969401660903585)** (4 条消息): - **思考经典 RL 中的未知领域**：一位成员询问是否有关于经典 RL 某个特定方面的研究，引发了好奇心，暗示了潜在的知识空白或未来探究的领域。 - **Value Function：不同方法中的可能关键**：另一位成员建议探索 **PPO value function** 与 **DPO 的 credit assignment** 之间的联系，暗示这可能会在 Reinforcement Learning 策略中产生有趣的见解。 - **Value Function 在 Planning 中的重要性**：后续讨论强调了 Value Function 的重要性，特别是在 Planning 而非经典 Reinforcement Learning 的背景下，突出了其关键作用。 --- **LLM Perf Enthusiasts AI ▷ #[prompting](https://discord.com/channels/1168579740391710851/1179271229593624677/1237119509165248593)** (7 条消息): - **探索 Anthropic 的 Prompt 生成器**：提到在 **Anthropic console** 中可以使用一个新的 **prompt generator tool**。 - **礼貌改写的结果**：一位成员测试了该工具，要求它 *用更礼貌的语言改写一个句子*，并分享说结果 *还不错*。 - **解码 System Prompt**：正在进行从工具中提取 System Prompt 的工作，其中 **k-shot examples** 是重要组成部分，包括一个著名的 *苏格拉底式数学导师* 示例。 - **提取的数据不完整**：尝试提取的成员报告说，Prompt 内容非常广泛，以至于在中间被截断了，特别是在冗长的数学导师示例部分。 - **承诺分享完整 Prompt**：该成员承诺一旦成功提取并整理好，将在这里分享完整的 System Prompt。 --- **Skunkworks AI ▷ #[datasets](https://discord.com/channels/1131084849432768614/1131669182124138616/1236350458663141386)** (1 条消息): - **寻找虚构数据**：一位成员表示需要一个**充满虚假信息的数据集**，目的是在 **Llama 3** 和 **Phi3** 等模型上实验 Fine-tuning 技术。他们表示，即使是完全虚假的数据对于他们的研究也是可以接受的。 --- **Skunkworks AI ▷ #[off-topic](https://discord.com/channels/1131084849432768614/1140423597454807179/1235948611292893263)** (2 条消息): - **提供快速算力资助**：一位成员为具有启发性的 Skunkworks AI 项目提供**快速算力资助 (fast compute grants)**，表达了支持创新的热忱。支持详情见 [推文](https://twitter.com/PrimeIntellect/status/1786386588726960167)。 - **分享 AI 视频资源**：分享了一个与人工智能相关的 YouTube 视频链接，作为社区成员的潜在资源或关注点。视频可以在[这里](https://www.youtube.com/watch?v=vvW2dwvNm2Q)观看。 --- **Datasette - LLM (@SimonW) ▷ #[llm](https://discord.com/channels/823971286308356157/1128504153841336370/1236429191092899941)** (3 messages): - **LLM 在错误摘要方面表现出色**：一位成员分享了一种使用 LLM 总结错误的有效方法；他们提供了一个通过管道（pipe）传输到 LLM 的 `conda activate` 命令示例。建议将其包含在 [LLM README](https://github.com/simonw/llm/blob/main/README.md) 中。 - **利用 LLM 进行错误评估的 Bash 函数**：提出了一个新的 `llm-err` bash 函数，通过将命令输出直接通过管道传输到 LLM 来帮助评估错误。该函数接受一个命令作为参数，并使用 LLM 来指明遇到的任何错误的具体原因。 --- **Cohere ▷ #[collab-opps](https://discord.com/channels/954421988141711382/1218409745380147320/1236060159990566942)** (2 messages): - **向德克萨斯州奥斯汀社区致意**：一位成员向位于**德克萨斯州奥斯汀 (Austin, TX)** 的所有人发出了友好的问候。 - **处于融资阶段的法国 AI 初创公司**：来自法国的 **Vivien** 介绍了 **Finexov** ([Finexov](https://www.finexov.com/))，这是一个简化 **R&D** 资助机会识别和申请生成的 AI 平台。该平台已经发布，并建立了合作伙伴关系，获得了 **Founder Institute** ([FI.co](https://fi.co/)) 的支持。 - **寻找 CTO 联合创始人**：Vivien 正在寻找一位具有深厚 **ML** 背景、并有志于建立和领导团队的 **CTO 联合创始人**。潜在的 CTO 应常驻欧洲或中东，具备法语能力者优先，并准备好进行包括融资在内的高强度工作。 - **迪拜会面机会**：6 月初在**迪拜 (Dubai)** 有见面机会，Vivien 邀请感兴趣的人士联系并进行潜在的交流。 **提到的链接**：Founder Institute: 全球最大的种子前初创企业加速器。：未找到描述。 --- **AI21 Labs (Jamba) ▷ #[jamba](https://discord.com/channels/874538902696914944/1222916247063232553/1236029165447413770)** (2 messages): - **探索新高度**：AI21 Labs 的员工在谈到其技术的某些方面时表示：“我们仍在探索，但我们可以达到更高的高度”，并邀请社区成员通过私信讨论他们的使用案例和想法。 --- **Alignment Lab AI ▷ #[general-chat](https://discord.com/channels/1087862276448595968/1095458248712265841/1235947724063375370)** (1 messages): - **提供快速算力资助**：一位成员分享了一篇 [Twitter 帖子](https://twitter.com/PrimeIntellect/status/1786386588726960167)，宣布为有需要的人提供**快速算力资助 (fast compute grants)**。该推文似乎是在征集获取算力资源的申请或提名。
← 返回首页