2. Databricks AI运行时与资源模型

在Databricks上跑AI任务，性能问题往往不是模型本身造成的，而是“任务被放到了什么计算资源上、这些资源如何被调度和隔离”决定的。理解运行时与资源模型，是后续做性能优化和容量治理的前提。本节把Databricks支撑AI任务的核心组件拆开来看：GPU/CPU集群、Photon引擎、ML Runtime、Serverless计算，以及它们背后的资源分配、隔离与调度机制。

一、计算平面的四个关键组件

GPU/CPU集群是AI任务的物理承载。Databricks集群分为两类节点：Driver负责协调、调度与结果汇总，Worker负责实际执行。AI场景中，GPU Worker通常选用单卡或多卡机型（如单节点8×A100/H100），CPU Worker则用于数据预处理、特征工程、轻量推理。关键参数包括：Worker数量、每Worker的GPU数、实例类型、自动伸缩上下限。GPU集群与CPU集群的本质差异在于：GPU节点按“卡”计费且显存是硬约束，CPU节点按核数计费且内存弹性更大。

Photon引擎是Databricks自研的C++向量化查询引擎，运行在Worker的CPU上。它把Spark的逐行处理改为按批（batch）向量化执行，并利用SIMD指令和多核并行。对AI任务而言，Photon主要加速数据读取、特征拼接、ETL和SQL预处理环节，不直接参与GPU上的模型前向/反向计算。因此“Photon + GPU”是常见组合：Photon把数据准备好，GPU专注训练或推理。

ML Runtime是在标准Databricks Runtime之上预装了ML/AI库的运行时版本，例如PyTorch、TensorFlow、scikit-learn、XGBoost、MLflow以及GPU驱动（CUDA/cuDNN）。选择ML Runtime而不是普通Runtime，可以避免手动安装GPU驱动和框架版本冲突。ML Runtime还针对GPU做了驱动与库的版本对齐，这是AI任务能否稳定跑起来的关键。

Serverless计算把集群管理交给Databricks：用户不指定节点类型和数量，平台按负载自动分配资源，任务结束即释放。它适合突发性、短时、交互式AI任务（如Notebook探索、轻量推理、定时特征任务），但不适合需要长时间独占GPU、精细控制拓扑或自定义驱动的训练任务。

二、资源分配：Driver、Worker 与 GPU 卡

一个AI任务提交后，资源分配遵循“先定集群、再分执行单元”的顺序。以一次典型的分布式训练为例：Driver 负责解析代码、构建执行计划、分发任务；每个 Worker 上的 Executor 拿到一个任务分片，在 GPU 上执行前向/反向计算。GPU 的分配粒度是“卡”，一个 Worker 上的多张卡可以被同一任务的不同进程使用，也可以被多个任务共享（取决于集群配置）。

这里有一个容易踩坑的点：GPU 数量不等于并行度。如果数据加载（DataLoader）的 worker 数不足，GPU 会因等待数据而空转，表现为 GPU 利用率低但 CPU 打满。因此资源分配要同时看三组参数：GPU 卡数、每卡对应的 CPU 核数、以及 DataLoader 的并行 worker 数。经验上，每张 GPU 配 4～8 个 CPU 核、2～4 个 DataLoader worker 是较常见的起点，具体需按数据管道复杂度调整。

三、隔离机制：Job、Cluster 与 Pool

隔离决定了“一个任务会不会影响另一个任务”。Databricks 提供三个层次的隔离：

• Job 隔离：不同 Job 使用不同集群，互不抢占资源，适合生产训练任务。
• Cluster 隔离：同一集群内多个 Notebook 共享资源，适合探索阶段，但一个重任务可能拖慢其他任务。
• Pool 隔离：实例池预先保留空闲实例，降低集群启动延迟，同时通过标签控制哪些团队可以使用。

对 AI 任务而言，训练任务建议用独立 Job 集群，避免被交互式查询抢占 GPU；推理服务则更适合 Serverless 或专用集群，保证延迟稳定。

四、调度机制：从 FIFO 到自动伸缩

Databricks 的调度分为集群级和任务级。集群级调度决定 Worker 何时启动、何时回收，核心是自动伸缩：根据待处理任务队列长度，在 min/max Worker 之间动态调整。任务级调度决定同一集群内多个任务如何排队，常见策略有 FIFO（先到先执行）和公平调度（按权重分配）。

AI 任务的调度有两个特殊约束：一是 GPU 资源稀缺，调度器需要感知 GPU 卡数而非仅看 Worker 数；二是训练任务通常需要“全有或全无”的资源，即要么拿到全部 GPU 开始训练，要么等待，避免部分启动导致通信死锁。因此在大规模训练中，常配合 Gang Scheduling（成组调度）思路，确保所有 Worker 同时就绪。

五、Serverless 与 Photon 的适用边界

Serverless 计算把资源分配和调度完全托管，用户只需提交代码。它的优势是启动快、按用量计费、无需管理集群；局限是无法指定 GPU 型号、无法精细控制拓扑、冷启动对延迟敏感任务不友好。因此 Serverless 更适合：特征工程、轻量推理、定时批处理、Notebook 探索。而需要多卡通信、自定义 CUDA 版本、长时间独占 GPU 的训练任务，仍应使用标准 GPU 集群。

Photon 的边界同样清晰：它加速的是 CPU 上的 SQL/DataFrame 操作，对 GPU 计算无直接帮助。判断是否启用 Photon，可以看任务中数据预处理占比——如果 ETL 和特征拼接耗时超过总时长的 30%，开启 Photon 通常有明显收益；如果任务几乎全部时间在 GPU 上做矩阵运算，Photon 的收益有限。

六、一个可参考的资源选型对照