┌─────────────────────────────────────────────────────────────┐
│                    🎯 应用层                                │
│   LLM推理引擎: vLLM / SGLang / xLLM                        │
│   生文模型: Qwen / Llama / GPT / DeepSeek                   │
│   生图模型: Stable Diffusion / Flux / DALL·E / Midjourney   │
├─────────────────────────────────────────────────────────────┤
│                    🏗️ 框架层                               │
│   PyTorch / TensorFlow / JAX                                │
│   ONNX（中间表示层）                                        │
├─────────────────────────────────────────────────────────────┤
│                    ⚡ 加速层                                │
│   CUDA（NVIDIA GPU 计算平台）                               │
│   cuDNN / TensorRT / FlashAttention                         │
├─────────────────────────────────────────────────────────────┤
│                    💻 硬件层                                │
│   NVIDIA GPU（A100 / H100 / RTX 4090）                      │
│   国产卡（昇腾 / 寒武纪 / HexaFlake）                       │
└─────────────────────────────────────────────────────────────┘

CUDA = 你给工人（GPU核心）下指令的语言
     相当于建筑工地的"施工标准"——怎么搬砖、怎么砌墙

💡 关键理解：没有 CUDA，PyTorch 和 TensorFlow 就无法在 GPU 上跑。CUDA 是整个 AI 生态的基石。

PyTorch = 乐高积木 —— 灵活、直观、想怎么拼怎么拼
TensorFlow = 预制板房 —— 规整、适合大规模生产、但改起来费劲

CUDA 相当于：给乐高/预制板提供动力的"电钻"

💡 关键理解：PyTorch 和 TensorFlow 都是"深度学习框架"，它们调用 CUDA 来在 GPU 上执行矩阵运算。你写 PyTorch 代码时，底层自动调用 cuBLAS/cuDNN。

类比理解：
ONNX = 世界语的"你好"
     无论你是中国人（PyTorch）还是美国人（TensorFlow），
     只要把你的模型翻译成 ONNX 格式，
     就能在任何支持 ONNX 的平台上运行

💡 关键理解：ONNX 不是框架，是"翻译官"。你的模型在 PyTorch 里训练好，导出为 ONNX，就能在任何硬件上用 ONNX Runtime 跑推理。

vLLM  = 通用型 LLM 推理引擎（市场主流）
SGLang = 新一代 LLM 推理引擎（性能更强）
xLLM  = 专用 LLM 推理引擎（Grok 专用）

它们都运行在 PyTorch 之上，调用 CUDA 加速

💡 关键理解：vLLM 和 SGLang 不是替代 PyTorch，而是在 PyTorch 之上做推理优化。它们管理显存、调度请求、优化批处理，但底层的矩阵运算还是通过 PyTorch 调用 CUDA 完成。

你输入："写一首诗"
    ↓
vLLM/SGLang（推理引擎）
    ├── 管理 KV Cache（PagedAttention）
    ├── 调度请求（Continuous Batching）
    ├── 约束解码（JSON Schema / Regex）
    ↓
PyTorch（深度学习框架）
    ├── 加载模型权重（Qwen3-32B）
    ├── 执行前向传播
    ├── 调用 CUDA 操作
    ↓
CUDA（GPU 计算平台）
    ├── cuBLAS → 矩阵乘法（Attention 中的 Q·K^T）
    ├── cuDNN → 其他深度学习原语
    ├── FlashAttention → 优化的注意力计算
    ↓
NVIDIA GPU（硬件）
    ├── Tensor Core → 混合精度矩阵运算（FP16/BF16/FP8）
    ├── HBM → 高带宽显存（模型权重 + KV Cache）
    └── SM → 流式多处理器（并行计算单元）
    ↓
输出："床前明月光，疑是地上霜……"

❌ 误解1：vLLM 是 PyTorch 的替代品

✅ 事实：vLLM 运行在 PyTorch 之上，底层还是调用 PyTorch 的算子。

❌ 误解2：ONNX 是一种框架

✅ 事实：ONNX 是一种模型格式/中间表示，不是框架。ONNX Runtime 才是推理引擎。

❌ 误解3：CUDA 和 PyTorch 是竞争关系

✅ 事实：CUDA 是底层平台，PyTorch 是上层框架，PyTorch 调用 CUDA 来加速。

❌ 误解4：SGLang 和 vLLM 是完全不同的东西

✅ 事实：它们解决同样的问题（LLM 推理加速），只是实现方式不同。SGLang 更新，性能更强。

推荐方案：vLLM 或 SGLang
底层依赖：PyTorch + CUDA + cuDNN + FlashAttention
硬件需求：NVIDIA GPU（A100/H100 或以上）

推荐方案：PyTorch + HuggingFace Transformers
分布式训练：DeepSpeed / FSDP / Megatron-LM
硬件需求：多卡 GPU（8x A100 起步）

推荐方案：ComfyUI / Diffusers
底层依赖：PyTorch + CUDA
硬件需求：NVIDIA GPU（RTX 4090 或以上）

推荐方案：PyTorch 训练 → ONNX 导出 → ONNX Runtime 部署
优势：一次导出，到处运行（CPU/GPU/ARM/Web）

一句话总结整个技术栈：

CUDA 是 GPU 的"操作系统"——让 GPU 能做通用计算。
PyTorch / TensorFlow 是"开发工具"——让你方便地定义和训练神经网络。
ONNX 是"翻译官"——让模型能在不同平台间迁移。
vLLM / SGLang 是"智能调度员"——让大模型推理又快又省显存。
LLM / 生图模型 是"最终产品"——真正干活的 AI。

它们不是竞争关系，而是层层依赖、互相配合的关系。理解了这个层次结构，你就掌握了 AI 技术栈的全貌。

十二、HuggingFace：AI 界的 GitHub

HuggingFace 是什么？

HuggingFace 是目前全球最大的AI 模型托管平台和开源社区。它不只是"一个工具"，而是一个完整的 AI 开发生态系统。

项目	说明
成立	2016年（法国巴黎）
创始人	Clément Delangue 等
定位	AI 模型托管 + 开源库 + 社区平台
估值	约 45 亿美元（2025年）
模型数量	超过 100 万个（截至2026年）

类比理解

HuggingFace = GitHub（代码托管） + PyPI（包管理） + Docker Hub（镜像仓库）
             三者合一的 AI 模型平台

HuggingFace 的核心组件

1. 🤗 Transformers 库（最核心）

项目	说明
作用	统一的 API 接口加载和运行几乎所有主流 Transformer 模型
支持的模型	GPT、Llama、Qwen、BERT、T5、Whisper、CLIP、Stable Diffusion 等
底层框架	支持 PyTorch / TensorFlow / JAX 三种后端
一句话	一行代码加载任何模型：from transformers import AutoModel

# Transformers 库的使用示例
from transformers import AutoModel, AutoTokenizer

# 一行代码加载 Qwen3-32B
model = AutoModel.from_pretrained("Qwen/Qwen3-32B")
tokenizer = AutoTokenizer.from_pretrained("Qwen/Qwen3-32B")

# 推理
inputs = tokenizer("你好", return_tensors="pt")
outputs = model.generate(**inputs)

2. 🤗 Diffusers 库

项目	说明
作用	统一 API 加载和运行生图/生视频模型
支持的模型	Stable Diffusion 1.5/XL/3、FLUX、DALL·E、CogVideoX 等
一句话	生图界的 Transformers

3. 🤗 Datasets 库

项目	说明
作用	海量数据集的统一加载和处理
数据集数量	超过 10 万个
一句话	AI 训练数据的"应用商店"

4. 🤗 Spaces

项目	说明
作用	在线部署和展示 AI 应用的平台（类似 Vercel for AI）
特点	免费 GPU、一键部署、Gradio/Streamlit 集成
一句话	AI 应用的"演示厅"

5. 🤗 Hub（模型仓库）

项目	说明
作用	托管模型文件、配置文件、tokenizer、推理代码
版本管理	支持 Git LFS，像 GitHub 一样管理模型版本
一句话	AI 模型的 GitHub

HuggingFace 在技术栈中的位置

┌─────────────────────────────────────────────────────┐
│                 HuggingFace 生态                      │
│                                                      │
│  ┌──────────┐  ┌──────────┐  ┌──────────┐           │
│  │  Hub     │  │ Spaces   │  │ Datasets │           │
│  │ (模型仓库)│  │ (应用部署)│  │ (数据集)  │           │
│  └────┬─────┘  └──────────┘  └────┬─────┘           │
│       │                           │                   │
│  ┌────┴───────────────────────────┴─────┐             │
│  │     Transformers / Diffusers 库       │             │
│  │     (统一API接口)                      │             │
│  └────────────────┬──────────────────────┘             │
│                   ↓                                    │
│  ┌──────────────────────────────────────┐              │
│  │  PyTorch / TensorFlow / JAX          │              │
│  │  (底层框架)                           │              │
│  └────────────────┬──────────────────────┘              │
│                   ↓                                    │
│  ┌──────────────────────────────────────┐              │
│  │  CUDA / cuDNN / FlashAttention       │              │
│  │  (GPU加速层)                          │              │
│  └──────────────────────────────────────┘              │
└─────────────────────────────────────────────────────────┘

HuggingFace 和文中其他概念的关系

概念	和 HuggingFace 的关系
PyTorch	HuggingFace Transformers 的默认后端。你写 from transformers import ... 时，底层调用 PyTorch
TensorFlow	Transformers 也支持 TensorFlow 后端（from transformers import TFAutoModel）
ONNX	HuggingFace 支持将模型导出为 ONNX 格式（transformers.onnx 包）
vLLM	vLLM 可以直接加载 HuggingFace Hub 上的模型（--model Qwen/Qwen3-32B）
SGLang	同样支持从 HuggingFace Hub 加载模型
CUDA	HuggingFace 本身不直接调用 CUDA，通过 PyTorch 间接使用
LLM	几乎所有开源 LLM 都发布在 HuggingFace Hub 上（Qwen、Llama、DeepSeek 等）
生图模型	Stable Diffusion、FLUX 等生图模型也托管在 HuggingFace Hub，通过 Diffusers 库加载

HuggingFace 的完整调用链（以加载 Qwen3-32B 为例）

你写代码：from transformers import AutoModel
          model = AutoModel.from_pretrained("Qwen/Qwen3-32B")
    ↓
Transformers 库
    ├── 从 HuggingFace Hub 下载模型文件（config.json, model.safetensors 等）
    ├── 自动选择 PyTorch 作为后端
    ├── 自动检测 CUDA 是否可用（device_map="auto"）
    ↓
PyTorch
    ├── 加载模型权重到 GPU 显存
    ├── 执行前向传播
    ├── 调用 CUDA 操作
    ↓
CUDA
    ├── cuBLAS → 矩阵乘法
    ├── cuDNN → 深度学习原语
    └── FlashAttention → 优化的注意力计算
    ↓
NVIDIA GPU
    └── Tensor Core → 混合精度矩阵运算
    ↓
输出："你好！有什么我可以帮你的吗？"

HuggingFace 的常见误解

HuggingFace 生态全景图

HuggingFace 生态
│
├── 📦 模型托管（Hub）
│   ├── 100万+ 模型
│   ├── Git LFS 版本管理
│   └── 模型卡片（文档/示例/评测）
│
├── 📚 开源库
│   ├── Transformers — 所有 Transformer 模型的统一接口
│   ├── Diffusers — 所有扩散模型的统一接口
│   ├── Datasets — 数据集加载和处理
│   ├── Accelerate — 分布式训练加速
│   ├── PEFT — 参数高效微调（LoRA/QLoRA）
│   ├── TRL — 强化学习训练（RLHF/DPO）
│   ├── Optimum — 模型优化（量化/剪枝）
│   └── Safetensors — 安全高效的模型存储格式
│
├── 🚀 部署平台（Spaces）
│   ├── 免费 GPU（T4 Small）
│   ├── Gradio / Streamlit 集成
│   └── Docker 自定义环境
│
├── 💰 企业服务
│   ├── Inference API（付费推理 API）
│   ├── AutoTrain（自动训练）
│   └── Enterprise Hub（私有部署）
│
└── 👥 社区
    ├── 讨论区（Discussions）
    ├── 模型排行榜（Leaderboards）
    └── 组织/企业账号

HuggingFace 和你的关系

在你的 Ascent Creator 平台中，HuggingFace 已经在多个地方被间接使用：

• Qwen3 模型：虽然通过百炼 API 调用，但模型本身也发布在 HuggingFace 上
• Transformers 库：如果你本地部署模型，就是用 Transformers 加载
• 模型格式：.safetensors 格式是 HuggingFace 推动的标准
• Tokenizers：你用的 tokenizer 很可能来自 HuggingFace

一句话总结 HuggingFace

十三、分布式训练框架：DeepSpeed / FSDP / Megatron-LM

为什么需要分布式训练？

一个 70B 参数的模型，仅模型权重就需要约 140GB 显存（FP16）。加上优化器状态（Adam 需要额外 2 倍）、梯度、激活值，单卡 H100（80GB）根本放不下。所以必须把模型切分到多张 GPU 上。

三种并行策略

策略	做法	类比
数据并行（DP）	每张卡放完整模型，分不同数据批次	10个厨师各做一整桌菜
张量并行（TP）	把一层网络切分到多张卡	一道菜10个人各炒一部分
流水线并行（PP）	不同层放在不同卡上	流水线作业，每人做一道工序

DeepSpeed

项目	说明
开发者	微软（Microsoft）
发布	2020年
核心创新	ZeRO（零冗余优化器）——把模型状态（参数/梯度/优化器状态）分散到各卡，需要时再收集
ZeRO 三个阶段	ZeRO-1：切分优化器状态（节省 4x 显存） ZeRO-2：切分优化器+梯度（节省 8x 显存） ZeRO-3：切分优化器+梯度+参数（节省 16x+ 显存）
开源	✅ 完全开源（Apache 2.0）
额外功能	DeepSpeed-Chat（RLHF 训练）、FlashAttention 集成、混合精度训练

# DeepSpeed 使用示例
deepspeed --num_gpus=8 train.py   --deepspeed ds_config.json

# ds_config.json 中配置 ZeRO 级别
{
  "zero_optimization": {
    "stage": 3,           # ZeRO-3
    "offload_optimizer": {"device": "cpu"},  # 优化器卸载到 CPU
    "offload_param": {"device": "cpu"}       # 参数卸载到 CPU
  }
}

FSDP（Fully Sharded Data Parallel）

项目	说明
开发者	Meta（PyTorch 团队）
本质	PyTorch 原生实现的 ZeRO-3
和 DeepSpeed 的关系	功能类似，实现不同。FSDP 是 PyTorch 官方方案，DeepSpeed 是微软的第三方方案
优势	原生 PyTorch 集成，不需要额外安装 deepspeed 包
劣势	优化不如 DeepSpeed 深入（如 offload 功能较弱）
开源	✅ 完全开源（PyTorch 的一部分）

# FSDP 使用示例（PyTorch 原生）
from torch.distributed.fsdp import FullyShardedDataParallel as FSDP

model = FSDP(model)  # 一行代码包装
output = model(input)  # 使用方式和普通模型一样

Megatron-LM

项目	说明
开发者	NVIDIA
发布	2019年
核心创新	张量并行（Tensor Parallelism）——把 Transformer 层的矩阵运算切分到多卡
特点	最底层的分布式训练框架，需要手动修改模型代码
性能	最高效，但使用门槛最高
开源	✅ 完全开源

三者的关系

三者的关系可以这样理解：

DeepSpeed = 微软的"全能工具箱"（ZeRO + offload + 通信优化）
FSDP      = PyTorch 官方的"轻量版 DeepSpeed"（只做 ZeRO）
Megatron  = NVIDIA 的"性能怪兽"（张量并行 + 流水线并行）

实际训练中，它们经常组合使用：
Megatron-DeepSpeed = Megatron 的张量并行 + DeepSpeed 的 ZeRO
Megatron-LM 负责"横着切"（张量并行）
DeepSpeed 负责"竖着切"（ZeRO 分片）

对比维度	DeepSpeed	FSDP	Megatron-LM
开发者	微软	Meta（PyTorch）	NVIDIA
核心策略	ZeRO（数据并行+分片）	ZeRO（PyTorch 原生）	张量并行+流水线并行
易用性	⭐⭐⭐（配置文件）	⭐⭐⭐⭐⭐（一行代码）	⭐（需改模型代码）
性能	⭐⭐⭐⭐	⭐⭐⭐	⭐⭐⭐⭐⭐
显存节省	⭐⭐⭐⭐⭐（支持 CPU offload）	⭐⭐⭐⭐	⭐⭐⭐（主要靠切分）
适用场景	大模型训练（通用）	中小模型训练（易用）	超大模型训练（极致性能）

---

十四、国产 GPU 适配大模型：适配的到底是什么？

国产 GPU 有哪些？

厂商	芯片	定位
华为	昇腾 910B / 910C	AI 训练/推理，最成熟的国产方案
寒武纪	思元 590 / 370	AI 训练/推理
海光	深算一号 / 二号	AI 推理为主
摩尔线程	MTT S4000	AI 推理 + 图形渲染
壁仞	BR100	AI 训练/推理
燧原	云燧 T20 / T21	AI 训练/推理
HexaFlake	Compass C10	你 245 服务器上用的那张卡

适配大模型，到底适配什么？

核心答案：适配的不是 ONNX，而是 CUDA。

ONNX 只是模型格式，真正难的是让模型在国产 GPU 上高效运行。适配工作分为以下几个层面：

第一层：算子适配（最底层、最核心）

NVIDIA 有 CUDA，国产 GPU 有自己的"CUDA"：
  华为  → CANN（异构计算架构）
  寒武纪 → BANG C（寒武纪编程语言）
  海光  → DTK（海光计算平台）
  摩尔线程 → MUSA（摩尔线程统一架构）
  壁仞  → BIREN（壁仞计算平台）

PyTorch 训练时调用的算子（如 torch.matmul、torch.nn.functional.softmax），在 NVIDIA GPU 上通过 CUDA 执行。在国产 GPU 上，需要把这些算子翻译成国产 GPU 能识别的指令。

适配的实质就是：让 PyTorch 的算子调用，能从"走 CUDA"变成"走 CANN/BANG C/MUSA"。

第二层：通信库适配

多卡训练时，GPU 之间需要高速通信。NVIDIA 用 NCCL，国产卡需要适配自己的通信库：

• 华为：HCCL（华为集合通信库）
• 寒武纪：CNCL（寒武纪通信库）
• 其他：各自实现兼容 NCCL 接口的通信库

第三层：推理引擎适配

vLLM、SGLang 等推理引擎底层也调用 CUDA。要在国产卡上跑，需要：

• 华为：vLLM 有 CANN 后端（vllm-ascend）
• 其他：需要各自实现对应的后端

第四层：框架适配

PyTorch 本身也需要适配国产 GPU。华为的解决方案是 torch_npu——一个 PyTorch 的插件，把 PyTorch 的算子路由到 CANN 上执行。

# 华为昇腾适配 PyTorch 的方式
import torch
import torch_npu  # 华为的 PyTorch 插件

# 一行代码切换设备
device = torch.device("npu:0")  # 而不是 "cuda:0"
model = model.to(device)

ONNX 在国产 GPU 适配中的角色

ONNX 在国产 GPU 适配中有一定作用，但不是核心：

场景	ONNX 的作用
模型迁移	PyTorch 模型 → ONNX → 国产卡推理引擎（如华为的 MindStudio）
推理优化	ONNX Runtime 支持多种国产卡后端（如 Huawei Ascend Execution Provider）
格式转换	ONNX 作为中间格式，再转为国产卡专用格式（如昇腾的 .om 格式）

一张图看懂国产 GPU 适配

NVIDIA 方案：                         国产 GPU 方案：
┌──────────────────┐                ┌──────────────────┐
│  PyTorch 模型     │                │  PyTorch 模型     │
└────────┬─────────┘                └────────┬─────────┘
         │                                    │
         ▼                                    ▼
┌──────────────────┐                ┌──────────────────┐
│  CUDA 算子       │                │  torch_npu 插件   │
│  (cuBLAS/cuDNN)  │                │  (算子路由层)      │
└────────┬─────────┘                └────────┬─────────┘
         │                                    │
         ▼                                    ▼
┌──────────────────┐                ┌──────────────────┐
│  NVIDIA GPU      │                │  CANN / BANG C   │
│  (A100/H100)     │                │  (国产计算平台)    │
└──────────────────┘                └────────┬─────────┘
                                              │
                                              ▼
                                     ┌──────────────────┐
                                     │  昇腾 / 思元 /   │
                                     │  摩尔线程 / 壁仞  │
                                     └──────────────────┘

国产 GPU 适配的现状和挑战

挑战	说明
算子覆盖率	CUDA 有上万个算子，国产卡只覆盖了最常用的几百个。遇到不支持的算子就报错
性能差距	即使算子能跑，性能也只有 NVIDIA 的 30-80%（取决于具体算子）
生态碎片化	每家厂商有自己的"CUDA"（CANN/BANG C/MUSA），模型要分别适配
推理引擎	vLLM/SGLang 等主流推理引擎对国产卡支持有限
训练框架	DeepSpeed/FSDP 对国产卡的适配还在进行中

你 245 服务器上的 HexaFlake 卡

你用的 HexaFlake Compass C10 也是国产卡。它适配大模型的方式和其他国产卡类似：

• 有自己的底层计算平台（hxsage）
• 通过 PyTorch 插件让模型能跑在卡上
• 算子覆盖率和性能取决于厂商的适配进度
• 你目前主要用它跑 Qwen3-32B 的推理

一句话总结国产 GPU 适配

十五、华为昇腾 910C 深度解析

昇腾 910C 是什么？

华为昇腾 910C 是华为最新一代 AI 训练芯片，也是目前国产 AI 芯片中综合性能最强的产品。它是昇腾 910B 的升级版，专门为大模型训练和推理设计。

项目	昇腾 910C	昇腾 910B
制程	7nm+（增强版）	7nm
FP16 算力	约 400 TFLOPS	约 320 TFLOPS
显存	HBM2e 64GB	HBM2e 48GB
显存带宽	约 1.5 TB/s	约 1.2 TB/s
互联	HCCS（华为自研高速互联）	HCCS
架构	Da Vinci（达芬奇）	Da Vinci

昇腾的 Da Vinci 架构

华为昇腾系列使用自研的 Da Vinci（达芬奇）架构，和 NVIDIA 的 CUDA Core + Tensor Core 设计思路不同：

Da Vinci 架构的核心是一个"3D Cube"矩阵计算单元：
┌─────────────────────────────────────┐
│  AI Core                             │
│  ┌───────────────────────────────┐   │
│  │  3D Cube（矩阵乘法引擎）       │   │  ← 专为 AI 设计的矩阵加速器
│  │  16x16x16 矩阵乘法阵列         │   │
│  └───────────────────────────────┘   │
│  ┌──────────┐ ┌──────────┐          │
│  │ Vector   │ │ Scalar   │          │  ← 通用计算单元
│  │ 单元     │ │ 单元     │          │
│  └──────────┘ └──────────┘          │
│  ┌──────────┐ ┌──────────┐          │
│  │ L1 缓存  │ │ L0 缓存  │          │  ← 片上缓存
│  └──────────┘ └──────────┘          │
└─────────────────────────────────────┘

对比 NVIDIA 的架构：
NVIDIA: Tensor Core（矩阵乘） + CUDA Core（通用计算）
华为:    3D Cube（矩阵乘） + Vector/Scalar（通用计算）

昇腾的软件栈

昇腾软件栈（从下到上）：
┌─────────────────────────────────────┐
│  CANN（华为计算架构）                 │
│  ├── AscendCL（底层编程接口）         │  ← 对标 CUDA
│  ├── AICore（算子库）                │  ← 对标 cuDNN
│  └── HCCL（集合通信库）              │  ← 对标 NCCL
├─────────────────────────────────────┤
│  torch_npu（PyTorch 适配层）          │  ← 让 PyTorch 跑在昇腾上
├─────────────────────────────────────┤
│  MindSpore（华为自研框架）            │  ← 对标 PyTorch/TensorFlow
├─────────────────────────────────────┤
│  MindStudio（开发工具）               │  ← 对标 NVIDIA NSight
└─────────────────────────────────────┘

---

十六、灵枢（Ling Shu）是什么？

灵枢的定位

灵枢（Ling Shu） 可能指代以下几个不同的事物，需要根据上下文区分：

指代	说明
灵枢 AI 芯片	国内某 AI 芯片厂商的产品，定位边缘计算和推理场景
灵枢医疗 AI	联影医疗旗下的 AI 平台，专注于医学影像分析
灵枢大模型	部分国内厂商发布的中文大模型名称

在 AI 芯片的语境下，灵枢通常指一款面向 AI 推理和边缘计算 的国产芯片，特点是低功耗、高能效比，适合部署在数据中心边缘或终端设备上。

灵枢芯片的典型规格（参考）

项目	规格
定位	AI 推理 / 边缘计算
算力	约 32-64 TOPS（INT8）
功耗	约 15-35W
典型场景	视频分析、语音识别、小模型推理

---

十七、DeepMind 及其整体架构

DeepMind 是什么？

DeepMind 是 Google 旗下的 AI 研究实验室（2014 年被 Google 收购），总部在伦敦。它是全球最顶尖的 AI 研究机构之一，以强化学习和基础科学研究闻名。

项目	说明
成立	2010年（伦敦）
创始人	Demis Hassabis、Shane Legg、Mustafa Suleyman
收购	2014年被 Google 以 5 亿美元收购
定位	AI 基础研究（非产品公司）
和 Google Brain 的关系	2023年与 Google Brain 合并为 Google DeepMind

DeepMind 的里程碑成果

年份	成果	意义
2013	DQN（深度 Q 网络）	AI 学会玩 Atari 游戏，强化学习里程碑
2016	AlphaGo	击败围棋世界冠军李世石，轰动全球
2017	AlphaZero	从零自学围棋/象棋/将棋，无需人类知识
2018	AlphaFold	蛋白质结构预测，解决生物学50年难题
2020	AlphaFold 2	蛋白质预测达到实验级精度
2022	Chinchilla	提出"更多数据 > 更大模型"的缩放定律
2023	RT-2	视觉语言动作模型，机器人领域突破
2024	Gemini	Google 多模态大模型（DeepMind + Brain 合并后）
2025	AlphaFold 3	蛋白质+DNA+RNA 全分子结构预测

DeepMind 的技术架构

DeepMind 不是芯片公司，不生产硬件。它的研究依赖 Google 庞大的 TPU（张量处理单元）集群：

DeepMind 的技术栈：
┌─────────────────────────────────────────────┐
│  🎯 研究领域                                  │
│  强化学习 / 深度学习 / 神经科学 / 生物信息学  │
├─────────────────────────────────────────────┤
│  🏗️ 框架层                                   │
│  JAX（Google 自研框架，DeepMind 主力使用）    │
│  TensorFlow（部分项目使用）                   │
│  Haiku / Optax / RLax（DeepMind 自研库）      │
├─────────────────────────────────────────────┤
│  ⚡ 硬件层（Google TPU 集群）                 │
│  TPU v4 / v5p / Trillium                     │
│  通过 Google 数据中心互联                    │
├─────────────────────────────────────────────┤
│  🧠 代表模型                                  │
│  AlphaGo / AlphaFold / Chinchilla / Gato     │
│  Gemini（与 Google Brain 合并后）             │
└─────────────────────────────────────────────┘

DeepMind 和 Google TPU

DeepMind 的训练基础设施是 Google 的 TPU（Tensor Processing Unit），这是 Google 自研的 AI 加速芯片：

TPU 版本	发布	算力	显存
TPU v4	2021	275 TFLOPS（BF16）	32GB HBM
TPU v5p	2023	459 TFLOPS（BF16）	95GB HBM
TPU Trillium	2024	约 900 TFLOPS（BF16）	~128GB HBM

---

十八、全球 AI 芯片大对比

训练芯片对比

芯片	厂商	FP16算力	显存	带宽	互联	制程	架构
H100	NVIDIA	989 TFLOPS	80GB HBM3	3.35 TB/s	NVLink 900GB/s	4nm	Hopper
B200	NVIDIA	2250 TFLOPS	192GB HBM3e	8 TB/s	NVLink 1.8TB/s	4nm	Blackwell
昇腾 910C	华为	~400 TFLOPS	64GB HBM2e	~1.5 TB/s	HCCS ~200GB/s	7nm+	Da Vinci
TPU v5p	Google	459 TFLOPS	95GB HBM	~2 TB/s	ICI（自研）	5nm	自研
Gaudi 3	Intel	~400 TFLOPS	~80GB HBM2e	~1.5 TB/s	RoCE	5nm	自研
MI300X	AMD	653 TFLOPS	192GB HBM3	5.2 TB/s	Infinity Fabric	5nm	CDNA 3
Compass C10	HexaFlake	~200 TFLOPS	~32GB HBM	~0.8 TB/s	自研	7nm	自研
思元 590	寒武纪	~256 TFLOPS	~32GB HBM	~1 TB/s	CNCL	7nm	MLU

推理/边缘芯片对比

芯片	厂商	INT8算力	功耗	场景
Jetson AGX Orin	NVIDIA	275 TOPS	15-60W	机器人/边缘
灵枢（参考）	国产	32-64 TOPS	15-35W	边缘推理
Intel Movidius	Intel	~4 TOPS	~2W	超低功耗
Google Edge TPU	Google	4 TOPS	~2W	IoT/边缘

软件生态对比

维度	NVIDIA CUDA	华为 CANN	Google TPU	AMD ROCm	Intel
成熟度	⭐⭐⭐⭐⭐	⭐⭐⭐⭐	⭐⭐⭐⭐	⭐⭐⭐	⭐⭐⭐
PyTorch 支持	原生	torch_npu	torch_xla	原生（部分）	XPU 插件
vLLM 支持	原生	vllm-ascend	有限	实验性	实验性
算子数量	10000+	~3000	~2000	~4000	~2000
社区生态	最庞大	国内为主	Google 内部	较小	中等
开放程度	闭源	部分开源	闭源	开源	部分开源

综合性能对比（以训练 70B 模型为例）

芯片	所需卡数	训练时间	总成本	可获得性
H100	~256 卡	~7 天	~$500K	受限（对华禁运）
B200	~128 卡	~4 天	~$800K	受限（对华禁运）
昇腾 910C	~512 卡	~14 天	~¥300W	可购买（国内）
TPU v5p	~256 卡	~8 天	~$400K	仅云服务
MI300X	~256 卡	~10 天	~$350K	可购买
Compass C10	~1024 卡	~30 天	~¥200W	可购买（国内）

架构设计理念对比

维度	NVIDIA	华为	Google	AMD
设计哲学	通用GPU + AI加速	AI专用芯片	AI专用芯片	通用GPU + AI加速
矩阵计算	Tensor Core	3D Cube	MXU（矩阵乘法单元）	Matrix Core
通用计算	CUDA Core（强）	Vector/Scalar（中）	弱（仅矩阵运算）	Stream Processor（强）
互联方案	NVLink（封闭）	HCCS（封闭）	ICI（封闭）	Infinity Fabric（开放）
编程模型	CUDA（闭源）	CANN（部分开源）	XLA（开源）	ROCm（开源）
核心优势	生态最强、性能最强	国产替代、政策支持	Google生态、TPU集群	开放生态、性价比
核心劣势	贵、对华禁运	生态不完善、性能差距	不对外销售	软件生态弱

DeepMind 在整个生态中的位置

DeepMind 不是芯片公司，而是 AI 研究的"顶级玩家"。
它和芯片的关系是：用最好的芯片做最前沿的研究。

具体来说：
- DeepMind 的研究成果（AlphaFold、Chinchilla 等）推动了对更强算力的需求
- 这些需求反过来推动了 Google TPU 的迭代
- TPU 的迭代又让 DeepMind 能做更复杂的研究
- 形成"研究 → 需求 → 硬件 → 更强研究"的正循环

这和 NVIDIA 的关系类似：
- 学术界用 PyTorch + NVIDIA GPU 做研究
- 研究成果推动对更强 GPU 的需求
- NVIDIA 根据需求迭代 GPU
- 新 GPU 让学术界能做更大规模的研究

一张图总结全球 AI 芯片格局

全球 AI 芯片格局（2026年）：

🏆 第一梯队（垄断级）
├── NVIDIA（H100/B200）— 市占率 ~80%
│   ├── 最强性能 + 最完善生态
│   └── 唯一问题：贵 + 对华禁运

🥇 第二梯队（追赶级）
├── 华为（昇腾 910C）— 国产最强
│   ├── 性能约为 H100 的 40-50%
│   └── 国内可购买，生态逐步完善
├── Google（TPU v5p）— 自用最强
│   ├── 性能接近 H100
│   └── 不对外销售，仅云服务
├── AMD（MI300X）— 开放挑战者
│   ├── 性价比高，ROCm 开源
│   └── 软件生态远不如 CUDA

🥈 第三梯队（国产替代）
├── 寒武纪（思元 590）
├── 海光（深算二号）
├── 摩尔线程（MTT S4000）
├── 壁仞（BR100）
├── 燧原（云燧 T21）
└── HexaFlake（Compass C10）— 你正在用的

🥉 第四梯队（边缘/推理）
├── NVIDIA Jetson
├── 灵枢（国产边缘芯片）
├── Google Edge TPU
└── Intel Movidius

十九、生视频模型

生视频模型是什么？

生视频模型 是指能够根据文字描述、图片或视频片段生成连续视频内容的 AI 模型。它是继生文（LLM）和生图（Diffusion）之后，AI 生成领域的下一个前沿方向。

生视频模型的技术架构

目前的生视频模型主要基于以下几种架构：

架构	原理	代表模型
扩散模型（Video Diffusion）	将生图的扩散过程扩展到时空维度，同时去噪所有帧	Stable Video Diffusion、Wan2.7、CogVideoX
DiT（Diffusion Transformer）	用 Transformer 替代 U-Net 作为扩散主干网络	Sora（OpenAI）、Open-Sora
自回归模型	把视频帧当成 token 序列，逐帧预测生成	VideoPoet（Google）、Emu Video（Meta）
3D VAE + Transformer	将视频压缩到潜空间，再用 Transformer 生成	Gen-3（Runway）、Kling（快手）

主流生视频模型对比

模型	厂商	架构	最大时长	分辨率	开源	推理引擎
Sora	OpenAI	DiT	60秒	1080p	❌	自研
Kling（可灵）	快手	3D VAE+Transformer	30秒	1080p	❌	自研
Wan2.7	阿里	Video Diffusion	10秒	720p	✅	Diffusers / ComfyUI
CogVideoX	智谱（Zhipu）	3D VAE+Transformer	10秒	720p	✅	Diffusers / ComfyUI
Open-Sora	ColossalAI	DiT	20秒	720p	✅	自研推理
HappyHorse	阿里	Video Diffusion	10秒	720p	✅	百炼 API
Gen-3 Alpha	Runway	3D VAE+Transformer	10秒	1080p	❌	自研
Pika 2.0	Pika Labs	Video Diffusion	10秒	1080p	❌	自研

生视频模型和生图模型的计算差异

维度	生图模型	生视频模型
输出维度	2D（H x W）	3D（T x H x W）
数据量	~1MB（一张图）	~100MB（10秒视频）
计算量	1x（基准）	100-1000x
显存需求	~8GB（SDXL）	~80GB（Sora级别）
推理时间	~2秒（SDXL）	~10分钟（Sora）
关键挑战	图像质量、风格一致性	时序一致性、运动合理性

生视频模型在技术栈中的位置

生视频模型的技术栈和生图模型类似，但计算量大了两个数量级：

┌─────────────────────────────────────────────┐
│  生视频模型（Wan2.7 / CogVideoX / Sora）     │
├─────────────────────────────────────────────┤
│  推理引擎                                    │
│  ├── ComfyUI（可视化工作流，最流行）           │
│  ├── Diffusers（HuggingFace 库，代码调用）    │
│  └── 自研引擎（Sora/Kling 等闭源模型）        │
├─────────────────────────────────────────────┤
│  PyTorch（加载模型、执行前向传播）             │
├─────────────────────────────────────────────┤
│  CUDA / cuDNN / FlashAttention              │
├─────────────────────────────────────────────┤
│  NVIDIA GPU（A100 80GB / H100 起步）         │
│  （生视频需要至少 40GB+ 显存）                │
└─────────────────────────────────────────────┘

---

二十、ComfyUI 为什么是推理引擎？

ComfyUI 是什么？

ComfyUI 是一个基于节点图（Node Graph）的 AI 图像/视频生成前端界面。但它远不止是一个"界面"——它本质上是一个可视化推理引擎。

推理引擎的定义

在 AI 领域，推理引擎（Inference Engine） 是指负责加载训练好的模型并执行前向传播（推理）的软件系统。它的核心职责是：

1. 模型加载：读取模型权重和配置文件
2. 计算图构建：把模型的计算过程组织成可执行的图
3. 算子调度：把图中的每个操作分配到 GPU 上执行
4. 显存管理：管理中间结果的存储和释放
5. 结果输出：把 GPU 上的张量转换回可读的格式（图片/视频）

ComfyUI 为什么符合推理引擎的定义？

推理引擎职责	ComfyUI 的实现
模型加载	ComfyUI 内置了模型加载器节点（Load Checkpoint / Load UNet / Load VAE 等），可以从 HuggingFace Hub 或本地路径加载 SD / FLUX / Wan2.7 等模型
计算图构建	用户拖拽节点连接的过程，本质上就是在可视化地构建计算图。每个节点是一个算子，连线是数据流。这和 TensorFlow 的静态计算图本质相同
算子调度	ComfyUI 有内置的执行引擎，按拓扑序遍历节点图，把每个节点的计算任务调度到 GPU 上执行。支持并行执行无依赖的节点
显存管理	ComfyUI 有智能的显存管理系统，自动缓存和释放中间张量。支持模型卸载（model offloading），在显存不足时把不用的模型移到 CPU
结果输出	通过 Save Image / Preview Image 等节点，把 GPU 张量转为 PNG/JPEG/MP4 文件

ComfyUI 和其他推理引擎的对比

维度	ComfyUI	vLLM	ONNX Runtime	Diffusers
定位	生图/生视频推理引擎	LLM 推理引擎	通用推理引擎	生图/生视频推理库
交互方式	可视化节点图（拖拽）	API / 命令行	API / 代码	Python 代码
计算图	可视化构建	隐式（模型内部）	ONNX 图	代码构建
显存优化	智能 offload	PagedAttention	基本	基本
支持的模型	SD / FLUX / Wan2.7 / CogVideoX	Qwen / Llama / DeepSeek	任何 ONNX 模型	SD / FLUX / Wan2.7
底层框架	PyTorch	PyTorch	自研	PyTorch

ComfyUI 的工作流程

ComfyUI 的完整推理流程：

用户拖拽节点图
    ↓
ComfyUI 解析节点图 → 构建 DAG（有向无环图）
    ↓
拓扑排序 → 确定执行顺序
    ↓
执行引擎开始遍历：
    ├── 节点1（Load Checkpoint）→ 加载模型权重到 GPU
    ├── 节点2（CLIP Text Encode）→ 编码提示词
    ├── 节点3（KSampler）→ 执行扩散采样（调用 PyTorch）
    │   ├── 循环 20-50 步：
    │   │   ├── 调用 UNet/DiT 前向传播
    │   │   ├── 调用 CUDA 执行矩阵乘法
    │   │   └── 更新潜空间张量
    │   └── 输出最终潜空间张量
    ├── 节点4（VAE Decode）→ 把潜空间张量解码为像素图
    └── 节点5（Save Image）→ 保存为 PNG 文件
    ↓
结果输出到用户界面

ComfyUI 和 vLLM 的类比

ComfyUI 之于生图模型 = vLLM 之于 LLM

vLLM:
  LLM 模型 → vLLM 管理显存/调度请求 → 输出文字

ComfyUI:
  生图模型 → ComfyUI 管理节点图/调度算子 → 输出图片/视频

两者都是"推理引擎"——负责让模型高效运行的中间层。
区别在于：
- vLLM 面向 LLM（文本生成），优化重点是 KV Cache 和 Continuous Batching
- ComfyUI 面向生图/生视频（视觉生成），优化重点是节点图执行和显存 offload

ComfyUI 在技术栈中的位置

┌─────────────────────────────────────────────┐
│  用户界面（ComfyUI 的 Web UI）               │
│  ├── 节点拖拽面板                            │
│  ├── 实时预览                                │
│  └── 工作流管理                              │
├─────────────────────────────────────────────┤
│  🔥 ComfyUI 执行引擎（推理引擎核心）          │
│  ├── 节点图解析器（解析 DAG）                 │
│  ├── 执行调度器（拓扑排序 + 并行执行）         │
│  ├── 显存管理器（智能 offload + 缓存）         │
│  └── 模型加载器（支持 SD/FLUX/Wan/Video）     │
├─────────────────────────────────────────────┤
│  PyTorch（底层框架）                          │
├─────────────────────────────────────────────┤
│  CUDA / cuDNN / FlashAttention              │
├─────────────────────────────────────────────┤
│  GPU（NVIDIA / 华为 / AMD）                  │
└─────────────────────────────────────────────┘

所以 ComfyUI 是推理引擎，不是"画图软件"。
它和 Photoshop 的区别就像 vLLM 和记事本的区别一样大。

常见误解

ComfyUI 和你的 Ascent Creator 平台

在你的 Ascent Creator 平台中，ComfyUI 的角色是：

• 图片工坊：底层可以用 ComfyUI 作为推理后端（通过 API 调用）
• 视频工坊：Wan2.7 / CogVideoX 等视频模型也可以用 ComfyUI 的工作流来执行
• AI 3D工坊：ComfyUI 也支持 3D 生成工作流
• 优势：ComfyUI 的节点图可以组合多个模型（如 ControlNet + IP-Adapter + SD），实现复杂的工作流