最新

我申请 YC 已经有好几次了……这次我想寻求一些帮助。而且我全力以赴了。我用来申请的东西完成了我的申请。我没有碰过任何旋钮或拨盘……也没有敲过一个键。我只是给代理下达了指令，它就使用了工具。你可以在这里看到这个疯狂的视频——加速了 21 倍（在视频描述中也有完整慢速视频的链接）：<a href="https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=udwuE1PrM_0&amp;feature=youtu.be" rel="nofollow">https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=udwuE1PrM_0&amp;feature=youtu.be</a> 对我来说，这是终极的 YC 申请——一个我无需为此感到压力，有人帮助我完成，并且它本身就是一次展示。这场表演是为了留下证据。 如果你想知道是什么样的“魔法”创造了这份疯狂，它在这里：<a href="https:&#x2F;&#x2F;fuckui.com" rel="nofollow">https:&#x2F;&#x2F;fuckui.com</a> 祝你好运！

我一直想尝试新的AI语音进行长篇旁白，但发现所有需要订阅的服务都因为我使用频率不高而显得不划算。我偶然发现了开源的Kokoro模型[0]，它的语音效果非常好，足以让我连续听几个小时而不会像以前那些机械的TTS语音那样感到疲劳。该模型拥有8200万个参数，设计运行速度很快，但我仍然难以在我的12核笔记本电脑上通过CPU推理获得可接受的生成速度。我设想使用基于云的GPU服务来快速生成有声读物，从而充实我自己的自托管库，并且这个流程也可以成为一个供他人使用的产品。 构建这个产品我有两个目标：一是接触AI多智能体编码工作流，二是构建一个专门针对电子书转有声读物转换的TTS产品。ebookaloud的99%代码是由DeepSeek v4在OpenCode中生成的。我花费了大约12美元的积分，使用了一亿个token，历时一个月，对结果非常满意。每一个修改/功能都经历了一个“计划 -> 实现 -> 测试 -> 审查 -> 纠正 -> 提交”的循环，由Pro和Flash智能体混合完成。这通常限制在一个或两个并发工作进程。我有一个独立的评估智能体负责质量控制，涵盖了提取和合成流程的各个部分，我可以同时运行8-10个。在AI工作流自动化方面，我可能正在接近Yegge的第六阶段[1]。 之后，我设置了Claude Code，并将Opus 4.8与DeepSeek并排运行。两者之间确实存在质量差异，但我是一名经验丰富的开发者，喜欢亲手实践。我没有编写任何代码，但阅读了生成代码的关键部分，并与DS Pro就每一步的实现进行了深入的交流。Opus对DeepSeek的选择没有太多批评性的意见，而且我不确定一个前沿模型是否能为我的工作流带来显著的改进。我猜测在大型代码库中，差异会更加明显，但我用Opus实现的几个修改与我使用过的所有模型都存在类似的问题：随机的、非我所期望的修改，过度复杂化简单的解决方案，在卡住时采取意想不到/破坏性的行动等等。我确实认为Opus能够处理更多我参与过的复杂规划和协调工作。这可能是我有时需要但有时不需要的功能。 至于产品本身，市面上已经有很多更成熟的解决方案。我无意与ElevenLabs竞争。我的目标是生成m4b格式的文件，提供无缝的有声读物体验，采用按需付费的定价模式，并提供足够好的输出质量。这是我第一次尝试商业化产品，而AI代码生成让一个打磨过的产品触手可及。如果没有AI，这需要我花费6-8个月的时间进行手动研究和开发，并且我可能在完成之前就已经精疲力尽了。 如果您只是想看看它在语音/格式方面的生成效果，网站首页有一个免费的示例。我在输出质量方面做了一些主观的决定。我为大多数语音设定了每分钟140字的语速，以符合行业标准，但有些语速更快或更慢，在这个语速下会失去韵律感。我没有给用户一堆选项，而是将语速控制等功能委托给播放设备。如果网站有实际的使用量，我希望扩展支持Kokoro的其他语言，并且从PDF提取和合成功能将使产品更加完善。

各位 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 可观测性工具似乎都需要侵入性的插桩和