ITPub博客

在今年的 AI Hardware Forum 上，IBM Research 及其合作伙伴展示了他们如何通过开放生态系统中的完整解决方案来变革 AI 时代。 AI 的下一次飞跃不会由一家公司或一个实验室完成，IBM Research 高级技术员工 Griselda Bonilla 宣称。“它将通过协作来实现。” 站在 Thomas J. Watson Research Center 礼堂的舞台中央，Bonilla 在第六届年度 AI Hardware Forum 开幕时发表了这些开场致辞，该论坛由 IBM Research AI Hardware Center 赞助。随后是一天的演讲和小组讨论，由来自产业界和学术界的 AI 研究人员主持，核心围绕构建支持未来 AI 异构硬件生态系统的开放软件。

当你想到处理 AI 任务的输入和输出时，图形处理器（GPU（图形处理器））可能是首先浮现在脑海中的主要基础设施组件。但它们只是拼图中的一块。如果没有合适的网络和存储基础设施，即使配备最先进的 GPU，当今的 AI 应用也会运行缓慢且成本高昂到令人望而却步。多年来，这对 AI 训练而言一直如此，而如今对 AI 推理同样如此。 基于大语言模型（LLM（大语言模型））的推理是现代 AI 应用的主要工作负载，它对所有三种基础设施资源（计算、网络和存储）造成了巨大压力，以至于全新的软件能力正在涌现，以支持推理的资源管理和优化。值得注意的例子包括 llm-d、vLLM 和 Dynamo。如果不对预计算的推理产物进行高效管理和复用，你既会让 GPU 因冗余的重复计算而不堪重负，又要等待很长时间才能让 LLM 响应每次查询。

今天，Cisco Talos 为 Cisco Secure Firewall 中的 Snort3 用户推出新功能。这些增强功能旨在让您在管理、组织和优先排序检测规则方面拥有更大的灵活性。它们还能让您更轻松地使 SNORT® 规则与您组织的特定安全需求保持一致。 在 Snort3 中，规则组允许您根据特定条件组织和检测规则。此前，只有两个顶级组可用： Rule Category：按 Snort2 类别对规则进行分组，例如 FILE-OTHER、MALWARE-CNC 等。 MITRE ATT&CK：按攻击者行为和技术对规则进行分组 这些组允许您设置从 0（禁用所有规则）到 4（启用所有规则）的安全级别。 新的 Severity 规则组引入了第三种组织规则的方式——按漏洞严重性，使用 CVSS 评分。

欢迎回到Humans of Talos。本月，Amy与来自战略分析团队的高级网络威胁分析师Lexi DiScola进行了交流。Lexi进入网络安全的旅程绝非传统路径——她将政治学和法语的背景带入到追踪全球网络威胁和与跨大洲同事协作的工作中。 请收听Lexi坦诚分享她如何在网络安全领域找到自己的位置、非技术背景带来的独特优势，以及平衡复杂情报分析与家中高耸待读（TBR）书堆的乐趣（与挑战）。 Amy Ciminnisi：你能介绍一下自己吗？你在Talos做什么？你在哪个团队工作，你的日常工作是什么样的？ Lexi DiScola：当然。我在Talos的战略分析团队。我大约三年前加入。我的团队做的事情非常多，但实际上我们专注于追踪和分析网络威胁态势中的主要趋势。我们与许多私营部门和政府合作伙伴保持情报共享关系。

现代云应用程序通常构建为一组松散耦合的微服务，运行在 Amazon Elastic Kubernetes（容器编排平台） Service（Amazon EKS）、Amazon Elastic Container Service（Amazon ECS）或 AWS Lambda 等服务上。这种架构为工程团队提供了灵活性和可扩展性，但其固有的分布式特性也使得故障排查更加困难。当出现问题时，工程师往往需要翻阅分散在不同可观测性层中的日志、事件和指标。以 Kubernetes 为例，如果对服务缺乏深入理解，故障排查可能会变成一项耗时的工作，需要手动关联来自不同来源的信息。 在本文中，我们将介绍如何为 Kubernetes 构建一个由生成式 AI 驱动的故障排查助手。

Pushmeet Kohli 和 Tom Lue 我们正处在一个拐点，先进 AI 与科学研究的融合有望开启一个新的发现黄金时代。认识到这一点，我们很高兴支持白宫的 Genesis Mission——一项历史性的国家行动，旨在利用 AI 变革科学研究的方式，并加速美国科学的发展速度。Genesis Mission 将动员美国能源部（DOE）的 17 个国家实验室、产业界和学术界，共同构建一个集成发现平台，加速在能源、科学发现和国家安全等国家最紧迫挑战上的突破。 在 Google DeepMind，我们的使命是负责任地构建 AI，以造福人类。也许没有比将 AI 应用于科学更能清晰体现这一点的了。

在服务大量短请求时，嵌入模型推理往往难以兼顾效率——这是搜索、检索和推荐系统中的常见模式。在 MongoDB 旗下的 Voyage AI，我们将这些短请求称为查询（queries），其他请求则称为文档（documents）。查询通常必须以极低延迟（通常为 100–300 毫秒）提供服务。 查询通常较短，其 token 长度分布高度偏斜。因此，查询推理往往受内存限制而非计算限制。查询流量波动很大，因此自动扩缩容过于缓慢。总之，顺序服务大量短请求的效率极低。 在这篇博客文章中，我们探讨如何利用批处理（batching）来更高效地服务查询。我们首先讨论现代推理引擎中的填充移除（padding removal），这是一项实现有效批处理的关键技术。然后，我们介绍形成批次和选择合适批次大小的实用策略。

William Isaac 和 Owen Larter 今天，我们宣布通过一份新的谅解备忘录扩大与英国人工智能安全研究所（UK AI Security Institute，AISI）的合作关系，聚焦基础安全与安保研究，以帮助确保人工智能安全发展并惠及所有人。 与 AISI 的研究合作是我们与英国政府在加速安全且有益的人工智能进展方面更广泛合作的重要组成部分。 人工智能在帮助治疗疾病、加速科学发现、创造经济繁荣和应对气候变化方面具有造福人类的巨大潜力。要实现这些益处，我们必须将安全和责任置于开发的核心。针对广泛潜在风险对我们的模型进行评估，仍然是我们安全战略的关键部分，而外部合作是这项工作的重要元素。 正因如此，自英国 AISI 于 2023 年 11 月成立以来，我们一直与其合作测试我们最强大的模型。

产品管理总监 杰出研究科学家 您的浏览器不支持音频元素。 本周早些时候，我们通过升级 Gemini 2.5 Pro 和 Flash 文本转语音模型，引入了对音频生成更强的控制能力。 但生成富有表现力的语音只是对话的一方面。今天，我们发布了面向实时语音智能体的更新版 Gemini 2.5 Flash Native Audio。此次更新提升了模型处理复杂工作流、遵循用户指令以及进行自然对话的能力。 Gemini 2.5 Flash Native Audio 现已在 Google 产品中上线，包括 Google AI Studio、Vertex AI，并已开始在 Gemini Live 和 Search Live 中逐步推出，首次将原生音频的自然感带入 Search Live。

语言模型可解释性团队 发布一套全新的、开放的语言模型可解释性工具套件 大语言模型（LLM（大语言模型））具备惊人的推理能力，然而其内部决策过程在很大程度上仍然是不透明的。如果系统未按预期运行，缺乏对其内部工作机制的可见性会使我们难以准确定位其行为的确切原因。去年，我们通过 Gemma Scope 推进了可解释性科学，这是一个旨在帮助研究人员理解 Gemma 2（我们的轻量级开放模型系列）内部工作机制的工具包。 今天，我们发布 Gemma Scope 2：一套全面的、开放的可解释性工具套件，适用于所有 Gemma 3 模型规模，从 270M 到 27B 参数。这些工具使我们能够追踪模型整个“大脑”中的潜在风险。 据我们所知，这是迄今为止 AI 实验室在可解释性工具方面规模最大的一次开源发布。

Gemini 3 Flash 是我们最新的模型，具备为速度打造的前沿智能，帮助每个人更快地学习、构建和规划任何事情。 产品管理高级总监，代表 Gemini 团队 您的浏览器不支持音频元素。 今天，我们通过发布 Gemini 3 Flash 扩展了 Gemini 3 模型系列，它以极低的成本提供为速度打造的前沿智能。通过此次发布，我们让 Gemini 3 的下一代智能通过 Google 产品惠及所有人。 上个月，我们以 Gemini 3 Pro 和 Gemini 3 Deep Think 模式开启了 Gemini 3 的序幕，反响令人难以置信。自发布之日起，我们的 API（应用程序编程接口） 每天处理超过 1T tokens。

这是智能体、推理与科学发现的一年。 Google DeepMind 首席执行官 研究、实验室、技术与社会高级副总裁 您的浏览器不支持音频元素。 2025 年是研究取得非凡进展的一年。借助人工智能，我们可以看到其轨迹正从工具转向实用：从人们使用的东西，变成人们可以投入工作的东西。如果说 2024 年是为这个时代奠定多模态基础，那么 2025 年就是 AI 开始真正思考、行动，并与我们一同探索世界的一年。在量子计算方面，我们朝着现实世界应用取得了进展。而在各个方面，我们都帮助将研究转化为现实，以更强大、更有用的产品和工具，对当今人们的生活产生积极影响。 下面回顾一下在这一年不懈进展中，定义 Google、Google DeepMind 和 Google Research 工作的一些突破、产品和科学里程碑。

IBM 研究人员提出了一种对流行大语言模型（LLM（大语言模型））架构的改进方案，以提升其记忆和逻辑推理能力，并使某些类型的数学问题更加直观。 支撑当今大语言模型的 Transformer（深度学习中的注意力模型架构） 架构挑战了我们对 AI 能力的既有认知。编写代码、语言翻译、从网络各个角落综合信息——这些任务如今的大语言模型似乎都能轻松应对。短短几年间，它已经改变了我们的工作方式。 但基于 Transformer 的模型存在固有局限，研究人员在试图扩展其能力并降低计算成本时不断遭遇这些瓶颈。Transformer 的核心缺陷之一——至少在理论上——在于其对序列数据建模的能力有限。这会使某些计数问题变得出奇地困难——比如统计“strawberry”中有几个“r”。

iSWE-Agent（智能体） for Java 在 GitHub issue 解决任务中占据了排行榜前两名。第一个条目使用前沿模型的单次运行，第二个条目使用开放模型的推理扩展。 就像汽车机械师的天赋最好花在修理发动机上，而不是整天修补漏气的轮胎，软件工程师的价值在于他们创造性的问题解决能力。不幸的是，工作日很容易被调试、编码和文档编写所吞噬。IBM Research 的一款新智能体 AI 工具旨在分担软件工程师工作中较为单调的部分，而两个新版本正引领潮流。 IBM 的软件工程（iSWE）-Agent for Java 目前在 Multi-SWE-Bench 的 Java 类别中占据第一和第二名。一个条目基于前沿模型 Claude 4.5 Sonnet，位居排行榜榜首，另一个基于开源模型，位列第二。

斯坦福大学基础模型透明度指数今年将 IBM Granite 评为第一名——创下该指数历史最高分。 如今，基础模型无处不在，为聊天机器人、代码助手和地理空间模型等各种 AI 工具提供支持。但随着基础模型改变越来越多的商业领域和我们的日常生活，值得一问的是：我们真的了解它们是如何构建的吗？ 这正是斯坦福大学基础模型研究中心所关注的问题，该中心今天发布了第三份年度基础模型透明度指数（FMTI）报告。IBM 于 2024 年将其 Granite 模型开源，但仅靠开放并不总能等同于对开发者和终端用户的透明。FMTI 根据 100 项不同指标对主流基础模型的透明度进行评分，包括数据来源、风险评估、开放权重、外部可复现性、事件报告协议和数据使用政策。

随着企业开发者开始部署智能体，他们面临一个共同的挑战：所依赖的工具并不总是为智能体使用做好准备。我们最近推出了 Agent（智能体） lifecycle Toolkit (ALTK)，其中包含可以稳定工具调用和后处理的组件，但许多故障的根源要早得多。工具可能描述不清，或元数据稀疏，导致智能体难以可靠地选择和调用它们。这会导致工具选择错误、参数格式错误，以及难以大规模诊断的脆弱智能体行为。 为弥补这一差距，我们推出 ToolOps，这是一组新的构建时 ALTK 组件，帮助团队为企业级智能体工作流构建、准备和验证工具。ToolOps 专注于改进工具语义、生成测试场景，并在部署前验证智能体与工具交互的方式。 即使是简单的 Python 工具，如果没有清晰的语义，智能体也可能难以使用。

为了帮助 AI 开发者更准确地评估模型能力，IBM Research 与圣母大学正在开源一个模板和自动化工具，用于大规模创建 LLM（大语言模型） 基准卡片。 如今 AI 的许多进展都可归功于基准测试——这些严谨、标准化的测试旨在揭示大语言模型能做什么、不能做什么，并推动进一步的创新。 基准测试提供了一种结构化方式，用于并排比较模型，并评估其偏见、风险以及对特定任务的适用性。一个 LLM 的受欢迎程度可能因其基准分数而上升或下降。那么，为什么这些人人共享的成败攸关的考试，其文档却如此糟糕？ IBM Research 的高级技术员工 Elizabeth Daly 在审视基准文档不一致、往往不完整的状态时，一直这样问自己。 “我开始看到可用信息与测试框架中信息表示方式之间存在巨大的脱节，”她说。

Ben Dicken [ @ BenjDicken ] | 2024 年 3 月 29 日 尽管我们尽力避免，但性能不佳的查询很容易在我们的工作负载中悄然出现，对数据库系统的性能产生负面影响。在大规模数据库环境中尤其如此，这些环境拥有数 GB 或数 TB 的数据、数百张表，以及每天执行的数千种查询模式。 幸运的是，MySQL 能够收集可用于识别有问题的查询的数据，并且还可以对这些查询进行分析，以深入了解其性能不佳的原因。在本文中，我将介绍几种在原生 MySQL 中实现此目的的内置技术。如果你使用 PlanetScale，则可以使用 PlanetScale Insights 仪表板更轻松、更直观地收集此类信息。我将在后文简要讨论此功能。 在本文中，我将使用以下 schema 作为示例。

Mike Coutermarsh | 2024年4月4日 工程团队的开发速度是 PlanetScale 的首要任务之一，无论是对我们自己的团队，还是对所有使用我们构建的工具的开发者而言。 在构建 PlanetScale 时，我们的早期目标之一就是为工程团队打造绝对最佳的模式变更流程。过去 3 年里我们一直在迭代优化，对于如今更改应用程序模式的便捷程度，我们越来越感到满意。 我们的主 API（应用程序编程接口） 是一个 Ruby on Rails 应用程序，连接了两个 PlanetScale 数据库。其中一个数据库包含我们大部分的业务和用户数据。另一个是更大的分片数据库，用于处理支撑 PlanetScale Insights 所需的大规模负载。 我们的团队几乎每天都会对这些数据库进行模式变更。

博客 | 工程 | Vitess Matt Lord | 2024年7月29日 Vitess 是一个广受欢迎的 CNCF 项目，被 Slack、Square、Shopify 和 GitHub 等公司用于扩展全球最大规模的 MySQL 部署。它提供了分片、连接池以及许多其他功能，使 MySQL 的水平扩展变得简单易行。 Vitess 和 MySQL 非常适合用作在线事务处理（OLTP）系统——在这种系统中，最终用户直接与系统交互，快速响应时间至关重要，用户获取产品和服务信息，生成订单、用户档案等关键业务记录。它们并未针对在线分析处理（OLAP）工作负载以及随着产品、公司和数据需求增长而遇到的其他用例和需求进行优化。