Modal与Replicate部署能力梳理

对照Modal的GPU、扩缩与冷启动配置，以及Replicate的运行计费、Prediction等待方式和API限流，形成可直接用于方案评审与上线核验的清单。

Modal 与 Replicate 的模型部署能力不能只按“能否运行模型”比较：Modal 侧要核对 Function 的 GPU、容器扩缩和冷启动，Replicate 侧要核对模型或实例类型、计费对象、Prediction 等待方式和 API 限流。下面按准备、配置、调用、计费与验收的顺序梳理，不作平台推荐。

Modal 的模型部署配置从哪里开始

开始配置前，按 Modal 的 GPU 指南核对：使用 GPU 需要账户中留有有效付款方式；单容器需要多张 GPU 时，在型号后追加 :n，如 gpu="H100:8"；gpu 还可以接收有序列表，Modal 会优先尝试靠前的型号。多数 GPU 型号最多支持 8 张，A10 最多支持 4 张；请求超过 2 张通常等待更久，同一容器中的 GPU 位于同一物理机器。选择 B300 时，还需确认容器镜像和依赖兼容 CUDA 13.1 或更高版本。

有序回退可以写成：

@app.function(gpu=["H100", "A100-40GB:2"])

这行是 Function 装饰器配置片段，不是完整 App。镜像定义、函数实现和部署命令仍应与你的项目版本及当前官方文档保持一致。

Modal：扩缩和保热如何设置

按 Modal 的扩缩指南，每个 Function 都有独立的 autoscaling container pool，没有输入时默认缩到零。max_containers 是单 Function 容器上限，min_containers 是非活跃期保留的热容器数，buffer_containers 是活跃期维持的额外缓冲，scaledown_window 是缩容前允许的最大空闲秒数。单 Function 有 4,000 个并发容器的硬上限，workspace 的容器与 GPU 并发上限则取决于 plan。

已部署的 Function 可按 Modal 的运行时更新方式调整 autoscaler：

f.update_autoscaler(min_containers=2, max_containers=10)

这种更新不必重新部署，但下次 deploy 时会恢复为 Function 装饰器中的配置，因此应把临时调整和正式配置分开记录。

Modal：冷启动从哪里排查

根据 Modal 的冷启动性能文档，没有可用容器而需要启动新容器就是 cold start，通常会带来较高延迟；等待 warm container 和首次调用初始化都可能 contributing；容器只有在全局代码、导入操作及 modal.enter 完成后才算 ready。文档给出的首要优化建议是提前下载模型权重，避免每次启动容器时重新下载。

Replicate：运行与计费如何区分

按 Replicate 的计费说明，public model 默认与其他客户共享 hardware pool 和 queue，只对 active processing time 收费，setup 与 idle time 免费；多数 private model 使用 dedicated hardware，不需要共享队列，但 setup、idle 和 active 时间都会计费。快速启动的 fine-tunes 是例外，无论 public 还是 private，都只按 active time 收费；deployments 则按实例在线的全部时间收费。模型使用的硬件可在模型页面的 Run time and cost 区域查看。

Replicate 的取消与失败计费规则还规定：失败的 run 不收费，但 official model 被取消时仍可能收费；按时间计费的模型会算到取消时刻，private model 或 deployment 的失败、取消操作仍可能产生实例 active time 费用。模型调用其他模型时，费用还包括 root model 与全部 downstream models。

若当前报价确认按时间计费，可用账单或报价中的字段估算：

PUBLIC_TIME_BILL = YOUR_ACTIVE_TIME × YOUR_RATE
PRIVATE_OR_DEPLOYMENT = (YOUR_SETUP_TIME + YOUR_IDLE_TIME + YOUR_ACTIVE_TIME) × YOUR_RATE
MODEL_CHAIN = YOUR_ROOT_MODEL_CHARGE + YOUR_DOWNSTREAM_MODEL_CHARGES

公开模型的时间公式只适用于当前模型确实按运行时间计费的情况；若计费单位不同，应按模型页面逐项填写，不要套用时间公式。

Replicate：API 入口、等待与轮询

Replicate 的 Prediction 创建文档将创建入口分为 community model、official model 和 deployment，对应方法名如下：

predictions.create
models.predictions.create
deployments.predictions.create

API 默认采用 async 模式，立即返回 prediction ID 和未完成的 prediction 对象。需要同步等待时，可按 Replicate 的同步等待规则发送：

Prefer: wait=5

Prefer: wait 默认保持请求 60 秒，也可以指定其他等待时间。等待结束仍未完成时，返回对象的 status 会是 starting 或 processing；应向初始响应 urls.get 字段或 Location 头提供的 prediction URL 发送 GET 请求并继续检查。创建时还可设置 Cancel-After 自动取消期限，其有效范围为 5 秒至 24 小时。

对于 Cog 微调，训练入口、启动命令和产物位置需要按目标模型的当前文档核对；Prediction API 的创建方法不能直接代替训练入口。

Replicate：API 限流如何纳入验收

按 Replicate 的 API 限流说明，创建 Prediction 的默认限制为每分钟 600 次请求，其他 endpoint 为每分钟 3000 次；超过默认限制的短暂突发可能先被接受，随后才触发 throttling。触发限制会收到 HTTP 429，响应体说明重置时间。账户接近额度耗尽时会适用更严格的限制；获得 credit 但没有付款方式的账户限制为每秒 1 次请求，每分钟最多 6 次。

验收与常见出错点

Modal 侧检查 gpu 型号、数量、回退顺序、autoscaler 参数及 CUDA 兼容性，并记录哪些工作发生在容器启动和首次调用阶段。
Replicate 侧确认创建方法与模型类型匹配，保存 prediction ID 和查询 URL，按规则处理未完成返回，并在收到限流响应时遵循重置时间。
费用核对时，从自己的账单或报价填写公式，不用 public model 的 active time 口径推算 private model 或 deployment。
本文步骤依据正文所链接的官方文档整理，未进行运行或测量；使用前应按当前版本复核。