AI Deploy大模型本地部署帮你部署

Modal冷启动优化：预热容器与卷挂载配置

Modal 在所有 `enter` 方法完成后才接收输入；本文说明如何配置 warm container、`@modal.enter` 与 Volume 权重缓存，并给出部署命令、首请求延迟验证方法和常见同步问题排查。

Modal 冷启动优化可以拆成两步：用 scaledown_window、min_containers 和 buffer_containers 保持 warm container，再把模型权重缓存到 Modal Volume，减少服务重启后的重复下载。在大模型部署时，把一次性加载放进 @modal.enter，再部署并比较空闲后的首请求与后续请求。下面直接给出配置、验证和排错路径。

大模型部署：先定位冷启动

Modal 的冷启动性能文档说明，没有 ready container 时，Modal 必须启动新容器，这就是 cold start。延迟可能来自等待 warm container 的排队，也可能来自新容器第一次调用时的 initialization；容器启动后，全局代码、imports 和 enter 方法仍需完成。如果主要瓶颈是启动时下载权重，官方建议提前下载，而不是等容器启动后再下载。

预热容器：选择保留策略

同一指南列出了三项控制 warm container 数量的参数：

  • scaledown_window：默认最大空闲时间为 60 秒，可设置为 2 秒至 20 分钟。延长它会降低后续请求遇到 cold start 的机会，但空闲期间占用的 GPU 预约或剩余内存仍会产生费用。
  • min_containers：为容器数量设置下限，使 Function 不缩容到零。
  • buffer_containers：在 Function 活动期间提供额外容器，适合需要应对突发请求的流量。

延长窗口并不保证完全没有冷启动，只是让容器保留更久；是否值得则取决于你的空闲时长和资源成本。

把初始化放进 @modal.enter

Modal 的容器生命周期钩子文档说明，@modal.enter 会在新容器启动时运行，适合加载模型权重、导入镜像中特有软件包等一次性工作。生命周期钩子要求使用 @app.cls 类式定义，因此相关装饰器分别是：

@app.cls

@modal.enter

容器必须等所有 enter 方法完成后才会接收输入。把工作移入 enter 并不会消除这段延迟，只是把它移到预热阶段；能够并发读取的大文件也不应串行读取。

权重缓存：用 Volume 挂载模型文件

Modal 的 Volumes 文档将其定义为面向 write-once、read-many 工作负载的分布式文件系统，模型权重正适合这种模式。通用创建与挂载配置如下：

vol = modal.Volume.from_name("my-volume", create_if_missing=True)

@app.function(volumes={"/data": vol})

这里的 /data 是挂载路径，不是所有模型都应使用的固定缓存目录。容器创建时会看到 Volume 的最新状态；其他容器后续提交的内容不会自动出现，需要显式调用 .reload()。容器内的修改也需要 commit 才能对外可见，Modal 会后台定期提交，并在容器关闭时执行最终提交。

Modal 的OpenAI-compatible vLLM 示例使用 Volume 缓存 Hugging Face 权重，并按需创建名为 huggingface-cache 的卷：

hf_cache_vol = modal.Volume.from_name("huggingface-cache", create_if_missing=True)

具体模型使用哪个缓存子目录，应核对该示例的当前版本，不要把通用示例中的 /data 当成固定路径。

Memory Snapshots：适合导入和编译初始化

Modal 的 Memory Snapshots 文档说明，Memory Snapshots 只会为已部署的 App 创建。需要纳入快照的初始化代码，应放在以下方法中：

@modal.enter(snap=True)

CPU Memory Snapshots 使用：

enable_memory_snapshot=True

GPU Memory Snapshots 目前是 alpha 功能，还需要：

experimental_options={"enable_gpu_snapshot": True}

GPU Memory Snapshots 通常不兼容 multi-GPU 代码。它主要减少 imports 和 JIT compilation 的初始化成本；如果大部分时间都花在从存储加载权重上，通常不会改善冷启动，额外开销甚至可能使结果更差。

部署并验证首请求

前述 vLLM 示例使用以下命令部署：

modal deploy vllm_inference.py

需要区分 Server 与 Function 的空闲行为：Modal Server 没有 active container 时会拒绝请求并返回 503 Service Unavailable，不能一概当作推理错误排查。

验证时，先让配置的 scaledown_window 结束，使容器不再处于 warm 状态；发送第一条请求后立即发送相同请求。保持模型、输入和生成参数一致，分别记录客户端观察到的时间。vLLM 的 Benchmark CLI 文档给出了一个在线测试示例：

vllm bench serve \
  --backend vllm \
  --model NousResearch/Hermes-3-Llama-3.1-8B \
  --endpoint /v1/completions \
  --dataset-name sharegpt

TTFT 是客户端从发出请求到收到第一个 streamed output 的时间。比较配置时，应固定数据集、request rate 和 concurrency，并同时查看 request throughput、output-token throughput 与 total-token throughput。不要连续对同一 Server 重复测试并据此判断优化效果，因为 prefix cache 可能复用已有 prompt，使吞吐量结果虚高。

常见出错点

  • 首请求仍然很慢：先区分等待 warm container 的时间与 enter 中的初始化时间；把加载工作移入 enter 只改变延迟发生的阶段。
  • 出现 volume busy：检查 Volume 上是否仍有打开的文件，关闭后再调用 .reload()。多个容器并发修改同一文件时采用 last-write-wins，Modal Volume 不提供分布式文件锁。
  • 快照恢复失败：重新部署新代码或配置会使旧快照失效；Volume 内容变化不会自动更新快照，删除恢复所需文件也会导致失败。

这些步骤依据正文所链接的官方文档整理，未运行或测量；使用前请对照当前版本检查。

资料来源