最新

大家好，我们是 Jeet 和 Husain，来自 Modulus (<a href="https://modulus.so" rel="nofollow">https://modulus.so</a>) - 一款桌面应用程序，让您可以使用共享项目记忆运行多个编码代理。 我们构建它的目的是为了解决我们反复遇到的两个问题： * 跨仓库上下文断裂。当跨多个代码仓库工作时，代理无法理解它们之间的依赖关系。即使我们在单独的 Cursor 窗口中打开两个仓库，在前端仓库中进行更改时，我们仍然需要手动解释后端 API 模式。 * 代理会丢失上下文。在不同的编码代理之间切换通常意味着丢失上下文并重复相同的指令。 Modulus 在代理和仓库之间共享记忆，这样它们就可以理解您的整个系统。 它是一种替代工具，例如 Conductor，用于编排 AI 编码代理来构建产品，但我们特别关注多仓库工作流程（例如，后端仓库 + 客户端仓库 + 共享库仓库 + AI 代理仓库）。我们从头开始构建了自己的记忆和上下文引擎，专门用于编码代理。 为什么要构建另一个代理编排工具？这源于我们自己的问题。在从事我们上一家初创公司的工作时，Husain 和我跨越了两个不同的代码仓库。跨仓库工作意味着手动在 Cursor 窗口之间粘贴 API 模式——一遍又一遍地告诉前端代理后端 API 的样子。所以我们构建了一个小的上下文引擎来跨仓库共享知识，并通过 MCP 将其连接到 Cursor。后来，它变成了 Modulus。 很快，Modulus 将允许团队与他人共享知识，以改善他们使用 AI 编码代理的工作流程——在 AI 编码时代实现团队协作。我们的 API 将允许开发人员在编码代理或 IDE 之间切换，而不会丢失任何上下文。 如果您想在尝试之前观看快速演示，这是我们的发布帖子 - <a href="https://x.com/subhajitsh/status/2024202076293841208" rel="nofollow">https://x.com/subhajitsh/status/2024202076293841208</a> 我们非常感谢您提供的任何反馈，并希望您有机会试用 Modulus。

使用 Vibe 编码工具，添加多语言支持变得出乎意料地简单。如果你要求模型添加西班牙语、葡萄牙语、德语或法语等语言，它通常可以很快地设置 i18n 结构，即使对于包含大量文本的项目也是如此。 我注意到的一件事是，一旦网站被 Google 索引，流量并不总是主要来自美国。有时，很大一部分流量来自其他国家，通过搜索而来。但大多数发布平台或目录都是纯英文的，因此它们在其他语言的可发现性方面并没有真正提供帮助。 因此，我尝试了名为 LeanVibe 的项目，做了一些不同的事情。这个想法很简单：你用你喜欢的任何语言提交你的产品一次。然后，平台会自动将内容翻译成支持的语言，访问者默认会看到他们本地语言的界面和产品描述。 顺便说一句，LeanVibe 不仅仅是一个发布平台。它更像是一个社区空间，有博客、论坛，可以关注人或产品，以及寻找合作者的方式。我目前的想法是将自动翻译扩展到博客文章和论坛讨论。 缺点是此功能会消耗大量 LLM 代币，并且比平台上的大多数其他功能更耗费资源。 我很好奇这里的人怎么看。自动多语言支持真的有助于早期产品的发现和增长吗，还是对于这样的平台来说，这是一种不必要的复杂性？

大家好，我们是 Sanchit 和 Shubham (YC W26)。我们为 Apple Silicon 构建了一个快速推理引擎。LLM、语音转文本、文本转语音——MetalRT 在我们测试的每种模式上都超越了 llama.cpp、Apple 的 MLX、Ollama 和 sherpa-onnx。自定义 Metal 着色器，没有框架开销。 此外，我们已经开源了 RCLI，这是 Apple Silicon 上最快的端到端语音 AI 管道。从麦克风到语音响应，完全在设备上完成。无需云端，无需 API 密钥。 开始使用： ``` brew tap RunanywhereAI/rcli https://github.com/RunanywhereAI/RCLI.git brew install rcli rcli setup # 下载约 1 GB 的模型 rcli # 交互模式，按住说话 ``` 或者： ``` curl -fsSL https://raw.githubusercontent.com/RunanywhereAI/RCLI/main/install.sh | bash ``` 数据（M4 Max，64 GB，可通过 `rcli bench` 重现）： LLM 解码 – 比 llama.cpp 快 1.67 倍，比 Apple MLX 快 1.19 倍（使用相同的模型文件）： - Qwen3-0.6B：658 tok/s（vs mlx-lm 552，llama.cpp 295） - Qwen3-4B：186 tok/s（vs mlx-lm 170，llama.cpp 87） - LFM2.5-1.2B：570 tok/s（vs mlx-lm 509，llama.cpp 372） - 首个 token 的时间：6.6 毫秒 STT – 70 秒的音频转录时间为 *101 毫秒*。这相当于 714 倍的实时速度。比 mlx-whisper 快 4.6 倍。 TTS – 178 毫秒合成。比 mlx-audio 和 sherpa-onnx 快 2.8 倍。 我们构建这个是因为在设备上演示 AI 很容易，但发布它却很困难。语音是最难的测试：你按顺序链接 STT、LLM 和 TTS，如果任何一个阶段变慢，用户就会感受到。大多数团队退而求其次使用云 API，不是因为本地模型不好，而是因为本地推理基础设施不行。 难以解决的问题是延迟叠加。在语音管道中，你按顺序堆叠了三个模型。如果每个模型增加 200 毫秒，那么在用户听到一个字之前就已经有 600 毫秒了，这感觉很糟糕。你不能优化一个阶段就认为完成了。每个阶段都需要快速，在一个设备上完成，没有网络往返来掩盖。 我们直接使用了 Metal。自定义 GPU 计算着色器，所有内存都在初始化时预先分配（推理期间零分配），以及一个统一的引擎用于所有三种模式，而不是将单独的运行时拼接在一起。 MetalRT 是第一个在 Apple Silicon 上原生处理所有三种模式的引擎。完整方法： LLM 基准测试：[https://www.runanywhere.ai/blog/metalrt-fastest-llm-decode-engine-apple-silicon](https://www.runanywhere.ai/blog/metalrt-fastest-llm-decode-engine-apple-silicon) 语音基准测试：[https://www.runanywhere.ai/blog/metalrt-speech-fastest-stt-tts-apple-silicon](https://www.runanywhere.ai/blog/metalrt-speech-fastest-stt-tts-apple-silicon) 如何实现：大多数推理引擎会在你和 GPU 之间添加层：图调度器、运行时分发器、内存管理器。MetalRT 跳过了所有这些。自定义 Metal 计算着色器用于量化矩阵乘法、注意力机制和激活函数——提前编译，直接分发。 语音管道优化细节：[https://www.runanywhere.ai/blog/fastvoice-on-device-voice-ai-pipeline-apple-silicon](https://www.runanywhere.ai/blog/fastvoice-on-device-voice-ai-pipeline-apple-silicon) RAG 优化：[https://www.runanywhere.ai/blog/fastvoice-rag-on-device-retrieval-augmented-voice-ai](https://www.runanywhere.ai/blog/fastvoice-rag-on-device-retrieval-augmented-voice-ai) RCLI 是基于 MetalRT 构建的开源语音管道 (MIT 许可证)：三个并发线程，带有无锁环形缓冲区，双缓冲 TTS，38 个 macOS 语音操作，本地 RAG（在 5K+ 块上约 4 毫秒），20 个热插拔模型，以及一个全屏 TUI，带有每个操作的延迟读数。当未安装 MetalRT 时，会回退到 llama.cpp。 源代码：[https://github.com/RunanywhereAI/RCLI](https://github.com/RunanywhereAI/RCLI) (MIT) 演示：[https://www.youtube.com/watch?v=eTYwkgNoaKg](https://www.youtube.com/watch?v=eTYwkgNoaKg) 如果设备上的 AI 真的和云一样快，你会构建什么？