嗨，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真的和云端一样快，你会构建什么？
返回首页
最新
我花了多年时间为建筑行业开发一款专注于健康与安全的SaaS产品。我们对用户界面和用户体验非常执着，因为我们的用户在年龄、技术适应能力、识字水平和首选语言上差异很大。尽管我们做得很好，但让新用户熟练使用这款产品始终是一项挑战。该公司在2022年被收购。
在这段旅程中，我注意到一件事：在内部，我们一直使用Slack。它成为了我们一切事务的中心——团队对话、服务器警报、支持工单。它总是打开的标签页。因此，我们自然希望我们的建筑客户也能采用它。
但他们没有。事后看来，原因显而易见：Slack是基于打字的。当你在屋顶上、在工作间开车或在脚手架上安装墙板时，这种方式并不适用。
经过一段时间的休息，我一直在思考这个差距。如果现场团队有一个统一的界面，他们可以：
- 与团队其他成员沟通
- 更新他们的工作订单、考勤或其他已使用的系统
- 提出问题，由经过他们公司自身文档和数据训练的AI进行解答
这一切都可以通过语音完成。任何语言。不需要打字。不需要学习多个应用程序。
这就是Conkoa。一位在梯子上的工头可以说：“我们在绿雪松项目的三楼有三名工人工作了八小时”，这些信息会被正确地录入Procore或他们的记录系统中。消息会自动转录和翻译，因此说西班牙语的团队成员和说英语的项目经理可以保持同步，而无需额外工作。团队可以上传照片和文件，这些信息会进入RAG管道，以便内置的AI代理可以按需总结和提取这些信息。
我们今天与Procore等工具集成，并正在构建更多集成。
Conkoa已经上线，并被数十家建筑公司使用。您可以在<a href="https://conkoa.ai" rel="nofollow">https://conkoa.ai</a>上设置一个免费的工作区——非常希望得到HN社区的反馈。
嘿，HN，作为一名前数据分析师，我一直在尝试让代理程序来完成我以前的工作。结果是这个系统，它可以帮助你实现大约80%的目标。我认为这是一个很好的数据点，展示了当前前沿模型的能力以及它们仍然不足的地方（在这种情况下——假设生成和一般数据直觉）。
一些初步的学习经验：
- 如果有明确的模板或预定义的组件供模型使用，生成基于网页应用的报告会顺利得多。
- 如果你给Claude访问图表图像的权限，并运行一个单独的质量检查循环，它可以“修复”损坏的图表。
我希望能听到社区的反馈，或者了解其他尝试过类似事情的人的经验！
我之所以创建这个项目，是因为我想知道我出生那一年日本人听了什么音乐。这个问题引发了更多思考：罗马的热门歌曲与同年在拉各斯的排行榜相比如何？随着流媒体的兴起，音乐影响力传播的速度前所未有，声音的风味是如何扩散的？
88mph是一个可玩音乐历史地图：涵盖20个国家的230个排行榜，跨越8个十年（1940–2025）。每首歌曲都可以通过YouTube或Spotify播放。这个项目是开源的，我非常希望能得到帮助来扩展它——有一个链接可以贡献新的国家和年份的排行榜。我们的目标是众包出一份完整的世界音响地图。
react-tourlight 是现代的 React 旅游库。它没有任何依赖，符合 WCAG 2.1 AA 无障碍标准，压缩后小于 5 kB。它与 React 19 兼容。
我一直在研究一种新的工作量证明（Proof-of-Work）架构，围绕确定性挖矿节奏构建（我称之为“限额工作量证明”）。<p>核心思想是一个协议强制的节奏模型，每个被接纳的身份以固定的速度（目前建模为每秒1个哈希）推进挖矿过程。节点不再通过原始哈希算力竞争，而是以确定的方式推进挖矿过程。<p>更广泛的架构旨在通过持续的基础设施参与（正常运行时间、活跃的网络连接和身份接纳限制）使大规模并行挖矿的优势变得在操作和经济上都很昂贵，从而中和这些优势。<p>在这种模型下，安全假设也发生了变化。由于挖矿进程是按每个被接纳的身份进行节奏控制，而创世身份将被广泛分配，因此获得多数控制权的概率渐近于51%。在有限的时间内，达到传统的51%控制几乎变得不可行。<p>为了验证核心机制，我构建了一个基于浏览器的最小可行产品（MVP），展示了确定性的每秒1个哈希的节奏模型。MVP链接：https://grahambell.io/mvp/Proof_of_Witness.html 你也可以观看演示视频：https://youtu.be/i5gzzqFXXUk?si=y_Pv5ZDv9SGhRFjY<p>我目前希望与对分布式系统、共识机制或协议架构感兴趣的工程师联系，探讨进一步共同开发的可能性。<p>如果这个模型可行，下一阶段将是组建一个小型核心团队，全面构建该协议。早期贡献者将有机会从零开始塑造系统的架构和方向。<p>如果你对这个愿景感兴趣，并且喜欢解决困难的分布式系统问题，请通过电子邮件联系我：hurairah@grahambell.io，内容包括：（1）你所构建的项目（2）这个问题对你为什么重要（3）你曾经解决的一个困难技术问题及其解决方案。<p>注意：这还不是一个完善的创业推介。我是一个独立创始人，正在探索一种协议架构，试图解决区块链系统中的中心化压力，我在寻找那些认为这个问题值得研究的认真构建者。