keakon

@suke119 7B 都加载不了的显卡，其实不推荐玩大模型。另外，单机多卡也比多机快很多倍。

如果单卡能部署的话，不要用 tp ，每个 GPU 开一个实例，前面用 nginx 之类的负载均衡，速度至少快几倍。

@Pipecraft 我也不知道，当时 Google 对于隐私审查还不严，也许可以通过插件收集用户数据来盈利吧。
另外，有些人愿意买一些项目充门面，简历里挂个 xxx 开发者也加分嘛。

妹子怕晒的话，还是室内比较好。博物馆、艺术展之类的，大部分都是免费。

@yamedie 我试了下不支持起点。它在原理上就是解决不了使用 addEventListener 绑定事件的。并且没法记住用户的设置，每次打开这些网站都得手动点收藏夹。

@kebamt 瞄了一下它的源码，原理是一样的，但是它的实现较复杂。
它通过消息机制在 backgroud 和 content scripts 之间进行通信，来确定是否对当前网站启用。但其实二者都可以直接访问 chrome.storage ，不需要引入消息通信来增加复杂度，并且这样也增加了延迟。
其次，它用的是 chrome.storage.local ，我用的是 chrome.storage.sync ，因此我可以在多设备间同步配置。
兼容性上，它绑定的是 HTML 根元素，我绑定的是 document 元素，理论上它可能存在更多漏网之鱼。（也许绑 window 更好）。

Chrome 内存占用小于 Safari ，但是后者更省电。

@mxdyeah 只有写才需要加锁啊，一天才几次

@daimaosix 假设你有 1000 个 topics ，5000 个客户端。
原方案是某个 topic 收到消息，只会通知 5 个客户端来获取消息。
你的方案会导致 5000 个客户端来获取消息，然后大部分丢弃掉。
性能差异可想而知。

此外，RabbitMQ 默认是不允许同一条消息被多个消费者并发消费的，需要使用 Fanout Exchange 。此时每个消费者都是一个单独的队列，即变成 5000 条队列，发布消息的开销会增大 5000 倍。