最新

写作说明（包括优秀/差劲的样本生成）：<a href="https://www.linum.ai/field-notes/launch-linum-v2">https://www.linum.ai/field-notes/launch-linum-v2</a> 我们是Sahil和Manu，两兄弟，过去两年一直在从零开始训练文本到视频的模型。今天，我们将这些模型以Apache 2.0的协议发布。 这些模型拥有20亿参数，能够生成2到5秒的360p或720p视频。就模型大小而言，最接近的比较是阿里巴巴的Wan 2.1（13亿参数）。根据我们的测试，我们在运动捕捉和美学方面取得了显著更好的效果。 我们并不声称已经达到了前沿技术。对我们来说，这只是通往最先进技术（SOTA）的一个垫脚石——证明我们可以自己端到端地训练这些模型。 为什么要从零开始训练模型？ 我们在2024年1月发布了第一个模型（在Sora之前），这是一个180p、1秒的GIF机器人，基于Stable Diffusion XL进行引导。图像变分自编码器（VAE）无法理解时间一致性，而没有原始训练数据，就无法在图像和视频分布之间平滑过渡。在某些情况下，重新开始反而更好。 在v2中，我们使用T5进行文本编码，Wan 2.1 VAE进行压缩，以及一个经过流匹配训练的DiT变体作为主干。我们构建了自己的时间VAE，但Wan的模型更小且性能相当，因此我们使用了它以节省嵌入成本。（我们将很快开源我们的VAE。） 大部分开发时间用于构建有效的筛选管道（例如，手动标记美学属性和微调VLM以进行大规模过滤）。 有效的方面：卡通/动画风格、食物和自然场景、简单角色动作。无效的方面：复杂物理、快速运动（例如，体操、舞蹈）、一致的文本。 为什么要在Veo/Sora存在的情况下构建这个？ 产品是底层模型能力的扩展。如果用户想要模型不支持的功能（角色一致性、相机控制、编辑、风格映射等），那么就会陷入困境。为了构建我们想要的产品，我们需要更新模型本身。这意味着要掌控开发过程。这是一项需要时间（和大量GPU计算）才能见效的赌注，但我们认为这是正确的选择。 接下来是什么？ - 针对物理/变形的后训练 - 提升速度的蒸馏 - 音频能力 - 模型扩展 我们在Notion中保持了一本“实验记录”，记录了所有实验。欢迎提问关于从0到1构建模型的相关问题。欢迎评论和反馈！

嘿，HN！我们是Nithin和Nikhil，双胞胎兄弟，正在开发BrowserOS（YC S24）。我们是一个开源、以隐私为首的替代品，旨在取代大实验室的AI浏览器。 在BrowserOS上，我们提供一流的支持，让您可以使用自己的LLM，无论是本地模型还是通过API密钥，并且完全在客户端运行代理，这样您的数据就能保留在您的机器上！ 今天我们推出了文件系统访问……就像Claude Cowork一样，我们的浏览器代理可以读取文件、写入文件、运行命令行指令！但老实说，我们并没有为此做过计划。事实证明，我们在9个月前做出的隐私决策意外地为这一刻做好了准备。 --- 我们9个月前的架构赌注 与其他AI浏览器（如ChatGPT Atlas、Perplexity Comet）不同，它们的代理循环在服务器端运行，我们早期决定将代理完全在您的机器上（客户端）运行。 但是在客户端构建一切并不顺利。 我们最初在一个Chrome扩展中构建了我们的代理循环，但我们不断遇到障碍： 1) JS（后台服务工作者）是单线程的，因此我们无法并行启动多个代理。 2) 没有访问类似NodeJS的运行时意味着我们无法使用许多优秀的npm包（如Vercel AI SDK、Anthropic的MCP SDK等）。 3) 最后，没有好的方法将我们的代理和工具暴露为API。 因此，我们在2个月前做出了艰难的决定，放弃我们所构建的一切，从头开始。 在新的架构中，我们采用了侧车方法。我们将代理循环放在一个独立的Bun二进制文件中，并与我们的Chromium二进制文件一起发布。我们还决定不重写自己的代理循环，而是借用了gemini-cli的循环，并进行了些许调整！我们编写了一个整洁的适配器，以在Gemini格式和Vercel AI SDK格式之间进行转换。您可以在这里查看我们的整个代码库：<a href="https://git.new/browseros-agent" rel="nofollow">https://git.new/browseros-agent</a> --- 这如何帮助构建文件系统访问 当Claude Cowork推出时，我们意识到：由于Atlas和Comet的代理循环在服务器端运行，因此它们的代理无法在不先将文件上传到服务器的情况下访问您的文件。 但我们的代理已经是本地的。添加文件系统访问意味着只需……打开大门（当然需要您的权限）。我们的代理现在可以像Claude Code一样读取和写入文件。无需上传，无需云存储，无需同步。 --- 您今天可以实际做的事情 a) 在我的桌面文件夹中整理文件 <a href="https://youtu.be/NOZ7xjto6Uc" rel="nofollow">https://youtu.be/NOZ7xjto6Uc</a> b) 打开前5个HN链接，提取细节并将摘要写入HTML文件 <a href="https://youtu.be/uXvqs_TCmMQ" rel="nofollow">https://youtu.be/uXvqs_TCmMQ</a> --- 我们现在的进展 如果您自上次Show HN以来还没有尝试过我们，请再给我们一次机会。新的架构解锁了大量新功能，我们的GitHub星标已增长至8500个，下载量超过10万： c) 您现在可以使用类似n8n的图形构建更可靠的工作流 <a href="https://youtu.be/H_bFfWIevSY" rel="nofollow">https://youtu.be/H_bFfWIevSY</a> d) 您还可以在Cursor或Claude Code中将BrowserOS用作MCP服务器 <a href="https://youtu.be/5nevh00lckM" rel="nofollow">https://youtu.be/5nevh00lckM</a> e) 您还可以安排重复任务！ --- 我们认为浏览器是合适平台的原因 我们非常看好浏览器作为类似Claude Cowork代理的合适平台。浏览器是知识工作者最常用的应用程序（电子邮件、文档、电子表格、研究等）。看起来连Anthropic也意识到了这一点——对于Claude Cowork，他们通过Chrome扩展与浏览器进行了粗糙的集成。但拥有整个技术栈使我们能够提供更顺畅的体验。这也让我们能够构建其他方式无法实现的差异化功能。一个例子：浏览器ACL。 代理可以做一些愚蠢或破坏性的事情，因此我们正在添加浏览器级别的保护措施（想想代理的IAM）：“角色（代理）：绝不能点击购买”或“角色（代理）：对我银行主页的只读访问。”我们已经有了一个原型——期待听到您对此及整体论点的看法。 我们会在评论区等候。感谢您的阅读！ GitHub: <a href="https://git.new/browseros" rel="nofollow">https://git.new/browseros</a> 下载: <a href="https://browseros.com">https://browseros.com</a>（适用于Mac、Windows、Linux！）

构建了一个可审计的人工智能（圣经）翻译流程：希伯来语/希腊语源数据包 -> 带注释的经文 JSON，汇总到章节、书籍和约。最终文本结合了指标（TTR，n-grams）。<p>据我所知，这是第一个完整文本的例子（Z世代圣经不算在内）。<p>虽然存在一些幻觉和问题，但整体质量让我感到惊讶。<p>大型语言模型在翻译和呈现更古老的文本方面有很大的潜力，使其变得“可接近”。<p>这项技术对信徒有很大的益处，我认为这才刚刚开始被探索。

错误：循环：aws_security_group.app -> aws_security_group.db -> aws_security_group.app 如果你在将AWS基础设施导入Terraform时遇到这个错误，你一定知道这种痛苦。 Terraform的核心引擎依赖于有向无环图（DAG）。它需要知道：“先创建A，然后创建B。” 但是AWS是最终一致的，并且乐于允许循环的存在。 死锁 最常见的罪魁祸首是安全组。想象一下两个微服务： - SG-App允许向SG-DB的出站流量 - SG-DB允许来自SG-App的入站流量 如果你用内联规则编写这个（这是terraform import的默认行为），你就会创建一个循环： ```hcl resource "aws_security_group" "app" { egress { security_groups = [aws_security_group.db.id] } } resource "aws_security_group" "db" { ingress { security_groups = [aws_security_group.app.id] } } ``` Terraform无法应用这个配置。它无法在没有db的ID的情况下创建app，反之亦然。 图论视角 在构建一个基础设施反向工程工具时，我意识到我不能仅仅将API响应直接转储为HCL。我们将AWS建模为一个图：节点是资源，边是依赖关系。 在一个健康的配置中，依赖关系是一个DAG： [VPC] --> [Subnet] --> [EC2] 但安全组往往会形成循环： ``` ┌──────────────┐ ▼ │ [SG-App] [SG-DB] │ ▲ └──────────────┘ ``` 寻找“结” 为了为数千个资源解决这个问题，我们使用Tarjan算法来查找强连通分量（SCCs）。它识别出“结”——循环依赖的节点集群——并将其标记以进行处理。 在我们的测试中，一个典型的企业AWS账户拥有500多个安全组，通常包含3到7个这样的集群。 解决方案：“壳与填充” 我们使用一种策略来打破循环： 1. 创建空壳：生成没有规则的安全组。Terraform会立即创建这些。 2. 用规则填充：将规则提取到单独的aws_security_group_rule资源中，并引用这些壳。 ```hcl 第一步：创建壳 [SG-App (空)] [SG-DB (空)] 第二步：创建规则 ▲ ▲ │ │ [规则：出站->DB] [规则：入站<-App] ``` 现在图是无环的。 “为什么不总是使用单独的规则？” 这是个合理的问题。问题在于： 1. terraform import通常生成内联规则。 2. 许多现有代码库更喜欢内联规则以提高可读性。 3. AWS API呈现的是“逻辑”视图（规则捆绑在一起）。 该工具需要检测循环并仅对有问题的部分进行处理。 为什么terraform import不够 标准导入按原样读取状态。它不会在生成代码之前构建全局依赖图或执行拓扑排序。它将重构的负担放在了人类身上。对于拥有2000多个资源的现有迁移，这并不可行。 --- 我在一个名为RepliMap的工具中实现了这个图引擎。我已经开源了运行只读扫描所需的文档和IAM策略。 如果你对像这样的边缘案例（或root_block_device陷阱）感兴趣，仓库在这里： https://github.com/RepliMap/replimap-community 欢迎提问。