最新

你好，HN，我们是来自Modulus的Jeet和Husain（<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）结构，即使对于文本量较大的项目也是如此。 我注意到的一点是，一旦网站被谷歌索引，流量并不总是主要来自美国。有时，来自其他国家的流量通过搜索也占据了相当大的比例。然而，大多数启动平台或目录仅支持英语，因此在其他语言的可发现性方面并没有太大帮助。 因此，我尝试了一个名为LeanVibe的不同项目。这个想法很简单：你只需以你喜欢的语言提交一次产品。平台会自动将内容翻译成支持的语言，访客默认会看到他们本地语言的界面和产品描述。 顺便提一下，LeanVibe不仅仅是一个启动平台。它更像是一个社区空间，包含博客、论坛、关注人或产品的功能，以及寻找合作者的方式。我目前的想法是将自动翻译扩展到博客文章和论坛讨论中。 缺点是，这个功能消耗了相当多的LLM令牌，并且比平台上的大多数其他功能更重。 我很好奇这里的人们怎么看。自动多语言支持是否真的有助于早期产品的发现和增长，还是对这样的平台来说是多余的复杂性？

嗨，HN，我们是Sanchit和Shubham（YC W26）。我们为Apple Silicon构建了一个快速推理引擎。无论是大型语言模型（LLMs）、语音转文本（STT）还是文本转语音（TTS），MetalRT在我们测试的每种模式下都超越了llama.cpp、Apple的MLX、Ollama和sherpa-onnx。我们使用了自定义的Metal着色器，没有框架开销。 此外，我们还开源了RCLI，这是在Apple Silicon上最快的端到端语音AI管道。从麦克风到语音响应，完全在设备上运行。无需云端，无需API密钥。 开始使用的方法： ```bash brew tap RunanywhereAI/rcli https://github.com/RunanywhereAI/RCLI.git brew install rcli rcli setup # 下载约1 GB的模型 rcli # 交互模式，按下说话 ``` 或者： ```bash 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） - 首个令牌时间：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（约4毫秒，处理5000多个块），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真的和云端一样快，你会构建什么？