最近在帮团队做一轮模型部署平台的选型前前后后把七个平台过了一遍Baseten、DigitalOcean、RunPod、Replicate、Modal、Hugging Face Inference Endpoints还有 CoreWeave。训练一个模型可能只花两周把它稳定地接进业务里让用户用起来却往往要折腾更久。这两周里我最大的感受是模型部署从来不是把容器跑起来那么简单GPU 从哪来、冷启动怎么扛、账单会不会爆、模型更新方不方便每一项都是坑。这篇文章就是把这轮选型的思考过程、实测要点和避坑清单整理出来。适合三类人看刚把模型训练完、准备接业务的新手团队想从自建 Kubernetes 搬出去、减少运维负担的中小团队以及正在对比 RunPod、Baseten 这类平台到底差在哪里的技术负责人。我会先拆需求再逐个平台分析定位然后给出横向对比、成本估算以及三个有代表性的部署实操流程最后是常见问题排查经验。1. AI 模型部署选型先想清楚要解决什么问题1.1 部署环节真正要面对的四个难题很多人选平台时一上来就比价格、比 GPU 型号实际上平台之间的差距往往不在表面参数而在下面四个问题上。第一个是算力获取。高端 GPU 不是你想要就能立刻拿到。H100 这类卡在很多平台长期处于缺货状态等配额可能比部署本身还久。你自己领域如果模型是 7B、8B 级别那 A10G、L4、4090 这种卡就够用选择面会宽很多一旦上了 70B 甚至更大模型H100/A100 的可用性就直接决定上线时间。第二个是流量伸缩。普通 Web 服务的一个请求可能只占几 MB 内存但大模型推理一个请求要同时吃下显存和算力可能占用几十 GB 显存。平时没流量时GPU 闲着也在烧钱流量一来如果平台自动扩容不够快用户就会看到几十秒的转圈。所以平台的自动缩放策略、冷启动时间、最小实例数设置比它宣传的并发能力重要得多。第三个是成本模型。GPU 是按小时甚至按秒计费的一个没配好自动休眠的推理端点一个月下来可能产生让人肉疼的账单。反过来如果为了省钱把实例缩到 0用户请求又要等冷启动。怎么在成本和体验之间找平衡是选型时绕不开的决策。第四个是业务集成。模型跑起来只是第一步后面还连着 API 网关、鉴权、日志、监控、模型版本回滚。选平台时要看它和现有技术栈能不能打通尤其要关注是不是兼容 OpenAI 的 API 格式这会影响你后面换平台时业务代码要不要重写。1.2 七家平台到底分属什么阵营七家平台表面都在做模型部署但底层逻辑完全不同。我按控制力从低到高把它们分成三类。一类是模型托管平台代表是 Baseten、Replicate、Hugging Face Inference Endpoints。你只要把权重或打包好的模型丢上去平台负责 GPU、伸缩、健康检查、安全。典型特征是开发效率高但你定制空间有限。一类是 Serverless GPU 平台代表是 RunPod 和 Modal。它们给你更接近底层的环境你可以自己写 Docker 镜像或 Python 函数同时保留按调用量计费和自动伸缩。灵活性和运维负担介于托管和自建之间。还有一类是通用云基础设施代表是 DigitalOcean 和 CoreWeave。前者是通用云提供 GPU Droplet 和 Kubernetes 服务但没有内置推理中间层你得自己用 vLLM、Ollama 这些推理引擎组装整套服务后者是偏大规模算力的 GPU 云产品形态更原始更适合批量训练或大规模推理。选型第一步不是比功能而是想清楚一个问题你团队里有没有人愿意长期承担推理平台的运维。如果没有老老实实选前两类如果有DigitalOcean 这类自建方案能带来更大的控制力和更可预测的账单。2. 七家平台逐个拆解定位、优势与适用场景2.1 Baseten把推理包装成标准生产产品Baseten 是我这次重点对比的对象之一也是目前模型托管平台里做得比较成熟的一家。它的核心流程是你用 Truss 这个打包工具把模型代码和依赖整理成一个目录然后推到 Baseten平台会自动处理 GPU 分发、健康检查、并发控制和自动伸缩。我最喜欢它的一点是生产链路很完整。部署完成后你拿到的是一个标准 HTTPS 端点支持 GPU 型号选择、最小副本数设置、多区域部署和线上监控。Baseten 自带一套模型观测面板能看到每个请求的延迟、吞吐、GPU 利用率和错误率这点很多平台都做不到。它适合产品型团队。如果你的核心精力在业务逻辑不想每天盯 GPU 节点希望模型部署像调用一个云服务一样简单Baseten 是很省心的选择。代价是价格比自建贵一些而且模型镜像格式是 Truss 生态的虽然容器化概念通用但平移到别的平台时还是要改打包流程。2.2 RunPod灵活性与性价比的平衡点RunPod 在国外 AI 社区里使用频率很高核心产品是两类。一类是 Pod 模式本质上是一台带 GPU 的远程容器或服务器你可以 SSH 进去做开发调试、跑训练另一类是 Serverless 端点把 GPU 包装成按调用计费的推理 API。它的优势是卡型选择非常丰富从 4090、L40S 到 A100、H100 都有而且价格相对透明。Pod 模式对开发调试特别友好我经常直接开一个 4090 Pod 进去测模型效果测完就删掉按小时计费成本也不高。Serverless 端点适合接生产流量支持设置最大并发和空闲超时时间。坑点也有。它的 Serverless 冷启动比 Baseten 更敏感如果你把空闲超时设得太短流量突增时用户会等很久设得太长账单又会上去。另外 Serverless 端点默认不带很完善的监控面板你可能需要自己接日志系统。2.3 DigitalOcean通用云上的自建推理方案DigitalOcean 出现在这个对比列表里很多人会有点意外。它本身不是专门做模型部署的但确实是不少团队的选择尤其是那些已经把业务跑在 DigitalOcean 上的团队。它提供 GPU Droplet也就是带显卡的虚拟机同时有 DigitalOcean KubernetesDOKS可以自己搭建推理服务集群。用 DigitalOcean 部署模型典型路径是创建 GPU Droplet 或 DOKS 节点池在上面用 Docker 跑 vLLM 或 Ollama 等推理引擎再用 Load Balancer 暴露对外访问。DIgitalOcean 的账单很简单带宽费用也比几家大云厂商实惠对预算敏感的自建团队有吸引力。代价是你要有相当的 DevOps 能力。没有自动伸缩现成方案你得自己配置 HPAGPU 节点供应也没有托管平台稳定热门卡型可能缺货。我的判断是它适合已经有 Kubernetes 经验、希望保留完全控制力的团队不适合想开箱即用的新手。2.4 Replicate原型验证效率极高Replicate 的打法是一行代码跑模型。你用 Cog 这个工具把模型打包成镜像推上去之后它会自动转换成推理 API。社区里有大量现成模型可以直接调用很多做 AI 应用原型的人第一站都在这里。它的优势是把模型调用的摩擦降到了极低几乎不需要懂 GPU 和 Kubernetes。适合快速验证产品想法或者做一些低并发的内部工具。但它不是万能的。姑且不提它现阶段的中文生态单说 GPU 高级配置和特殊推理优化Replicate 就不如 Baseten 这类专业平台灵活。高并发、低延迟要求的生产场景我更倾向于把它当作选型参考基线而不是终点。2.5 Modal代码优先的 Serverless GPUModal 的思路是把普通的 Python 函数直接变成云端推理端点。你写的函数可以是跑模型、跑数据处理、跑批量任务Modal 负责调度 GPU、扩缩容按毫秒级计费。它的开发体验非常特别适合事件驱动和批处理场景。比如你要定期跑一批推理任务或者做一个偶尔调用的 AI 工具Modal 能让代码量保持在很低的水平。它在桩机上的冷启动控制做得也不错。不过它需要你适应它的编程模型函数调度和本地开发有差异。如果你的主要场景是常驻的聊天类 APIModal 的反模式就比较明显它更适合突发型、任务型负载。2.6 Hugging Face Inference Endpoints与模型库深度绑定如果你工作流已经深度依赖 Hugging Face HubInference Endpoints 是最顺手的方案。你可以从 Hub 上选一个模型点几下就能部署成一个推理端点支持 GPU 型号选择和自动缩放。优势在于模型和数据集生态的整合。模型更新、版本管理、实验记录都围绕 Hub 展开对于研究团队或已经用 Hugging Face 做实验管理的团队来说迁移成本几乎为零。生产线上的问题在于它的端点更偏模型服务而非应用服务高级路由、多模型灰度、细粒度观测工具相对弱一些。作为快速上线验证很好作为复杂 AI 应用的底座可能需要搭配其他网关。2.7 CoreWeave给大规模算力需求方准备的选项CoreWeave 是这几个平台里最重的。它本质上是面向 AI 的云基础设施提供 Kubernetes 原生的 GPU 集群H100、A100 资源池很大很多大模型公司都在用它的算力。如果你有小规模推理需求CoreWeave 并不是成本最优解它的最小起租和对 Kubernetes 的依赖程度都不适合小团队。但如果你要做大模型微调、批量推理或者已经有成熟的 K8s 平台它的 GPU 供给能力和价格可以做到非常出色。我在选型时把它当作未来万一算力需求暴涨的备选方案平时不会作为首选但会提前开好账号熟悉它的一套操作方法。3. 横向对比从成本、冷启动和伸缩看真实差异3.1 七个平台核心维度对照这里把七个平台放到一张表里方便快速对照。价格写的是大致区间GPU 云的价格变动比较频繁具体以官网实时报价为准。平台部署方式典型 GPU计费粒度伸缩能力学习曲线适合阶段BasetenTruss 打包托管A10G、L4S、H100 等按秒/按小时自动缩放可配最小实例低生产型产品团队RunPodPod Serverless 端点4090、L40S、A100、H100 等Pod 按小时Serverless 按秒自动缩放可配并发和空闲超时中开发调试 生产混合DigitalOceanGPU Droplet / DOKS 自建H100、A100 等随供给按小时/按月需自己配 HPA 或自建伸缩高有运维能力的自建团队ReplicateCog 打包托管平台自动调度按推理时长自动缩放低原型与轻量生产ModalPython 函数 ServerlessA100、H100 等可选按毫秒计费自动缩放冷启动控制好中批量/事件驱动任务Hugging Face EndpointsHub 一键部署T4、A10G、A100 等按秒可配自动缩放低已有 HF 生态的团队CoreWeaveKubernetes 原生 GPU 云A100、H100按小时全手动靠 K8s 平台能力高大规模算力需求3.2 成本模型不是只看 GPU 时薪很多人选平台时第一眼只看GPU 每小时多少钱这个出发点容易踩坑。GPU 时薪只是账本的第一行真正决定月度成本的是空转率、冷启动费用和流量费用。举个例子。假设部署一个 Llama-3.1-8B-Instruct 模型目标支持 50 并发P95 请求延迟控制在 2 秒以内。如果全部走 ServerlessBaseten 或 RunPod 上需要配置最小 2 个副本常驻按 L4 或类似档位 GPU 估算两个实例每月的常驻成本大约在 600 到 900 美元之间。之所以要最小 2 副本是因为聊天类请求对冷启动极其敏感一旦缩到 0用户体验会断崖式下降。如果换成 DigitalOcean 的自建方案两个 GPU 节点常驻加上负载均衡和对象存储基础成本大约也在 800 到 1200 美元之间。表面上看自建更便宜但别忘了运维时间成本。自己搭 vLLM、配监控、处理节点故障一个月至少投入 0.5 到 1 个人日的工时。折算下来托管平台多出来的那部分钱买的是工程时间。我的经验是流量低且波动大的阶段Serverless 托管平台的成本优势明显因为你不用为闲置付钱流量稳定且持续高的阶段预留实例或自建才可能更划算。3.3 冷启动是聊天类应用选型的头号指标冷启动是 Serverless GPU 平台最要命的问题。普通 Serverless 函数冷启动只要几百毫秒GPU 推理服务冷启动则要把模型权重加载进显存时间以十秒甚至几十秒计算。三家的处理策略不一样。Baseten 允许设置最小副本数相当于提前把 GPU 实例跑热请求来了直接打上去。RunPod 的 Serverless 端点可以通过空闲超时参数控制实例存活时间比如设置 10 分钟空闲才回收代价是低峰期也要为这些存活实例付费。Modal 在冷启动优化上做得很激进它的调度系统会预留一部分热容器。实测下来聊天类的应用如果目标 P95 是 2 秒那 Serverless 平台的最小实例数不能设成 0至少保持 1 到 2 个热副本。这也是我在多轮对比后反复提醒团队的一个点省冷启动的钱就是劝退用户。4. 实操复盘三个平台部署同一个模型的真实流程这一节我用同一个模型场景分别展示 Baseten、RunPod Serverless 和 DigitalOcean 自建三条路径。由于平台控制台界面会不断更新以下命令和配置以当前常见版本为例。4.1 Baseten用 Truss 把模型推到生产端点Baseten 的打包工具是 Truss。它的思路是把模型代码、依赖、配置全部收敛到一个目录里平台上直接识别这种目录结构。第一步本地安装工具链pip install truss baseten第二步初始化一个 Truss 项目truss init llama-app cd llama-app第三步在config.yaml里配置资源和推理行为。核心配置项大概有下面这些不同版本字段名会有差异以官方文档为准model_server: truss_server: num_replicas: 2 resources: cpu: 2 memory: 8Gi gpu: L4s use_gpu: true runtime: predict_concurrency: 16这里的num_replicas就是常驻副本数聊天类应用建议至少设 2。模型代码写在model.py里大致结构是这样from transformers import AutoTokenizer, AutoModelForCausalLM class Model: def __init__(self, **kwargs): self.tokenizer AutoTokenizer.from_pretrained( meta-llama/Llama-3.1-8B-Instruct ) self.model AutoModelForCausalLM.from_pretrained( meta-llama/Llama-3.1-8B-Instruct ).to(cuda) def predict(self, request): inputs self.tokenizer(request[prompt], return_tensorspt).to(cuda) outputs self.model.generate(**inputs, max_new_tokens512) return self.tokenizer.decode(outputs[0], skip_special_tokensTrue)先在本地跑通truss run确认没有依赖问题后推送到平台baseten login # 输入你的 API Key truss push推送完成后你会在控制台看到这个部署的 URL可以直接发 HTTP 请求测试。之后每次改代码重新执行truss push即可更新线上版本。如果你想通过 SDK 精确控制 GPU 型号、最小副本数和自动缩放也可以在 Python 里用 Baseten 的 Python SDK 完成部署参数注入。整体体验是七个平台里最接近开箱即用的。4.2 RunPod Serverless把 vLLM 容器包装成一个可调用的端点RunPod 的 Serverless 端点更灵活因为它本质上是 Docker 容器只要你能把推理服务跑在容器里就能包装成端点。最简单的做法是直接用 vLLM 的 OpenAI 兼容镜像。先准备一个handler.py用来在容器启动时加载模型并在每次请求时调用推理import runpod from vllm import LLM, SamplingParams llm None def init_model(): global llm llm LLM(modelmeta-llama/Llama-3.1-8B-Instruct) def handler(job): prompt job[input].get(prompt, ) params SamplingParams(max_tokens512, temperature0.7) result llm.generate([prompt], params) return {output: result[0].outputs[0].text} init_model() runpod.serverless.start({handler: handler})接着写一个尽可能精简的 DockerfileFROM vllm/vllm-openai:latest WORKDIR /app COPY handler.py handler.py CMD [python, handler.py]构建镜像后推到镜像仓库然后在 RunPod 控制台创建 Serverless Endpoint填上镜像地址、选择一个 GPU 类型比如 L4 或 A100设置最大并发数和空闲超时时间。创建完成后RunPod 会自动生成一个调用地址你把自己的 API Key 加到请求头里就能调用。这里要提醒一个细节RunPod 的 Serverless 端点计费是从镜像拉取到实例回收的完整生命周期所以空闲超时设置很关键。我建议先按 120 秒起步观察实际流量分布后再调整。如果设置成 5 秒高峰期必然频繁冷启动用户会出现大量明显卡顿。4.3 DigitalOcean在 Kubernetes 里自建 vLLM 推理服务DigitalOcean 这条路线适合有 K8s 经验的团队。我先创建一个 GPU Droplet或者在 DOKS 集群里加一个 GPU 节点池然后直接部署 vLLM。下面是一个精简的 Deployment 配置apiVersion: apps/v1 kind: Deployment metadata: name: vllm-llama spec: replicas: 2 selector: matchLabels: app: vllm-llama template: metadata: labels: app: vllm-llama spec: containers: - name: vllm image: vllm/vllm-openai:latest command: [python, -m, vllm.entrypoints.openai.api_server] args: - --model - meta-llama/Llama-3.1-8B-Instruct - --served-model-name - llama - --port - 8000 resources: limits: nvidia.com/gpu: 1保存后执行kubectl apply -f vllm-deployment.yaml kubectl expose deployment vllm-llama \ --typeLoadBalancer \ --port80 \ --target-port8000这条命令会创建一个对外负载均衡指向 vLLM 的 8000 端口。之后你可以用标准的 OpenAI 客户端访问curl http://负载均衡IP/v1/chat/completions \ -H Content-Type: application/json \ -d {model: llama, messages: [{role: user, content: 你好}]}但请注意这个方案还没有自动伸缩。要真正应对流量波动你还得装一个支持 GPU 指标的监控组件比如 Prometheus GPU 指标导出器再配 HPA 基于请求量或 GPU 利用率扩容。整套体系搭完你会获得很强的掌控感但也要接受它比托管平台复杂一到两个量级的事实。5. 常见问题与选型陷阱实录5.1 高频问题速查表这些问题是我实际使用和与人交流时反复遇到的整理成表方便对照。现象/问题可能原因处理建议请求偶尔超时尤其凌晨Serverless 实例被回收冷启动在裸奔设置最小实例数调整 idle timeout月底账单远超预期实例一直存活但从没被人调用检查空闲超时和最小副本数给端点加配额GPU 显存不够模型加载失败模型权重 KV cache 超过显存换更大显存卡开启量化比如 INT8/FP8单请求延迟高但 GPU 利用率很低并发设置太小请求排队提高predict_concurrency或 vLLM 的并发参数每次改模型代码都很慢没有规划模型版本和回滚策略用平台自带的版本功能别手动覆盖线上端点高峰期调用报 429并发上限被触发提高最大并发检查上游日志是否有热点想迁移到另一家平台业务代码要改直接耦合了平台 API应用层包一层 OpenAI 兼容接口统一抽象5.2 我给团队的选型决策参考如果今天让我再给团队做一次选型我会按下面这个顺序走。场景是快速验证 Demo不一定上线优先 Replicate 或 Hugging Face Inference Endpoints它们能让你在半小时内拿到一个可以外链的模型 API。场景是准备接生产流量但运维人手不足优先 Baseten 或 RunPod Serverless。Baseten 的观测和自动化做得更省心RunPod 胜在灵活和价格适合你已经能写 Docker 镜像的团队。场景是已经有 K8s 平台和运维团队想要掌握一切DigitalOcean GPU Droplet 加上 DOKS 是合理选择但一定要预留足够的工程人力。场景是有大模型微调或大量批量推理需求CoreWeave 或 RunPod Pod 模式更合适它们在大规模 GPU 调度上的价格和供给能力都更强。还有一个总的原则不要让业务代码和平台绑定。不管用哪家都在应用层包一个 OpenAI 兼容接口这样后续切换平台、做多平台容灾代价都会小很多。5.3 容易被忽视的隐藏成本再补充几个很多人选型时没注意的隐藏成本。第一是带宽和流量费用有的平台 GPU 便宜但流量贵模型服务又是流量密集型应用月度账单可能因此差出几个百分点。第二是模型更新成本有的平台每次推送新模型都要重建实例这期间旧版本是否继续服务、新版本是否能灰度都需要确认。第三是安全合规成本如果你的数据不能出特定的合规区就要确认平台的数据中心地域DigitalOcean 这类可用区较多的平台反而有优势。6. 关于选型我最后想说的经验踩过这轮选型的坑之后我个人的习惯已经固定下来Demo 阶段用 Replicate 或 Hugging Face Endpoints 快速验证一旦确认要接生产流量优先用 Baseten 或 RunPod Serverless 扛住第一波用户等到真实 QPS 数据跑出来流量曲线足够平滑了再决定要不要迁到 DigitalOcean 自建。这个顺序能帮你避免两个极端过早自建导致武器过剩以及长期绑死在托管平台导致成本失控。最后再分享一个实战技巧无论是 Baseten、RunPod 还是 DigitalOcean部署完模型之后第一件事不是压测而是把模型 API 地址和 Key 写进一个小脚本模拟真实业务连续调用 24 小时同时记录账单曲线。这个动作看起来简单但能一次性暴露出冷启动策略、空闲超时、并发限制和计费口径的问题。等这几项数据都清晰了选型结论自然也就出来了。