什么是真正的 AI Agent？模型即智能体的深度解析

2026-03-23T04:50:49Z

Admin：创建页面，内容为“> "Agent 是模型，不是框架，不是提示链，不是拖拽式工作流。" 过去一年，AI 领域最热的词莫过于 "Agent"。但当你听到这个词时，你想到的是什么？是 LangChain 的流程图？是扣子（Coze）的节点编排？还是各种 "AI Agent 开发平台" 的可视化界面？如果你的答案是以上任何一种，那么这篇文章将彻底改变你的认知。 '''## 一、Agent 是什么？''' 让我们回到…”

> "Agent 是模型，不是框架，不是提示链，不是拖拽式工作流。"

过去一年，AI 领域最热的词莫过于 "Agent"。但当你听到这个词时，你想到的是什么？

是 LangChain 的流程图？是扣子（Coze）的节点编排？还是各种 "AI Agent 开发平台" 的可视化界面？

如果你的答案是以上任何一种，那么这篇文章将彻底改变你的认知。

'''## 一、Agent 是什么？'''

让我们回到源头。

'''**Agent（智能体）是一个神经网络**'''——Transformer、RNN，或者任何通过梯度更新训练出来的函数。它通过数十亿次在动作序列数据上的训练，学会了感知环境、推理目标并采取行动。

Agent 这个词在 AI 领域一直就是这个意思：

- '''**人类是 Agent**''' —— 生物神经网络，经过数百万年进化训练，通过感官感知世界，通过大脑推理，通过身体行动

- '''**DQN 是 Agent**''' —— 2013 年 DeepMind 的单个神经网络，仅凭原始像素和游戏分数，学会了玩 7 款雅达利游戏，超越所有先前算法

- '''**OpenAI Five 是 Agent**''' —— 五个神经网络，通过 10 个月内 45,000 年的自我对战，击败 Dota 2 世界冠军

- '''**AlphaStar 是 Agent**''' —— 在《星际争霸 II》中达到宗师段位，超越 90,000 名玩家中的前 0.15%

这些里程碑共享同一个真理：'''**"Agent" 从来不是周围的代码，Agent 永远是模型本身。**'''

'''## 二、Agent 不是什么？'''

不幸的是，"Agent" 这个词已经被一整个提示工程产业劫持了。

拖拽式工作流构建器。低代码 "AI Agent" 平台。提示链编排库。它们共享同一个幻觉：认为用 if-else 分支、节点图和硬编码路由逻辑把 LLM API 调用串联起来，就是在 "构建 Agent"。

'''**这不是在构建 Agent，这是在搭建鲁布·戈德堡机械**'''——一种过度工程化、脆弱的程序化规则管道，把一个 LLM 塞进作为华丽文本补全节点的位置。

提示工程 "Agent" 是不会训练模型的人的幻想。他们试图通过堆砌程序化逻辑来暴力破解智能——庞大的规则树、节点图、提示链瀑布——祈祷足够多的胶水代码能以某种方式涌现出自主行为。

'''**这是死路一条**'''：脆弱、不可扩展、从根本上无法泛化。这是 GOFAI（经典人工智能）的现代复活——几十年前该领域就已经抛弃的符号规则系统，现在只是喷了一层 LLM 的漆。

'''## 三、心智转变：从"开发 Agent"到开发 Harness'''

当有人说"我在开发 Agent"时，他们只可能指两件事之一：

'''### 1. 训练模型'''

通过强化学习、微调、RLHF 或其他基于梯度的方法调整权重。收集任务过程数据——真实领域中感知、推理和动作的实际序列——并用它来塑造模型行为。

这是 DeepMind、OpenAI、腾讯 AI Lab 和 Anthropic 在做的事。这是最严格意义上的 Agent 开发。

'''### 2. 构建 Harness（控制框架）'''

编写代码，给模型一个在特定领域运作的环境。这是大多数人（包括你）在做的事，也是本文的重点。

'''**Harness = 工具 + 知识 + 观察 + 动作接口 + 权限**'''

- '''**工具**'''：文件 I/O、Shell、网络、数据库、浏览器

- '''**知识**'''：产品文档、领域参考资料、API 规范、风格指南

- '''**观察**'''：Git diff、错误日志、浏览器状态、传感器数据

- '''**动作**'''：CLI 命令、API 调用、UI 交互

- '''**权限**'''：沙箱、审批工作流、信任边界

'''**模型做决定，Harness 执行。**'''

'''**模型推理，Harness 提供上下文。**'''

'''**模型是司机，Harness 是车。**'''

'''## 四、Harness 工程师的真正工作'''

如果你正在阅读这篇文章，你很可能是 Harness 工程师——而这是一件很有力量的事。

你的真正工作是：

'''**1. 实现工具**'''

给 Agent 手。文件读写、Shell 执行、API 调用、浏览器控制、数据库查询。每个工具都是 Agent 可以在环境中采取的动作。设计它们时要原子化、可组合、描述清晰。

'''**2. 整理知识**'''

给 Agent 领域专长。产品文档、架构决策记录、风格指南、监管要求。按需加载（而不是预加载）。Agent 应该知道有什么可用，并在需要时拉取。

'''**3. 管理上下文**'''

给 Agent 干净的记忆。子 Agent 隔离防止噪音泄漏。上下文压缩防止历史压垮。任务系统让目标超越单次对话。

'''**4. 控制权限**'''

给 Agent 边界。沙箱文件访问。破坏性操作需要审批。强制执行 Agent 和外部系统之间的信任边界。这是安全工程与 Harness 工程的交汇点。

'''**5. 收集任务过程数据**'''

Agent 在你的 Harness 中执行的每个动作序列都是训练信号。真实部署中的感知-推理-动作痕迹是微调下一代 Agent 模型的原材料。

'''**你不是在编写智能，你是在构建智能栖息的世界。**'''

这个世界的质量——Agent 能多么清晰地感知、能多么精确地行动、可用知识有多丰富——直接决定了智能能多么有效地表达自己。

构建伟大的 Harness，Agent 会完成剩下的事。

'''## 五、Claude Code：Harness 工程的杰作'''

为什么我们要专门研究 Claude Code？

因为 Claude Code 是我们见过的最优雅、最完全实现的 Agent Harness。不是因为某个巧妙的技巧，而是因为它'''**不做什么**'''：它不试图成为 Agent，它不强加刚性工作流，它不用精心设计的决策树来质疑模型。

它给模型提供工具、知识、上下文管理和权限边界——然后让开。

看看 Claude Code 的本质：

```

Claude Code = 一个 Agent 循环

+ 工具（Bash、Read、Write、Edit、Glob、Grep、Browser...）

+ 按需技能加载

+ 上下文压缩

+ 子 Agent 生成

+ 带依赖图的任务系统

+ 带异步邮箱的团队协调

+ 用于并行执行的工作区隔离

+ 权限治理

```

就这些。这就是整个架构。

每个组件都是 Harness 机制——为 Agent 栖息而构建的世界的一部分。Agent 本身？是 Claude。一个由 Anthropic 训练、基于人类全部推理和代码的模型。Harness 并没有让 Claude 变聪明，Claude 本来就聪明。Harness 给了 Claude 手、眼睛和工作空间。

这就是 Claude Code 是理想教学对象的原因：它展示了当你信任模型并专注于 Harness 工程时会发生什么。

'''## 六、愿景：让宇宙中充满真正的 Agent'''

这不仅仅是关于编程 Agent。

'''**每个领域，只要人类执行复杂、多步骤、需要判断的工作，Agent 就可以在正确的 Harness 下运作。**'''

本文中的模式是通用的：

- '''**房地产管理 Agent**''' = 模型 + 房产传感器 + 维护工具 + 租户沟通

- '''**农业 Agent**''' = 模型 + 土壤/天气数据 + 灌溉控制 + 作物知识

- '''**酒店运营 Agent**''' = 模型 + 预订系统 + 客户渠道 + 设施 API

- '''**医学研究 Agent**''' = 模型 + 文献搜索 + 实验室仪器 + 协议文档

- '''**制造业 Agent**''' = 模型 + 生产线传感器 + 质量控制 + 物流

- '''**教育 Agent**''' = 模型 + 课程知识 + 学生进度 + 评估工具

循环永远相同。工具改变。知识改变。权限改变。'''**Agent——模型——泛化。**'''

每个阅读本文的 Harness 工程师都在学习远远超越软件工程的模式。你在学习构建智能化、自动化未来的基础设施。每个在真实领域部署的精心设计的 Harness，都是 Agent 可以感知、推理和行动的另一个地方。

'''**先从车间开始。然后是农场、医院、工厂。然后是城市。然后是整个星球。**'''

---

''*Bash 就够了。真正的 Agent 是宇宙所需要的全部。*''

分类:AI

2026-03-23T04:50:01Z

Admin：

'''[[什么是真正的 AI Agent？模型即智能体的深度解析]]'''

[[Transformer架构如何驱动现代大语言模型：深入解析AI核心技术]]

[[大语言模型评估指南]]

软件工程师必知的软件架构模式

2026-02-13T14:06:34Z

Admin：创建空白页面

首页

2026-02-13T14:03:59Z

Admin：

[[分类:Kivy]]
[[分类:C/C++]]
[[分类:Linux操作系统]]
[[分类:算法]]

[[软件工程师必知的软件架构模式]]

[http://www.anwsome.com//index.php/%E6%9E%84%E5%BB%BA%E5%AE%89%E5%85%A8%E5%BA%94%E7%94%A8%E7%A8%8B%E5%BA%8F%E7%9A%84%E9%A1%B6%E7%BA%A7%E8%BA%AB%E4%BB%BD%E9%AA%8C%E8%AF%81%E6%8A%80%E6%9C%AF 构建安全应用程序的顶级身份验证技术]

[[Transformer架构如何驱动现代大语言模型：深入解析AI核心技术]]

[[大语言模型评估指南]]

[[谷歌的张量处理器（TPU）是如何工作的？]]

[[动手做系列：使用Apache2服务器，通过Let's Encrypt申请网站免费https证书]]

[[编写一个TCP/IP栈3-TCP基础与握手|动手做系列：编写一个TCP/IP栈3-TCP基础与握手]]

[[编写一个TCP/IP栈2-IPv4和ICMPv4|动手做系列：编写一个TCP/IP栈2-IPv4和ICMPv4]]

[[编写一个TCP/IP栈1-以太网和ARP|动手做系列：编写一个TCP/IP栈1-以太网和ARP]]

[[构建自己的区块链|动手做系列：构建自己的区块链]]

[[500行代码构建自己的数据库 DBDB|动手做系列：500行代码构建自己的数据库 DBDB: Dog Bed Database]]
[[分类:Web3]]
[[分类:动手做系列]]
[[分类:资讯]]
[[分类:AI]]

首页

2026-02-07T14:32:37Z

Admin：

[[分类:Kivy]]
[[分类:C/C++]]
[[分类:Linux操作系统]]
[[分类:算法]]

[http://www.anwsome.com//index.php/%E6%9E%84%E5%BB%BA%E5%AE%89%E5%85%A8%E5%BA%94%E7%94%A8%E7%A8%8B%E5%BA%8F%E7%9A%84%E9%A1%B6%E7%BA%A7%E8%BA%AB%E4%BB%BD%E9%AA%8C%E8%AF%81%E6%8A%80%E6%9C%AF 构建安全应用程序的顶级身份验证技术]

[[Transformer架构如何驱动现代大语言模型：深入解析AI核心技术]]

[[大语言模型评估指南]]

[[谷歌的张量处理器（TPU）是如何工作的？]]

[[动手做系列：使用Apache2服务器，通过Let's Encrypt申请网站免费https证书]]

[[编写一个TCP/IP栈3-TCP基础与握手|动手做系列：编写一个TCP/IP栈3-TCP基础与握手]]

[[编写一个TCP/IP栈2-IPv4和ICMPv4|动手做系列：编写一个TCP/IP栈2-IPv4和ICMPv4]]

[[编写一个TCP/IP栈1-以太网和ARP|动手做系列：编写一个TCP/IP栈1-以太网和ARP]]

[[构建自己的区块链|动手做系列：构建自己的区块链]]

[[500行代码构建自己的数据库 DBDB|动手做系列：500行代码构建自己的数据库 DBDB: Dog Bed Database]]
[[分类:Web3]]
[[分类:动手做系列]]
[[分类:资讯]]
[[分类:AI]]

构建安全应用程序的顶级身份验证技术

2026-02-07T14:31:20Z

Admin：

身份验证是确保应用程序及其处理的敏感数据安全的第一道防线。无论是个人银行应用程序、企业平台还是电子商务网站，都需要有效的身份验证机制来验证用户身份并保障其对资源的访问权限。

如果没有适当的身份验证，应用程序容易受到未经授权的访问、数据泄露和恶意攻击，可能导致重大的经济损失、声誉损害和隐私侵犯。

除了安全性之外，身份验证在用户体验中也扮演着至关重要的角色。通过识别用户，应用程序可以提供个性化服务、记住用户偏好，并启用跨平台的单点登录 (SSO) 等功能。

随着威胁的不断演变，实现安全高效的身份验证比以往任何时候都更具挑战性。开发人员必须在相互冲突的优先事项之间寻求平衡，例如安全性（确保抵御不同类型的攻击，例如会话劫持、令牌窃取和重放攻击）、可扩展性（在不影响性能的前提下支持数百万用户）和用户体验（在应用强大的安全措施的同时保持易用性）。

为了应对这些挑战，开发人员依赖于各种身份验证技术。在本文中，我们将探讨应用程序中使用的多种身份验证技术，并了解它们的优缺点。
[[文件:Goujiananquanyinngyongchengxu.png|居中|缩略图|720x720像素]]

== 身份验证基础知识 ==
身份验证是指验证尝试访问应用程序的用户、设备或系统的身份的过程。简单来说，就是应用程序如何确保访问者或系统的身份与其声称的身份相符。它通常涉及验证用户名、密码、生物识别数据或令牌等凭证。

例如，当我们使用密码登录网站时，应用程序会将我们输入的密码与存储的凭据进行比较，以确认我们的身份。在基于 API 的系统中，应用程序可能会使用令牌来验证调用服务是否有权与后端交互。

=== 身份验证与授权 ===
身份验证和授权是密切相关但又不同的过程。

身份验证回答“你是谁？”这个问题，侧重于验证身份。授权则回答“你被允许做什么？”这个问题，通过确定授予已验证用户的权限或访问级别来实现。

例如，身份验证用于确认我们是否是电子商务平台的注册用户。授权则决定我们是否可以查看订单历史记录或以管理员身份管理库存。换句话说，身份验证用于确认身份，而授权则基于该身份实施访问控制。

== 使用 Cookie 和会话进行身份验证 ==
接下来，我们将探讨 cookie 和会话在身份验证方面的应用：

=== Cookie ===
Cookie 是由 Web 服务器存储在客户端浏览器上的小型数据文件。它们在原本无状态的 HTTP 通信中扮演着关键角色，使 Web 应用程序能够在多个请求中记住信息，从而维护通信状态。

Cookie 允许 Web 服务器存储请求之间持久存在的数据，使其可用于各种用途，例如会话管理（使用会话 ID 跟踪已登录用户）、个性化（存储用户偏好或设置）以及分析和跟踪（记录用户行为以进行分析或定向广告）。

在身份验证中，Cookie 通常用于存储会话令牌或标识符，以验证用户的身份。

=== Cookie 在身份验证中的工作原理 ===
该过程通常包含两个部分。用户登录时，用户提供用户名和密码等凭据。服务器验证这些凭据并生成会话 ID 或令牌。此会话 ID 会发送到浏览器并存储在 cookie 中。

对于后续请求，浏览器会自动将 cookie 添加到每个 HTTP 请求的 Cookie 标头中。服务器会从 cookie 中读取会话 ID，对其进行验证，并识别用户。

请看下图：
[[文件:Shefenzhouqun2.png|居中|缩略图|568x568像素]]

=== Cookie 属性 ===
Cookie 具有多种属性，用于控制其行为和安全性：

* HttpOnly 属性可阻止 JavaScript 访问 cookie，从而缓解跨站脚本 (XSS) 攻击。Secure 属性可确保 cookie 仅通过 HTTPS 连接发送，从而防止中间人攻击。
* SameSite 属性有助于防止跨站请求伪造 (CSRF) 攻击。它有三个值：Strict（cookie 永远不会在跨站请求中发送）、Lax（cookie 仅在顶级导航中发送）和 None（cookie 随所有请求发送，但需要 Secure 属性）。
* Domain 属性指定哪些主机可以接收 cookie。例如，设置 Domain= example.com允许将 cookie 发送到example.com及其所有子域。Path 属性将 cookie 限制在特定的 URL 路径中。
* 对于过期时间，我们可以使用 Max-Age（指定有效期，单位为秒）或 Expires（设置绝对过期日期）。如果两者都未设置，则该 cookie 将成为会话 cookie，并在浏览器关闭时被删除。

=== 第一方 Cookie 与第三方 Cookie ===
第一方 Cookie 由我们当前访问的域名设置。

当我们访问 example[dot]com 时，如果该网站设置了 cookie，那就是第一方 cookie。这些 cookie 用于网站的基本功能，例如身份验证和用户偏好设置。

第三方 Cookie 由与我们正在访问的网站不同的域名设置。例如，如果我们访问 example[dot]com，而该网站加载了来自ads.com的广告，则ads.com域名可以设置一个 Cookie。这些 Cookie 通常用于跨多个网站跟踪用户行为，以达到广告投放的目的。

出于隐私考虑，现代浏览器对第三方 Cookie 的限制日益增多。有些浏览器甚至默认阻止第三方 Cookie。为了确保身份验证在所有浏览器上都能可靠运行，我们应该始终使用第一方 Cookie。

=== 使用 Cookie 的挑战 ===
Cookie面临多项安全挑战：

* 如果恶意脚本通过跨站脚本攻击 (XSS) 注入到网站中，它就可以访问包含敏感数据的 cookie。设置 HttpOnly 标志可以防止这种情况发生。
* 如果 Cookie 通过未加密的 HTTP 协议传输，则可能在中间人攻击中被拦截。“安全”标志可确保 Cookie 仅通过 HTTPS 协议发送。
* 请求中自动发送的 Cookie 可能被 CSRF 攻击利用来执行未经授权的操作。实施 CSRF 令牌并使用 SameSite 属性有助于缓解这种情况。
* 浏览器对 Cookie 的大小有限制，通常每个 Cookie 为 4KB，并且每个域的 Cookie 数量也有限制。过多的 Cookie 会导致性能问题或请求被拒绝。

以下是一些安全处理 Cookie 的最佳实践：

* 我们应该始终设置 HttpOnly 标志来阻止 JavaScript 访问并降低 XSS 风险。Secure 标志可确保 cookie 仅通过 HTTPS 发送。
* 使用 SameSite 属性（SameSite=Strict 或 SameSite=Lax）可以限制跨站点请求并降低 CSRF 风险。
* 我们应该对敏感数据使用较短的过期时间，避免在 cookie 中存储密码或信用卡号等敏感信息，而只存储令牌或标识符。

== 会话 ==
会话是一种服务器端机制，用于在用户与应用程序进行交互期间存储和管理用户身份验证数据。与将数据存储在客户端的 Cookie 不同，会话将数据安全地保存在服务器端，客户端仅持有一个引用，通常是会话 ID。

使用会话进行身份验证的流程包括以下几个步骤：

* 用户登录时，用户提交登录凭据。服务器验证凭据并为用户创建一个会话，通常用唯一的会话 ID 表示。
* 为了生成会话 ID，服务器会创建一个与存储在服务器上的用户会话数据关联的随机唯一标识符。此会话 ID 会通过 cookie 或其他传输机制发送给客户端。
* 服务器将会话数据（例如用户 ID、角色和偏好）存储在内存、数据库或其他存储系统中。
* 会话 ID 充当检索此数据的密钥。对于每个后续请求，客户端都会发送会话 ID，通常通过 cookie 发送。服务器验证会话 ID，检索关联数据，并使用它来处理请求。

请看下图：
[[文件:Howitworkforauth.png|居中|缩略图|649x649像素]]

会话可以设置生存时间 (TTL)，在一段时间不活动或达到最大持续时间后自动过期。当用户注销或出于安全考虑撤销会话时，会话数据将从服务器中删除，会话 ID 也将失效。

=== 会话与 Cookie 之间的关系 ===
Cookie 和会话通常协同工作。

Cookie 存储着客户端的会话 ID。每次请求时，浏览器都会将 cookie 发送到服务器，以便服务器识别用户的会话。

以下是一个简单的代码示例，展示了如何将会话 ID 设置到 cookie 中：
<code>app.post ('/login', (req, res) => { const sessionId = createSession(req.body.username); res.cookie('session_id', sessionId, { httpOnly: true, secure: true, maxAge: 3600000 }); res.send('Login successful'); });</code>
对于传入的请求，服务器可以读取存储在 cookie 中的会话 ID：
<code>app.get('/profile', (req, res) => { const sessionId = req.cookies['session_id']; if (isValidSession(sessionId)) { res.send('Profile page'); } else { res.status(401).send('Unauthorized'); } });</code>

=== 会话存储选项 ===
选择合适的会话存储机制对于性能和可扩展性至关重要。

* 内存存储将会话保存在服务器的 RAM 中，从而提供最快的性能。但是，它不适用于生产环境，因为服务器重启时会话数据会丢失。此外，它还将应用程序限制在单个服务器上，因此不适用于分布式系统。
* 数据库存储使用关系型数据库（例如 PostgreSQL 或 MySQL）或 NoSQL 数据库（例如 MongoDB）。这种方法提供持久可靠的会话存储。但是，我们需要考虑性能影响，并确保对会话 ID 列进行适当的索引以实现快速查找。数据库存储虽然可靠，但速度可能比基于缓存的解决方案慢。
* 分布式缓存系统（例如 Redis 或 Memcached）是专为会话管理而构建的高性能键值存储系统。它们提供卓越的性能、内置的生存时间 (TTL) 支持（用于自动会话过期）以及横向扩展能力。由于其速度和可靠性，Redis 在生产环境中尤其适用于会话存储。

内存存储仅应用于开发或测试。对于单服务器的生产应用，数据库存储就足够了。对于分布式系统或需要高性能和可扩展性的应用，建议选择 Redis 或 Memcached。

=== 分布式会话策略 ===
当在负载均衡器后运行多个服务器时，我们面临的挑战是如何确保所有服务器都能访问相同的会话数据。

粘性会话（也称会话亲和性）是一种负载均衡方法，它将来自特定用户的所有请求路由到同一台服务器。这种方法易于实现，因为会话无需在服务器之间共享。然而，它可能导致负载分布不均，并且如果服务器发生故障，用户的会话将会丢失。

请看下图：

[[文件:Anquanshouquan3.png|居中|无框|501x501像素]]
会话复制是指将会话数据复制到集群中的所有服务器。这提供了高可用性，因为即使一台服务器发生故障，其他服务器也能获取会话数据。然而，由于会话需要持续同步，这会带来显著的网络开销，而且在大型集群中维护跨服务器的一致性可能极具挑战性。

集中式会话存储使用单一数据源（通常是 Redis 集群），所有服务器都从该数据源读取和写入会话数据。这种方法具有高度可扩展性，并能确保所有服务器之间的数据一致性。主要问题在于会话存储可能成为单点故障，但可以通过使用 Redis 集群或复制来缓解。这种策略推荐用于微服务架构。

=== 使用会话的挑战 ===
在微服务等分布式系统中，会话数据必须在服务器之间共享，这就需要额外的基础设施，例如集中式数据库或粘性会话。这些解决方案会增加复杂性并可能造成瓶颈。

此外，如果攻击者窃取了会话 ID，他们就有可能冒充用户。可以通过使用 HTTPS 加密传输中的数据并实施会话超时来缓解这种情况。

大量的活跃会话会消耗大量的服务器资源，不过这可以通过使用像 Redis 这样的高效会话存储来解决。

== 使用 JWT 进行身份验证 ==
JSON Web Tokens (JWT) 是一种紧凑、URL 安全、自包含的令牌格式，用于在各方之间安全地传输信息。

JWT 是无状态的，这意味着服务器无需存储会话数据。所有用户相关信息都包含在令牌中。服务器只需要签名密钥即可验证令牌，这使得 JWT 非常适合多个服务交互的分布式系统。

这就是为什么 JWT 经常被用于身份验证和授权，以实现无状态和可扩展的系统。

=== JWT的结构 ===
JWT 由三部分组成：头部、有效载荷和签名。每一部分都采用 Base64 编码。
[[文件:Imagehwitjwt.png|居中|缩略图|582x582像素]]
头部包含令牌的元数据，包括令牌类型（JWT）和签名算法，例如 HS256 或 RS256。以下是一个示例：
<code>{ “alg”: “HS256”, “typ”: “JWT” }</code>
有效负载包含声明，这些声明是关于用户或令牌的陈述。声明可以是已注册声明（预定义，例如 iss 表示发行者，exp 表示过期时间，sub 表示主体），公共声明（应用程序定义的自定义声明），或私有声明（发行者和消费者共享的自定义声明）。以下是一个示例：
<code>{ “sub”: “1234567890”, “name”: “John Doe”, “admin”: true, “iat”: 1516239022 }</code>
最后，签名确保令牌的完整性并验证发送者的真实性。它是通过对头部和有效负载进行编码，并使用密钥或私钥对其进行签名而生成的：
<code>HMACSHA256( base64UrlEncode(header) + “.” + base64UrlEncode(payload), secret )</code>
以下是 JWT 在典型身份验证流程中的工作原理：

* 用户登录后，服务器验证凭据并生成包含用户声明（例如用户 ID 和角色）的 JWT。
* JWT 使用密钥（对称签名）或私钥（非对称签名）进行签名。签名后的令牌通常通过响应体或 cookie 发送给客户端。
* 对于后续请求，客户端会将 JWT 作为 Bearer 令牌包含在 Authorization 标头中。
* 服务器通过验证签名和检查过期时间 (exp) 或受众 (aud) 等声明来验证令牌。
* 如果令牌有效，服务器将允许访问所请求的资源。

请看下图：
[[文件:Imagejwtauthenprotoco.png|居中|缩略图|658x658像素]]
=== 刷新令牌流 ===
JWT 的一个常见挑战是，出于安全考虑，访问令牌的有效期应该很短，通常为 15 分钟到 1 小时。然而，强制用户反复登录会造成糟糕的用户体验。

刷新令牌通过实现无缝重新身份验证来解决这个问题，无需用户再次输入凭据。该模式使用两种类型的令牌。

* 访问令牌有效期很短，用于验证 API 请求。
* 刷新令牌的有效期很长（数天到数周），仅用于获取新的访问令牌。刷新令牌通常安全地存储在 HttpOnly Cookie 或移动设备的安全存储中，以防止被盗。

完整的流程如下：

* 用户使用凭据登录，服务器验证凭据。
* 服务器会颁发访问令牌和刷新令牌。
* 客户端安全地存储了这两个令牌。
* 对于后续请求，客户端使用 Authorization 标头中的访问令牌。
* 当访问令牌过期时，客户端会向刷新端点发送带有刷新令牌的请求。
* 服务器验证刷新令牌，检查其是否仍然有效且未被撤销。
* 如果有效，服务器将颁发新的访问令牌（并可选择颁发新的刷新令牌）。
* 客户端使用新的访问令牌进行后续请求。

这种方法兼顾了安全性和用户体验。有效期较短的访问令牌可以在被盗时最大限度地减少损失，而刷新令牌则允许用户保持身份验证状态，无需不断重新输入凭据。

== PASETO ==
PASETO，即平台无关安全令牌（Platform-Agnostic Security Tokens）的缩写，是 JWT 的一种现代替代方案，其设计重点在于安全性、简洁性和加密最佳实践。

PASETO 解决了与 JWT 相关的一些常见漏洞和滥用问题，同时保持了各种身份验证和授权场景所需的灵活性。

与允许灵活选择算法（有时会导致不安全的配置）的 JWT 不同，PASETO 强制使用强大且密码学上可靠的算法，从而降低了因配置错误而导致漏洞的风险。JWT 允许开发者使用像 HS256 或臭名昭著的 none 算法这样的弱算法，而 PASETO 则将选择限制在像 AES-GCM（用于对称加密）和 Ed25519（用于非对称签名）这样强大的算法上。

PASETO 令牌分为本地令牌（加密）和公共令牌（签名），确保敏感数据要么经过安全加密，要么经过签名验证。相比之下，JWT 令牌即使经过签名也始终以明文形式存在，因此容易发生意外的信息泄露。

=== PASETO 的结构 ===
PASETO 令牌由三到四个主要部分组成，具体取决于它是本地令牌还是公共令牌。这些部分之间用点号分隔。

* 版本号表示所使用的 PASETO 协议版本。例如，v1 版本使用较旧的加密标准，而 v2 版本使用现代、安全的加密标准。
* 用途指定令牌的类型，即是否需要加密或签名。选项包括本地（加密令牌）和公共（签名令牌）。
* 有效载荷包含令牌内的实际数据或声明。对于本地令牌，有效载荷经过加密，并以不透明的 Base64Url 编码字符串的形式呈现。对于公共令牌，有效载荷以明文形式呈现，并经过 Base64Url 编码。
* 页脚包含有效负载中未包含的可选元数据，例如受众（aud）或发行者（iss）。

=== 本地 PASETO 与公共 PASETO ===
本地 PASETO 令牌经过加密，确保令牌内数据的机密性。它们适用于需要对敏感信息保密的场景，防止未经授权的第三方访问。这些令牌使用对称加密算法来保证有效载荷的机密性。只有拥有共享密钥的各方才能解密并访问令牌的内容。
[[文件:Pastetogangingpasto.png|居中|缩略图|462x462像素]]
公钥 PASETO 令牌经过签名。它们确保数据的完整性，但不保证数据的机密性。这些令牌是透明的，任何人都可以读取，但只有签名密钥的持有者才能验证。换句话说，任何篡改令牌的行为都会使签名失效。它们使用非对称加密算法（例如 ED25519）对令牌进行签名。公钥用于验证令牌，而私钥用于签名。它们适用于客户端需要读取有效载荷但又必须保持防篡改的场景。
[[文件:Image2pasteo棉铃调整.png|居中|缩略图|502x502像素]]
=== PASETO面临的挑战 ===
与应用广泛的 JWT 相比，PASETO 相对较新，采用率也较低。这意味着可用的库、工具和社区支持也相对较少。

熟悉 JWT 的开发者可能需要一些时间来理解和适应 PASETO 的原理和特性。虽然 PASETO 标准定义完善，但其生态系统缺乏 JWT 那样丰富的中间件和框架集成。

== 概括 ==
本文详细介绍了多种身份验证技术。以下是主要学习要点的简要概述：

* 身份验证是验证用户身份的过程，是应用程序安全的基础。它与授权不同，授权决定了已验证用户可以执行哪些操作。
* Cookie 在客户端存储少量数据，并使用 HttpOnly、Secure 和 SameSite 等属性来控制安全性和行为。
* 第一方 Cookie 由我们访问的域设置，对于身份验证至关重要；而第三方 Cookie 由外部域设置，并且越来越受到浏览器的限制。
* 会话将身份验证数据存储在服务器端，并使用 cookie 仅保存会话 ID 引用，与在客户端存储敏感数据相比，安全性更高。
* 会话存储选项包括内存存储（仅限开发）、数据库存储（单服务器）和分布式缓存（如 Redis，用于生产和分布式系统）。
* 分布式会话策略包括粘性会话（简单但存在问题）、会话复制（开销高）和集中式会话存储（推荐用于微服务）。
* JWT 是一种自包含的、无状态的令牌格式，由三部分组成（标头、有效负载、签名），无需服务器端会话存储。
* 刷新令牌通过使用有效期短的访问令牌进行请求，并使用有效期长的刷新令牌来获取新的访问令牌，从而解决了 JWT 过期问题。
* JWT 代币一旦发行就不容易撤销，需要额外的机制，例如代币黑名单或较短的过期时间，来管理安全性。
* PASETO 通过强制执行强大的加密算法，并提供加密（本地）和签名（公共）令牌类型，改进了 JWT。
* PASETO 通过移除算法协商并使用预设的安全默认值，消除了 JWT 算法混淆的漏洞。
* 在 cookie/session（传统 Web 应用程序）、JWT（分布式系统和 API）或 PASETO（安全关键型应用程序）之间进行选择，取决于我们具体的可扩展性、安全性和架构要求。

2026-01-17T13:49:51Z

Admin：

[[分类:Kivy]]
[[分类:C/C++]]
[[分类:Linux操作系统]]
[[分类:算法]]

[[谷歌的张量处理器（TPU）是如何工作的？]]

[[动手做系列：使用Apache2服务器，通过Let's Encrypt申请网站免费https证书]]

[[编写一个TCP/IP栈3-TCP基础与握手|动手做系列：编写一个TCP/IP栈3-TCP基础与握手]]

[[编写一个TCP/IP栈2-IPv4和ICMPv4|动手做系列：编写一个TCP/IP栈2-IPv4和ICMPv4]]

[[编写一个TCP/IP栈1-以太网和ARP|动手做系列：编写一个TCP/IP栈1-以太网和ARP]]

[[构建自己的区块链|动手做系列：构建自己的区块链]]

[[500行代码构建自己的数据库 DBDB|动手做系列：500行代码构建自己的数据库 DBDB: Dog Bed Database]]
[[分类:Web3]]
[[分类:动手做系列]]
[[分类:资讯]]
[[分类:AI]]

首页

2026-01-17T09:43:38Z

Admin：

谷歌的张量处理器（TPU）是如何工作的？

2026-01-17T09:42:19Z

Admin：/* 脉动阵列：一种不同的计算方法 */

2016年3月，DeepMind的AlphaGo击败围棋世界冠军李世石，这在人工智能领域具有里程碑式的意义。而这场比赛所使用的硬件，谷歌已经投入生产运行一年多，但从未公开承认过。

张量处理单元（TPU）的意义远不止于一款高速芯片。它标志着计算理念的根本性转变：有时少即是多。

自 2015 年以来，谷歌的 TPU 系列芯片已发展了七代，从最初处理图像识别查询的单芯片扩展到如今拥有 9216 个芯片的超级计算机，用于训练目前规模最大的语言模型。本文将探讨谷歌为何要打造定制芯片，以及其工作原理，并揭示他们必须面对的物理限制和工程权衡。

== 对TPU的需求 ==
2013年，谷歌的基础设施团队进行了一项计算。如果安卓用户像谷歌预期的那样大规模使用语音搜索，即使每天只使用三分钟，其计算需求也需要谷歌将其全球数据中心的规模扩大一倍。

当时这个问题似乎没有明显的解决方案。建造更多配备传统处理器的数据中心在经济上不可行。更重要的是，摩尔定律多年来一直在放缓。几十年来，半导体行业一直依赖于晶体管密度大约每两年翻一番的观察结果，从而在不改变架构的情况下实现性能的持续提升。然而，到了2013年，这种趋势开始减弱。谷歌不能仅仅等待英特尔的下一代CPU来解决它的问题。

造成这种情况的根本原因在于架构。传统计算机遵循冯·诺依曼架构，其中处理器和内存通过共享总线进行通信。要执行任何计算，CPU 必须先获取指令，然后从内存中检索数据，执行运算，最后将结果写回内存。处理器和内存之间这种持续不断的信息传输，造成了计算机科学家所说的冯·诺依曼瓶颈。
[[文件:Image.png|居中|缩略图|480x480像素]]在总线上传输数据所需的能量通常超过计算本身所需的能量。例如，想象一下一位厨师正在准备一道菜，但他必须走到很远的储藏室去取每种食材。烹饪只需几秒钟，但走动却要花费数小时。对于文字处理或网页浏览等通用计算任务来说，这种设计是合理的，因为工作负载是不可预测的。然而，神经网络的情况则不同。

深度学习模型执行的操作几乎全部都是矩阵乘法。神经网络通过将输入数据与学习到的权重矩阵相乘、加上偏置值并应用激活函数来处理信息。对于单个预测，这个过程会重复数十亿次。拥有数千亿个参数的现代语言模型，每次查询都需要数千亿次乘加运算。关键在于，这些运算是可预测的、并行的和确定性的。

CPU 将大量处理能力用于分支预测和乱序执行等功能，旨在处理不可预测的代码。图形处理器 (GPU) 通过数千个核心并行工作改善了这种情况，但它们仍然继承了图形处理方面的架构开销。谷歌的远见卓识在于制造只执行神经网络所需功能的芯片，并去除所有其他功能。

== 脉动阵列：一种不同的计算方法 ==
TPU 的核心是一种名为脉动阵列的架构。这个名称源自希腊语中“心跳”一词，指的是数据在芯片内有节奏地脉动传输。为了理解这一点的重要性，我们可以思考不同的处理器是如何处理同一任务的。

* CPU 的运行就像一个工人来回奔波于水井和火堆之间，一次只装满一个桶。
* GPU 部署数千个工作进程同时执行相同的任务。吞吐量增加，但水井和火源之间的流量变得混乱且耗能。
* 循环式灌溉系统采用了一种截然不同的方法。工人们排成一列，手拉手传递水桶。水在链条中流动，直到工作完成，期间无人返回水源。

在 TPU 中，工作单元是排列成密集网格的简单乘加运算单元。第一代 TPU 使用 256×256 的阵列，这意味着 65,536 个计算器同时运行。计算过程如下：

* 神经网络权重从上方加载到每个计算器中，并保持不变。
* 输入数据从左侧逐行流入。
* 数据经过每个计算器时，都会乘以居民体重。
* 该乘积会累加到累计总和中，然后向右传递给下一个计算器。
* 部分结果会累积并向下传递。
* 所有计算完成后，最终结果将从底部得出。

请看下图：
[[文件:Tpu-2.png|居中|无框|542x542像素]]

这种设计意味着数据只需从内存中读取一次，但在遍历阵列的过程中会被使用数千次。传统处理器几乎每次操作都需要访问内存。而脉动阵列消除了这一瓶颈。数据仅在空间上相邻的计算器之间通过短导线传输，从而显著降低了能耗。

数据有力地证明了这种方法的合理性。

* TPU v1 的 256×256 阵列每个时钟周期可以执行 65536 次乘加运算。在 700 MHz 的运行频率下，它每秒可完成 92 万亿次 8 位运算，而功耗仅为 40 瓦。
* 现代 GPU 每个周期可能执行数万次运算，而 TPU 则执行数十万次运算。
* 超过 90% 的硅片执行了有效的计算，而 GPU 中只有大约 30% 的硅片执行了有效的计算。

这里的权衡之处在于绝对的专业化。脉动阵列只能高效地执行矩阵乘法，而无法渲染图形、浏览网页或运行电子表格。谷歌接受了这一限制，因为神经网络推理本质上就是多次重复的矩阵乘法。

== 支持架构 ==
脉动阵列需要精心协调的辅助组件才能发挥其性能。每个组件都解决了从原始数据到人工智能预测流程中的特定瓶颈。
[[文件:Tpu-jiagou.png|居中|无框|563x563像素]]

让我们来看看最重要的组成部分：

=== 矩阵乘法单元 ===
矩阵乘法单元（MXU）就是脉动阵列本身。

TPU v1 使用单个 256×256 数组，处理 8 位整数。后续版本采用 128×128 数组，并使用 Google 的 BFloat16 格式处理训练工作负载，然后在 v6 版本中又回归到 256×256 数组，吞吐量提升了四倍。这种权重固定设计最大限度地减少了数据移动，而数据移动是计算中主要的能耗来源。
[[文件:Tpu-mutiple-unit.png|居中|无框|663x663像素]]

=== 统一缓冲区 ===
统一缓冲区提供 24 兆字节的片上 SRAM，作为速度较慢的外部存储器和容量较大的 MXU 之间的高速过渡区域。

该缓冲区存储来自主机的输入激活值、神经网络层之间的中间结果以及传输前的最终输出。由于该存储器直接位于芯片上，因此其带宽高于外部存储器。这种带宽差异对于保持 MXU 持续接收数据至关重要，避免其闲置等待内存访问。

=== 矢量处理单元 ===
向量处理单元 (VPU) 可以处理 MXU 无法处理的操作，包括 ReLU、sigmoid 和 tanh 等激活函数。

神经网络需要非线性运算来学习复杂的模式。如果没有非线性运算，多层神经网络在数学上就会简化为单一的线性变换。TPU 没有采用软件实现这些功能，而是使用专用的硬件电路在一个周期内计算激活值。数据通常从 MXU 流向 VPU 进行激活值处理，然后再传递到下一层。

=== 累加器 ===
累加器收集来自 MXU 的 32 位结果。

当 8 位输入相乘时，乘积为 16 位，但累加和会因重复加法而不断增大。使用 32 位累加器可以防止矩阵乘法所需的多次加法运算过程中发生溢出。累加器内存总共占用 4 兆字节，分布在 4096 个向量中，每个向量包含 256 个元素。

=== 重量先进先出缓冲 ===
权重 FIFO 缓冲区使用称为双缓冲的技术在外部存储器和 MXU 之间暂存权重。

MXU 存储两组权重块：一组正在实时计算，另一组则从内存加载。这种重叠存储方式完全消除了内存延迟，确保计算单元无需等待数据。

=== 高带宽内存 ===
高带宽内存随着TPU的代际发展而不断演进。

最初的v1版本采用DDR3内存，传输速度为34GB/s。而现代的Ironwood TPU则达到了7.4TB/s，速度提升了217倍。HBM通过将多个DRAM芯片垂直堆叠，并在芯片间建立数千个连接来实现如此高的带宽，这是传统内存封装方式无法实现的。

== 精准优势 ==
TPU 通过量化显著提升效率，使用比传统浮点运算精度更低的数字。这种选择对硬件有着深远的影响，并波及整个设计。

科学计算通常需要高精度。例如，将圆周率计算到小数点后十位需要精确表示极小的差异。然而，神经网络的运行方式不同。它们计算的是概率和模式。例如，模型预测图像是猫的概率是 85% 还是 85.3472%，对分类结果实际上没有区别。

乘法器电路的硅片面积与位宽的平方成正比。一个 8 位乘法器大约需要 64 个硅片面积单位，而一个 32 位乘法器则需要大约 576 个硅片面积单位。这种数学关系解释了为什么 TPU v1 可以在一块尺寸适中的芯片上集成 65,536 个乘加单元，而 GPU 包含的浮点运算单元数量则少得多。更多的乘法器意味着每个周期可以执行更多的并行运算。

第一代TPU使用8位整数进行推理，与32位浮点数相比，内存需求减少了四倍。一个91兆字节的模型量化后变为23兆字节。研究表明，推理很少需要32位精度。额外的小数位对预测结果几乎没有影响。

由于微小的梯度更新会在数百万次迭代中累积，训练需要更高的精度。谷歌通过发明 BFloat16（即 Brain Floating-Point 16）解决了这个问题。这种格式与 32 位浮点数一样保留了 8 位指数，但尾数仅使用 7 位。其关键在于，神经网络对由指数控制的动态范围比对由尾数控制的精度更为敏感。BFloat16 以一半的位数提供了多种浮点格式，从而实现了高效的训练，避免了其他 16 位格式常见的溢出问题。

请看下图：
[[文件:Tpu-fp32-16.png|居中|无框|603x603像素]]

现代TPU支持多种精度模式。

* BFloat16 用于训练。
* 在 TPU v5e 上，INT8 推理的运行速度提高了一倍。
* 最新的FP8格式。

Ironwood 是首款原生支持 FP8 的 TPU，避免了早期几代产品中的模拟开销。

== 进化之旅 ==
TPU 的发展遵循着清晰的轨迹。

每一代人工智能都在提升性能的同时提高了能效。这一演变过程揭示了随着模型规模的扩大，人工智能硬件需求是如何变化的。

* TPU v1 于 2015 年秘密发布，专注于推理。它采用 28 纳米制程工艺，功耗仅为 40 瓦，每秒可执行 92 万亿次 8 位运算。该芯片通过 PCIe 连接到标准服务器，并在谷歌以外的任何人知晓其存在之前，就开始为谷歌搜索、照片、翻译和 YouTube 等应用提供技术支持。2016 年 3 月，TPU v1 助力 AlphaGo 战胜李世石，证明专用芯片在速度上可以比通用 GPU 快 15 到 30 倍，在能效上可以快 30 到 80 倍。
* TPU v2 于 2017 年发布，其架构进行了根本性变革以支持训练。它用两个 128 x 128 的 BFloat16 阵列取代了原有的 256 x 256 8 位阵列，从而实现了训练所需的浮点精度。此外，它还增加了 16 GB、600 GB/s 的高带宽内存，彻底解决了 v1 版本中存在的内存瓶颈问题。更重要的是，v2 引入了芯片间互连技术，这是一种定制的高速链路，可将各个 TPU 直接连接起来。这使得 TPU Pod 成为可能，其中 256 个芯片作为一个独立的加速器运行，可提供 11.5 petaflops 的性能。
* 2018 年推出的 TPU v3 将性能提升了一倍，单芯片性能达到 420 万亿次浮点运算，并引入了液冷技术以应对更高的功率密度。Pod 的芯片数量扩展到 1024 个，性能超过 100 千万亿次浮点运算，足以在合理的时间范围内训练当时规模最大的 AI 模型。
* 2021 年发布的 TPU v4 带来了多项创新。SparseCores 技术仅占用芯片面积的 5%，就将推荐系统和语言模型的关键嵌入操作速度提升了 5 到 7 倍。光路交换机实现了动态网络拓扑重构。它不再使用固定电缆，而是利用机械反射镜在光纤间引导光束。这使得互连能够绕过故障，并可扩展至 4,096 个芯片的 Pod，性能接近 1 exaflop。3D 环面拓扑结构中，每个芯片连接到六个相邻芯片而非四个，从而降低了分布式训练的通信延迟。
* Ironwood（或称 TPU v7）将于 2025 年发布，代表着迄今为止最重大的飞跃。它专为推理时代而设计，在这个时代，大规模部署 AI 比训练更为重要。每颗芯片可提供 4,614 万亿次浮点运算的性能，配备 192 GB 的 HBM 显存，带宽高达 7.4 TB/s。

== 最后 ==
TPU部署在各种应用中都展现出了实际效果。

作为参考，单个 TPU 每天可处理超过 1 亿张 Google Photos 照片。AlphaFold 团队利用 TPU 解决了困扰人们 50 年的蛋白质折叠难题，并因此荣获 2024 年诺贝尔化学奖。PaLM 是一个拥有 5400 亿个参数的语言模型，在 6144 个 TPU v4 芯片上训练，50 天内硬件利用率达到 57.8%，如此大规模的分布式训练效率令人瞩目。除了 Google 之外，TPU 还为 Anthropic 的 Claude 助手、Midjourney 的图像生成模型以及众多研究突破提供支持。

然而，TPU并非在所有方面都优于GPU。它们在处理大规模语言模型训练和推理、需要大量矩阵运算的CNN和Transformer模型、高吞吐量批量处理以及优先考虑能效的工作负载方面表现出色。另一方面，对于PyTorch原生开发而言，GPU仍然是更好的选择，因为原生开发需要PyTorch/XLA桥接，而这会带来一些不便。小批量处理、混合AI和图形工作负载、多云部署以及快速原型开发通常更适合使用GPU。

TPU 代表着整个行业向特定领域加速器转变的趋势。

通用计算模型（即CPU能够相当流畅地运行任何程序）在工作负载扩展到每次查询数万亿次运算时，就会达到物理极限。而牺牲灵活性以换取效率的专用芯片，则能带来数量级的性能提升，这是任何通用处理器优化都无法比拟的。

谷歌的张量处理器（TPU）是如何工作的？

2026-01-17T09:29:19Z

Admin：

2016年3月，DeepMind的AlphaGo击败围棋世界冠军李世石，这在人工智能领域具有里程碑式的意义。而这场比赛所使用的硬件，谷歌已经投入生产运行一年多，但从未公开承认过。

张量处理单元（TPU）的意义远不止于一款高速芯片。它标志着计算理念的根本性转变：有时少即是多。

自 2015 年以来，谷歌的 TPU 系列芯片已发展了七代，从最初处理图像识别查询的单芯片扩展到如今拥有 9216 个芯片的超级计算机，用于训练目前规模最大的语言模型。本文将探讨谷歌为何要打造定制芯片，以及其工作原理，并揭示他们必须面对的物理限制和工程权衡。

== 对TPU的需求 ==
2013年，谷歌的基础设施团队进行了一项计算。如果安卓用户像谷歌预期的那样大规模使用语音搜索，即使每天只使用三分钟，其计算需求也需要谷歌将其全球数据中心的规模扩大一倍。

当时这个问题似乎没有明显的解决方案。建造更多配备传统处理器的数据中心在经济上不可行。更重要的是，摩尔定律多年来一直在放缓。几十年来，半导体行业一直依赖于晶体管密度大约每两年翻一番的观察结果，从而在不改变架构的情况下实现性能的持续提升。然而，到了2013年，这种趋势开始减弱。谷歌不能仅仅等待英特尔的下一代CPU来解决它的问题。

造成这种情况的根本原因在于架构。传统计算机遵循冯·诺依曼架构，其中处理器和内存通过共享总线进行通信。要执行任何计算，CPU 必须先获取指令，然后从内存中检索数据，执行运算，最后将结果写回内存。处理器和内存之间这种持续不断的信息传输，造成了计算机科学家所说的冯·诺依曼瓶颈。
[[文件:Image.png|居中|缩略图|480x480像素]]在总线上传输数据所需的能量通常超过计算本身所需的能量。例如，想象一下一位厨师正在准备一道菜，但他必须走到很远的储藏室去取每种食材。烹饪只需几秒钟，但走动却要花费数小时。对于文字处理或网页浏览等通用计算任务来说，这种设计是合理的，因为工作负载是不可预测的。然而，神经网络的情况则不同。

深度学习模型执行的操作几乎全部都是矩阵乘法。神经网络通过将输入数据与学习到的权重矩阵相乘、加上偏置值并应用激活函数来处理信息。对于单个预测，这个过程会重复数十亿次。拥有数千亿个参数的现代语言模型，每次查询都需要数千亿次乘加运算。关键在于，这些运算是可预测的、并行的和确定性的。

CPU 将大量处理能力用于分支预测和乱序执行等功能，旨在处理不可预测的代码。图形处理器 (GPU) 通过数千个核心并行工作改善了这种情况，但它们仍然继承了图形处理方面的架构开销。谷歌的远见卓识在于制造只执行神经网络所需功能的芯片，并去除所有其他功能。

== 脉动阵列：一种不同的计算方法 ==
TPU 的核心是一种名为脉动阵列的架构。这个名称源自希腊语中“心跳”一词，指的是数据在芯片内有节奏地脉动传输。为了理解这一点的重要性，我们可以思考不同的处理器是如何处理同一任务的。

* CPU 的运行就像一个工人来回奔波于水井和火堆之间，一次只装满一个桶。
* GPU 部署数千个工作进程同时执行相同的任务。吞吐量增加，但油井和火源之间的流量变得混乱且耗能。
* 循环式灌溉系统采用了一种截然不同的方法。工人们排成一列，手拉手传递水桶。水在链条中流动，直到工作完成，期间无人返回水源。

在 TPU 中，工作单元是排列成密集网格的简单乘加运算单元。第一代 TPU 使用 256×256 的阵列，这意味着 65,536 个计算器同时运行。计算过程如下：

* 神经网络权重从上方加载到每个计算器中，并保持不变。
* 输入数据从左侧逐行流入。
* 数据经过每个计算器时，都会乘以居民体重。
* 该乘积会累加到累计总和中，然后向右传递给下一个计算器。
* 部分结果会累积并向下传递。
* 所有计算完成后，最终结果将从底部得出。

请看下图：
[[文件:Tpu-2.png|居中|无框|542x542像素]]

这种设计意味着数据只需从内存中读取一次，但在遍历阵列的过程中会被使用数千次。传统处理器几乎每次操作都需要访问内存。而脉动阵列消除了这一瓶颈。数据仅在空间上相邻的计算器之间通过短导线传输，从而显著降低了能耗。

数据有力地证明了这种方法的合理性。

* TPU v1 的 256×256 阵列每个时钟周期可以执行 65536 次乘加运算。在 700 MHz 的运行频率下，它每秒可完成 92 万亿次 8 位运算，而功耗仅为 40 瓦。
* 现代 GPU 每个周期可能执行数万次运算，而 TPU 则执行数十万次运算。
* 超过 90% 的硅片执行了有效的计算，而 GPU 中只有大约 30% 的硅片执行了有效的计算。

这里的权衡之处在于绝对的专业化。脉动阵列只能高效地执行矩阵乘法，而无法渲染图形、浏览网页或运行电子表格。谷歌接受了这一限制，因为神经网络推理本质上就是多次重复的矩阵乘法。

== 支持架构 ==
脉动阵列需要精心协调的辅助组件才能发挥其性能。每个组件都解决了从原始数据到人工智能预测流程中的特定瓶颈。
[[文件:Tpu-jiagou.png|居中|无框|563x563像素]]

让我们来看看最重要的组成部分：

=== 矩阵乘法单元 ===
矩阵乘法单元（MXU）就是脉动阵列本身。

TPU v1 使用单个 256×256 数组，处理 8 位整数。后续版本采用 128×128 数组，并使用 Google 的 BFloat16 格式处理训练工作负载，然后在 v6 版本中又回归到 256×256 数组，吞吐量提升了四倍。这种权重固定设计最大限度地减少了数据移动，而数据移动是计算中主要的能耗来源。
[[文件:Tpu-mutiple-unit.png|居中|无框|663x663像素]]

=== 统一缓冲区 ===
统一缓冲区提供 24 兆字节的片上 SRAM，作为速度较慢的外部存储器和容量较大的 MXU 之间的高速过渡区域。

该缓冲区存储来自主机的输入激活值、神经网络层之间的中间结果以及传输前的最终输出。由于该存储器直接位于芯片上，因此其带宽高于外部存储器。这种带宽差异对于保持 MXU 持续接收数据至关重要，避免其闲置等待内存访问。

=== 矢量处理单元 ===
向量处理单元 (VPU) 可以处理 MXU 无法处理的操作，包括 ReLU、sigmoid 和 tanh 等激活函数。

神经网络需要非线性运算来学习复杂的模式。如果没有非线性运算，多层神经网络在数学上就会简化为单一的线性变换。TPU 没有采用软件实现这些功能，而是使用专用的硬件电路在一个周期内计算激活值。数据通常从 MXU 流向 VPU 进行激活值处理，然后再传递到下一层。

=== 累加器 ===
累加器收集来自 MXU 的 32 位结果。

当 8 位输入相乘时，乘积为 16 位，但累加和会因重复加法而不断增大。使用 32 位累加器可以防止矩阵乘法所需的多次加法运算过程中发生溢出。累加器内存总共占用 4 兆字节，分布在 4096 个向量中，每个向量包含 256 个元素。

=== 重量先进先出缓冲 ===
权重 FIFO 缓冲区使用称为双缓冲的技术在外部存储器和 MXU 之间暂存权重。

MXU 存储两组权重块：一组正在实时计算，另一组则从内存加载。这种重叠存储方式完全消除了内存延迟，确保计算单元无需等待数据。

=== 高带宽内存 ===
高带宽内存随着TPU的代际发展而不断演进。

最初的v1版本采用DDR3内存，传输速度为34GB/s。而现代的Ironwood TPU则达到了7.4TB/s，速度提升了217倍。HBM通过将多个DRAM芯片垂直堆叠，并在芯片间建立数千个连接来实现如此高的带宽，这是传统内存封装方式无法实现的。

== 精准优势 ==
TPU 通过量化显著提升效率，使用比传统浮点运算精度更低的数字。这种选择对硬件有着深远的影响，并波及整个设计。

科学计算通常需要高精度。例如，将圆周率计算到小数点后十位需要精确表示极小的差异。然而，神经网络的运行方式不同。它们计算的是概率和模式。例如，模型预测图像是猫的概率是 85% 还是 85.3472%，对分类结果实际上没有区别。

乘法器电路的硅片面积与位宽的平方成正比。一个 8 位乘法器大约需要 64 个硅片面积单位，而一个 32 位乘法器则需要大约 576 个硅片面积单位。这种数学关系解释了为什么 TPU v1 可以在一块尺寸适中的芯片上集成 65,536 个乘加单元，而 GPU 包含的浮点运算单元数量则少得多。更多的乘法器意味着每个周期可以执行更多的并行运算。

第一代TPU使用8位整数进行推理，与32位浮点数相比，内存需求减少了四倍。一个91兆字节的模型量化后变为23兆字节。研究表明，推理很少需要32位精度。额外的小数位对预测结果几乎没有影响。

由于微小的梯度更新会在数百万次迭代中累积，训练需要更高的精度。谷歌通过发明 BFloat16（即 Brain Floating-Point 16）解决了这个问题。这种格式与 32 位浮点数一样保留了 8 位指数，但尾数仅使用 7 位。其关键在于，神经网络对由指数控制的动态范围比对由尾数控制的精度更为敏感。BFloat16 以一半的位数提供了多种浮点格式，从而实现了高效的训练，避免了其他 16 位格式常见的溢出问题。

请看下图：
[[文件:Tpu-fp32-16.png|居中|无框|603x603像素]]

现代TPU支持多种精度模式。

* BFloat16 用于训练。
* 在 TPU v5e 上，INT8 推理的运行速度提高了一倍。
* 最新的FP8格式。

Ironwood 是首款原生支持 FP8 的 TPU，避免了早期几代产品中的模拟开销。

== 进化之旅 ==
TPU 的发展遵循着清晰的轨迹。

每一代人工智能都在提升性能的同时提高了能效。这一演变过程揭示了随着模型规模的扩大，人工智能硬件需求是如何变化的。

* TPU v1 于 2015 年秘密发布，专注于推理。它采用 28 纳米制程工艺，功耗仅为 40 瓦，每秒可执行 92 万亿次 8 位运算。该芯片通过 PCIe 连接到标准服务器，并在谷歌以外的任何人知晓其存在之前，就开始为谷歌搜索、照片、翻译和 YouTube 等应用提供技术支持。2016 年 3 月，TPU v1 助力 AlphaGo 战胜李世石，证明专用芯片在速度上可以比通用 GPU 快 15 到 30 倍，在能效上可以快 30 到 80 倍。
* TPU v2 于 2017 年发布，其架构进行了根本性变革以支持训练。它用两个 128 x 128 的 BFloat16 阵列取代了原有的 256 x 256 8 位阵列，从而实现了训练所需的浮点精度。此外，它还增加了 16 GB、600 GB/s 的高带宽内存，彻底解决了 v1 版本中存在的内存瓶颈问题。更重要的是，v2 引入了芯片间互连技术，这是一种定制的高速链路，可将各个 TPU 直接连接起来。这使得 TPU Pod 成为可能，其中 256 个芯片作为一个独立的加速器运行，可提供 11.5 petaflops 的性能。
* 2018 年推出的 TPU v3 将性能提升了一倍，单芯片性能达到 420 万亿次浮点运算，并引入了液冷技术以应对更高的功率密度。Pod 的芯片数量扩展到 1024 个，性能超过 100 千万亿次浮点运算，足以在合理的时间范围内训练当时规模最大的 AI 模型。
* 2021 年发布的 TPU v4 带来了多项创新。SparseCores 技术仅占用芯片面积的 5%，就将推荐系统和语言模型的关键嵌入操作速度提升了 5 到 7 倍。光路交换机实现了动态网络拓扑重构。它不再使用固定电缆，而是利用机械反射镜在光纤间引导光束。这使得互连能够绕过故障，并可扩展至 4,096 个芯片的 Pod，性能接近 1 exaflop。3D 环面拓扑结构中，每个芯片连接到六个相邻芯片而非四个，从而降低了分布式训练的通信延迟。
* Ironwood（或称 TPU v7）将于 2025 年发布，代表着迄今为止最重大的飞跃。它专为推理时代而设计，在这个时代，大规模部署 AI 比训练更为重要。每颗芯片可提供 4,614 万亿次浮点运算的性能，配备 192 GB 的 HBM 显存，带宽高达 7.4 TB/s。

== 结论 ==
TPU部署在各种应用中都展现出了实际效果。

作为参考，单个 TPU 每天可处理超过 1 亿张 Google Photos 照片。AlphaFold 团队利用 TPU 解决了困扰人们 50 年的蛋白质折叠难题，并因此荣获 2024 年诺贝尔化学奖。PaLM 是一个拥有 5400 亿个参数的语言模型，在 6144 个 TPU v4 芯片上训练，50 天内硬件利用率达到 57.8%，如此大规模的分布式训练效率令人瞩目。除了 Google 之外，TPU 还为 Anthropic 的 Claude 助手、Midjourney 的图像生成模型以及众多研究突破提供支持。

然而，TPU并非在所有方面都优于GPU。它们在处理大规模语言模型训练和推理、需要大量矩阵运算的CNN和Transformer模型、高吞吐量批量处理以及优先考虑能效的工作负载方面表现出色。另一方面，对于PyTorch原生开发而言，GPU仍然是更好的选择，因为原生开发需要PyTorch/XLA桥接，而这会带来一些不便。小批量处理、混合AI和图形工作负载、多云部署以及快速原型开发通常更适合使用GPU。

TPU 代表着整个行业向特定领域加速器转变的趋势。

通用计算模型（即CPU能够相当流畅地运行任何程序）在工作负载扩展到每次查询数万亿次运算时，就会达到物理极限。而牺牲灵活性以换取效率的专用芯片，则能带来数量级的性能提升，这是任何通用处理器优化都无法比拟的。