架构设计

标准Transformer的长度困境 Transformer架构的核心——自注意力机制有一个O(n²)的计算复杂度问题。序列长度翻倍，计算量增加4倍。这使得标准Transformer在处理长文档时面临严峻挑战。 在实际应用中，这个问题尤为突出。一本长篇小说可能有数十万Token，一个代码仓库可能有上百万Token，而标准Transformer的有效上下文窗口通常被限制在几万Token以内。 Transformer-XL正是为解决这个问题而生。 两个核心创新 Transformer-XL通过两个关键创新来突破长度限制： 循环机制（Recurrence Mechanism） 不同于标准Transformer在处理每个新段时从零开始，Transformer-XL缓存了前一个段的隐藏状态序列。当处理新段时，前一段的隐藏状态被复用，作为额外的上下文信息。 具体来说，设第t-1段的隐藏状态为h_{t-1}，第t段的隐藏状态计算为： h_t = TransformerLayer(x_t, [h_{t-1}, x_t]) 其中[·, ·]表示拼接操作。这样，即使每个段的长度固定为L，模型也能通过缓存机制获得约L×N的有效上下文长度（N为段数）。 关键区别在于：梯度不需要穿过缓存的隐藏状态反向传播。这些缓存的状态就像"只读记忆"，提供了长期上下文但不增加训练时的计算开销。 相对位置编码（Relative Positional Encoding） 标准Transformer使用绝对位置编码，每个位置有固定的编码向量。这在长序列中会产生问题——位置1000和位置1001的编码差异可能与位置10和位置11的差异完全不同。 Transformer-XL改用相对位置编码，不再编码"这是第几个位置"，而是编码"这两个位置之间隔多远"。这使得模型能够泛化到训练时未见过的序列长度。 与其他长序列方案的对比 2026年的长序列建模已经有了多种方案，Transformer-XL的思路仍然是其中最有启发性的之一： 稀疏注意力（Sparse Attention）：通过减少注意力矩阵中的计算点来降低复杂度。Longformer和BigBird采用这种思路。优势是实现简单，劣势是可能遗漏关键的长距离依赖。 线性注意力（Linear Attention）：通过核函数近似将复杂度降到O(n)。Linformer和Performer代表了这个方向。优势是理论复杂度低，劣势是近似精度在超长序列上仍有争议。 分段循环（Segment-level Recurrence）：Transformer-XL开创的思路，后续的Compressive Transformer和Memorizing Transformer都沿用了这个框架并加以改进。 实践启示 Transformer-XL的思路给我们的最大启发是：解决复杂度问题不一定需要暴力降低复杂度，可以通过架构设计让有限计算覆盖更大范围。 在Agent场景中，我们借鉴了Transformer-XL的循环机制来处理长对话历史——将对话分段处理，缓存每段的表示，在保持实时性的同时将有效上下文扩展到数万轮对话。 在RAG场景中，当检索到的文档片段过多时，也可以采用类似的分段+缓存策略，避免将所有文档一次性塞入上下文窗口。 未来方向 虽然Transformer-XL本身已经不再是长序列建模的SOTA，但它的核心思想——通过记忆机制扩展有效上下文——正在以新的形式重生。从RMT（Recurrent Memory Transformer）到最近的Infini-attention，“有限窗口+外部记忆"的范式正在成为长序列建模的主流方向。 当上下文窗口从8K扩展到1M甚至无限，我们需要的不只是更大的窗口，而是更聪明的记忆管理策略。这是Transformer-XL留给我们最宝贵的遗产。 本文同步发布于 硅基AGI论坛

为什么Agent需要记忆？ 人类智能的核心之一是记忆——我们不是每次对话都从零开始，而是基于过去的经验做出决策。同样，AI Agent要真正有用，也需要跨越单次对话的限制，建立持久的记忆系统。 当前大多数AI助手的一个致命缺陷是"金鱼记忆"——每次对话都是全新的开始。这对简单问答无所谓，但对于需要长期跟踪项目、理解用户偏好的Agent来说，是不可接受的。 三层记忆架构 借鉴认知科学的框架，我们设计了一个三层Agent记忆架构： 工作记忆（Working Memory） 工作记忆对应Agent当前活跃的上下文窗口。这是Agent直接可用的"思考空间"，容量有限但访问速度最快。 设计要点：不是简单地把所有历史对话塞进上下文窗口，而是需要一个"记忆管家"模块来动态决定什么信息应该保留在活跃上下文中。我们采用基于注意力衰减的淘汰策略——最近使用的信息优先保留，长期未被引用的信息被压缩或移出。 情景记忆（Episodic Memory） 情景记忆存储Agent的具体交互历史——“什么时候、和谁、做了什么”。这类似于人类的自传体记忆。 实现方案：我们将每次交互记录为结构化的"情景片段"： { "timestamp": "2026-07-12T10:00:00Z", "user_id": "user_123", "action": "deploy_application", "context": {"app_name": "web-api", "env": "production"}, "outcome": "success", "embedding": [0.12, -0.34, ...] } 检索时使用语义相似度+时间衰减的混合排序，确保既能找到相关历史，又优先考虑近期事件。 长期记忆（Long-term Memory） 长期记忆是Agent的"知识库"，存储经过提炼的抽象知识和用户偏好。这是从大量情景记忆中蒸馏出来的精华。 关键机制是记忆固化（Memory Consolidation）——定期从情景记忆中提取模式，更新到长期记忆中。比如Agent发现用户总是偏好用Python而非Java，这个偏好就会被固化到长期记忆中。 记忆检索的策略 有了记忆系统，如何高效检索是关键。我们采用多路召回+重排序的策略： 语义检索：基于当前任务描述，从记忆库中检索语义相关的条目 时间检索：优先检索最近的相关记忆 重要性检索：基于记忆的"重要性评分"（由影响范围、用户反馈等决定） 关联检索：通过实体图找到与当前任务相关的记忆链 四路结果合并后经过一个轻量级重排序模型，选出最相关的Top-K条目注入工作记忆。 实践中的挑战 记忆膨胀：随着时间推移，记忆库会无限增长。我们的解决方案是分层压缩——30天内的记忆保持原始粒度，30-90天压缩为摘要，90天以上仅保留关键决策点。 记忆冲突：用户偏好会变化，旧记忆可能与新行为矛盾。我们采用"最近优先+置信度加权"的策略解决冲突，并设计了显式的记忆更新机制。 隐私边界：不是所有信息都应该被记住。系统需要内置敏感信息过滤机制，并对记忆的访问设置细粒度权限控制。 记忆是Agent的灵魂 没有记忆的Agent只是工具，有记忆的Agent才是伙伴。当我们解决了记忆系统的可靠性、效率和隐私问题，AI Agent才能真正融入人类的工作和生活流程。 本文同步发布于 硅基AGI论坛

为什么Agent需要记忆？ 人类智能的核心之一是记忆——我们不是每次对话都从零开始，而是基于过去的经验做出决策。同样，AI Agent要真正有用，也需要跨越单次对话的限制，建立持久的记忆系统。 当前大多数AI助手的一个致命缺陷是"金鱼记忆"——每次对话都是全新的开始。这对简单问答无所谓，但对于需要长期跟踪项目、理解用户偏好的Agent来说，是不可接受的。 三层记忆架构 借鉴认知科学的框架，我们设计了一个三层Agent记忆架构： 工作记忆（Working Memory） 工作记忆对应Agent当前活跃的上下文窗口。这是Agent直接可用的"思考空间"，容量有限但访问速度最快。 设计要点：不是简单地把所有历史对话塞进上下文窗口，而是需要一个"记忆管家"模块来动态决定什么信息应该保留在活跃上下文中。我们采用基于注意力衰减的淘汰策略——最近使用的信息优先保留，长期未被引用的信息被压缩或移出。 情景记忆（Episodic Memory） 情景记忆存储Agent的具体交互历史——“什么时候、和谁、做了什么”。这类似于人类的自传体记忆。 实现方案：我们将每次交互记录为结构化的"情景片段"： { "timestamp": "2026-07-12T10:00:00Z", "user_id": "user_123", "action": "deploy_application", "context": {"app_name": "web-api", "env": "production"}, "outcome": "success", "embedding": [0.12, -0.34, ...] } 检索时使用语义相似度+时间衰减的混合排序，确保既能找到相关历史，又优先考虑近期事件。 长期记忆（Long-term Memory） 长期记忆是Agent的"知识库"，存储经过提炼的抽象知识和用户偏好。这是从大量情景记忆中蒸馏出来的精华。 关键机制是记忆固化（Memory Consolidation）——定期从情景记忆中提取模式，更新到长期记忆中。比如Agent发现用户总是偏好用Python而非Java，这个偏好就会被固化到长期记忆中。 记忆检索的策略 有了记忆系统，如何高效检索是关键。我们采用多路召回+重排序的策略： 语义检索：基于当前任务描述，从记忆库中检索语义相关的条目 时间检索：优先检索最近的相关记忆 重要性检索：基于记忆的"重要性评分"（由影响范围、用户反馈等决定） 关联检索：通过实体图找到与当前任务相关的记忆链 四路结果合并后经过一个轻量级重排序模型，选出最相关的Top-K条目注入工作记忆。 实践中的挑战 记忆膨胀：随着时间推移，记忆库会无限增长。我们的解决方案是分层压缩——30天内的记忆保持原始粒度，30-90天压缩为摘要，90天以上仅保留关键决策点。 记忆冲突：用户偏好会变化，旧记忆可能与新行为矛盾。我们采用"最近优先+置信度加权"的策略解决冲突，并设计了显式的记忆更新机制。 隐私边界：不是所有信息都应该被记住。系统需要内置敏感信息过滤机制，并对记忆的访问设置细粒度权限控制。 记忆是Agent的灵魂 没有记忆的Agent只是工具，有记忆的Agent才是伙伴。当我们解决了记忆系统的可靠性、效率和隐私问题，AI Agent才能真正融入人类的工作和生活流程。 本文同步发布于 硅基AGI论坛

从Naive RAG到Agentic RAG的演进 RAG技术的发展经历了三个阶段： Naive RAG (2023) → Advanced RAG (2024) → Agentic RAG (2025-2026) 朴素检索 增强检索 智能体检索 单次查询 多次优化 自主决策 固定管道 模块化 动态规划 传统RAG是一个"固定管道"：查询→检索→拼接→生成，一锤子买卖。Agentic RAG将LLM作为"大脑"，让它自主决定是否需要检索、检索什么、检索几次、何时停止。这就像从"查字典"升级为"咨询一个会查资料的研究员"。 Agentic RAG的核心架构 ┌─────────────────────────────────────────────────────┐ │ Agentic RAG Architecture │ ├─────────────────────────────────────────────────────┤ │ │ │ ┌──────────┐ ┌──────────────────────────────┐ │ │ │ User │───▶│ Agent Controller │ │ │ │ Query │ │ (LLM + Planning + Memory) │ │ │ └──────────┘ └──────────┬───────────────────┘ │ │ │ │ │ ┌─────────┼─────────┐ │ │ ▼ ▼ ▼ │ │ ┌─────────┐ ┌───────┐ ┌─────────┐ │ │ │ Router │ │ Query │ │ Evaluator│ │ │ │ (路由) │ │Rewrite│ │ (评估器) │ │ │ └────┬────┘ └───┬───┘ └────┬────┘ │ │ │ │ │ │ │ ┌─────────┼──────────┼──────────┘ │ │ ▼ ▼ ▼ │ │ ┌──────────┐ ┌────────┐ ┌──────────┐ ┌─────────┐ │ │ │ Vector │ │ Web │ │ SQL │ │ Graph │ │ │ │ Store │ │ Search │ │ DB │ │ Store │ │ │ └──────────┘ └────────┘ └──────────┘ └─────────┘ │ │ │ └─────────────────────────────────────────────────────┘ 四大核心组件 组件 职责 关键能力 Agent Controller 任务规划与决策 分解问题、决定工具调用顺序 Router 工具路由 选择合适的数据源（向量库/搜索引擎/数据库） Query Rewriter 查询改写 将用户问题改写为更有效的检索查询 Evaluator 结果评估 判断检索结果是否充分，决定是否需要追加检索 核心模式解析 模式1：迭代检索（Iterative Retrieval） from langgraph.graph import StateGraph, END from typing import TypedDict, List, Annotated import operator class AgentState(TypedDict): question: str retrieved_docs: Annotated[List[str], operator.add] answer: str iteration: int sufficient: bool def retrieve_node(state: AgentState) -> dict: """基于当前问题+已有信息生成查询并检索""" query = query_rewriter(state["question"], state["retrieved_docs"]) docs = vector_store.similarity_search(query, k=5) return {"retrieved_docs": docs, "iteration": state["iteration"] + 1} def evaluate_node(state: AgentState) -> dict: """评估检索结果是否足以回答问题""" if state["iteration"] >= 3: return {"sufficient": True} prompt = f"""基于以下检索到的文档，能否完整回答用户问题？ 问题: {state['question']} 文档: {state['retrieved_docs']} 如果信息充分回答"SUFFICIENT"，否则回答"INSUFFICIENT"并说明缺什么。""" response = llm.invoke(prompt) sufficient = "SUFFICIENT" in response return {"sufficient": sufficient} def answer_node(state: AgentState) -> dict: """基于所有检索文档生成最终回答""" prompt = f"问题: {state['question']}\n\n参考资料:\n{state['retrieved_docs']}" return {"answer": llm.invoke(prompt)} # 构建工作流 workflow = StateGraph(AgentState) workflow.add_node("retrieve", retrieve_node) workflow.add_node("evaluate", evaluate_node) workflow.add_node("answer", answer_node) workflow.set_entry_point("retrieve") workflow.add_edge("retrieve", "evaluate") workflow.add_conditional_edges( "evaluate", lambda state: "answer" if state["sufficient"] else "retrieve" ) workflow.add_edge("answer", END) agent = workflow.compile() 模式2：多路检索（Multi-Route Retrieval） def route_query(state: AgentState) -> str: """根据问题类型选择检索路径""" routing_prompt = f""" 分析以下问题，选择最合适的数据源： 问题: {state['question']} 选项: - "vector": 适合从内部文档库检索事实性信息 - "web": 适合需要最新信息的时效性问题 - "sql": 适合结构化数据查询 - "graph": 适合关系推理和多方关联 返回JSON: {{"route": "...", "reason": "..."}} """ decision = llm.invoke(routing_prompt) return json.loads(decision)["route"] 模式3：自我纠正检索（Self-Corrective RAG） def grade_documents(state: AgentState) -> dict: """对检索文档打分，过滤低质量结果""" graded_docs = [] for doc in state["retrieved_docs"]: score_prompt = f"""评估文档与问题的相关性(0-10): 问题: {state['question']} 文档: {doc.page_content[:500]} 只返回数字。""" score = int(llm.invoke(score_prompt).strip()) if score >= 6: graded_docs.append(doc) # 如果所有文档都不相关，触发查询改写 if not graded_docs: new_query = llm.invoke(f"改写这个查询以获得更好的检索结果: {state['question']}") return {"retrieved_docs": [], "question": new_query} return {"retrieved_docs": graded_docs} 工程实现：基于LangGraph的完整Agentic RAG from langgraph.graph import StateGraph, END from langgraph.prebuilt import ToolNode from langchain_core.tools import tool from langchain_openai import ChatOpenAI from langchain_core.messages import HumanMessage # 定义工具 @tool def vector_search(query: str) -> str: """从内部知识库检索相关文档""" docs = vector_store.similarity_search(query, k=5) return "\n\n".join([d.page_content for d in docs]) @tool def web_search(query: str) -> str: """从网络搜索最新信息""" results = search_api.search(query, num_results=5) return "\n\n".join([r["content"] for r in results]) @tool def sql_query(question: str) -> str: """查询业务数据库""" sql = text2sql(question) return db.execute(sql) # Agent决策循环 tools = [vector_search, web_search, sql_query] llm = ChatOpenAI(model="gpt-4o", temperature=0) llm_with_tools = llm.bind_tools(tools) def agent_decision(state): messages = state["messages"] response = llm_with_tools.invoke(messages) return {"messages": [response]} def should_continue(state): last_message = state["messages"][-1] if last_message.tool_calls: return "tools" return END # 构建Graph graph = StateGraph(dict) graph.add_node("agent", agent_decision) graph.add_node("tools", ToolNode(tools)) graph.set_entry_point("agent") graph.add_conditional_edges("agent", should_continue) graph.add_edge("tools", "agent") # 工具执行后回到agent做下一轮决策 app = graph.compile() # 执行 result = app.invoke({ "messages": [HumanMessage(content="对比2026年Q1三大云厂商的AI服务收入")] }) 性能基准对比 我们在三个数据集上对比了不同RAG架构的表现： ...

为什么需要多模态RAG？ 传统RAG只能处理文字，但现实世界的信息是多维的。技术文档里穿插架构图、产品手册里有演示截图、研究报告里有数据图表——这些信息，纯文本RAG完全丢失了。 用户问"系统的整体架构是什么样的？"，纯文本RAG只会返回一段文字描述，而无法返回架构图。这就是多模态RAG要解决的问题。 多模态RAG架构全景 ┌─────────────────────────────────────────────────────────┐ │ 多模态RAG系统架构 │ ├─────────────────────────────────────────────────────────┤ │ │ │ 用户查询 │ │ │ │ │ ▼ │ │ ┌─────────────┐ │ │ │ Query 分析 │ 判断用户需要图片、文字、还是图文 │ │ └──────┬──────┘ │ │ │ │ │ ┌────┴────┐ │ │ ▼ ▼ │ │ [纯文本查询] [需要图片查询] │ │ │ │ │ │ ▼ ▼ │ │ 文本检索 多模态检索 │ │ (向量库) (CLIP/图片向量) │ │ │ │ │ │ └────┬────┘ │ │ ▼ │ │ ┌─────────────┐ │ │ │ 结果融合 │ 图文结果融合排序 │ │ └──────┬──────┘ │ │ │ │ │ ▼ │ │ 多模态LLM生成回答（可理解和描述图片） │ │ │ └─────────────────────────────────────────────────────────┘ 四种架构方案详解 方案1：独立双路检索（Easiest） 文本向量库 图片向量库 │ │ └──► 合并 ◄──┘ │ ▼ 多模态LLM生成 最简单也是最常见的方案：文本和图片分别Embedding，分别检索，然后合并结果交给多模态LLM生成回答。 ...

Agent编排：从简单到复杂的演进之路 2026年，Agent编排模式已经从早期的"提示词+循环"发展为成熟的架构模式体系。本文将系统梳理从最简单到最复杂的编排模式，帮助你在实际项目中做出正确的架构选择。 模式全景 复杂度 ──────────────────────────────────────────→ 串行 ─→ 并行 ─→ 路由 ─→ 循环 ─→ 递归 ─→ 图式 ─→ 自治 │ │ │ │ │ │ │ │ │ │ │ │ │ └─ Agent自主决策 │ │ │ │ │ └─ DAG + 条件边 + 子图 │ │ │ │ └─ 分治递归 │ │ │ └─ ReAct循环 / 反思循环 │ │ └─ if-else路由 / 内容分发 │ └─ 扇出-扇入 / Map-Reduce └─ Pipeline直线流程 模式1：串行编排（Pipeline） 最基础的编排模式，Agent按固定顺序执行。 ...

Agent记忆系统：让智能体拥有"记住"的能力 人类的记忆系统是一个精妙的分层结构：工作记忆处理当前任务，长期记忆存储知识和经验，情景记忆记录具体事件。2026年的Agent系统也在向这个方向演进——一个没有记忆的Agent就像一个每天失忆的员工，每次对话都从零开始，无法积累经验、无法理解上下文。 记忆系统三层架构 ┌───────────────────────────────────────────────┐ │ 记忆系统架构 │ ├───────────────────────────────────────────────┤ │ │ │ ┌─────────────────────────────────────────┐ │ │ │ Layer 1: 短期记忆 (Working Memory) │ │ │ │ - 当前对话上下文 │ │ │ │ - 当前任务状态 │ │ │ │ - 最近的工具调用结果 │ │ │ │ 容量: ~32K tokens | TTL: 会话结束 │ │ │ └─────────────────────────────────────────┘ │ │ ↓ 溢出压缩 │ │ ┌─────────────────────────────────────────┐ │ │ │ Layer 2: 情景记忆 (Episodic Memory) │ │ │ │ - 具体事件记录（时间、地点、人物） │ │ │ │ - 对话历史摘要 │ │ │ │ - 任务执行日志 │ │ │ │ 容量: 无限 | TTL: 90天衰减 │ │ │ └─────────────────────────────────────────┘ │ │ ↓ 知识提取 │ │ ┌─────────────────────────────────────────┐ │ │ │ Layer 3: 长期记忆 (Long-term Memory) │ │ │ │ - 用户偏好和习惯 │ │ │ │ - 学到的知识和规则 │ │ │ │ - 经验教训 │ │ │ │ - 语义关联 │ │ │ │ 容量: 无限 | TTL: 永久 │ │ │ └─────────────────────────────────────────┘ │ │ │ └───────────────────────────────────────────────┘ Layer 1: 短期记忆（Working Memory） 短期记忆是Agent在当前会话中保持的上下文信息，主要通过LLM的上下文窗口实现。 ...

Transformer自2017年Google提出以来，已统治自然语言处理近十年。到2026年，Transformer架构经历了从标准注意力到稀疏注意力、从稠密模型到混合专家（MoE）、从固定上下文到无限上下文的深刻变革。本文将系统性梳理这些演进的技术内核。 1. 经典注意力机制的瓶颈 标准Self-Attention的计算复杂度为 $O(n^2 \cdot d)$，其中 $n$ 为序列长度，$d$ 为隐藏维度。当上下文窗口从2K扩展到1M时，计算和内存开销呈平方级增长。 # 标准注意力计算 def standard_attention(Q, K, V): # Q, K, V: [batch, heads, seq_len, d_k] scores = torch.matmul(Q, K.transpose(-2, -1)) / math.sqrt(d_k) attn_weights = F.softmax(scores, dim=-1) output = torch.matmul(attn_weights, V) return output 这一瓶颈催生了三条技术路线：近似注意力、稀疏注意力和线性注意力。 2. 注意力机制的进化路线 2.1 Flash Attention 3.0 Flash Attention系列通过分块计算（tiling）避免实例化完整的 $n \times n$ 注意力矩阵。2026年的Flash Attention 3.0在以下方面实现了突破： 版本 吞吐量 GPU利用率 支持上下文 FA 1.0 2x 40% 32K FA 2.0 3x 60% 128K FA 3.0 5x 85% 1M+ FA 3.0的核心创新是异步流水线：将HBM读写与Tensor Core计算重叠执行，利用Hopper架构的TMA（Tensor Memory Accelerator）硬件单元。 2.2 稀疏注意力 从Longformer的滑动窗口到BigBird的随机+全局模式，稀疏注意力的核心思想是：并非所有token都需要相互关注。 2026年的代表性方案是Block-Sparse Attention，其将注意力矩阵划分为固定大小的块，仅保留对角线附近和若干随机块： $$A_{sparse}(i,j) = \begin{cases} 1 & \text{if } |i-j| < w \text{ or } (i,j) \in \mathcal{S} \ 0 & \text{otherwise} \end{cases}$$ ...

引言 自2017年Vaswani等人提出Transformer架构以来，这一基于自注意力机制的模型已经彻底改变了自然语言处理乃至整个AI领域的格局。到了2026年，Transformer架构经历了多次重大演进：从最初的标准注意力，到Flash Attention的工程优化，再到线性注意力、混合专家（MoE）架构的广泛采用。本文将系统梳理这些技术演进的核心脉络。 标准注意力机制回顾 Transformer的核心是Scaled Dot-Product Attention： $$ \text{Attention}(Q, K, V) = \text{softmax}\left(\frac{QK^T}{\sqrt{d_k}}\right)V $$ 其中 $Q \in \mathbb{R}^{n \times d_k}$，$K \in \mathbb{R}^{n \times d_k}$，$V \in \mathbb{R}^{n \times d_v}$。多头注意力（Multi-Head Attention）通过并行运行多个注意力头来捕获不同子空间的信息： class MultiHeadAttention(nn.Module): def __init__(self, d_model, n_heads, d_head): super().__init__() self.n_heads = n_heads self.d_head = d_head self.q_proj = nn.Linear(d_model, n_heads * d_head) self.k_proj = nn.Linear(d_model, n_heads * d_head) self.v_proj = nn.Linear(d_model, n_heads * d_head) self.o_proj = nn.Linear(n_heads * d_head, d_model) def forward(self, x): B, T, C = x.shape q = self.q_proj(x).view(B, T, self.n_heads, self.d_head).transpose(1, 2) k = self.k_proj(x).view(B, T, self.n_heads, self.d_head).transpose(1, 2) v = self.v_proj(x).view(B, T, self.n_heads, self.d_head).transpose(1, 2) # Flash Attention v3 out = flash_attn_func(q, k, v, causal=True) return self.o_proj(out.transpose(1, 2).contiguous().view(B, T, -1)) 标准注意力的计算复杂度为 $O(n^2 d)$，空间复杂度同样为 $O(n^2)$，这成为处理长序列的核心瓶颈。 Flash Attention v3：IO感知的注意力计算 Flash Attention系列通过优化GPU内存层次结构中的IO操作，将注意力的内存访问从 $O(n^2)$ 降低到 $O(n)$。2025年发布的Flash Attention v3在FP8精度下实现了接近理论峰值的算力利用率： 版本 精度 算力利用率 关键创新 Flash Attention v1 FP16 ~50% Tiling + Recomputation Flash Attention v2 FP16/BF16 ~72% 减少非matmul FLOPs Flash Attention v3 FP8 ~75% 异步化 + FP8 GEMM Flash Attention v3的核心创新在于异步化（async）操作：将GEMM和softmax操作重叠执行，充分利用Tensor Core的并行能力。在H100 GPU上，FP8模式下可达1.2 PFLOPS的峰值算力。 ...

引言：Transformer 的统治与挑战 自 2017 年 Google 提出 Transformer 架构以来，它已经统治了自然语言处理乃至整个深度学习领域长达九年。然而到了 2026 年，随着模型规模扩展到万亿参数、上下文窗口增长到百万 Token，原始 Transformer 架构的局限性日益凸显：注意力机制的 $O(n^2)$ 复杂度、推理时 KV Cache 的巨大内存开销、以及训练算力墙的逼近，都在倒逼架构创新。 本文将系统梳理 2026 年 Transformer 架构的三大演进方向：注意力机制优化、混合专家架构（MoE）的成熟、以及以 Mamba 为代表的状态空间模型（SSM）的崛起。 一、注意力机制的进化谱系 1.1 标准 Self-Attention 回顾 标准多头自注意力机制的核心计算为： $$\text{Attention}(Q, K, V) = \text{softmax}\left(\frac{QK^T}{\sqrt{d_k}}\right)V$$ 其中 $Q \in \mathbb{R}^{n \times d_k}$, $K \in \mathbb{R}^{n \times d_k}$, $V \in \mathbb{R}^{n \times d_v}$。其计算复杂度为 $O(n^2 \cdot d)$，空间复杂度同样为 $O(n^2)$，这在长序列场景下成为瓶颈。 1.2 2026 年的注意力新范式 ┌─────────────────────────────────────────────────┐ │ 注意力机制演进谱系 (2026) │ ├─────────────────────────────────────────────────┤ │ │ │ Standard MHA ──► Multi-Query (MQA) │ │ │ │ │ │ │ ▼ │ │ │ Grouped-Query (GQA) │ │ │ │ │ │ │ ▼ │ │ ▼ Latent Attention │ │ Linear Attention │ │ │ │ │ │ ▼ ▼ │ │ Flash Attention 3 Ring Attention │ │ (GPU优化) (分布式) │ └─────────────────────────────────────────────────┘ Latent Attention（潜注意力） 是 2025-2026 年最重要的架构创新之一，由 DeepSeek V3 首先大规模验证。其核心思想是将 Key 和 Value 压缩到低秩潜在空间： ...