DreamFusion 通过分数蒸馏采样技术，把二维扩散模型学到的先验知识迁移到三维表示中，能够在没有大规模三维标注数据的情况下生成可用的 NeRF 或网格资产。这类工作对运行环境极为敏感：PyTorch 版本、CUDA 版本、xformers、tinycudann、nvdiffrast 等扩展之间的兼容关系稍有不慎就会导致显存溢出或编译失败。把服务容器化之后，开发机、训练节点和推理集群可以使用完全一致的运行时环境，减少因驱动差异带来的问题。

镜像选型与基础环境固化

容器化 DreamFusion 的第一步是选择合适的基础镜像，而不是直接使用某个通用 Python 镜像。推荐从 NVIDIA 官方维护的 CUDA 镜像开始，例如 nvidia/cuda:12.1.0-cudnn8-devel-ubuntu22.04，因为后续需要编译 tinycudann 和 nvdiffrast 等 CUDA 扩展，devel 版本包含 nvcc 工具链。如果只是想运行已经编译好的 wheel 包，可以选择 runtime 版本，但容易在 pip 安装时缺少头文件。

在基础镜像之上，建议固定 PyTorch 版本和 CUDA 变体，不要简单执行 pip install torch。可以提前确认 PyTorch 官方提供的 cu121 或 cu118 索引地址，然后在 Dockerfile 中显式指定。例如使用 pip install torch==2.1.0 torchvision==0.16.0 --index-url https://download.pytorch.org/whl/cu121。这样做能避免后续安装扩展时自动拉取不匹配的 CUDA 版本。

FROM nvidia/cuda:12.1.0-cudnn8-devel-ubuntu22.04
ENV DEBIAN_FRONTEND=noninteractive \
    PIP_NO_CACHE_DIR=1 \
    PYTHONUNBUFFERED=1
RUN apt-get update && apt-get install -y \
    python3.10 python3-pip git build-essential \
    libgl1 libglib2.0-0 && \
    ln -s /usr/bin/python3 /usr/bin/python && \
    rm -rf /var/lib/apt/lists/*
RUN pip install torch==2.1.0 torchvision==0.16.0 \
    --index-url https://download.pytorch.org/whl/cu121
WORKDIR /opt/dreamfusion
COPY requirements.txt .
RUN pip install -r requirements.txt

这里把 apt 安装和 pip 安装分开成两个 RUN 层，目的是充分利用 Docker 构建缓存。依赖列表没有变化时，已经安装好的系统包和 PyTorch 不会重新下载，构建速度会快很多。如果 DreamFusion 依赖了需要从源码编译的扩展，还需要保证 gcc、g++ 和 CUDA 编译器版本一致。

扩展安装与构建缓存策略

DreamFusion 常使用 tinycudann 作为神经网络加速组件，这个库需要从源码编译，编译时间较长。直接把 git clone 和 cmake 构建都放进 Dockerfile 会导致每次构建都重新编译。更合理的做法是先拉取源码并安装，再把构建产物保留在镜像层中。例如：

RUN git clone --recursive https://github.com/NVlabs/tiny-cuda-nn /opt/tiny-cuda-nn && \
    cd /opt/tiny-cuda-nn/bindings/torch && \
    python setup.py install

如果网络环境不稳定，可以先在宿主机上下载源码压缩包，通过 COPY 命令复制到镜像内，再执行构建。源码包形式比 git clone 更容易做哈希校验，也能避免构建过程中因网络波动导致失败。nvdiffrast 的安装较简单，可以使用 pip 直接安装预编译包，但同样需要注意 CUDA 版本匹配。

构建加速的关键在于充分利用 Docker 的层缓存：把变动最少的系统依赖放在最前面，把经常修改的项目代码放在最后。requirements.txt 如果没有变化，pip 安装层会被复用。只有最后一层 COPY 项目代码会频繁失效，但这一层只涉及文件复制，不会重新执行昂贵的编译步骤。

GPU 运行时配置与显存管理

容器本身不会自动获得 GPU 访问权限，需要在运行时通过 NVIDIA Container Toolkit 暴露设备。启动容器时必须加上 --gpus all 参数，或者指定具体设备 --gpus device=0,1。如果宿主机安装了 nvidia-container-runtime，也可以直接在 Docker Compose 中用 deploy.resources.reservations.devices 来声明 GPU 资源。

DreamFusion 生成高分辨率模型时，显存占用可能超过单个 GPU 的容量。容器化之后可以通过环境变量限制 PyTorch 的显存分配，例如设置 PYTORCH_CUDA_ALLOC_CONF=backend:cudaMallocAsync，但更有效的方式是让服务在启动时根据可用显存动态调整分辨率或 batch size。共享内存也是常被忽略的点，默认 Docker 容器的 /dev/shm 只有 64MB，而 PyTorch 多进程数据加载会使用共享内存，容易导致程序崩溃。启动时应配置 --shm-size=8g 或者 --ipc=host。

docker run --gpus all \
  --shm-size=8g \
  -p 8000:8000 \
  -v /data/models:/models \
  dreamfusion-service:latest

如果服务需要同时处理多个请求，建议根据单卡显存大小设置最大并发数，避免多个任务同时占用显存导致 OOM。可以在应用层加一个简单的信号量或队列，超过并发限制时返回 503 让客户端稍后重试。容器编排层也可以配合进行水平扩展。

服务化封装与接口设计

容器化的最终目的是把 DreamFusion 暴露成一个可调用的 HTTP 服务。最简单的方式是使用 FastAPI 封装一个异步接口，接收文本提示词和生成参数，返回任务 ID 或直接返回 3D 文件。由于生成过程耗时较长，直接同步返回会占用 Web 服务器的工作线程，建议采用任务队列模式，客户端提交任务后轮询状态。

from fastapi import FastAPI, BackgroundTasks
from pydantic import BaseModel
import uuid
app = FastAPI()
class GenerateRequest(BaseModel):
    prompt: str
    steps: int = 64
jobs = {}
def run_dreamfusion(job_id: str, prompt: str, steps: int):
    jobs[job_id] = "running"
    # 调用 DreamFusion 生成逻辑
    # result = dreamfusion_generate(prompt, steps)
    jobs[job_id] = "done"
@app.post("/generate")
async def generate(req: GenerateRequest, background_tasks: BackgroundTasks):
    job_id = str(uuid.uuid4())
    jobs[job_id] = "queued"
    background_tasks.add_task(run_dreamfusion, job_id, req.prompt, req.steps)
    return {"job_id": job_id}
@app.get("/status/{job_id}")
async def status(job_id: str):
    return {"status": jobs.get(job_id, "not_found")}

这个接口设计把生成任务放入后台队列，前端通过轮询获取结果。生产环境中还可以把状态存储到 Redis，用 Celery 或 Dramatiq 管理任务，容器水平扩展时也能共享任务状态。模型权重文件建议通过挂载卷注入，不要直接打进镜像，避免镜像体积过大。

编排部署与健康检查

单机部署使用 Docker Compose 足够，多机调度则需要 Kubernetes 配合 GPU 插件。Compose 配置中要声明 GPU 设备、共享内存大小和环境变量，保证容器重启后能自动恢复。健康检查可以设置一个轻量接口，避免把生成接口当作存活探针。

version: "3.8"
services:
  dreamfusion:
    image: dreamfusion-service:latest
    ports:
      - "8000:8000"
    volumes:
      - /data/models:/models
      - /data/output:/output
    shm_size: "8gb"
    environment:
      - NVIDIA_VISIBLE_DEVICES=all
    deploy:
      resources:
        reservations:
          devices:
            - driver: nvidia
              count: 1
              capabilities: [gpu]

Kubernetes 场景下需要安装 NVIDIA Device Plugin，并在 Pod 中声明 nvidia.com/gpu 资源。节点上的驱动版本、容器运行时和插件版本都要保持一致，否则会出现 GPU 调度成功但容器内无法识别设备的问题。日志采集建议统一输出到 stdout，把生成进度、显存占用、错误堆栈都打印成结构化 JSON，方便后续监控和告警。

容器化 DreamFusion 服务不是把代码复制进镜像再运行那么简单，核心在于把 CUDA 工具链、扩展编译、GPU 调度和接口封装这几个环节都纳入可复现的流程中。做好这些基础工作之后，文本生成3D的能力才能真正变成一个稳定的推理服务，而不是实验室里偶尔能跑通的一段脚本。