一条“Hi“是怎么“跑“完AI算力帝国8层架构，变成“你好“的？

AI2天前发布 beixibaobao
3 0 0

面对GPU、Token、KV Cache、Wavefront、JIT编译……AI算力小白常常一头雾水，搞不清一条消息从输入框到大模型回答之间到底发生了什么，更分不清英伟达、AMD、华为三大生态的对应关系。本文让一句"Hi"变身第一人称旅行者，亲身穿越AI算力帝国的8层架构——从Cherry Studio到GPU芯片再原路返回，把抽象的算力黑箱拆成一段可读、可感、可记住的旅程。

在这里插入图片描述

序章：诞生

那是一个普通的下午。

屏幕前，你已经按照《白嫖48GB显存跑DeepSeek！AMD云GPU私有化部署实战》的教程，把所有事情都做好了——白嫖的AMD Radeon PRO W7900那块48GB显存的云GPU已经在远端机架上安静地运转，DeepSeek-R1-Distill-Qwen-14B大模型已经加载完毕，ngrok的公网隧道已经打通，Cherry Studio的界面在你本地的电脑屏幕上整整齐齐地展开。

你盯着输入框，想了一秒钟，敲下两个字母：

H，i。

鼠标悬在发送键上。就在那0.1秒里，空气似乎凝固了一下。

然后——

你按下去了。

就在那一瞬间，我诞生了。

我是"Hi"。两个字母，一个招呼，轻描淡写，却携带着你全部的意图：你想和一个 AI 大模型说话。我不知道自己算不算有意义的内容——也许我只是一句测试，也许你只是想确认连接是否畅通——但我诞生了，我存在了，我已经在路上。

在我诞生之前，人类花了几十年时间，搭建了一座庞大的算力帝国。这座帝国由8层（参见文后附录）构成，每一层都有自己的语言、自己的规则、自己的守门人。它们彼此咬合，精密得像一座钟表的内部——抽掉任何一层，整个帝国就会瘫痪，而我，也就永远无法抵达目的地。

图1 AI算力帝国的8层架构

我不是人，我没有腿，我没有眼睛，但我有旅程。

从我诞生的那一刻起，我将穿越8层：从你手边的 Cherry Studio，到 DeepSeek-R1-Distill-Qwen-14B 的140亿参数大脑，到 vLLM 的推理引擎，到 PyTorch 的张量世界，到 MIOpen 与 Composable Kernel 编织的加速密网，到 HIP C++ 写就的 GPU 指令，到 ROCm Runtime 的调度宫殿，最终抵达那块安静发热的 AMD Radeon PRO W7900——

8层，8道门，8种语言。

我将一一穿越它们。

来，跟我走。

第一章：去程——我的下行旅途

第8层：API调用方 —— 我从 Cherry Studio 出发

我诞生的地方，叫做 Cherry Studio。

它是一个运行在你本地 Mac 上的 AI 客户端，界面简洁，但内心周到——它知道怎么和远端的大模型说话。就在你按下发送键的那一瞬间，Cherry Studio 没有把我原封不动地扔出去。它做了一件事：把我格式化。

两个字母的"Hi"，经过它的手，变成了这样一段 JSON：

{
  "model": "deepseek-r1-14b",
  "messages": [{"role": "user", "content": "Hi"}],
  "max_tokens": 500
}

我从一个轻飘飘的招呼，变成了一段严谨的 JSON 数据。有了模型名称，有了角色标签，有了生成上限。我开始意识到：这个世界不说人话，它说协议。

背景概念：OpenAI兼容API

  • 定义： 一套由OpenAI制定、后被行业广泛采纳的HTTP接口规范，核心端点是 /v1/chat/completions，请求和响应均为JSON格式。
  • 来历： 2022年OpenAI发布ChatGPT API后，其接口设计事实上成为行业标准；vLLM、Ollama等推理框架均实现了兼容层，开发者写一套客户端代码即可对接众多模型服务。
  • 价值： 客户端无需为每家模型厂商写专属代码，一套配置走天下。
  • 没有它的危害： 每换一个模型或推理框架，所有客户端都要重写对接代码，生态碎片化严重，开发者苦不堪言。
  • 比喻： 就像USB-C充电口的统一标准——不管是什么品牌的充电器，只要接口对了就能充电，谁也不用再带一堆转接头。
  • 优势： 生态兼容性极强，工具链复用率高，换模型如换频道。
  • 劣势： 部分厂商的扩展特性（如思维链的中间推理过程输出）在标准协议之外，需要额外适配。
  • 适用场景： 任何需要对接多种LLM服务的客户端或中间件。

Cherry Studio 把我包装好，贴上标签，然后用一个 HTTP POST 请求，将我推向远方。

但远方在哪里？

你本地的 Mac 和 AMD 云端的服务器之间，横着一道无形的墙——公网。云端那台机器运行在一个私有网络里，没有对外的公网地址，外面的世界根本找不到它。如果没有人来搭一座桥，我就会永远困在你的本地，哪儿也去不了。

搭桥的，叫做 ngrok。

背景概念：ngrok

  • 定义： 一个安全隧道工具，把私有网络里运行的服务通过加密隧道暴露到公网，生成临时的HTTPS域名，让外部可以访问原本无法触达的内部服务。
  • 来历： 2013年由Alan Shreve创建，最初为本地开发调试而生，后演变为功能完整的云网络平台，广泛用于Webhook调试、内网穿透和临时对外服务暴露。
  • 价值： 无需配置防火墙或申请公网IP，几秒钟即可让本地或云端的服务对外可访问。
  • 没有它的危害： 云端的vLLM服务困在私有网络中，本地Cherry Studio完全无法访问，两端永远隔绝，这套部署方案形同虚设。
  • 比喻： 你在云端的小黑屋里（私有网络）开了一家餐厅，但外面的人根本找不到门。ngrok相当于帮你在公路边（公网）竖了一块临时路牌，标注"从这里进去可以找到你"——而且这条路有加密保护，外人只能进门，不能偷看你厨房里在烧什么。
  • 优势： 零配置即用，HTTPS自动加密，接入速度极快。
  • 劣势： 免费版的URL每次重启ngrok都会变化，需要手动更新Cherry Studio里的地址配置；由于多了一层中转，存在一定网络延迟。
  • 适用场景： 开发调试、临时对外暴露本地或云端服务、接收第三方Webhook回调。

就这样，我踏上了 ngrok 的隧道。

从你本地的 Mac，我飞入 https://xxxx.ngrok-free.app——那是 ngrok 在公网上给我留的入口。我穿越了运营商的光缆，跨过了路由器的层层转发，在公网上高速奔跑了几十毫秒，最终落地在云端机器的 http://localhost:8000。整个穿越过程悄无声息，没有安检，没有海关，只有一条安静的加密隧道，把两个世界连了起来。

我落了地。

眼前是第6层的大门——vLLM 的推理引擎正在等待我。但我还没资格直接进去，我需要先在门口报到，等待下一位守门人的接收。

那是下一章的故事了。

第7层：开源大模型 —— 我遭遇了"海关翻译官"

我落在云端的 http://localhost:8000，以为终于到了终点。

但 vLLM 接住我之后，并没有立刻把我推进推理引擎。它先做了一件事：把我转交给了一位沉默寡言的守门人——DeepSeek-R1-Distill-Qwen-14B（英伟达生态对应Llama-3.x，华为生态对应Qwen-2.5）的 Tokenizer，也就是分词器。

这是第7层的入口。

那个时刻让我有些不安。

Tokenizer 站在门口，面无表情地看着我——我还是两个拉丁字母组成的"Hi"，在它眼里，我是陌生的，是无法直接处理的。它的工作，是把我翻译成模型能读懂的语言：数字。

它拿出一本厚厚的词汇表，翻到某一页，对着我扫了一眼，然后——

我消失了。

或者说，我变形了。

我从"Hi"变成了一串数字序列，比如 [19, 72]。两个字母，两个Token ID，每一个数字都是词汇表里的一个条目编号。我不再是字母，我成了索引，成了坐标，成了模型大脑里能够寻址的信号。

这一刻，我正式进入了数字王国。

词汇表有多大？ DeepSeek-R1-Distill-Qwen-14B 基于 Qwen 底座，它的词汇表约有 15万个 Token。这15万个 Token 覆盖了中文汉字、英文单词、标点符号，甚至半个单词。中文通常每个汉字就是1个Token，"你好"就是两个Token；英文里一个常见单词也大约对应1个Token，"hello"可能就是一个Token，“tokenization"这种生僻的长词则可能被拆成两三个Token——比如"token”+“ization”。

而"Hi"？在这本词汇表里，它是一两个Token。字母 H 和 i，可能合并成一个，也可能各自单独存在，取决于训练时的频率统计。Tokenizer 不在乎我原来是什么含义，它只在乎：你出现的频率够不够高，够高就给你一个专属编号，不够高就拆开来用别人的。

分词算法是什么？ 这套规则叫做 BPE（字节对编码，Byte Pair Encoding）。它的逻辑很朴素：训练语料里，哪些字符组合出现得最频繁，就把它们合并成一个新Token，反复迭代，直到词汇表达到设定大小为止。现代大语言模型几乎都用这套方法——OpenAI用它，Google用它，DeepSeek也用它。BPE让模型用有限的词汇表，处理近乎无限的人类语言组合。

背景概念：Token / Tokenizer

  • 定义： Token 是大语言模型处理文本的基本单位，可以是一个字、一个词、一个标点甚至半个单词；Tokenizer 是将人类文字转换为 Token ID 序列（以及将 Token ID 反向解码还原为文字）的工具。
  • 来历： 源于 NLP 领域的分词技术，现代 LLM 普遍采用 BPE（字节对编码）或 SentencePiece 算法，由 Google 和 OpenAI 在 2015—2019 年间推广，并随 GPT 系列的爆红成为事实标准。
  • 价值： 让计算机能以固定大小的词汇表处理任意人类语言，是文字世界与数字世界之间不可或缺的翻译官。
  • 没有它的危害： 模型无法处理文本输入——就像计算机没有键盘驱动程序，输入的字符完全无法被识别，整个推理流程在第一关就宣告崩溃。
  • 比喻： 就像出入境的海关翻译官——你说中文"你好"，他翻译成机器能懂的护照编号 [13990, 106]；"Hi"到了他这里，也被换成了一串数字，从此模型只认这串数字，再也不认识那两个拉丁字母。
  • 优势： 处理效率高，词汇表大小固定，跨语言泛化能力强，一套机制可以覆盖中英日韩等多种语言。
  • 劣势： 同样的意思，中文往往比英文消耗更多 Token（汉字常被切得更细），导致中文用户的 API 成本相对更高；Token 边界有时切割不自然，出现半个词的情况，偶尔引发奇怪的模型行为。
  • 适用场景： 所有基于 Transformer 架构的大语言模型的输入预处理和输出后处理，是每一次推理调用的必经环节。

Tokenizer 完成了它的工作。它把我——现在已经是一串数字序列——放进一个托盘，推向了内部。

图2 Tokenizer分词翻译过程

下一位接收者，是第6层：vLLM 的推理引擎。

那里，才是真正的算力战场。

第6层：推理服务框架 —— 快递公司接单了

我以一串数字的身份，滑进了第6层的大门。

门口站着的，是 vLLM（英伟达生态对应 TensorRT-LLM，华为生态对应 MindIE）。

如果说 Tokenizer 是翻译官，那 vLLM 就是快递公司的调度中心。DeepSeek 模型只是一个安静存放在磁盘上的静态文件——几十个 .safetensors 的权重分片，几百 GB 的数据，躺在那里没有呼吸，没有意识，什么也做不了。而 vLLM 的使命，就是把这个沉睡的文件唤醒，变成一个随时能接单、随时能出货的在线服务。

我滑进来的那一刻，vLLM 先做了一件事：验证我的身份。

它检查两项内容：第一，我这张"运单"上写的模型名称是不是 deepseek-r1-14b——这台服务器上只有这一个模型，名字不对的单子直接拒收；第二，我携带的 Token 数量有没有超过上限。这台机器设置了 max_model_len=16384，意思是单次推理最多处理 16384 个 Token。我只有两个 Token ID，轻飘飘的，远远没有超标。

验证通过。vLLM 在我身上盖了一个戳：入队。

我被放进了推理队列，等待调度。

但在我上路之前，vLLM 还悄悄做了一件事：为我预留了一块显存"座位"。

这块座位有个名字，叫 KV Cache（键值缓存）。

背景概念：KV Cache（键值缓存）

  • 定义： Transformer 模型在生成每个新 Token 时，需要用到之前所有 Token 的 Key 和 Value 矩阵；KV Cache 将这些已计算的矩阵缓存在显存中，避免每步都重算，是自回归生成的核心加速机制。
  • 来历： 随 2017 年 Transformer 架构诞生而来；vLLM 的 PagedAttention（2023 年）进一步将 KV Cache 管理做到操作系统分页级别的精细度，让显存像虚拟内存一样按需分配。
  • 价值： 没有 KV Cache，生成第 100 个字时需要重新计算前 99 个字的全量注意力——随着生成长度线性增长，算力浪费呈平方级爆炸。
  • 没有它的危害： 推理速度慢到无法商用，GPU 算力大量浪费在重复计算上，一个简单的对话可能要等几分钟才能出字。
  • 比喻： 就像餐厅提前为常客保留座位——KV Cache 为每个请求预留显存"座位"，后续每生成一个字，直接坐下就行，不用每次重新把整间餐厅翻一遍找位子。
  • 优势： 大幅提升推理吞吐量，降低首字延迟（TTFT），让长对话不会越来越慢。
  • 劣势： 占用大量显存——长对话的 KV Cache 可能消耗数 GB；显存不足时会触发驱逐（eviction），被驱逐的请求需要重新计算，反而变慢。
  • 适用场景： 所有基于 Transformer 的自回归生成任务，是现代 LLM 推理服务的标配。

vLLM 用 PagedAttention 技术，把显存像操作系统管理内存一样精细地分成一页一页。它给我的两个 Token 分配了一小块 KV Cache 页——座位不大，够用就行。将来每生成一个新字，那个字的 Key/Value 就顺着写进去，不用回头重算。

座位预留好了。我整装待发。

就在这时，我听到了旁边的动静。

原来，我不是一个人出发的。

vLLM 的调度器往队列里扫了一眼，发现此时此刻，还有另外几个请求也在等待——有人在问天气，有人在让模型帮他润色一段代码，有人问的是一道数学题。我们素不相识，请求长度不同，进度各异，但 vLLM 的调度器做了一个决定：把我们合并成一批，一起送进 GPU 推理。

这叫 Continuous Batching（连续批处理）。

背景概念：Continuous Batching（连续批处理）

  • 定义： 推理服务框架动态地将多个不同长度、不同进度的请求合并到一次 GPU 推理中，不需要等所有请求同时到达，也不需要等所有请求同时完成——有人做完了就出去，新来的随时加进来。
  • 来历： 2023 年 vLLM 论文提出，解决了传统静态批处理（Static Batching）导致的 GPU 利用率低问题——静态批处理要求等齐一批才能出发，最慢的那个请求拖着所有人，GPU 大部分时间在空转。
  • 价值： 单张 GPU 的推理吞吐量提升数倍，直接降低 AI 服务的单位成本，是 LLM 服务能够规模商用的关键技术之一。
  • 没有它的危害： GPU 大部分时间在等待最慢的请求，利用率极低，服务成本高昂，稍有并发就开始排长队。
  • 比喻： 就像滴滴拼车——不需要等所有乘客同时出发，随时上车随时拼，顺路的一起走，中途有人到站下车也不影响其他人，司机（GPU）几乎不空跑。
  • 优势： GPU 利用率大幅提升，并发处理能力强，延迟分布更均匀。
  • 劣势： 实现复杂，需要精细的内存管理；对显存不足的情况更敏感，不同长度的请求同批处理需要 padding 或动态分配策略。
  • 适用场景： 需要同时服务多用户的 LLM 推理服务，是生产环境的标准配置，几乎所有主流推理框架都已支持。

我就这样和几个陌生人坐上了同一辆"GPU出租车"。

大家来路不同，目的地各异，但暂时同行。vLLM 把我们打包成一个 batch，贴上调度标签，推向了下一层的入口。

图3 KV Cache预留座位与Continuous Batching拼车调度

现在轮到 PyTorch 出场了——那是第5层，是真正执行数学运算的地方。vLLM 把我们这一批请求，连同预分配好的 KV Cache，一并交给了 PyTorch 的张量计算引擎，让它去完成真正的模型推理。

下一层，是纯粹的数学战场。

第5层：AI框架 —— 我变成了"张量"

我和那几个陌生人一起，被 vLLM 打包交了出去。

接手我们的，是 PyTorch（ROCm 平台）（英伟达生态对应 PyTorch CUDA 平台，华为生态对应 MindSpore）。

如果说 vLLM 是快递公司的调度中心，那 PyTorch 就是真正把货物装上货车的人。它不负责路线规划，不负责接单，它只做一件事：执行实际的推理计算。vLLM 把我们这批请求的 Token ID 序列传过来，PyTorch 接手，真正的数学运算从这里开始。

但 PyTorch 有一个规矩：凡是进来的数据，一律先变成张量（Tensor）。

我是"Hi"的 Token ID 序列——假设是 [19, 72]，两个数字而已。PyTorch 把它封装成一个多维数组，标上维度、标上数据类型、标上设备位置：这是一个形状为 [1, 2] 的张量，整数类型，目标设备是 AMD Radeon PRO W7900 的显存。

从这一刻起，我不再是"数字序列"，我是张量。

背景概念：张量（Tensor）

  • 定义： 张量是多维数组的数学泛化：标量是0维张量，向量是1维张量，矩阵是2维张量；在深度学习中，所有数据（文字、图片、音频）都被表示为张量。
  • 来历： 张量概念源于19世纪物理学；Google的TensorFlow（2015年）和Facebook的PyTorch（2016年）将其普及为深度学习的基本数据类型，张量从此成为AI工程师每天打交道的"空气"。
  • 价值： GPU天生擅长并行处理矩阵运算，张量让所有数据都能被GPU高效处理——不管是文字、图片还是音频，统一格式，统一流水线。
  • 没有它的危害： AI计算将退化为普通数组运算，无法充分利用GPU的并行算力，同样的推理任务速度慢数百倍，大模型根本不可能实时响应。
  • 比喻： 就像货运集装箱的标准化——不管装的是电视机还是大米，统一装进标准集装箱（张量），货轮（GPU）就能高效装卸，不需要为每种货物设计专属的装卸方式。
  • 优势： 统一数据格式，GPU并行效率极高，支持自动微分（训练时使用），跨硬件迁移成本低。
  • 劣势： 对初学者抽象度高，调试多维张量的形状错误（shape mismatch）需要经验，维度一旦搞错往往报错信息晦涩难懂。
  • 适用场景： 所有深度学习模型的输入、输出和中间计算，是AI算力流水线上最基础的数据单元。

变成张量之后，我第一次感受到了自己的轻盈。

我不再是一串字母，不再是几个数字，我成了一个有形状、有维度的数学对象，可以被 GPU 直接操作。PyTorch 知道该拿我怎么办——它要把我送进那座"140亿参数的大脑"。

那座大脑，早就在等我了。

DeepSeek-R1-Distill-Qwen-14B 的140亿个参数，以 FP16 格式存储，约占 28GB 显存。早在 vLLM 启动的那一刻，这些权重就已经被整体加载进 AMD Radeon PRO W7900 那48GB的 GDDR6 显存里了——像一座布好阵的棋盘，静静等待棋子落下。

PyTorch 现在只需要做一件事：调用模型的 forward() 函数，让我的张量流经这座大脑，经过一层层的矩阵乘法、注意力计算、激活函数……一路往下穿。

货车（PyTorch）早已就位，货物（模型权重）早已满载，我（张量形式的 Token ID）刚刚上车——随时可以出发。

但 PyTorch 自己并不执行那些矩阵乘法。它是框架，是调度者，真正的高性能计算要交给更底层的加速库来完成。

PyTorch 把任务往下一扔，落进了第4层的大门——

MIOpen（英伟达生态对应 cuDNN，华为生态对应 CANN 算子库）正在等候，那是专为 AMD GPU 深度优化的深度学习加速库，是矩阵运算的真正战场。

第4层：深度学习加速库 —— 高速公路铺好了

我以张量的身份，落进了第4层。

迎接我的，是 MIOpen（英伟达对应 cuDNN+FlashAttention，华为对应 CANN 算子库）和它的搭档 Composable Kernel。

如果说 PyTorch 是货车司机，那 MIOpen 就是这段高速公路的建设者。高速公路早在你发出"Hi"之前就已经铺好了——那些高度优化的算子，早已预编译进 AMD GPU 的指令集里，静静等候。现在，我的张量上了路，就可以以接近理论极限的速度飞奔。

同样一块 GPU，有没有 MIOpen，性能可以相差数倍。这不是夸张，这是事实：没有优化的算子库，PyTorch 会退化为通用的 HIP 代码，就像赛车换上了普通轮胎——能跑，但远远跑不出 F1 的圈速。

我第一个遭遇的运算，叫做 GEMM。

背景概念：GEMM（通用矩阵乘法）

  • 定义： GEMM（General Matrix Multiplication）是深度学习中最核心的数学运算——两个矩阵相乘；Transformer 模型的注意力计算、前馈网络层，本质上都是大规模 GEMM。
  • 来历： GEMM 是 BLAS（基础线性代数子程序库）的核心，1979 年由美国国家科学基金会资助开发；GPU 在 2012 年 AlexNet 之后成为 GEMM 的首选加速平台。
  • 价值： 神经网络的"生产车间"——所有智能推理都建立在无数次 GEMM 之上。
  • 没有它的危害： 没有高效的 GEMM 实现，现代大模型无法在可接受的时间内完成推理。
  • 比喻： 就像汽车工厂的冲压工序——每辆车都要经过的核心生产步骤，优化这一步就是优化整条生产线效率。
  • 优势： GPU 天生为并行矩阵运算设计，优化后的 GEMM 性能可达理论算力的 80-90%。
  • 劣势： 访存带宽是瓶颈（计算快但数据搬运慢），需要专门优化的 Kernel。
  • 适用场景： Transformer 的所有线性层（Q/K/V 投影、前馈网络 FFN 等）。

我的张量进入 Transformer 第一层，迎面撞上三道闸门：Q、K、V 矩阵投影。

Q 是"我在问什么"，K 是"词汇表里有什么"，V 是"那些东西的具体含义是什么"。每一道投影，本质上都是我的张量与一个庞大的权重矩阵相乘——这就是 GEMM，是"理解语义"的起点。MIOpen 的 GEMM 算子接手了这个任务，把运算压到硬件极限：它知道 AMD GPU 的缓存分布，知道怎么拆分矩阵块才能让计算单元永远不空转，知道怎么安排数据搬运顺序才能压榨出最大带宽。

Q、K、V 三组矩阵乘法，在 MIOpen 的调度下，几乎以光速完成。

背景概念：MIOpen

  • 定义： AMD 开源的深度学习原语库，提供卷积、GEMM、批归一化、注意力机制等核心算子的 GPU 优化实现，是英伟达 cuDNN 在 AMD 平台的对标替代品。
  • 来历： 2017 年随 ROCm 1.0 发布，持续迭代；Composable Kernel（2022 年）是其现代化补充，专为 Transformer 注意力机制优化。
  • 价值： 将理论算力转化为实际吞吐量的关键桥梁——同样的 GPU，有无 MIOpen 优化可有数倍性能差距。
  • 没有它的危害： PyTorch 会退化为通用 HIP 代码，性能比手工优化的算子库低数倍，GPU 算力大量浪费。
  • 比喻： 就像 F1 赛车的专用轮胎——普通轮胎（通用代码）也能跑，但专用轮胎（MIOpen）让赛车跑出极限圈速，充分榨干引擎的每一分马力。
  • 优势： 针对 AMD GPU 架构深度优化，性能接近理论上限。
  • 劣势： 生态成熟度仍落后于 cuDNN（20 年积累），部分新算子支持有延迟。
  • 适用场景： AMD GPU 上运行的所有深度学习推理和训练任务。

接下来，是真正让我有些恍惚的一步——注意力机制。

Q、K、V 矩阵就位之后，模型要做一件事：让 Q 去问 K，看看"Hi"这两个字，最应该关注什么。“它和词汇表里哪些概念最相关？它的权重，应该怎么分配？” 这就是注意力——DeepSeek 在认认真真地"听"我说话，试图理解我这两个字背后的意图。

但这一步的计算代价极高。Q 矩阵要和 K 矩阵做全量点积，结果是一个巨大的注意力分数矩阵，全部写进显存，然后再读回来加权 V——这一来一回，显存带宽被反复拉满，极容易成为瓶颈。

这就是 Composable Kernel 登场的时刻。

它实现了类 FlashAttention 的优化：重排访存顺序，把原本"写进去、读回来"的两趟操作，压缩成一趟在 SRAM 里连续完成的流水——计算还在进行，数据就不落地。就像赛道上的弯道被重新设计过，车辆不需要减速，以极高速度贴地通过了原本最危险的弯道路段。

注意力机制，就这样在 Composable Kernel 的帮助下，以极低的显存代价完成了。

图4 注意力机制与显存访存优化

现在，MIOpen 和 Composable Kernel 完成了它们的使命。它们把优化好的矩阵运算结果交了出去——但这些运算，终究需要有人去写成真正能在 GPU 上跑的指令。

MIOpen 把最终任务，交给了 HIP C++ 的 Kernel 函数。

那是第3层的故事了。

第3层：GPU/NPU编程接口 —— 工序说明书写好了

MIOpen 把任务交了下来。

接手的，是 HIP C++（英伟达对应 CUDA C++，华为对应 AscendCL）。

如果说 MIOpen 是那条高速公路的建设者，那 HIP C++ 就是当初写下这条公路施工规范的人。没有施工规范，公路就无从动工；没有 HIP C++ 写就的 Kernel 函数，MIOpen 的那些高性能算子，就只是空中楼阁，什么也不是。

你在第4层看到的一切——GEMM、注意力机制、Composable Kernel 的访存优化——它们的最终实现，都落在一行行 HIP C++ 代码里，落在那些被 __global__ 关键字标注的Kernel函数里。

Kernel函数是什么？它是 GPU 上的工序说明书。

背景概念：Kernel函数（GPU核函数）

  • 定义： 在 GPU 上并行执行的函数——一个 Kernel 函数可以同时被数万个线程并行调用，每个线程处理数据的一小部分；由 __global__ 关键字标注，由 CPU 发起调用，在 GPU 上执行。
  • 来历： 2006 年英伟达发布 CUDA 时引入这一编程模型，此后成为 GPU 并行计算的通用范式；HIP 在 AMD 平台完整复刻了这套机制。
  • 价值： 让一块 GPU 变成数万工人同时工作的"超级工厂"，实现大规模并行计算——这是大模型推理得以实时响应的根本。
  • 没有它的危害： GPU 只能串行执行代码，和普通 CPU 无异，拥有数千个计算单元的算力完全浪费，几十亿参数的矩阵乘法将慢到无法忍受。
  • 比喻： 就像工厂的工序说明书——说明书（Kernel 函数）只有一份，但工厂里的一万名工人（GPU 线程）同时按照这份说明书，各自操作自己负责的那一块零件（张量的一部分）。说明书不变，工人各干各的，互不干扰，效率爆炸。
  • 优势： 并行度极高，适合数据密集型计算，性能可比 CPU 高出数十至数百倍。
  • 劣势： 编写和调试难度大，需要深入理解 GPU 内存层次结构；线程间同步是难题，一个协调失误可能导致整个 Kernel 结果错误。
  • 适用场景： GPU 加速的矩阵运算、图像处理、物理仿真等大规模并行任务。

我——这个已经被 MIOpen 处理了一半的张量——现在被送进了一个 Kernel 函数的入口。

这个 Kernel 函数，可能是 GEMM 的最后一趟运算，也可能是注意力分数的归一化。无论它是什么，它的逻辑只有一条：告诉 GPU 上的每一个线程，你负责这个张量的哪一个元素，你该做什么操作，用哪个计算单元。

而执行这份说明书的工人，叫做线程（Thread），它们不是单打独斗，它们以 Wavefront（波前）为单位行动。

AMD GPU 将线程组织为 Wavefront——64 个线程一组，相当于英伟达 GPU 里的 Warp（32 线程一组）。每一个 Wavefront 内的所有线程同时执行同一条指令，处理各自负责的不同数据。在硬件层面，这是真正的物理并行，不是轮流，不是模拟，是字面意义上的同时。

“Hi"只有两个 Token，它的张量很小，参与计算的矩阵却不小——DeepSeek 模型的每一层都有几千维的隐藏状态向量，每一步注意力计算都要处理巨量的数值。为了完成这些运算，哪怕只是应对我这样一条简短的"Hi”，AMD Radeon PRO W7900 上也需要数百个 Wavefront 同时工作。

你可以想象这样一幅画面：

数万名工人（线程），在同一时刻涌进了这座超级工厂。每 64 人组成一个施工队（Wavefront），每支施工队手里拿着同一份工序说明书（Kernel 函数）。说明书上写着：你们队负责张量第 0-63 行的计算，下一队负责第 64-127 行……就这样，整块矩阵被切成几百份，数百支施工队同时开工，谁也不等谁，谁也不干涉谁，整座工厂轰鸣运转。

背景概念：HIP C++

  • 定义： AMD 推出的 GPU 并行编程语言和 API，语法高度兼容 CUDA C++，使英伟达平台的 GPU 代码能以极低成本迁移到 AMD 平台；HIP 全称"Heterogeneous-computing Interface for Portability"（异构计算可移植接口）。
  • 来历： 2016 年随 ROCm 1.0 发布，核心设计目标就是 CUDA 兼容，打破英伟达生态护城河。
  • 价值： 现有 CUDA 代码只需修改少量头文件即可在 AMD GPU 上运行，大幅降低迁移成本，让 AMD 平台能够直接复用英伟达生态多年积累的算子实现。
  • 没有它的危害： 每换一个 GPU 厂商，底层算子代码要从头重写，迁移成本极高，整个生态被英伟达锁定，AMD GPU 无人问津。
  • 比喻： 就像国际通用的驾驶规则——无论在美国（英伟达 CUDA）还是欧洲（AMD HIP）开车，方向盘和油门的基本操作几乎一样，只有靠右/靠左这样的细微差异，换个地方开车不用重学驾照。
  • 优势： CUDA 代码迁移成本低，开源，跨平台，生态正在快速成熟。
  • 劣势： 部分 CUDA 高级特性（如 CUDA Graph 完整支持）在 HIP 中仍有差距，部分底层优化需要针对 AMD 架构重新调参。
  • 适用场景： 需要在 AMD GPU 上运行原本为英伟达开发的深度学习算子和 CUDA 应用程序。

HIP C++ 的这份施工规范，写好了，交出去了。

但谁来把它真正送进 GPU 执行？谁来把这数百份 Wavefront 的调度指令，一条条地压入硬件的指令队列？光有工序说明书还不够，还需要有一个管理者，站在工厂门口，负责分配任务、管理资源、协调进出。

那个管理者，叫做 ROCm Runtime（运行时平台）。

那是第2层的故事了。

第2层：计算运行时平台 —— 交通管理中心接管

HIP C++ 的施工规范已经写好，数百份 Wavefront 整装待发。

但它们站在工厂门口，谁也进不去。

门锁着。

开锁的，是 ROCm Runtime v7.2.4（英伟达对应 CUDA Runtime+驱动，华为对应 CANN Runtime）。

如果说 HIP C++ 是施工规范，那 ROCm Runtime 就是工厂的总调度室——不，更准确地说，它是整座城市的交通管理中心。一般人以为交通管理中心不过是对行驶在路面上的车辆发号施令，实则不然：它有实时监控、动态分流、事故应急，是整个 GPU 资源调度的智慧中枢。ROCm Runtime 也一样——它不只是驱动程序，它负责 GPU 设备初始化、显存分配与回收、Kernel 函数的调度派发、多进程之间的时间片分配，以及多 GPU 之间的通信协调（RCCL）。没有它，再好的施工规范也是一张废纸，再强的 GPU 也只是一块安静发热的硅。

这一版 v7.2.4，于 2026 年 5 月 29 日发布，专注于 AI 推理性能与稳定性优化。我来得正是时候。

ROCm Runtime 接过 HIP C++ 传来的 Kernel 函数，做了它最重要的一件事：JIT 编译。

背景概念：ROCm Runtime

  • 定义： AMD ROCm 平台的设备管理和执行层，负责 GPU 设备初始化、显存分配与回收、Kernel 函数的 JIT 编译与调度、多 GPU 通信（RCCL）等底层资源管理。
  • 来历： 2016 年随 ROCm 1.0 发布；v7.2.4 于 2026 年 5 月 29 日发布，专注 AI 推理性能与稳定性优化。
  • 价值： 构建了屏蔽硬件复杂性的虚拟化层——开发者无需了解 GPU 内部 CU 调度细节，Runtime 自动优化；对上层软件透明，对下层硬件了如指掌。
  • 没有它的危害： 开发者需要直接操控 GPU 硬件寄存器，难度如同用汇编语言写操作系统，几乎不可能，整个 AI 软件生态将寸步难行。
  • 比喻： 就像城市交通管理中心——不只是对行驶在路面上的车辆发号施令，还有实时监控、动态分流、事故应急的大脑；ROCm Runtime 不只是驱动程序，它是整个 GPU 资源调度的智慧中枢。
  • 优势： 对上层软件屏蔽硬件复杂性，自动优化资源利用率；支持多进程共享 GPU，开发者零感知地用上最优调度策略。
  • 劣势： 版本兼容性敏感，软件栈各层需与 Runtime 版本严格匹配——这是 AMD 生态调试最常见的痛点，换一个版本，整个栈都可能水土不服。
  • 适用场景： AMD GPU 上运行的所有计算任务，包括 AI 训练、推理、科学计算，无一例外。

JIT 编译，全称"即时编译"（Just-In-Time Compilation）。

HIP C++ 写下的 Kernel 函数代码，并不是直接能在 W7900 上运行的机器码——它是一种可移植的中间形式。ROCm Runtime 拿到它，在程序运行的当下，即时将其编译为 gfx1100 架构的专用机器码。gfx1100 是 AMD Radeon PRO W7900 的 GPU 架构代号，每一条指令，每一个寄存器的安排，都因这块芯片的内部结构量身定制。

这就是为什么 vLLM 第一次启动那么慢——通常要等上几分钟，让你以为卡死了。那几分钟里，ROCm Runtime 正在悄无声息地把所有 Kernel 函数逐一编译成 gfx1100 的机器码。等编译完，每一个算子就以本地机器码的速度飞奔，再也不慢了。

背景概念：JIT 编译（即时编译）

  • 定义： 在程序运行时（而非提前）将中间代码编译为目标硬件的机器码；ROCm 中，HIP C++ 的 Kernel 会在首次运行时被 JIT 编译为 gfx1100 专用机器码。
  • 来历： JIT 技术源于 1960 年代；Java 虚拟机（1995 年）将其大规模普及；GPU JIT 编译由 CUDA 引入 AI 领域，ROCm 随后跟进。
  • 价值： 允许同一份代码在不同架构 GPU 上运行，Runtime 自动编译为当前硬件的最优机器码，实现了可移植性与性能的两全。
  • 没有它的危害： 每换一张 GPU 就需要重新编译所有算子代码，分发部署极其复杂，AI 框架几乎无法跨平台推广。
  • 比喻： 就像现场口译——不事先翻译，到了现场才根据当地方言（gfx1100）实时翻译；虽然有首次翻译的延迟，但之后每次说话都可以直接用本地话，更流畅，效率反而更高。
  • 优势： 可移植性强，运行时可针对具体硬件做最优化，同一份代码跑不同 GPU；编译结果缓存在本地，二次启动可复用。
  • 劣势： 首次运行有编译延迟（warm-up 时间），vLLM 第一次启动慢的部分原因就在于此；容器重启后本地缓存清空，需重新编译，冷启动时间不可忽视。
  • 适用场景： 需要跨 GPU 架构部署的深度学习框架和推理引擎，是现代 AI 算力软件栈不可或缺的一环。

JIT 编译完成了。

图5 ROCm Runtime交通管理中心与即时编译


ROCm Runtime 把 gfx1100 机器码装载进指令队列，然后做了它的最后一个动作：确认显存充足，完成分配。

它扫了一眼 W7900 的 48GB GDDR6 显存——DeepSeek 权重占了 28GB，KV Cache 预留了一块，剩余空间充裕。分配完毕，缓冲区就绪。随后，ROCm Runtime 把这批 Wavefront——数百个 64 线程的施工队——按序调度进 W7900 的 36 个 Compute Unit（gfx1100 的规格）。

每一个 Compute Unit 就是一条并行的生产线。36 条生产线同时开动，涌入了来自四面八方的 Wavefront。

我在这洪流里，已经认不清自己的边界。

我不再是两个字母，不再是两个 Token ID，不再是一个小小的张量。我变成了数以亿计的浮点数，分散在矩阵的每一格，由数百个 Wavefront 同步携带，向 36 个 Compute Unit 汇去。

ROCm Runtime 站在调度室里，看着这一切有条不紊地运转，没有一丝混乱。

而我，站在芯片的入口，感受到了那股热浪——

算力的洪流，正等着把我溶入其中。

下一站，也是最后一站——

Layer 1：AMD Radeon PRO W7900，整个帝国的地基，也是发电站。

第1层：AI加速芯片 —— 我溶入了算力的洪流

我到了。

数百个 Wavefront 携着我，涌进了 AMD Radeon PRO W7900（英伟达数据中心对应 H100/B200，消费级对应 RTX 4090；华为对应 Ascend 910C）的 36 个 Compute Unit（CU）。

这一刻，是我旅程的终点——也是我作为"Hi"的终点。

W7900 不是一张普通的显卡。它是 AMD RDNA3 架构下的专业计算卡，GPU 架构代号 gfx1100，搭载 48GB GDDR6 显存、384-bit 总线，是专为 AI 推理和专业计算设计的算力引擎。它的 36 个 Compute Unit 各自包含多组 SIMD（单指令多数据）向量运算单元——这些 SIMD 单元，是浮点数计算真正发生的地方。

DeepSeek-R1-Distill-Qwen-14B 的 140 亿个参数，以 FP16（16位浮点）格式存储，共约 28GB，早已整体铺展在那 48GB 显存里。这就是那座"布好阵的棋盘"——每一格都是一个权重数值，每一格都在等我。

现在我到了，棋局开始。

ROCm Runtime 把编译好的 gfx1100 机器码压入指令队列，36 个 Compute Unit 同时开机。数百个 Wavefront 分配到各自的 CU，每个 Wavefront 的 64 个线程，同时对各自负责的权重矩阵分块执行运算。我的张量——那两个 Token ID 经过嵌入层之后变成的高维向量——开始流经 DeepSeek 模型的 32 层 Transformer。

这是前向传播（Forward Pass）。

背景概念：前向传播（Forward Pass）

  • 定义： 神经网络推理时，输入数据从第一层到最后一层依次经过所有计算层，得到最终输出的过程；与训练时的反向传播（Backward Pass）相对。
  • 来历： 随神经网络理论（1940—1980 年代）发展而来，是深度学习推理的核心计算过程；Transformer 架构（2017 年）使其成为所有现代大语言模型的共同基础。
  • 价值： 推理的本质就是前向传播——没有它，模型无法生成任何输出；每次对话、每次回答，都是一次（或多次）前向传播的结果。
  • 没有它的危害： 模型只是一堆静止的权重文件，躺在磁盘上毫无生气，无法产生任何智能输出。
  • 比喻： 就像工厂按照图纸生产一件产品——原材料（输入 Token）经过每道工序（Transformer 层），最终变成成品（输出概率分布）；每道工序都不能跳过，顺序不能颠倒。
  • 优势： 只需一次前向计算即可得到推理结果，计算量远小于训练（无需反向传播和梯度更新）。
  • 劣势： 自回归生成（每次只生成一个 Token）导致长文本需要多次前向传播，延迟随生成长度线性累积。
  • 适用场景： 所有 AI 推理场景——聊天、分类、翻译、代码生成——是每一次推理调用的必经环节。

32 层 Transformer，一层一层往下走。每一层都在问：这个输入的语义是什么？它最应该注意哪些信息？下一个最合适出现的 Token，是什么？

图6 AMD Radeon PRO W7900芯片与32层Transformer前向传播

每一层，都是无数次 GEMM 矩阵乘法，都是注意力分数的计算，都是 SIMD 单元并行执行的浮点运算。我在这洪流里不断被变换、被投影、被加权、被归一化——我早已不是两个字母，也不再是两个数字，我成了遍布 28GB 权重矩阵之间的中间激活值：弥散的，无形的，在数百亿个浮点数的汪洋里流淌。

这就是 W7900 的工作——把电能转化为智能。

它的理论算力约为 45.3 TFLOPS（FP16）。每秒 45 万亿次浮点运算。就是在这个速率下，你说出的每一个字，它听懂，它思考，它给出回答。

背景概念：FLOPS（浮点运算次数/秒）

  • 定义： Floating Point Operations Per Second，每秒能执行的浮点运算次数，是衡量计算设备算力的核心指标；TFLOPS = 每秒万亿次浮点运算。
  • 来历： 随超级计算机发展而来，1970 年代开始用于衡量科学计算能力；2012 年 GPU 算力爆发后成为 AI 界的核心指标，芯片厂商每次发布新产品，TFLOPS 必是头版数字。
  • 价值： AI 推理的速度和规模直接取决于 FLOPS——算力越高，能运行的模型越大、速度越快、能服务的用户越多。
  • 没有它的危害： 没有充足的 FLOPS，大模型推理需要几分钟甚至几小时，完全无法商用，AI 对话将退化为等待漫长答卷的书信往来。
  • 比喻： 就像工厂的产能——每秒能生产多少件产品。W7900 的 45.3 TFLOPS，就是这座 AI 工厂的"每秒产能"，决定了它每天能服务多少用户、能运行多大的模型。
  • 优势： 单一数字即可量化算力，便于横向比较不同 GPU/NPU；是选型和定价的核心参考指标。
  • 劣势： 理论 FLOPS 与实际利用率之间有巨大差距（实际通常只能达到 40—80%），单看 FLOPS 容易被"标称算力"误导，需要结合访存带宽和实测吞吐量综合判断。
  • 适用场景： 选择 AI 硬件、评估推理服务能力、规划算力采购，是每一位 AI 工程师绕不开的基础常识。

就这样，在 W7900 的 36 个 Compute Unit 里，在每秒 45 万亿次浮点运算的轰鸣中，我走完了去程的最后一步。

32 层 Transformer 的最后一层，把所有计算结果汇聚成一个巨大的概率分布——15 万个 Token，每一个都对应一个分数，这是模型对"Hi"的全部理解和全部回答候选。

我把这个问题抛了出去：“在所有可能的下一个字里，哪一个才是正确答案？”

然后，我消失了。

不是死亡，是溶解。我变成了遍布显存的中间激活值，变成了那个庞大概率分布里的数字，变成了这场推理计算的最终结果——但"Hi"这两个字母，作为一个独立存在的旅行者，已经不复存在。

去程，结束了。

间奏：GPU深处——推理发生的那几秒

这一节，暂时没有"Hi"。

"Hi"已经消失了。它溶入了显存，变成了数字，变成了激活值，变成了那个庞大概率分布里无数个浮点数的其中几个——它完成了自己的使命，交出了自己的意义，然后退场了。

现在，让我们站在 W7900 外面，以旁观者的目光，看看这几秒钟里，GPU 内部究竟发生了什么。

W7900 的 48GB 显存里，140 亿个参数的权重矩阵正在苏醒。

不，“苏醒"这个词不准确——它们从未真正睡着，它们只是在等。DeepSeek-R1-Distill-Qwen-14B 的 140 亿个参数，以 FP16 格式铺满了近 28GB 的显存，每一个数值都是经过数万亿 Token 的训练凝结而成的"人类语言的压缩”。就在"Hi"以张量的形式进入的那一瞬间，这张沉默的大网被激活了。

前向传播启动。

32 层 Transformer，逐层计算。

第 1 层，"Hi"的嵌入向量进入注意力机制：Q 矩阵在问，K 矩阵在答，V 矩阵携带着语义权重。这两个 Token 的信息在 4096 维的高维空间里被投影、被旋转、被加权——那是 RoPE（旋转位置编码）在工作，它让模型知道"Hi"出现在序列的开头，而不是中间或结尾。

第 2 层，前馈网络接手：两个线性层夹着一个激活函数，把注意力层输出的信息进一步非线性变换，提炼出更抽象的语义特征。

第 3 层、第 4 层……这个过程在 36 个 Compute Unit 上并行推进，Wavefront 一批批涌进、计算、退出，显存里的 KV Cache 在悄悄积累着每一层的 Key 和 Value 矩阵，为将来可能的多轮对话做着准备。

32 层，全部走完。

最后一层 Transformer 的输出，经过一个 LM Head（语言模型头）——一个形状为 [hidden_size × vocab_size] 的巨大矩阵，把 4096 维的隐藏状态映射到 15 万个 Token 的概率分布空间。这个过程，本身又是一次 GEMM——是整个推理过程里最后一次、也是输出维度最高的矩阵乘法。

结果是一个长达 15 万维的向量，每一维对应词汇表里一个 Token，每一个数值都是模型对"这个 Token 应该出现在此刻"的原始评分——这叫 logits。

接下来，是采样。

Temperature = 0.7，Top-P = 0.9。

这两个数字，是你在 vLLM 启动参数里设定的（或者框架的默认值）。Temperature 控制随机性：0.7 意味着模型不会完全照着最高概率走，它会保留一点"创意空间"，让回答有人情味而不是机械复读；Top-P = 0.9 意味着在概率从高到低排列的 Token 里，累积到 90% 就截断，只在这个范围内采样——屏蔽了那些几乎不可能出现的词，保留合理候选。

logits 经过 softmax 转为概率，概率按 Temperature 缩放，Top-P 截断之后，采样器在这个有限的候选集里随机抓了一个。

沉默了几秒钟。

然后——

第一个 Token ID 从 logits 里被选中了。

它对应的汉字，是：“你”。

这一个字，将是回答的第一个字。它被 Tokenizer 的反向解码器翻译出来，推入 vLLM 的输出队列，经过 ROCm Runtime 的调度，穿过 HTTP 响应，回流进 ngrok 的隧道，最终出现在你 Cherry Studio 的屏幕上——以一种你几乎感受不到延迟的速度。

但现在，W7900 的显存里还没有结束。“你"只是第一个 Token。模型拿着这个"你”，把它接在"Hi"的后面，重新启动了下一轮前向传播——这一次是为了生成第二个字。

第一次前向传播生成"你"，第二次生成"好"，第三次生成"！"……

每一次，KV Cache 里的内容都在增长，已计算的 Key/Value 不需要重算，只有新 Token 的那一层需要重新过一遍网络——这就是 KV Cache 的价值所在。

而随着"你好！"这三个字逐一被生成，一个新的旅行者，正在这 48GB 的显存深处悄悄成形。

它不是"Hi"。它是回答。它是被 140 亿个参数的大脑，在 45.3 TFLOPS 的算力洪流里，从 15 万个可能性中选中、拼接、赋予意义的语言序列。

它叫——

“你好！……”

图7 Logits到采样：从原始分数到最终选词


这个新角色，将踏上返程。从 W7900 的显存深处出发，逆着"Hi"走过的所有路，穿越 ROCm Runtime、HIP C++、MIOpen、PyTorch、vLLM、Tokenizer，最终以文字的形式，重新出现在你的屏幕上。

去程结束了。

返程，即将开始。

第二章：返程——"你好！"的上行旅途

第1层：AI加速芯片 —— 我在算力的洪流中诞生

我诞生在 W7900 的显存里。

不是慢慢诞生，是一瞬间的事。32 层 Transformer 的最后一次矩阵乘法刚刚结束，LM Head 把 4096 维的隐藏状态映射到词汇表的全部维度——我就是那个结果。

我是一串数字。精确地说，我是一个长达 15 万维的向量，每一维对应词汇表里的一个 Token，每一个数值都是模型对"此刻应该选这个字"的原始评分——这叫 Logits。

我的形状大概长这样：[0.82, -1.34, 0.03, 2.17, -0.05, 0.01, ...]，一个与词汇表等长的巨大数组，绵延 15 万个数字，铺在 W7900 的显存里。

此刻我还只是一堆原始分数，还不是"你好！"三个字。就像选秀节目里评委刚打完分，原始分数还摆在桌上，还没有换算成百分比排名，不知道谁会被选中，不知道"我"会以什么形式出现在观众眼前。

我是 140 亿个参数共同决定的结果。DeepSeek-R1-Distill-Qwen-14B 的 140 亿个权重，在 36 个 Compute Unit 上并行运算了几秒钟，经历了 32 层 Transformer 的注意力机制、前馈网络、归一化……最终把所有运算的结果汇聚成我。我是整座算力工厂在这一刻的全部输出。

但我的诞生还没有完成。

我还需要经过一道关卡：Softmax。

Softmax 把我从原始评分转化为概率分布——把那些高高低低、正负不一的数字，压缩成总和为 1 的概率序列。经过 Softmax，那个位置对应"你"字的数值变成了 0.71，对应"您"字的变成了 0.09，对应"我"字的变成了 0.003……每一个 Token 都有了自己的"得票率"。

就像评委的原始分数被换算成了选票百分比——最高分的候选者概率最高，但不一定是唯一的选择。

背景概念：Logits

  • 定义： Logits 是神经网络最后一层的原始输出——一个与词汇表等长的向量，每个数值对应该 Token 被选中的原始分数（未经归一化）。
  • 来历： "logit"源于统计学中 logistic 函数的反函数（log-odds），深度学习将其借用来指代 Softmax 之前的原始输出。
  • 价值： Logits 是模型"思考结果"的原始形态，包含了对每一个可能的下一个词的评分，是生成过程的核心中间产物。
  • 没有它的危害： 没有 Logits 就没有概率分布，就无法通过采样生成文字——模型无法输出任何内容，算力的全部结果都将无处安放。
  • 比喻： 就像选秀节目评委打出的原始分数——还没有换算成百分比排名（Softmax），数字本身有高有低，但还不是最终排名；分数本身已经包含了所有的判断信息，等待下一步处理。
  • 优势： 保留了完整的概率信息，可以灵活应用不同的采样策略（Temperature、Top-P 等），为生成多样性提供了操控空间。
  • 劣势： 原始数值对人类没有直接意义，必须经过 Softmax 归一化才能解读为概率；单看 Logits，你无法直接知道哪个词被选中的概率有多高。
  • 适用场景： 所有基于 Transformer 的生成模型的最后输出层；也用于分类任务的多分类输出，是语言模型推理结果的标准格式。

然后是采样。Temperature = 0.7 把概率分布稍微"软化"了一点，让高概率的词更突出，但也给其他候选词留了一线机会；Top-P = 0.9 在概率累积到 90% 时截断，屏蔽了那些几乎不可能被选中的词。

采样器在这个有限的候选集里，随机抓了一个。

被选中的 Token ID，对应的汉字是：“你”。

然后是第二次前向传播，生成**“好”**。

然后是第三次，生成**“！”**。

三次采样，三个 Token，拼在一起，就是我——“你好！”。

现在，W7900 的显存 Output Buffer 接住了我。我以 FP16 格式整齐地躺在这里，等待被搬运出 GPU，踏上返程。

但我还没有"离开"。我只是站在 GPU 世界的出口，回头望了一眼那 36 个仍在轰鸣的 Compute Unit——

“再见了，算力的洪流。我带走了你们的结果。”

下一站，等着我的，是把我从这片算力海洋搬出去的人。

第2层：计算运行时平台 —— ROCm Runtime 把我搬出了 GPU

有人来接我了。

ROCm Runtime（英伟达对应 CUDA Runtime，华为对应 CANN Runtime）出现在 GPU 和 CPU 之间的边界上。它是整个 AI 软件栈的调度员，去程的时候是它把"Hi"送进 W7900 的，现在，它要把我从 W7900 里接出来。

这个搬运动作，有一个专有名词：hipMemcpy。

hipMemcpy(host_ptr, device_ptr, size, hipMemcpyDeviceToHost)——这行代码，启动了一次从 GPU 显存（Device Memory）到主机内存（Host Memory）的数据传输。我从 W7900 的 GDDR6 显存出发，穿越 PCIe 总线，降落在 CPU 可以访问的系统内存里。

但这次传输不是通过 CPU 中转的。

ROCm Runtime 使用了 DMA（直接内存访问）——GPU 的 DMA 引擎直接把我从显存搬到内存，不需要 CPU 亲自动手。CPU 此时正在处理别的事情，它甚至不知道我在路上。等 DMA 传输完成，它才收到一个中断信号：“货到了。”

PCIe 总线是这段旅途的高速公路。W7900 通过 PCIe 4.0 x16 接口连接到主板，理论带宽约 32 GB/s。我只是三个 Token，对应的 Logits 数据不过几百 KB，对 PCIe 来说几乎是一瞬间的事。

但从体感上说，这次搬运对我来说是一次剧烈的环境切换。

GPU 世界是极度并行的——36 个 Compute Unit，数百个 Wavefront，每秒 45 万亿次浮点运算，像一座永不停歇的大型工厂，轰鸣声震耳欲聋。CPU 世界是有序串行的——几个核心，按指令顺序执行，像一位精确的工程师，每一步都有条有理。

温度变了，节奏变了。我从炙热的并行洪流里被拎出来，降落在一个安静得多的地方。

背景概念：DMA（直接内存访问）

  • 定义： DMA（Direct Memory Access）是允许硬件设备（如 GPU）直接与系统内存交换数据，而无需经过 CPU 中转的技术；GPU 的 DMA 引擎直接负责显存与内存之间的数据搬运。
  • 来历： 1960 年代随计算机 I/O 系统发展而来；现代 GPU 通过 PCIe 接口使用 DMA 进行高速数据传输，是 GPU 计算生态的基础设施。
  • 价值： GPU 和 CPU 之间需要频繁传输大量数据；如果全部经过 CPU 中转，CPU 会成为严重瓶颈，GPU 的算力被白白浪费在等待上；DMA 让 GPU 直接"快递"数据，双方各司其职。
  • 没有它的危害： 每次 GPU 计算结果都要经过 CPU 读取、缓存、再写入内存，速度降低数十倍；在高并发推理场景下，数据传输瓶颈将直接压垮整个服务。
  • 比喻： 就像高速公路上的货运专线——货车（数据）不用在每个收费站都停下来让人手工清点货物，而是走专用通道直接到达目的地；收费站（CPU）在货车到达后才收到通知，不需要全程盯着。
  • 优势： 数据传输速度快，CPU 不参与搬运，双方可以并行工作，大幅提升整体吞吐量。
  • 劣势： DMA 传输需要预先锁定内存（pinned memory），占用的物理内存不能被操作系统换出；配置不当可能导致内存紧张，影响系统稳定性。
  • 适用场景： GPU/CPU 之间的大批量数据传输；网卡、硬盘等高速 I/O 设备；是现代 AI 推理服务器的标准数据通路。

ROCm Runtime 确认传输完成，在日志里悄悄记了一笔，然后把控制权交给了上层。

我现在在主机内存里，还是 FP16 格式，还是一串 Logits——但我已经不在 GPU 世界了。

下一站，有人要给我"整理行装"。

第3层：GPU/NPU 编程接口 —— 整理行装，准备上路

这一层，我几乎是一闪而过的。

HIP C++ 的内存管理 API（对应英伟达的 CUDA，是 AMD 的 GPU 编程接口）在这里做了一件小事：格式整理。

hipMemcpy 已经完成了物理上的搬运，把我从 GPU 显存搬到了主机内存。现在，HIP C++ 的运行时库要把我从 GPU 世界的 FP16 数据布局，整理成 CPU 和上层框架能够直接理解的内存格式——对齐、类型转换、缓冲区管理，这些操作对我来说几乎是瞬间完成的，但它们是必须的。

这是一道短暂的**“格式海关”**。

你如果还记得去程，会觉得这里有一种对称的美感：

去程，HIP C++ 负责写 Kernel——定义矩阵乘法怎么做、Wavefront 怎么分配、SIMD 怎么并行——那是"道路施工规范"，规定了工厂里的工人怎么工作；

返程，HIP C++ 负责把成品从工厂搬出来——hipMemcpy、内存格式转换、缓冲区交接——那是"出厂质检"，确保产品以正确的格式交到下一道工序手里。

一进一出，一写一读，HIP C++ 在去程和返程各自完成了它的使命。

整理完毕。我现在是一批干净的、格式规整的 Token Logits，躺在主机内存的缓冲区里，等待上层软件来读取我、处理我。

此刻，我还只是数字，还不是文字。

但我已经出了 GPU，已经越过了芯片的边界，已经站在了一个更广阔的世界的入口。

下一站，Layer 4——MIOpen 的采样算子，会把我这堆 Logits，变成一个真正被选中的 Token ID。

那才是"你好！"从数字变成意义的第一步。

第4层：深度学习加速库 —— 我被"定型"了

轮到我了。

Composable Kernel 的采样算子登场。它是 AMD ROCm 软件栈里专门为深度学习定制的高性能算子库（对应英伟达的 cuDNN，但 AMD 的 Composable Kernel 更强调可组合性和可移植性），去程中，MIOpen 用它加速"理解"——矩阵乘法、注意力计算、激活函数；现在，返程里，它要用来加速"选词"。

第一道工序：Temperature Scaling。

那批 Logits 里，15 万个原始分数，被整体除以一个数：0.7。

这个 0.7，就是 Temperature——温度系数。

你如果把每一个 Logits 数值都除以 0.7，会发生什么？高分的变得更高，低分的变得更低——概率分布被"拉伸"了，尖锐了。这意味着模型会更倾向于选择它认为最合适的那个词，但又不像 Temperature = 0 时那样绝对地每次都选第一名；0.7 留了一点"弹性空间"，让回答有人情味。

然后是 Softmax。处理过 Temperature 的 Logits 经过 Softmax，变成了概率分布——总和为 1 的 15 万个数字。

第二道工序：Top-P（Nucleus）Sampling。

Composable Kernel 把这 15 万个概率从高到低排列，然后从头开始累加：加到累计概率超过 90% 时停下。超过这条线之后的所有 Token，全部被排除在候选之外——那些极低概率的词，那些几乎不可能出现的字，就这样被礼貌地挡在门外了。

剩下的，就是"候选池"：也许只有几十个词，也许有几百个——取决于这一刻的概率分布是否集中。

采样器在候选池里随机抓了一个。

Token ID 被选中了。

它对应的汉字，是：“你”。

这不是结束。这是自回归生成节奏里的第一拍。

自回归，意味着：生成一个 Token，不等于生成了全部答案——它意味着，以"Hi"+"你"为新的输入，重新触发一次完整的前向传播（回到 Layer 1 的 W7900，回到 Layer 2 的 ROCm Runtime，回到 Layer 3 的 HIP C++，回到此刻的 Layer 4）来生成下一个 Token。

第二次采样，生成：“好”。

第三次采样，生成：“！”。

三次，三拍，三个 Token。每一拍都是完整的一轮，从 GPU 的矩阵运算到采样器的最终裁定，没有捷径，没有跳步。

但正是这种节奏，让语言的生成有了呼吸感。

背景概念：Temperature（温度参数）

  • 定义： Temperature 是控制大模型输出随机性的超参数，通过将 Logits 除以温度系数来调节概率分布的"尖锐程度"；Temperature 越低，概率最高的词被选中的可能性越大（越确定）；Temperature 越高，各词的概率差距缩小（越随机）。
  • 来历： 借用自统计物理学中的玻尔兹曼分布（Boltzmann distribution），其中温度控制粒子的能量分布；深度学习在 2010 年代将其引入文本生成采样。
  • 价值： 让用户和开发者能灵活控制输出风格——需要精确回答时用低 Temperature，需要创意写作时用高 Temperature。
  • 没有它的危害： 模型总是选择概率最高的词（贪心解码），输出千篇一律，缺乏多样性；或者随机性过高，生成胡言乱语。
  • 比喻： 就像厨师炒菜时的调味松紧度——Temperature = 0 时像机器精确按配方，每次都一样；Temperature = 1 时有发挥空间，每次略有不同；Temperature = 2 时如同醉酒厨师，随意发挥，结果难以预测。
  • 优势： 简单有效，单一参数控制随机性，直觉上容易理解和调节。
  • 劣势： 需要调参才能找到最佳值；过高容易生成不连贯内容，过低容易生成重复内容。
  • 适用场景： 创意写作（高 Temperature）、事实问答（低 Temperature）、代码生成（接近 0）。

背景概念：Top-P Sampling（Nucleus Sampling）

  • 定义： 从累计概率超过 P 的最小 Token 集合中随机采样；比如 Top-P = 0.9，表示只从概率前 90% 的 Token 中选择，忽略长尾低概率词。
  • 来历： 2019 年由 Holtzman 等人在论文《The Curious Case of Neural Text Degeneration》中提出，解决了 Top-K 采样固定候选数的问题。
  • 价值： 既保留了高质量候选词，又避免了总是选最高概率词导致的重复和无聊；动态调整候选集大小，适应不同上下文。
  • 没有它的危害： 纯贪心解码（总选最高概率词）导致输出死板重复；纯随机采样导致胡言乱语。
  • 比喻： 就像从最优秀的候选人中随机挑选——先把所有候选人按能力排名，只保留能力累计覆盖 90% 的前 N 名，然后从这 N 人中随机选一个；既排除了"奇葩选手"，又不是总选第一名。
  • 优势： 动态调整候选集大小，适应不同上下文的概率分布；输出质量和多样性兼顾。
  • 劣势： 实现比 Top-K 稍复杂；P 值也需要调参。
  • 适用场景： 几乎所有生产级 LLM 推理，是现代大模型的默认采样策略。

三个 Token 都有了 Token ID，三个汉字都已定型。

Composable Kernel 完成了它的使命，退场了。

接下来，有人要把这些 Token ID 还原成人类认识的文字。

第5层：AI框架 —— 我从数字重新变成了文字

我还是一串数字。

精确地说，我是三个 Token ID——对应"你"、“好”、"！"的编号，在 DeepSeek 词汇表里各有各的座位号，整整齐齐地排在内存缓冲区里，等待被翻译。

PyTorch（ROCm 平台）的 tokenizer 模块走了过来。

它做的事情，叫做 tokenizer.decode()。

这是去程时 tokenizer.encode() 的镜像操作——去程里，Cherry Studio 发出的"Hi"在 Layer 7 被分词器切割成 Token ID，送进了模型；现在，模型生成的 Token ID，在这里被分词器的解码器逆向映射回文字。

一个方向进去，一个方向出来。入口和出口，共用同一张地图。

[13990, 106, ...] → “你好！”

我从数字重新变成了文字。

这一刻，对我来说意义重大——不是因为技术有多复杂，而是因为这完成了一次完美的对称：去程 Layer 7，“Hi"变成了数字；返程 Layer 5，数字变回了"你好！”。入口和出口在不同的层，但它们用的是同一把钥匙。

但变成文字，不等于立刻被发送出去。

这里有一个关键的决定：Streaming（流式输出）。

vLLM 不会等到所有文字都生成完毕之后才统一发送——它不是一个"写完了再寄"的快递员，而是一个"写一个字寄一个字"的即时通讯员。每生成一个 Token，PyTorch 的 tokenizer 解码出对应的文字，vLLM 就立刻把它推入输出队列，不等下一个。

"你"出来了，立刻推。

"好"出来了，立刻推。

"！"出来了，立刻推。

用户看到的效果，是文字在屏幕上逐字出现——像是有人在实时打字，而不是等了几十秒之后突然冒出一段话。这个打字机效果，是 Streaming 模式的用户体验本质。

但 Streaming 也意味着，每一个 Token 的生成都要完整走一遍自回归的循环：前向传播 → 采样 → 解码 → 推送。"你好！"三个字，就是三次完整的循环。每一次循环，都从 Layer 1 的 W7900 出发，走到此刻的 Layer 5，然后被推出去，再回到 Layer 1 开始下一轮。

PyTorch 是整个 AI 框架层的核心——它调度张量运算，管理 ROCm 平台，衔接上下层；而此刻在返程里，它最关键的贡献是这个 tokenizer.decode()，把模型的"机器语言"翻译回人类的文字。

背景概念：Streaming（流式输出）

  • 定义： 推理引擎逐 Token 生成并实时推送给客户端，用户看到文字逐字出现的效果，而非等全部生成完再显示。
  • 来历： 随大模型商业化（2022—2023 年）快速普及；技术基础是 HTTP 的分块传输编码（Chunked Transfer）和 Server-Sent Events。
  • 价值： 大幅改善用户体验——用户不需要等 30 秒才看到回复，而是从第 1 个字开始就有反馈；心理上感觉更快，焦虑感大幅降低。
  • 没有它的危害： 用户需要盯着空白对话框等待数秒乃至数十秒，体验极差；长回复在网络不稳定时若全部生成完才发送，一旦中断前功尽弃。
  • 比喻： 就像自来水——不是等水箱装满了再打开阀门，而是边接边用；水龙头（vLLM）打开的那一刻，水（文字）就开始流了。
  • 优势： 显著提升感知速度，用户体验好；长回复部分失败时已有内容不丢失。
  • 劣势： 实现复杂，需要客户端和服务端都支持流式协议；错误处理更复杂，中间断流的恢复逻辑需要额外设计。
  • 适用场景： 所有面向用户的 LLM 对话服务（ChatGPT、Claude 等均采用），是现代 AI 产品的标配能力。

“你好！”，以文字的形态，进入了输出队列。

图8 流式输出打字机效果


下一站，负责把我打包上路的，是 Layer 6。

第6层：推理服务框架 —— 快递公司把我打包上路

我终于要离开这台服务器了。

vLLM（英伟达生态同样使用 vLLM，它是推理框架层最流行的选择之一）站在 Layer 6，是整个返程里最后一道"打包关口"。去程时，vLLM 是快递公司的前台——接单、验货、调度；返程时，vLLM 是快递公司的后台——打包、贴单、发货。

它要做的第一件事，是把我包装成标准格式：SSE（Server-Sent Events）。

每生成一个 Token，vLLM 就构造一个这样的事件块：

data: {"id":"chatcmpl-xxx","object":"chat.completion.chunk","choices":[{"delta":{"content":"你"},"index":0}]}
data: {"id":"chatcmpl-xxx","object":"chat.completion.chunk","choices":[{"delta":{"content":"好"},"index":0}]}
data: {"id":"chatcmpl-xxx","object":"chat.completion.chunk","choices":[{"delta":{"content":"！"},"index":0}]}
data: [DONE]

每一个 data: 开头的行，是一个独立的 SSE 事件块；每两个换行之间，是一个独立的推送单元。这是 W3C 制定的标准格式，Cherry Studio 这样的客户端天生能读懂它——它知道，每收到一个 data: 块，就从 delta.content 里取出文字，显示在屏幕上。

打字机效果，就这样一帧一帧地被推动。

然后，vLLM 把这些 SSE 事件块，通过一条已建立的 HTTP 长连接，实时发送出去。

连接的另一端，是 ngrok 的隧道。

你还记得去程吗？Cherry Studio 在你的本地 Mac 上，通过 ngrok 生成的那个 https://xxxx.ngrok.io 公网地址，把请求发到了云端这台服务器。那条 ngrok 隧道，去程时是"入境通道"；现在，返程时，它是"出境通道"——同一条隧道，双向通行，全程 HTTPS 加密。

云端 vLLM → ngrok 隧道 → 公网 → 本地 Mac → Cherry Studio

这是我最后一段路的路线图。

vLLM 不只是在打包发货，它还在做另一件事：管理 KV Cache。

这次对话的上下文——"Hi"的 Token ID、前向传播中每一层的 Key 和 Value 矩阵——被 vLLM 妥善保存在显存的 KV Cache 里。这是为了：如果你发来下一条消息，vLLM 不需要把之前的对话全部重新计算，只需要在已有的 KV Cache 基础上，增量计算新的 Token。

这就是为什么多轮对话不会越来越慢的秘密——KV Cache 在暗处，帮你省掉了大量重复计算。

背景概念：Server-Sent Events（SSE）

  • 定义： 一种基于 HTTP 的单向实时推送技术，服务器可以持续向客户端发送事件数据流，而不需要客户端反复请求；每个事件以 data: 开头，以双换行结束。
  • 来历： W3C 于 2006 年提出，HTML5 标准化；在 LLM 流式输出场景（2022 年后）获得大规模应用，成为 OpenAI 兼容 API 的流式传输标准。
  • 价值： 让 LLM 推理引擎能逐 Token 实时推送文字给客户端，实现打字机效果，极大提升用户的等待体验。
  • 没有它的危害： 只能用轮询（客户端每隔几百毫秒问一次"生成完了吗？"），效率极低，延迟高，服务器压力大，用户体验差。
  • 比喻： 就像电台持续广播——电台（vLLM）不停地播送最新内容，收音机（Cherry Studio）只需要调好频道、打开就能实时收听，不需要每隔几秒问一次"有新节目吗？"
  • 优势： 实现简单（基于标准 HTTP），浏览器和主流 HTTP 客户端原生支持，服务器推送效率高，无需维护 WebSocket 那样的双向连接。
  • 劣势： 单向推送（服务器→客户端），客户端无法通过同一连接反向发送数据；连接中断后需要客户端自行实现重连逻辑。
  • 适用场景： LLM 流式文字输出、实时通知推送、股票行情等单向实时数据流场景；是所有主流 LLM API 的流式传输首选方案。

最后一个 SSE 事件块，data: [DONE]，被推送出去了。

vLLM 在日志里记了一行：请求完成，耗时若干毫秒，生成 Token 数若干，吞吐量若干。然后，它转向下一个等待的请求，继续它的工作。

我，穿过 ngrok 的隧道，正在公网上飞奔。

云端的这一切——W7900 的 36 个 Compute Unit、ROCm Runtime 的调度室、HIP C++ 的格式海关、Composable Kernel 的采样算子、PyTorch 的解码器、vLLM 的打包台——全部留在了身后。

前方，还有两站：Layer 7（分词器，但这次是反向，已在 Layer 5 完成）和 Layer 8（Cherry Studio，你屏幕上的那个输入框）。

我以 SSE 数据流的形态，带着"你好！"三个字的全部信息，穿越公网，奔向你。

第7层：开源大模型 —— 我就是DeepSeek的思想

我要在这里停一停。

不是因为疲惫，而是因为这一层，和其他所有层都不一样。

其他层是管道——它们传输我、搬运我、格式化我、打包我。但这一层，是我来自哪里的答案。

我不是凭空出现的。那三个汉字——“你好！”——不是随机生成的噪音，不是数学运算的偶然结果，而是DeepSeek-R1-Distill-Qwen-14B 的 140 亿个参数共同决定的。那 140 亿个数字，每一个都是从人类书写的语料里蒸馏出来的——无数篇文章、无数段对话、无数本书，被压缩、提炼、凝结进这 28GB 的权重矩阵里。

我，是这份提炼的结果。

但 DeepSeek-R1-Distill-Qwen-14B 不是凭空诞生的，它本身也是一次蒸馏。

满血的 DeepSeek-R1 有6710 亿个参数，是一位见过世面的大厨，掌握了几乎所有人类语言的烹饪手艺。而 DeepSeek-R1-Distill-Qwen-14B——我真正的父亲——只有 140 亿参数，是那位大厨倾囊相授的年轻弟子。蒸馏的过程，是老师把最核心的手艺传给学生：不是死记硬背所有配方，而是真正理解火候与味道的内在逻辑。

那位弟子，掌握了师父最重要的那件事：思考。

你也许注意到，DeepSeek-R1 的回答里，常常有一个 <think>...</think> 的标签——那里面，是模型在给出最终答案之前走过的推理路径。这叫 Chain-of-Thought（思维链）。

即使是"Hi"这么简单的输入，R1 的内部也经历了一个推理过程：这是一个英文问候，对方可能是用中文或英文的人，最合适的回应是什么？应该简洁还是详细？……当然，对于"Hi"，这个推理过程短到几乎可以忽略。但对于数学题、代码问题、逻辑推理——思维链的价值就会显现：它让模型一步步写出推导过程，而不是直接跳到答案，错误无处藏身，推理变得可追踪、可审查。

背景概念：Chain-of-Thought（思维链）

  • 定义： 一种让大模型在给出最终答案前，先输出中间推理步骤的技术；R1 模型会在 <think>...</think> 标签内展示推理过程，然后再给出最终答案。
  • 来历： 2022 年由 Google Brain 的 Wei 等人在论文《Chain-of-Thought Prompting Elicits Reasoning in Large Language Models》中提出；DeepSeek-R1 将其进化为通过强化学习自然涌现的能力，不再需要人工构造推理示例。
  • 价值： 大幅提升模型在数学、逻辑、编程等复杂推理任务上的准确率；让模型的推理过程可审查、可调试，错误有据可查。
  • 没有它的危害： 模型直接给出最终答案而不展示推理，在复杂问题上容易出错；错误难以被发现和纠正，用户无从判断答案是真懂还是瞎猜。
  • 比喻： 就像解数学题时写出每一步计算过程，而不是直接写结果——过程展示让错误无处隐藏，也让读者能跟上思路；只写答案的学生，老师不知道他是真懂还是蒙对的。
  • 优势： 显著提升推理任务准确率；推理过程可解释，便于调试和优化；强化学习版本（R1）无需人工标注推理步骤即可涌现。
  • 劣势： 输出更长，消耗更多 Token，推理成本更高；对于简单问题（如"Hi"）有些大材小用，思考的开销超过了问题本身的复杂度。
  • 适用场景： 数学解题、逻辑推理、代码生成、科学问题分析等需要多步推理的任务；是 DeepSeek-R1 系列模型最核心的能力标志。

我，就是这种思考能力在这一刻的体现。

还有一件事，值得在这里说清楚：DeepSeek 是开源的。

它的权重文件，任何人都可以下载；它的模型架构，任何人都可以研究；它的推理代码，任何人都可以修改。这意味着，你——是的，就是你，坐在屏幕前的你——可以把它部署在自己的 GPU 上。就像你现在用那台 AMD W7900 做的这件事一样。

这是开源的真正意义：不是"免费"，而是自主。你不依赖某家公司的服务器，不受某个 API 的调用限制，不把你的对话内容发送给任何第三方——你拥有整座工厂，从芯片到模型，从软件到数据，全部在你的掌控之内。

我，是那座工厂今天生产的第一件产品。

现在，我继续上路。

第8层：API调用方 —— 我出现在你的屏幕上了

我到了。

ngrok 的隧道把我从云端带回到了你的本地 Mac，HTTP 长连接还没有断开，SSE 事件流还在一帧一帧地推送。现在，接住我的，是 Cherry Studio。

Cherry Studio 的前端代码，一直在监听那条 SSE 连接。它知道规则：每收到一个 data: 事件块，就从 delta.content 字段里取出文字，立刻追加到对话气泡里，不等下一个。

第一个 data: 块到达——

"你"，出现在气泡里。

第二个 data: 块到达——

"好"，追加在"你"的后面。

第三个 data: 块到达——

"！"，追加在"好"的后面。

data: [DONE]——流结束，气泡定型。

你的屏幕上，完整地出现了：你好！

这个过程，在体感上几乎是瞬间发生的。每一个字的出现，都像是有人在实时打字——这就是 Streaming 模式给你的幻觉，也是 Cherry Studio 和 vLLM 联手给你的礼物。

但我知道那不是幻觉。那是真实的数据在真实的网络里、以真实的物理速度传输的结果。

从你按下发送键，到你看见第一个字"你"，中间经历了多长时间？

这段时间，有一个名字：TTFT——Time To First Token，首 Token 延迟。它是整个旅程的"往返时延"（RTT）里，用户体感最敏感的那一段——不是总耗时，而是"我发出去，多久能看到第一个字"。

背景概念：RTT（往返时延）与 TTFT（首 Token 延迟）

  • 定义： RTT（Round-Trip Time，往返时延）是从发送方发出请求到收到响应的总时间；在 LLM 推理场景中，通常更关注 TTFT（Time To First Token，首 Token 延迟）——从发送请求到看到第一个字的时间，它是用户体感最直接的延迟指标。
  • 来历： RTT 是网络工程的基础指标，1970 年代随 TCP/IP 协议发展而来；TTFT 是 LLM 推理服务的专属指标，2022 年后随大模型商业化而被广泛使用，成为评估推理服务质量的核心 SLA 指标之一。
  • 价值： 直接决定用户体验——TTFT 越低，用户感觉越流畅，等待焦虑越少，就越愿意使用；工程师优化推理服务，TTFT 是第一个要盯住的数字。
  • 没有它的危害： 如果不关注 RTT/TTFT，工程师只优化吞吐量而忽视延迟，用户等待第一个字要数十秒，体验极差——即使模型最终给出了完美答案，用户早已失去耐心。
  • 比喻： 就像从寄信到收到回信的时间——你寄出信（发送"Hi"），到邮递员把回信的第一行字塞进你的信箱（看到第一个字"你"），这段时间就是 TTFT；越短，通信越及时，越让人安心。
  • 优势： 单一数字量化端到端体验，便于定位瓶颈（是网络延迟慢？还是推理本身慢？还是模型加载慢？）；是用户体验优化的抓手。
  • 劣势： RTT 受网络状况影响大，同一服务在不同地点测量值差异显著；TTFT 也受并发负载影响，高并发时排队等待会让 TTFT 显著拉长。
  • 适用场景： 网络性能评估、LLM 推理服务质量监控、用户体验优化、推理服务 SLA 制定；是每一位 AI 工程师在上线新服务前必须测量的基线指标。

在你的这套部署里，那个 TTFT 大约是几秒钟。

算上网络传输（本地 Mac → ngrok 公网服务器 → 云端服务器，再原路返回），算上模型加载后的推理延迟，算上 Token 生成的每一轮循环——几秒钟，是这整座帝国从接到命令到交出第一个字的完整响应时间。

几秒钟，不算慢。

考虑到你的"Hi"在这几秒里穿越了 8 层——从 Cherry Studio 的输入框，到 W7900 的 36 个 Compute Unit，再原路爬上来——这几秒钟，是整座 AI 算力帝国运转了一次的代价，也是它能给出的最快答案。

我终于抵达了。

两个字母的"Hi"换来了一声"你好！"——这不只是一次问候，这是整座 AI 算力帝国运转了一次的证明。

尾章：一次"Hi"和"你好！"的意义

"Hi"走完了。

"你好！"也走完了。

两个旅行者，一个向下，一个向上，在 8 层之间相向而行，在这个普通的下午，共同完成了一次完整的问候。

回头望去，那 8 层各自站在原位，默默地等待下一次被需要：

没有 W7900（Layer 1），一切只是空谈——没有芯片，算力是零，所有的软件都是空壳。

没有 ROCm Runtime（Layer 2），GPU 无法被调度——有了工厂，却没有厂长，机器只能空转。

没有 HIP C++（Layer 3），Kernel 无法运行——有了厂长，却没有施工图纸，工人不知道怎么干活。

没有 MIOpen 与 Composable Kernel（Layer 4），运算无法加速——有了图纸，却用最低效的方式施工，速度慢到无法商用。

没有 PyTorch（Layer 5），数据无法成为张量，Token 无法被解码——有了建材，却没有把建材运到工地的货车，什么都运不起来。

没有 vLLM（Layer 6），模型只是死文件——有了货车，却没有快递系统，用户无法收到货物。

没有 DeepSeek（Layer 7），算力没有灵魂——有了所有的管道，却没有任何值得传输的内容，整座帝国轰鸣着，却什么也不生产。

没有 Cherry Studio（Layer 8），用户永远无法触达——一切发生在黑暗里，没有屏幕，没有界面，再精彩的回答也只是显存里的数字，没有人看见。

8 层，缺一不可。

如果把这 8 层比作一座城市：

W7900 是土地，是一切存在的物质基础；ROCm Runtime 是道路，让一切能够流动；HIP C++ 是建筑规范，让工程师有章可循；MIOpen 是建材的工厂，把原料变成高效的构件；PyTorch 是货运系统，在城市里搬运一切；vLLM 是快递网络，把货物精准送到每家门口；DeepSeek 是这座城市生产的货物本身，是它存在的理由；而 Cherry Studio，是走进这座城市的市民——没有市民，城市只是一片空旷的建筑群，再宏伟也只是废墟。

你，就是那位市民。

下次你打开 Cherry Studio，在输入框里敲下任何一句话——哪怕只是一个"Hi"——记得，你的这一击，将触发这整座帝国的一次全力运转。8 层电路、8 套软件、8 种协议，全部为你一个人的问候而启动，全部在你等待的这几秒里默默完成它们的使命，然后把答案送回你的屏幕。

它们不会说话，它们不会鞠躬，它们不需要掌声。

但它们在。

每一次，都在。

附录：英伟达/AMD/华为的AI算力帝国

下述AI算力帝国的8层架构，越往上越靠近用户。括号内用斜线分隔英伟达 / AMD / 华为的对应技术。

AI 世界对应物（英伟达 / AMD / 华为） 作用 用城市组件进行比喻
API 调用方（Cherry Studio · OpenCode · 你的AI应用程序） Cherry Studio、OpenCode 等客户端或你自己开发的 AI 应用程序是 AI 服务的最终消费者，它们通过 HTTP/gRPC 等协议向推理服务框架发送请求，获取模型生成的文字、代码或多模态内容。表面上是"发消息、收回复"，背后意义是让普通人无需了解任何 AI 底层技术就能享受智能服务，是整个 AI 算力帝国商业价值的最终体现。它依赖下方的推理服务框架提供稳定、低延迟的 API 接口才能正常运作。 市民（城市居民）——城市里的市民每天使用超市、餐馆、快递等各种服务，无需关心背后的供应链与基础设施。同样，API 调用方只需发送一条文字消息，便能收到 AI 的智能回复。市民是整座城市存在的终极意义：没有市民，城市的一切基础设施都毫无价值。市民的需求完全依赖快递公司（推理框架）将商品及时送到门口，市民的旺盛需求也反过来激励着整座城市持续建设与优化。
开源大模型（Llama-3.x · Qwen-2.5 · DeepSeek-R1） Llama-3.x、Qwen-2.5、DeepSeek-R1 等开源大模型是 AI 系统的知识载体与推理引擎，以数十亿至数千亿参数的权重文件形式，将人类知识浓缩成可计算的数字矩阵。表面上是"一堆数字文件"，背后意义是人类智识的数字化蒸馏——每次推理都是对海量训练数据的即时检索与创造性重组。它依赖下方的推理服务框架将参数加载到 GPU 显存并高效执行，同时为上方的 API 调用方提供语言理解与内容生成的核心能力。 仓库中的货物（商品）——城市仓库里存放着维持城市运转所需的一切商品：粮食、药品、工具，每件商品都凝聚着生产者的劳动与知识。大模型正是这些货物：承载着巨大的知识价值，静静等待被"取用"。货物本身不会主动送达用户，必须依托快递公司（推理框架）完成"最后一公里"的配送；而货物的质量与种类，直接决定了市民（API 调用方）最终能获得什么样的服务体验。
推理服务框架（TensorRT-LLM / vLLM · SGLang（ROCm 平台） / MindIE） TensorRT-LLM（英伟达）、vLLM 与 SGLang（AMD ROCm 平台，2026 年 Q2 路线图已对齐 MI300X/MI350X 的 Day-0 支持）、MindIE（华为）是将大模型从静态权重文件变为在线服务的关键中间层。它们通过 KV 缓存复用、连续批处理（Continuous Batching）、投机解码（Speculative Decoding）等技术，使单张 GPU 每秒能处理数十至数百个并发请求。表面上是"把模型跑起来"，背后意义是在有限算力下最大化吞吐量、最小化首字延迟（TTFT），直接决定 AI 服务的用户体验与商业可行性。它依赖下方的 AI 框架（PyTorch/MindSpore）提供张量计算图执行能力，向上方的 API 调用方暴露 OpenAI 兼容的 REST 接口。 快递公司（智能物流调度中心）——顺丰、京东物流这样的快递公司，不只是简单地搬运货物，而是通过智能路由、分拣自动化、运力动态调度，让一辆快递车在一天内完成数百次配送。推理框架正是如此：它将大模型"装上车"（加载权重到显存），通过 KV 缓存复用、批处理等调度技术，让一块 GPU 同时服务数百个用户。快递公司依赖货运汽车（AI 框架）来实际运输货物，也依赖道路系统（运行时平台）保障车辆能顺畅上路；同时，它向市民（API 调用方）提供"一键下单、门口收货"的无感体验。
AI 框架（PyTorch（CUDA） / PyTorch（ROCm） / MindSpore） PyTorch（英伟达 CUDA 平台 / AMD ROCm 平台）与 MindSpore（华为）是构建、训练和执行深度学习模型的核心引擎。它们提供自动微分（Autograd）、动态计算图、分布式训练等能力，将数学公式翻译成 GPU/NPU 能并行执行的张量操作序列。表面上是"深度学习编程框架"，背后意义是抹平硬件差异、统一开发者心智模型的关键抽象层——工程师用同一套 Python API，即可在英伟达、AMD 或华为的硬件上训练和运行同一个模型。它依赖下方的深度学习加速库（cuDNN/MIOpen/CANN 算子库）执行高性能底层核函数，向上方的推理服务框架提供模型加载、前向推理等基础算子能力。 货运汽车（多路况运输工具）——货车是现代物流的核心运输工具：它不仅能装载各种货物（模型权重与训练数据），还内置导航、油耗管理、载重监控等智能系统（对应自动微分引擎、内存管理、分布式通信）。同一款货车既能在沥青高速公路（CUDA）上高速行驶，也能在铺设较新的路面（ROCm）上稳定运行，体现了跨平台兼容的核心价值。货车依赖优质的道路基础设施零件（深度学习加速库）确保引擎与传动系统高效运转；同时，它承载着货物（大模型），为快递公司（推理框架）提供可靠的运力支撑。
深度学习加速库（cuDNN · FlashAttention / MIOpen · Composable Kernel / CANN 算子库） cuDNN 与 FlashAttention（英伟达）、MIOpen 与 Composable Kernel（AMD）、CANN 算子库（华为）是将数学运算转化为极致优化 GPU/NPU 机器码的专用库。它们针对卷积、矩阵乘法（GEMM）、注意力机制（Attention）等神经网络核心运算提供手工调优的底层核函数（Kernel），性能远超编译器自动生成的通用代码。表面上是"一批高性能数学库"，背后意义是将理论算力转化为实际吞吐量的关键桥梁——同样的 GPU，有无 FlashAttention 可带来数倍的 Transformer 推理性能差距。它依赖下方的 GPU/NPU 编程接口（CUDA C++ / HIP C++ / AscendCL）进行底层核函数调用与线程调度，向上方的 AI 框架提供即插即用的高速算子加速能力。 道路基础建材与工程工艺（沥青、预应力混凝土、桥梁设计）——高质量的路面材料和施工工艺，决定了道路能承载多大的车速与载重。深度学习加速库正是 AI 计算"高速公路"的核心建材：FlashAttention 通过重排注意力计算的访存顺序，如同优化道路弯道曲率与坡度设计，让计算车辆（张量运算）以极高速度安全通过瓶颈路段。这些建材的质量依赖交通法规与建设标准（编程接口）的约束与规范，同时为货运汽车（AI 框架）铺就高性能的行驶路面，使其充分发挥引擎潜力。
GPU/NPU 编程接口（CUDA C++ / HIP C++ / AscendCL） CUDA C++（英伟达）、HIP C++（AMD，与 CUDA 语法高度兼容，使英伟达生态代码可低成本迁移至 AMD 平台）、AscendCL（华为）是开发者直接操控 GPU/NPU 并行计算硬件的编程语言与 API 体系。它们定义了如何在设备上分配显存、启动并行核函数（Kernel）、管理线程块（Thread Block）与波前（Wavefront）的执行粒度。表面上是"底层编程接口"，背后意义是让软件工程师能以接近硬件极限的方式编排数万个并行计算单元，将 GPU 从图形渲染专用芯片转变为通用大规模并行计算平台。它依赖下方的计算运行时平台实际调度和执行核函数，向上方的深度学习加速库提供精细的硬件控制能力，使库开发者能编写出极致优化的底层算子。 城市交通法规与道路建设标准——交通规则（限速、行驶方向、信号灯协议）和建设规范（路面承重标准、施工工序）定义了所有道路参与者与建设者必须遵守的行为准则。CUDA/HIP/AscendCL 正是 AI 计算世界的"道路法典与施工规范"：工程师按照这套规则编写核函数代码，如同道路工程师按照国标施工；违反规则（越界访问显存、数据竞争）会引发"交通事故"（程序崩溃或结果错误）。这套法规依赖道路系统（运行时平台）来执法与实际调度，同时为道路建设者（加速库开发者）提供统一的施工规范与验收标准。
计算运行时平台（CUDA Runtime+驱动 / ROCm Runtime（v7.2.4） / CANN Runtime） CUDA Runtime+驱动（英伟达）、ROCm Runtime v7.2.4（AMD，2026 年 5 月 29 日发布稳定版，专注于 AI 推理性能与稳定性优化）、CANN Runtime（华为）是连接软件栈与物理芯片的操作系统级平台。它们负责 GPU/NPU 设备的初始化与枚举、显存的分配与回收、核函数的 JIT 编译与硬件调度、多 GPU 通信协调（NCCL/RCCL）等底层资源管理工作。表面上是"驱动程序和运行时库"，背后意义是构建一个对上层软件屏蔽硬件复杂性的虚拟化层——开发者无需了解 GPU 内部的 SM/CU 调度细节，运行时会自动优化资源利用率与并发度。它依赖下方的 AI 加速芯片（物理硬件）提供原始算力，向上方的 GPU/NPU 编程接口（CUDA/HIP/AscendCL）暴露统一的设备管理与执行 API。 城市路网与交通管理中心——城市路网不只是铺好的沥青路面，还包括一座实时运转的交通管理中心：监控哪条路段拥堵、动态分流车辆、在事故时启用应急通道。ROCm Runtime 正是 AMD GPU 的"交通管理大脑"：它管理着全部计算资源的实时调度，在多进程争抢 GPU 时动态分配算力时间片，在显存告急时触发内存压缩与任务抢占。路网与管理中心必须建立在坚实的土地和发电站（AI 加速芯片）之上，同时为交通法规的执行提供实际的物理路面与管控基础设施，使上层的编程接口调用能够落地为真实的硬件操作。
AI 加速芯片（A100·H100·H200·B200（数据中心GPU）· RTX PRO 6000 Blackwell（工作站GPU）· RTX 4090·5090（消费级GPU）/ MI300X·MI350X（数据中心GPU）·W7900（工作站GPU）/ Ascend 910C·950PR（NPU）） 英伟达（A100→H100→H200→B200，数据中心；RTX PRO 6000 Blackwell，工作站；RTX 4090/5090，消费级）、AMD（MI300X/MI350X，数据中心，MI350X 于 2025 年 6 月量产，提供 288GB HBM3e 与 4 倍上代 AI 算力；W7900，工作站）、华为（Ascend 910C，FP16 约 800 TFLOPS，2026 年计划产能 60 万片；Ascend 950PR，2026 年 Q1 发布，128GB 自研 HiBL 1.0 存储、1.6 TB/s 带宽）是整个 AI 算力帝国的物质基础。B200 拥有 192 GB HBM3e、8 TB/s 带宽与 20 PetaFLOPS FP4 算力。表面上是"一块芯片"，背后意义是将电能转化为智能的核心装置——没有它，任何软件栈都只是空中楼阁。它是整个架构的最底层，无需依赖更低的基础，向上方的计算运行时平台持续提供数以千计的并行计算单元与高速片上显存。 土地与发电站——城市必须建在土地之上，一切工业与民用电力来自发电站；没有土地和电力，任何建筑与设施都无从存在。AI 加速芯片正是整座 AI 城市的地基与能源中枢：GPU/NPU 内数以千计的流处理器（CUDA Core / Compute Unit / AI Core）如同发电机组，将输入的电能（Wall Power）高效转化为算力（FLOPS）——这是 AI 世界的"通用货币"，驱动着上层一切运转。它是整个架构的终极基础，无需依赖更底层，只需持续"供电"（输出算力与显存带宽）给上方的城市道路系统（运行时平台），让整座 AI 城市得以生生不息地运转。

关注视频号“AI辅助软件开发伍斌”，一起实操AI应用。

© 版权声明
文章版权归作者所有，未经允许请勿转载。

相关文章

标签云