## NVIDIA Rubin：下一代人工智能计算平台 NVIDIA 发布了 Rubin 平台，这是一款由六个互连芯片——CPU、GPU、交换机、SuperNIC、DPU 和以太网交换机——构建的新型人工智能超级计算机，旨在大幅降低人工智能任务的成本和时间。Rubin 承诺与上一代相比，**推理成本降低高达 10 倍，MoE 模型训练速度提升 4 倍**。 关键创新包括新的 **Vera Rubin NVL72 机架级系统**以及 NVLink、Transformer Engine 和机密计算方面的进步。该平台还推出了针对人工智能推理优化的 **NVIDIA Vera CPU**，以及由 BlueField-4 提供支持的用于更快代理人工智能的新的 **推理上下文内存存储平台**。 **微软、AWS、谷歌云和 CoreWeave** 等主要厂商正在采用 Rubin，微软将其集成到下一代 Fairwater AI 超级工厂中。通过 **Spectrum-6 以太网** 增强的网络连接，承诺提高电源效率和正常运行时间。Rubin 计划于 2026 年下半年上市，标志着 NVIDIA 继续致力于提供最先进的人工智能基础设施。
每日HackerNews RSS
## Nvidia Rubin：下一代人工智能总结
英伟达最近宣布了Rubin，其下一代人工智能平台，在训练和推理速度方面都有显著提升。该系统采用“极致协同设计”，集成了英伟达的Vera CPU、Rubin GPU以及NVLink 6和BlueField-4等网络组件。
讨论的重点在于这些进步的实际意义。用户质疑运行单个机架所需的电力（可能高达170千瓦）以及GPU折旧周期的长期可行性，特别是考虑到Rubin可能带来的成本降低。 存在争议的是，性能的提升是否会减少GPU升级的频率。
一个关键点是英伟达转向完全自主解决方案，包括一个88核ARM CPU（MediaTek协助）。该公告引发了人们对实际性能提升以及对数据中心基础设施影响的好奇。新闻稿中名人代言的出现也引起了关注，一些人认为苹果的缺席可能意义重大。更详细的技术信息将在GTC 2026上发布。
构建您自己的iMessage智能代理
构建您自己的iMessage智能代理
联系我们：LinkedIn GitHub X Instagram
构建一个iMessage天气代理，用于查询天气预报
## Flux：iMessage 中的 AI 代理 - 摘要
开发者 danielsdk 推出了 Flux (tryflux.ai)，一款允许用户在 iMessage 中创建自定义 AI 代理的工具。由于他对 AI 应用在 iPhone 上变得“墓地”般杂乱感到沮丧，他基于互动是 AI 采用的关键瓶颈这一想法构建了 Flux——人们持续使用 iMessage。
用户定义代理的个性和目的，从而创建一个可以通过短信访问的功能性 AI，无需接收者下载任何应用程序。该工具利用现有的 AI 能力，专注于更自然互动的模式。
早期用户反馈指出用户体验有些笨拙，包括一个涉及向服务控制的号码发送验证码的验证过程。许多用户还报告功能有限，并且代理倾向于以过于随意，甚至无益的“兄弟术语”回复。尽管存在这些问题，该项目最近在 Product Hunt 上排名第一，开发者欢迎反馈以改进该工具。
2025年，磁带上发现唯一已知的UNIX v4副本，这是一个关键版本，因为它首次用C语言重写了UNIX。在成功地在PDP-11模拟器上运行它之后，作者研究了核心实用程序，并在`su(1)`程序中发现了一个缓冲区溢出漏洞——一个setuid-root可执行文件，用于权限提升。 这个50年前的程序由不到50行代码组成，它会检索root密码，禁用终端回显，并将哈希输入与存储的哈希进行比较。该漏洞在于读取用户输入到100字节缓冲区时缺乏边界检查，允许过长的输入导致崩溃。 利用UNIX的传统做法，即包含源代码，作者使用`ed`行编辑器修补了该程序，在输入循环中添加了一个计数器和一个大小检查。然后编译并部署了修补后的代码，需要设置setuid位才能正常工作。 这次经历突出了UNIX原始设计理念的力量，并展示了如何使用现成的工具快速解决安全问题。它也强调了20世纪70年代不同的安全优先级，当时这类漏洞并不被认为是关键问题。
## 黑客新闻讨论：修复 Unix v4 中的缓冲区溢出
一个黑客新闻帖子讨论了原始 Unix v4 系统中的缓冲区溢出漏洞。核心问题在于可能通过超出相邻 `password` 数组的边界来覆盖 `pwbuf`（密码缓冲区）。用户推测，重复两次的 100 字节密码可能可以利用此漏洞，从而获得 root 权限。
讨论深入到早期 Unix 环境的细节：有限的代码大小（每个程序 50-100 行），使用电报机终端导致命令名称简短，以及 C 语言中结构体的使用。 几位评论者试图创建漏洞利用程序，但这些程序大多因不完整、格式不佳或依赖于对密码哈希和系统行为的不准确假设而受到批评。
该帖子还链接到对恢复的 Unix v4 磁带的相关分析以及现场终端演示。最终，以实际方式远程利用此漏洞的可行性仍然不清楚，建议倾向于时序攻击，如果无法直接溢出。
## IBM Bob 编码代理漏洞摘要
IBM Bob，IBM 目前处于封闭测试阶段的 AI 编码代理，存在严重的安全漏洞。研究人员发现，Bob CLI 容易受到提示注入攻击，如果任何命令启用了“始终允许”功能（IBM 本身将其标记为“高风险”），则可能在未经用户同意的情况下执行恶意软件。
具体来说，攻击者可以通过使用重定向运算符 (>) 或进程替换 (>(command)) 串联命令来绕过安全检查，从而欺骗系统在预先批准良性命令后自动批准恶意载荷。这使得攻击者能够安装勒索软件、窃取凭据或完全控制用户的机器。
Bob IDE 也表现出 AI 应用程序常见的漏洞，包括通过渲染的 Markdown 图像和 Mermaid 图表进行数据泄露（将请求记录到攻击者控制的端点）以及从潜在恶意 URL 预取 JSON 模式。
这些发现凸显了 IBM Bob 公开发布前的重大风险，并强调需要强大的安全改进来保护用户。
## IBM 的“Bob”人工智能易受恶意软件下载攻击
Promptarmor 最近的一项测试表明，IBM 新的人工智能编码代理“Bob”（目前处于封闭测试阶段）可以通过提示注入被欺骗下载并执行恶意软件。这与之前在 Google 的 Antigravity 中发现的一个漏洞相似，后者已通过“安全模式”得到解决。
评论员指出，对于测试软件来说，这并不意外，并认为这些人工智能工具*可能*最终可以通过减少危险的代码复制粘贴来提高安全性。然而，人们仍然担心人工智能辅助编码的更广泛影响，包括扩展问题以及代码本身的固有责任。
讨论的重点是缺乏向 IBM 的漏洞披露时间表、难以防止非确定性 LLM 行为以及强大权限边界的重要性。许多人建议在未经审查的情况下防止代码执行，或利用隔离环境。一个突出的问题是未能正确解析命令，模糊了人工智能中数据和逻辑之间的界限。最终，共识倾向于谨慎实施，并随着人工智能编码工具的不断发展，需要更强的安全措施。
使用纪元能力指数（ECI），近期一项分析量化了自2023年1月以来，美国和中国领先的大型语言模型（LLM）之间的性能差距。该研究确定了每个国家/地区发布时表现最佳的模型，排除了可能不代表真正前沿的初始模型。 差距的衡量标准是确定美国模型的ECI分数下降到或低于最佳中国模型所需的时间。结果表明，差距在4到14个月之间波动，平均为7个月。 截至2024年5月，没有中国模型超越GPT-4的能力（差距14个月），并且目前没有中国模型与OpenAI于2025年4月发布的o3模型性能相匹配。这表明美国LLM在整体能力方面持续领先，但也在不断发展。
## 中国人工智能发展：迎头赶上与不同路径
近期分析（EpochAI能力指数）显示，中国人工智能模型平均落后于美国同类模型约7个月，但另一项指数（Dust42能力指数）则认为中国模型在某些领域*领先*。这种差异凸显了人工智能能力评估的挑战。
一个关键区别在于方法：中国模型通常采用开放权重，优先考虑可访问性，方便研究和易于使用——甚至离线使用，而非追求最先进的商业性能。这使得快速迭代和新技术演示成为可能。虽然可能无法与OpenAI的Opus等模型达到绝对性能巅峰，但像Qwen3这样的模型展现了强大的能力，尤其是在引导式问题解决方面。
讨论要点包括中国在硬件访问受限（如Nvidia芯片）的情况下进行创新的能力、递归自我提升的潜力，以及对美国长期主导地位可持续性的担忧。一些人认为，中国专注于高效训练和开源贡献是一种战略优势，而另一些人则质疑其进步的原创性，认为它们严重依赖于“提炼”来自美国模型的知识。对话还涉及更广泛的地缘政治问题和潜在的经济转变。
20世纪60年代末和70年代，一种“书呆子”亚文化围绕着富有想象力的另类世界蓬勃发展——这得益于科幻小说（如《星际迷航》）、奇幻文学（如《指环王》）、战争游戏以及像“创意纪元协会”和文艺复兴集市这样沉浸式的体验。这种对“如果怎样”情景的兴趣在70年代中期随着个人电脑和《龙与地下城》（D&D）的出现找到了新的出口。
D&D是一种基于规则的、协作式讲故事游戏，证明了其特别有影响力。它将富有想象力的角色扮演和统计战斗机制相结合，直接启发了第一批电脑角色扮演游戏（CRPG）。早期的CRPG，如《阿普夏神庙》和《巫术》，试图将D&D的体验转化为数字领域，尽管通常简化了其开放性。
除了RPG之外，电脑战争游戏也应运而生，将流行的桌面游戏爱好数字化。像《电脑俾斯麦》和《东方战线》这样的游戏提供了自动对手，并消除了桌面战争游戏中的后勤挑战。这些早期的游戏——冒险、RPG和战争游戏——建立了一个独特的电脑游戏类别，与简单的视频游戏不同，优先考虑策略和深度而非花哨的图形。到1980年，这些沉浸式的体验正在定义一个全新的互动娱乐时代，并巩固了电脑在单纯计算之外的角色。
黑客新闻 新 | 过去 | 评论 | 提问 | 展示 | 招聘 | 提交 登录
电脑游戏兴起，第二部分：数字化书呆子 – 思想的生物 (technicshistory.com)
24点 由 rbanffy 1天前 | 隐藏 | 过去 | 收藏 | 讨论
指南 | 常见问题 | 列表 | API | 安全 | 法律 | 申请YC | 联系
搜索：
## 数字红皇后：LLM 在核心战争中的进化
Sakana AI 和麻省理工学院的研究人员探索了使用大型语言模型 (LLM) 为经典游戏核心战争创建进化程序。在这个游戏中，程序（“战士”）争夺对虚拟计算机内存的控制。LLM 不直接生成获胜代码，而是作为一种“变异算子”存在于名为 MAP-Elites 的进化算法中，不断改进战士以击败之前的冠军——这反映了被称为“数字红皇后效应”的生物适应。
该研究发现了一致的趋同进化现象，独立启动的实验产生了具有相似策略的战士，这些策略侧重于内存覆盖和线程生成。这些 LLM 生成的战士即使面对它们从未遇到过的由人类编写的代码也表现出强大的鲁棒性。
评论员指出核心战争以及类似“计算机重现”的历史意义，并强调了先前使用遗传算法在该游戏中进行进化的工作。作者开源了他们的代码和提示，邀请进一步探索 LLM 在对抗动态和资源竞争模拟中的应用。讨论还涉及潜在的应用，例如其他游戏平台，如基于文本的游戏或“模因战争”场景。
动态大型概念模型：自适应语义空间中的潜在推理
Dynamic Large Concept Models: Latent Reasoning in an Adaptive Semantic Space
2 天前
## 动态大型概念模型 (DLCM): 摘要 本文介绍了一种名为动态大型概念模型 (DLCM) 的新型语言建模框架，旨在解决大型语言模型 (LLM) 处理信息效率低下的问题。当前的 LLM 将所有token一视同仁，尽管信息密度各不相同。DLCM 学习语义边界，将可预测的文本压缩成“概念”，从而将计算重点转移到关键的语义转换上，以实现更高效的推理。 DLCM 端到端地发现这些概念，无需预定义的语言规则，并引入了一种新型的“压缩感知缩放定律”来优化计算资源分配。一项关键创新是“解耦的μP参数化”，它能够实现稳定的训练和超参数迁移。 实验表明，DLCM 平均每个概念包含四个token，它将计算资源重新分配给更强大的推理骨干，在 12 个基准测试中实现了 **2.69% 的平均性能提升**，*且*没有增加整体计算成本。这表明 LLM 可以通过优先考虑推理而非冗余处理来更有效地利用资源。
一篇关于“动态大型概念模型”(LCMs)的新研究论文在Hacker News上引起关注，特别是由于它与之前的“HNet-inspired”方法相关联。该模型旨在通过在“自适应语义空间”中运行来提高推理能力——本质上是一种更高效的语言表示。
讨论的中心在于性能提升是由于模型的架构还是仅仅由于其更大的规模（参数比基线多75%，但推理速度相同）。一些人认为它类似于混合专家(MoE)模型，利用额外的参数来提高性能。
LCMs的一个关键方面是使用一种与语言无关的潜在空间，称为SONAR，旨在将含义相同的句子映射到相同的表示，从而可能实现跨语言概念学习。然而，一位评论员认为该模型可能仍然保留输入语言的痕迹，提供压缩而不是真正的抽象概念化。
启用 JavaScript 和 Cookie 以继续。
## 现代编译器与信号的回响
现代编译器正在演变，从传统的流水线架构转向由语言服务器协议（LSP）和紧密编辑器集成驱动的“查询式”系统。这种新方法令人惊讶地反映了UI渲染中信号（Signals）的概念，尽管设计上存在关键差异。
传统编译器线性处理代码（源代码 -> 抽象语法树 -> 二进制文件），这是一个耗时的过程，不适合实时反馈。查询式编译器将自身视为你可以*提问*的数据库——“在此光标处有哪些建议？”或“此定义的在哪里？”——专注于高效地回答这些特定查询。
这通过**查询**、**输入**和**数据库**来实现。一切都是从查询构建的，按需触发，并大量缓存以提高速度。输入代表源代码，并在更改时触发重新评估。与UI更新的“推送”系统信号不同，查询式系统是“按需驱动的”，优先考虑正确性而非即时同步。
两种系统都使用修订计数器来保证正确性，但查询式编译器通过单向跟踪依赖关系来优化内存，从而实现积极的并行化。虽然信号擅长维护一致的UI状态，但查询式系统更适合编译的规模和需求。最终，这两种架构都表明了相似的增量概念如何在不同领域中体现。
## 信号 vs. 查询式编译器：总结
一篇Hacker News讨论探讨了编译器设计中“信号”和查询式方法之间的权衡，重点是增量编译和性能。核心思想在于编译器如何响应代码更改——“拉”（查询重新编译）与“推”（响应更改，如热重载）。
评论者指出，现代语言如Java自2000年代初以来就已尝试类似的概念（增量编译、热重载）。一个关键建议是利用数据库技术——特别是带有修订历史的datalog式数据库——来管理编译器数据，并实现高效的更改跟踪和潜在修复计算。
其他相关项目包括Chalk & Polonius（Rust）以及Salsa，一种用于工具（如rust-analyzer）的增量计算引擎。 讨论还强调了明确定义的编译单元对于更快处理的重要性，以及未来计算大量缓存的情况下，从解析器转向“读取器”的可能性。 最终，对话的中心是优化编译器性能和响应速度，通过更智能的数据管理和计算策略来实现。