最新

嗨，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访问图表图像的权限，并运行一个单独的质量检查循环，它可以“修复”损坏的图表。 我希望能听到社区的反馈，或者了解其他尝试过类似事情的人的经验！