最新

嗨，HN， 我有大约2000个书签是我永远不会去阅读的。你可能也有类似的情况。我不断收集新的阅读材料，清单每天都在增长，但我几乎没有时间去阅读它们。问题，我意识到，更多的是因为在选择阅读内容时的分析瘫痪。这有点像我们花费大量时间去决定在Netflix上看什么电影。 因此，我制作了一个简单的Chrome扩展程序：它随机选择一个书签，带你进入该页面，并在一个浮动工具栏上提供两个按钮——“随机下一篇”（Stumble）或“已读”（Done，标记为已读并移动到下一个随机书签）。就这样。它完全消除了决策的负担，而且因为加载的内容具有多样性（和新颖性），与之互动也变得有趣，同时仍然在我想要阅读的内容范围内。此外，我还添加了每日目标和连续阅读的功能，以激励我完成清单并将其变成日常习惯。 你可以简单地右键点击 -> 添加到Stumbleback来保存新的书签，除此之外，它会读取你现有的Chrome书签，或者你也可以粘贴网址，无需单独的数据库。 这是免费的。希望能收到任何尝试过清理阅读清单但未能成功的人的反馈。

Speakrs 在 Rust 中实现了完整的 pyannote community-1 风格的分段识别管道，包括分段、幂集解码、重叠添加聚合、二值化、嵌入、PLDA 和 VBx 聚类。<p>该库路径中没有 Python 运行时。推理在 ONNX Runtime 或原生 CoreML 上运行，其余的管道则保持在 Rust 中。<p>在 macOS 上速度提升为 20 倍至 30 倍，但在 Linux/CUDA 上仅提升 2-3 倍（具体取决于 CPU）。<p>其速度更快的几个原因：<p>1. Speakrs 使用的是 CoreML 版本的模型。我专门导出了这些模型以便在 CoreML 上运行。而 PyAnnote 则是在 macOS 上通过 MPS（Metal）运行相同的 PyTorch 版本。<p>2. PyAnnote 并不是单一模型，而是将几个不同的模型组合在一起形成的管道，README 中有关于完整管道的一些信息。<p>3. Speakrs 优化了管道，使得不同部分可以在 CPU、神经引擎和 GPU 上运行。<p>Speakrs 具有批处理模式，可以同时处理多个文件，这样可以充分利用 CPU/GPU/ANE 的资源。<p>因此，在 Linux/CUDA 上速度提升并不明显，因为 PyAnnotate 已经优化为在 CUDA 上运行，我们在 CUDA 上获得的速度提升是通过在 CPU 上运行一些任务，同时在 GPU 上运行其他任务实现的。Linux 上的速度提升将取决于 CPU 的性能。<p>此外，还有一种快速模式，牺牲了一些速度以提高准确性，速度可提升至 50 倍，对于某些类型的音频，准确性损失并不明显。基准测试中有更多相关信息。