最新

各位 HN 的朋友们！Sipp 是一个开源的 AI 推理库，可以在浏览器中运行本地模型，解码速度比其他库快高达 3 倍。 我的背景是人机交互（HCI）和图形编程。我和我的联合创始人一直在思考，当 token 变得像“免费”一样普遍时，下一代用户体验会是什么样子。我们的一个动机是尝试超越目前占主导地位的聊天应用和信息检索用例，探索 AI 如何作为一种持续、无声的手，间接帮助用户，微妙地监测他们的意图，并动态生成或调整 UI 以满足他们的需求。 在我们的探索过程中，我们遇到了两个痛点：1）在浏览器中运行 AI 时，性能不足以支持实时应用，模型加载和缓存也是问题；2）在尝试于桌面本地运行时，没有好的解决方案可以将模型嵌入到 Electron 或 Tauri 等平台中使用。 因此，几个月前，我们开始为 llama.cpp 项目贡献代码，以探索浏览器推理。当时，它对 WebGPU 的支持还不够完善。我们帮助让后端在大多数现代 GPU 上（需要 16 位浮点）工作，并提供了相当好的操作覆盖。同时，我们开始从头开始构建 Sipp，使用 Rust 和 C++ 创建一个统一的库，围绕如何在实际应用和用例中将本地和云推理结合使用。 结果是，Sipp 在整体 token 解码速度上比其他库快了 3 倍。但我们相信仍有改进空间。我们的目标是为每种模型架构研究更定制化的推理管道，这将使我们能够更有效地优化计算和内存限制。 Sipp 使用一个单一的、统一的客户端 API。我们非常关注如何创建一个能够有效地、以简单的方式连接本地和云推理的库。我们希望开发者能够从通过 WebGPU（或其他后端）在浏览器中运行小型本地模型开始，然后通过更改端点，将完全相同的代码路径扩展到自托管网关（CUDA/Vulkan/Metal）或云提供商。这使得在处理小型任务时能够获得本地运行的好处，同时可以将需要更强智能的任务卸载给提供商或云。 目前，我们的主要重点是优化浏览器体验，但我们也在积极开发额外的后端，以便通过我们的客户端 API 在本地运行 LLM，该 API 目前支持 Node、Rust 和 Python。 我们接下来最兴奋的是进一步推动我们现有的后端。正如任何从事高性能系统工作的人都知道，原始算法和高效的矩阵乘法只是成功的一半。实时系统中很大一部分瓶颈来自于低效的内存管理和显存与内存之间的传输成本。 我们相信，通过激进的内核融合，有巨大的机会提取更多性能。通过创建针对特定模型架构量身定制的“定制”内核，我们可以极大地减少中间内存拷贝。我们的下一个目标是精确地了解我们能在消费级硬件上将本地推理推向理论上“完美”的解码和预填充速度有多近。 我们在网站上提供了一个完全在设备上运行的实时、简单的聊天演示，以及一个基准测试工具，如果您想在自己的硬件上测试或验证性能差异。 我们非常欢迎您深入研究代码，运行基准测试，并告诉我们可以在哪些方面进行改进。我今天都会在这里回答关于架构、内核融合或本地 LLM 时代 HCI 的任何问题。 更多深入的技术信息请参见：<a href="https:&#x2F;&#x2F;dev.to&#x2F;constant_chen_&#x2F;sipp-a-local-first-runtime-for-hybrid-ai-applications-2ce5" rel="nofollow">https:&#x2F;&#x2F;dev.to&#x2F;constant_chen_&#x2F;sipp-a-local-first-runtime-for...</a>

Orchid（Orchestration interactive debugger）是一个无需插桩的代理，可以捕获代理管道中的每一个 API 和 LLM 调用，然后允许您在本地逐步检查和重放整个运行过程。无需插桩，无需供应商锁定，无需云依赖。它还提供了一个可视化检查器和 MCP 服务器，因此您可以自己检查会话，或者使用您喜欢的 agentic 编码 IDE 来调试您的代理运行。 我构建它是为了摆脱通过 grep 日志来调试代理失败的困境，而且现有的 AI 可观测性工具似乎都需要侵入性的插桩和