1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
[Physical World]

[Robotics / Sensors / UI] ← Agent的“手脚与感官”

┌──────────────────────┐
│ 🤖 Agent │ ← Planning + Memory + Tool Use + Reflection
└──────────────────────┘

[Application Layer] ← RAG、Workflow引擎、Multi-Agent系统

┌──────────────────────┐
│ 🧠 Model Serving │ ← Triton / vLLM / TGI(文本生成推理)
│ 🔧 Optimization │ ← Quantization, Distillation, Pruning
└──────────────────────┘

[Framework Layer] ← PyTorch / TensorFlow / JAX

┌──────────────────────┐
│ System/Runtime │ ← CUDA / cuDNN / XLA / TVM
└──────────────────────┘

[Hardware Layer]
├─ CPU(控制流)
├─ GPU(并行计算主力)
├─ NPU/TPU(专用加速)
└─ Memory Hierarchy(HBM → DDR → SSD Offload)
  1. 应用层

  2. 能力层

  3. 智能体Agent

    • RAG检索增强生成
    • fine-tuning 模型微调
    • Prompt Engineering 提示词工程
    • Chain-of-Thought (CoT) 思维链
    • 数据处理
  4. 服务与部署

    • 训练:分布式训练、框架支持

    • 推理:

    • | 类型 | 工具 | 特点 |
      | ——— | ——————————————————— | ————————————————- |
      | 云服务 | NVIDIA Triton, TorchServe, KServe | 支持动态批处理、多模型、gRPC/HTTP |
      | 端侧 | TensorFlow Lite, Core ML, SNPE(高通) | 量化(INT8/INT4)、剪枝、蒸馏 |
      | 边缘 | ONNX Runtime, TensorRT Lite | 低延迟、低功耗 |

  5. 模型层

    • 大语言模型
    • 多模态模型
  6. 系统与驱动层

  7. 基础设施(算力)

    • GPU

    • CPU

    • RAM

    • SSD/HDD[硬盘]

L5 智能体层 Agent Layer 目标驱动的自主决策与行动闭环 ReAct, AutoGen, LangChain, Toolformer, Reflection
L4 策略/算法层 Policy & Algorithm Layer 定义“如何思考/决策”的逻辑 Prompt Engineering, CoT/ToT, RLHF, PPO/DPO, Self-Refine, RAG
L3 基础设施层 Infrastructure (Infra) Layer 支撑模型训练/推理的分布式系统 DeepSpeed, FSDP, Ray, vLLM, Triton, Kubernetes, MLOps
L2 编译与运行时层 Compiler & Runtime Layer 将模型高效映射到硬件 TVM, TensorRT, ONNX Runtime, TorchDynamo, AOT Inductor, XLA
L1 硬件抽象层 Hardware Abstraction Layer 屏蔽底层异构硬件差异 CUDA, ROCm, SYCL/oneAPI, Ascend C, Vulkan, OpenCL

编程语言链

Python 代码 ⟶ 抽象语法树(AST) ⟶ 字节码(Bytecode) ⟶ 机器码(Machine Code) ⟶ 电信号/01

1. Python 源代码(High-level Code)

1
2
3
4
5
# example.py
def add(a, b):
return a + b

print(add(2, 3))
  • 人类可读、高度抽象
  • 含语法糖(如 + 自动调用 __add__

2. AST(Abstract Syntax Tree)

✅ 过程:

  • 词法分析(Lexing):拆成 Token def add ( a , b ) : return a + b
  • 语法分析(Parsing):按 Python 语法规则 → 构建树状结构(AST)

🔍 AST 示例(简化):

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
(dif_cu124py310) mvb@4090-6:/home/projects/wwj/adapter$ python -m ast example.py
Module(
body=[
FunctionDef(
name='add',
args=arguments(
posonlyargs=[],
args=[arg(arg='a'),arg(arg='b')],
kwonlyargs=[],
kw_defaults=[],
defaults=[]),
body=[
Return(
value=BinOp(
left=Name(id='a', ctx=Load()),
op=Add(),
right=Name(id='b', ctx=Load())))],
decorator_list=[]),
Expr(
value=Call(
func=Name(id='print', ctx=Load()),
args=[
Call(
func=Name(id='add', ctx=Load()),
args=[Constant(value=2),Constant(value=3)],
keywords=[])],
keywords=[]))],
type_ignores=[])

📌 工具:

  • python -m ast example.py 可查看真实 AST
  • 编译器前端核心:Parser

✅ 此时仍是平台无关、语言无关的结构化表示


3. 字节码(Bytecode)

什么是字节码?

  • 一种低级、紧凑、平台无关的中间指令集
  • 类似“虚拟CPU”的汇编语言(CPython 的虚拟机叫 CPython VM,也称 Eval Loop
  • 存在 .pyc 文件中(位于 __pycache__/
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
(dif_cu124py310) mvb@4090-6:/home/projects/wwj/adapter$  python -m dis example.py 
2 0 LOAD_CONST 0 (<code object add at 0x7f8d4d14d2c0, file "example.py", line 2>)
2 LOAD_CONST 1 ('add')
4 MAKE_FUNCTION 0
6 STORE_NAME 0 (add)

5 8 LOAD_NAME 1 (print)
10 LOAD_NAME 0 (add)
12 LOAD_CONST 2 (2)
14 LOAD_CONST 3 (3)
16 CALL_FUNCTION 2
18 CALL_FUNCTION 1
20 POP_TOP
22 LOAD_CONST 4 (None)
24 RETURN_VALUE

Disassembly of <code object add at 0x7f8d4d14d2c0, file "example.py", line 2>:
3 0 LOAD_FAST 0 (a)
2 LOAD_FAST 1 (b)
4 BINARY_ADD
6 RETURN_VALUE

📌 关键指令:

  • LOAD_FAST:加载局部变量
  • BINARY_ADD:执行加法
  • CALL_FUNCTION:调用函数

Python 是“先编译成字节码 + 再解释执行字节码”,不是纯解释型!
(类似 Java 的 .java → javac → .class → JVM


4. 机器码(Machine Code)

🟢 路径 A:传统 CPython(解释执行字节码)

  • CPython 用 C 实现了一个 字节码解释器(eval_frame.c)
  • 每条 bytecode 指令 → 对应一段 C 代码 → 最终由 CPU 执行
  • ❌ 缺点:解释开销大(每条指令要查跳转表、压栈等)
1
2
3
4
5
6
7
8
// CPython 内部伪代码
switch (opcode) {
case BINARY_ADD:
x = POP(); y = POP();
PUSH(PyNumber_Add(x, y));
break;
...
}

🟢 路径 B:JIT 编译(Just-In-Time)— 如 PyPy, Numba

  • 运行时动态将热点字节码 → 本地机器码
  • 例如 PyPy 的 JIT Compiler(基于 RPython)
    1
    Bytecode → Trace(热点路径)→ Optimize → x86_64 machine code
  • ✅ 优势:消除解释开销,速度提升 5–10×
  • 🔴 缺点:启动慢、内存高、兼容性风险

🟢 路径 C:AOT 编译(Ahead-Of-Time)— 如 Nuitka, Cython

工具 原理 输出
Nuitka 将 Python → C++ → GCC/Clang → .so/.exe 原生机器码,无 Python 依赖
Cython .pyx(Python+类型注解)→ C → 编译为扩展模块 高性能混合模块(如 pandas 底层)

🌰 Nuitka 示例:

1
nuitka --standalone example.py  # → 生成 example.bin(纯机器码)

✅ 此时:Python 已彻底变成 .text 段的 x86/ARM 指令!


5. 0/1 二进制位流

✅ 机器码本质

  • 一串 二进制指令(如 x86-64 的 0x48 0x01 0xD8 = add rax, rbx
  • 由 CPU 的 取指-译码-执行(IF-ID-EX)流水线处理

🔄 如何变成 0 和 1?

  1. 可执行文件(ELF / PE)加载到内存(.text 段)
  2. CPU 从 RIP 寄存器取指令地址 → 读内存 → 得到 字节序列
  3. 控制单元(CU)将操作码(Opcode)解码 → 激活 ALU / 寄存器 / 总线
  4. 最终体现为:
    • 数字电路:晶体管开关(CMOS)→ 高电平(≈3.3V = 1)/低电平(≈0V = 0)
    • 存储:DRAM 电容充放电 / SSD 闪存浮栅电荷

📌 真实示例(add a, b 的底层):

1
2
3
4
5
6
7
8
9
10
11
12
Python: a + b

Bytecode: BINARY_ADD

机器码(x86-64): 48 01 D8 ; add rax, rbx

二进制: 01001000 00000001 11011000

CPU 执行:
- 指令译码器识别 01001000 → “64位加法”
- ALU 拉高 ‘ADD’ 控制线
- 寄存器文件输出 RAX/RBX 值 → ALU 相加 → 写回 RAX


📊 对比:不同语言的处理链

语言 典型路径 是否生成 Bytecode? 是否 JIT?
Python (CPython) .py → AST → BytecodeInterpreter .pyc
Java .javajavacBytecode (.class)JVM (JIT) ✅ (HotSpot)
C/C++ .cclang/gccAssemblyAssemblerMachine Code ❌(纯AOT)
Rust .rsrustc(LLVM)→ LLVM IROptimize → Machine Code ❌(但有 MIR/LLVM IR)
JavaScript (V8) JS → AST → Bytecode (Ignition)JIT (TurboFan) → Machine Code

💡 Python 的“慢”,本质是:高级抽象 + 动态类型 + 解释执行 bytecode
破解之道 = 类型提示(Type Hints) + Cython/Nuitka + JIT(如 PyPy)


🎯 总结图:Python 的全链路翻译过程

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
[Python 源码]


[Lexer + Parser] → AST(树结构)


[Compiler] → Bytecode(.pyc,平台无关)

├─▶ [CPython Interpreter] → 逐条执行 → 调用 C 函数 → CPU 执行

├─▶ [PyPy JIT] → 热点 trace 编译 → x86/ARM 机器码

└─▶ [Nuitka AOT] → 转 C++ → GCC → 原生机器码(.exe/.so)


[OS Loader] → 加载到内存


[CPU Fetch-Decode-Execute]


[0 和 1:晶体管开关 / 电平信号]