返回首页
最新
我创建了Lime Reader，这是一个简约的网站，展示了来自Hacker News、Tildes、Lobsters、Slashdot、Bear以及一些与科学、技术和编程相关的subreddit的按时间排序的热门帖子。
您可以通过点击我网站顶部的口号“您每日的STEAMD网络指南”来了解更多关于该网站的信息：
<a href="https://limereader.com/about" rel="nofollow">https://limereader.com/about</a>
之前，我一直使用Rust或NodeJS作为后端，Postgres作为数据库。
这次，我首次使用Swift作为后端构建网站，使用SQLite作为数据库，仅使用了一个第三方依赖：在Swift应用中使用Vapor作为Web服务器，并将其全部自托管在一台旧的Mac mini上。
我非常厌恶庞大臃肿的网站，也不喜欢在没有绝对必要的情况下添加第三方框架。因此，我将Lime Reader设计得尽可能小，以便能够瞬间加载。PageSpeed Insights和Pingdom均将我网站的性能评为优秀。
它是服务器端渲染的，因此即使禁用JavaScript也能正常工作（虽然启用它会为每个链接提供一些额外功能，如快速访问archive.org）。即使禁用CSS，它也能在一定程度上工作。
该网站没有任何广告（我讨厌广告，并在各处安装了广告拦截器！），没有追踪器或分析工具。CloudFlare会自动在网站上启用真实用户监控（RUM）。我做的第一件事就是禁用这个功能。
我在一台旧的Mac mini上自托管该网站。这是一款2020年的Intel型号，配备2018年的芯片（Intel的3 GHz 6核Core i5）和32GB内存。Qwen模型的内存使用约为5.5GB，每个标题分类大约需要2秒。
Swift应用与本地运行的Qwen3 8b LLM进行通信，以判断标题是否属于政治类。这是通过Ollama的REST API完成的。这似乎效果很好，远胜于Apple的基础模型。最初，我尝试使用Apple的基础模型进行分类。当它有效时，效果还不错。然而，许多标题（甚至一些相当平淡的标题）会不知为何触发其保护机制。我在Stack Overflow上寻求帮助，但像往常一样，他们因缺乏细节而关闭了问题：
<a href="https://stackoverflow.com/questions/79785822/how-to-disable-apple-intelligences-guardrails" rel="nofollow">https://stackoverflow.com/questions/79785822/how-to-disable-...</a>
例如，这个标题：
> SEC批准德克萨斯证券交易所，这是几十年来美国首个新的综合交易所
会触发Apple的保护机制，并抛出一个错误，提示“拒绝：可能包含敏感内容”。
Apple确实提供了一个“宽松的保护模式”，具体见：
<a href="https://developer.apple.com/documentation/foundationmodels/improving-the-safety-of-generative-model-output#Use-permissive-guardrail-mode-for-sensitive-content" rel="nofollow">https://developer.apple.com/documentation/foundationmodels/i...</a>
这确实允许某些文本正常工作。然而，对于其他一些文本，它仍然失败。这时我放弃了使用Apple的基础模型，转而使用没有此类问题的Qwen3 8b模型。令人遗憾的是，基础模型有很大的潜力，但Apple却严重削弱了它们。
我最初在配备M4芯片的新Mac上尝试了Apple的基础模型，一旦遇到保护机制的问题，我决定切换到在Intel上运行的Qwen模型，并使用我的旧Mac mini。
我遇到的一个问题是我的Swift应用间歇性崩溃。根本原因有两个：
1. 第一个与从多个线程访问SQLite数据库有关。显然，对于多线程使用，SQLite需要用`SQLITE_OPEN_FULLMUTEX`标志进行初始化。
2. 第二个是来自macOS操作系统本身的“坏文件描述符”错误。这与Process.run()中的一个可能的bug有关，导致它在一段时间后崩溃：
<a href="https://github.com/swiftlang/swift/issues/57827" rel="nofollow">https://github.com/swiftlang/swift/issues/57827</a>
我能够通过上述“fileHandleForReading.close()”的解决方法修复它。
让我们看看这个网站现在能持续多久而不崩溃 :)
如有任何问题，请随时询问。
这是我最近看到的一个例子 - https://x.com/ycombinator/status/1988366241460089118
最近我发现越来越多这样的无意义的商业模式，而我并不是唯一有这种感觉的人。你怎么看？
我不使用名片，更喜欢让人们扫描我手机上的二维码。不过，这里有两个问题：
- 其他人往往会给我名片，结果这些名片堆成一堆，难以区分。
- 当人们扫描我的二维码时，信息会直接进入他们的联系人中，之后再也看不到了。
为了解决这个问题，我创建了netcards。这是一个非常简单的渐进式网页应用（PWA），我和Claude一起编写了代码。工作流程如下：
- 在“我的名片”页面输入你的信息和事件名称并保存。二维码会随之出现。
- 在标签页面设置标签。
- 当人们用手机的应用扫描二维码时，信息会直接进入他们的联系人黑洞，但至少会有一个事件名称和你的所有信息。
- 如果在应用之间扫描，你可以选择标签，之后可以根据事件名称和标签进行筛选。
- 然后你可以分享联系人，为他们生成二维码，或者保存vcards以导入到你的本地联系人应用中。
显然，使用的人越多，这个工具就越有用，所以我想先在HN上分享一下。
技术：
- 原生JavaScript，支持离线的PWA
- 使用IndexedDB进行本地持久化
- 使用jsQR和qrcodejs进行扫描/生成
- Bulma CSS，所有依赖项来自CDN
- 网址：<a href="https://netcards.app" rel="nofollow">https://netcards.app</a>
GitHub: <a href="https://github.com/evronm/net-cards/" rel="nofollow">https://github.com/evronm/net-cards/</a>
我只在我的安卓手机上测试过这个，所以我特别想听听iPhone用户的使用体验。不过，总的来说，我想知道大家是否觉得这个工具有用，以及是否有人有任何建议。
我一直在开发 Fast LiteLLM——一个用于流行的 LiteLLM 库的 Rust 加速层，并且我有一些有趣的经验，可能会引起其他开发者的共鸣，他们也在努力从现有系统中挤出性能。
我的假设是，作为一个 Python 库，LiteLLM 会有很多优化的低垂果实。因此，我开始使用 PyO3 创建一个 Rust 层，以加速性能关键部分：令牌计数、路由、速率限制和连接池。
**方法**
- 使用 tiktoken-rs 构建令牌计数的 Rust 实现
- 添加无锁数据结构 DashMap 以支持并发操作
- 实现异步友好的速率限制
- 创建猴子补丁 shim 以透明地替换 Python 函数
- 添加全面的功能标志以实现安全、渐进的发布
- 开发性能监控以实时跟踪改进
在构建完所有 Rust 加速后，我进行了全面的基准测试，比较了基线 LiteLLM 和经过 shim 处理的版本：
| 功能 | 基线时间 | Shimmed 时间 | 加速比 | 改进 | 状态 |
|---------------------|----------------|------------------|------------|--------------|------------|
| token_counter | 0.000035s | 0.000036s | 0.99x | -0.6% | |
| count_tokens_batch | 0.000001s | 0.000001s | 1.10x | +9.1% | |
| router | 0.001309s | 0.001299s | 1.01x | +0.7% | |
| rate_limiter | 0.000000s | 0.000000s | 1.85x | +45.9% | |
| connection_pool | 0.000000s | 0.000000s | 1.63x | +38.7% | |
结果表明，LiteLLM 已经相当优化！核心的令牌计数几乎没有变化（慢了 0.6%，可能在测量噪声范围内），而最显著的提升来自于更复杂的操作，如速率限制和连接池，Rust 的并发原语在这些方面确实产生了实质性的差异。
**关键收获**
1. 不要假设现有库是低效的——维护者通常对他们的领域非常了解。
2. 关注算法改进而非重新实现——有时候，更好的方法胜过更快的语言。
3. 微基准测试可能会产生误导——现实世界的性能影响差异显著。
4. 最大的收益往往来自复杂部分，而非简单操作。
5. 即使是“适度”的改进在规模上也可能很重要——在高吞吐量应用中，速率限制的 45% 改进是有意义的。
虽然核心的令牌计数几乎没有改善，但速率限制和连接池的提升仍然为高流量用例提供了价值。我构建的基础设施（功能标志、性能监控、安全回退）为未来的优化奠定了坚实的基础。
该项目继续在 GitHub 上以 Fast LiteLLM 的名义进行，欢迎对 Rust-Python 集成模式感兴趣的朋友参与，尽管性能提升让人谦卑。
编辑：为了澄清——token_counter 的负性能可能在测量的噪声范围内，这表明 LiteLLM 的令牌计数已经相当优化。而在速率限制和连接池方面超过 45% 的提升仍然为高吞吐量应用提供了价值。