## 目录 - [⚙️ 技术与工程 (23条)](#⚙️-技术与工程) - [在普通笔记本上运行未裁剪的万亿级稀疏模型成为可能](#💡-技术洞见-1) - [稀疏 MoE 模型在消费级笔记本上的流式运行实现](#💡-技术洞见-2) - [LLM训练的四个阶段及其重要性](#💡-技术洞见-3) - [偏好微调通过人类选择优化模型响应](#💡-技术洞见-4) - [推理微调利用程序验证提升模型能力](#💡-技术洞见-5) - [ComfyUI通过开放权重和API扩展创作者生态](#💡-技术洞见-6) - [CreativAI通过数据层化实现视觉智能的结构化查询](#💡-技术洞见-7) - [循环模型与MoE结合提升推理基准的参数效率](#💡-技术洞见-8) - [智能代理嵌入团队通信提升协作效率的关键路径](#💡-技术洞见-9) - [定期删除外部提示以简化模型维护的策略](#💡-技术洞见-10) - [探索性建模为生成模型引入新的扩展维度探索](#💡-技术洞见-11) - [优先构建深度有状态的合成环境提升代理能力](#💡-技术洞见-12) - [稀疏MoE模型的本地化实现路径](#💡-技术洞见-13) - [避免上下文污染以提高模型推理能力](#💡-技术洞见-14) - [微软研究通过深层环境提升交互代理模型性能](#💡-技术洞见-15) - [避免上下文污染以提升复杂系统性能](#💡-技术洞见-16) - [MiniMax H3的多模态视频生成能力与开源计划](#💡-技术洞见-17) - [ChatGPT 作为家庭日常内容推送引擎的应用场景探索](#💡-技术洞见-18) - [开放权重与多示例输入的短视频生成模式](#💡-技术洞见-19) - [将 SoTA agentic 安全作为默认配置的自动化服务模式](#💡-技术洞见-20) - [前沿模型与开源模型的闭环优化策略提升企业服务效率](#💡-技术洞见-21) - [本地AI代理的设计需兼顾实用性与安全性](#💡-技术洞见-22) - [企业级LLM应用的可控资产化策略](#💡-技术洞见-23) - [🔬 科学与发现 (1条)](#🔬-科学与发现) - [多模态空间推理的子任务训练提升路径](#💡-科研洞见-1) - [💰 商业与战略 (5条)](#💰-商业与战略) - [Stripe创始人分享创业成功的思考与数据分析](#💡-商业洞见-1) - [企业AI采用呈现快速验证到规模化迁移的生命周期](#💡-商业洞见-2) - [语音AI的核心护城河在于数据与基础设施的结合](#💡-商业洞见-3) - [降低 token 成本对 AI 用户行为的潜在影响](#💡-商业洞见-4) - [云服务提供者通过算力投资初创公司成为新趋势](#💡-商业洞见-5) - [🌐 行业与趋势 (3条)](#🌐-行业与趋势) - [欧盟AI合规要求推动软件可追溯性设计的重要性](#💡-行业洞见-1) - [无人化物流闭环的市场价值与产业替代效应](#💡-行业洞见-2) - [AI检测器的不可靠性引发的法律与声誉风险](#💡-行业洞见-3) --- ## ⚙️ 技术与工程 ### 💡 技术洞见 #1 **在普通笔记本上运行未裁剪的万亿级稀疏模型成为可能** 📝 **推文原文** > 突破性进展：现在我们可以在一台普通消费级笔记本电脑上运行完整且未经改动的拥有2.78万亿参数的Kimi K3模型，这一切通过只从NVMe（非易失性存储设备）流式化调用活跃的专家节点实现。 > > “你根本跑不了Kimi K3！”——他们曾放言道。 > > 但通往成功的路径不止一条。 > > 而以下，是一种实现方式： > > **Marco Bambini让Kimi K3在笔记本电脑上顺畅运行** > > 来认识一下Marco Bambini，他完成了在昨天看起来几乎不可能的任务。 > > 他开发了 **WASTE（Weight-Aware Streaming Tensor Engine，权重感知流式张量引擎）**，一个干净、无依赖的C语言推理引擎。这个引擎实现在不做蒸馏、剪枝，也不依赖云的情况下，通过仅从NVMe流式化调用活跃的专家节点，运行完整且未经改动的拥有2.78万亿参数的Kimi K3模型。 > > 没有蒸馏。 > 没有剪枝。 > 没有云服务依赖。 > > 这是完整的开源权重模型。 > > 我们现在就在实验室中验证运行这一成果。 > > **Marco到底完成了什么？** > > Kimi K3是一个稀疏的 **混合专家系统（Mixture-of-Experts system，MoE）**。 > > 这个系统的亮点是，在每一令牌（token）上只有大约4%的权重会被激活。Marco的关键洞察是简单却凌厉的：闲置的专家节点无须驻留在内存中，只需要在调用时能够被快速访问即可。 > > WASTE将模型的“主干部分”（例如注意力机制、共享组件、嵌入层）存储于内存中——整个主干的内存占用约27 GB（基于转换后的容器计算）。 > > 而超过82,000个路由专家节点以高度压缩的残差矢量量化记录的形式存储在硬盘中。当路由器为每一层选择16个专家节点时，WASTE引擎直接从NVMe进行缓存直通式读取（绕过缓存），并将其加载到有限的专家缓存中，剩余的设备内存则作为该缓存的工作区域。 > > 在一台具有64 GB内存和内部固态硬盘（SSD）的MacBook Pro上，我们测得的生成速度为每秒0.32至0.34个令牌，同时内存预算处于舒适范围。而预填充的速度稍快一些。视觉塔正常工作，输出结果与参考实现的偏差在百万分之几范围内。这是真实的完整模型。 > > 转换后的容器大小约为982 GiB（从最初的1.42 TB MXFP4权重压缩而来）。短上下文条件下的最低内存需求略高于29 GB。提高内存预算可显著提升专家缓存命中率，但如果超过某一阈值，可能出现分页问题而导致速度急剧下降。根据目前的消费级硬件性能，“最佳区间”清晰且可量化。 > > **我们如何测试它？** > > 在引擎稳定的当天，我们完成了官方权重的转换、容器验证，并展开系统化测试。 > > 首先，我们在短提示下确认了与PyTorch参考实现的数值一致性。随后转入更长的生成测试、视觉输入和多轮对话测试（使用Kimi专属的XTML格式）。 > > 我们测量了实际解码时间、专家I/O与计算的分工比例、不同内存预算下的缓存命中率，以及在持续高负载运行下的热效应。 > > 我们还测试了搭建在同一C语言库之上的OpenAI兼容服务器，这使我们无需重写代码，即可将模型无缝集成到现有代理逻辑中。 > > **早期观察结果：** > > - 专家I/O为预期中的核心瓶颈。在快速内部NVMe上，硬盘子系统几乎达到了实际可用性能的上限。 > > - 模型架构的稀疏性是整项技术得以实现的关键。如果设计为稠密模型，这种规模的模型在本地运行几乎无望。 > > - **上下文长度**目前更多受限于RAM，而非模型本身。在64 GB硬件上，实际可用的上下文长度可以轻松达到数万个令牌。要实现完整的百万令牌窗口需要更多内存或使用更智能的KV管理方式。 > > - 高计算量的令牌生成速度较慢。长时间的内部推理可能需要数小时完成。面对以代理为导向的工作流，我们已经在尝试优化，精确控制何时调用全面推理功能。 > > 我们将其视为一种研究工具，而非最终产品。每次运行都为我们揭示关于专家节点分布、预取机会，以及纯软件流式推理在普通硬件上极限性能的宝贵信息。 🧠 **深度解读** 通过把 MoE 的稀疏专家以矢量量化、按需从 NVMe 流式加载并保持模型主干常驻内存，可在普通笔记本上运行未裁剪的万亿级稀疏模型——瓶颈从算力转为专家 I/O 与缓存管理，因而应把工程资源优先投入到存储格式、I/O 路径与预取/缓存策略上，而不是单纯扩展内存或算力。 🔗 **[查看原文](https://news.miracleplus.com/share_link/145964)** --- ### 💡 技术洞见 #2 **稀疏 MoE 模型在消费级笔记本上的流式运行实现** 📝 **推文原文** > “你可别撒谎了，Brian，咱们在三台笔记本电脑上测试了，虽然它确实慢，但还能用啊。不过重点是，我现在在运行完整的 Kimi K3 模型了！听说有人吐槽你，但奇怪的是，你每次都能交出成果。” > > **“突破性进展：仅通过 NVMe（非易失性内存协议）流式传输激活的专家（activated experts），成功在消费级笔记本上运行完整、未经修改的2.78万亿参数**Kimi K3**模型。” > > **“他们曾断言‘Kimi K3没法在这种硬件上跑’， > 事实证明，可行的方案有很多种。” > > 以下是其中之一： > > Marco Bambini 成功地在笔记本电脑上实现了 Kimi K3 的完整运行。 > > 认识一下 Marco Bambini，他完成了一件直到昨天还被认为不可能的事。 > 他构建了一个被称为“WASTE”（Weight-Aware Streaming Tensor Engine，权重感知流式张量引擎）的清晰、无依赖的 C 推理引擎，这让完整、未经修改的2.78万亿参数的 Kimi K3 模型得以通过 NVMe 流式传输激活的专家实现运行。 > > 完全没有模型蒸馏（distillation）。 > 没有剪枝（pruning）。 > 也不依赖云端（cloud）。 > 只运行完整的开源全权重模型。 > > 我们目前已经在实验室内运行起这个模型了。 > > ### Marco 的核心创新 > Kimi K3 是一个稀疏专家系统（sparse Mixture-of-Experts system）。 > 在每个 token（标记）处理过程中，只有大约4%的权重会被激活。Marco 的洞察非常简单且直接：那些闲置的专家（idle experts）根本不需要驻留在内存（RAM）中，它们只需要在需要时可以被快速访问即可。 > > WASTE 推理引擎会将模型的“主干”（trunk）（包括注意力机制、共享组件以及嵌入层）保留在内存中——转换容器（container）后，这部分大约占用 27 GB 内存。 > 而另外 82,000+ 的路由专家（routed experts）会以高度压缩的残差矢量量化记录（residual vector-quantized records）的形式驻留在磁盘上。 > 当路由器在每一层选择 16 个专家时，引擎直接从内置的 NVMe（内部固态硬盘）进行缓存绕过读取（cache-bypassing reads），并将其传递到受限的专家缓存（bounded expert cache）中。 > 机器其余的内存则作为缓存的工作空间使用。 > > 在一台配备 64 GB 内存、内部 SSD 的 MacBook Pro 上，我们测得生成速率为每秒 0.32–0.34 个 token，且只需适量的内存预算。 > 预填充操作（prefill）速度稍高一点。模型的视觉模块（vision tower）也能正常运作。Logits（模型输出概率分布）与参考实现的偏差不到百万分之几。这就是完整的 Kimi K3 模型。 > > 转换后，整个容器大小为 982 GiB（原始 1.42 TB 的 MXFP4 权重）。 > 模型运行的最低内存需求略高于 29 GB（对于短上下文）。 > 如果提高内存预算，专家缓存的命中率（cache hit rate）会有所提升；但预算过高会导致换页操作（paging），进而显著降低速度。目前，在现有的消费级硬件上，可以清晰测得一个最佳运行点。 > > ### 测试方式及初步发现 > > 我们转换了官方权重，验证了容器，并在引擎稳定后同一天开始系统化地运行测试。 > 首先，我们对短提示（prompt）输入进行了数值一致性验证，与 PyTorch 基准实现进行了对比。 > 接着，我们逐步测试了长文本生成、视觉输入，以及使用 Kimi 模型原生 XTML 格式的多轮对话。 > > 我们正在测量： > - 墙时解码时间（wall-clock decode timing） > - 专家 I/O 与计算时间的分布 > - 不同内存预算下的缓存命中率 > - 在持续高负载下的散热情况 > > 我们还在使用基于相同 C 库构建的 OpenAI 兼容服务器，方便直接将模型挂载到现有的智能代理循环（agent loops）中，无需任何代码重写。 > > 初步观察如下： > - 如预期，专家 I/O 主导了时间线。在高速 NVMe 上，整个引擎已经接近存储子系统的实际性能上限。 > - 架构的稀疏性是这一切的核心推动力。一个等规模的稠密模型根本无法在本地硬件上运行。 > - 上下文长度目前受限于内存，而不是模型本身。在 64 GB 的硬件配置下，合理的工作上下文长度可舒适地达数万 token；但如果要支持百万 token 范围的窗口，则需要更多内存或更智能的 KV 管理。 > - 在当前速度下，“思考 token”（复杂推理 token）的代价很高。长时间的内部推理独白会占用数小时运行时间。为了服务代理任务，我们已经开始尝试更精细的控制机制，以优化复杂推理的调用时机。 > > 目前，我们将这款引擎视为研究工具，而非成品。每一次运行都能让我们更深入了解专家的分布存储、本地化预取机会，以及软件流式传输在普通机器上推动万亿规模推理的潜力。 > > （1/2）” 🧠 **深度解读** 对稀疏 MoE，保持模型“trunk”常驻 RAM、把大量专家以残差向量量化后紧凑存为 NVMe 记录，并通过直接 I/O + 有界专家缓存按需流式加载，是在普通笔记本上运行未经蒸馏/剪枝的万亿参数模型的可行模式；性能受限于 NVMe I/O 与缓存命中率，优化点在于预取策略、缓存预算调优与KV管理，且对 agent 设计应避免频繁长内部推理以节省极慢的“thinking tokens”。 🔗 **[查看原文](https://news.miracleplus.com/share_link/146072)** --- ### 💡 技术洞见 #3 **LLM训练的四个阶段及其重要性** 📝 **推文原文** > LLM训练的四个阶段，精简讲解： > > （这是一个热门的LLM（大语言模型）面试问题，建议收藏） > > → 预训练（Pre-training） > → 指令微调（Instruction fine-tuning） > → 偏好微调（Preference fine-tuning） > → 推理微调（Reasoning fine-tuning） > > 图中的内容涵盖了所有阶段的详情。 > > 基本模型会将问题理解为需要继续生成的文本，而不是需要回答的请求。在它的训练数据中，问题通常伴随着其他问题出现，因此模型的回答也是生成类似的问题。 > > 预训练之后的阶段可以改变这种行为，每个阶段都通过不同的训练信号来实现这一点： > > 0）随机初始化模型 > 模型的权重是随机数，令其对每个词元（token）的选择接近于均匀分布，因此输出通常是无法理解的文本。 > --- > 1）预训练（Pre-training） > 模型读取大量的文本语料库，并通过反复预测下一个词元来进行训练。 > 这一阶段主要教会模型语法规则以及关于世界的基础知识。 > 同时，模型的大部分基础推理能力也是在这一阶段获得的，且几乎耗费了全部的计算资源。 > 此时，模型擅长继续生成文本，但目标中并没有明确指出如何将问题和答案连接起来。 > --- > 2）指令微调（Instruction fine-tuning） > 在这个阶段，模型在指令和良好响应的配对数据上进行训练，从而学会了一些约定俗成的规则，例如问题应该得到答案，请求归纳应该得到总结。 > 在GPT-3的训练中，OpenAI使用了大约1.3万个人类编写的示例，而预训练的语料库则由数千亿单词构成。 > 知识已经嵌入模型的权重中，这一阶段主要是教授一种响应的格式。 🧠 **深度解读** LLM的训练过程分为四个阶段：预训练、指令微调、偏好微调和推理微调。预训练阶段通过大量文本数据教会模型语法和基础知识，耗费大量计算资源。指令微调则通过配对数据训练模型如何正确响应指令。每个阶段都有其独特的训练信号，逐步提升模型的理解和生成能力，使其从简单的文本生成转变为能够理解和回答问题的智能体。 🔗 **[查看原文](https://news.miracleplus.com/share_link/146072)** --- ### 💡 技术洞见 #4 **偏好微调通过人类选择优化模型响应** 📝 **推文原文** > 3）偏好微调（Preference fine-tuning） > 许多请求本身并没有唯一的正确答案，而监督微调（Supervised fine-tuning）需要具体的目标来作为训练依据。 > 在这种情况下，两个回答会被提交给人类，由人类选择较好的一个。你可能已经在ChatGPT中见过类似的操作，它会询问你哪一个回答更好。 > 这些选择用于训练一个单独的预测模型，来判断人类会更倾向于哪种响应。随后，主模型会更新，以便在该预测模型的评分中获得更高分数。 🧠 **深度解读** 偏好微调通过让人类选择更好的回答来优化模型响应，这种方法不需要唯一正确答案，而是通过人类偏好训练预测模型，进而更新主模型以提高其在预测模型评分中的表现。 🔗 **[查看原文](https://news.miracleplus.com/share_link/146073)** --- ### 💡 技术洞见 #5 **推理微调利用程序验证提升模型能力** 📝 **推文原文** > 4）推理微调（Reasoning fine-tuning） > 在数学和代码问题中，通常只有一个正确答案，并且可以通过程序进行验证。在这种情况下，不需要人类偏好，因为正确性本身就是一种奖励信号（reward signal）。 > 模型尝试解决问题，答案会被验证，正确时会得到奖励。 > DeepSeek通过GRPO（Guided Reinforcement Policy Optimization, 引导式强化策略优化）方法对R1进行了这种训练，结果模型在此过程中展现出以下行为： > 如分步骤解决问题、回溯并修正自己错误的能力，这些行为并未通过具体示例进行演示，而是训练过程中自然形成的。 > > 不过，需要注意的是，阶段4只有在可以通过程序验证答案时才能发挥作用，例如数学和代码是天然具有这种特性的领域。 > 但对于技术支持回复、RAG答案（检索增强生成，Retrieval-Augmented Generation）或总结这类请求，没有明确的正确输出可供验证，因此奖励信号必须从其他地方获取。 > > 我曾写过一篇完整的解析，详细介绍了各实验室如何处理这一问题的方案，从RLHF（基于人类反馈的强化学习）到GRPO，以及替代验证器的方式。详情见下文。 🧠 **深度解读** 推理微调通过程序验证来提升模型能力，尤其在数学和代码领域，正确性作为奖励信号引导模型优化。DeepSeek使用GRPO方法训练模型，使其自然形成分步骤解决问题和自我修正的能力。然而，这种方法仅适用于可程序验证的领域，其他领域需另寻奖励信号。 🔗 **[查看原文](https://news.miracleplus.com/share_link/146073)** --- ### 💡 技术洞见 #6 **ComfyUI通过开放权重和API扩展创作者生态** 📝 **推文原文** > 推文原文: > 感谢@ComfyUI团队的支持 🙌 > 更多画布、更丰富的自定义节点、更灵活的工作流， > 并且很快还会开放权重（weights，模型可训练参数），让你可以自由构建任何你想要的复杂图形！🧑‍🎨✨ > > ✨ MiniMax H3现已通过Partner Nodes（合作节点）集成到ComfyUI中： > → 多模态输入/输出（Multimodal I/O）：文本转视频（T2V）、首/尾帧（First/Last Frame）、全局参考（Omni Reference） > → 每段视频支持原生立体音频（Native stereo audio） > → 最高支持2K分辨率，5到15秒的视频，24帧/秒（FPS） > → 可以直接编辑角色、场景、对话和语音 > > API接口现已上线，权重开放（Native open-weight support）也即将推出！ 🧠 **深度解读** ComfyUI通过开放API和即将开放的权重，提供了一个灵活的多模态短视频创作平台，允许创作者通过自定义节点和工作流构建复杂图形。这种策略不仅占领了创作者的工作流，还通过开放生态促进了社区的持续增长和扩展。 🔗 **[查看原文](https://news.miracleplus.com/share_link/146074)** --- ### 💡 技术洞见 #7 **CreativAI通过数据层化实现视觉智能的结构化查询** 📝 **推文原文** > 推文原文: > RT @moElhoseiny 昨天我跟你们聊到了一个困扰我多年的难题。 > > 而今天，我终于突破了——并有两个重磅消息要宣布👇 > **1. CreativAI 正式公开——这是 Physical 和 Visual AI（物理与视觉人工智能）的 SQL（结构化查询语言）层；还能够让视觉智能变得可验证、可信赖且具有成本效益。** > **2. 我们推出了一款可以立即使用的产品。没有等待名单，不只是愿景展示，而是真正可以现在试用的东西👇 [链接]** > > 无论你是对 AI 探索感兴趣的个人，正在开发下一代应用的开发者，还是希望释放视觉数据价值的企业，CreativAI 都已为你准备好。你可以选择云端部署、本地部署，或通过 API 集成，灵活适配你的工作流程。 > > 感谢我们的首席创意官 Waleed、顾问 Rob Ferguson 和 Abdul Jarrar，以及 Google for Startups、AWS Startups、Microsoft for Startups 和 NVIDIA for Startups Inception 的支持。 > > 这些年来，我一直专注于视觉-语言（vision-language）人工智能的基础研究——包括在 KAUST、Stanford、Meta FAIR 和 Adobe 进行研究，并为该领域奠定了许多如今被广泛认可的重要基石：如 CLIP 的线性版本（ICCV13；[链接]）以及首个视觉大语言模型（vision LLM）——VisualGPT（CVPR22）和 MiniGPT-4（Arxiv'23, ICLR24）。 > > 在这个过程中，我发现视觉人工智能（Visual AI）领域的最难问题发生了转变。 > 各种数据类型都实现了突破：文档有了强大的搜索引擎，表格数据有了 SQL，代码有了 GitHub。每一个革新都赋予了混乱的数据一种结构，让它们可以被查询、验证并加以利用。而视觉数据——我们生产的最大数据类型，占据着超过 80% 的互联网流量，全球有十亿台摄像头并持续增长——却从未实现像 SQL 那样的可访问性。 > > 更深层的问题是：这些模型变得非常强大，但对于你的业务中最关键的事件，却极少出现在预训练数据中。一个通用模型也许从未见过这些事件，因此也无法在你的现实环境中识别它们。 > > 这正是我们在 CreativAI 所打造的。 > 无论是摄像头、机器人、直播流，还是多年的存档内容，只要对准镜头，我们的**Data Plating（数据层化）**技术就能在事件发生的瞬间，将原始像素转化为有结构的数据：实体、事件和行为。不只是字幕，也不仅仅是元数据，而是直接将视频变成像表格一样的行与列。直播内容实时转化，存档资源化身为可以查询的知识库。你的团队可以用自然语言查询，通过 API 为你的智能系统服务，或者在设备端让机器人通过分析闭环决策，嵌入你的各类工作流中。 > > 每一行数据都回溯到它的来源时刻——因此每一个结果都可以被追溯、验证并安全构建。这是一个有结构的全局视图，也是唯一可信的数据源，每个人都从同一张记录中获取信息。 > > 而这正是预训练差距得以弥合的地方：你可以教给它你的领域知识——你的事件、你的实体，以及那些重要却少见的特殊场景。CreativAI 能够学习到通用模型永远无法掌握的内容，让你的独特领域中那些长尾信息也能像其他数据一样变得可被查询。 🧠 **深度解读** CreativAI通过将视频和视觉流即时“Data Plating”为带有行级溯源的表格，实现了视觉智能的结构化查询。这种方法不仅提供了SQL风格的查询能力，还允许域内学习，将视觉数据转化为可验证、可操作、可集成的基础设施，弥合了预训练模型的差距。 🔗 **[查看原文](https://news.miracleplus.com/share_link/146076)** --- ### 💡 技术洞见 #8 **循环模型与MoE结合提升推理基准的参数效率** 📝 **推文原文** > RT @huskydogewoof 🔥 > 𝐍𝐞𝐰 𝐛𝐥𝐨𝐠:《迈向正确实现的循环模型（Looped Models）——第一部分》 > > 循环模型（Looped Models）通过在不同深度上重复利用同一组权重（weights），在计算量和参数量之间提供了更优的平衡，尤其是在推理任务中具有潜力。 > > 但是： > 1）当训练和推理的 FLOPs（浮点运算次数，衡量计算开销的指标）匹配后，这种优化还能保持吗？ > 2）到底哪些架构设计选择才是真正关键的？ > > 我们进行了苹果对苹果（apples-to-apples）的对比实验，覆盖从 Ouro 到 Huginn 的模型。总体来看，Huginn 表现更优秀，最大的提升来源于“中间循环”（loop-in-the-middle，也称“夹心”设计）和输入注入（input injection），但它们各自带来的好处有所不同。 > > 在基于 **5000 亿（500B）tokens 的训练**中，一个 **8B-A0.8B Huginn MoE（专家混合模型，Mixture of Experts）** 在多个推理基准测试（包括 GSM8K）上表现接近或超越了一个 **32B-A3.2B 前馈式 MoE（Feedforward MoE）**。具体数据为：Huginn 实现 83.6%（对比前者的 80.8%），同时在**训练和推理 FLOPs 匹配的情况下**使用了 **75% 更少的常驻（resident）参数**。 > > 更多细节和博客链接请查阅评论区↓ 🧠 **深度解读** 在匹配 FLOPs 的公平条件下，循环权重共享 + MoE，并优先采用 loop-in-the-middle 与输入注入，可显著提升推理基准的参数效率——以更少常驻参数达到或超过更大前馈 MoE 模型的性能。 🔗 **[查看原文](https://news.miracleplus.com/share_link/146079)** --- ### 💡 技术洞见 #9 **智能代理嵌入团队通信提升协作效率的关键路径** 📝 **推文原文** > RT @snowmaker 最近几周，我每天都在使用QM（Quantum Mechanic，一种长效智能代理工具），它成为我在YC（Y Combinator，一家著名的创业孵化器）内完成工作的主要助手。 > > 让我深感惊艳的是，拥有一个长期驻留在公司Slack（团队协作工具）的智能代理，并且能够完全访问公司数据，是多么有用。 > > 在使用QM之前，很多工作需要在Slack和某些代理/LLM（大语言模型，Large Language Model）产品之间复制粘贴，非常繁琐。 > > 使用QM后，这些工作直接在Slack频道中完成，所有人都能实时看到整个过程。 这是我首次看到一个真正可行的多人协作AI版本。 🧠 **深度解读** 把长期存在、能访问公司数据的智能代理直接嵌入团队通信渠道，从个人单点调用转为在公共频道可见的多人协作流程，是提升企业级代理采用率和产生持续价值的关键路径。 🔗 **[查看原文](https://news.miracleplus.com/share_link/146080)** --- ### 💡 技术洞见 #10 **定期删除外部提示以简化模型维护的策略** 📝 **推文原文** > 转发 @rohanpaul_ai 关于Claude Code的创作者Boris Cherny（@bcherny）的发言： > > “对于那些不是在开发代理型(agentic)产品，而是使用Claude Code的人，我建议每隔6个月，删除你的`claude.md`文件，删除你的技能(skills)，以及删除你的钩子(hooks)。然后看看模型会怎么表现。这可能会让你感到惊讶。 > > 针对Opus 5版本，我们强烈建议尝试删除所有这些东西，因为模型可能不再需要此前版本必需的那些复杂指令。” > > ——在Y Combinator创业学校2026 (Y Combinator Startup School 2026)发表的演讲 > > （完整视频链接请见评论，来自“Y Combinator”的YouTube频道） 🧠 **深度解读** 定期（例如每6个月）删除并检验外部提示/技能/钩子，以发现模型已内化的能力并据此简化工程维护；对 Opus 5 这类新模型应特别尝试彻底删除这些工件。 🔗 **[查看原文](https://news.miracleplus.com/share_link/146081)** --- ### 💡 技术洞见 #11 **探索性建模为生成模型引入新的扩展维度探索** 📝 **推文原文** > 很高兴分享我们关于“探索性建模（Explorative Modeling）”的新成果！ > > 通过在训练期间进行多代搜索，并从最佳匹配每个训练样本的结果中学习，我们为生成模型（Generative Models）开启了继数据规模和模型规模之后的第三个扩展维度——探索（Exploration）。 > > 我们发现，在参数和数据之外，还有一个新的预训练轴：探索。 > 随着探索的扩大，成效在图像、视频和语言模型中都能单调提升，并实现端到端（End-to-End）生成。 > > 最简单的情况下，这只是一个 `for` 循环的实现。 > > 现在，为大家正式介绍“探索性建模（Explorative Modeling）”！ > > 核心要点总结： > - 探索带来的收益随规模增长：当数据规模增加时，收益从 7% 提升到 36%；当参数规模增加时，收益从 13% 提升到 23%；而在计算量提升 3 倍的情况下，收益翻倍。 > - 在接近当前最优（~SOTA, State-of-the-Art）的基线上引入探索，可实现： > - 数据效率提升 6.2 倍 > - 浮点运算效率（FLOP Efficiency）提升 4.1 倍 > - 参数效率提升 47% > - 在 ImageNet 上实现无引导的接近 SOTA 的 1.43 FID 值 > - 探索能够让你在训练计算量与泛化能力之间实现权衡，并扩大生成模型的端到端能力。 > - 端到端的探索性模型（Explorative Models, XMs）在控制任务中的表现可匹敌扩散模型（Diffusion Models），同时推理计算量减少高达 256 倍！ 🧠 **深度解读** 将训练时的候选生成+按样本挑选（exploration）作为独立的可扩展维度，可以显著提高数据/算力/参数效率并把训练 compute 转化为更端到端、更低推理成本的生成性能——实现路径简单（内层多次采样循环+选择最佳）且收益随模型/数据规模扩大而增长。 🔗 **[查看原文](https://news.miracleplus.com/share_link/146082)** --- ### 💡 技术洞见 #12 **优先构建深度有状态的合成环境提升代理能力** 📝 **推文原文** > 微软（Microsoft）新研究。 > > 这项研究聚焦于如何大规模训练计算机使用代理（computer-use agents）。 > > 近期的研究流程能够成批生成合成环境（synthetic environments），但瓶颈已从环境数量转移到如何让环境本身更具质量。Echoverse通过将规范（specifications）编译为具备状态的应用程序（stateful applications），并基于这些应用程序自身的数据库对任务打分。然后运行一个共同进化循环（co-evolution loop），每次运行读取每个评分结果两次：一次用来修复环境、其任务以及验证程序（verifier）；另一次用来生成模型的训练信号（training signal）。 > > 在相同领域内，浅层环境（shallow environments）将实时场景的准确率从基础模型的80.0%降低到75.0%；而深层环境（deep environments）则将准确率提升，从80.0%提高到85.0%，从48.0%提高到65.0%。 > > 修复单个环境后，基于其训练的模型表现从16.2%跃升至38.5%。在十二个环境中，一个9B模型（参数规模为90亿的模型）在十四个评估数据集（evaluation splits）上从36.5%提升至67.1%，与用于教学的更大前沿模型（frontier model）的表现仅相差十四个百分点。 > > 他们发布了四个环境作为基准（benchmark），附带应用程序、种子数据（seed data）和带有具体评分标准的评估工具（grounded graders）。 🧠 **深度解读** 优先构建深度、有状态且自带判分器的合成环境，并用协同进化（read-each-rollout twice：修复环境/判分器 + 作为训练信号）来迭代环境与模型，比单纯扩大量级或浅层环境，能更快且更低成本提升代理能力。 🔗 **[查看原文](https://news.miracleplus.com/share_link/146084)** --- ### 💡 技术洞见 #13 **稀疏MoE模型的本地化实现路径** 📝 **推文原文** > 24小时运行完整的Kimi K3 Frontier模型，设备竟是一台笔记本电脑。 > > 首先，这件事本身就令人难以置信，居然真的可能实现。 > > 这种配置非常实用，并且大大减少了浪费。它是一种极具创新意义的开源车库发明，也是我们能做到的技术奇迹的冰山一角。 > > 我已经调整了一些配置以提高速度，认为通过硬件改装（modifications）还有可能获得更多性能提升，我会在本周末测试这一点。 > > 不过，目前系统速度还不足以胜任简单的聊天环境要求。在一台笔记本电脑上运行，虽然不满速，但足以处理几十页内容。 > > 真正令人兴奋的本地化用途在于代码编写和智能代理（agent）场景。目前，这是迄今为止最优秀的本地代码开发平台，哪怕存在本地系统上下文窗口的限制。 > > 在智能代理方面，它的运行表现已经超越了其他所有本地AI模型。 > > 迄今为止的成果都相当惊艳，但这还只是序幕。它表明我们正在拉近“前沿AI”与本地部署之间的距离。 > > 在我看来，这可能是今年AI领域最重要的事件之一。 > > 此外，这也展现了开源AI技术，尤其是那些来自资源受限环境中“车库工程师”的创新潜力。我们获得了一个让成本无法被AI代币（AI token，指基于云服务付费的计算模型成本）正当化的技术实现方式的机会。 > > 我怀疑我们仍然能通过更多硬件调整，进一步大幅度提高这一巨型模型的速度。 > > 正如我提到的，未来36个月内，我们极有可能实现“神话级AI”（mythos-class AI）装进口袋的目标。 > > 至于那些关于“这太危险了”的争论，将会像千禧年问题（Y2K）的恐慌一样显得过度紧张。 > > 那些从一开始宣称“你不可能在这台设备上运行Kimi K3”的人——他们错了。这是条可行之路之中的一个例子： > > 马克·班比尼（Marco Bambini）刚刚为我们带来了完整Kimi K3模型在笔记本电脑上的实现。 > > 认识一下马克·班比尼，他完成了一件在昨天还被认为绝不可能的壮举。 > > 他构建了一个名为WASTE（Weight-Aware Streaming Tensor Engine，权重感知流式张量引擎）的工具，这是一种干净、无依赖的C语言推理引擎。凭借这一工具，它能够通过从NVMe（非易失性存储器，常见于高速固态硬盘）流式加载激活的专家模块，运行完整且未经裁剪的Kimi K3模型（其参数规模达2.78万亿）。 > > 不需要萃取模型（distillation）。 > 不需要修剪参数（pruning）。 > 不需要云计算支持。 > 仅使用完整的开源模型。 > > 我们目前正在实验室中运行这一配置。 > > ### 马克究竟做了什么？ > Kimi K3是一个稀疏的专家混合（Mixture-of-Experts, MoE）系统。 > > 每个令牌（token）输入时，只有约4%的权重会被调用。马克的设计理念简单而精准：闲置的专家模块并不需要长驻在运行内存（RAM）中，它们只需要能够在需要时被及时调用即可。 > > WASTE让模型的“主干部分”（包括注意力机制、共享模块和嵌入层）常驻在内存中，大约占用了27 GB存储空间。而82,000多个按路由分配的专家模块则作为高度压缩的残差矢量量化记录存储在硬盘中。当路由器为每层选中的16个专家模块运行时，直接从内部NVMe中进行读取，并跳过缓存加载到受限的专家缓存中。 > > 机器所有剩余的内存空间则作为缓存的工作区。 > > 在使用一台内置SSD的64 GB MacBook Pro时，我们测量到的性能为0.32-0.34令牌每秒（tokens per second），且运行内存预算维持在舒适范围内。初始化时间稍高，视觉模块也正常运行，并且模型的预测值与参考实现的误差仅为百万分之几。这是一个完全真实、匹配的模型。 > > 转换后的容器大小为982 GiB（原始的1.42 TB MXFP4权重数据减少后）。对于短上下文（context scenes），最小内存需求为29 GB以上。增加运行内存空间，会提升缓存命中率；但超出最佳预算范围后，因内存分页行为（paging）会导致速度大幅下降。目前消费者硬件上的最佳体验点非常清晰且可测量。 > > ### 我们是如何测试的？ > 我们完成了官方权重的转换，验证了容器后，在引擎稳定的当天开始进行系统性的测试。 > > 首先，我们在短提示的输入上确认了数值精度与PyTorch参考实现的一致。随后扩展到更长的文本生成、视觉输入以及Kimi原生的XTML多轮聊天格式。 > > 同时，我们监测了墙钟解码（wall-clock decode）时间、专家模块的输入/输出与计算分配比例、在不同内存预算下的缓存命中率，以及在高负载下的热性能表现。 > > 此外，这是一个基于兼容OpenAI的服务器测试架构，运行于同样的C语言库之上，因此我们可以直接在现有的智能代理循环中无缝应用该模型，无需重写代码。 > > ### 目前的一些初步观察： > - 正如预期，专家模块的输入/输出占用主要时间。在高速内置NVMe上，推理引擎已经接近当前存储子系统的实际上限。 > - 架构的稀疏性是实现这一目标的关键。如果是密集型模型，这样的规模在本地使用上简直是“宣判死刑”。 > - 当前上下文长度更多地受限于内存而非模型本身。在64 GB硬件上，可稳定处理数万令牌的上下文内容。若要实现完整的百万令牌窗口，则需要更多内存或更智能的键值（KV）管理策略。 > - 在当前速度下，每个“思考令牌”（thinking token）的成本很高。较长的内部推理过程会花费数小时完成。对于智能代理工作场景，我们已经开始测试如何更精确地控制完整推理的触发场景。 > > 我们将此视为一个研究工具，而非最终产品。每次运行都会带给我们有关专家模块本地化、预取机会，以及纯软件流式传输在消费级硬件上推进万亿参数推断的具体潜力的更多启发。 🧠 **深度解读** 对稀疏 MoE 模型，按需从 NVMe 流式加载已激活的专家（保持模型干线常驻内存并用紧凑磁盘格式存专家）是将‘前沿模型’迁移到消费级本地设备的可行工程路径。 🔗 **[查看原文](https://news.miracleplus.com/share_link/146085)** --- ### 💡 技术洞见 #14 **避免上下文污染以提高模型推理能力** 📝 **推文原文** > 当我意识到自己从一开始就扮演了“对抗性导师”（adversarial advisor）的角色，并引入了上下文信息“腐烂”（context rot），从而导致模型陷入这种无法自拔的困境时，我的反应是这样的：https://t.co/G9lqjRonjX > > “在比赛期间，我的代理模型（agents）曾一度在性能上陷入瓶颈，完全止步不前。我在这里分享一下当时的经历。 > > 在排行榜上，我最终排名第七（用户名：sankalp1999）。下图展示了最快选手（黄色）与我的提交记录（红色）的对比曲线。可以看到，在7月25日左右出现了一个高峰期。比赛的前几天，我采用了自动化循环的方式运行模型（只要我还有足够的Codex代币用量，而且Tibo一直重置），但循环很快卡住了，运行时间停在约800微秒。 > > 我尝试手动调整，但进展非常缓慢，而GPT 5.6 SOL高/超高级模式（gpt 5.6 sol high/xhigh）无法找到结构上的改进方法。后来我打开了自己的代码文件，大致浏览了一遍。发现源代码长度有15,000行，里面包含了大量CUDA代码和tcgen指令。 > > 我怀疑，可能是因为我的文件中存在的上下文信息腐烂（context rot）问题，加上我的编排循环也出现了上下文信息腐烂的现象，导致模型无法进一步优化。 > > 更早的时候，出于想借鉴某些面板设计的灵感，我引入了tc-gen大神‘Gau-Nernst’的QR分解内核（qr decomposition kernel，在QR分解比赛中排名第二）。这种方法在某些领域确实有效，但随着时间推移，我发现它逐渐扩散到其他领域，导致这些地方的表现并不理想，最终污染了整个文件。 > > 所以，我决定从头开始重写整个代码。同一时期，Opus 5上线了，因此我购买了一份100美元的Claude Max订阅。我用自己之前最好的提交结果作为种子，向Opus 5请求一个基于纯Triton的通用解法。最初时间停在3000微秒左右，但在两天时间内，模型通过寻山算法（hillclimb）将时间优化到500微秒。 > > Claude Opus 5在从0到1阶段表现极其惊人，但当问题变复杂后，它就容易陷入停滞。有趣的是，我的纯Triton重写方案在超越我之前提交的版本时，代码量只有最初的十分之一，仅1500行。 > > 我特别尝试引导模型做到以下两点： > > 1. 保持所有内容由纯Triton实现，除非特别必要，否则不要使用Gluon或tcgen。 > 2. 删除所有厂商函数（例如cuSolver的函数）。否则，模型可能在进行lib函数的排列组合时卡住，特别是对GPT 5.6系列来说。这种策略最终带来了不错的成果。 > > 下面是我总结的一些经验教训： > > - 必须尽一切努力避免上下文信息腐烂（context rot）。LLM（大语言模型）倾向于将某些在一个领域有效的代码复制到其他领域，但如果它们对这些代码并不非常自信，这种方式可能会导致性能显著下降。 > > - Triton或更高级的领域专用语言（DSLs）更容易让模型推理。它们还会自动处理许多底层调优工作，让模型聚焦到问题本身，而不是纠结于Gluon语法或过于细粒度的细节。只有在绝对必要时，才使用Gluon/CUDA。 > > - 总的来说，和Gluon或CUDA这种较底层语言相比，模型在使用Triton等更高阶语言时自信度更高。当然，这可能随着Opus 5的推出有所改变（Opus 5截至知识截止日期为2026年5月下旬），因为我看到它能够自主完成调度（swizzling）任务，而无需我提供任何启发性思路。 > > 当我引入Gau-Nernst内核并让模型自主运行时，发生了一些上下文漂移（context drift）。我使用的是GPT 5.6 SOL，原本只想为模型提供灵感种子，但实际上却适得其反——根据“想法多样性”（idea diversity）相关研究，我自己成了那个“对抗性导师”（adversarial advisor）。 > > 【推测】另一个观察是，模型在进行优化时，通常会经历一系列从A -> B -> C -> D的渐进式思考过程，直到达到一个突破点或高级优化。这可能与瓶颈点的逐步转换（shifted bottlenecks）顺序有关。 > > 如果你将GPT 5.6 SOL暴露于它所不知道的信息领域，或者让它面对自己不够自信的优化方案，那么即使这种优化奏效，也可能使模型陷入局部最优解的困境，会被困很久。我倾向于认为，最好让模型通过它自身的分布观察到那些逐步转移的瓶颈点（shifted bottlenecks），然后自行得出结论。模型越大（无论是智能还是知识库），它就越能快速跳过初始阶段。” 🧠 **深度解读** 避免在长期自治的 LLM 循环中注入大且具体的示例或外部实现；优先使用高层 DSL、精简代码和移除复杂第三方函数以减少模型的上下文污染，从而提高可推理性和避免陷入局部最优。 🔗 **[查看原文](https://news.miracleplus.com/share_link/146086)** --- ### 💡 技术洞见 #15 **微软研究通过深层环境提升交互代理模型性能** 📝 **推文原文** > 微软的一项新研究。 > > 这次研究聚焦于大规模训练计算机使用代理（computer-use agents）。 > > 近期的流程能够大批量生成合成环境（synthetic environments），从而将瓶颈从“环境数量”转移到“每个环境内部质量”。Echoverse 将规格（specifications）编译成具备状态的应用程序（stateful applications），这些应用程序的任务会根据自身数据库进行评分。随后通过共进化（co-evolution）循环运行流程，每次评分的结果会被读取两次：一次用于修复环境、任务以及验证器，另一次作为模型的训练信号。 > > 在相同领域中，简单的浅层环境（shallow environments）将在线场景准确率（live-site accuracy）从原始模型（base model）的80.0%降至75.0%。而复杂的深层环境（deep environments）则将准确率从80.0%提升至85.0%，以及从48.0%提升至65.0%。 > > 修复单个环境可以将基于该环境训练的模型准确率从16.2%提升至38.5%。在12个环境中，一个拥有90亿参数的模型（9B model）在14个评估测试中准确率从36.5%升至67.1%，已接近其教师模型（frontier model）的性能，仅差14个百分点。 > > 他们还发布了四个环境作为基准（benchmark），并提供了相关应用程序、初始数据（seed data）和参考评分器（grounded graders）。 > > 论文链接：https://t.co/thTetOjep1 > > 关注我们学院里的热门AI论文追踪：https://t.co/1e8RZKs4uX 🧠 **深度解读** 在训练交互代理时，优先把工程投入放在环境深度、基于应用状态的打分器与环境—模型的共演化修复循环上，比大规模合成环境的数量扩张更能提升模型效果并缩小与更大模型的差距。 🔗 **[查看原文](https://news.miracleplus.com/share_link/146087)** --- ### 💡 技术洞见 #16 **避免上下文污染以提升复杂系统性能** 📝 **推文原文** > 在比赛期间，我的模型一度遇到了明显的性能瓶颈，特意在这里分享一下这个小故事。 > > 我在排行榜上最终排名第七（用户：sankalp1999）。图中展示了最快参赛者（黄色）和我（红色）的原始提交曲线。从图中可以看到，7月25日左右有一个峰值。比赛的头几天，我在运行一个自动化循环（autonomous loop），只要没有用光Codex的tokens（Codex提供的计算单位）且Tibo继续重置，我的循环就会持续工作。但很快程序卡在了800微秒上，无法继续优化。 > > 我尝试手动调整方向，但进展极为缓慢，而GPT 5.6 sol（高阶/超高阶模型）在结构性改进方面也没法帮上什么忙。后来我打开了我的代码文件，发现这是一份有1.5万行代码的长文件，其中有许多CUDA部分，并包含了tcgen（Tensor Core生成）指令。 > > 我怀疑模型无法进一步优化的原因是我的文件和我的调度循环（orchestration loop）都发生了“上下文漂移”（context rot，指长期运行过程中理解上下文的能力变差）。 > > 某个节点上，我引入了(tc-gen大神) Gau-Nernst的QR分解（QR decomposition）内核（该内核在QR分解竞赛中获得第二名）作为模块启发。这的确在某些区域起到了作用。然而，随着时间推移，这些逻辑逐渐扩散到了其它区域，结果却并不理想，导致了整个文件被污染。 > > 为了重新优化，我决定完全重写代码。与此同时，Opus 5正式推出，于是我花了100美元订阅了Claude Max版本。我用之前最优版本的代码作为种子，与Opus 5合作，让它生成了一个纯Triton（Triton是一种高级编程语言框架）基础上的通用方案。起初模型运行时间为3000微秒，但两天之内，它通过爬坡优化（hillclimbing）将时间缩短到了500微秒。 > > Opus 5的表现令人震撼，在从0到1的阶段尤为强大，但事情变得复杂时，它似乎容易陷入瓶颈。最有趣的是，当我的纯Triton代码超越以前版本时，代码规模只有原来的1/10——从最初的1.5万行缩减到了1500行。我特别引导它： > > 1. 完全使用纯Triton，不碰Gluon或tcgen，除非确实必要。 > 2. 删除所有供应商函数（比如cuSolver库函数），因为这些函数会让模型在将库函数排列组合的过程中迷失方向，尤其是GPT 5.6系列。这样的操作最终证明是值得的。 > > 一些从中得出的经验教训包括： > 避免上下文漂移（context rot）至关重要。大语言模型（LLMs）喜欢在一个区域认为可行的内容复制到其他区域，而这可能在模型缺乏绝对信心时导致性能下降。 > > Triton或其他更高级的领域特定语言（DSLs）更易于模型理解，它们在底层调优上花费的功夫更少，帮助模型可以专注于解决问题，而不是纠结于Gluon语法或微小的细节。因此，只在确实需要时才使用Gluon/CUDA的内容。 > > 简单来说，模型在面对像Gluon或CUDA这样低层次的语言时显得信心不足。不过，随着Opus 5的推出（其知识截止时间至2026年5月底），这一情况可能有所改善。我观察到它甚至能够在没有任何输入提示的情况下自动完成“数据交换（swizzling）”。 > > 当我引入Gau-Nernst内核并让模型自主工作时，发生了一些上下文漂移。我当时使用的是GPT 5.6 sol。在试图为模型注入新想法时，反倒让我自己成了模型的对抗性顾问（adversarial advisor，根据“想法多样性（idea diversity）”文献的描述）。 > > 此外，有一个值得探讨的观察是，模型倾向于经历一系列步骤（a->b->c->d）后，才能最终达到突破点或实现高级优化。这可能与“变换的瓶颈（shifted bottlenecks）”的次序有关。如果你让一个模型处理超出其知识范围的东西，或者它不太有信心的优化方向，尽管这种优化偶尔会奏效，但这会将你困在“局部最优”的位置很久。相比之下，让模型自主通过观察“瓶颈转换”来达成结论会更好。更大更强的模型（在智能和知识上）跳过初期步骤的速度也会更快。 > > 最终，我在GPU模式下的Cholesky问题（线性代数竞赛系列）取得了第七的成绩。感谢Codex、Tibo、Claude和那家最棒的纽约公司Modal。https://t.co/8tmsrWwdGV 🧠 **深度解读** 避免上下文污染：把复杂系统拆成小、用高层 DSL 实现并剔除供应商黑盒，能显著降低 LLM 的组合搜索负担并防止次优模式扩散，从而帮助模型跨越局部极值实现实质性性能提升。 🔗 **[查看原文](https://news.miracleplus.com/share_link/146088)** --- ### 💡 技术洞见 #17 **MiniMax H3的多模态视频生成能力与开源计划** 📝 **推文原文** > 从单个剪辑到完整内容，保留声音、角色和创意意图。 > > **MiniMax H3** 已正式上线 @LeonardoAi。开放权重（weights，模型参数）即将推出，为创作者提供更多自由，根据自己的品牌、角色和工作流调整 H3。 > > 非常感谢 Day 0 的支持 💜 "MiniMax H3 已上线 Leonardo。" > > 大部分视频模型只能生成剪辑，而 H3 不仅生成剪辑，还提供音轨——并且你的角色形象和声音能根据参考（reference）精准锁定。你可以期待： > > - 广告、电商、游戏和用户界面（UI）的商业级质量 > - 同类别中性价比最佳的选择 > - 一款轻量化的全能多模态（multimodal）模型 > > 专为一键生成成品内容而设计：品牌预告片、产品视频、时尚短片与互动角色形象内容。 🧠 **深度解读** 轻量化的全多模态、参考驱动(one-shot)视频生成，联合平台上线并随后开源权重，是一条能快速把生成模型转化为可直接替代商业内容制作的可复制路线。 🔗 **[查看原文](https://news.miracleplus.com/share_link/146089)** --- ### 💡 技术洞见 #18 **ChatGPT 作为家庭日常内容推送引擎的应用场景探索** 📝 **推文原文** > 听到的一个特别酷的 ChatGPT（生成式预训练变换模型）应用场景： > > 连接你全家的日历，并结合孩子们的兴趣爱好。 > > 每天早上，在送孩子上学的路上，用它生成一段播客，聊聊一个孩子下午的足球比赛、另一个孩子即将到来的生日、一点新闻等等。 🧠 **深度解读** 把 LLM 当作实时、情境化的“内容推送引擎”来服务日常短时刻（micro-moments），能创造差异化消费产品；但这种模式对连接性、上下文管理和隐私保障的工程要求比典型的单次查询型应用更高，产品化路径应同时把可控的本地/边缘处理、精简上下文与强权限模型作为核心能力来实现。 🔗 **[查看原文](https://news.miracleplus.com/share_link/145996)** --- ### 💡 技术洞见 #19 **开放权重与多示例输入的短视频生成模式** 📝 **推文原文** > 特别感谢 @magnific 将 H3 带给了全球创作者们 🎬 > > 对于设计师和视觉叙事者来说，这不仅仅是一个全新的工具：H3 的权重（weights）即将开放，这意味着社区可以研究它、微调（fine-tune）它，并在此基础上构建全新的创意工作流。 > > 让每个人都能享受开放的视频生成技术。 > > #MiniMaxH3 由 @Hailuo_AI 带来的 MiniMax H3 已正式登陆 Magnific！ > > 添加角色、动作与节奏，其余的交给模型来搞定： > → 最多支持上传 9 张图片用于角色和风格设定 > → 支持 3 个视频以控制动作和镜头 > → 输出 2K 分辨率，时长 5 到 15 秒 > > 立即在 Magnific 上试用：https://t.co/ZEjustpMIg 🧠 **深度解读** 开放权重+多示例分离式条件化（最多9张角色/风格图 + 3个运动/镜头视频，生成2K、5–15s短片）构成一个可复制的产品化模式：用短时高质输出降低计算与工程成本，用多示例输入提供可控性，再通过开源权重吸引开发者/微创新者构建垂直工作流与定制化模型。 🔗 **[查看原文](https://news.miracleplus.com/share_link/146094)** --- ### 💡 技术洞见 #20 **将 SoTA agentic 安全作为默认配置的自动化服务模式** 📝 **推文原文** > 让人们开发安全的应用程序的唯一办法，就是为他们自动完成这些工作。 > > 我非常喜欢Bolt（一个即时支付工具）的方法。 > > 以下是当你点击发布（Publish）按钮后，他们所做的一切： > > 1. 安全代理（security agent）开始对你的应用进行深度扫描 > 2. 自动修复发现的任何问题 > 3. 确保应用程序依然能够正常构建 > 4. 为每一个新的更改生成版本记录，便于随时回滚 > > “今天，我们为每一个Bolt项目注入了一个安全工程师。” > > 人工智能（AI）让开发变得更快，同时也让攻击者的速度更快。 > > 因此，我们让业界最先进（SoTA，State of the Art）的主动安全（agentic security）成为默认配置，并且完全免费提供。🧵 https://t.co/dkeWpdLgg6 🧠 **深度解读** 将 SoTA agentic 安全作为默认、免费、内嵌于发布流程的自动化服务——不仅检测，还自动修补、确保构建并为每次改动建立可回滚版本——是把安全变成开发者行为中的‘无感产出’的可复制模式。 🔗 **[查看原文](https://news.miracleplus.com/share_link/146095)** --- ### 💡 技术洞见 #21 **前沿模型与开源模型的闭环优化策略提升企业服务效率** 📝 **推文原文** > 年收入10万美元的客户能享受白手套服务，而年付10美元的客户只能用自助帮助中心。@DecagonAI 的观点是，人工智能（AI）正在弥合这一差距，而企业对此买账了。 > > 联合创始人 Jesse Zhang 和 Ashwin Sreenivas 与 a16z 的 Kimberly Tan 和 Sarah Wang 一起探讨了他们在服务全球最大银行、航空公司和电信公司的过程中所得的经验教训，包括： > > - “智能模型 vs. 便宜模型”是个假命题 > - 优先在新用例中使用前沿模型，成熟后再迁移到开源模型 > - 应用层面针对具体用例进行微调（fine-tuning）更有效 > - 需求总是超过供应：成本越低，企业买得越多 > > 00:00 引言 > 01:07 Decagon 90%的运行基于开源技术 > 05:00 “智能 vs. 便宜” 是个伪选择 > 09:26 内部构建模型工厂 > 15:07 实验室会是创业公司最后的净土吗？ > 21:21 部署现场工程师是陷阱吗？ > 28:36 构建生成代理的代理 > 37:02 透明模型（glass box）胜于黑箱模型（black box） > 47:55 从传统客服到 AI 管家 > 1:14:45 客户支持领域的杰文斯悖论（Jevons paradox） 🧠 **深度解读** 采用“前沿模型快速定义-应用层微调-成熟后迁移到开源/低成本”的闭环，将性能、可控性与成本三者同时优化；并把降低交付成本作为增长杠杆，因为更便宜的支持/自动化会被企业大量购买。 🔗 **[查看原文](https://news.miracleplus.com/share_link/146097)** --- ### 💡 技术洞见 #22 **本地AI代理的设计需兼顾实用性与安全性** 📝 **推文原文** > 不只是可爱。 > 你的本地AI伙伴——聊天、编辑文件、记住你的喜好。 > Kawaii Agent V2。 🧠 **深度解读** 将“聊天 + 文件操作 + 持久记忆”组合成本地代理能显著提高实用性并获得高用户兴趣，但同时把“是否真·本地、操作系统兼容性、聊天/记忆的存储策略与执行安全”变成首要的产品设计与沟通要点。 🔗 **[查看原文](https://news.miracleplus.com/share_link/146098)** --- ### 💡 技术洞见 #23 **企业级LLM应用的可控资产化策略** 📝 **推文原文** > 昨天我在财报电话会上提到的 ROIC Intelligence App 今天可以详细介绍一下了。 > > 我使用了 Morgan Stanley（摩根士丹利）的 Brian Nowak 本周针对 Hyperscale ROIC（超大规模投资回报率）制作的 PDF，通过我们即将推出的新超级应用程序中的 Copilot Code（协作开发助手代码）功能，仅用一个简单的提示加上技能指令（/drill-me）制定了这个计划，然后用 autopilot（自动驾驶功能）自动生成了完整的应用程序（包括历史记录、数据查询、情景分析、“假设”分析等功能）。最后还用 /rubber-duck 功能进行了测试。 > > 最棒的是，所有的工件都在我的企业环境内！我的应用程序运行在 Copilot 中，代码托管在 GitHub Enterprise（企业版 GitHub），所有的数据管道、数据湖以及语义模型都托管在 Fabric 平台中，而这一切全都在 Agent 365 的 IT/安全/财务运营（FinOps）控制之下！ > > 所以，这并不是单纯追求“Tokenmaxxing”（最大化令牌利用）或者“Vibe Coding”（凭感觉编程）。每一步都在有条不紊地为企业创造长期价值。这些资产具有可复用性，同时配套完善的治理结构、安全保障和成本管控。 > > 这就是一套完整的系统，专为推动业务价值而设计。声明：所有内容均来自公开信息，仅供演示使用——不构成财务建议！:) > > 以下是这个应用程序和它的架构设计…… 🧠 **深度解读** 用可编排的 prompt/skill + autopilot 自动生成应用，但把所有产物写入企业平台（Copilot app、GitHub Enterprise 代码、Fabric 数据/语义层），并由 Agent 365 的 IT/Sec/FinOps 负责治理与成本控制，从而将 LLM 产物从短期实验转为长期可控资产。 🔗 **[查看原文](https://news.miracleplus.com/share_link/146099)** --- ## 🔬 科学与发现 ### 💡 科研洞见 #1 **多模态空间推理的子任务训练提升路径** 📝 **推文原文** > 人类在这张图像中数箱子的准确率（包括隐藏的箱子）达到82.1%，而最好的现成多模态模型(multimodal model)仅能达到17.7%。 > > Spatial-IQ是NVIDIA Research推出的一项诊断性基准(benchmark)，通过九种感知和认知子任务将3D物体计数问题拆解开来，例如数柱子、推断结构下方必须存在的支撑块等，并分别对每一项任务进行评分。在这些子任务上进行训练将Qwen2.5-VL-32B的物体计数准确率从2.9%提升到了62.6%。 > > 对于开发多模态推理系统的研究人员来说，这提供了一个实用的循环：识别空间推理失败的环节，针对缺失的能力进行优化，并验证改进是否反映了组合能力提升，而不仅仅是最终得分的提高。 🧠 **深度解读** 为多模态空间推理构建可分解的子任务集并对这些子任务进行有针对性的训练，是从低水平基线跃迁到实际可用空间推理能力的高杠杆路径；同时要求以子任务级别打分来确认改进是组合性能力的增长而不是仅仅提升最终分数。 🔗 **[查看原文](https://news.miracleplus.com/share_link/146078)** --- ## 💰 商业与战略 ### 💡 商业洞见 #1 **Stripe创始人分享创业成功的思考与数据分析** 📝 **推文原文** > 推文原文: > 2009年，@patrickc 和 @collision 在加州伯克利参加了Startup School创业学校，之后在Potrero Hill吃了寿司，在回家散步的路上决定创立 @Stripe。正如Patrick回忆的那样，他们之所以做出这个决定，是因为“我们不妨试试，反正这可能也不会太难。” > > 两年后，Stripe正式上线。 > > 十七年后的2026年，在Startup School创业学校上，Patrick与YC（Y Combinator）的 @harjtaggar 进行了对谈，讨论了他两次辍学MIT（麻省理工学院）的经历、为什么创业者应该问问自己成功后会发生什么，以及Stripe的数据如何揭示创业的最佳时机。 > > 00:07 — 在人工智能（AI）时代，你还有什么需要学习的？ > 02:01 — 知识依旧重要 > 05:12 — 你应该辍学创业吗？ > 09:58 — 为什么Stripe能够成功 > 12:10 — 在Stripe上线之前如何构建它 > 17:20 — 精益创业（The Lean Startup）的模式还适用吗？ > 19:07 — 构建Stripe背后隐藏的收获 > 22:36 — 人工智能会让你的创业失败吗？ > 25:17 — 为什么创业的机会从未像现在这么好 > 29:23 — Stripe的数据如何分析AI经济 > 30:45 — 打造真正满足需求的产品 🧠 **深度解读** Stripe创始人Patrick分享了创业过程中对成功的思考，强调将“如果我们成功”作为常规检验条件的重要性。这种思维方式将成功的后果视作设计输入，显著提高了早期决策的鲁棒性与可执行性，同时通过数据分析揭示了创业的最佳时机。 🔗 **[查看原文](https://news.miracleplus.com/share_link/146075)** --- ### 💡 商业洞见 #2 **企业AI采用呈现快速验证到规模化迁移的生命周期** 📝 **推文原文** > .@DecagonAI 的联合创始人兼CEO张杰西（Jesse Zhang）表示，当前企业对开源（open-source）的采用率正在下降，这其实是接受度而非排斥度的表现： > > “尽管关于开源技术的讨论非常火热，但现阶段开源技术用于推理（inference）的比例实际上在下降。” > > “人们正在大量开发新的用例，而在开发新的用例时，自然会优先选择更前沿的模型（frontier models），直到它们足够成熟。” > > “一旦这些模型成熟，企业就会倾向使用开源技术，因为相比之下它更便宜、更高效。” > > “企业很想做出更多变革，但同时只能处理一定数量的用例。这其中确实存在惯性（inertia），他们还需要完成模型风险治理（model risk governance）和各类安全审核。” > > “我相信这需要时间，但终究会实现。” > > @thejessezhang 表示：“一家每年支付10万美元的客户可以享受到全方位一对一服务，而每年消费10美元的客户只能使用自助帮助中心。@DecagonAI 的核心假设是，AI将缩小这一服务差距，而企业正在接受这一转变。” > > Decagon的联合创始人张杰西（Jesse Zhang）和阿什温·斯里尼瓦斯（Ashwin Sreenivas）与a16z的Kimberly Tan和Sarah Wang进行了深入讨论，分享他们在为大型银行、航空公司和电信公司部署智能代理（agents）的过程中积累的经验： > - “智能模型”与“低成本模型”并非对立（smart-vs-cheap models are a false trade-off） > - 在新用例中优先使用前沿模型，随着用例成熟再迁移到开源模型 > - 每个用例的微调（fine-tuning）应在应用层进行 > - 支持需求总是超过供应：通过降低成本，企业就会增加购买量 🧠 **深度解读** 企业 AI 采用呈现“快速验证（用 frontier 模型）→规模化迁移（到开源）”的生命周期：成功后会寻求更便宜的开源解法，但迁移受治理与激励阻力阻碍，且降低成本会放大需求，因此产品应把价值放在迁移路径、治理合规工具、应用层定制与自动化白手套服务上。 🔗 **[查看原文](https://news.miracleplus.com/share_link/146083)** --- ### 💡 商业洞见 #3 **语音AI的核心护城河在于数据与基础设施的结合** 📝 **推文原文** > RT @MollySOShea 新消息：AssemblyAI 每天处理的语音数据量是 YouTube 的 4 倍。 > > “Our TAM（可服务市场）增加了100倍。” > ——CEO Dylan Fox (@YouveGotFox) > > 语音技术是人工智能（AI）增长最快的领域之一，为记笔记、医疗健康、编程助手、呼叫中心、AI陪伴机器人、汽车餐厅点单系统、消费电子设备、类人机器人等提供支持。 > > 而 AssemblyAI 则是这些背后的基础设施提供者。 > > 支持价值数十亿美元的公司，如 Granola、Commure、Tolans 和 Ciro AI。 > > 数据速览： > › 峰值时每周语音对话量超1.2亿 > › 每天2M+小时语音处理量，为YouTube的4倍 > › 每周对话量3年内增长800% > › 超过100万开发者，其中40%去年注册 > › 每天约1亿次API调用 > › 公司员工约80人 > > @AssemblyAI 是 2017 年 Y Combinator (YC) 第一批人工智能创业公司之一，由 Daniel Gross 运营。背后的投资者包括 Accel、Insight Partners、YC、Smith Point Capital、Nat Friedman、Daniel Gross，以及 Patrick 和 John Collison。 > > 我们探讨了： > › 在麦当劳汽车餐厅点单时，其实麦当劳也不知道你点单的AI是我们支持的 > › 为何训练语音模型时，数据占75%的决定因素 > › 为什么类人机器人无法区分谁在和它说话 > › 语音助手是否需要披露自己的存在 > > 𝐓𝐈𝐌𝐄𝐒𝐓𝐀𝐌𝐏𝐒 时间轴： > (00:00) AssemblyAI 创始人兼 CEO Dylan Fox > (01:06) AssemblyAI 的语音流量是 YouTube 的 4 倍 > (03:33) 一切始于价值10万美元的GPU积分 > (06:39) 为什么语音AI正在迎来拐点 > (10:11) AssemblyAI 的基础设施优先战略 > (12:41) 每周处理1.2亿通电话的幕后故事 > (14:49) AI 代理如何重塑 AssemblyAI 的内部运营 > (17:05) 无人解决的“主权AI”问题 > (18:26) 键盘和鼠标时代是否即将终结？ > (22:33) 类人机器人尚未解决的核心难题 > (25:14) 翻译语言背后的真正问题 > (29:27) AI 能和动物对话吗？ > (31:24) 开源基准测试为何存在偏差？ > (34:20) 小时候在聊天室里搭建网站 > (36:48) 设备端AI模型将如何改变一切 > (43:03) 影响 Dylan 职业生涯的人物 🧠 **深度解读** 语音AI的核心护城河是“数据+基础设施”：数据占模型价值的主导（“75%”），而能接入并实时处理YouTube级别语音流量的基础设施是将这种数据转化为产品与商业化能力的杠杆；边缘/主权化与内部AI agents是下一波可复制的竞争手段。 🔗 **[查看原文](https://news.miracleplus.com/share_link/146091)** --- ### 💡 商业洞见 #4 **降低 token 成本对 AI 用户行为的潜在影响** 📝 **推文原文** > 大家都在努力大幅降低每个**token**（令牌）的成本，同时提高性能。 > > 人工智能（AI）其实被“低估”了。 > > 就像我在播客中提到的那样，当**token**成本接近于零（或者不再计量收费）时，你的行为方式会发生巨大的变化。 > > 目前有99.99%的人工智能用户还未体验过这种转变——但在接下来的这一年内，他们都会经历。 > > 接下来的发展会非常疯狂！ > > ——根据任务的平均成本来看，**Hermes Agent**（Hermes代理）和**Pi Agent**（Pi代理）具有成本优势，而**Claude Code**的成本是**Pi**的约3.7倍： > > - $0.39 Hermes Agent > - $0.40 Pi Agent > - $0.47 Codex > - $0.51 OpenCode > - $0.54 Kimi Code > - $1.47 Claude Code > > 中位成本数据显示相同趋势：**Pi Agent**和**Hermes Agent**的中位成本为$0.29；**OpenCode**为$0.35；**Kimi Code**为$0.38；**Codex**为$0.39；**Claude Code**则为$0.72。这表明，成本差异在典型任务中始终存在，并非由少量昂贵的运行造成的。 > > 这些成本是根据**Kimi K3**公开的定价计算得出的：输入**token**为每百万个$3，缓存的输入**token**为每百万个$0.30，输出**token**为每百万个$15。 🧠 **深度解读** 当 token 成本趋近于零或变为非计量时，用户使用模式会被放大——在此情景下，提供显著更低每次任务成本（通过缓存与更低的输出/输入定价）的平台，将以远高于价格差异本身的速度赢得使用量和创新场景。 🔗 **[查看原文](https://news.miracleplus.com/share_link/146092)** --- ### 💡 商业洞见 #5 **云服务提供者通过算力投资初创公司成为新趋势** 📝 **推文原文** > 据彭博社报道，Moonshot公司通过与阿里巴巴的一项保密协议，使用了大约20,000枚Nvidia（英伟达）芯片来运行其Kimi模型。 > > 这些硬件设备构成了支持Kimi系统的大量计算能力来源。 > > 阿里巴巴是Moonshot公司的最大投资者之一，并且希望其资助的初创公司运行在阿里巴巴的云服务平台上。 > > 阿里巴巴提供的20,000枚芯片是属于上一代的Hopper（霍普）系列产品。一些接近Moonshot公司的人士指出，这些芯片为H200，是该系列中速度最快的型号。 > > 针对H200的说法，阿里巴巴回应称完全没有根据，但同时并未否认其提供了20,000枚芯片，也未说明这些芯片的具体型号。 > > 文章来源：theedgemalaysia.com/node/812910 🧠 **深度解读** 云服务提供者作为投资者能把大规模算力作为‘实物投入’纳入融资关系，令算力分配成为与股权同等重要的竞争与议价手段；因此‘算力表’正在与‘股权表’并列成为创业公司关键资产表。 🔗 **[查看原文](https://news.miracleplus.com/share_link/146096)** --- ## 🌐 行业与趋势 ### 💡 行业洞见 #1 **欧盟AI合规要求推动软件可追溯性设计的重要性** 📝 **推文原文** > 三天后，也就是8月2日，欧盟人工智能办公室（EU's AI Office）将有权对无法解释其人工智能（AI）系统的公司处以最高全球营收3%或1500万欧元的罚款。 > > 这些义务可追溯至去年8月的违规行为。 > > 大多数我交流过的CEO都将此视为一项为了合规而“求生”的挑战，但我认为这实际上是一个“上游设计”问题——要么你几年前就解决了，要么你根本没有解决。 > > 如果你的软件的每一个操作都能追溯到一个被人类批准的需求，以及一个能证明其仍然有效的测试，那么最后期限只是完成一些文书工作而已。 > > Software Factory（软件工厂）的一个显著特性是，它能够创造不止是针对整个系统，还能细化至单个功能的治理和可审计性，从而使这种合规成为可能。 🧠 **深度解读** 在可追溯性成为监管硬性要求的环境下，能将运行时行为绑定到“经人批准的需求 + 自动化测试证明”的平台级能力，成为产品与工程团队的核心差异化能力和合规防护线。 🔗 **[查看原文](https://news.miracleplus.com/share_link/146077)** --- ### 💡 行业洞见 #2 **无人化物流闭环的市场价值与产业替代效应** 📝 **推文原文** > https://t.co/HbcCV7MawQ 🧠 **深度解读** 把移动自主（FSD 车辆）和场景作业机器人（Optimus）结合，能把“會走的車”与“會動手的人”两端连成完整的无人化物流闭环，解锁比单一产品更大的市场价值和产业级替代效应。 🔗 **[查看原文](https://news.miracleplus.com/share_link/146090)** --- ### 💡 行业洞见 #3 **AI检测器的不可靠性引发的法律与声誉风险** 📝 **推文原文** > 转推@BrianRoemmele 无用的“AI检测器”使耶鲁大学被告上联邦法庭 > > Thierry Rignol花费超过20万美元在耶鲁大学攻读高级工商管理硕士（Executive MBA）课程，并一度成为班级的佼佼者，直到一次不可靠的AI检测器（人工智能检测器）误判了他精心完成的考试。 > > 该校将一个本就薄弱的怀疑无限放大，展开了一场不断变动的调查。当AI相关指控站不住脚时，他们甚至捏造了“缺乏坦诚”的罪名。 > > 最终，他被判不及格（F），停学一年，并失去了学术地位。这场起初的学术审查演变成了一场包含13项指控的联邦诉讼，揭露了耶鲁大学为了保护自身利益而牺牲公平程序的倾向。 > > 详情请继续阅读…… 🧠 **深度解读** 将未充分验证的AI检测工具作为决定性证据，会将机构置于程序正义与法律风险的两难：检测器的不可靠性不仅会错判个人，还会在调查失败后促使机构用模糊指控掩护，进而引发诉讼与声誉成本。 🔗 **[查看原文](https://news.miracleplus.com/share_link/146093)**