1. Databricks AI工作负载全景与性能容量挑战

在 Databricks 上运行 AI 工作负载，和传统 Spark 批处理有本质区别：同一套 Lakehouse 平台要同时承载数据准备、模型训练、在线推理和检索服务，而这些负载对算力、内存、网络和存储的诉求彼此冲突。理解这些冲突，是后续做性能优化与容量治理的前提。本节先建立一张“负载全景图”，再逐类拆解它们的运行形态、资源画像与典型瓶颈。

一、五类典型 AI 负载的运行形态

特征工程是整条链路的起点，通常以 Spark 或 PySpark 作业运行在通用集群上，把原始表加工成训练用的特征表。它的特点是数据量大、计算密集但模型无关，瓶颈多出现在 shuffle、倾斜分区和 Delta 写入的小文件上。在 Databricks 上常配合 Feature Store 落地，特征表一旦被多个模型复用，就会从“一次性作业”变成“被反复读取的共享资产”，容量压力随之上升。

LLM 训练（含预训练与继续训练）是资源最重的负载，运行在 GPU 集群上，依赖多机多卡的集合通信（AllReduce、AllGather）。它的瓶颈往往不在单卡算力，而在 GPU 利用率被数据加载、checkpoint 写入和网络带宽拖低。训练任务通常长时间独占集群，是容量规划中最难压缩的部分。

微调（SFT、LoRA/QLoRA）介于训练与推理之间，数据量小、迭代快，常见形态是单机多卡或少量多卡。LoRA 类方法显存占用低，但会引入大量短周期实验任务，造成 GPU 集群“碎片化占用”——每个任务都不大，却频繁申请和释放资源，调度开销和排队时间反而成为主要痛点。

推理是延迟敏感型负载，运行在 Model Serving 或 GPU 推理集群上，核心指标是首 token 延迟（TTFT）、每 token 输出延迟（TPOT）和吞吐。它和训练最大的区别是：训练追求吞吐，推理要在延迟和吞吐之间取平衡，且流量呈波峰波谷，容量必须按峰值预留，否则尾延迟会迅速恶化。

向量检索支撑 RAG 场景，由嵌入模型 + 向量索引（如 Databricks Vector Search）组成。嵌入生成是批处理式的 GPU/CPU 负载，索引构建和查询则是内存与 I/O 密集型。它的瓶颈常出现在索引刷新频率、向量维度与召回率之间的权衡上。

二、资源画像：为什么它们不能共用一套容量策略

把五类负载放在一起看，会发现它们的资源画像差异极大。特征工程吃 CPU、内存和 shuffle 带宽，对 GPU 无需求；训练吃 GPU 显存和卡间网络，对 CPU 相对不敏感；微调吃显存但任务短小；推理吃显存和延迟，对并发敏感；向量检索吃内存和 I/O。这意味着如果用一个集群“通吃”，必然出现某类资源被闲置、另一类被抢空的情况。

更麻烦的是时间维度。训练任务可能连续占用 GPU 数小时到数天，微调任务几分钟到几十分钟，推理服务则要求 7×24 常驻。三者混部时，短任务被长任务阻塞、在线服务被离线任务抢占，是 Databricks 上最常见的容量投诉来源。因此容量治理的第一原则不是“买更多 GPU”，而是按负载类型做资源池隔离与优先级划分。

三、性能瓶颈的四个高发位置

结合实践，AI 负载的性能问题高度集中在四个位置，值得在优化前优先排查：

• 数据供给跟不上算力：GPU 利用率长期低于 60%，往往是 DataLoader 读取 Delta 表时小文件过多、或未做缓存，导致 GPU 空转等数据。
• Checkpoint 与日志写入抖动：训练过程中周期性卡顿，多因 checkpoint 同步写入共享存储，与数据读取争抢带宽。
• 推理批处理策略不当：为压低 TTFT 而关闭动态批处理，导致吞吐上不去、单位成本高；反之批太大又推高尾延迟。
• 特征与索引重复计算：同一份特征被多个作业各自重算，或向量索引频繁全量重建，造成算力与存储的隐性浪费。

四、容量治理的核心痛点

容量治理要回答三个问题：需要多少资源、资源被谁占用、如何在不牺牲性能的前提下压缩浪费。在 Databricks AI 场景下，痛点具体表现为：