Posts

新规概览：从生成式AI管理办法到《人工智能法》 2026年7月1日，《中华人民共和国人工智能法》正式施行。这是中国首部系统性的人工智能法律，标志着中国AI监管从碎片化管理进入了体系化治理的新阶段。 该法于2026年3月由全国人大常委会通过，共九章六十七条，涵盖AI系统分类、研发规范、使用规则、安全评估、国际合作等方面。与2023年的《生成式人工智能服务管理暂行办法》相比，新法在监管范围、责任划分和处罚力度上都有了质的飞跃。 核心制度设计 AI系统分级分类 新法最核心的制度是AI系统的分级分类管理： 第一级：不可接受风险（禁止） 社会评分系统 实时生物特征远程识别（执法场景除外） 操纵性AI系统（利用潜意识技术影响决策） 利用弱势群体特征的系统 第二级：高风险（严格审批） 医疗诊断AI 自动驾驶系统 金融决策AI（信贷审批、投资建议） 教育评价和选拔AI 就业筛选AI 司法辅助AI 关键基础设施管理AI 第三级：有限风险（备案+透明度义务） 聊天机器人 内容生成AI 推荐算法 情感识别系统 第四级：最小风险（自律管理） 垃圾邮件过滤 游戏AI 库存管理 其他未列入前三级的应用 算法备案制度 所有第三级及以上AI系统必须在国家AI监管平台进行算法备案，内容包括： 算法基本原理 训练数据来源和规模 模型架构和参数量 预期用途和使用限制 风险评估报告 应急处置预案 截至2026年6月底，已有超过2.8万个AI算法完成备案。 生成内容标识义务 新法明确要求所有AI生成内容必须带有可识别标识： 显性标识：用户可直接感知的标识（如"AI生成"水印） 隐性标识：嵌入文件元数据中的机器可读标识 内容溯源：对深度合成内容，必须保留原始素材信息 违反标识义务的，最高可处以500万元罚款。 对产业的影响 大模型公司：合规成本大幅上升 新法对大模型公司的影响最为直接： 1. 训练数据合规 新法要求训练数据必须"来源合法、内容合规"。这意味着： 网页爬取数据需验证是否违反robots协议 个人信息必须脱敏处理 需要保留数据来源证明链 某头部大模型公司估算，仅数据合规审查一项，就增加了约15%的训练成本。 2. 模型评估认证 高风险AI系统在上线前必须通过国家AI检测认证机构的评估，包括： 安全性测试（对抗攻击、越狱测试） 公平性测试（不同人群的性能差异） 鲁棒性测试（异常输入的处理能力） 可解释性评估 评估周期通常为2-4个月，费用在50-200万元不等。 3. 持续监测义务 模型上线后，运营者需要持续监测模型行为，定期提交安全报告。对于参数量超过100B的模型，每季度需提交一次详细安全报告。 应用层企业：业务模式面临调整 内容生成行业 AI生成内容标识义务对内容营销、影视制作等行业影响巨大。一家MCN公司反馈，其AI生成的短视频在添加标识后，平均完播率下降了12%，广告转化率下降了8%。 但长期来看，标识制度有助于建立用户信任。调查显示，68%的用户表示更愿意使用明确标注AI生成内容的平台。 金融行业 ...

引言 规划是智能的核心标志之一。一个Agent能否制定合理的计划、在执行过程中动态调整计划、从失败中学习改进计划，直接决定了它的能力上限。 2026年，Agent规划算法已经从简单的ReAct模式发展出多种变体。每种算法都有其适用的场景和局限。本文将系统对比这些算法，帮助开发者做出合适的选择。 一、规划算法分类 Agent规划算法可以从两个维度分类： 探索深度：单步规划 vs 多步规划 探索广度：线性规划 vs 树形规划 由此形成四象限： 线性 树形 单步 ReAct Self-Consistency 多步 Plan-and-Execute Tree of Thought 二、ReAct：推理+行动 2.1 原理 ReAct（Reasoning + Acting）是最基础的Agent规划模式。Agent在每一步中先推理（Thought），再决定行动（Action），观察结果（Observation），然后进入下一步。 Thought: 用户想知道今天北京的天气。我需要查询天气。 Action: search_weather(city="北京") Observation: 北京今天晴，最高温度35°C。 Thought: 我已经获得了天气信息，可以回答用户了。 Answer: 北京今天晴天，最高温度35°C。 2.2 优势 简单直观，易于实现 每一步都有明确的推理过程，可解释性强 适合大多数日常任务 2.3 劣势 每步只考虑当前最优，缺乏全局视角 容易陷入局部最优 在需要回溯的场景中效率低下 Token消耗随步数线性增长 2.4 适用场景 ReAct适合步骤较少（<10步）、每步决策明确、不需要回溯的任务。如信息查询、简单操作执行。 三、Plan-and-Execute：先规划后执行 3.1 原理 Plan-and-Execute将规划与执行分离。Agent首先制定一个完整的计划，然后逐步执行。执行过程中如果发现计划不可行，可以重新规划。 Plan: 1. 搜索北京今天的天气 2. 搜索北京明天的天气 3. 对比两天天气差异 4. 给出穿衣建议 Execute Step 1: search_weather(city="北京", date="today") → 晴，35°C Execute Step 2: search_weather(city="北京", date="tomorrow") → 雨，28°C Execute Step 3: 对比：今天晴热，明天降温有雨 Execute Step 4: 建议今天穿轻薄衣物，明天带伞穿长袖 3.2 优势 全局视角，避免局部最优 计划可审核，用户可以在执行前确认或修改 并行执行：无依赖的步骤可以并行 3.3 劣势 初始计划可能基于不完整信息，需要频繁重新规划 规划阶段消耗大量Token 对动态变化的环境适应性差 3.4 适用场景 适合步骤较多、需要全局规划、允许提前审核计划的任务。如项目管理、复杂工作流执行。 ...

Meta的开源野心：Llama 4来了 2026年6月，Meta正式发布Llama 4系列开源大模型。此次发布包含三个规格：Llama 4 Scout（67B）、Llama 4 Maverick（146B）和Llama 4 Behemoth（405B）。其中旗舰模型Behemoth采用混合专家架构，总参数405B，激活参数仅52B，在多项基准测试中已逼近GPT-5水平。 这是开源大模型社区的重大里程碑。Llama 4 Behemoth是迄今为止性能最强的完全开源模型，其权重、训练方法和评估结果全部公开。 架构详解 MoE架构设计 Llama 4全系采用MoE（Mixture of Experts）架构，这是Meta首次在大模型中使用MoE： # Llama 4 Behemoth MoE配置 llama4_config = { # 模型结构 "num_layers": 48, "hidden_size": 16384, "num_attention_heads": 128, "num_kv_heads": 16, # GQA "head_dim": 128, # MoE配置 "moe_layers": "all", # 所有层都使用MoE "num_experts": 64, "experts_per_token": 8, "router_type": "top_k_with_auxiliary_loss", "auxiliary_loss_weight": 0.01, # 总参数: 405B, 激活参数: 52B # 等效dense模型: ~120B # 上下文 "max_context_length": 524288, # 512K "rope_base": 500000, "rope_scaling": "dynamic", # 词表 "vocab_size": 256000, } 与Llama 3的Dense架构相比，Llama 4的MoE设计有几个关键特点： 全部层使用MoE：不同于某些MoE模型只在部分层使用专家路由，Llama 4在所有48层都使用MoE 64专家8激活：每token仅激活8个专家，计算量相当于一个52B的Dense模型 动态RoPE缩放：支持最高512K上下文窗口，且在推理时可以动态调整 注意力机制创新 Llama 4在注意力机制上做了两个重要改进： ...

引言 2026年，一个生产级Agent可能需要调用数百甚至上千个工具。从发邮件到查数据库，从写代码到部署服务，工具是Agent与物理世界交互的桥梁。但工具数量增长带来了一个棘手的问题：Agent如何从数百个工具中选择正确的那个？ 这不是一个简单的匹配问题。用户说"帮我看看昨天那个数据"，Agent需要理解"昨天"是哪天、“那个数据"指什么、应该从哪个数据源查、用什么查询语言。工具选择架构的设计直接决定了Agent的能力边界。 一、工具选择的挑战 1.1 规模挑战 当工具数量少于20个时，可以将所有工具描述放入LLM上下文，让模型直接选择。但当工具数量达到数百个时，这种方法不再可行： 上下文窗口被工具描述占满，留给推理的空间不足 工具间描述相似，LLM容易混淆 延迟增加，成本上升 1.2 语义挑战 用户意图与工具描述之间往往存在语义鸿沟。用户说"把这个发给老板”，Agent需要理解这是要发邮件，收件人是"老板"，内容是"这个"（需要从上下文解析）。 1.3 组合挑战 有些任务需要组合多个工具。例如"帮我查一下竞品最近的价格变化并生成报告"需要：搜索竞品列表→查询各竞品价格→对比分析→生成报告文档。工具选择不仅要选对单个工具，还要规划正确的执行顺序。 二、工具选择架构分层 2.1 工具索引层 工具索引层负责工具的注册、描述和索引。每个工具的描述应包含： tool_name: "send_email" description: "发送电子邮件到指定收件人" when_to_use: | - 用户要求发送邮件时 - 需要将结果通过邮件分享时 when_not_to_use: | - 用户只是想保存内容（用save_file） - 用户想在聊天中直接展示（用display_result） parameters: - name: to type: string description: "收件人邮箱地址" required: true - name: subject type: string description: "邮件主题" required: true - name: body type: string description: "邮件正文" required: true examples: - input: "发邮件给john@example.com，主题是项目更新" output: "send_email(to='john@example.com', subject='项目更新', body='...')" cost: "low" latency: "medium" 2.2 工具路由层 工具路由层是架构的核心。当Agent接收到用户请求时，路由层负责从工具池中筛选出最相关的候选工具。 ...

Gemini 3 Ultra：Google的全面反击 2026年5月，Google DeepMind发布Gemini 3 Ultra。作为Google第三代原生多模态大模型，Gemini 3 Ultra被DeepMind CEO Demis Hassabis称为"第一个真正意义上的通用AI系统"。这个评价是否名副其实？经过两个月的深度测试，我们带来了这份全面评测。 基础能力评测 文本理解与生成 在标准NLP基准测试上，Gemini 3 Ultra的表现： 基准测试 Gemini 3 Ultra GPT-6 Claude 5 MMLU (5-shot) 92.1% 93.4% 91.8% GSM8K 95.8% 97.3% 94.6% MATH 79.3% 82.1% 76.8% HumanEval 88.4% 91.2% 85.7% BBH 89.2% 90.8% 87.6% 纯文本任务上，Gemini 3 Ultra略逊于GPT-6，但差距不大。在数学和代码等强推理任务上，GPT-6仍然领先约3-4个百分点。 多模态理解 这是Gemini 3 Ultra真正的舞台。作为原生多模态模型，Gemini 3 Ultra在以下基准上表现突出： 图像理解： MMMU基准：78.3%（GPT-6: 72.1%，Claude 5: 68.4%） DocVQA（文档视觉问答）：94.2% ChartQA（图表理解）：89.7% 视频理解： VideoMME（长视频理解）：72.8%（竞品大多在50-60%） 在1小时视频中发现特定事件：准确率87% 音频理解： 多语言语音识别WER：3.2%（支持100+语言） 音频事件检测：85.6% Gemini 3 Ultra在多模态评测中的领先是显著的。特别是在视频理解领域——它能够观看一个完整的视频，然后回答关于视频内容的复杂问题，这种能力在其他模型中很少见。 ...

引言 人类的记忆是一个复杂的分层系统：感觉记忆、短期记忆、长期记忆，各有不同的容量、持续时间和检索机制。AI Agent的记忆系统也遵循类似的分层设计原则，但具体实现截然不同。 2026年，随着Agent需要在长时间跨度上执行复杂任务，记忆架构已经成为决定Agent能力上限的关键因素。本文将从认知科学和工程实践两个角度，深入探讨Agent记忆架构的设计。 一、记忆的分类体系 1.1 工作记忆（Working Memory） 工作记忆对应Agent的当前上下文窗口。它容量有限（2026年主流模型为128K-2M tokens），但访问速度最快。 工作记忆中存储的信息包括： 当前任务的描述和目标 最近的对话历史 正在处理的中间结果 活跃的工具调用结果 设计要点：工作记忆的管理核心是"什么该保留，什么该遗忘"。实践中，我们采用注意力衰减策略：越早的信息权重越低，当上下文接近满时，优先淘汰低权重信息。 1.2 情节记忆（Episodic Memory） 情节记忆记录Agent经历的具体事件——什么时候、在什么场景下、做了什么、结果如何。 每个情节记忆条目的结构： { "episode_id": "ep-001", "timestamp": "2026-07-01T14:30:00Z", "context": { "task": "数据分析报告", "environment": "production" }, "action": "执行了SQL查询分析用户行为", "result": "发现用户留存率下降15%", "outcome": "positive", "lessons": ["留存下降与新版UI发布时间吻合"] } 1.3 语义记忆（Semantic Memory） 语义记忆存储Agent学到的知识和事实，脱离了具体情境。例如"PostgreSQL在处理JSONB类型时性能优于JSON类型"。 语义记忆通常以知识图谱或向量数据库的形式存储，支持高效的语义检索。 1.4 程序记忆（Procedural Memory） 程序记忆存储Agent的技能和操作流程——如何使用某个工具、如何执行某类任务。这类似于人类的肌肉记忆。 在实现上，程序记忆可以是一组可复用的Prompt模板、工具使用模式或工作流定义。 二、记忆存储架构 2.1 三层存储模型 ┌─────────────────────────────────────┐ │ 工作记忆（LLM上下文） │ ← 快速，容量小 ├─────────────────────────────────────┤ │ 会话记忆（Redis / 内存数据库） │ ← 中速，中等容量 ├─────────────────────────────────────┤ │ 长期记忆（向量DB + 知识图谱 + 关系DB） │ ← 慢速，大容量 └─────────────────────────────────────┘ 2.2 向量数据库选择 2026年主流向量数据库对比： ...

Anthropic的野心：用上下文长度定义企业AI新标准 2026年6月底，Anthropic正式发布Claude 5企业版，最引人注目的特性是1000万token的上下文窗口——这相当于可以一次性处理约750万字的文本，或约2000页的PDF文档，或一个中型代码库的全部源代码。 这不是简单的技术参数堆砌。10M上下文窗口背后是Anthropic对企业AI市场的深层理解：企业不需要更聪明的AI，而需要能"理解全部业务上下文"的AI。 10M上下文窗口的技术实现 稀疏注意力 + 分层缓存 Claude 5企业版能够实现10M上下文，核心在于三个技术创新： 1. 稀疏注意力模式 Claude 5采用了一种动态稀疏注意力机制，根据查询的类型自动调整注意力范围： # 简化的注意力模式选择逻辑 def select_attention_pattern(query_type, context_length): if context_length < 100_000: return FullAttention() # 全注意力 elif query_type == "factual_lookup": return SparseAttention(top_k=1024) # 稀疏检索 elif query_type == "reasoning": return WindowedAttention(window=32_000, stride=8_000) elif query_type == "summarization": return ClusteredAttention(num_clusters=256) else: return HybridAttention() # 混合模式 2. 分层KV缓存 对于超长上下文，Claude 5将KV缓存分为三个层级： L0缓存：最近8K token的全精度KV（GPU HBM） L1缓存：最近256K token的8位量化KV（GPU HBM） L2缓存：完整10M token的4位量化KV（CPU内存 + NVMe SSD） 这种设计使得推理时GPU显存占用控制在40GB以内，同时保持了快速的长程信息检索能力。 3. 上下文压缩 Claude 5在处理超长上下文时会自动进行无损语义压缩——识别重复信息、模板化内容和冗余格式，将其压缩为紧凑的语义表示。实测显示，典型企业文档的压缩比可达3:1到5:1。 性能数据 在实际测试中，Claude 5企业版的10M上下文表现令人印象深刻： 指标 100K上下文 1M上下文 10M上下文 检索准确率 99.2% 98.7% 97.8% 推理质量评分 4.8/5 4.7/5 4.5/5 首token延迟 0.8s 2.1s 8.5s 端到端成本 $3/请求 $15/请求 $80/请求 可以看到，从1M到10M上下文，检索准确率仅下降0.9个百分点，但成本增加了5倍多。这意味着10M上下文应该用于真正需要的场景。 ...

引言 如果将多智能体系统比作一个组织，那么通信协议就是这个组织的语言和规则。没有良好的通信协议，再强大的Agent也只能是信息孤岛。2026年，随着多智能体应用规模从几个扩展到几十个甚至上百个，通信协议设计已经成为系统成败的关键因素。 一、通信协议的层次模型 借鉴OSI七层模型的思想，我们将Agent通信协议分为四个层次： 1.1 传输层 负责消息的物理传递。2026年的主流选择包括： HTTP/2 + SSE：适合Web原生场景，支持流式输出 gRPC：高性能RPC框架，适合内部服务间通信 WebSocket：全双工通信，适合实时交互场景 Message Queue（Kafka/NATS）：适合异步解耦场景 1.2 消息层 定义消息的封装格式。目前有三种主流格式： JSON：可读性好，生态丰富，但冗余度高。适合原型开发和小规模系统。 Protocol Buffers：二进制格式，高效紧凑。适合高性能场景和跨语言通信。 MessagePack：介于JSON和Protobuf之间，兼顾可读性和效率。 1.3 语义层 定义消息的含义和意图。这是Agent通信协议与传统分布式系统协议最大的区别。一条消息不仅包含数据，还包含发送者的意图、期望的回应类型和处理优先级。 1.4 会话层 管理Agent间的多轮交互。包括会话建立、维护、终止，以及会话状态的同步。 二、消息格式设计 一个好的Agent通信消息格式应该包含以下字段： { "message_id": "msg-uuid-001", "conversation_id": "conv-uuid-001", "from": { "agent_id": "researcher-01", "agent_type": "research_agent", "capabilities": ["web_search", "data_analysis"] }, "to": { "agent_id": "writer-01", "agent_type": "writing_agent", "capabilities": ["content_generation"] }, "intent": "request_review", "content": { "type": "document_draft", "data": "...", "metadata": { "word_count": 1500, "language": "zh-CN" } }, "expected_response": { "type": "review_feedback", "deadline": "2026-07-01T10:30:00Z" }, "priority": "normal", "requires_ack": true, "timestamp": "2026-07-01T10:00:00Z" } 关键设计决策 意图字段（intent）：明确消息的目的，如request_info、provide_result、request_review、delegate_task等。这帮助接收方快速理解如何处理消息。 期望响应（expected_response）：告知接收方应该返回什么类型的响应，降低误解概率。 能力声明（capabilities）：发送方声明自己的能力，便于接收方判断是否需要转发给其他Agent。 三、通信模式 3.1 请求-响应 最基础的通信模式。Agent A向Agent B发送请求，B处理后返回响应。适用于同步、一对一的场景。 3.2 发布-订阅 Agent发布消息到主题，所有订阅该主题的Agent都能收到。适合一对多、解耦的场景。例如，一个Agent发布"新数据可用"事件，多个Agent各自处理。 ...

泄露事件回顾 2026年6月中旬，GitHub上出现了一个名为"gpt6-architecture-reference"的仓库，其中包含了据称是OpenAI GPT-6模型架构的部分技术文档和代码片段。尽管该仓库在48小时内被删除，但技术社区已经对其内容进行了全面分析和存档。 OpenAI官方既未确认也未否认泄露内容的真实性。但多位前OpenAI员工在匿名采访中表示，泄露的架构描述与他们了解的GPT-6方向"高度一致"。本文基于泄露内容和社区分析，梳理GPT-6可能的关键技术变化。 架构变化：从纯Transformer到混合架构 泄露文档中最引人注目的变化是：GPT-6不再采用纯Transformer架构，而是引入了混合专家（MoE）与状态空间模型（SSM）的融合架构。 MoE配置升级 根据泄露代码，GPT-6的MoE配置如下： # GPT-6 MoE Configuration (from leaked reference) config = { "total_params": 1.8e12, # 1.8万亿总参数 "active_params": 220e9, # 2200亿激活参数 "num_experts": 128, # 128个专家 "experts_per_token": 8, # 每token激活8个专家 "router_type": "hierarchical", # 层级路由 "router_loss": 0.02, # 负载均衡损失 "expert_specialization": "semantic", # 语义特化 } 与GPT-4的16个专家相比，GPT-6扩展到128个专家，但每token仅激活8个。这意味着在总参数量增加约4.5倍的情况下，单次推理的计算量只增加了约1.5倍。层级路由机制让专家选择更加精准——先在高层级分组中选择，再在组内细选，降低了路由错误率。 SSM层的引入 GPT-6的另一个重大变化是在部分层中用Mamba2风格的状态空间模型替换了自注意力机制： class HybridLayer(nn.Module): def __init__(self, config): super().__init__() # 交替使用Attention和SSM self.use_attention = config.layer_idx % 3 != 0 if self.use_attention: self.attn = GroupedQueryAttention( num_heads=96, num_kv_heads=8, head_dim=128, use_rope=True, context_length=2_097_152 # 2M上下文 ) else: self.ssm = Mamba2Block( d_model=12288, d_state=512, expand_factor=4, chunk_size=256 ) 这种设计的优势在于：SSM层在处理长序列时的时间和空间复杂度为O(n)，而注意力机制为O(n²)。通过每三层中用一层SSM替换注意力，GPT-6在保持2M上下文窗口的同时，推理成本仅比GPT-4的128K上下文高约40%。 原生多模态设计 GPT-6从架构层面就是为多模态设计的，而非后期拼接。泄露代码显示了一个统一的token化方案： 文本：BPE tokenizer（词汇表256K） 图像：16x16 patch，经ViT编码后投影到文本嵌入空间 音频：EnCodec 24kHz，每秒75个token 视频：每帧图像token + 时序位置编码 所有模态共享同一个Transformer主干，这意味着跨模态推理不再需要额外的对齐模块。 训练数据与对齐 训练数据规模 泄露文档提到GPT-6的训练数据量约为300万亿token，是GPT-4的约15倍。数据组成： ...

2026年AI芯片市场：三足鼎立的新格局 2026年7月，全球AI芯片市场的竞争已经进入白热化阶段。NVIDIA、AMD和Intel三家巨头在数据中心AI加速器领域的争夺战，正在重塑整个科技产业的权力版图。从训练到推理，从云端到边缘，每一家都在用自己的方式寻找突破口。 NVIDIA：霸主地位依然稳固，但护城河正在被侵蚀 NVIDIA在2026年上半年的市值一度突破4万亿美元，这主要得益于Blackwell架构的全面铺开。Blackwell Ultra GPU（B300系列）在Q2开始规模出货，单卡FP4性能达到15 PFLOPS，较上一代Hopper H200提升了约3.2倍。 但NVIDIA的真正优势不在芯片本身，而在其CUDA生态。截至2026年6月，CUDA开发者社区已超过600万人，几乎所有主流AI框架的首选后端仍然是CUDA。这种生态壁垒不是一两代芯片就能打破的。 然而，NVIDIA也面临严峻挑战： 产能瓶颈：台积电的CoWoS封装产能仍然紧张，Blackwell Ultra的交付周期长达12-16周 价格压力：B300单卡售价超过4万美元，大型数据中心客户的TCO压力巨大 客户自研芯片：Google TPU v6、AWS Trainium 3、Microsoft Maia 2都在蚕食NVIDIA的市场份额 NVIDIA 2026财年Q2数据中心营收预计达到380亿美元，同比增长65%，但增速已明显放缓。 AMD：MI400是最后的机会 AMD在2026年的处境可以用"不成功便成仁"来形容。MI300X虽然取得了商业成功（2025年数据中心GPU营收超过50亿美元），但市场份额仍然不到NVIDIA的1/5。 2026年6月，AMD正式宣布MI400系列，采用3nm工艺和全新的CDNA 4架构： 规格 MI400 NVIDIA B300 制程 3nm (TSMC) 3nm (TSMC) FP8性能 12 PFLOPS 15 PFLOPS 显存 288GB HBM3e 192GB HBM3e 显存带宽 8.6 TB/s 8.0 TB/s 功耗 1000W 1200W 预估售价 ~$32,000 ~$42,000 MI400的策略很明确：用更大的显存和更低的价格来吸引对成本敏感的客户。Meta和Microsoft已经确认采购MI400用于推理负载。 AMD的软件栈ROCm在2026年也取得了长足进步。PyTorch 3.0对ROCm的原生支持已接近CUDA水平，Hugging Face上超过80%的模型可以在ROCm上无修改运行。 但AMD最大的问题仍然是生态深度——在分布式训练、内核优化、社区支持等方面，与CUDA的差距依然明显。 Intel：转型中的巨人 Intel的AI芯片之路走得最为坎坷。Gaudi 3虽然获得了部分企业客户，但市场份额不到3%。2026年，Intel押注的是Falcon Shores——一款融合GPU和AI加速器的新架构产品。 Falcon Shores原计划2025年发布，但推迟到了2026年Q3。根据Intel公布的规格，其FP8性能目标为10 PFLOPS，支持256GB HBM3e，采用Intel 18A工艺。 ...