前段时间我刚刚折腾完一套 Kubernetes 实验室。从容器、Deployment、Service到 Jenkins、GitHub Actions、Harbor再到 Prometheus、Grafana、Loki、Alertmanager一路搭下来对传统 Cloud Infra 已经算有了一套比较完整的实验环境。接下来我准备继续往AI Infra方向走。但刚开始研究时很容易碰到一个问题AI Infra 到底是什么是买一张 GPU安装 CUDA跑一个本地大模型安装 vLLM还是把 GPU 接进 Kubernetes网上一搜还会看到一大串名词CUDA PyTorch vLLM TensorRT-LLM KServe llm-d KubeRay GPU Operator ……如果一开始就追着这些工具安装很容易变成安装 ↓ 报错 ↓ 改配置 ↓ 终于运行 ↓ 但还是不知道为什么需要它所以这次我准备换一种方式。第一篇先不急着装东西而是回答三个最基本的问题AI Infra 和传统 Cloud Infra 有什么区别训练和推理是什么一张 GPU 到一个真正可以使用的大模型服务中间到底有哪些层先把地图画出来再一层一层搭。一、Cloud Infra 原来解决的是什么问题传统 Cloud Infra我们已经非常熟悉了。比如一个普通 Web 服务大致可以理解为Application ↓ Container ↓ Kubernetes ↓ Linux ↓ CPU / Memory / Network / Storage它最核心的问题其实就是怎样把计算、内存、网络和存储这些资源组织起来稳定运行大量应用。例如服务器忙了可以增加 Pod2 Pods ↓ 4 Pods ↓ 8 PodsKubernetes 再负责考虑CPU Memory Node 网络 存储把应用放到合适的机器上。我们平时观察的指标通常也是CPU Usage Memory Usage QPS Latency Network Disk IO这就是传统 Cloud Infra 最典型的世界。二、AI Infra 为什么又不一样了从外面看一个 AI 服务似乎也只是一个 API。例如用户提问 ↓ 服务器 ↓ 返回答案好像跟普通 Web 服务没有太大区别。但服务器内部发生的事情已经明显不同了。一个大语言模型请求大概会经历Prompt ↓ 模型 ↓ 推理程序 ↓ CUDA ↓ GPU ↓ 一个 Token 一个 Token 地生成答案于是马上出现了一些传统应用不太关心的问题模型能不能装进显存 GPU 有没有跑满 多个用户同时提问怎么办 第一个字为什么等很久 模型一次能处理多少请求 GPU 不够时怎么办所以我现在对 AI Infra 最简单的理解就是传统 Cloud Infra 主要解决“应用怎么运行”而 AI Infra 进一步解决“模型怎么在 GPU 上高效运行和提供服务”。三、Cloud Infra 和 AI Infra区别在哪可以先做一个非常简单的对比。Cloud InfraAI InfraCPUGPU内存内存 显存应用程序模型ContainerContainer ModelQPS请求数 Token 生成速度CPU 调度GPU 调度普通缓存模型缓存、KV CacheWeb ServingModel Serving当然这只是为了方便理解并不是说 AI Infra 不再需要 CPU、网络和存储。恰恰相反。AI Infra 通常是在原来的 Cloud Infra 基础上又增加了GPU 模型 推理引擎 显存管理 模型调度这些新的问题。可以把它理解成Cloud Infra AI Workload AI Infra四、训练和推理不是一回事谈 AI 时有两个词非常常见Training Inference也就是训练 推理简单来说训练是让模型学会东西。例如给模型大量数据让它不断调整内部参数。可以粗略理解为数据 ↓ 模型 ↓ 计算误差 ↓ 调整参数 ↓ 继续训练训练通常非常吃 GPU而且大型模型训练往往需要很多张 GPU。而推理则不同。模型已经训练好了我们只是使用它。例如输入问题 ↓ 模型计算 ↓ 生成答案ChatGPT、DeepSeek、Qwen 这些模型平时回答我们的过程本质上都是推理。这个系列主要研究的也是Inference Infra也就是大模型推理基础设施。原因很现实。我手里只有一张 RTX 3060。如果一开始研究几百张 GPU 高速互联 大规模分布式训练离实际实验环境太远。但只有一张消费级 GPU我们依然可以真正研究CUDA PyTorch 模型加载 显存 量化 vLLM 推理性能 GPU 调度 Kubernetes Model Serving 监控所以这条路线更适合个人实验室。五、一条 AI 请求到底经过哪些层现在可以先画一张简化的 AI Infra 技术栈。AI Application Chat / RAG / Agent ↓ Model Serving ↓ Inference Engine 例如 vLLM ↓ Model Qwen / Llama / Gemma ↓ PyTorch / CUDA ↓ NVIDIA Driver ↓ GPU如果以后进入 Kubernetes还会继续增加Kubernetes GPU Scheduling Observability Autoscaling所以整个系列大概是在研究这样一条路线应用 ↓ 模型服务 ↓ 推理引擎 ↓ 模型 ↓ PyTorch ↓ CUDA ↓ GPU第一篇先知道它们的位置就够了。后面会逐层拆开。六、几个必须先理解的核心层1. GPU最下面是 GPU。传统程序大量运行在 CPU 上而神经网络中有大量矩阵计算这类计算非常适合 GPU 并行处理。所以CPU 更擅长复杂控制逻辑 GPU 更擅长大量并行计算这也是今天 AI 服务器为什么几乎绕不开 GPU。我们的实验室里就是NVIDIA RTX 30602. CUDA但程序不能直接对 GPU 说“帮我把这个模型算一下。”中间需要一套软件接口。对于 NVIDIA GPU 来说最重要的就是CUDA现在先把它简单理解成让软件能够使用 NVIDIA GPU 进行计算的一套平台。所以关系大概是PyTorch ↓ CUDA ↓ NVIDIA Driver ↓ GPU下一篇会专门把这几层真正跑通。3. 模型再往上就是模型。例如Qwen Llama Gemma DeepSeek从 Infra 的角度来看一个大模型最直接的问题就是它很大。例如一个 7B 模型大约有 70 亿个参数。如果每个参数占 2 Bytes那么只算模型参数7 × 10^9 × 2 ≈ 14GB但 RTX 3060 常见显存只有 12GB。怎么办这就会引出以后经常碰到的一个概念Quantization 量化例如把模型从 16 位压缩到 8 位、4 位。第一篇先知道模型大小和 GPU 显存之间存在直接关系。后面我们会真正实验。4. 推理引擎模型能够跑起来并不等于跑得高效。如果只有一个用户一个请求 ↓ 模型 ↓ GPU问题还比较简单。但如果突然来了几十个请求用户 A ─┐ 用户 B ─┤ 用户 C ─┤ 用户 D ─┘ ↓ GPU怎么高效处理这就是Inference Engine推理引擎开始发挥作用的地方。这个系列会重点研究vLLM现在先把它理解为专门负责让大模型在 GPU 上更高效进行推理的软件。以后我们再研究Batching KV Cache TTFT TPOT Throughput这些概念。第一篇不展开。5. Serving 和调度再往上问题又变了。如果以后有多个模型、多个 GPU请求应该去哪个模型 模型应该放在哪张 GPU GPU 满了怎么办 服务挂了怎么办 怎么扩容这时候就会重新回到我们熟悉的Kubernetes并进一步出现KServe llm-d GPU Operator这些工具。现在我们暂时只需要知道Kubernetes 仍然会是 AI Infra 里非常重要的一层但我们不会一开始就上 Kubernetes。因为首先要搞明白模型到底是怎么跑到 GPU 上的七、完整技术栈长什么样把这些层放到一起可以画成这样┌──────────────────────────────┐ │ AI Application │ │ Chat / RAG / Agent │ ├──────────────────────────────┤ │ Model Serving │ │ KServe / llm-d │ ├──────────────────────────────┤ │ Inference Engine │ │ vLLM │ ├──────────────────────────────┤ │ Model │ │ Qwen / Llama / Gemma │ ├──────────────────────────────┤ │ Framework │ │ PyTorch │ ├──────────────────────────────┤ │ GPU Compute │ │ CUDA / NVIDIA Driver │ ├──────────────────────────────┤ │ Scheduling │ │ Kubernetes │ ├──────────────────────────────┤ │ Hardware │ │ GPU / CPU / RAM / Storage │ └──────────────────────────────┘这个系列不会一次把所有东西装上。而是从下面开始GPU ↓ CUDA ↓ PyTorch ↓ 模型 ↓ vLLM ↓ Docker ↓ Kubernetes ↓ Model Serving每出现一个新问题再加入一层新的 Infra。八、我们的 AI Infra 实验环境这次实验使用的是我现有的一台普通 PC。当前配置项目配置OSUbuntu 24.04 ServerCPUIntel Core i5-10400FMemory16GBStorage500GB NVMe SSDGPUNVIDIA GeForce RTX 3060GPU 数量1这其实是一套非常普通、甚至有点老的家用 PC 配置。没有H100 H200 B200 NVLink InfiniBand 多 GPU Server更谈不上什么大型 AI 集群。但我觉得这反而很适合作为个人 AI Infra 实验室。因为我们真正想学习的是GPU 是怎么工作的 CUDA 是什么 模型怎么进入 GPU 显存为什么不够 推理引擎解决了什么 Kubernetes 怎么管理 GPU AI 服务为什么需要新的调度方式这些原理并不会因为显卡不是 H100 就失去意义。九、读者需要什么样的电脑这里也特别说明一下上面的 RTX 3060 i5-10400F 16GB只是我当前实验室的配置并不是这个系列的硬性要求。如果读者也想跟着做其实配置可以比较灵活。大致可以分成几档。最基本Linux PC NVIDIA GPU 6GB8GB 显存 16GB RAM已经可以学习CUDA PyTorch GPU 基础 小模型推理 Docker GPU模型可以选得小一些或者使用量化模型。比较推荐Ubuntu 22.04 / 24.04 NVIDIA RTX 3060 12GB 或类似级别 GPU 16GB32GB RAM 500GB SSD这种配置比较适合完整跟这个系列。12GB 显存可以运行不少中小型量化模型也足够观察显存变化 模型加载 Batching KV Cache 并发这些现象。如果显卡更强例如RTX 3090 24GB RTX 4090 24GB RTX 5090 专业 GPU当然更好。可以尝试更大的模型、更长 Context、更高并发。如果没有 NVIDIA GPU 呢也不是完全不能学习。可以先通过CPU 云 GPU 其他 GPU 平台了解模型和 Serving。但是如果希望完整研究CUDA NVIDIA Container Toolkit Kubernetes GPU Scheduling GPU Operator那么有一张 NVIDIA GPU 会方便很多。所以这个系列最理想的实验环境依然是一台 Ubuntu PC 一张 NVIDIA GPU。并不要求服务器级硬件。十、为什么我们先不用虚拟机以前我的很多 Kubernetes 实验都是放在 VirtualBox VM 里面做的。但这次 AI Infra 第一阶段准备直接使用Ubuntu 24.04 Server RTX 3060裸机。原因很简单GPU 虚拟化本身就是一个新的大坑。如果把 GPU 放进虚拟机可能还要研究PCI Passthrough IOMMU VFIO vGPU这些技术当然也很有价值。但这样第一篇很快就会从学习 AI Infra变成学习 GPU 虚拟化所以第一阶段尽量减少变量。直接Linux ↓ Driver ↓ CUDA ↓ GPU先跑通。十一、第一个实验盘点我们的 GPU Node这一篇不急着安装模型。先把这台机器当成未来 AI Cluster 中的一台GPU Node看看它到底有什么资源。1. 查看系统hostnamectl以及cat /etc/os-release确认Ubuntu 24.04 x86_64 Kernel2. 查看 CPUlscpu或者lscpu | grep -E Model name|Socket|Core|Thread|CPU\(s\)虽然 AI 的主角是 GPU但 CPU 依然很重要。例如以后Tokenizer Web Server Docker Kubernetes都需要 CPU。3. 查看内存free -h我们的实验机目前是16GB RAM后面运行模型 Docker Kubernetes Prometheus Grafana都会占内存。所以 RAM 也是 AI Infra 的一个资源边界。4. 查看磁盘lsblk以及df -hAI 实验还有一个很现实的问题模型很占空间。以前一个 nginx 镜像可能只有几十 MB。现在一个模型可能5GB 10GB 20GB 甚至更大500GB SSD 看起来不少但下载几个模型之后很快就会开始关注磁盘空间。十二、系统到底有没有看到 RTX 3060首先lspci | grep -i nvidia如果能看到 NVIDIA GPU说明 PCIe 设备已经被 Linux 发现。然后运行nvidia-smi这个命令以后会非常常见。主要关注GPU Name Driver Version Memory Usage GPU Utilization Temperature Power第一篇我们可以先把这些数据记录下来。例如GPU RTX 3060 VRAM xxxx MiB GPU Utilization 0% Memory Used xxx MiB这就是整个实验室的初始 GPU Baseline。以后每运行一个模型都可以回来比较。十三、第一个很容易踩的坑nvidia-smi 正常不代表 CUDA Toolkit 已经安装这是初学 CUDA 时很容易混淆的一件事。运行nvidia-smi可能会看到CUDA Version: xx.x于是很容易认为CUDA 已经安装好了。但再运行nvcc --version却可能得到command not found其实并不矛盾。简单理解nvidia-smi 主要反映 NVIDIA Driver 能够支持到哪个 CUDA 版本 nvcc 属于 CUDA Toolkit也就是说Driver 正常并不等于CUDA Toolkit 已安装这个问题下一篇会详细实验。十四、第二个坑Linux 看到 GPU不等于 AI 程序能使用 GPU即使nvidia-smi完全正常也只是证明Linux ↓ NVIDIA Driver ↓ GPU已经打通。真正运行模型时我们还需要验证PyTorch ↓ CUDA ↓ Driver ↓ GPU所以以后安装 PyTorch 后还要运行类似import torch print(torch.cuda.is_available()) print(torch.cuda.get_device_name(0))真正看到True NVIDIA GeForce RTX 3060才说明Python AI Framework 到 GPU 的路径真正打通。十五、我们的实验室最终准备搭成什么样第一阶段Ubuntu ↓ NVIDIA Driver ↓ CUDA ↓ PyTorch ↓ Model然后加入推理引擎Model ↓ vLLM ↓ GPU再继续Docker ↓ Kubernetes ↓ GPU Scheduling最后再研究Model Serving Routing Autoscaling Observability也就是说我们不是第一天 ↓ 安装整个 AI 平台而是遇到问题 ↓ 理解问题 ↓ 加入新的 Infra ↓ 继续实验我觉得这样会更容易真正理解 AI Infra。十六、AI Infra 和之前的 Kubernetes 实验室有什么关系其实关系非常大。以前研究 Kubernetes我们关心资源 调度 服务 扩容 网络 监控到了 AI Infra这些问题依然存在。只不过资源变成了GPU 显存 模型服务对象也从普通应用变成了LLM所以 AI Infra 并不是把 Cloud Infra 推倒重来。更像是Cloud Infra 上出现了一种非常特殊、非常吃资源的新 Workload。于是原来的很多知识Linux Container Kubernetes Network Scheduling Observability突然又可以继续往 AI 世界延伸。这也是我想搭这个实验室的主要原因。十七、这个系列大概怎么走先定一个大方向GPU ↓ CUDA ↓ PyTorch ↓ 本地模型 ↓ vLLM ↓ 推理性能 ↓ Docker GPU ↓ Kubernetes GPU ↓ GPU Scheduling ↓ Model Serving ↓ Observability后面还可能继续扩展Distributed Inference KServe llm-d Agent Runtime但这些都先不急。第一阶段只需要回答一个问题模型到底是怎么跑到 GPU 上的十八、总结这一篇我们还没有真正运行大模型。但至少已经把地图画出来了。传统 Cloud Infra 可以简单理解成Hardware ↓ Linux ↓ Container ↓ Kubernetes ↓ Application到了 AI Infra则多出了一条非常重要的链GPU ↓ CUDA ↓ PyTorch ↓ Model ↓ Inference Engine ↓ Model Serving它们最终又会重新和Docker Kubernetes Scheduling Observability结合起来。而我们的实验室并不是什么豪华 AI Server。就是一台很普通的Ubuntu 24.04 Server i5-10400F 16GB RAM RTX 3060但这已经足够用来研究很多 AI Infra 最核心的问题。对于读者来说也不需要完全复制这套配置。有一台 Linux 电脑再有一张支持 CUDA 的 NVIDIA GPU就已经可以开始。下一篇为什么首先要研究 CUDA 和 PyTorch现在我们的 Linux 已经能够看到RTX 3060但这离“让模型真正运行在 GPU 上”还差几层。下一篇我们就从最底层开始。看看NVIDIA Driver CUDA CUDA Toolkit PyTorch GPU到底是什么关系。同时亲手验证CPU Tensor ↓ GPU Tensor真正发生了什么。下一篇《从零搭建一个 AI Infra 实验室②GPU、CUDA 与 PyTorch——模型到底是怎么跑到显卡上的》从这里开始我们真正让 RTX 3060 干活。 从零搭建一个 AI Infra 实验室①：AI Infra 到底是什么——我们准备搭一个怎样的实验室
前段时间我刚刚折腾完一套 Kubernetes 实验室。从容器、Deployment、Service到 Jenkins、GitHub Actions、Harbor再到 Prometheus、Grafana、Loki、Alertmanager一路搭下来对传统 Cloud Infra 已经算有了一套比较完整的实验环境。接下来我准备继续往AI Infra方向走。但刚开始研究时很容易碰到一个问题AI Infra 到底是什么是买一张 GPU安装 CUDA跑一个本地大模型安装 vLLM还是把 GPU 接进 Kubernetes网上一搜还会看到一大串名词CUDA PyTorch vLLM TensorRT-LLM KServe llm-d KubeRay GPU Operator ……如果一开始就追着这些工具安装很容易变成安装 ↓ 报错 ↓ 改配置 ↓ 终于运行 ↓ 但还是不知道为什么需要它所以这次我准备换一种方式。第一篇先不急着装东西而是回答三个最基本的问题AI Infra 和传统 Cloud Infra 有什么区别训练和推理是什么一张 GPU 到一个真正可以使用的大模型服务中间到底有哪些层先把地图画出来再一层一层搭。一、Cloud Infra 原来解决的是什么问题传统 Cloud Infra我们已经非常熟悉了。比如一个普通 Web 服务大致可以理解为Application ↓ Container ↓ Kubernetes ↓ Linux ↓ CPU / Memory / Network / Storage它最核心的问题其实就是怎样把计算、内存、网络和存储这些资源组织起来稳定运行大量应用。例如服务器忙了可以增加 Pod2 Pods ↓ 4 Pods ↓ 8 PodsKubernetes 再负责考虑CPU Memory Node 网络 存储把应用放到合适的机器上。我们平时观察的指标通常也是CPU Usage Memory Usage QPS Latency Network Disk IO这就是传统 Cloud Infra 最典型的世界。二、AI Infra 为什么又不一样了从外面看一个 AI 服务似乎也只是一个 API。例如用户提问 ↓ 服务器 ↓ 返回答案好像跟普通 Web 服务没有太大区别。但服务器内部发生的事情已经明显不同了。一个大语言模型请求大概会经历Prompt ↓ 模型 ↓ 推理程序 ↓ CUDA ↓ GPU ↓ 一个 Token 一个 Token 地生成答案于是马上出现了一些传统应用不太关心的问题模型能不能装进显存 GPU 有没有跑满 多个用户同时提问怎么办 第一个字为什么等很久 模型一次能处理多少请求 GPU 不够时怎么办所以我现在对 AI Infra 最简单的理解就是传统 Cloud Infra 主要解决“应用怎么运行”而 AI Infra 进一步解决“模型怎么在 GPU 上高效运行和提供服务”。三、Cloud Infra 和 AI Infra区别在哪可以先做一个非常简单的对比。Cloud InfraAI InfraCPUGPU内存内存 显存应用程序模型ContainerContainer ModelQPS请求数 Token 生成速度CPU 调度GPU 调度普通缓存模型缓存、KV CacheWeb ServingModel Serving当然这只是为了方便理解并不是说 AI Infra 不再需要 CPU、网络和存储。恰恰相反。AI Infra 通常是在原来的 Cloud Infra 基础上又增加了GPU 模型 推理引擎 显存管理 模型调度这些新的问题。可以把它理解成Cloud Infra AI Workload AI Infra四、训练和推理不是一回事谈 AI 时有两个词非常常见Training Inference也就是训练 推理简单来说训练是让模型学会东西。例如给模型大量数据让它不断调整内部参数。可以粗略理解为数据 ↓ 模型 ↓ 计算误差 ↓ 调整参数 ↓ 继续训练训练通常非常吃 GPU而且大型模型训练往往需要很多张 GPU。而推理则不同。模型已经训练好了我们只是使用它。例如输入问题 ↓ 模型计算 ↓ 生成答案ChatGPT、DeepSeek、Qwen 这些模型平时回答我们的过程本质上都是推理。这个系列主要研究的也是Inference Infra也就是大模型推理基础设施。原因很现实。我手里只有一张 RTX 3060。如果一开始研究几百张 GPU 高速互联 大规模分布式训练离实际实验环境太远。但只有一张消费级 GPU我们依然可以真正研究CUDA PyTorch 模型加载 显存 量化 vLLM 推理性能 GPU 调度 Kubernetes Model Serving 监控所以这条路线更适合个人实验室。五、一条 AI 请求到底经过哪些层现在可以先画一张简化的 AI Infra 技术栈。AI Application Chat / RAG / Agent ↓ Model Serving ↓ Inference Engine 例如 vLLM ↓ Model Qwen / Llama / Gemma ↓ PyTorch / CUDA ↓ NVIDIA Driver ↓ GPU如果以后进入 Kubernetes还会继续增加Kubernetes GPU Scheduling Observability Autoscaling所以整个系列大概是在研究这样一条路线应用 ↓ 模型服务 ↓ 推理引擎 ↓ 模型 ↓ PyTorch ↓ CUDA ↓ GPU第一篇先知道它们的位置就够了。后面会逐层拆开。六、几个必须先理解的核心层1. GPU最下面是 GPU。传统程序大量运行在 CPU 上而神经网络中有大量矩阵计算这类计算非常适合 GPU 并行处理。所以CPU 更擅长复杂控制逻辑 GPU 更擅长大量并行计算这也是今天 AI 服务器为什么几乎绕不开 GPU。我们的实验室里就是NVIDIA RTX 30602. CUDA但程序不能直接对 GPU 说“帮我把这个模型算一下。”中间需要一套软件接口。对于 NVIDIA GPU 来说最重要的就是CUDA现在先把它简单理解成让软件能够使用 NVIDIA GPU 进行计算的一套平台。所以关系大概是PyTorch ↓ CUDA ↓ NVIDIA Driver ↓ GPU下一篇会专门把这几层真正跑通。3. 模型再往上就是模型。例如Qwen Llama Gemma DeepSeek从 Infra 的角度来看一个大模型最直接的问题就是它很大。例如一个 7B 模型大约有 70 亿个参数。如果每个参数占 2 Bytes那么只算模型参数7 × 10^9 × 2 ≈ 14GB但 RTX 3060 常见显存只有 12GB。怎么办这就会引出以后经常碰到的一个概念Quantization 量化例如把模型从 16 位压缩到 8 位、4 位。第一篇先知道模型大小和 GPU 显存之间存在直接关系。后面我们会真正实验。4. 推理引擎模型能够跑起来并不等于跑得高效。如果只有一个用户一个请求 ↓ 模型 ↓ GPU问题还比较简单。但如果突然来了几十个请求用户 A ─┐ 用户 B ─┤ 用户 C ─┤ 用户 D ─┘ ↓ GPU怎么高效处理这就是Inference Engine推理引擎开始发挥作用的地方。这个系列会重点研究vLLM现在先把它理解为专门负责让大模型在 GPU 上更高效进行推理的软件。以后我们再研究Batching KV Cache TTFT TPOT Throughput这些概念。第一篇不展开。5. Serving 和调度再往上问题又变了。如果以后有多个模型、多个 GPU请求应该去哪个模型 模型应该放在哪张 GPU GPU 满了怎么办 服务挂了怎么办 怎么扩容这时候就会重新回到我们熟悉的Kubernetes并进一步出现KServe llm-d GPU Operator这些工具。现在我们暂时只需要知道Kubernetes 仍然会是 AI Infra 里非常重要的一层但我们不会一开始就上 Kubernetes。因为首先要搞明白模型到底是怎么跑到 GPU 上的七、完整技术栈长什么样把这些层放到一起可以画成这样┌──────────────────────────────┐ │ AI Application │ │ Chat / RAG / Agent │ ├──────────────────────────────┤ │ Model Serving │ │ KServe / llm-d │ ├──────────────────────────────┤ │ Inference Engine │ │ vLLM │ ├──────────────────────────────┤ │ Model │ │ Qwen / Llama / Gemma │ ├──────────────────────────────┤ │ Framework │ │ PyTorch │ ├──────────────────────────────┤ │ GPU Compute │ │ CUDA / NVIDIA Driver │ ├──────────────────────────────┤ │ Scheduling │ │ Kubernetes │ ├──────────────────────────────┤ │ Hardware │ │ GPU / CPU / RAM / Storage │ └──────────────────────────────┘这个系列不会一次把所有东西装上。而是从下面开始GPU ↓ CUDA ↓ PyTorch ↓ 模型 ↓ vLLM ↓ Docker ↓ Kubernetes ↓ Model Serving每出现一个新问题再加入一层新的 Infra。八、我们的 AI Infra 实验环境这次实验使用的是我现有的一台普通 PC。当前配置项目配置OSUbuntu 24.04 ServerCPUIntel Core i5-10400FMemory16GBStorage500GB NVMe SSDGPUNVIDIA GeForce RTX 3060GPU 数量1这其实是一套非常普通、甚至有点老的家用 PC 配置。没有H100 H200 B200 NVLink InfiniBand 多 GPU Server更谈不上什么大型 AI 集群。但我觉得这反而很适合作为个人 AI Infra 实验室。因为我们真正想学习的是GPU 是怎么工作的 CUDA 是什么 模型怎么进入 GPU 显存为什么不够 推理引擎解决了什么 Kubernetes 怎么管理 GPU AI 服务为什么需要新的调度方式这些原理并不会因为显卡不是 H100 就失去意义。九、读者需要什么样的电脑这里也特别说明一下上面的 RTX 3060 i5-10400F 16GB只是我当前实验室的配置并不是这个系列的硬性要求。如果读者也想跟着做其实配置可以比较灵活。大致可以分成几档。最基本Linux PC NVIDIA GPU 6GB8GB 显存 16GB RAM已经可以学习CUDA PyTorch GPU 基础 小模型推理 Docker GPU模型可以选得小一些或者使用量化模型。比较推荐Ubuntu 22.04 / 24.04 NVIDIA RTX 3060 12GB 或类似级别 GPU 16GB32GB RAM 500GB SSD这种配置比较适合完整跟这个系列。12GB 显存可以运行不少中小型量化模型也足够观察显存变化 模型加载 Batching KV Cache 并发这些现象。如果显卡更强例如RTX 3090 24GB RTX 4090 24GB RTX 5090 专业 GPU当然更好。可以尝试更大的模型、更长 Context、更高并发。如果没有 NVIDIA GPU 呢也不是完全不能学习。可以先通过CPU 云 GPU 其他 GPU 平台了解模型和 Serving。但是如果希望完整研究CUDA NVIDIA Container Toolkit Kubernetes GPU Scheduling GPU Operator那么有一张 NVIDIA GPU 会方便很多。所以这个系列最理想的实验环境依然是一台 Ubuntu PC 一张 NVIDIA GPU。并不要求服务器级硬件。十、为什么我们先不用虚拟机以前我的很多 Kubernetes 实验都是放在 VirtualBox VM 里面做的。但这次 AI Infra 第一阶段准备直接使用Ubuntu 24.04 Server RTX 3060裸机。原因很简单GPU 虚拟化本身就是一个新的大坑。如果把 GPU 放进虚拟机可能还要研究PCI Passthrough IOMMU VFIO vGPU这些技术当然也很有价值。但这样第一篇很快就会从学习 AI Infra变成学习 GPU 虚拟化所以第一阶段尽量减少变量。直接Linux ↓ Driver ↓ CUDA ↓ GPU先跑通。十一、第一个实验盘点我们的 GPU Node这一篇不急着安装模型。先把这台机器当成未来 AI Cluster 中的一台GPU Node看看它到底有什么资源。1. 查看系统hostnamectl以及cat /etc/os-release确认Ubuntu 24.04 x86_64 Kernel2. 查看 CPUlscpu或者lscpu | grep -E Model name|Socket|Core|Thread|CPU\(s\)虽然 AI 的主角是 GPU但 CPU 依然很重要。例如以后Tokenizer Web Server Docker Kubernetes都需要 CPU。3. 查看内存free -h我们的实验机目前是16GB RAM后面运行模型 Docker Kubernetes Prometheus Grafana都会占内存。所以 RAM 也是 AI Infra 的一个资源边界。4. 查看磁盘lsblk以及df -hAI 实验还有一个很现实的问题模型很占空间。以前一个 nginx 镜像可能只有几十 MB。现在一个模型可能5GB 10GB 20GB 甚至更大500GB SSD 看起来不少但下载几个模型之后很快就会开始关注磁盘空间。十二、系统到底有没有看到 RTX 3060首先lspci | grep -i nvidia如果能看到 NVIDIA GPU说明 PCIe 设备已经被 Linux 发现。然后运行nvidia-smi这个命令以后会非常常见。主要关注GPU Name Driver Version Memory Usage GPU Utilization Temperature Power第一篇我们可以先把这些数据记录下来。例如GPU RTX 3060 VRAM xxxx MiB GPU Utilization 0% Memory Used xxx MiB这就是整个实验室的初始 GPU Baseline。以后每运行一个模型都可以回来比较。十三、第一个很容易踩的坑nvidia-smi 正常不代表 CUDA Toolkit 已经安装这是初学 CUDA 时很容易混淆的一件事。运行nvidia-smi可能会看到CUDA Version: xx.x于是很容易认为CUDA 已经安装好了。但再运行nvcc --version却可能得到command not found其实并不矛盾。简单理解nvidia-smi 主要反映 NVIDIA Driver 能够支持到哪个 CUDA 版本 nvcc 属于 CUDA Toolkit也就是说Driver 正常并不等于CUDA Toolkit 已安装这个问题下一篇会详细实验。十四、第二个坑Linux 看到 GPU不等于 AI 程序能使用 GPU即使nvidia-smi完全正常也只是证明Linux ↓ NVIDIA Driver ↓ GPU已经打通。真正运行模型时我们还需要验证PyTorch ↓ CUDA ↓ Driver ↓ GPU所以以后安装 PyTorch 后还要运行类似import torch print(torch.cuda.is_available()) print(torch.cuda.get_device_name(0))真正看到True NVIDIA GeForce RTX 3060才说明Python AI Framework 到 GPU 的路径真正打通。十五、我们的实验室最终准备搭成什么样第一阶段Ubuntu ↓ NVIDIA Driver ↓ CUDA ↓ PyTorch ↓ Model然后加入推理引擎Model ↓ vLLM ↓ GPU再继续Docker ↓ Kubernetes ↓ GPU Scheduling最后再研究Model Serving Routing Autoscaling Observability也就是说我们不是第一天 ↓ 安装整个 AI 平台而是遇到问题 ↓ 理解问题 ↓ 加入新的 Infra ↓ 继续实验我觉得这样会更容易真正理解 AI Infra。十六、AI Infra 和之前的 Kubernetes 实验室有什么关系其实关系非常大。以前研究 Kubernetes我们关心资源 调度 服务 扩容 网络 监控到了 AI Infra这些问题依然存在。只不过资源变成了GPU 显存 模型服务对象也从普通应用变成了LLM所以 AI Infra 并不是把 Cloud Infra 推倒重来。更像是Cloud Infra 上出现了一种非常特殊、非常吃资源的新 Workload。于是原来的很多知识Linux Container Kubernetes Network Scheduling Observability突然又可以继续往 AI 世界延伸。这也是我想搭这个实验室的主要原因。十七、这个系列大概怎么走先定一个大方向GPU ↓ CUDA ↓ PyTorch ↓ 本地模型 ↓ vLLM ↓ 推理性能 ↓ Docker GPU ↓ Kubernetes GPU ↓ GPU Scheduling ↓ Model Serving ↓ Observability后面还可能继续扩展Distributed Inference KServe llm-d Agent Runtime但这些都先不急。第一阶段只需要回答一个问题模型到底是怎么跑到 GPU 上的十八、总结这一篇我们还没有真正运行大模型。但至少已经把地图画出来了。传统 Cloud Infra 可以简单理解成Hardware ↓ Linux ↓ Container ↓ Kubernetes ↓ Application到了 AI Infra则多出了一条非常重要的链GPU ↓ CUDA ↓ PyTorch ↓ Model ↓ Inference Engine ↓ Model Serving它们最终又会重新和Docker Kubernetes Scheduling Observability结合起来。而我们的实验室并不是什么豪华 AI Server。就是一台很普通的Ubuntu 24.04 Server i5-10400F 16GB RAM RTX 3060但这已经足够用来研究很多 AI Infra 最核心的问题。对于读者来说也不需要完全复制这套配置。有一台 Linux 电脑再有一张支持 CUDA 的 NVIDIA GPU就已经可以开始。下一篇为什么首先要研究 CUDA 和 PyTorch现在我们的 Linux 已经能够看到RTX 3060但这离“让模型真正运行在 GPU 上”还差几层。下一篇我们就从最底层开始。看看NVIDIA Driver CUDA CUDA Toolkit PyTorch GPU到底是什么关系。同时亲手验证CPU Tensor ↓ GPU Tensor真正发生了什么。下一篇《从零搭建一个 AI Infra 实验室②GPU、CUDA 与 PyTorch——模型到底是怎么跑到显卡上的》从这里开始我们真正让 RTX 3060 干活。