AI News
OpenAI 开发者大会:Apps SDK、AgentKit、Codex 正式版 (GA)、GPT-5 Pro 以及 Sora 2 API。
OpenAI 在其开发者大会(DevDay)上展示了多项重大产品发布,包括 Apps SDK、AgentKit,以及现已正式商用(GA)并具备 SDK 和企业级功能的 Codex。
他们推出了多款新模型,如 gpt-5-pro、gpt-realtime-mini-2025-10-06、gpt-audio-mini-2025-10-06、gpt-image-1-mini,以及包含专业版的 sora-2。
Apps SDK 支持在 ChatGPT 内部嵌入交互式应用,首批合作伙伴包括 Canva、Figma、Zillow 和 Coursera。AgentKit 为构建和部署生产级智能体(agents)提供了一套全栈方案,并配备了 ChatKit 和 Guardrails 等工具。Codex 支持语音和控制器驱动的编程,被认为是 OpenAI 内部保持高速开发交付的功臣。
此外,GPT-5 Pro 的定价也已公布:每百万 token 输入为 15 美元,输出为 120 美元。“OpenAI 将 ChatGPT 变成了一个应用平台”以及“AgentKit 在不到 8 分钟内构建了一个可运行的智能体”成为了本次大会的亮点。
OpenAI 可能就是你所需的一切。
2025年10月3日至10月6日的 AI 新闻。我们为你查看了 12 个 subreddit、544 个 Twitter 账号和 23 个 Discord(196 个频道,20085 条消息)。预计节省阅读时间(按每分钟 200 词计算):1496 分钟。我们的新网站现已上线,支持完整的元数据搜索,并以精美的 vibe coded 风格展示所有往期内容。请访问 https://news.smol.ai/ 查看详细的新闻分类,并在 @smol_ai 上向我们提供反馈!
OpenAI 的 GPT5 在总结今天的 OpenAI DevDay 活动方面表现出色,因此我们直接沿用了它为今天邮件拟定的标题。我们将在明天的 Latent Space 播客中与团队进行更深入的分析,除此之外,以下是不容错过的链接:
OpenAI DevDay 产品/API/SDK 发布
- 与 Sama 进行的 50 分钟开幕主题演讲:https://www.youtube.com/watch?v=hS1YqcewH0c&t=1382s
- 与 Andrew Mayne 进行的 1 小时 OAI 播客:https://www.youtube.com/watch?v=QIdUllqmuls
- 官方网站:https://openai.com/devday
- 在 ChatGPT 中引入应用以及全新的 Apps SDK (博客):https://openai.com/index/introducing-apps-in-chatgpt
- Apps SDK (文档):https://developers.openai.com/apps-sdk
- 1 分钟 YouTube 预告片:https://www.youtube.com/watch?v=2C4Cs6503gw
- 推出 AgentKit (博客):https://openai.com/index/introducing-agentkit
- 5 分钟 Agent Builder 介绍:https://www.youtube.com/watch?v=44eFf-tRiSg
- Agents (文档):https://platform.openai.com/docs/guides/agents/agent-builder
- ChatKit Studio (应用):https://chatkit.studio/ (playground, widget builder, demo)
- ChatKit 文档:https://platform.openai.com/docs/guides/chatkit
- ChatKit Python:https://openai.github.io/chatkit-python/
- ChatKit JS:https://openai.github.io/chatkit-js/
- Guardrails (文档):https://guardrails.openai.com/docs
- Evals (文档):http://platform.openai.com/docs/guides/evaluation-getting-started
- Codex 现已正式发布 (GA) (博客):https://openai.com/index/codex-now-generally-available
- Codex SDK (文档):https://developers.openai.com/codex/sdk
- 服务健康状态 (Service Health) 仪表板:https://platform.openai.com/settings/organization/service-health
- GitHub 项目:https://github.com/orgs/openai/repositories?q=apps-sdk+OR+chatkit+OR+guardrails (apps, chatkit, guardrails)
新发布的模型
- gpt-5 pro (模型):https://platform.openai.com/docs/models/gpt-5-pro
- gpt-realtime-mini-2025-10-06 (模型):https://platform.openai.com/docs/models/gpt-realtime-mini (降价 70%)
- gpt-audio-mini-2025-10-06 (模型):https://platform.openai.com/docs/models/gpt-audio-mini
- gpt-image-1-mini (模型):https://platform.openai.com/docs/models/gpt-image-1-mini (降价 80%)
- 使用 Sora 生成视频 (文档):https://platform.openai.com/docs/guides/video-generation
- Sora 2: Prompting Guide (cookbook):https://github.com/openai/openai-cookbook/blob/16686d05abf16db88aef8815ebde5c46c9a1282a/examples/sora/sora2_prompting_guide.ipynb#L7
- sora-2 (模型):https://platform.openai.com/docs/models/sora-2
- sora-2-pro (模型):https://platform.openai.com/docs/models/sora-2-pro
AI Twitter 回顾
OpenAI DevDay: Apps SDK, AgentKit, Codex GA, GPT‑5 Pro 和 Sora 2 API
- OpenAI 将 ChatGPT 转型为一个应用平台。全新的 Apps SDK(基于 MCP 构建)允许合作伙伴直接在 ChatGPT 中嵌入完整的交互式应用,支持自定义 UI、操作以及即将推出的变现功能。早期合作伙伴包括 Canva、Figma、Zillow 和 Coursera。查看 OpenAI 主旨演讲中的发布和现场演示:ChatGPT 内部的应用 @OpenAI,SDK 预览 @OpenAIDevs,以及 “DevDay ships” 汇总 @edwinarbus。
- AgentKit 是 OpenAI 的端到端 Agent 技术栈——包含可视化 Agent Builder、ChatKit UI、Guardrails、Evals 和 Connectors——用于构建、部署和强化生产级 Agent。在舞台现场,OpenAI 在 8 分钟内构建了一个可运行的 Agent @gdb。文档与公告:AgentKit,博客。值得注意的是,内置的 Prompt 优化器符合社区最佳实践(例如 GEPA)@dbreunig。
- Codex 现已正式发布 (GA),配备 SDK、Slack 集成以及用于代码审查和 CLI/IDE 工作流的企业级控制/分析功能(GA 公告)。现场演示展示了由语音+控制器驱动的 Codex 编程 @gdb。团队将交付速度归功于 Codex(在某些内部构建中,80% 的 PR 由其编写)@stevenheidel。
- 新模型/API 及规模统计数据:
- GPT-5 Pro 已加入 API,用于更复杂的推理;现场及社区观察者分享的价格为:每 100 万 Token 输入 $15 / 输出 $120 @OpenAIDevs,@scaling01。
- gpt-realtime-mini 提供语音对语音功能,成本比 gpt-realtime 低约 70% @juberti。
- Sora 2 和 Sora 2 Pro 现已可通过 API 访问(支持声音、重混、时长控制)。价格示例:Sora 2 为 $0.10/秒 (720p);Pro 为 $0.30/秒 (720p) / $0.50/秒 (1024p) @scaling01。Mattel 已经在使用 Sora 2 进行“从草图到概念”的循环设计 @gdb。
- 平台指标:400 万开发者,8 亿 ChatGPT 周活跃用户,通过 API 每分钟处理超过 60 亿 Token @kevinweil,@nickaturley。新增服务健康状态仪表板,以及响应速度提升约 40% 的 GPT-5 优先级层级 @OpenAIDevs。
算力和推理基础设施:OpenAI × AMD、NVIDIA 技术栈以及 vLLM
- OpenAI 和 AMD 宣布了一项多年计划,将部署 6 GW 的 Instinct GPU,AMD 向 OpenAI 授予了高达 1.6 亿股的认股权证,根据部署/价格里程碑行权。受此消息影响,AMD 股价跳涨;OpenAI 强调这是在持续购买 NVIDIA 产品基础上的增量 @sama,@LisaSu,@TheRundownAI,@gdb。
- NVIDIA 的 B200 现已在 Hugging Face Inference Endpoints 上可用 @ClementDelangue。NVIDIA 的 TensorRT-LLM 发布 v1.0 版本,具有 PyTorch 原生核心、CUDA Graphs、投机解码 (speculative decoding) 以及 GB200 支持——目前支持 Llama3、DeepSeek V3/R1、Qwen3 等模型 @ZhihuFrontier。
- vLLM 继续为前沿的 RL 循环提供支持(例如具有运行中权重更新和陈旧 KV cache 混合功能的 PipelineRL)@vllm_project,@DBahdanau。
中国模型激增:Qwen3-VL、GLM-4.6、混元 (Hunyuan)
- Qwen 发布了 Qwen3‑VL‑30B‑A3B (Instruct & Thinking):采用 MoE 架构,激活参数约为 3B,支持 256k–1M 上下文及多语言(32 种语言),旨在达到与 GPT‑5‑Mini/Claude Sonnet 相当的水平,并提供 FP8 变体。相关资源涵盖对话、GitHub/cookbooks、API、ModelScope、Hugging Face,以及一个实时的 HF Space @Alibaba_Qwen, HF demo。Nexa 强调了首日即支持 MLX @nexa_ai。
- 智谱的 GLM‑4.6 目前在 LMArena 中位列开源模型第一,总榜第四,即使在没有“风格控制”的情况下也有强劲表现 @arena, @jietang。生产状态:由于 CPU 服务器受到攻击,z.ai 曾出现短暂宕机(现已解决) @Zai_org。从业者认为 GLM‑4.5/4.6 是极具价值的 Claude 风格替代方案,具有宽松的限制和低廉的成本 @Tim_Dettmers。
- 腾讯的 HunyuanImage 3.0 在 T2I Arena 中跃升至总榜第一和开源第一,取代了之前的领先者 @arena, @TencentHunyuan。Hunyuan Vision 1.5 Thinking 进入 Vision Arena 并列第三 @arena。
RL 与后期训练:LoRA 胜出、抽象化、带有 RL 信号的预训练
- 用于 RL 的 LoRA 持续赢得关注。John Schulman 强调了多个复现案例,在这些 RL 设置中,LoRA rank=1 的效果与全量微调(full fine‑tuning)非常接近;TRL 发布了一个名为 “LoRA without regret” 的参考复现 @johnschulman2, @ClementDelangue。相关讨论分析了为什么 RL 更新存在于低维子空间中(这对 LoRA 有利) @nrehiew_。
- RLAD(强化学习与抽象演绎)将“如何推理”(短自然语言提示)与“如何回答”分离。据报道,与 long‑CoT 基准相比,AIME 2024 提升了 11%,AIME 2025 提升了 9%,在相同或更低的序列预算下,比标准长链方法提升了约 44% @TheTuringPost。
- NVIDIA 的 RLP(强化学习预训练)在预训练期间将思维链(CoT)视为动作,并使用无验证器的密集奖励,在数学/科学领域的 8 个基准测试中报告了显著提升:Qwen3‑1.7B‑Base 提升 24%,Nemotron‑Nano‑12B‑Base 提升 43% @ahatamiz1。
- RL 基础设施正在快速演进:基于 vLLM 的 PipelineRL 支持 KV 复用的实时更新 @vllm_project;应用于矩阵优化器的算法方差缩减(Muon 上的 MARS‑M) @YIFENGLIU_AI。RL 趋势和基础的整理:TD learning 解释 @TheTuringPost,新兴 RL 趋势列表 @TheTuringPost,GAIN‑RL 数据课程加速 @DeepLearningAI。
Agent、评估以及 OpenAI 之外的工具
- Anthropic 开源了 Petri,这是一个场景驱动的对齐审计工具包,内部用于 4.5 的对齐测试(如谄媚、欺骗),并被 AISec Inst. 改编用于外部评估 @AnthropicAI, @sleepinyourhat。
- Google DeepMind 的 CodeMender Agent 已经向主要的 OSS 仓库提交并合并了 72 个安全修复;研究细节即将公布 @GoogleDeepMind, @ralucaadapopa。
- LangChain 发布了一个精选的 LangGraph.js 示例库,以及一个集成 SingleStore 的 Agentic 教程 @LangChainAI, @LangChainAI。Comet 继续推进用于长媒体分析的“AI 浏览器”工作流 @AravSrinivas。
- 平台动态:Yupp 增加了 GPT‑5 Pro 和 Qwen3‑VL‑30B‑A3B,并提供 “Help Me Choose” 评估摘要 @yupp_ai。
具身智能与视频生成
- 特斯拉的 Optimus 持续取得快速的能力提升——现在正在“学习功夫”——其领导层暗示将统一自动驾驶和人形机器人技术栈 @elonmusk, @aelluswamy。Figure 报告称在宝马 X3 生产线上进行了为期五个月、每天 10 小时的人形机器人作业(预告了声称达到 2050 年水平的演示视频;作业更新 @adcock_brett)。
- 长视频扩散缩放:字节跳动的 Self‑Forcing++ 在没有长视频教师模型的情况下,可生成长达 4 分 15 秒的视频,并保持了保真度和一致性 @HuggingPapers。Synthesia 3.0 推出了带有化身/语音同步功能的交互式“视频 Agent”,用于培训和支持场景 @lax97981。
- Sora 2 安全控制:出镜者所有权限制、更清晰的水印以及审核机制微调;账号解绑修复已上线 @billpeeb, @turtlesoupy。Sora 2/2 Pro 现已加入 API(见上文)。
热门推文(按互动量排序)
- 特斯拉 Optimus “学习功夫”演示 @elonmusk
- “你现在可以在 ChatGPT 中与应用对话” @OpenAI
- Sora 更新串(Sam Altman) @sama
- Figure:在宝马 X3 生产线上工作 5 个月 @adcock_brett
- Anthropic 的帽子/书籍快闪店 @signulll
AI Reddit 摘要
/r/LocalLlama + /r/localLLM 摘要
1. 社区供应商感谢贴(图片)
- 目前社区最大的供应商,感谢他们 (热度: 2530): 这是一个非技术性的梗图贴,赞扬了中国的 LLM 供应商——GLM(智谱 AI/THUDM)、阿里巴巴的 Qwen 和 DeepSeek——认为他们通过提供强大的模型和低成本的访问,成为目前社区最大的贡献者,这与西方那些更封闭、成本更高的产品形成鲜明对比。评论区的背景将这些群体描述为 AI 访问权限的民主化推动者,对比了 OpenAI 历来不透明的做法和产品化路线;帖子中未提供 Benchmark 或实现细节。 热门评论称赞 GLM/Qwen/DeepSeek 是“给人类的礼物”,认为 OpenAI 在安全的名义下优先考虑保密性,并声称如果没有这些供应商,开发者为获得类似 GPT 的访问权限将支付高得多的费用。
- 评论者强调了中国的开源权重(open-weight)模型系列——GLM (THUDM/智谱 AI)、Qwen (阿里巴巴) 和 DeepSeek——由于发布了权重、详细的模型卡(model cards)和具有竞争力的 Benchmark,它们已成为目前社区的主力军。它们经常在社区排行榜(MMLU/GSM8K/HumanEval)上被引用,作为封闭 API 的强力开源替代方案;参见 Open LLM Leaderboard: https://huggingface.co/spaces/HuggingFaceH4/open_llm_leaderboard 以及 GLM (https://github.com/THUDM/ChatGLM3)、Qwen (https://github.com/QwenLM/Qwen2.5) 和 DeepSeek (https://huggingface.co/deepseek-ai) 的模型中心。
- 一个反复出现的技术主题是成本与部署:使用 vLLM (https://github.com/vllm-project/vllm) 或 llama.cpp (https://github.com/ggerganov/llama.cpp) 等运行时,在拥有约
8–24 GBVRAM 的消费级 GPU 上自托管7B–14B模型(通常为 4/8 位量化),可以避免按 Token 收费的 API 费用。这实现了可预测的 TCO(总拥有成本)、离线/边缘部署以及定制的安全护栏/微调流水线,而这些在闭源层级(如 GPT-3.5/4)上成本极高。 - 评论中对 OpenAI 的封闭发布实践(自 GPT-3 以来训练细节有限)进行了技术性批评,并与这些群体的开放性(权重、训练/评估方案、推理栈)形成对比,后者实现了独立的 Benchmark 测试和可复现性。参考资料:Qwen 文档/论文和模型卡 (https://huggingface.co/Qwen),DeepSeek 发布内容 (https://github.com/deepseek-ai),以及 GLM/ChatGLM 资源 (https://huggingface.co/THUDM)。
非技术性 AI Subreddit 摘要
/r/Singularity, /r/Oobabooga, /r/MachineLearning, /r/OpenAI, /r/ClaudeAI, /r/StableDiffusion, /r/ChatGPT, /r/ChatGPTCoding, /r/aivideo, /r/aivideo
1. DeepMind Codemender 与 Gemini 3 工具调用(Tool-Use)更新
- Google DeepMind 推出新型代码安全 AI Agent —— CodeMender,可自动发现并修复代码漏洞,并已在主要开源项目中提交了 72 个高质量修复(目前尚未公开访问,但即将推出) (Activity: 396): Google DeepMind 宣布了 CodeMender,这是一款 AI 代码安全 Agent,能够自主检测代码库中的漏洞并提出/提交修复方案,并声称已向主要开源项目贡献了
72个高质量补丁;目前尚未向公众开放 (post)。提供的链接内容仅包含网站导航,因此关于模型系列、训练/评估数据集、支持的语言、漏洞类别、CI/CD 集成、评审工作流以及安全/护栏机制的细节在本次输入中未披露。 热门评论质疑此类 Agent 是否会在组织工作流中持续运行,指出了针对人为因素风险(如凭据管理)的局限性,并对过度干预/误报(如删除 .env/机密信息)表示担忧,暗示需要严格的范围控制、护栏和基于评审的自动化。- 参与者指出,代码修复 Agent 无法解决更广泛的操作安全风险:即使是完美的静态/动态修复也无法阻止通过不良实践(如贴纸上的密码、摄像头泄露)导致的凭据泄露。这强调了在任何自动化漏洞修复 Agent 之外,还需要代码之外的纵深防御(机密管理、最小权限访问、终端加固和用户培训)。
- 对自动修改代码库的怀疑凸显了对严格护栏的需求:Agent 应通过黑/白名单避免触碰敏感工件(如 .env),在补丁前后集成机密扫描,并要求受保护分支、强制代码评审、演练差异对比(dry-run diffs)以及便捷的回滚,以防止破坏性更改或意外的机密泄露。
- 关于“常驻”部署,评论者含蓄地提出了操作层面的担忧:持续运行的 Agent 应集成在 PR 阶段和/或定期扫描(每晚/每周),并具备速率限制、成本/治理控制、限定范围的 Token 和详细的审计日志,以在减少噪音和仓库频繁变动的同时维护供应链完整性。
- Gemini 3 将能够调用工具 (Activity: 533): 该帖子声称“Gemini 3 将能够调用工具”,即支持结构化函数/工具调用(function/tool calling)以调用外部 API 并处理其输出——从而实现检索、代码执行和其他 Agent 风格的操作。从技术上讲,这是与现有 LLM 生态系统对齐的基本门槛(具有类型化参数/类 JSON 模式和工具选择的函数调用接口),与纯自由文本提示相比,提高了可靠性和集成度。 评论者大多认为这是基准功能(“这年头难道不是必备吗”),一些人对该帖子的严肃性表示怀疑,暗示这一声明平淡无奇而非创新。
- “调用工具”是指由 LLM 发起的函数调用,模型选择工具名称并发出结构化参数(通常是 JSON),由运行时执行(如网络搜索、数据库查询、代码运行),并将结果返回给模型以整合进后续对话中——类似于 ReAct 风格的循环。这与 OpenAI (docs)、Google Gemini (docs) 以及 Anthropic Claude 的 “Tool Use” (docs) 等其他技术栈中提供的 function calling / tools 能力相同。它实现了落地(grounding)、获取最新数据以及超越纯文本生成的精确操作。
- 工具使用日益成为生产级 LLM 应用的基准,因为它驱动了 RAG(检索/搜索)、计算器/代码执行和集成(应用/API),显著减少了幻觉并扩展了能力。大多数具有竞争力的技术栈——GPT-4/4o (Assistants API tools)、Claude 3.5 (Tool Use) 和开源 Agent 框架——都将工具调用视为一等公民,因此缺乏可靠的工具使用是一种竞争劣势。在实践中,这取决于强大的模式遵循(schema adherence)、工具选择/路由以及多步规划/执行的保真度。
- 几位评论者提到了 Gemini 在工具使用(tool use)方面的历史可靠性弱于同行,指出了一些问题,如 schema 不匹配的参数、错误的工具选择以及脆弱的多轮计划导致的失败(例如,来自严格 API 的 4xx 错误)。从业者通常通过更严格的 JSON schemas、验证、工具选择门控(tool-choice gating)和分解计划来缓解这些问题,但据报道,在社区测试中,其开箱即用的成功率仍落后于 GPT‑4o/Claude 3.5。如果 “Gemini 3” 改进了工具路由(tool routing)、参数形成和迭代计划,它可能会缩小在 Agent 工作负载方面的差距。
- Gemini 3 (Activity: 503): 标题为 “Gemini 3” 的帖子分享了一张图片(无法查看),根据讨论,该图片的核心是 Gemini 的工具使用能力和平台集成。评论者强调 Gemini 需要调用当前 Gemini Apps 沙箱之外更广泛的外部工具/API,并将稳定性/一致性视为首要任务,这表明其在可靠性和生态系统广度方面存在差距。 值得注意的辩论澄清了“工具”的含义——是设备端操作(手机)还是跨设备/桌面命令执行——至少有一位用户报告 Gemini 可以在笔记本电脑上执行命令,这暗示了工具支持的不均衡或依赖于上下文。
- 对更广泛工具使用和开放互操作性的需求:评论者要求支持目前 Gemini Apps 中有限的 “Actions” 之外的功能,其中一位指出 “目前阶段 MCP 兼容性是必要的”。采用 Model Context Protocol (MCP) 将实现跨助手的厂商无关工具、标准化的发现/schemas 以及权限/日志流,让 Gemini 能够利用与其他生态系统支持的相同的第三方功能(modelcontextprotocol.io, github)。这将减少插件碎片化,并使将文件系统、HTTP、代码和自定义企业工具作为统一服务器引入变得更加容易。
- 跨设备执行对等性和 OS 限制:一位用户报告 Gemini 可以“在我的笔记本电脑上执行命令”,但在手机上受到限制,突显了平台差异。桌面 Agent 可以利用原生应用、shell 或浏览器扩展,而移动 OS 则限制后台任务和应用间自动化;弥合这一差距可能需要与 Android Intents、iOS App Intents/Shortcuts、前台服务以及本地 RPC 桥接进行深度集成,以便在获得明确用户许可的情况下将设备功能作为工具公开。清晰的权限管理和沙箱机制对于安全的设备端操作至关重要,同时还能保持可靠性。
- 将可靠性/一致性作为最高工程优先级:评论者强调“一致性和可靠性高于一切”,这对应于具体的指标,如工具调用(tool-call)成功率、端到端操作完成率和确定性计划。技术手段包括 schema 约束的函数调用(function calling)、用于计划/工具选择的
temperature=0、具有指数退避和超时的重试机制、幂等性令牌(idempotency tokens)以及用于可审计性的结构化错误处理/日志记录。强大的评估(evals,例如跨设备的操作成功率)以及提示词(prompts)的缓存/稳定性可以实质性地减少偏差和用户可见的不稳定性。
2. TTS 语音口音投诉(苏格兰口音)
- 甚至没尝试苏格兰口音。 (Activity: 494): 从标题和评论来看,该帖子展示了一个 AI 语音克隆(voice-clone)渲染了一段与苏格兰口音相关的台词(可能是《勇敢的心》中的“Freedom”),但使用的是 Michael Jackson 风格的声音;系统保留了 MJ 的音色和个人语癖(例如 “hee-hee”、“shamone”),但在口音迁移(accent transfer)方面失败了。这突显了零样本(zero-shot)TTS/语音克隆的一个常见局限性:模型通常针对说话人身份和韵律进行优化,但如果没有经过口音条件训练或微调,对地域口音的控制力较弱(参见多说话人 TTS,如 YourTTS 或 VALL-E)。 热门评论注意到了 MJ 的特征——“Free-hee-hee-dom”和“The SHAMOOOONE”——这暗示模型捕捉到了风格化的习惯特征,但丢失了苏格兰口音,读者认为这很有趣而非问题。
- 甚至没尝试苏格兰口音。 (Activity: 492): Reddit 上的媒体链接 (v.redd.it/qu1ek8f8jetf1) 返回了 HTTP 403 Forbidden 错误页面,表明 Reddit 的 CDN/网关需要身份验证访问(OAuth 或开发者凭据)才能检索资源。从标题和评论线索来看,该片段可能包含应用于苏格兰口音语境的 AI 生成的 Michael Jackson 风格语音(语音克隆/VC 或 TTS),但未披露任何模型、流水线或质量指标,且由于访问限制,内容无法验证。 评论大多是非技术性的,表达了对“AI MJ”声音的娱乐感,并引用了 MJ 的发音习惯(如 “hee-hee,” “shamone”),没有实质性的技术争论。
3. AI 社区情绪:模因(Memes)、氛围与审核辩论
- 现在的氛围 (Activity: 416): 引用的 Reddit 帖子无法访问:请求返回 HTTP 403 Forbidden(“客户端被网络安全拦截”)并提示需要身份验证;内容似乎是托管在 v.redd.it (https://v.redd.it/mgss3gugtitf1) 的视频。在无法访问的情况下,无法提取技术细节、基准测试或实现说明;修复路径包括通过 Reddit Login 登录、使用开发者 Token 或提交 支持工单。 热门评论是非技术性的:有兴趣在农场看到“这个”,感到好笑(“I’m LMAO”),以及讽刺它可能会将“婴儿潮一代的 FB 垃圾内容”推向新高度——暗示了对扩展低质量自动生成内容的担忧。
-
孩子们,未来会很带劲! (Activity: 629): 位于 v.redd.it/hjy60pum5jtf1 的链接媒体返回
HTTP 403 Forbidden,表明 Reddit 的身份验证层或边缘(CDN/WAF)强制执行了访问控制,需要用户登录或开发者 Token 才能检索资源。由于内容本身无法访问,唯一具体的理论收获是关于 Reddit 媒体 CDN 的分发和准入控制,而非生成式 AI 的任何模型、基准测试或实现细节。 评论者推测生成式 AI 的用途将严重偏向娱乐/NSFW 内容(“50% 带劲的模因和 50% 色情”),并提出了关于历史制服准确性的问题(“希特勒穿着英国制服吗?”),暗示了潜在的 Deepfake/风格化;另一位表达了毁灭论(doomer)情绪(“好吧,这是一段有趣的旅程”)。未提供技术证据或基准测试。 - 如果 ChatGPT 计划强迫我们证明身份,那么在验证我们年满 18 岁后,他们最好移除 SFW “护栏” (热度: 527):用户报告称 ChatGPT 最近收紧了 SFW 安全过滤器,现在会阻止或锁定包含合意的、虚构成人内容的现有线程;模型经常要求澄清然后拒绝,破坏了之前可行的创意写作工作流。发帖者建议,如果 OpenAI 为 ChatGPT 增加身份/年龄验证 (KYC),应允许通过验证的 18+ 用户绕过 NSFW 护栏——这与 OpenAI 当前的性内容安全规范相悖,该规范无论用户年龄大小均禁止生成显式性内容(参见:https://platform.openai.com/docs/guides/safety-specifications/sexual-content)。 评论者敦促回滚或增加 18+ “绕过”模式;一位评论者称默认的 “GPT-5” 行为过度对齐且“乏味”,另一位则认为这些限制并非为了保护未成年人。实质性的担忧在于 NSFW 检测中升高的误报率破坏了与先前线程的向后兼容性,并阻碍了合法的成人小说使用场景。
- 多名用户报告称,最近 NSFW 安全过滤器有所收紧,现在会触发多步“澄清”提示,随后拒绝,即使是针对明确的成人虚构角色。这种行为破坏了迭代写作工作流(例如,项目后的“假设”场景生成),甚至将用户锁在现有的对话线程之外——这表明是平台级的 moderation wrapper(审核包装层)发生了变化,而非基础模型本身的限制。
- 一位评论者将“默认状态下的 GPT-5”描述为受到极端限制,暗示默认的系统提示词/安全层是创意/NSFW 输出的瓶颈,而非原始模型的能力。这突显了底层模型与部署的、受策略强制执行的配置之间的区别,在这种配置中,默认的 safety scaffolding(安全脚手架)会显著削弱生成质量。
- 有人提出了一种替代方案:使用 Mistral 的 “Le Chat”,据称其能力与 GPT-4o 相似,但在不同的(更宽松的)策略制度下运行,从而避开了 OpenAI 的护栏。参考资料:Le Chat (https://chat.mistral.ai) 和 OpenAI 的 GPT-4o 概述 (https://openai.com/index/hello-gpt-4o/)。
- 感谢社区最大的提供者 (热度: 1034):这张图片是一个模因(meme)“感谢”贴,暗示中国实验室目前是通过发布开源权重(open-weight)成为开源 AI 社区的“最大提供者”,例如阿里巴巴/Qwen (HF)、01.AI/Yi (HF)、DeepSeek (HF) 和 InternLM (HF)。来自评论的技术细节:这些是“开放权重”,而非完全的“免费/开源”;许可证可能包含使用限制,且下游生态系统支持(LoRA 微调、工具链)落后于流行的西方基座模型如 PonyXL/Illustrious。 评论者认为“这不是免费的”(许可证细微差别),并指出中国通过发布权重获得了影响力,而美国/欧盟公司则保持封闭;其他人注意到针对中国模型的社区 LoRA 较少,可能是由于硬件限制。
- 几位评论者澄清说,“免费”访问和 open-weights 发布是不同的:开放权重允许下载和本地使用/微调,但仍会产生计算成本,并可能存在许可限制,这与完全的 FOSS 代码不同。实际上,开放权重支持离线推理、量化和 LoRA 训练——这些是封闭 API 无法提供的优势——同时将成本转移到了用户的硬件和电力上。这种细微差别通过支持社区基准测试和可复现性来影响生态系统的健康,即使模型运行并非零成本。
- 在模型采用方面,中国开源模型的一个关键障碍是 LoRA 生态系统:用户注意到,与 PonyXL 或 Illustrious 相比,社区 LoRA 较少,这可能是由于 XL 规模微调的硬件限制。SDXL 级别的 LoRA 训练通常会挑战消费级 GPU 的极限;许多拥有
8–12 GB VRAM的爱好者必须使用极小的 batch sizes 或激进的内存优化,而更流畅的训练通常受益于>16–24 GB。与背景深厚的生态系统相比,这减少了社区 LoRA 的数量/质量;像 kohya-ss (https://github.com/bmaltais/kohya_ss) 这样的工具有所帮助,但 XL 模型仍然比 SD1.5 更耗资源。
- Brett Adcock: “本周,Figure 在 BMW X3 车身车间生产线上已经运行满 5 个月。我们每个生产日运行 10 小时,从未间断!据信 Figure 和 BMW 是全球首个利用人形机器人实现这一目标的。” (热度: 1153): Brett Adcock 报告称,Figure 人形机器人已在 BMW X3 车身车间生产线上运行了约
~5 months,每个生产日运行约~10 hours/day,并声称这是汽车制造领域首次持续部署人形机器人。该帖子未提供有关任务范围、MTBF/运行时间、错误率、安全事件或吞吐量影响的定量细节;引用的片段受访问限制 (video, Figure)。 具有技术背景的评论者质疑,对于重复性工位,选择人形形态(form factor)而非专用或轮式平台以及更简单的末端执行器(end-effectors)是否合理,并指出与典型的工业机器人工作周期(通常是 24/7 连续运行)相比,每天10 h/day的时间较短,这表明目前可能仍处于有限的或试点部署阶段。其他人则推测了更广泛的采用时间表(例如,到 2035 年机器人将“无处不在”)。- 形态之争(人形 vs 轮式/专用):评论者质疑,当固定机器人单元或轮式移动协作机器人(mobile manipulator)可能更简单、更可靠时,为什么在重复的循环任务中需要人形机器人。强调的技术权衡是,人形机器人可以无缝适配为人类设计的工作单元(工作空间范围、工具几何形状、夹具)并使用人类工具而无需重新调整工具,但腿部和五指手增加了复杂性、成本和潜在的故障模式;许多工厂任务可以通过带有 2 指或 3 指抓取器或平行爪末端执行器的轮式底座来处理。隐含的优化问题是灵活性/覆盖范围与运行时间/MTBF 以及集成成本之间的博弈,人形机器人在提供灵活性的同时,牺牲了更简单、高可靠性的专用自动化方案。
- 运行时间和工作周期的质疑:关于“5 个月内每天 10 小时”的说法引发了讨论,即工业机器人通常以多班次或
24/7运行为目标,因此限制在 10 小时可能反映了集成/安全约束、人类班次配合、充电/散热限制或可靠性磨合。技术读者指出,OEE/MTBF/MTTR 以及干预间的平均循环次数等指标比日历时间更有意义,建议需要有关干预频率、恢复时间和自主错误处理的数据来评估生产就绪度。 - 与现有工业机械臂机器人的比较:由于单元中已经存在大型 6-DoF 机械臂机器人,评论者询问人形机器人增加了什么独特价值。技术主题是,固定机械臂擅长高度受限、有夹具的任务(如焊接、物料转移),但在非结构化或多变的子任务(临时搬运、工具拾取、检查、电缆布线)中表现不佳,而在这些任务中,类人的触达范围、姿态和多接触操作可以减少定制夹具和换线时间。权衡点在于专用单元的吞吐量和简单性,与针对边缘情况或高混合/小批量生产的可重构性和更低的工具更换成本之间的平衡。
AI Discord Recap
由 gpt-5 生成的摘要的摘要的摘要
1. Sora 2 视频生成:演示、限制与反应
- Duckumentary Dazzles, Memes Multiply: OpenAI 首映了 30 秒的 Sora 2 短片 The Quack: Part 1 — OpenAI on X,引发了关于 Sora 2 创作忠实度以及随预告片分享的邀请码 FRIYAY 的热议。这次发布通过一段制作精良、易于传播的短视频,展示了 AI 视频生成领域的快速进展,并在一个紧凑的场景中测试了 prompt‑to‑video 的一致性。
- 社区成员庆祝了 gen‑video 质量的飞速提升,并将其与最近的其他 Sora 2 片段进行了对比,例如 @elder_plinius 提到的低重力“宇航员骑马”恶搞视频 (Sora 2 Pro’s leap)。许多人认为这次发布是向更可靠的 storyboard adherence(分镜脚本遵循)和电影感节奏迈出的明显一步。
- Sora Slams the IP Door Shut Overnight: 创作者报告称 Sora 2 突然出现了提示词重写以及对受版权保护内容的彻底禁止。在最初看起来表现强劲的动漫测试后,Andrew Curran on X 引用了这一现象。这一转变削减了直接引用(例如命名的 IP 系列),并迫使人们对受保护的角色和世界使用描述性的绕过方法。
- 用户将这种体验描述为“加速平台劣化” (speedrunning enshittification),同时注意到该模型现在会激进地清理提示词和输出,缩小了 fan‑style video(粉丝向视频)的创作空间。讨论集中在这些 policy changes(政策变化)如何影响制作流程,以及仅包含风格的描述符是否能在审核中幸存。
2. Local/Edge Inference: LM Studio Compatibility and DIY Throughput
- LM Studio Speaks OpenAI v1 Responses: LM Studio 0.3.29 增加了 OpenAI /v1/responses 兼容性,让那些期望标准 OpenAI API 格式的应用可以直接接入本地模型。该版本还首次推出了 CLI 助手
lms ls --variants来列出本地模型变体,简化了多变体开发工作流。- 工程师报告称,得益于终端中强大的 variant discovery(变体发现)功能,与 OpenAI‑style clients 的集成更加顺畅,迭代速度也更快。这缩小了本地实验与假设使用 /v1/responses 语义的生产原型之间的差距。
- Wi‑Fi Farm Feeds GLM at 23 tok/s: 一套方案在 3 个节点上运行了 distributed inference(分布式推理),通过 Wi‑Fi 连接 8 张 RTX 3090,在 8-bit 量化下运行 GLM 4.5 Air,达到了约 5.5k 的提示词处理速度和约 23 tok/s 的吞吐量。该模型可通过 OpenRouter/Z.ai 上的 GLM 4.5 Air (free) 获取。操作者计划在零件到达后重新平衡为 2 个节点 (4/4),以使吞吐量翻倍。
- 该报告强调了精细的 sharding(分片)、精度选择和互联如何廉价地提升本地集群的吞吐量。它还突出了 GLM 4.5 Air 作为一个可靠、对频率限制友好的基准,适用于压力测试分布式服务。
3. OpenRouter Access: iFlow Hacks, Model Swaps, and Seed LLMs
- iFlow Flip Unlocks Free GLM‑4.6 Calls: 一位成员对 iFlow 进行了逆向工程,通过简单的 运行 Python 脚本,即可从任何兼容 OpenAI 的客户端路由免费的 GLM‑4.6 请求。该技术无需 Docker,据报道可与 Qwen/Gemini 栈配合使用。
- 讨论集中在如何将其接入现有的 OpenAI SDK 流程中,同时提醒注意可靠性和服务条款风险。这一黑客手段展示了如何利用 adapter layers(适配层)来搭便车使用第三方模型端点。
- DeepSeek Dies; GLM Air Abides: 在供应商停止托管 deepseek‑v3.1‑base (HTTP 404) 后,用户转向了替代方案,如 GLM 4.6 和通过 OpenRouter/Z.ai 提供的免费 GLM 4.5 Air 层级。这一切换稳定了依赖 OpenAI 风格 API 的下游应用。
- 随着 Grok 4 Fast 不再免费,GLM 的免费层级成为了测试期间避免 rate‑limit(频率限制)困扰的首选。讨论帖对比了各备选方案之间的 latency(延迟)、Token 定价和可靠性,以保持原型开发不被中断。
- Seed Models Tease Frontier on the Cheap: 开发者要求 OpenRouter 添加 ByteDance 的 Seed LLMs(例如 Seed 1.6),理由是其表现强劲且价格低廉,通过 Volcengine Ark 托管的价格约为 $0.11/$0.28 mtok。关注点源于其 frontier‑like performance(类前沿模型性能)和极具竞争力的成本曲线。
- 尽管对 China‑hosted(中国托管)控制面有所顾虑,但与会者倾向于通过实验来验证 quality‑to‑price ratios(性价比)。共识是:如果访问权限和政策透明度得到改善,Seed 可能会给主流定价带来压力。
4. GPU Systems: New dtypes, Multi‑GPU Compilers, and NVLink Insights
- Arm 通过 6-bit MXFP6 为 AI 赋能:Arm 宣布在其 A-profile 路线图中,通过 OCP MXFP6 格式支持 6-bit AI 数据类型,并引入了新的 SVE/SME 指令,详见 Arm Architecture Developments 2025。此举旨在减少 edge/embedded AI 的内存占用和带宽需求。
- 工程师们预计 MXFP6 将提升量化友好型模型的吞吐量,因为这类模型的瓶颈通常在于 memory bandwidth。这一更新标志着行业正朝着利用硬件原生 Kernel 进行 sub-8-bit 推理的方向迈进。
- Mercury 让多 GPU 编译飞速提升:Mercury 论文 介绍了 CommIR,它将远程 GPU 内存视为内存层级的受管扩展,用以编译多 GPU 算子。报告结果显示,与手工优化的基准相比,平均实现了 1.56× 的加速,在实际的 LLM 工作负载中提升高达 1.62×。
- 通过对数据放置和设备间流量进行显式建模,Mercury 最小化了困扰 3D parallel 训练的跨 GPU 停顿(stalls)。讨论中对比了 CommIR 以循环为中心的方法与针对 NVLink/NVSwitch 拓扑的厂商库。
- NVLink 复制引擎测得高带宽:基准测试 NVLink copy engines 及其配置的公开实验已发布:NVLink bandwidth experiments (copy engines)。结果强调,测得的 bandwidth 随平台布线和复制路径的不同而波动。
- 工程师对比了 TMA vs. load/store vs. memcpy 路径,并注意到在某些 B200 多 GPU 测试中 cudaMemcpy 有惊人的性能空间。结论:在确定 Kernel 策略之前,请先针对你具体的 fabric + driver 组合进行 Profile。
5. Agentic Tooling: AppsSDK vs MCP, New DSPy Modules, and Gateways
- AppsSDK 搅局 MCP:OpenAI 的 AppsSDK 为应用带来了 in-ChatGPT UI(发布合作伙伴:TheFork),而 Cloudflare 的 Code Mode 则致力于将 Agent 工具调用转化为 Workers。MCP 贡献者讨论了 AppsSDK UI 与 MCP-UI 之间的重叠,以及 Code Mode 是否对简单的工具调用进行了过度设计。
- 一些人认为 AppsSDK 可以减少 Agent 任务的轮次(turn count)和延迟;另一些人则指出其相对于普通 web APIs/SDKs 的性能和复杂性问题。讨论敦促将 MCP 发现/能力与应用式交互对齐,以保持生态系统的一致性。
- DSPy ReAct Machina 助力多轮 Agent:社区模块 DSPy-ReAct-Machina 已上线 PyPI,它通过为对话提供单一且不断增长的上下文缓冲区来实现多轮 ReAct。作者在配套文章中详细介绍了设计权衡:Dev.to blog。
- 开发者讨论了轨迹存储(trajectory storage)、对整个 ReAct 链的反思,以及将其接入现有 DSPy 程序的方法。关注点集中在减少工具调用抖动(tool-call thrash)和稳定长周期计划上。
- Neosantara 开放免费 LLM 网关:Neosantara AI 推出了一个集成了 DSPy 的免费 LLM Gateway Platform,文档见:Neosantara DSPy docs。新用户每月可获得 10k consume tokens,并可向公布的联系方式发送反馈。
- 该网关旨在快速进行应用脚手架(app scaffolding)搭建,而无需绑定单一供应商,适用于演示和成本敏感型原型开发。早期采用者强调在正式发布前应测试速率限制(rate limits)和回退机制(fallbacks)。
Discord: High level Discord summaries
LMArena Discord
- Perplexity 促销引发推荐竞赛:一项 Perplexity 学生优惠 浮出水面,要求具备活跃的学生身份,这导致用户公开索要推荐奖励。
- 该优惠引发了关于其获取门槛以及用户为了获得折扣所付出的努力的讨论。
- Comet 浏览器:教育科技还是作弊工具?:Comet 浏览器 受到评测,一位成员将其描述为 学习的好地方,而另一位则开玩笑称其为 作弊的好地方。
- 针对 Comet 助手 的评价褒贬不一,有人认为它不如 ChatGPT 或 Gemini,而另一些人则对其 voice mode 表示赞赏。
- 渴求资源的 AI 导致当地地下水位紧张:成员们辩论了 AI 对环境的影响,特别是数据中心冷却的用水量,有人指出 ChatGPT 的 20 个回答大约消耗 0.5 升水。
- 一位成员声称 AI 数据中心附近的居民正面临困境,而另一位成员则推测未来可能出现利用太空进行散热的太空数据中心。
- Gemini 3 发布泄露:2025 年 10 月 9 日?:聊天中引用了 早期测试人员和行业内部人士的报告,称 Gemini 3 有望在 2025 年 10 月 9 日 正式发布,目前正在 AI Studio 等平台上进行测试。
- 一位成员表示希望该模型仅限 AI Ultra 用户使用。
- 混元 3 (Hunyuan 3) 图像生成模型亮相:成员们分享了对 腾讯 (Tencent) 新图像生成器 混元 3 (Hunyuan 3) 的第一印象,有人认为它优于 Qwen 或 Flux,与 Imagen 旗鼓相当。
- 另一位成员指出,这些中国模型在翻译成英文时,往往在翻译质量以及细微的文化细节和语境处理上表现不佳。
OpenAI Discord
- GPT-5 旨在实现即时痛苦检测:GPT-5 Instant 正在进行更新,以更好地识别和支持处于痛苦时刻的用户,引导 敏感对话 以提供即时援助。
- ChatGPT 将继续告知用户当前活跃的模型,并讨论了如何强制 ChatGPT 仅使用 GPT Instant。
- 免费 ChatGPT 企业版计划:用户正在利用一个直接链接获取包含多达 5 个席位的 ChatGPT Business 一个月免费试用,之后将按每席位 30 美元计费,链接指向 该优惠的直接地址。
- 这种免费访问引发了关于生成无限账号以及企业版计划中 Codex 实用性的讨论。
- Arduino 的 AI MCU 模拟神经网络魔力:Arduino 正在开发一种 支持 AI 的微控制器,类似于基于 NPU 的 ARM,推测是一款类似 Hailo-8 的小型设备。
- 一位用户报告称,在树莓派上使用 Hailo-8L,功耗低于 2 瓦 即可实现 2000+ FPS 的物体识别,并将其安装在了 UGV Waveshare 玩具机器人坦克上。
- Sora 2 因表现低劣而遭冷遇:用户嘲讽 Sora 2 较低的分辨率质量 和水印,使其显得廉价。
- 许多人声称某个 OSS 20B 模型表现更好,并且很难为健康研究信息图实现一致的 JSON context profiles。
- 版权审查限制了 DBZ 内容的创作:成员们注意到新的版权限制阻止了生成如 龙珠 Z (Dragon Ball Z) 等受版权保护的内容,要求用户在不直接提及的情况下描述角色和场景。
- 用户必须描述 悟空 (Goku) 和 贝吉塔 (Vegeta)、世界观、动画风格、服装和基调,但被提醒这可能与 DBZ 原作并不十分相似。
Unsloth AI (Daniel Han) Discord
- B200 按需租用缺失!:用户报告 DeepInfra 缺失单卡 B200 按需租用,目前仅提供 8x B200 配置。
- 建议了 Modal 和 Thundercompute 等替代方案,但据报告这些平台目前也处于不可用状态。
- Discord 遭遇安全漏洞!:Discord 披露了 9 月 20 日发生的一起安全事件,第三方客户服务系统遭到未经授权的访问,可能导致个人数据和政府身份证件图像泄露。
- 该漏洞可能与针对 Trust & Safety 团队的社会工程学攻击有关,引发了关于数字身份和数据存储实践的讨论。
- 数据集降级成为 TTS 救星!:一位正在调试 Orpheus 4B TTS model 微调的用户通过将 datasets 降级到
3.6.0版本,解决了数据集加载错误。- ‘torchcodec.decoders.AudioDecoder’ object is not subscriptable 错误曾导致数据集加载和训练失败,这突显了版本兼容性问题。
- Qwen MoE 展示六模型混搭!:一位成员展示了使用自定义的 6B Qwen 3 架构在 2 个数据集上分别训练 6 个独立模型,然后使用 Unsloth 将它们“MoE 化”为一个 6X6B Qwen MoE, 36B 模型 (压缩后为 27B)。
- 特别感谢 Unsloth、提供量化的 Team Mradermacher,以及负责 MLX 并在该模型项目多个部分进行协作的 Team Nightmedia;数据集为内部创建,可在 DavidAU/Qwen3-MOE-6x6B-Star-Trek-Universe-Alpha-D-256k-ctx-36B 获取。
- Sequence Packing + Flash Attention 加速微调!:一位成员通过 Sequence Packing 和 Flash Attention 将每轮(epoch)训练时间从 约 30 分钟缩短至约 4-5 分钟(约 5 亿 token),实现了 100% 的 GPU 利用率且无 CPU 中断。
- Flash Attention 需要手动编译,这使工作站的显存占用达到了峰值。
LM Studio Discord
- LM Studio 引入 OpenAI /v1/responses 兼容性:LM Studio 0.3.29 推出了 OpenAI
/v1/responses兼容性 API,使开发者能够将 LM Studio 与期望标准 OpenAI API 响应格式的应用程序集成。- 最新的 LM Studio CLI 功能
lms ls --variants允许用户直接从终端轻松列出其本地模型变体。
- 最新的 LM Studio CLI 功能
- AI 泡沫讨论:成员们讨论了 Nvidia、Oracle 和 OpenAI 的资金循环,认为如果其中一家倒闭,可能会引发雪崩效应。
- 另一位成员指出,Tool Calls 在他的本地使用场景中价值不大,但他补充说,如果有一个插件能将知识库内容注入到 System Prompt 中而无需 Tool Calls,那就太棒了。
- GPT-OSS-120B 框架落地,具备 128k 上下文:GPT-OSS-120B 框架已发布,拥有 128k 上下文窗口,在 Ryzen AI max+ 硬件上运行速度达 19.76 tokens/s。
- 其他成员跟进询问了具体的硬件规格。
- 分布式推理设置表现出色:一位成员分享了成功的分布式推理设置,通过 WiFi 在 3 个节点上使用 8x 3090,在全 8-bit 精度下实现了 GLM 4.5 air 约 5.5k 的 Prompt 处理速度和 23 tokens/s 的输出速度。
- 他们计划在待换零件到达后,通过在 2 个节点上使用 4/4 配置来使速度翻倍。
- 旧 GPU 上 Vulkan > CUDA?:一位成员发现,在 LM Studio 中使用 qwen/qwen3-30b-a3b-2507 (Q4_K_M) 模型时,NVIDIA P40 上的 Vulkan 性能显著优于 CUDA(63.02 tokens/s 对比 23.31 tokens/s)。
- 成员们认为 P40 过时的驱动程序以及 Vulkan 对旧显卡更好的支持可能是原因所在。
OpenRouter Discord
- iFlow 逆向工程暴露了免费的 GLM-4.6:一名成员通过逆向工程 iFlow,通过运行文件夹中的 python 文件,使任何 OpenAI-compatible tool 都能进行免费的 GLM-4.6 请求。
- 社区讨论了在不使用 Docker 的情况下将其与 Qwen/Gemini 配合使用。
- Deepseek 3.1 宣告终结:在提供商停止托管后,用户报告了 deepseek-v3.1-base 的 404 错误;不过,成员们建议将 deepseek v3.1 deepinfra 和 GLM 4.6 作为可行的替代方案。
- 由于 Grok 4 Fast 不再免费,用户正在寻找替代方案,有人建议通过 Z.ai 使用 GLM 4.5 Air(免费)来规避速率限制错误。
- OpenRouter 上的 BYOK 概念得到澄清:用户寻求关于 BYOK (Bring Your Own Key) 的澄清,解释称 OpenRouter 充当 API(如 OpenAI)的代理,用户直接由 API 提供商计费。
- 指出 OpenRouter 免除了 BYOK 的 5% 附加费,提供了支出控制和备选方案等优势。
- Sora 2 的定价方案浮出水面:Sora 2 的定价已揭晓:专业版视频为 $0.3/秒,非专业版为 $0.1/秒。
- 这引发了关于轻松生成 deepfakes 的影响以及绕过水印和加密技术的方法的讨论。
- 字节跳动的 Seed 模型引发关注:成员们对 OpenRouter 引入字节跳动的 Seed LLM models(如 Seed 1.6)表示出兴趣,理由是它们具有前沿级的性能和低廉的价格($0.11 / $0.28 mtok)。
- 虽然有人担心主要托管方是 volcengine.com(一个中国平台),但这些模型的潜力仍被认为值得关注。
Cursor Community Discord
- GPT-5 和 Claude 4.5 在基准测试中展开对决:用户发现 GPT-5 会过度设计解决方案并依赖于提示词,而 Claude 在许多任务中表现更好且速度更快,尽管意见存在分歧。
- 一些用户发现 Sonnet 4 不如 GPT-5,而另一些人则更喜欢 Ultra。
- 神秘的 Cheetah 模型跃入视野:成员们发现了一个名为 Cheetah 的新付费模型,可能是 Gemini 3.0,并赞扬了它的速度,一名用户报告图像生成时间不到 5 秒。
- 一名用户对其进行了测试,称它几乎立即修复了一个问题,另一名用户则吹捧了它的速度。
- GPT-5 Pro 账单更贵:新发布的 GPT-5 Pro 比 Opus 等其他模型更贵,用户正在测试它在 Cursor CLI 中的表现。
- 一名用户报告称 GPT-5 Codex 经常进行零差异编辑 (zero diff edits)。
- Cursor UI 变更令用户感到困惑:用户讨论了最近 Cursor UI 变更中消失的关闭聊天按钮。
- 一名成员没有意识到顶部的 Cursor logo 可以关闭面板,误以为它是一个 Agent 按钮。
- 后台 Agents 深受 Bug 困扰!:多名用户报告 background agents 运行失败并正在接受调查,其中一人指出使用了不同的 node 版本。
- 一名用户好奇通过 API 启动 Agent 是否会成功。
GPU MODE Discord
- Arm 展示 AI 的 6-bit 未来:Arm 宣布支持用于 AI 的 6-bit 数据类型,采用 OCP MXFP6 格式,并整合了新的 Scalable Vector Extension (SVE) 和 Scalable Matrix Extension (SME) 指令。
- 这些新增功能旨在通过优化内存使用和降低带宽需求来提高 AI 模型效率,为更强大的边缘和嵌入式 AI 应用奠定基础。
- All2All AMD Kernel 获得优化:一位用户通过实现缺失的
custom_kernel函数(运行基准 all2all kernel 的入口点)修复了其提交。- 通过优化代码解决了超时问题,特别是针对 gemm-rs,计算与通信重叠(overlap)的改进带来了 1.25x 的加速。
- CUDA graphs 通过 worklists 实现迭代:一位开发者寻求通过 while 条件和交换 worklists 来改进 CUDA graphs 的管理,旨在减少额外的 device pointer 分配。
- 目标是使用 CUDA while node 优化 kernel 计算,避免在迭代 graph 执行期间产生不必要的指针开销。
- NVSHMEM 对称堆指针讨论:
nvshmem_malloc()执行集合操作(collective operation),预留内存并返回一个对称指针,允许在没有特定模式的情况下进行高效的远程内存访问。- 它与 NCCL 不同,因为它要求每个 GPU 一个进程,而 NCCL 支持单进程;对称堆通过在处理单元之间使用非恒等指针值来提高访问效率。
- 锁定 GPU 时钟以获得稳定的 Profiling:成员建议使用
nvidia-smi --lock-gpu-clocks锁定 GPU 时钟,以确保稳定的 profiling 结果。- 使用基础 TDP 频率可确保满载下的稳定性,防止因过热导致的降频;这种方法与使用最高频率形成对比,后者可能随着 GPU 升温而导致不稳定。
HuggingFace Discord
- ONNX 社区转换图像转文本模型:成员们正在 ONNX Community 的帮助和指导下,将 VLM 和多模态模型转换为 ONNX。
- 共享的转换技巧可以在 HF Discord 频道 中找到。
- Gemma 1B 驱动离线 Prompt:PromptVault Android 应用现在通过 MediaPipe Tasks 使用 Gemma 1B IT 模型 运行端侧 AI,用于离线 prompt 生成和优化,可在 Google Play store 下载。
- 该应用具有本地和 Google Drive(加密)备份、离线模式,以及用于编写标题、描述和 prompt 文本的实验性 AI 操作。
- BERT 模型分类 AI 文章:一位成员训练了一个 BERT 模型,使用来自 Kaggle 的数据集将 AI 生成的文本与人类撰写的文本进行分类。
- 该成员正在寻找在更大数据集上加速训练的方法,因为目前的数据集并不是最好的。
- TrackIO 版本导致 DPOTrainer 问题:成员们发现,将
trackio固定在 0.4.0 版本 可以解决 DPOTrainer/DPOConfig 中的一个问题,相关 issue。- 这一修复表明 0.5.1 版本 存在问题。
- 由于 GAIA 错误,建议复制 Space 而非克隆:在一次 GAIA 练习中,一位用户在尝试克隆 Space 时遇到了 500 错误,被建议改为 duplicate(复制)该 Space。
- 课程明确指示用户复制 Space 而不是克隆,但没有说明原因。
Modular (Mojo 🔥) Discord
- Pixi 前来救场:一位用户通过将频道从
nightly切换到max-nightly,修复了 Pixi 的 Access denied 错误。- Pixi 类似于 uv 与快速 conda 实现的结合体。
- Mojo 的 MAX 旨在取代 TensorFlow 和 PyTorch:一位成员指出 MAX 有可能取代 TensorFlow 和 PyTorch,并询问了其目前的对等性及开源状态。
- 另一位成员回复称,MAX 在推理性能方面已接近或领先,但目前仅部分开源,并计划在明年年初进一步开放。
- Mojo GPU 计算能力与 CUDA 正面交锋:一位成员询问 Mojo 是否能复制 CUDA 中可用的所有功能。
- 另一位成员回答说,虽然 Mojo 目前缺乏与 GPU 图形硬件交互的最佳方式,但几乎任何计算任务都应该是可以实现的;欢迎针对任何未满足的需求提交功能请求。
- 穿针引线:C 库与 Mojo:一位成员询问了在 Mojo 中利用 pthreads 等 C 库 的可能性。
- 一位成员回复称,虽然 C 库通常可以很好地集成,但由于 Mojo 的运行时(runtime)环境及其对标准库函数的影响,pthreads 可能并不理想,并指出 Mojo 目前的并发模型尚不完整。
Nous Research AI Discord
- Sora 2 禁止受版权保护的内容:在以出色的动漫输出惊艳成员后,Sora 2 视频生成模型开始重写提示词,并从昨晚开始彻底禁止受版权保护的内容,根据一条推文显示,这实际上削弱了其创作潜力。
- 成员们表达了失望,将这种体验描述为“平台劣化(enshittification)的极速版”。
- LPDDR5X 助力 Ryzen AI 迷你主机:一台配备 128GB LPDDR5X 的 HP G1a R-AI-Max+ Pro 395 被用于 AI 测试,其特点是采用了板载焊接、不可更换的 LPDDR5X,这种内存通常比 DDR5 快得多且功耗更低。
- 根据三星半导体的链接,LPDDR5X 使得 DGX Spark 和流行的 Ryzen AI 迷你主机能够达到 8000 Mhz 的内存频率和 250GB/s+ 的总线速度。
- Qwen VL 遭遇时钟识别不准确:成员们讨论了 Qwen 2.5 VL 的奇特现象,即较小的模型在视觉任务上有时表现优于较大模型,但在处理文本时会遭遇“迷失在中间”(lost-in-the-middle)现象。
- 在一次时钟读取测试中,它完全漏掉了两个时钟,且大部分错误;而本地运行的 vllm 则答对了 3/5,除了数字颠倒外基本正确。
- Transformer 学习多步损失函数:一位成员描述了他们使用多步 Transformer 损失(multi-step transformer loss)进行的实验,方法是从 Transformer 的部分中间层选择隐藏向量(hidden vectors),并将其附加到输入向量中进行另一次前向传播(forward pass)。
- 他们提到这是在一个非常笨的 gemma 3 270 mit 模型上完成的,但 CLI Agent 开放了实验训练和钻研算法的权限,这简直太疯狂了。
- Dragon Hatchling 论文孵化新想法:一位成员分享了一篇题为《THE DRAGON HATCHLING: THE MISSING LINK BETWEEN THE TRANSFORMER AND MODELS OF THE BRAIN》(Arxiv 链接)的论文,探讨了 Transformer 与大脑模型之间的潜在联系。
- 关于大脑模型和 Transformer 架构的讨论正在进行中。
Latent Space Discord
- DeepSeek 削弱 CUDA 对中国的掌控:DeepSeek 正在通过其 FP8 spec 和 TileLang 语言挑战 Nvidia 的 CUDA 锁定,旨在为中国芯片股建立共享标准和编程桥梁,更多信息见 X。
- 虽然此举代表了中国的战略对齐,但对于与 CUDA 之间仍存在的性能差距,疑虑依然存在。
- Sora 2 鸭子纪录片首映:OpenAI 推出了 The Quack: Part 1,这是一部使用 Sora 2 生成的 30 秒 AI 短片,引发了热议和鸭子主题的梗,包括邀请码 (FRIYAY),链接见 X。
- 此次发布凸显了 AI 视频生成能力的飞速进步。
- 智能体浏览器成为 AI 战场:AI 公司目前正在智能体浏览器 (Agentic Browsers) 领域展开竞争,Claude 在上周五的 AIIA 电话会议上展示了其新浏览器,早期用户注意到了它的能力。
- 这一趋势标志着向更集成、AI 驱动的浏览体验的重大转变。
- Sora 的宇航员骑马革命化生成式 AI:Pliny 庆祝了 Sora 2 Pro 的进步,从去年的不可能静态图像提示词进化到了令人印象深刻的低重力视频:一个真实的马驮着宇航员,并带有即兴、自发生成的任务控制中心幽默 (xcancel.com)。
- 讨论强调了生成式 AI (Gen-AI) 的快速进展、基准测试和内部梗。
- OpenAI 对 Medal 的收购邀约中断:据报道,OpenAI 曾出价 5 亿美元收购游戏视频平台 Medal,以收集训练素材,但交易告吹 (xcancel.com)。
- Medal 正在启动内部 AI 部门——General Intuition——目前正在完成 1 亿美元的融资轮。
Yannick Kilcher Discord
- 机器人浪漫预示未来:关于 AI 性爱机器人 何时变得不再尴尬的讨论,恰逢 Unitree R1 的推出,这是一款虽然“笨拙”但价格亲民(6000 美元)的机器人 (X 链接)。
- 对话涉及了英国的年龄验证要求,一些成员期待着奇点和机器人妻子的到来。
- Discord 数据泄露事件披露:The Verge 报道了一起 Discord 客服数据泄露事件 (The Verge)。
- 新论文探索低秩梯度:一位成员分享了新论文 Low Rank Gradients,指出其涉及复杂的线性代数 (Linear Algebra),引发了兴趣和可能的探索环节。
- 另一位成员开玩笑说,当涉及复杂的数学时,他们喜欢招募一位带有黑猫图片的特定成员,因为他是一位出色的副驾驶,并分享了一个 猫视频。
- 扩散模型需要信号增强:一位成员建议将问题建模为扩散过程 (diffusion process),指出调节信号 (conditioning signal) 可能权重过低,并建议增加调节/引导权重 (conditioning/guidance weight)。
- 另一位成员表示赞同,指出模型对背景欠拟合,验证了对更强调节信号的需求。
- GPT-5 数学能力预测:有关 GPT-5 协助数学家解决数学问题的说法正在流传,并附有链接 推文 1 和 推文 2。
- 一位成员注意到第一条推文发布于 2025 年 8 月 1 日,暗示这是一个关于未来的预言。
Eleuther Discord
- 人类评估 Diffusion Models 优于 FVD:成员们讨论了 diffusion models 的评估,包括对图像使用 FID/CLIPScore、人工评估,以及对视频使用 FVD 等自动化指标。
- 一位成员对视频评估表示好奇,指出与 Sora 2 的图像评估方法相比,视频评估仍处于相对原始的阶段。
- Gemma 的架构:并非热门:尽管在 LM Arena 上表现强劲,但 Gemma 的架构 并没有像 Qwen 那样被广泛采用。
- 一位成员认为,训练数据和微调分布 是影响 LLM 性能的比架构本身更重要的因素。
- Synaptik Core 承诺可验证的 AI:来自 Synaptik Core 的 Janay 介绍了 Synaptik Core,这是一个用于 AI 系统中可验证、长期记忆和可审计性的工具链。
- 她分享了一篇 LinkedIn 帖子,展示了 AI agents 以及她在 OpenAI Open Model Hackathon 之前的冲刺阶段 (链接)。
- 用于更简单学习的 AO3 子集出现:成员们探索创建一个具有更简单语法结构的 AO3 故事子集,以便于学习,类似于 TinyStories。
- 该小组考虑使用可读性评分来过滤数据,同时也承认了在噪声去除方面的权衡。
- nanoGPT Speedrun 记录被打破:一位成员分享了一篇 LessWrong 帖子,强调 nanoGPT speedrun 世界记录在 3 个月内下降了 20%。
- 这表明即使在较小规模上,快速进展仍在发生。
MCP Contributors (Official) Discord
- GitHub 团队拥抱基础设施即代码 (Infrastructure-As-Code):该团队将 GitHub 团队管理迁移到基础设施即代码,通过 modelcontextprotocol/access 上的代码管理成员身份和仓库权限。
- 此次迁移旨在实现社区所有权、透明度、审计追踪以及 AI 友好的访问管理,预计在部署期间会有简短的访问中断。
- 版本控制问题困扰 MCP Tools:一位 Intuit 工程师在 MCP Servers 中面临 MCP Tools 的版本控制挑战,特别是在大规模下的依赖管理和兼容性方面,并正在寻求合作者。
- 他们起草了一份包含潜在解决方案的 SEP,可在 modelcontextprotocol/modelcontextprotocol#1575 查看,并正在征求反馈。
- Cloudflare 的 Code Mode 面临过度设计指责:讨论了 Cloudflare 的 Code Mode,一些人认为它误解了 MCP,或者根据这篇博文,将工具调用过度设计成了对 Cloudflare worker 的请求。
- 一些成员辩论 Code Mode 是否能减少 Agent 交付结果所需的轮次,而另一些人则根据这个原型表达了对性能的担忧,并将其与 web APIs 或 client SDKs 进行了不利的对比。
- AppsSDK 引发 MCP-UI 重叠辩论:OpenAI 发布了其 AppsSDK,在 ChatGPT 中引入了带有 MCP 的 UI,TheFork 作为发布合作伙伴,详见其公告。
- 成员们想知道参与 MCP-UI 是否会是更好的选择,但 OpenAI 打算确保它们在一起感觉自然,并将全面支持来自使用 ACP 的应用的交易。
- MCP 特性支持矩阵解读:一位成员询问了 Model Context Protocol 的 特性支持矩阵 (Feature Support Matrix) 中 Discovery 的含义。
- 另一位成员澄清说,Discovery 指的是服务端能力 (server capabilities) 以及传达工具变更的能力。
Moonshot AI (Kimi K-2) Discord
- Kimi-latest 不是 Kimi-K2:别名 ‘Kimi-latest’ 指的是为 Kimi assistant 提供动力的闭源生产级 Kimi large model,而 ‘Kimi-K2’ 则表示开源权重的 MoE 系列(例如 k2-0905)。
- moonshot.ai 上的 ‘proprietary llm’ 行属于闭源技术栈,与 K2 分开,尽管 K2 在 UI 上很突出。
- 破折号(Em Dash)引发争议:一位用户询问,在不与 AI 交互时,其他人是否会忽视包含 em dashes 的消息。
- 一位受访者承认,为了避免被误认为是机器人,他们克制了对 em dashes 的自然使用,并通过一张表情包表达了对 Kimi 的喜爱。
- Kimi 在翻译过程中的审查问题:一位成员报告称,Kimi 的 censoring(审查)可能导致其擦除输出并替换为道歉。
- 他们建议使用 Qwen 进行翻译,因为它具有百万 token 的上下文窗口和卓越的翻译能力。
- 股东追求乐趣与利润:一位用户透露,他们在一个持有 8% 阿里巴巴股票 权重的基金中拥有超过 100 美元,而该基金持有 Moonshot 约 35% 的股份。
- 该成员开玩笑地断言,生命的目的是最大化股东价值,引起了其他人的哄笑。
aider (Paul Gauthier) Discord
- Deepseek 使用 Claude 测试浏览器:一位成员分享了一篇关于使用 Claude CLI 和 Chrome DevTools MCP 进行 Deepseek 浏览器测试 的博客文章。
- 他们还在 Claude Code 和 Opencode 中通过 Anthropic API 使用 Deepseek,因为它在工具任务上表现更好。
- Aider 迫切需要手动控制功能:一位成员表示,他们最怀念 Aider 的功能是对上下文的手动控制,例如 /tokens、/add、/remove 和 /clear。
- 他们认为,对于大型代码库,如果没有这些功能,Aider 就没有机会,而且目前还没有其他工具实现这一点。
- Agentic Grep 可能赋予 Aider 优势:成员们讨论了 agentic tools 如何使用 regex grep 找到所需部分,然后对周围行进行 views(查看),而 Aider 缺少 ripgrep agentic handler。
- 另一位成员表示赞同,称 agentic grep 将真正有助于使 Aider 在当前一代工具中具有竞争力。
- Aider Prompt Cache 默认激活:Aider 的
models.py现在为提供商 Z.aialso 设置了cache_control: bool = True和caches_by_default: bool = True,并在欢迎消息中添加了 “prompt cache”。- 新的欢迎消息将类似于:“Main model: openrouter/deepseek/deepseek-v3.2-exp with diff edit format, 8k think tokens, prompt cache”。
- 开源 vs 闭源权重:价格担忧浮现:讨论转向比较 open-source 与 closed-source AI 模型权重,强调了对闭源权重所有者可能随意涨价的担忧。
- 持续的讨论集中在跟进 Aider 工具的最新更新和功能,确保用户充分利用其潜力。
DSPy Discord
- Neosantara AI 开启 LLM Gateway:Neosantara AI 推出了一个新的 LLM Gateway 平台用于构建 AI 应用,提供免费访问以及 DSPy 集成文档。
- 新用户注册后每月可获得 10k consume tokens,反馈可发送至 halo@neosantara.xyz。
- 呼吁在 Issues 之外提供 DSPy 路线图:一位成员请求在现有的 GitHub issues 和变更日志之外提供 DSPy 路线图,并引用了最近在 X/Twitter 上的提及。
- 共享了 Drew Houston 的帖子和 Huyen Chip 关于 React+Reflection 的博客链接,作为社区参与的案例。
- Elysia 助力 Agent 进行 ReAct:讨论了在较长的 Agent 步骤中,将 ReAct 轨迹存储在磁盘还是内存中的问题,并建议使用 Weaviate 开发的 Elysia,这是一个带有决策树(Decision Tree)的 DSPy 项目。
- 一位成员正在考虑实现 React+Reflection,以对 ReAct 部分的整个轨迹进行反思。
- Fallback 的困扰逐渐消退:一位成员询问如何修改 DSPy 中的 fallback 行为。
- 目前的 硬编码 fallback 机制暂时无法更改。
- DSPy-ReAct-Machina 问世:一位成员发布了 DSPy-ReAct-Machina,这是 DSPy 的另一种 ReAct 实现,通过单一且不断增长的上下文历史记录促进多轮对话,已在 PyPI 上线。
- 他们还分享了一篇博客文章,详细介绍了动机和架构,并寻求社区意见。
tinygrad (George Hotz) Discord
- tinygrad 开发者进入悬赏挑战:寻求加入 tinygrad 的人员必须参加 悬赏计划(bounty program) 以展示其技能。
- tinygrad 团队澄清说,他们不进行个人面试或直接招聘。
- tinygrad NIR 后端准备好接受审查:NIR 后端现在已准备好接受审查(PR #12089)。
- 欢迎工程师对后端的各项功能进行审计和测试。
- tinygrad 将探索 match 语句:团队正在考虑在编译 pattern matcher 时使用
match语句。- 这将取代重复的 if 语句,以改进渲染后的代码。
- 3dgs 仓库考虑移植到 tinygrad:一个 3dgs 仓库 (LichtFeld-Studio) 的维护者计划移除 libtorch,并考虑将 tinygrad 移植到 C++ 以进行推理,并支持 CUDA。
- 一位成员建议将模型编译为 CUDA 或 C kernels,然后导出带有这些 kernel 的 C 代码,并链接到了一个 EfficientNet C 示例。
Manus.im Discord Discord
- 潜在客户生成 MCP 服务器已激活:一个用于批发潜在客户生成(wholesale lead generation)的 MCP 服务器已使用 wrangler/Cloudflare 部署,用于抓取特定政府网站以寻找被低估的房产和急售卖家,然后分解分析数据以生成最终购买提案,访问地址为 wholesale-lead-generator-frontend.pages.dev。
- 一位用户调侃道:“趁它被删除前赶紧抓取恶意软件”。
- Manus iOS 客户端崩溃 Bug 已修复:有报告称 Manus iOS 客户端存在一个 Bug,在计划任务界面选择文本输入时会导致 100% 冻结/崩溃。
- 提供了一个临时解决方案:“在另一个应用中写好你的命令或文本……避免在该字段内选择或编辑文本”,以及利用苹果内置的 Shortcuts 应用和键盘内置的剪贴板管理器。
- 探索轻量级上下文 AI 工具:一位成员正在探索一种轻量级解决方案,用于解决 AI 工具缺乏个人上下文的问题,使其能够连接到用户选择的数据,通过针对性问题识别知识鸿沟,并理解用户目标,以便在任何工具中使用。
- 该成员正在积极寻求湾区(Bay Area)内的合作者和早期采用者,以帮助完善和测试该解决方案。
MLOps @Chipro Discord
- AI Summit 聚焦 Feature Stores:Feature Store Summit 定于 10月14日 8:30 AM PT(5:30 PM CET)举行,届时将有来自 Uber、Pinterest、Zalando、Lyft 和 Coinbase 的演讲者。
- 讨论将涵盖 AI、ML 的基础设施,以及对大规模和实时能力有极高要求的应用,同时还将探讨预计在 2025 年塑造 Feature Stores 的趋势;可通过此链接进行注册。
- AI Summit 探讨大规模实时工程:即将举行的峰会演讲将深入探讨大规模实时特征工程,以及生产环境中的向量数据库和生成式 AI。
- 此外,还将探讨批处理与实时工作流之间的平衡。
- AGI:一个毫无意义的统称?:一位成员对 AGI 的定义提出质疑,认为它是一个没有明确通用性标准的毫无意义的统称。
- 他们还指出,目前缺乏对人类智能的可靠衡量标准。
LLM Agents (Berkeley MOOC) Discord 没有新消息。如果该频道长时间保持沉默,请告知我们,我们将将其移除。
Windsurf Discord 没有新消息。如果该频道长时间保持沉默,请告知我们,我们将将其移除。
您收到这封邮件是因为您通过我们的网站订阅了。
想更改接收这些邮件的方式吗? 您可以从该列表中取消订阅。
Discord:各频道详细摘要与链接
LMArena ▷ #general (1252 messages🔥🔥🔥):
Perplexity 学生优惠, Comet 浏览器, ChatGPT 作弊, Gemini 用于学习, AI 用水量
- 学生们争相获取 Perplexity 优惠补贴:一位成员分享了 Perplexity 学生优惠,但提醒说这需要活跃的学生身份,这导致了一些明显的获取推荐奖励的尝试。
- Comet 浏览器:学习伙伴还是作弊利器?:成员们讨论了 Comet 浏览器,其中一人将其描述为学习的好地方,而另一人则开玩笑地称其为作弊的好地方。
- 对 Comet 助手的评价褒贬不一,有些人认为它不如 ChatGPT 或 Gemini,而另一些人则称赞其语音模式。
- AI 渴了吗?讨论用水量:成员们辩论了 AI 对环境的影响,包括冷却数据中心的用水量,其中一人提到 ChatGPT 的 20 个答案大约消耗 0.5 升水。
- 一位成员表示,AI 数据中心附近的当地居民正面临困难,而另一位成员则表示,未来的趋势是将数据中心放在太空以释放热量。
- Gemini 3 泄露:10月9日发布?:聊天成员引用了早期测试人员和行业内部人士的报告,称在 AI Studio 等平台进行彻底测试后,官方发布日期很可能定在 2025年10月9日。
- 一位成员希望它仅对 AI Ultra 用户开放。
- Hunyuan 3:初步印象:一位用户分享了对 Tencent 新图像生成器 Hunyuan 3 的初步印象,认为它优于 Qwen 或 Flux,且可与 Imagen 媲美。
- 另一位成员提到,这些中国模型在翻译成英文时,往往在翻译和准确描绘细微的文化细节及语境方面存在困难。
OpenAI ▷ #annnouncements (4 messages):
GPT-5 Instant, Sam Altman 主旨演讲, 使用 OpenAI 工具的初创公司
- GPT-5 Instant 获得困境识别功能:OpenAI 正在更新 GPT-5 Instant,以更好地识别并在用户处于困境时提供支持。
- 对话中的敏感部分现在将路由到 GPT-5 Instant 以快速提供有用的回复;当被问及时,ChatGPT 将继续告知用户当前哪个模型处于活跃状态。
- Sama 的主旨演讲直播:Sam Altman 的主旨演讲正在直播,可通过提供的 OpenAI 官网链接访问。
- DevDay [2025] 将于明天 10am PT 开始。
- 初创公司利用 OpenAI 工具:@Cursor_ai、@getSchoolAI、@AbridgeHQ 和 @Jamdotdev 等初创公司正在加入 OpenAI,分享他们如何使用 OpenAI 工具来变革其行业。
- 活动于 11:25am PT 开始,可通过 OpenAI podcast 链接观看。
OpenAI ▷ #ai-discussions (1074 条消息🔥🔥🔥):
Gemma 3 12B multimodal, Arduino AI microcontroller, ChatGPT Business free, AI voice replication, Sora 2 low-rez quality
- Arduino 开发 AI 微控制器:Arduino 正在开发一种类似于基于 NPU 的 ARM 的 AI 启用微控制器,推测是一种更小的类似 Hailo-8 的设备。
- 配合 Raspberry Pi 上的 Hailo-8L,一位用户报告称在功耗低于 2 瓦的情况下,物体识别速度达到 2000+ FPS,并在安装于 UGV Waveshare 玩具机器人坦克上进行了演示。
- “穷哥们”获得免费 ChatGPT Business:用户发现通过使用优惠直接链接,可以免费获得一个月包含多达 5 个席位的 ChatGPT Business,之后按每个席位 $30 计费。
- 免费访问引发了关于生成无限账号以及商业计划中 Codex 价值的讨论。
- OpenAI 语音升级与 AI 语音克隆:成员们注意到 OpenAI 已在其语音模型中加入了 Internet search,使其反应更快、内容更深入;同时其他人分享了 AI 语音复制片段,其中 ElevenLabs 被推崇为最佳。
- 讨论涉及对 Deepfake 时代的担忧,以及需要意识到任何内容都可以被生成。一位用户每天听 AI Chris Hitchens 的音频;而其他人则感到紧张,因为许多人会相信他们在互联网上看到的一切。
- Sora 2 的糟糕表现:用户指出 Sora 2 的低分辨率画质和水印让它显得廉价。
- 许多人声称某个 OSS 20B 模型效果更好。
- Grok 凭借 Waifu 和视频取得进展:SuperGrok 订阅者可以在移动端与 Ani 对话(Waifu 功能),质量令人惊讶。
- 用户分享了 Grok 生成的视频(提示词为
Imagine Spongebob finding out he is banned on Sora),尽管有些人认为这些视频质量低劣、侵犯版权且缺乏连贯的故事。
- 用户分享了 Grok 生成的视频(提示词为
OpenAI ▷ #gpt-4-discussions (19 条消息🔥):
GPT Instant, Error in the stream, GPT-4o switch, GPT publishing review time, NSFW filter
- GPT Instant 引发偏好讨论:一位成员询问如何强制 ChatGPT 仅使用 GPT Instant 而不是 thinking mini。
- 另一位成员开玩笑地建议:威胁它。
- 串流错误困扰 GPT-5 用户:一位成员报告在给 GPT-5 发消息时收到奇怪的 Error in the stream 消息,但在 GPT-4 上没有。
- 针对 Error in the stream 消息尚未提出解决方案。
- GPT-4o 切换故障:一位成员报告说他们似乎无法切换到 GPT-4o,并将该切换开关描述为某种 安慰剂(placebo)。
- 针对 GPT-4o 的 安慰剂 开关尚未提出解决方案。
- 用户遇到 NSFW 过滤器绕过失败:一位成员询问是否有人遇到 ChatGPT 突然拒绝配合绕过 NSFW 过滤器的情况。
- 一位成员回应称,绕过安全机制在 TOS 中是被禁止的。
- ChatGPT App 在 iPhone 上响应不佳:一位成员报告在 iPhone 上使用 GPT app 时出现问题,表现为完全无法工作且从不响应。
- 他们报告说尝试过删除并重新安装 App,但它只在网页端正常工作。
OpenAI ▷ #prompt-engineering (57 条消息🔥🔥):
用于信息图表的 Sora 提示词,生成 DBZ 内容的版权限制,写实 POV 恐怖视频提示词,利用 AI 为 ATS 优化简历,ChatGPT 的极简沟通风格
- Sora 在创建 Json 上下文配置时遇到困难:一名成员正尝试为 Sora 制作的健康研究信息图表创建一个一致的 json 上下文配置(context profile)。
- 他们还请求了关于 Pokemon、Demon Slayer、Hunter x Hunter、Jujutsu Kaisen 以及 Makita 视频 AI 的提示词。
- 版权审查限制了 DBZ 内容的创作:一位用户寻求创建 Dragon Ball Z (DBZ) 提示词的帮助,但一名成员回复称,新的版权限制阻止了生成受版权保护的内容。
- 他们建议描述 Goku 和 Vegeta、世界观、动画风格、服装和基调,但提醒说结果可能与 DBZ 并不十分相似。
- 制作 POV 恐怖视频提示词:一位用户寻求帮助以创建写实的第一人称视角(POV)恐怖视频,因为他们目前的提示词导致生成结果具有类似游戏的质感。
- 一名成员建议明确指定所需的图像类型,以避免出现不必要的视频游戏/卡通风格。
- 由 AI 定制的 ATS 友好型简历:一名成员请求帮助编写一个强大的提示词,以便针对职位优化简历,从而获得更高的 Applicant Tracking System (ATS) 分数。
- 另一名成员分享了 “The_ATS_Resonance_Engine.md“,这是一个用于定制简历的有趣的提示工程框架。
- 指令 ChatGPT 保持极简风格:一名成员分享了一个提示词,用于指令 ChatGPT 采用严格、极简的沟通风格,消除友好性、详细阐述或闲聊。
- 目标是让 ChatGPT 作为一个冷酷、简练的助手,专注于提供直接、准确的答案,而没有不必要的对话。
OpenAI ▷ #api-discussions (57 条消息🔥🔥):
保存艺术提示词,Sora 与信息图表的 JSON 上下文,受版权保护内容的生成,提高视频质量,利用 AI 定制简历
- 艺术提示词存档技巧:成员们讨论了保存艺术提示词的各种方法,包括 Google Sheets、本地 markdown 文件以及 ChatGPT 中的对话线程。
- 一位用户提到在 ChatGPT 中使用项目文件夹来区分不同的渲染分组。
- Sora 在科学风格上的困难:一位用户反映,在使用 Sora 制作健康研究信息图表时,难以获得一致的 JSON 上下文配置。
- 另一位用户建议在向 ChatGPT 索取 Sora 提示词时,要具体说明摄像机角度。
- 版权需求受阻:用户注意到生成受版权保护的内容已受到限制,这可能是由于法律威胁,用户必须在不提及受版权保护的角色或名称的情况下描述创意。
- 一位用户对这些限制表示遗憾,希望未来的工具能够绕过这些限制。
- 恐怖视频帮助台:一位用户请求帮助生成写实的 POV 恐怖视频,因为输出结果有时具有视频游戏般的质感。
- 一名成员建议明确指定所需的图像类型,以防止模型进行猜测并可能选择视频游戏/卡通风格。
- ATS 晋升王牌助手:一位用户请求协助编写一个强大的提示词,以便针对职位优化其简历,从而获得更高的 ATS 分数。
- 另一位用户回复了一个 “The ATS Resonance Engine.md” 文件的链接。
Unsloth AI (Daniel Han) ▷ #general (842 messages🔥🔥🔥):
GLM 4.6 on 5090, B200 租赁, 模型质量 vs 精度, 平台侧边栏
- GLM 4.6 在 5090 上能运行但速度极慢:一位用户询问是否可以在拥有 200GB RAM 的 5090 上运行 GLM 4.6,并建议 Q4_K_M 及以下版本可以装下,但运行速度会很慢。
- 另一位用户确认应该可以装下,但速度会很慢。
- 单卡 B200 按需租赁缺失:用户讨论了在 DeepInfra 移除该选项后,无法进行单卡 B200 按需租赁的问题,目前仅提供 8x B200 配置。
- 一位用户建议查看 Modal 是否有单卡 B200 按需租赁选项,而另一位用户则询问了 Thundercompute 上的可用性。
- 量化质量受到质疑:一位用户询问模型在量化后是否能保持相同的智能水平,特别是关于 Q4_K_M 的质量。
- 一位用户回复称,虽然与全精度相比质量有所下降,但 Q4_K_M 相当不错,不过这取决于模型和使用场景。
- Unsloth 新版主产生:宣布了一位新版主,成员们对新角色和频道权限做出了反应。
- 一位用户说:我以为会有一个秘密频道。想象一下我的失望吧。
- 用户寻求上下文感知建议:一位用户正在构建一个 AI 统计应用,并就具有 context-aware(上下文感知)能力的模型寻求建议。
- 该用户希望为应用提供 local database(本地数据库)访问权限,并希望模型能回答与数据库相关的问题。建议他们研究 RAG (Retrieval-Augmented Generation) 并使用诸如
ibm-granite/granite-4.0-h-tiny之类的模型。
- 该用户希望为应用提供 local database(本地数据库)访问权限,并希望模型能回答与数据库相关的问题。建议他们研究 RAG (Retrieval-Augmented Generation) 并使用诸如
Unsloth AI (Daniel Han) ▷ #introduce-yourself (12 messages🔥):
支持频道权限, 自动版主问题, AI-ML 研究员自我介绍
- 应对支持频道的准入门槛:一位用户询问如何获得支持频道的发布权限,却发现尽管表面上有权限,但尝试发布仍被阻止。
- 很快发现是 auto moderator(自动版主)阻止了该用户发布,随后另一名成员介入。
- 自动版主对支持频道的严密控制:成员们发现 auto moderator 是导致支持频道发布受限的原因。
- 在确认 auto moderator 是罪魁祸首后,一名成员介入并转达了该用户的问题。
- AI-ML 研究员加入对话:一位利用 Generative AI 模型、云集成和可扩展平台来优化业务运营的独立 AI-ML researcher 兼开发人员介绍了自己。
- 该成员受到了频道内其他成员的欢迎,链接见此处。
Unsloth AI (Daniel Han) ▷ #off-topic (800 messages🔥🔥🔥):
AI 音乐检测, AI 教授音乐, Suno 和 Udio 音乐 AI, Discord 安全事件, GPTS Agent
- 需要 AI 音乐侦探:一位成员询问是否可以使用 AI 区分清晰的 J-pop 和动漫歌曲,类似于 AI 区分 AI 音乐与人类音乐的方式。
- Discord 遭遇安全惊魂:Discord 通知用户,9 月 20 日发生了一起安全事件,未经授权的第三方获得了对第三方客户服务系统的有限访问权限,可能导致个人数据和政府身份证件图像泄露。
- 此次泄露可能与针对 Trust & Safety 团队的社会工程学攻击有关,引发了关于数字身份和数据存储实践的讨论。
- 数据质量困境:讨论涉及了为机器学习定义高质量数据的复杂性,一位成员指出毕业标准的波动表明数据集存在噪声。
- 探索了在音频处理中识别和处理噪声数据的技术,并指出了建立可靠基准的困难。
- Meta 和 Google 对 ChatGPT 集成应用做出反应:成员们讨论了 OpenAI 将应用集成到 ChatGPT 的举动,并期待 Meta 和 Google 的回应。
- 一些人认为此举可以防止其他人仅仅创建 GPT 套壳应用,而另一些人则推测 Apple 和 Google 可能会进行操作系统级别的集成。
- Unsloth 迎来新版主:社区庆祝了新版主的加入,祝贺他们获得新职位。
Unsloth AI (Daniel Han) ▷ #help (221 条消息🔥🔥):
llama.cpp 编译, GGUF 输出, 结合 Gemma 的 vLLM, Axolotl 修复, FA3
- Unsloth 的好友编译 llama.cpp:一位刚接触 AI 的 C++ 工程师在指导下使用新的
cmake指令成功编译了 llama.cpp,并表示进度 非常接近完成。- 另一位成员建议查看有关
maximum_memory_usage的文档,以避免进一步的编译问题。
- 另一位成员建议查看有关
- FA3 在其他训练框架中的效率:一位团队成员提到,虽然可以使用其他训练框架,但用户必须禁用 FA3,并指出 Unsloth 仍然是最有效的选择。
- 另一位团队成员表示:是的,某种程度上,对于其他训练框架你必须禁用 FA3,但无论如何,我们仍然是最有效率的。
- Orpheus TTS 微调调试马拉松:一位用户在加载本地数据集以微调 Orpheus 4B TTS 模型 时遇到问题,出现了 ‘torchcodec.decoders.AudioDecoder’ object is not subscriptable 错误,并寻求社区帮助解决数据集加载问题。
- 经过长时间调试,用户发现将 datasets 降级到
3.6.0版本修复了该问题,从而实现了数据集的成功加载和训练。
- 经过长时间调试,用户发现将 datasets 降级到
- 视觉模型图像调整大小引发的问题:一位用户发现 UnslothVisionDataCollator 意外地截断了其视觉模型中的 token,原因是该 collator 将图像大小调整为 512,而手动处理步骤并未这样做。
- 一位成员澄清说,调整为 512 是因为模型配置中缺少默认图像大小,并建议传递所需的大小以避免此问题。
- 通过 WSL 和 Docker 解决 GPU 问题:一位在 Ubuntu 5090 上运行的用户在训练期间遇到了 steps/s 性能下降的问题,而一位团队成员建议为 Unsloth 使用 WSL 或 Docker。
- 该团队成员分享了 Docker 设置指南链接,并鼓励用户提供详细日志以获取进一步帮助。
Unsloth AI (Daniel Han) ▷ #showcase (12 条消息🔥):
高级 AI 安全 Notebook, SFT + GRPO, 结构化输出, Qwen Moe, TNG 数据集
- AI 安全 Notebook 讨论分享!:一位成员分享了一个关于 高级 AI 安全 notebook 的 GitHub 讨论,这是对私聊讨论的后续跟进,希望它能为其他探索 SFT + GRPO 或处理 结构化输出 的人提供一个有用的、可运行的示例。
- 六模型 Qwen Moe 展示!:一位成员展示了使用自定义构建的 6B Qwen 3 架构(55 层,607 个张量)在 2 个数据集 上分别训练 6 个独立模型,然后使用 Unsloth 将它们“MoE 化”为一个 6X6B Qwen Moe, 36B 模型(27B 压缩版)。
- 特别感谢 Unsloth(目前已微调超过 30 个模型)、负责量化的 Team Mradermacher,以及负责 MLX 并在该模型项目多个部分进行协作的 Team Nightmedia。
- 数据集详情披露!:数据集为内部创建,以确保在广泛测试后获得最高的质量/模型微调效果,所有训练均在本地机器上使用 Unsloth 完成;用于训练的“基础” 6B 模型(JanV1, Qwen 3, 256k 上下文, W adapter)可在 DavidAU/Qwen3-MOE-6x6B-Star-Trek-Universe-Alpha-D-256k-ctx-36B 获取。
- TNG 数据集微调大获成功!:使用 TNG 数据集 提升了模型的编程能力,并且在可能的情况下对模型进行了多项指标的基准测试,以验证微调效果以及非目标性的改进。
Unsloth AI (Daniel Han) ▷ #research (16 条消息🔥):
Qwen MoE, Unsloth Dynamic 4bit, Sequence Packing, Flash Attention, torch.compile
- MoE-Money MoE Problems?: 一位成员建议使用 Unsloth dynamic 4bit 对 16B 参数的 MoE 模型进行微调,并指出在使用 token 选择进行训练时,高稀疏性的 MoE 很常见。
- 讨论似乎暗示这仅适用于 Qwen 模型架构。
- Sequence Packing + Flash Attention: 微调突破!: 一位成员通过 sequence packing 和 Flash Attention 将每个 epoch 的训练时间从 ~30 分钟缩短至 ~4-5 分钟(约 5 亿个 token),实现了 100% 的 GPU 利用率且无 CPU 中断。
- Flash Attention 需要手动编译,这使工作站达到了内存使用峰值。
- Torch Compile 难题引发困扰: 一位成员报告了 torch.compile 的问题,在 Python 3.12 和 3.10 中都遇到了故障,最终将其禁用。
- 建议尝试使用
aot_eager_decomp_partition作为比inductor更温和的替代方案。
- 建议尝试使用
- ml-cross-entropy 未达预期,速度慢得多: 一位成员发现
ml-cross-entropy比他们自己基于 PyTorch 的 linear cross-entropy 实现慢了 3-4 倍,尽管其目标是减少 GPU 显存带宽占用。- 他们原本希望通过节省几 MB 显存来补偿一些计算开销。
- Apex 崛起:Fused Optimizers 获胜: 一位成员报告了使用带有
fused-adam和FusedRMSNorm的 apex 取得的成功,并指出它们为性能带来了显著提升。- 他们还分享了他们的 linear cross-entropy 实现。
LM Studio ▷ #announcements (1 条消息):
LM Studio 0.3.29, OpenAI /v1/responses compatibility, LM Studio CLI
- LM Studio 兼容 OpenAI v1 Responses: LM Studio 0.3.29 引入了 OpenAI
/v1/responses兼容 API。- 这使开发者能够将 LM Studio 与期望标准 OpenAI API 响应格式的应用程序集成。
- LM Studio CLI 新增变体列表功能: LM Studio 的命令行界面 (CLI) 通过
lms ls --variants命令增加了一项新功能。- 这允许用户直接从终端轻松列出本地模型变体。
LM Studio ▷ #general (709 条消息🔥🔥🔥):
AGI, Qwen3, LM Studio overload protection, Simulating Sentience, Mark Zuckerberg location
- LM Studio 具备过载保护: LM Studio 内置了防止系统过载的保护功能,因此如果计算机无法处理某个 AI 模型,也不会发生糟糕的情况。
- 即使禁用保护也只会导致系统崩溃,而不会导致硬件损坏,尽管一位用户开玩笑说希望他们的电脑着火。
- 讨论使用多层 LLM 模拟意识: 一位用户询问了如何使用多层 LLM 模拟意识,包括输入模型、循环模型、情感反应模型、内心独白模型、推理模型以及多个向量数据库。
- 另一位用户回应说,我们已经在模拟这一点了,不需要四个不同的模型来完成一个任务。
- LM Studio 无法在自定义根证书下从 Hugging Face 获取模型: 一位用户询问了为什么 LM Studio 无法在自定义根证书环境下从 Hugging Face 获取模型。
- 另一位用户建议尝试在应用设置中配置代理。
- 成员称 AI 泡沫即将破裂: 一位成员表示,AI 泡沫的破裂将使互联网泡沫显得微不足道,并指向一段关于 Nvidia、Oracle 和 OpenAI 资金循环的视频。
- 另一位用户简要回复道,Nvidia 给 OpenAI 钱,OpenAI 从 Oracle 购买算力,Oracle 从 Nvidia 购买设备,并补充说“如果其中一个环节失败,可能会引发雪崩”。
- 用于知识注入的 Memento MCP: 一位用户询问了链接到 Neo4j 的 Memento MCP,指出它看起来更先进,但开销很大。
- 另一位成员表示,对于他的本地用途来说,使用 toolcalls 并不值得,但补充说“如果有一个插件可以在不使用 toolcalls 的情况下将知识内容注入系统提示词 (system prompt),那就太棒了”。
LM Studio ▷ #hardware-discussion (328 messages🔥🔥):
GPT-OSS-120B, Ryzen AI max 性能, 分布式推理设置, AMD vs NVIDIA, AMD 的 Vulkan 与 CUDA 对比
- **GPT-OSS-120B 框架发布,支持 128k Context:一名成员报告称 **GPT-OSS-120B 框架已经发布,拥有 128k Context 窗口,并在 Ryzen AI max+ 硬件上以 19.76 tokens/s 的速度运行。
- 其他成员随后询问了具体的硬件规格。
- **分布式推理 (Distributed Inference) 设置表现出色:一名成员分享了一个成功的分布式推理设置,该设置通过 **WiFi 在 3 个节点上使用 8x 3090s,在全 8-bit 精度下为 GLM 4.5 air 实现了约 5.5k 提示词处理 (prompt processing) 和 23 tokens/s 的输出。
- 他们计划在零件到货后,通过在 2 个节点上使用 4/4 配置来将速度翻倍。
- **AMD GPU 仍需改进:成员们辩论了 **AMD GPU 与 NVIDIA 的价格和性能,讨论了 AMD 在软件支持方面是否落后,一名成员表示,他们应该首先开发一套体面的软件,以便将其 GPU 加速器 用于游戏以外的其他用途,并确保其能正常工作。
- 引用了此链接来尝试 MI250。
- 感叹笔记本电脑 AI (Laptop AI)** 的局限性:成员们讨论了使用笔记本电脑执行 **AI 任务的局限性,理由是硬件较弱(带宽更低、VRAM 更少、散热更差)。
- 普遍的建议是尽可能获取更多的 VRAM,而所有选择中最好的仍然是 Macbook Pro。
- 旧款 GPU 上 **Vulkan > CUDA?:一名成员发现,在 LM Studio 中使用 **qwen/qwen3-30b-a3b-2507 (Q4_K_M) 模型时,NVIDIA P40 上的 Vulkan 性能显著优于 CUDA(63.02 tokens/s 对比 23.31 tokens/s)。
- 成员们认为 P40 过时的驱动程序以及 Vulkan 对旧卡更好的支持可能是原因所在。
OpenRouter ▷ #app-showcase (4 messages):
逆向工程 iFlow, GLM-4.6 请求, 无需 Docker 的 Qwen/Gemini
- iFlow 逆向工程实现免费 GLM-4.6:一名成员对 iFlow 进行了逆向工程,以便为任何 OpenAI 兼容工具启用免费的 GLM-4.6 请求。
- 该成员确认从文件夹中运行 python 文件即可工作。
- 无需 Docker 即可使用 Qwen/Gemini?:一名成员询问是否可以在不使用 Docker 的情况下,将逆向工程后的 iFlow 与 Qwen/Gemini 配合使用。
- 该成员确认从文件夹中运行 python 文件即可工作。
OpenRouter ▷ #general (392 条消息🔥🔥):
Multimodal Model Recommendations, Deepseek 3.1 availability, BYOK setup and use, Free models alternatives to Grok, Sora2 pricing
- Gemini Flash 和 Llama 4 Maverick 在结构化输出方面表现出色:用户在寻找具有结构化输出功能的免费 Multimodal 模型,建议认为 Llama 4 Maverick 和 Gemini Flash 是可行的选择。
- Kyle 分享了一段使用 OpenAI 库从 Gemini API 获取 base64 数据的 Python 代码片段。
- Deepseek 3.1 失效,用户寻找替代方案:用户报告 deepseek-v3.1-base 出现 404 错误,并获知提供商已停止托管该模型。
- 作为替代方案,成员们建议使用 Deepinfra 上的 Deepseek v3.1 和 GLM 4.6。
- 明确 OpenRouter 上的 BYOK 机制:用户对 BYOK (Bring Your Own Key) 的运作方式感到困惑,其他成员解释说 OpenRouter 充当 API(如 OpenAI)的 Proxy,用户直接由 OpenAI 计费。
- 使用 BYOK 时,OpenRouter 会免除通常收取的 5% 附加费,并提供支出控制和 Fallback 选项等便利功能。
- Grok 4 Fast 下架,用户寻找替代方案:由于 Grok 4 Fast 不再免费,用户正在寻找替代品。stackedsilence 推荐了 Deepseek v3.1,而其他人则指向了更具成本效益的选择,如新的 Deepseek 3.2 或 GLM 4.6。
- 在随后的讨论中,GLM 4.5 Air(免费版)被认为是不会出现 Rate Limit 错误且表现最好的免费模型,尤其是使用 Z.ai 作为提供商时。
- Sora2 定价方案曝光!:Sora 2 的定价已公布,Pro 版为 $0.3/秒 视频,非 Pro 版为 $0.1/秒,这引发了关于轻松生成 Deepfakes 影响的讨论。
- 有人建议了绕过水印和加密的方法,这可能会导致滥用。
OpenRouter ▷ #new-models (1 条消息):
Readybot.io: OpenRouter - New Models
OpenRouter ▷ #discussion (50 条消息🔥):
ByteDance Seed LLM models, Inference providers pivoting, GPT 5 pricing, Meta's frontier lab status, Grok fast training data
- 字节跳动 Seed 模型引发关注:成员们好奇 OpenRouter 是否会引入字节跳动的 Seed LLM 模型(如 Seed 1.6),并指出其具有潜在的前沿级性能和低廉的价格($0.11 / $0.28 mtok)。
- 尽管有人担心主要托管方是 volcengine.com(火山引擎,一个中国平台),但该模型的潜力仍被认为值得关注。
- 推理提供商转型面临风险:一位成员询问是否有人在关注那些已从主要提供推理服务转型的推理提供商,并以 Kluster 和 Inference.net 为例。
- 另一位成员调侃道,这些提供商对他来说已经“凉了”。
- GPT-5 定价传闻四起:关于 GPT-5 潜在定价的猜测不断,有人链接到 一条 X 帖子,暗示其具有 Sonnet 级别的速度,但没有推理(reasoning)能力。
- 讨论中考虑了这是否是一个新的 GPT-5 Checkpoint,或者实际上是 Gemini 3 Flash。
- Meta 展示其前沿实验室实力:成员们辩论 Meta 是否通过进行类似于 Pro/deepthink 模型的并行 Test Time Compute,将其定位为前沿实验室。
- 一些人表示怀疑,其中一位指出 Google 不太可能对像 Flash 这样的隐身模型收费,因为他们通常提供大量的免费算力。
- Sora 2 API 将登陆 OpenRouter?:社区发现一些演示文稿中发布的图片显示 Sora 2 API 可能会登陆 OpenRouter。
- 一位成员开玩笑说:“Sora 2 在 OpenRouter 里会像 Nano Banana 一样吗?还是没戏?”
Cursor Community ▷ #general (441 messages🔥🔥🔥):
GPT-5 vs Claude, Cursor billing changes, Cheetah model, GPT-5 Pro, Cursor UI changes
- GPT-5 对比 Claude 4.5:巨头之战:一些成员认为 GPT-5 更依赖于 Prompt 且容易过度设计解决方案,而 Claude 在许多任务中表现更好且速度更快。
- 一些成员发现 Sonnet 4 的性能不如 GPT-5,而另一些人则极力推崇 Ultra 模型,因此这因人而异且取决于具体任务。
- Cheetah 模型狂飙,定价公布:成员们发现了一个名为 Cheetah 的新型付费隐藏模型,并怀疑它可能是 Gemini 3.0,因为它的速度非常快。
- 一位成员测试后表示它几乎立即修复了一个问题,另一位成员称赞其速度,其中一人提到它在 不到 5 秒 内生成了一张图像。
- GPT-5 Pro 登场,价格高于 Opus:成员们讨论了新发布的 GPT-5 Pro,并指出其成本高于 Opus 等其他模型。
- 虽然一些人发现 GPT-5 在 Cursor CLI 中优于 Claude,但一位用户报告称 GPT-5 Codex 经常进行 零差异编辑 (zero diff edits)。
- 用户努力适应 Cursor UI 变更:成员们讨论了 Cursor 最近的 UI 变更,特别是关闭聊天按钮的消失。
- 一位成员承认他们没意识到顶部的 Cursor logo 可以关闭面板,因为它 看起来像一个 Agent 按钮。
- 学生计划风波:需要 .edu 域名:成员们讨论了学生计划的限制,该计划需要 .edu 邮箱地址 进行验证。
- 一位成员分享说,他们联系了支持团队,以允许拥有学校域名的用户访问一个关于 NLP 的 Google 活动,并建议其他人也这样做。
Cursor Community ▷ #background-agents (5 messages):
Background Agents Failing, Different node version being used, Feature Board App Development, Automazeio CCMP Framework, Custom VM Snapshot not being picked up
- Background Agents 失败!:多位用户报告 Background Agents 出现故障,该问题正在调查中。
- 一位用户指出,Agent 在执行启动命令时卡住,因为它使用了 不同的 Node 版本,并且似乎没有使用他们的 Dockerfile,而是在另一个具有随机配置的容器中启动。
- 开发快速 Feature Board 应用:一位用户正在开发一个快速 Feature Board 应用,并正在解决 git worktree 的限制。
- 他们正在考虑通过 Cursor 使用 Sonnet 是否可以处理生成 3 个 Dev Agent、3 个 Reviewer Agent 和 3 个 PM Agent,以根据已实现的能力审查需求,并提到 automazeio/ccpm 框架作为一个可能的替代方案。
- 自定义 VM Snapshot 失败:一位用户报告称他们的 Background Agents 没有识别到自定义 VM Snapshot。
- 另一位用户很想看看使用 API 启动 Agent 是否会成功。
- API 缺少 Snapshot ID:一位用户指出,通过 API 启动 BA 时似乎无法指定 Snapshot ID。
- 他们引用了 Background Agents OpenAPI 文档 来支持他们的观察。
GPU MODE ▷ #general (25 messages🔥):
Hopper vs Blackwell SM 象限, Futhark, 2:4 稀疏训练, VRAM 破解, CUDA 技能集
- 关于 Blackwell 是否沿用 Hopper 象限设计的疑问:根据这篇博客,Hopper GPU 将 SM 分为 4 个象限,每个象限各有一个 Tensor Core,从而实现每个时钟周期执行 4 个 Warp;一位成员询问 Blackwell 是否保留了这一设计。
- 另一位成员解释说,从 Ampere(可能甚至从 Volta)开始,每个 SM 就已经拥有 4 个象限,且每个象限都有自己的 Warp Scheduler。
- “Futhark” 讨论开启:成员们开始讨论 Futhark:高性能纯函数式数据并行数组编程。
- 一位成员指出,这对编程语言极客来说会非常有趣。
- 稀疏训练教程的加速效果需要提升:一位成员询问关于在 PyTorch 中进行 2:4 稀疏训练 的资源,并指出在使用教程的代码示例时没有看到加速效果,直到手动使用
torch.sparse中的SparseSemiStructuredTensor._FORCE_CUTLASS = True修改了稀疏张量行为。 - 不建议对 1660 Super 进行 VRAM 破解:一位成员询问是否可以将 1660 Super 的 VRAM 破解至 12GB。
- 另一位成员推荐了 <#1349152646484987974> 频道,但指出该服务器的大部分关注点在于软件优化而非硬件改装。
- FA3 Kernel 的深度要求似乎并不寻常:一位成员对实现 FA3 等项目所需的知识深度表示惊讶,并好奇这种技能集在计算机科学研究生中有多普遍。
- 另一位成员指出这是一种罕见的技能集,并强调虽然作者名单非常精简,但许多才华横溢的性能工程师在大公司工作,结论是“相信过程(trust the process)”。
GPU MODE ▷ #triton (7 messages):
Meta 的 TLX 团队, Triton 会议
- Meta 的 TLX 团队备受关注:Meta TLX 团队的工程经理提到他们一直在 TLX 领域工作。
- 此外还提到,该团队的工程师并不经常查看此 Discord 频道。
- Triton 会议将展示 TLX:TLX 团队将于今年 10 月在 Triton 会议上展示 TLX。
- 该团队欢迎感兴趣的人士提出关于 TLX 的问题。
GPU MODE ▷ #cuda (36 messages🔥):
PTX .aligned 的含义, Tensor Cores 矩阵乘法, Vast AI GPU 上的 NCU, 带有工作列表的 CUDA 图, Blackwell 支持 256bit 加载
- 使用 PTX .aligned 的 Warp 执行:根据 NVIDIA 文档,PTX 中的
.aligned指令意味着期望整个 Warp 同时执行该指令。 - 深入探讨使用 Tensor Cores 进行矩阵乘法:关于使用 Tensor Cores 进行自定义稀疏矩阵乘法的入门,成员们推荐了这篇文章,以及另一篇更基础的文章和这一篇。
- 云端 GPU 上的 NCU 权限问题:用户在 Vast AI 等租赁硬件上尝试使用 NCU 时遇到权限错误,且其网站上似乎没有现成的关于使用 NCU 进行性能分析的文档。
- 通常,云供应商不提供使用 NCU 和硬件计数器的足够权限,除非硬件所有者开启它们;可能会成立一个工作组来游说云供应商允许此类操作,或识别哪些供应商已经支持。
- 带有工作列表的 CUDA 图循环:一位开发者正在寻求更好的方法来管理带有 while 条件和两个在迭代间交换的工作列表(worklists)的 CUDA 图,目前正在使用额外的设备指针进行交换。
- 他们正在寻找更高效的方法,以避免在使用 CUDA while 节点时分配额外的设备指针,并将设备指针传递给执行计算的 Kernel。
- Blackwell 庞大的带宽盛宴:有人分享说 Blackwell 架构支持 256-bit 加载。
GPU MODE ▷ #cool-links (3 messages):
404 Error, GPU Performance Engineering, Arm Architecture Developments 2025, 6-bit data types for AI, Scalable Vector Extension (SVE)
- 哈佛 GPU 性能博客链接更新:一位成员报告遇到了 404 错误,另一位成员纠正了 URL,指向 哈佛 GPU 性能工程博客。
- 修正后的链接指向一篇关于 GPU 性能工程的详细博客文章。
- Arm 为 AI 推出 6-bit 数据类型:一位成员分享了关于 Arm Architecture Developments 2025 的链接,重点介绍了通过 Open Compute Project 的 OCP MXFP6 格式对 AI 6-bit 数据类型的支持。
- 此次更新包括新的 Scalable Vector Extension (SVE) 和 Scalable Matrix Extension (SME) 指令,通过减少内存使用和带宽需求来提高 AI 模型的效率。
GPU MODE ▷ #jobs (4 messages):
Postdoc position at ISTA, DASLab, QUTLASS, Quartet
- ISTA 的 DASLab 寻找博士后牛人:奥地利科学技术研究院 (ISTA) 的深度算法与系统实验室 (DASLab) 正在寻找一名博士后研究员,以推进高效机器学习系统的研究。
- 该职位要求拥有 PhD 学位,具备深厚的 high-performance computing 背景和丰富的 GPU programming 经验,并参与包括 QUTLASS 和 Quartet 在内的开源项目;申请人应将简历和简短的动机陈述发送至 dan.alistarh@ist.ac.at。
- ISTA 博士后福利与详情公开:关于 ISTA 博士后职位的更多信息可以在其工作环境页面找到。
- 一位成员评价该职位非常“诱人”。
GPU MODE ▷ #beginner (12 messages🔥):
CUDA programming, CMake versions, GEMM vs cuBLAS, NVIDIA Data Center Failure Analysis
- CMake 版本过旧,需要更新!:一位用户遇到了 CMake 错误,提示其版本过旧(低于 3.5),需要更新。
- 另一位用户建议从 Kitware 的下载页面下载更新的版本(例如 3.31)。
- GEMM 项目建议:一位成员建议创建一个 GEMM 项目,针对特定架构与 cuBLAS 竞争。
- 该用户表示:“仅凭这一点就能让你远超那些只会‘写 CUDA’的人。”
- CUDA 讲座助力新手:一位 CUDA 编程新手感谢另一位成员推荐的讲座,称其受益匪浅,并分享了一个 CUDA 学习的 GitHub 链接。
- 该用户随后请求帮助寻找 GitHub 仓库中缺失的第 15 和 16 讲的讲座幻灯片/代码。
- NVIDIA 员工可能协助 CUDA 日志记录:一位在 NVIDIA 从事数据中心故障分析(Data Center Failure Analysis)工作的成员提出,可以调查 CUDA 日志记录方面的概念性问题。
- 该用户表示他们可以“看一看”。
GPU MODE ▷ #pmpp-book (1 messages):
PMPP Code Style, Future Editions of PMPP
- PMPP 为了广泛的受众倾向于 C 风格:成员们注意到 PMPP 保持了 C-style 代码库,以最大限度地提高受众的可访问性。
- 成员中出现了推测,认为这种方法“可能会在后续版本中演进”。
- PMPP 版本的演进:讨论提到目前的 C-style 方法可能会在以后的 PMPP 版本中重新审视。
- 这种潜在的转变暗示了一种在可访问性与现代编码实践之间取得平衡的适应策略。
GPU MODE ▷ #torchao (1 messages):
aguunu: 谢谢!
GPU MODE ▷ #irl-meetup (1 messages):
josephtracyvoltagepark_53706: 我要去参加 PyTorch 大会了!希望能面基。
GPU MODE ▷ #triton-puzzles (4 messages):
Triton Interpreter, Numpy version compatibility, Triton-Puzzles
- **Triton Interpreter 的 Numpy 版本噩梦!:一位用户发现 **Triton interpreter 表现不稳定,仅在 numpy 版本 <= 2.0 时才能按预期工作。
- 他们建议通过调整安装方式来修复此问题,详见他们的 Triton-Puzzles notebook。
- Triton Interpreter 需要特定版本的 Numpy:一位用户解释说,由于 interpreter 使用了 numpy,因此解释器能否正常工作似乎依赖于特定的 numpy 版本,这解释了为什么 Triton interpreter 会出现错误或异常。
- 似乎需要 2.0 版本。
GPU MODE ▷ #rocm (12 messages🔥):
MI300, rocm-compute-viewer, warp specialization for AMD GPUs, wavefront partitioning in Triton, rocBLAS
- rocm-compute-viewer 已在 MI355 上验证:一名成员确认 rocm-compute-viewer 可以在 MI355 上运行,但尚未与随机采样(stochastic sampling)集成。
- 该工具也已确认支持 MI300 系列。
- AMD GPU Kernels 与 Warp Specialization:文档匮乏:一名成员询问是否有关于 AMD GPU kernels 的 warp specialization 公开资源。
- 另一名成员提到,目前还没有像这篇博客文章那样详尽的资源,但 Triton issue #8281 中关于 wavefront partitioning 的工作正在进行中。
- rocBLAS 未使用 wavefront specialization:一名成员原本期望 rocBLAS 会率先在 HIP 级别使用 wavefront specialization。
- 有人指出,由于缺乏 warpgroup 指令,warp specialization 在 AMD 上的表现通常不佳。
GPU MODE ▷ #lecture-qa (1 messages):
seb3523: 当然,为什么不呢 🙂
GPU MODE ▷ #self-promotion (3 messages):
Cute-Bench Package, Prefix Sum and Kogge-Stone Algorithm, Tiny MoE Optimization
- **Cute-Bench 软件包用于基准测试 Kernel:一名成员介绍了 **cute-bench,这是一个 Python 软件包,可以通过
pip install -U git+https://github.com/NTT123/cute-bench.git轻松安装并对 kernel 进行基准测试。- 该软件包包含使用 torch profiler 和 CUDA events 进行基准测试的功能,并通过代码示例展示了如何返回 kernel 测量结果。
- **Prefix Sum 算法可视化:一名成员分享了一个 YouTube 视频,解释了 **prefix sum 和 Kogge-Stone 算法,并包含了完整的代码实现。
- 视频创作者表示由于是视频制作新手,欢迎所有批评意见。
- 微型 **MoE 优化 演示:一名成员优化了一个微型的 **0.5B 参数 MoE(Qwen 风格),并将在 Maven 链接中进行免费分享。
- 他们通过使用 profiler、一个 fused GEMM 以及其他技巧,将训练时间从超过 60 小时(使用 DDP 为 23 小时)缩短至 13.4 小时,且尚未动用 CUTLASS。
GPU MODE ▷ #🍿 (3 messages):
LLM generated kernels, Sakana CUDA engineer
- Alexander 加入 Popcorn Manifesto:Alexander (github.com/zanderjiang) 表达了对 LLM 生成 kernel 的兴趣,并热衷于为 Popcorn Manifesto 项目做贡献。
- 他一直致力于可靠代码生成、稳健的 kernel 基准测试与评估,以及用于 kernel 生成的 Agent/框架/工具等项目。
- Sakana CUDA 工程师文档搜寻开始:一名成员正在寻找 Sakana AI CUDA 工程师文档的原始 PDF 或 Wayback Machine 网页快照,该文档已从互联网上撤回。
- 另一名成员提到,人们现在只是在引用 Twitter 帖子。
GPU MODE ▷ #thunderkittens (3 messages):
B200 multi-GPU cudaMemcpy, TMA vs load/store Performance, NVLink Bandwidth
- 报告 B200 cudaMemcpy 速度提升:一名成员报告称 B200 多 GPU cudaMemcpy 达到了 726GB/s,超过了另一名成员测得的略高于 670GB/s 的结果。
- 原贴作者对这一差异表示好奇,并询问了实现更高带宽所使用的代码,并指出在 NCCL 测试中难以复现该结果。
- TMA 性能令人失望:一位用户发现 TMA 并不比 load/store 操作显著快,仅比 memcpy 稍慢,并推测使用 32-byte PTX instructions(在 12.9 中引入)可能是一个因素。
- 他们注意到 NCCL 代码在同一线程上使用连续加载(back-to-back loads),这一技术他们尚未进行妥善对比。
- 分享关于 NVLink 带宽的公开实验:一位用户分享了他们关于 NVLink 带宽的公开实验链接以及使用 copy engines 的结果。
- 他们还补充道,带宽性能取决于测试所使用的具体机器配置。
GPU MODE ▷ #submissions (72 messages🔥🔥):
amd-all2all Leaderboard, MI300x8 Performance, amd-ag-gemm Leaderboard, amd-gemm-rs Leaderboard, gau-nernst and Kernel GM
- AMD All2All 排行榜:
amd-all2all排行榜收到了多次提交,其中几项在 MI300x8 上获得了第一名,耗时分别为 445 µs 和 439 µs。- 其他值得注意的成绩包括 90.3 ms 的个人最佳纪录,以及几次在 1100-1200 µs 左右的成功提交。
- AG-GEMM AMD 排行榜竞争激烈:
amd-ag-gemm排行榜收到了许多提交,在 MI300x8 上的耗时范围大约在 500 µs 到 800 µs 之间。- 其中一次提交以 499 µs 获得第四名,而另一次提交的耗时为 59.1 ms。
- GEMM-RS AMD 排行榜:
amd-gemm-rs排行榜在 MI300x8 上收到了几次提交,耗时在 570-590 µs 左右。- 其中一次提交的耗时为 1289 µs。
- GAU-Nernst 让 Kernel GM 感到恐惧:一名成员评论道 拥有 Kernel GM 角色的 gau-nernst 是一件可怕的事情。
- 未提供进一步解释。
GPU MODE ▷ #hardware (38 messages🔥):
homelabs builds, b200s, A100 32G SXM2, cursed builds, GPU direct storage
- 渴望疯狂的 Homelab 配置:一名成员对频道里没有充满疯狂的 homelab 配置表示失望 <:wahh:1404542087860584570>,而另一名成员提到正在组装一台设备并考虑进行直播。
- 另一名成员插话道,他们更希望能看到一些廉价硬件(brokie hw)。
- 讨论 A100 32G SXM2 节点配置:成员们讨论了一个 4x A100 32G SXM2 节点的设置,有人建议这可能会吸引那些以“诡异配置(cursed builds)”闻名的人。
- 讨论中提到这些显卡没有功耗限制。
- 探索 PCIe 限制和扩展选项:对话转向了尝试升级到 8 GPU 时的 PCIe 通道限制,建议包括使用双路服务器主板或 PCIe switch 方案。
- 一名成员开玩笑地提议通过 PCIe switch 方案在系统上安装 64 个 GPU。
- GPU Direct Storage:一名成员询问 GPU 是否可以通过 P2P 直接从磁盘存储读取数据,并好奇非 Nvidia GPU 是否也存在类似技术,这里指的是 Nvidia 的 GPUDirect storage API。
- 有人分享了 NIXL 的后端指南链接,提到 GPUDirect Storage (GDS) 是 NIXL 使用的后端之一。
GPU MODE ▷ #tpu (4 messages):
TPU VM, TPU Pods, TPU Slices, TPU Workers
- TPU 新手寻求指导:一名成员按照 tpu-starter GitHub 的说明进行操作,但在创建 TPU VM 时遇到了配置问题。
- 他们正在寻找学习 TPU Pods、TPU Slices 和 TPU Workers 的资源。
- 关于 TPU 设置的更多细节:该用户附上了他们的 TPU 配置图片,表明他们已经阅读了关于 pods、slices 和 workers 的内容。
- 他们询问在设置过程中是否遗漏了某些环节。
GPU MODE ▷ #factorio-learning-env (9 messages🔥):
FLE 0.3.0 on Mac M1/M2, FLE on M4, Factorio Modding, FLE Sync Meeting
- FLE 0.3.0 在 M 系列 Mac 上运行:一位成员询问 FLE 0.3.0 是否能在 Mac M1/M2 芯片上运行以及运行状况是否良好。
- 另一位成员确认它在 M4 上运行成功,并建议尝试安装。
- Factorio Modding 专家加入:一位熟悉 Factorio modding environment 的成员表示愿意贡献力量。
- 另一位成员邀请他们参加 FLE Sync 会议。
- FLE Sync 会议邀请:一位成员提到了 FLE Sync 会议 并分享了 Google Meet 链接。
- 同时分享了一个相关的 Twitch clip 链接。
- 发布备受好评!:一位成员祝贺团队发布了 FLE 0.3.0。
- 他们用火箭表情表达了对未来更多版本发布的期待。
GPU MODE ▷ #amd-competition (32 messages🔥):
rocshmem issues, all2all kernel errors, amd_gemm_rs timeouts, libtorch usage, gemm-rs optimization
- 自定义 Kernel 难题引发困惑:一位用户在运行基准测试 all2all kernel 时遇到了
ImportError: cannot import name 'custom_kernel' from 'submission'错误,并被告知其代码中缺少custom_kernel函数(这是他们应该实现的一个入口点)。- 另一位成员建议超时问题的起因可能源于用户实现中的 bug。
- GEMM-RS 稳步进展:一位对 amd_gemm_rs 进行基准测试的用户遇到了超时,但随后确认环境配置正常,另一位用户成功运行,且 gemm-rs 的优化空间可能比 ag-gemm 更大。
- 建议指出,在良好的计算与通信重叠(overlap)下,改进会更加明显;在线数据显示 gemm-rs 的重叠改进约为 1.25x。
- LibTorch 限制凸显:一位用户询问关于将 libtorch 与 cpp_extension 配合使用并需要其路径的问题。
- 该用户随后反馈
/dev/shm/空间不足。
- 该用户随后反馈
- rocSHMEM 的坎坷之路:资源限制困扰用户:用户报告了 rocshmem 的相关问题,包括需要将其与 rdc 链接,以及在分配 buffer 时遇到空间限制,在分配一定量后会出现错误。
- 建议认为限制可能与分配时间而非大小有关,并有人请求为 rocshmemcc 增加空间分配。
GPU MODE ▷ #cutlass (46 messages🔥):
Vectorization Issues with cute.copy, Layout Visualizers, cute.copy vectorization, TV Layouts, SVG TV visualizer
cute.copy向量化需要源和目标的对齐:一位用户发现tAsA.store(tAgA.load())可以向量化,但cute.copy(tiled_copy_g2s_a, tAgA, tAsA)却不行;强制使用更大的num_bits_per_copy会导致 ICE(内部编译器错误),通过翻转 smem layout 以使两侧对齐解决了该问题。一位成员确认了这一点,即cute.copy要求源和目标都具有atom_v结构才能进行向量化。- 共识是,当你在创建 atom 时通过指定
num_bits_per_copy来强制执行时,它会在 IR 验证阶段失败;由于使用了受限的cp.async,它根本无法向量化。
- 共识是,当你在创建 atom 时通过指定
- Layout 可视化工具大比拼:成员们讨论了 layout 可视化工具,一位成员展示了他们的 SVG TV 可视化工具,另一位成员链接了他们托管在 Hugging Face Spaces 上的 TV layout 可视化工具。
- 前者基于 C++ 实现,可以在
cute.jit/kernel中调用,现在支持 swizzle、copy 和 MMA layout;而后者在线托管,被一些人认为更方便。
- 前者基于 C++ 实现,可以在
- Cute 可视化工具竞赛升温:在讨论 layout 可视化工具后,一位成员分享了他们用 Python 编写的 cute-layout-display。
- 这引发了关于“开发 layout 可视化工具竞赛”的幽默评论,似乎每个 CuteDSL 初学者都需要这个功能。该可视化工具支持 swizzle、copy 和 MMA layout。
GPU MODE ▷ #general (1 messages):
mojo, pip install, Python scripts
- 直接从 Python 脚本安装 Mojo:你现在可以使用
pip直接在 Python 脚本中安装 Mojo。- 分享了一个代码片段:
import pip pip.main(['install', 'mojo'])
- 分享了一个代码片段:
- 使用 pip 管理 Mojo:消息强调了使用 Python 包安装程序 pip 来管理 Mojo 安装的可能性。
- 这可以为熟悉 Python 环境的用户简化安装过程。
GPU MODE ▷ #multi-gpu (53 messages🔥):
Profiling overhead, NVSHMEM and NCCL symmetric memory, Multi-GPU operator optimization, Locking GPU clocks
- 分析张量传输:同步还是淹没?:分析张量传输时,对于较小的张量,可能会不成比例地测量到同步开销;而对于像 (65536, 5120) 这样的大型张量,则可能揭示 MoE 训练运行中的落后者效应(straggler effects)和同步屏障。
- 建议使用 Nsight-Systems (nsys) 进行精确计时,或在传输前后记录 CUDA events,同时通过锁定 GPU 时钟和预热运行(warmup runs)来确保结果的一致性。
- NVSHMEM vs NCCL:指针交锋:在 NVSHMEM 和 NCCL 中,
nvshmem_malloc()执行集体操作(collective operation),从 NVSHMEM 对称堆中预留内存并返回一个对称指针,该指针在每个处理单元(PE)上看起来是相同的。- 虽然指针的数值在不同 PE 之间不会完全相同,但 nvshmem_ptr 可以高效地访问远程内存而无需特定的访问模式,但它要求每个 GPU 一个进程,这与支持单进程的 NCCL 不同。
- Mercury:多 GPU 算子优化器:Mercury 论文 引入了一种基于循环的中间表示 CommIR,将远程 GPU 内存视为多 GPU 算子编译中显式管理的内存层级扩展。
- 这种方法实现了对数据放置和设备间通信的全局推理,与 USP 和 Ulysses 等最先进的手工优化设计相比,平均实现了 1.56 倍的加速,在实际 LLM 工作负载中比模型级 3D 并行性能提升高达 1.62 倍。
- GPU 时钟锁定:稳定速度:为了确保分析结果的一致性,成员建议使用
nvidia-smi --lock-gpu-clocks将 GPU 时钟锁定在一个稳定的频率,可以是nvidia-smi –lock-gpu-clocks=tdp,tdp设置的基础 TDP 频率。- 需要注意最高频率,因为当 GPU 发热时,无论如何它都会降低时钟,因此使用 tdp 作为基准可以在满载期间保持稳定。
GPU MODE ▷ #irl-accel-hackathon (1 messages):
Multimodal Data Processing, Hackathon Team Formation
- 黑客松参与者寻找多模态处理团队:一名参与者希望在黑客松期间合作开展多模态数据处理项目,邀请感兴趣的人员联系并共同规划。
- 黑客松参与者询问团队和选题列表:一名参与者表示有兴趣查看现有的团队列表和选题,以便贡献力量并提出新想法。
- 他们表示 “很想看看并也提交一些东西。”
GPU MODE ▷ #opencl-vulkan (2 messages):
Khronos Group, OpenCL, Vulkan
- 对 Khronos 对齐频道的热情:一名成员对该频道与 Khronos Group 的对齐表示热烈欢迎,表明了对 OpenCL 和 Vulkan 讨论的兴趣。
- 这表明了对并行计算和图形 API 行业标准的关注。
- 关于 OpenCL 和 Vulkan 的潜在讨论:用户的评论暗示了对 OpenCL 和 Vulkan 进行深入交流的渴望。
- 这些是 GPU 编程和跨平台开发的关键技术。
GPU MODE ▷ #cluster-management (10 messages🔥):
Node Failures Mitigation, MPI Fault Tolerance, CCL Reconfiguration, AI-Driven Observability
- 节点故障困扰不断扩大的 GPU 集群:成员们正在讨论缓解大型 GPU 集群中节点故障的策略,指出故障点不断增加以及可靠性和恢复的重要性,并引用了一项研究,其中提到约 5% 的过度配置(over-provisioning)。
- 讨论强调,对于一个拥有 1,056 个 H100 或 A100 GPU 的集群,过度配置每月可能耗资约 100 万美元。
- MPI 旨在从硬件故障中恢复:根据 这个 GitHub,MPI 论坛正致力于使 MPI 程序能够从硬件故障中幸存并在运行时重新添加节点。
- 有人指出,目前除了大量的手动调整外,还没有非常完美的解决方案,NCCL 和 RCCL 可能会借鉴 MPI FTWG 的经验。
- Checkpoint 和 Restart 仍是首选恢复方案:成员们一致认为,目前大多数 CCL 仍假设节点集是固定的,因此 Checkpoint 和 Restart 仍然是首选的恢复路径。
- 有人提到,在短期内,务实的做法是投资于自动化和更智能的 Checkpointing 以实现更快的恢复,直到像 FT-MPI 或 PCCL 这样的容错堆栈能够在生产环境中处理动态节点变化。
- AI 关注主动的、基于可观测性的韧性:该小组最近开始探索嵌入在集群中的 Agentic 系统,能够实时观察日志、指标和遥测数据。
- 其理念是从被动恢复转变为主动的、AI 驱动的可观测性和韧性,并自主重新平衡负载以维持集群健康。
GPU MODE ▷ #penny (3 messages):
Cloud Providers, Vast AI limitations, nvshmem, ncu/nsys access, nvm
- 为项目头脑风暴云端选项:一位成员正在寻求合适的云服务商建议以支持其项目,初步计划在 AWS 和一个名为 nvm 的供应商上进行试验。
- 他们对 Vast AI 表示不满,因为其缺乏 nvshmem 以及 ncu/nsys 访问权限,而这些对他们的项目需求至关重要。
- VastAI 缺失 Nvshmem 和 Nsys/NCU 访问权限:一位用户报告称 Vast AI 缺少 nvshmem、ncu 和 nsys 访问等核心功能,阻碍了他们的项目进展。
- 该用户提到他们将探索 AWS 和另一个名为 NVM 的供应商作为潜在替代方案,以克服这些限制。
HuggingFace ▷ #general (312 条消息🔥🔥):
Image-to-text ONNX conversion, Large-scale conversation datasets, Model drift, Uncensored AI roleplay models, Hugging Face Pro subscription
- ONNX 社区助力图像转文本转换:将 VLM 和多模态模型转换为 ONNX 可能比较棘手,因此建议向 ONNX Community 寻求帮助和指导。
- 同时分享了一个 HF Discord 相关频道的链接,其中包含 转换技巧。
- 获取高质量对话数据集:在寻找大规模、高质量的 3 人以上参与者对话数据时,建议探索 Hugging Face 上的现有项目。
- 这也可能属于 Hugging Science 的范畴。
- 数据漂移的解码与揭秘:一位成员分享了一篇文章链接,以深入了解 Model vs Data Drift(模型漂移与数据漂移)。
- 该文章被视为一篇关于 drift(漂移)如何发生以及如何缓解或减少 drift 的教育性文章,例如通过不断用相关信息更新 LLM 以保持其相关性。
- Vision-to-Text 模型在 OVH 托管上的障碍:一位成员在 OVH 托管方面遇到问题,在尝试使用 vision-to-text 模型 为每张图片生成约 200 字描述(每次约 100 张不同图片)时需要建议。
- 建议该成员使用 OVH,并考虑是否使用 Ollama 部署 GGUF 文件。
- 解析 Deepseek 下载问题:一位成员在寻找适用于 Deepseek 模型的正确文件时遇到困难,并被告知他们 100% 没有足够的内存来运行任何 deepseek-v3 模型。
- 解释称对于本地托管,人们通常运行 GGUF,这些可以在量化(quantizations)分类下找到。
HuggingFace ▷ #i-made-this (5 条消息):
Neovim RAG Chatbot, PromptVault Android App with Gemma 1B IT, BERT Model for AI Text Detection, Art Video
- Vim 改进版语义搜索进入 Neovim:一位成员使用 Claude-4.5 Sonnet 构建了一个 用于 Neovim 帮助文档的 RAG 聊天机器人,旨在为 Neovim 文档提供更好的语义搜索。
- 尽管该聊天机器人还比较基础,但作者对其这个业余项目感到满意。
- PromptVault 应用通过 Gemma 实现离线提示词功能:一位成员宣布他们的免费 Android 应用 PromptVault 现在通过 MediaPipe Tasks 使用 Gemma 1B IT 模型 运行端侧 AI,实现离线提示词生成和优化。
- 该应用具有本地和 Google Drive(加密)备份、离线模式,以及用于编写标题、描述和提示词文本的实验性 AI 操作。
- BERT 严厉打击 AI 生成的论文:一位成员使用来自 Kaggle 的数据集训练了一个 BERT 模型,用于从人类撰写的文本中检测 AI 生成的文本。
- 由于当前数据集不是最好的,该成员正在寻找在更大数据集上加速训练的方法。
- AI 艺术引发 GigaChad 反应:一位成员分享了一个视频,并请求观众如果认为该视频是艺术作品,请回复 <:GIGACHAD:1159748479535558718>。
- 视频以 download.mov 的形式附带。
HuggingFace ▷ #computer-vision (1 条消息):
Wan2.2 tuning, LoRA tuning for high noise models, Tuning high and low noise models, Single component model tuning
- 用户寻求 Wan2.2 tuning 建议:一名用户正在使用 LoRA 对高噪声模型进行 Wan2.2 tuning,但在 5 个 epoch、10 次数据集重复、77 个视频(每个视频 81 帧)后得到了奇怪的结果。
- 该用户描述视频内容非常糟糕,只能看到单个物体在画面中移动,并向社区寻求帮助。
- 同时微调高低噪声模型:同步还是分开?:有用户询问是否应该同时微调高低噪声模型,如果是,是否应该一次性微调(例如,一个完整的周期)。
- 他们还询问是否可以使用相同的低噪声模型仅微调模型的单个组件(例如,仅高噪声模型)。
HuggingFace ▷ #smol-course (20 条消息🔥):
Leaderboard Updates, TrackIO issues with DPOTrainer, Private Datasets on Leaderboard, LoRA SFT with TRL + SmolLM3 issues
- 排行榜手动刷新:课程排行榜已手动更新,链接见此处。
- 成员询问了更新频率,得到的答复是这是一个手动过程。
- TrackIO 软件包问题:一名成员在按照示例使用 DPOTrainer/DPOConfig 时遇到了
trackio的问题,并分享了相关 issue 的链接。- 将
trackio固定在 0.4.0 版本 解决了该问题,这表明 0.5.1 版本 存在问题。
- 将
- 排行榜需要公开数据集:注意到一些学生向 Space 提交了内容,但将其评估数据集设为私有。
- 官方发布了警告:如果没有公开数据集,排行榜将无法工作,并要求检查 PR 以及提供了排行榜讨论的链接。
- LoRA SFT 故障排除:一名成员报告在 Colab 中使用 LoRA SFT 结合 TRL + SmolLM3 时遇到了与意外关键字参数
dataset_kwargs相关的 TypeError。- 讨论期间未找到解决方案。
HuggingFace ▷ #agents-course (17 条消息🔥):
GAIA errors, DuckDuckGoSearchTool errors, Smolagents costs, Duplicating vs Cloning
- 克隆 GAIA Space 导致 500 错误:在 GAIA 练习中,用户在尝试克隆 Space 时遇到了 500 错误,被建议改为 duplicate(复制)该 Space。
- 另一名成员确认了这一方法,称:“我认为你应该复制 Space 而不是克隆它。我当时也是这么做的”。
- 工具错误导致 DuckDuckGo 停止运行:一名刚开始 AI Agents 课程的新学生在将 DuckDuckGoSearchTool 添加到 Agent 工具时遇到了错误,并在附图中分享了该错误。
- Smolagents 费用:它是免费的吗?:用户询问了使用 smolagents 相关的费用,想知道是否需要付费 AI 服务。
- 他们回忆起过去曾为了继续课程而向 Hugging Face 支付过费用,但不记得具体细节。
- 复制 Space 优于克隆:用户询问为什么 duplicate 一个 Space 比在本地 cloning 它更好。
- 回复指出课程明确指示用户复制 Space 而不是克隆,但未说明具体原因。
Modular (Mojo 🔥) ▷ #general (206 messages🔥🔥):
GPU Puzzles Feedback, Mojo vs CUDA, Mojo and pthreads, Tinker as a Threat to Mojo, MAX and Pytorch
- Mojo GPU Puzzles 反馈:一位成员询问了提交关于 GPU puzzles 书籍反馈和更正的适当频道。
- 另一位成员提供了一个 GitHub 链接,指向 Mojo GPU Puzzles 仓库。
- Mojo 的计算能力 vs CUDA:一位成员询问 Mojo 是否可以复制 CUDA 中可用的所有功能。
- 另一位成员回答说,虽然 Mojo 目前缺乏与 GPU 图形硬件交互的最佳方式,但几乎任何计算任务都应该是可以实现的;欢迎针对任何未满足的需求提出功能请求。
- 在 Mojo 中使用 C 库进行线程操作:一位成员询问了在 Mojo 中利用 pthreads 等 C 库 的可能性。
- 一位成员回答说,虽然 C 库通常集成良好,但由于 Mojo 的运行时环境及其对标准库函数的影响,pthreads 可能并不理想,并指出 Mojo 目前的并发模型尚不完整。
- Tinker 对 Mojo 训练的潜在威胁:一位成员建议 Tinker 可能对 Mojo 构成竞争挑战,特别是如果它限制对微调权重的访问,从而限制模型定制选项。
- 一位成员回应称,训练对 Modular 来说优先级较低,因为推理才是 AI 真正盈利的地方。
- MAX:推理领域的有力竞争者:一位成员指出 MAX 有可能取代 TensorFlow 和 PyTorch,并询问其目前的对等性(parity)和开源状态。
- 另一位成员回答说,MAX 在推理性能方面已接近或处于领先地位,但目前仅部分开源,计划在明年年初进一步开放。
Modular (Mojo 🔥) ▷ #mojo (80 messages🔥🔥):
Pixi vs UV, Mojo Notebook, Python type hints, Mojo const generics, Mojo debugging
- Pixi 前来救场:不再有访问拒绝!:一位用户报告了使用 Pixi 时出现的 Access denied 错误,但通过切换到
max-nightly频道而非nightly解决了该问题。- Pixi 就像是 uv 和一个运行不慢的 conda 实现的结合体。
- 在 Jupyter notebook 中运行 Mojo:如这篇论坛帖子所示,可以使用
%%mojo魔法命令在 Jupyter notebook 中使用 Mojo,但现在的导入路径已更改为mojo.notebook。- 注意 Jupyter 单元格目前尚不支持 Mojo 语法高亮。
- Rust 风格的 Traits 即将引入 Mojo:Mojo 旨在提供比 Python 更强大的类型系统,计划中或已实现的包括 Rust 风格的 traits、
where子句、强大的 const generics 以及 variadic generics。- 此外,Mojo 拥有线性类型(linear types),并从 Zig 中汲取灵感开发静态反射 API,最终目标是在类型系统能力上接近 Dependent Haskell 或 Idris。
- 使用 UV 安装时无法进行 Mojo 调试:当 Mojo SDK 以 wheel 形式安装时,不支持使用 ‘mojoFile’ 选项调试 Mojo 文件。
- 用户报告称,即使按照文档使用 pixi 并在 Apple M3 等标准处理器上运行,仍然无法进行调试。
Vectorize函数详情:Mojo 中的vectorize函数不关心数据布局;它指示用户从偏移量i加载接下来的width个元素,并处理消耗循环(drain loop)。- 为了使用
vectorize进行高效处理,建议将数据重新组织为 SoA (Structure of Arrays) 格式,而不是使用List[ComplexSIMD]。
- 为了使用
Modular (Mojo 🔥) ▷ #max (3 messages):
Max Hardware Support, vLLM SGLang, OAI endpoint outside Max docker
- Max 硬件支持分级:Modular 文档中提供了当前的 GPU 兼容性分级列表。
- 虽然你可以在 20XX 系列 GPU 上测试 GPU 功能,但完整的模型可能无法运行;它们可以在 H100 上运行。
- Max 在吞吐量上可能超越 vLLM/SGLang:根据模型的不同,Max 在 H100 上的吞吐量可能比 vLLM 或 SGLang 更有优势。
- 参考此基准测试指南进行自行测试。
- OAI 端点可在 Docker 外部暴露:OpenAI 端点应当暴露在 Docker 容器之外。
Nous Research AI ▷ #general (255 messages🔥🔥):
Sora 2 视频生成,LLM 提示词重写,HP G1a R-AI-Max+ Pro 395 性能,LPDDR5X 对比 DDR5,Qwen VL 模型特性与退化
- Sora 2 生成动漫但陷入 IP 牢笼:成员们发现 Sora 2 视频生成模型的动漫输出效果出奇地好,但注意到该模型会重写提示词,并开始一夜之间彻底禁止版权内容,根据一条推文显示,这实际上削弱了它的创作潜力。
- Sora 的体验被描述为“竞速式劣化(enshittification)”,许多人表达了失望:“几乎永久性地变残缺了,既然如此,它存在的意义是什么?”。
- Ryzen AI 迷你主机搭载 LPDDR5X:购入了一台配备 128GB LPDDR5X 的 HP G1a R-AI-Max+ Pro 395 用于 AI 测试,其特点是板载焊接、不可更换的 LPDDR5X,通常比 DDR5 速度更快、功耗更低。
- 根据三星半导体的链接,LPDDR5X 使得 DGX Spark 和流行的 Ryzen AI 迷你主机能够达到 8000 Mhz 的内存速度和 250GB/s+ 的总线速度。
- Qwen VL 表现出奇怪的退化和时钟不准确:成员们讨论了 Qwen 2.5 VL 的怪癖,即较小的模型在视觉任务上有时优于较大的模型,但在处理文本时会遭遇迷失在中间(lost-in-the-middle)现象。
- 在一次时钟读取测试中,它被显示完全漏掉了两个时钟,且大部分错误;而本地运行的 vllm 正确率为 3/5,除了数字颠倒外基本正确。
- 多步 Transformer 损失微调:一位成员描述了他们使用多步 Transformer 损失的实验,通过从 Transformer 中间层中选择一定数量的隐藏向量(hidden vectors),并将其附加到输入向量中进行另一次前向传递。
- 他们指出这是在一个非常笨的 gemma 3 270 mit 模型上完成的,但 CLI Agent 开放了实验训练和钻研算法的权限,这简直太疯狂了。
Nous Research AI ▷ #research-papers (1 messages):
Dragon Hatchling 论文,Transformer 与大脑的联系
- Dragon Hatchling:Transformer 与大脑之间缺失的环节?:一位成员分享了一篇题为“The Dragon Hatchling: The Missing Link Between the Transformer and Models of the Brain”的论文链接 (ArXiv:2509.26507)。
- 该论文探讨了 Transformer 架构与大脑模型之间的潜在联系。
- 请求进一步探索大脑模型:为了满足最小条目数,考虑增加与大脑模型和 Transformer 架构相关的额外研究或讨论点。
- 例如,详细说明社区对 Dragon Hatchling 论文的反馈或替代解释(如果有)。
Nous Research AI ▷ #interesting-links (2 messages):
巴西初音未来 Nous 女孩
- 分享了巴西初音未来 Nous 女孩:一位成员分享了来自 X 的链接:Brazilian Miku Nous girl。
- 该帖子的标题为 ee.dd。
- 又分享了一个巴西初音未来 Nous 女孩:另一位成员也分享了来自 X 的链接:Brazilian Miku Nous girl。
- 这第二个帖子的标题是 ee.dd 的变体。
Nous Research AI ▷ #research-papers (1 messages):
Dragon Hatchling 论文,Transformer 与大脑的联系
- Dragon Hatchling 论文发布:一位成员分享了一篇新论文的链接,题为“THE DRAGON HATCHLING: THE MISSING LINK BETWEEN THE TRANSFORMER AND MODELS OF THE BRAIN” (Arxiv 链接)。
- Dragon Hatchling:桥接 Transformer 与大脑模型:这篇名为“THE DRAGON HATCHLING”的论文探讨了 Transformer 与大脑模型之间的潜在联系 (Arxiv 链接)。
Latent Space ▷ #ai-general-chat (184 条消息🔥🔥):
DeepSeek 对 CUDA 的掌控、Sora 2 首映、Claude 对阵人类团队、Goodfire 的教训、Kilo Code 的播放量
- DeepSeek 破解中国 CUDA 锁定:DeepSeek 的 FP8 规范和 TileLang 语言正在提振中国芯片股,旨在通过共享标准和简易编程桥梁来削弱 Nvidia 的 CUDA 锁定;这是一种战略对齐,但性能差距依然存在,更多详情见 X。
- Sora 2 发布鸭子短片首秀:OpenAI 使用 Sora 2 首映了一部名为 The Quack: Part 1 的 30 秒 AI 生成短片,引发了惊叹、兴奋以及带有海报和邀请码(FRIYAY)的鸭子客串梗,链接见 X。
- Agentic Browsers 成为浏览器战场:Agentic Browsers 是 AI 公司竞争的新战场,上周五的 AIIA 电话会议上演示了新的 Claude 版本,早期访问用户称其在某些用例中“相当强大”。
- Kilo Code 的播放量受到质疑:Discord 正在辩论 Nick Baumann 声称 Kilo Code 宣传片获得 950 万自然播放量的说法,认为这些指标更像是付费广告/机器人,并引用了 RooCode 较低的数据,查看原始 X 帖子。
- GPT-5 切换引发反抗:ChatGPT 现在以压力支持为借口,将敏感对话自动路由到更便宜的 GPT-5;用户对这种“煤气灯效应”、模型切换和错误标签感到愤怒,发起了 #Keep4o 活动。
Latent Space ▷ #genmedia-creative-ai (15 条消息🔥):
Pika 被迅速超越、AI 骑马宇航员、OpenAI 收购 Medal 失败、General Intuition
- Pika 的 AI 梦想被巨头阻断?:Chongz Luong 观察到,曾经备受瞩目的初创公司 Pika 已被 Google、Meta 和 OpenAI 及其先进的 AI 视频模型(如 Veo 3、Vibes 和 Sora 2)迅速超越 (xcancel.com)。
- 讨论强调了财力如何驱动 AI 霸权,并预测 Pika 可能是众多失去关注的初创公司中的第一个,因为行业重心正从模型转向工具。
- Sora 的宇航员骑马革命:Pliny 庆祝了 Sora 2 Pro 从去年不可能实现的静态图像提示词到令人印象深刻的低重力视频的飞跃:一匹真实的马背着宇航员,并带有即兴生成的任务控制幽默 (xcancel.com)。
- 回复讨论了生成式 AI 的快速进展、基准测试和内部梗。
- OpenAI 5 亿美元收购 Medal 失败!:据报道,OpenAI 去年曾出价 5 亿美元收购游戏视频平台 Medal,以获取用于训练模型的素材 (xcancel.com)。
- 交易破裂,Medal 转而成立了内部 AI 部门 —— General Intuition —— 目前正在完成 1 亿美元的融资。
Yannick Kilcher ▷ #general (77 messages🔥🔥):
AI Sex Robots, Unitree R1 Robot, Discord Data Breach, Safety Benchmark, Automating Scientific Method
- **机器人浪漫:AI 性爱机器人即将来临?: 用户讨论了 **AI 性爱机器人 何时会变得不再那么尴尬,恰逢 Unitree R1 的推出,这是一款虽然笨拙但价格亲民的 $6k 机器人 (X 链接)。
- 此次对话正值英国出台年龄验证要求之际,一些用户已经开始期待与机器人妻子的奇点(Singularity)到来。
- **Discord 灾难:客服数据泄露曝光: 一位用户分享了 The Verge 关于 **Discord 客服数据泄露 的报道链接 (The Verge)。
- **矩阵数学指令:深度学习需要线性代数: 一位用户询问是否有必要学习复杂的矩阵数学**来开始 AI 之路。
- 成员们建议学习线性代数(Linear Algebra)、多变量微积分(Multivariable Calculus)和概率论入门(Intro Probability),并推荐了社区学院课程、YouTube 视频以及斯坦福和伯克利的讲义等资源。
- **AGI 对立面:通用智能是否被过度炒作?: 一位用户质疑对 **AGI 的痴迷,认为特定领域的 ML 系统将更有效地改变世界。
- 其他人辩论了 AGI 的定义,一位用户将其定义为能够完成交给任何领域专家的任何任务,而一些人则将其与技术奇点(The Singularity)联系起来 (维基百科)。
- **MoGs 狂热:高斯混合模型作为 AGI 指标: 一位成员分享了大型基础模型(Foundation Models)可以隐式学习高斯混合模型(MoGs)**的理论保证,并引用了多篇论文 (arxiv 1, arxiv 2, arxiv 3, aclanthology)。
- 他们提议将 AGI 定义为大型基础模型完美模拟由 K 个分量组成的 MoGs 所描述的数据分布的能力。
Yannick Kilcher ▷ #paper-discussion (15 messages🔥):
Low Rank Gradients paper, Paper Exploration session, Peer pressure and beer
- 新论文引发对低秩梯度的关注: 一位成员分享了一篇新论文 Low Rank Gradients,引发了兴趣和潜在的论文研读会。
- 另一位成员指出该论文侧重于重度线性代数(Heavy LA)。
- 用户被“施压”去研究论文: 一位成员询问另一位成员是否愿意主持 Low Rank Gradients 论文的研读会。
- 另一位成员开玩笑说,当涉及复杂数学时,他们喜欢招募那位使用黑猫头像的成员,因为他是一位出色的副驾驶(Co-pilot)。
- 猫咪图片: 一位成员开玩笑说,“不知为何,大佬们(Cracked dudes)都用猫咪头像”,并附带了一个 猫咪视频。
Yannick Kilcher ▷ #agents (2 messages):
Diffusion Problem, Conditioning Signal, Guidance Weight
- Diffusion 模型需要更强的信号: 一位成员建议将问题构建为 Diffusion 过程,并指出条件信号(Conditioning Signal)似乎权重不足。
- 他们建议增加 Conditioning/Guidance Weight,以确保输出更紧密地贴合分镜脚本的雪地背景(Storyboard Snow Background)。
- 背景欠拟合得到确认: 另一位成员同意模型对背景欠拟合(Underfitting),验证了对更强条件信号的需求。
- 原帖作者承认他们不知道如何强制执行这一点,这取决于所使用的 Agent。
Yannick Kilcher ▷ #ml-news (9 条消息🔥):
LLM Reasoning, Tree-of-Thought, Gemini 2.5 Deep Think, GPT-5 Math Claims
- 关于 LLM Reasoning 天真假设的辩论:成员们正在辩论 LLM 是否真的如天真假设的那样使用 reasoning tokens,并指出尽管性能有所提升,但 “reasoning”(推理)往往看起来像是一种事后辩护。
- 有人指出,对简单任务过度思考等问题表明,目前的推理可能更多是表演性的,而非真实的。
- 多模型推理 (Multi-Model Reasoning) 探索:一位成员建议探索来自不同来源的多个小型模型是否可以共同推理,每个模型为解决方案贡献一个步骤。
- 这种方法旨在鼓励语义上有用的推理步骤,而不依赖于 token 间的怪异现象;然而,另一位成员指出,这可能成本太高,不值得。
- 提出 Tree-of-Thought 变体:一位成员建议多模型推理概念可能是 Tree-of-Thought (arxiv link) 的一种变体,可能使用一种半 Agentic 的流水线,将步骤路由到专家模型。
- 有人指出,虽然这种方法的成本效益不如大型模型,但它可以将性能扩展到标准 Prompting 之外;Google 的 “Deep Think” 和 Grok 的 “Super Think” 可能会使用类似的方法,如这篇 blogpost 所述。
- GPT-5 数学实力主张:展示了关于 GPT-5 帮助数学家解决数学问题的说法,并附带了 Tweet 1 和 Tweet 2 的链接。
- 一位成员注意到第一条推文发布于 2025 年 8 月 1 日,暗示这是一个未来主义的主张。
Eleuther ▷ #general (68 条消息🔥🔥):
Diffusion Model Evaluation, Gemma Architecture Adoption, Synaptik Core for AI Memory, COLM Eleuther Meetup, AO3 Story Subset
- 人类评估 Diffusion Models:成员们讨论了 Diffusion Model 的评估,包括 FID/CLIPScore、人工评估以及针对视频的 FVD 等自动指标。
- 一位成员表示:“玩了 Sora 2 之后,我对视频方面的评估感到好奇,因为目前的评估感觉更加原始。”
- Gemma 的架构不如 Qwen 受欢迎:成员们讨论了为什么 Gemma 的架构不像 Qwen 那样被广泛使用,尽管它在 LM Arena 上表现强劲。
- 一位成员建议,架构并不是 LLM 性能的主要驱动因素,训练数据和微调分布 (finetuning distribution) 更为重要。
- Synaptik Core 增强 AI 信任:来自 Synaptik Core 的 Janay 介绍了 Synaptik Core,这是一个用于 AI 系统中可验证长期记忆 (long-term memory) 和可审计性的工具链。
- 她分享了一篇展示 AI Agent 的 LinkedIn 帖子,以及另一篇描述她在 OpenAI Open Model Hackathon 之前的冲刺经历的帖子 (链接)。
- COLM 的 Eleuther 塔可聚会:成员们提到了在 COLM (Conference on Language and Model) 的聚会以及由 Featherless AI 主办的塔可社交活动 (Luma link)。
- 他们希望能在聚会上一起喝咖啡或啤酒。
- 构建用于简化学习的 AO3 子集:成员们讨论了创建一个语法结构更简单的 AO3 (Archive of Our Own) 故事子集,以便于学习,类似于 TinyStories。
- 他们考虑使用可读性评分来过滤数据,尽管有人担心这会去除噪声。
Eleuther ▷ #research (7 messages):
Manning and Csordas, top-k attention, MoE, BabyLM, hopfield-like optimizer
- Top-K Attention 扩展了 MoE 架构:一位成员指出,top-k attention 感觉像是我们在 MLP 中看到的 MoE 和 top-k routers 的自然延伸。
- 他还表示,其动机是在不进行递归的情况下实现 UTs;并质疑如果有人想将其用于训练,如何确保聚类允许梯度流动,且不会在模型的计算图中导致不连续性。
- BabyLM 用于高效的认知合理模型:一位成员表示,未来通过各种技术,所谓的 LLMs 极有可能再次变“小”,那么为什么不从一开始就关注那些(据称)更高效的认知合理(cognitively plausible)模型呢?
- 在这方面,像 BabyLM 这样的倡议受到了高度赞赏。
- 类 Hopfield 优化器缓冲动量:一位成员建议使用一种优化器,它结合了 N 个动量缓冲区(momentum buffers)用于最终更新步骤,并且从输入向量到每个缓冲区都有一个 Hopfield(或类 Hopfield)更新。
- 他们认为这为利用更新矩阵的近似 top eigenvectors(特征向量)做许多酷炫的事情开辟了道路。
Eleuther ▷ #scaling-laws (8 messages🔥):
Block Scaling Factors vs Per-Float, Attention as Inductive Bias, nanoGPT Speedrun
- Block Scaling 优于 Per-Float Scaling?:Rain AI 关于 block scaling factors 优于 per-float scaling factors 的论点似乎得到了 mxfp8 的验证,但考虑到 Nvidia 先前的产品发布,这也抵消了他们可能拥有的任何竞争优势。
- 一位成员询问,Attention 作为一种归纳偏置(inductive bias)的有效性仅仅是巧合,还是归功于 Noam Shazeer 的先见之明。
- Attention:不仅仅是为了 GPU 的便利?:一位成员提到 Dzmitry Bahdanau 是 Attention 机制的另一位关键人物,并链接到了 Andrej Karpathy 的帖子,该帖子承认 attention 当时已经“呼之欲出”。
- 其他人则认为它便于使用 GPU 进行训练。
- nanoGPT Speedrun 时间下降:一位成员分享了一篇 LessWrong 帖子,指出 nanoGPT speedrun 世界纪录在 3 个月内下降了 20%,这意味着即使在较小规模上也有进展。
MCP Contributors (Official) ▷ #general (48 messages🔥):
GitHub 团队管理迁移, MCP 工具版本控制, Cloudflare 的 Code Mode, OpenAI 的 AppsSDK
- GitHub Teams 迁移至基础设施即代码 (Infrastructure-As-Code):该团队将 GitHub 团队管理迁移到了基础设施即代码模式,通过 modelcontextprotocol/access 的代码来管理成员资格和仓库权限。
- 此次迁移旨在实现社区所有权、透明度、审计追踪以及 AI 友好的访问管理,预计在部署期间会出现短暂的访问中断。
- Intuit 工程师调查 MCP 工具版本控制 (Versioning) 挑战:一位 Intuit 工程师正面临在 MCP Server 中对 MCP Tools 进行版本控制的挑战,特别是在大规模情况下的依赖管理和兼容性问题,并正在寻求合作者。
- 他们起草了一份包含潜在解决方案的 SEP,详见 modelcontextprotocol/modelcontextprotocol#1575,并征求反馈。
- Cloudflare 的 Code Mode 是否对 MCP 进行了过度工程化?:讨论了 Cloudflare 的 Code Mode,一些人认为它误解了 MCP,或者根据这篇博文,将工具调用过度工程化为对 Cloudflare worker 的请求。
- 有人指出 Code Mode 能够减少 Agent 交付结果所需的轮次 (turns),但也有人对其性能以及是否优于直接使用 Web API 或客户端 SDK 表示担忧。基于这个原型正在进行一些有趣的实验。
- OpenAI AppsSDK 引发 MCP-UI 重叠争议:OpenAI 发布了其 AppsSDK,在 ChatGPT 中引入了结合 MCP 的 UI,TheFork 作为发布合作伙伴,详见其公告。
- 成员们在思考参与 MCP-UI 是否会是更好的选择。OpenAI 打算参与其中以确保两者结合得自然,并将全面支持使用 ACP 的应用进行交易。
MCP Contributors (Official) ▷ #general-wg (13 messages🔥):
功能支持矩阵澄清, 初始化请求中的服务端能力, 服务端中的图标元数据
- 发现 MCP 功能支持矩阵:一位成员询问了 Model Context Protocol 功能支持矩阵 (Feature Support Matrix) 中“Discovery”的含义。
- 这里的 Discovery 似乎是指服务端能力 (server capabilities) 以及传达工具变更的能力。
- 服务端能力被意外发送:一位成员提到在一次演讲中点名了 Cursor,指出 Cursor 在初始化请求中发送了 server capabilities。
- 另一位成员承认这是意料之外但无害的,在附图中,服务端能力被以黄色高亮显示。
- 图标元数据 (Icon Metadata) 用例说明:一位成员寻求关于在服务端添加图标元数据用例的澄清,并注意到它们存在于其他服务端原语中。
- 另一位成员解释说,图标为应用程序提供了视觉呈现,例如在工具列表或执行工具时在聊天中内联显示。
Moonshot AI (Kimi K-2) ▷ #general-chat (47 messages🔥):
Kimi-latest vs Kimi-k2, K1.5 is proprietary, em dashes usage, translation, Sam Altman introducing OK computer
- **Kimi-latest 不等于 Kimi-K2: “Kimi-latest” 是一个别名,始终指向驱动 **Kimi assistant 的闭源生产级大模型,而 “Kimi-K2” 是独立的开放权重 MoE 系列(例如 k2-0905)。
- moonshot.ai 上的 “proprietary llm” 行指的是该闭源技术栈,而不是 K2,即使 UI 中也显著展示了 K2。
- 部分用户会忽略带有破折号(em dashes)的消息: 一位用户好奇,在与 AI 对话之外,其他人是否会立即忽略带有 破折号 的消息。
- 另一位用户回复说,他们一生都在使用破折号,并且必须克制使用的本能,以免别人认为他们是机器人,并附上了一张表达对 Kimi 喜爱之情的表情包。
- **Kimi 的翻译审查问题: 一位成员表示,有时 **Kimi 的 审查(censoring) 会导致它删除所有已写内容,并替换为“抱歉,我无法为此提供帮助”。
- 他们建议使用 Qwen 进行翻译,因为它拥有百万级上下文,且在翻译方面表现更好。
- 股东为了乐趣和利润实现最大化: 一位用户明确表示,他在一个基金中投资了超过 100 美元,该基金按权重持有 8% 的阿里巴巴股票,而阿里巴巴持有 Moonshot 约 35% 的股份。
- 该成员声称,如果不是为了最大化股东价值,人生的意义何在,其他成员觉得这很有趣。
aider (Paul Gauthier) ▷ #general (34 messages🔥):
Deepseek Browser testing with Claude, Aider vs. Opencode, Agentic tools and ripgrep, Aider and GPT-5 Codex, Aider with Emacs
- Deepseek 使用 Claude 测试浏览器: 一位成员分享了一篇关于使用 Claude CLI 和 Chrome DevTools MCP 进行 Deepseek 浏览器测试 的博客文章。
- 他还在 Claude Code 和 Opencode 中通过 Anthropic API 使用 Deepseek,因为它在工具调用任务上表现更好。
- Aider 需要手动控制: 一位成员表示,他们最怀念 Aider 的功能是对 上下文的手动控制,例如
/tokens、/add、/remove和/clear。- 他们认为所有其他工具都迫切需要这些功能,但目前还没有工具实现,并认为对于大型代码库,Aider 在这些工具面前非常有竞争力。
- Aider 需要 Agentic Grep: 成员们讨论了 Agent 工具 如何使用正则 grep 来查找所需部分,然后对周围行进行“视图”操作,而 Aider 缺少 ripgrep agentic handler。
- 另一位成员表示同意,称 Agentic grep 将真正有助于使 Aider 在当前一代工具中保持竞争力。
- Aider 支持 GPT-5 Codex: 一位成员询问是否有补丁使 Aider 能够与 GPT-5-Codex 配合使用。
- 另一位成员回答说,支持已经合并到 main 分支。
- Aider 与 Emacs 集成: 一位成员表示,个人一直觉得对于他们熟悉的工程/任务,Aider 非常棒,因为它允许他们精确执行想要的操作,而且速度很快,因为他们基本上提供了所需的上下文。
- 另一个优点是它与 Emacs 集成良好。
aider (Paul Gauthier) ▷ #questions-and-tips (4 messages):
aider prompt cache, image analysis
- Aider 默认激活 Prompt Cache: Aider 的
models.py现在为提供商 Z.aialso 设置了cache_control: bool = True和caches_by_default: bool = True,并在欢迎消息中添加了 “prompt cache”。- 新的欢迎消息将类似于:“Main model: openrouter/deepseek/deepseek-v3.2-exp with diff edit format, 8k think tokens, prompt cache”。
- 用户需要图像分析方面的帮助: 一位用户分享了一条消息 hello, sorry i need some help… 并附带一张图片询问 Am i doing something wrong?。
- 附带的图片可能与该用户需要帮助的问题有关。
aider (Paul Gauthier) ▷ #links (1 messages):
Open vs Closed weights, Weight prices and ownership, Aider tool updates
- 开源 vs 闭源权重:价格担忧浮现:讨论转向对比 开源 (open-source) 与 闭源 (closed-source) AI 模型权重,强调了闭源权重所有者可能会随意提高价格的担忧。
- Aider 工具:保持更新:持续的讨论集中在紧跟 Aider 工具的最新更新和功能,确保用户能够充分发挥其潜力。
DSPy ▷ #show-and-tell (1 messages):
Neosantara AI, LLM Gateway Platform, Free AI Apps, DSPy integration, Free consume tokens
- Neosantara AI 推出 LLM 网关:Neosantara AI 推出了一款全新的 LLM Gateway Platform,用于构建 AI 应用,并提供免费使用。
- DSPy 集成进入 Neosantara AI:用户可以将 Neosantara AI 与 DSPy 集成,文档详见 这里。
- 注册获取每月免费 Token:新用户注册即可获得 每月 10k 消耗 Token。
- 用户可以通过电子邮件 halo@neosantara.xyz 提供反馈。
DSPy ▷ #general (26 messages🔥):
DSPy Roadmap, ReAct Trajectories, Fallback Behavior, DSPy and Feature Engineering, BAMLAdapter
- DSPy 路线图:除了 Issues 和变更日志还有什么?:一名成员询问了除了 GitHub issues 和已接受增强功能及新版本的变更日志之外,是否还有 DSPy 路线图,并附带了近期在 X/Twitter 和 DSPy 官方账号 上提到的 DSPy 链接。
- 另一名成员分享了 Drew Houston 关于使用 DSPy 的帖子 链接,以及 Huyen Chip 关于 React+Reflection 的博客文章。
- ReAct 轨迹:磁盘还是内存?:一名成员询问关于在磁盘还是内存对象中维护 ReAct 轨迹 (trajectories) 以处理更长的 Agent 步骤,另一名成员推荐了 Weaviate 的 Elysia,这是一个具有决策树概念的 DSPy 项目。
- 另一名成员正在考虑实现 React+Reflection,以此来对 React 部分的整个轨迹进行反思。
- 硬编码回退的挫败感已修复?:一名成员询问关于更改 DSPy 中 回退行为 (fallback behavior) 的问题,目前确认该行为是 硬编码回退 (hardcoded fallback)。
- DSPy-ReAct-Machina 发布:一名成员宣布发布 DSPy-ReAct-Machina,这是 DSPy 的另一种 ReAct 实现,它通过维护一个单一的、不断增长的上下文历史来实现多轮对话,并已在 PyPI 上发布。
- 他们还分享了一篇 博客文章 解释其动机和架构,并征求反馈。
tinygrad (George Hotz) ▷ #general (15 messages🔥):
tinygrad hiring process, tinygrad bounties, tinygrad meeting #91, tinygrad nir backend, tinygrad pattern matcher
- tinygrad 开发者必须通过 Bounty 挑战:一名用户询问直接招聘的机会,但被告知 tinygrad 的招聘流程 围绕着首先 解决 Bounty (悬赏任务) 展开。
- 没有个人面试或直接招聘。
- tinygrad 董事会会议下周一举行:tinygrad 第 91 次会议 的议程包括公司更新、符号化事项、rangeify bug、速度提升、清理以及 Bounty 讨论。
- 会议将于 周一 圣地亚哥时间上午 6 点(香港时间晚上 9 点)举行。
- NIR 后端开放认领:NIR backend 现在已准备好接受审查(PR #12089)。
- 未分享其他信息。
- 考虑为 Pattern Matcher 使用 match 语句:讨论探索了在编译 pattern matcher 时使用
match语句,而不是在渲染代码中使用重复的 if 语句。- 团队同意尝试这种方法。
tinygrad (George Hotz) ▷ #learn-tinygrad (8 messages🔥):
tinygrad C++ 移植, tinygrad ONNX 前端, 3dgs 仓库
- 3dgs 仓库关注 tinygrad 移植以提升效率:LichtFeld-Studio(一个 3dgs 仓库)的维护者计划移除 libtorch,并考虑将 tinygrad 移植到 C++ 以支持推理和 CUDA。
- 一名成员建议使用维护中的 Python 版 tinygrad 将模型编译为 CUDA 或 C kernels,然后导出包含这些 kernels 的 C 代码,并参考 EfficientNet C 示例进行链接。
- Tinygrad 的 ONNX 前端可能是解决方案:一名成员建议使用 tinygrad 的 ONNX 前端配合现有模型的 ONNX 版本作为快速解决方案。
- 另一名成员确认运行推理应该没有问题。
- 将 tinygrad 移植到 C++:维护者表示他们不介意移植的工作量,因为 tinygrad 能提供融合算子(fused kernels)的优化,而不需要为每种情况手动编写。
- 维护者提到另一种方法是包含一个 Python 解释器,并在 Python 中执行重度的张量操作,类似于 Blender 的做法。
Manus.im Discord ▷ #general (6 messages):
用于潜在客户开发的 MCP Server,Manus iOS 客户端崩溃,AI 工具缺乏个人上下文
- 恶意软件 MCP Server 已部署!:一个用于批发潜在客户开发的 MCP Server 已使用 wrangler/Cloudflare 部署,用于抓取特定政府网站以寻找低估房产和急售卖家,然后分解分析数据以生成最终购买方案,地址为 wholesale-lead-generator-frontend.pages.dev。
- 一名用户开玩笑地称其为 “在被删除前赶紧抓取恶意软件”。
- Manus iOS 客户端崩溃已修复!:Manus iOS 客户端报告了一个 Bug,在计划任务界面选择输入文本时会导致 100% 冻结/崩溃,一名工程师提供了两种解决方案。
- 第一个解决方案是:“在单独的应用(如 Apple Notes)中编写命令或文本。复制文本。在 Manus 应用中,点击输入框一次以放置光标,然后粘贴文本。避免在该字段内选择或编辑文本。”,第二个解决方案是使用 Apple 内置的 Shortcuts 应用和键盘内置的剪贴板管理器。
- 找到 AI 工具缺乏个人上下文的解决方案:一名成员正在探索一种针对缺乏个人上下文的 AI 工具的轻量级解决方案,并设定了具体目标。
- 目标包括 “连接到你选择的数据,通过提问针对知识差距,理解你的目标和现状,并将该上下文插入你正在使用的任何工具中”,目前正在寻找湾区的合作者和早期用户。
MLOps @Chipro ▷ #events (1 messages):
Feature Store 峰会,实时特征工程,向量数据库与生成式 AI,批处理与实时工作流
- 第五届 Feature Store 峰会宣布召开:Feature Store 峰会是一项年度在线活动,将邀请来自 Uber、Pinterest、Zalando、Lyft 和 Coinbase 等公司的技术演讲者。
- 该峰会专注于 AI、ML 的基础设施,以及需要大规模和实时能力的应用。
- 峰会演讲将涵盖大规模实时工程:峰会的演讲将探讨大规模实时特征工程、生产环境中的向量数据库与生成式 AI,以及批处理与实时工作流的平衡。
- 与会者还可以期待关于推动 2025 年 Feature Store 演进的新兴趋势的讨论。
- Feature Store 峰会日期公布:峰会定于 10 月 14 日举行,开始时间为太平洋时间上午 8:30(欧洲中部时间下午 5:30)。
- 感兴趣的人士可以通过提供的链接进行注册。