24小时热榜

<a href="https://xcancel.com/eastdakota/status/2062860530360959273" rel="nofollow">https://xcancel.com/eastdakota/status/2062860530360959273</a>

大家好，我们是来自General Instinct的Guanming和Bill（<a href="https://general-instinct.com">https://general-instinct.com</a>）。 <p>经过多年的机器人领域工作，我们不断遇到同一个问题：最佳模型往往无法适配我们实际拥有的硬件。</p> <p>表现最好的模型通常是基于数据中心的假设设计的：大型GPU、大量内存带宽和可靠的网络访问。但大多数物理系统却面临相反的限制。</p> <p>这促使我们探索如何在确保模型前沿性的同时，使其能够在边缘硬件上实际运行。</p> <p>作为这项工作的一个成果，我们最近开源了InstinctRazor（<a href="https://github.com/General-Instinct/InstinctRazor" rel="nofollow">https://github.com/General-Instinct/InstinctRazor</a>）。</p> <p>我们特别兴奋的一项成果是将大约245 GB的BF16 MoE模型Qwen3.5-122B-A10B压缩到48 GiB的GGUF中。这个模型的体积实际上比Gemma-4-26B-A4B还要小，但在MMLU-Pro和GPQA-D等基准测试中表现更佳。我们保留了始终活跃的部分（如路由器、归一化层、Gated-DeltaNet/SSM层、视觉通路等），并对路由专家进行了更积极的量化。然后，我们使用在线蒸馏技术来恢复在量化过程中损失的能力。</p> <p>该模型还可以在“小GPU”配置下运行，其中专家从系统RAM中流式传输。在8k上下文窗口下，峰值显存使用量约为7.6–8 GB。</p> <p>如果您对技术细节感兴趣，我们在这里写下了相关方法（<a href="https://general-instinct.com/blog/frontier-moe-sub-4-bit">https://general-instinct.com/blog/frontier-moe-sub-4-bit</a>）。</p> <p>我们尤其希望听到那些将模型部署到机器人或其他边缘设备上的人的反馈。您今天尝试在本地运行哪些模型？在将它们投入生产时，遇到的最大瓶颈是什么？</p>

你好，周五快乐！ 我计划举办一些面对面的“开发者入门”工作坊，希望能得到你们对“现代工具”的建议。 参与者的背景各不相同，从充满热情的新手（“我听说可以用AI制作自己的应用！”）到希望掌握现代开发技能以便构建项目和找到使用AI工具的工作的现有软件开发者。 对于那些最近使用AI工具进行软件开发和“技术”工作的人，如果你们有很好的开发环境和工作流程，我非常想了解你们的开发设置、使用的工具以及最适合你们（和你们团队）的工作流程。 // 我的背景 我从事编程和开发已经超过20年，但在使用AI工具方面并不多（除了在几个项目中使用了一些大型语言模型API）。 我重视开源，追求长期的质量和可维护性。像测试驱动开发（TDD）、使用经过验证/文档完善的工具、以客户为中心的开发（通常与客户配对）等技术，使得做正确的事情变得简单。如果你熟悉Pivotal Labs、敏捷开发和极限编程（XP），那就是我的风格。 以下是工作坊的一些即将使用的案例，以及我个人的“IT待办事项”： - 创建一个静态的“单页”个人/专业网站 - 设置一个博客/静态网站生成器（Pelican），创建一个简单但时尚的主题 - 创建一个简单的Web应用/后端API（FastAPI）工具 - 基于表单的计算器，将X数据转换为PDF等 - 找出如何让SyncThing自动同步家中3台Linux电脑的主文件夹 - 备份和归档我iPhone上的照片和视频 // 我目前使用的技术栈： - 操作系统：Linux Mint Debian (LMDE) - 编辑器：VSCodium - 编程语言：Python, HTML/CSS - 服务器平台：Amazon AWS 我猜大多数工作坊参与者会使用MacBook和Windows电脑，但也有一些人使用Linux，因为我最近举办了一次“Linux安装派对”。 我还没有使用过任何“AI工具包”、代理或类似的东西，但对如何更好地利用这些工具感到好奇。 感谢你们分享知识！ // JRO

简而言之：我训练了一个分类器，用于将请求路由到最便宜的模型和推理深度。结合额外的自动化令牌效率技术，这使得在相同支出下使用量提高了三倍。对于任何想自己尝试的人：<a href="https:&#x2F;&#x2F;nerfguard.com" rel="nofollow">https:&#x2F;&#x2F;nerfguard.com</a> 最近，我和一些团队成员从Claude Code切换到了Codex。我们仍在这两种工具之间切换，但Codex的速度和可控性以及性能提升让人难以忽视。一个缺点是，按令牌计费的费用很快就开始生效。这种情况普遍存在，但我们在Codex中感受得尤为明显。我们是一家初创公司，团队成员全天候工作，热衷于构建产品——因此，我们的<i>每日</i>账单显得格外引人注目。 幸运的是，我们正在追求一个重要的使命，速度比边际令牌支出更为重要。不过，这让我们思考，尽管我们的产品在减少令牌支出和显著加快代理工作流程方面有着意想不到的效果，但我们却在所有类型的内部编码任务中使用这些顶级模型，而没有进行任何优化。这种浪费显得相当荒谬——最明显的罪魁祸首是，我们似乎在每个任务上都使用了最高智能模型和最大推理深度，即使这些任务显然并不需要如此。作为一家花费大量时间在缓存智能上的公司，我们也很容易看到还有许多其他的低悬果实可以摘取。 因此，在最近的一个周末，我迅速构建了一个工具来优化我们的使用。它的核心是一个<i>非常快速</i>的分类器，可以将请求分类到完成任务所需的最低智能水平，并在此基础上进行一些不错的令牌优化。结果是，令牌支出大幅降低，但质量大致相同。对我们来说，更令人兴奋的是，合理打包的智能和推理水平使我们的速度也显著提升。这并非微不足道。 我们观察到，每个人每天节省了高达三倍的时间，这些时间本来是用来等待工具的响应和编码代理的反馈。 对我们来说，这意味着工程效率的提升，以及在相同支出下显著更高的使用量。这也意味着在被限制之前可以使用更多的资源。 当我告诉朋友们这件事时，他们也想开始使用它，以最大化他们从编码代理计划中获得的使用量。现在，许多最前沿的人工智能公司的工程师都在使用这个工具来优化他们的令牌利用率。不仅是为了节省资金，更是为了最大化产出。事实证明，避免被Claude限制的最佳方法是有选择性地主动限制自己。我们决定将其发布给其他开发者社区使用。现在，您可以为自己启用Nerfguard，今天就开始获得更多的使用量。