一周热榜

我开始在 X 上给“接触草地”的人发放徽章，纯粹是为了好玩，而且大多数人都很喜欢！所以，我决定为此创建一个网站。<p>流程很简单： - 输入 X 用户名 / 链接 - 获取头像并选择徽章 - 生成一个徽章页面，可以分享，带有漂亮的 OG 图片<p>该网站部署在 Vercel 上，使用 R2 和浏览器渲染 OG 图片，并用于数据存储。

Hi HN， 过去几年，我一直在使用多个前端技术栈（React、Vue、Angular 等），并且一直遇到一个反复出现的烦恼： 核心 UI 组件，比如下拉选择框和提示通知，每次框架变更时都要重写。 即使行为和用户体验基本相同，实现方式也与框架紧密耦合，这使得长期存在的 UI 逻辑出乎意料地脆弱。 因此，我决定尝试一种不同的方法：将 UI 原语构建为原生 Web Components，然后选择性地为框架进行封装，而不是重新实现它们。 因此，我构建了两个组件： SeoSelect — 面向生产环境的下拉选择框组件 虚拟滚动，适用于大型数据集 多语言模糊搜索（包括韩语、日语和中文输入模式） 默认支持键盘和屏幕阅读器的无障碍访问 零运行时依赖 SeoToast — 轻量级、与框架无关的提示通知组件 多种位置和动画效果 重复消息分组 SSR（服务器端渲染）安全行为 ~10KB gzipped 这两个组件首先被实现为纯 Web Components，仅在需要提升开发者体验时才添加框架封装。 我并不是想取代框架——这更多的是关于测试 UI 原语是否可以在框架生命周期之外存在，同时仍然适用于实际应用。 我非常感谢那些有以下经验的人的反馈： 在生产环境中使用过 Web Components 构建过跨框架共享的设计系统 遇到过这种方法的局限性或棘手问题 链接： https://www.npmjs.com/package/seo-select https://www.npmjs.com/package/seo-toast 很乐意回答问题或讨论权衡取舍。 谢谢！

ElasticMM 是一个新发布的开源服务系统，专为现代多模态大型语言模型（MLLM）设计。该研究成果被选为 NeurIPS 2025 的口头报告。 与主要针对纯文本工作负载优化的现有服务栈（如 vLLM）不同，ElasticMM 引入了弹性多模态并行（EMP），这是一种新的执行范式，可在不同的推理阶段和模态之间调整并行度。 论文的主要发现： * TTFT（首次令牌时间）降低高达 4.2 倍 * 在混合多模态工作负载下，吞吐量提高 3.2 倍至 4.5 倍 * 模态感知调度、弹性阶段划分、统一前缀缓存和非阻塞编码 论文（OpenReview PDF）： [https://openreview.net/pdf?id=Zd6VyjmN1S](https://openreview.net/pdf?id=Zd6VyjmN1S) GitHub 仓库： [https://github.com/hpdps-group/ElasticMM](https://github.com/hpdps-group/ElasticMM) 很想听听 HN 社区的看法，特别是那些构建 LLM/MLLM 推理栈或处理生产环境中多模态服务的用户。