2. Databricks工作区与计算资源准备

在Databricks上做生成式AI，第一步不是写模型代码，而是把“工作区—计算—存储”这条底座搭对。工作区（Workspace）是组织Notebook、作业、集群和权限的容器；计算资源（Cluster）决定你能跑多大的模型、多快的推理；存储（DBFS与Volumes）决定数据、模型权重和向量索引放在哪里。三者配置不当，后续会出现显存不足、依赖冲突、数据读不到、成本失控等连锁问题。本节按“集群配置→Notebook交互→存储选择→GPU选型与成本控制”的顺序展开，并给出可直接参考的配置样例。

一、集群配置：先分清交互式与作业集群

Databricks集群分两类：交互式集群（All-Purpose）用于Notebook探索、调试，按秒计费但单价高；作业集群（Job Cluster）由作业触发创建、结束即销毁，单价低，适合生产。生成式AI开发阶段通常用交互式集群调通流程，再把稳定逻辑迁移到作业集群。

配置集群时重点看四个参数：Databricks Runtime（DBR）、节点类型、自动伸缩、Spark配置。做LLM微调或推理，应选带GPU的ML Runtime，例如 15.4 LTS ML (GPU, Scala 2.12, Spark 3.5)，它预装了PyTorch、Transformers、CUDA驱动，省去大量环境配置。节点类型按云厂商命名，如AWS的 g5.2xlarge（1×A10G 24GB）、p3.2xlarge（1×V100 16GB），Azure的 Standard_NC6s_v3。自动伸缩设置最小/最大Worker数，单机推理可设min=0、max=0，仅用Driver节点。

一个可参考的交互式GPU集群配置如下：

Cluster Mode: Single Node
Databricks Runtime: 15.4 LTS ML (GPU, Scala 2.12, Spark 3.5)
Node type: g5.2xlarge (1×A10G, 24GB VRAM, 8 vCPU, 32GB RAM)
Autoscaling: 禁用（单节点）
Spark Config:
  spark.databricks.cluster.profile singleNode
  spark.master local[*]
  spark.sql.shuffle.partitions 8
Environment variables:
  HF_HOME=/dbfs/volumes/ai/models/hf_cache
  TRANSFORMERS_CACHE=/dbfs/volumes/ai/models/hf_cache
Auto termination: 30 分钟

注意 spark.sql.shuffle.partitions 默认200，单节点小数据下会拖慢任务，调小到8～16更合适。自动终止建议设30分钟，避免忘记关机持续计费。

二、Notebook交互：把环境与数据路径固定下来

Notebook是Databricks的主要交互界面，支持Python、SQL、Scala、R混排。生成式AI开发中，建议在Notebook开头用 %pip 安装依赖并固定版本，避免不同会话环境漂移：

%pip install -q transformers==4.44.2 datasets==2.21.0 accelerate==0.33.0 peft==0.12.0
dbutils.library.restartPython()

restartPython() 是必须的，否则新装的包不会生效。之后用 dbutils.widgets 把模型名、数据路径、输出路径参数化，方便切换实验：

dbutils.widgets.text("model_name", "meta-llama/Llama-3.1-8B")
dbutils.widgets.text("data_path", "/Volumes/ai/raw/corpus/train.jsonl")
dbutils.widgets.text("output_path", "/Volumes/ai/checkpoints/llama31-8b-lora")

Notebook还支持 %run 引入公共函数、%md 写说明、display() 可视化DataFrame。调试GPU任务时，用 nvidia-smi 查看显存占用，用 torch.cuda.memory_allocated() 观察PyTorch实际分配，两者对照能快速定位显存泄漏。

三、DBFS与Volumes：数据与模型放哪里

DBFS（Databricks File System）是挂载在 /dbfs 的抽象文件系统，底层是云对象存储（S3/ADLS/GCS）。它适合放临时数据、日志、小文件，但不适合直接放模型权重和训练数据——DBFS写入有大小限制，且FUSE挂载性能差。

Unity Catalog Volumes是推荐的存储方式，路径形如 /Volumes/<catalog>/<schema>/<volume>，支持权限控制、版本追踪，且能直接被Spark和Python读写。建议按用途划分Volume：

• /Volumes/ai/raw/corpus/：原始训练语料，JSONL格式
• /Volumes/ai/processed/：清洗、分词后的数据
• /Volumes/ai/models/hf_cache/：HuggingFace模型缓存
• /Volumes/ai/checkpoints/：训练检查点
• /Volumes/ai/vector_index/：向量索引文件

读取时用 spark.read.json("/Volumes/ai/raw/corpus/") 或 datasets.load_dataset("json", data_files=...)。注意Volumes路径在Python中可直接用 open() 访问，无需 /dbfs 前缀。

四、GPU实例选型：按模型规模匹配显存

选GPU的核心是显存，不是算力。推理时显存需求约为 参数量 × 精度字节数 × 1.2（含KV Cache和框架开销）。例如7B模型用FP16推理约需 7×2×1.2≈16.8GB，T4 16GB会紧张，A10G 24GB更稳。微调时还要加上优化器状态和梯度，LoRA可大幅降低需求，全参微调则需 参数量×16字节 以上。

若显存不够，优先用4-bit量化（bitsandbytes）把权重压到1字节/参数，7B模型可降到约8GB，T4即可运行，但推理速度会下降。选型时先估算，再选最小满足的GPU，避免为“可能用到”的算力付费。

五、成本控制：三个立竿见影的动作

第一，自动终止。交互式集群设30分钟无活动自动关闭，这是最容易被忽略的浪费点。第二，用作业集群跑生产，单价约为交互式集群的1/3，且任务结束即释放。第三，Spot/抢占式实例，价格可低至按需的30%～50%，适合容错性好的训练任务，但需处理被回收时的检查点恢复。

此外，把HuggingFace缓存指向Volumes而非DBFS，避免每次重启重新下载模型；用 dbutils.fs 定期清理旧检查点；对推理服务用Model Serving按需扩缩，而非常驻集群。这些动作叠加，能把生成式AI实验的月度成本控制在可预期范围内。