对于一个百亿参数以下的模型，难点不在于能不能托管------几乎任何服务商都能提供一台能跑得动的机器；真正的挑战在于找到与你的流量模式、定制需求和预算相匹配的托管方案。大多数人的目光都集中在大模型上，这很正常：它们因为参数规模大而性能最强。但越来越多的用户发现，随着 LLM 技术的进步，较小的模型已经能很好地满足他们的需求了。
小模型改变了成本计算方式。一个 7--9B 的模型可以放在单块中端 GPU 上，这就解锁了大模型（70B+）无法企及的各种选择（无服务器、按 token 计费、单卡 GPU 服务器）。从经济角度来看，这为更多用户打开了使用 AI 技术的大门------那些以前在成本上不可行的 AI 技术，如今在各种全新场景中都变得触手可及。
那么，究竟应该在哪里运行这样一个模型呢？简而言之：对于大多数运行百亿参数以下模型的团队来说，支持自带模型的托管推理平台是最理想的起点------你获得生产级的服务，又无需管理 GPU 服务器，而且可以托管你自己微调的权重，而不仅仅是现成的模型库。自行管理 GPU 服务器只有在流量持续稳定且量级很高时才有意义。
本问的其余部分会阐述这个结论背后的逻辑。我们将从一个快速估算框架开始，让你精确了解一个百亿参数以下的模型需要多少 GPU 内存；然后逐一介绍四种托管方式及其适用场景；最后给出具体的推荐方案和分步快速入门指南。读完之后，你就能在几分钟内为你的模型匹配到合适的托管方式，并知道什么时候值得切换。
本文关键要点
- 让托管方式适配你的流量，而不是你的模型大小。对于一个百亿参数以下、流量突发或不可预测的模型，无服务器按 token 推理是最划算的，因为空闲时你不需要付任何费用；只有在利用率持续较高时，专用 GPU 才有优势。
- 大多数团队应该从托管平台起步。如果现成的模型（Llama、Mistral、Qwen）能满足需求，使用无服务器推理；如果你要部署自己的微调模型，使用自带模型（BYOM）------两种方式都能提供生产级的服务，而你无需自行管理 GPU、驱动或推理服务器。
- 小模型改变了成本逻辑。一个量化后的 7--9B 模型可以放在单块 48 GB GPU 上（FP16 约 14 GB，8-bit 约 7 GB，4-bit 约 3.5 GB），因此你可以在廉价的单 GPU 方案中做选择，而不需要搭建多 GPU 集群------而且按 token 计费与按 GPU 小时计费之间的盈亏平衡点，比 70B+ 模型来得更快。
第一步：评估你的模型------你到底需要多少 GPU？
在比较各家服务商之前，先算清楚你的模型实际需要多少 GPU 内存------这是决定哪些托管方案可供选择的唯一关键数字。经验法则很简单：VRAM 与每个参数消耗的字节数成正比。全精度（FP32）每个参数 4 字节，半精度（FP16/BF16）每个 2 字节，8-bit 每个 1 字节，4-bit 每个约 0.5 字节。乘以参数量就能得到权重的占用空间。
小模型（约 7--9B 参数）的 VRAM 需求
| 精度 | 字节 / 参数 | 仅权重（7B） | 仅权重（9B） | 建议预留 VRAM | 可适配的典型 GPU |
|---|---|---|---|---|---|
| FP32（全精度） | 4 | ~28 GB | ~36 GB | ~34 / ~43 GB | A6000 48 GB、L40 48 GB（9B 时略紧）；H100 / H200 绰绰有余 |
| FP16 / BF16（半精度） | 2 | ~14 GB | ~18 GB | ~17 / ~22 GB | A6000 48 GB、L40 48 GB 很宽裕；高并发选 H100 / H200 |
| 8-bit（INT8） | 1 | ~7 GB | ~9 GB | ~9 / ~11 GB | A6000 / L40 留有大量 KV-cache 空间；H100 / H200 性能过剩 |
| 4-bit（NF4 / GPTQ / AWQ） | 0.5 | ~3.5 GB | ~4.5 GB | ~5 / ~6 GB | 上述四类均可；H100 / H200 只有在高并发时才能体现其价值 |
表 1 - 不同精度下的 VRAM 需求：一个 7--9B 模型在 FP16 下大约需要 14--18 GB 的 VRAM，8-bit 下约 7--9 GB，4-bit 下约 3.5--4.5 GB，因此量化后的百亿参数以下模型可以轻松放在单块 48 GB GPU 上。
结论是：量化后的百亿参数以下模型可以轻松运行在单块 48 GB GPU 上，4-bit 版本则更加从容。这也正是其成本计算与 70B+ 模型截然不同的原因：你是在单 GPU 方案（无服务器、按 token、单 GPU Droplet）之间做选择，而不需要搭建多 GPU 集群。
有两个注意事项值得一提。首先，量化是在质量与占用空间之间的权衡：从 FP16 降到 4-bit 约可使 VRAM 再减少四分之三，绝大多数场景下质量损失极小，但这并非没有代价，因此在正式上线之前请用你自己的评估集验证一下（可参考arxiv上的《量化指令微调 LLM 的综合评估》）。每降一级------从 FP16 到 8-bit，再从 8-bit 到 4-bit------权重的占用空间大约再减半。其次，权重只是下限。实际场景中的 VRAM 消耗更多取决于上下文长度和并发数，而非模型本身，因为 KV cache 会随两者增长。在长上下文和大量并发请求下，KV cache 可能在权重之上额外增加数个 GB，所以请按峰值并发负载来规划，而不仅仅是模型大小。（以上数字是刻意取整的经验法则；采用分组查询注意力（GQA）的现代架构消耗的 KV cache 明显少于旧设计。）（可参考aclanthology.org上的《GQA:Training Generalized Multi-Query Transformer Models from Multi-Head Checkpoints》）
托管小型开源模型有哪些方式？
实际上只有四种方式可以运行推理，每种方式适合不同的流量、定制需求和运维偏好。下面逐一说明每种方式是什么、适合谁、成本如何。
无服务器 / 按 token 计费的推理 API
你向托管的端点发送请求，仅按消耗的 token 付费。底层全都交给平台处理，空闲时自动释放资源，不产生任何费用。这最适合突发或不可预测的流量、原型项目以及任何负载不固定的场景，因为不提供服务时不用付任何费用。代价是对服务栈的控制较少、空闲期后偶有冷启动，以及在流量高且稳定时，按 token 费率可能超过专用 GPU 服务器。
要注意，无服务器推理和按Token 计费的推理API，或者大家常见的一些API中转站，提供的都是平台上已经部署好的模型，一般不支持BYOM（自己上传已经微调过的模型）。而下面三种途径，都支持使用自己微调过的模型。
自带模型（BYOM）托管
你上传自己的权重------通常是微调后的模型------平台会在其优化的服务栈上运行。如果你的团队有自己定制的百亿参数以下模型，既想要生产级的服务质量，又不想自己管运维，那这个方案最合适：vLLM 不用操心，批处理不用调参数，内核优化也不用追。代价是受限于平台支持的模型格式和架构，但作为交换，你省去了大量的运维工作。对于大多数交付微调小模型的团队来说，这是阻力最小的路径。
自行管理的 GPU 实例
你租用一台 GPU 虚拟机，自己运行推理服务器------高吞吐生产环境用 vLLM，或者用 Text Generation Inference 作为替代方案，如果只是想几分钟内跑起来就用 Ollama。这让你拥有最大程度的控制权，在持续稳定的负载下或有特殊需求时也是最具成本效益的选择。代价是你现在要自己处理伸缩、批处理、监控和可用性；vLLM 可以让每块 GPU 获得极佳的吞吐量，但保持它健康运行是你的事。
本地 / 边缘 / 私有部署
你在自己的硬件上运行模型------工作站 GPU、私有服务器或边缘设备。这适用于严格的数据驻留要求、离线环境、开发或业余项目。代价是无法弹性伸缩，以及需要前期资本支出而非按用量付费。
无服务器 vs. BYOM vs. 自行管理 GPU：如何比较？
| 方式 | 最适合 | 控制权 | 运维负担 | 计费模式 | 伸缩 |
|---|---|---|---|---|---|
| 无服务器 / 按 token API | 突发、不可预测、原型项目 | 低 | 无 | 按 token 付费 | 自动，空闲时归零 |
| 托管 BYOM | 自定义/微调模型、精简团队 | 中 | 低 | 按 token 或按小时 | 由平台管理 |
| 自行管理 GPU | 持续高流量、完全控制 | 高 | 高 | 按 GPU 小时 | 自行构建 |
| 本地 / 边缘 / 私有部署 | 合规、离线、开发 | 完全 | 高（硬件） | 资本支出 | 无（固定容量） |
表 2 - 四种托管方式对比：无服务器适合突发流量，零运维负担；托管 BYOM 适合微调模型，适合精简团队；自行管理 GPU 适合持续高流量，代价是一切自己动手；本地/私有部署适合合规或离线需求。
到底怎么选：一个决策框架
你不需要把四种方案都仔细权衡一遍------通常几个问题就能指向一个答案。按顺序回答以下问题：
你的流量是可预测的吗？如果是突发、尖峰或你还不确定，无服务器按 token 计费可以保护你免于为空闲 GPU 付费。如果流量稳定且量大，专用 GPU 在成本上开始胜出。
你在运行自己的模型吗？如果现成的模型能满足需求，托管推理 API 是最快的路径。如果你微调了自己的百亿参数以下模型，则需要 BYOM 或自行管理 GPU 来部署这些权重。
你希望承担多少基础设施？如果你不想管理 GPU、驱动和推理服务器，托管或无服务器平台就是答案。如果你有平台团队并想榨取每一分吞吐量，自行管理给你最多的控制权。
你的成本盈亏平衡点在哪里？按 token 计费在低流量和变化流量时最便宜；按 GPU 小时计费在利用率持续高时最便宜。存在一个盈亏平衡点，随着持续流量的增长，平衡点会向专用 GPU 倾斜。
你有合规或数据驻留方面的限制吗？数据存放位置的要求或离线运行的需求可能会覆盖上述所有条件，把你推向特定区域或完全本地部署。
对于大多数刚开始推出小模型的团队来说，前三个问题通常会指向同一个方向：早期流量不可预测、希望对模型有控制权、不希望操心基础设施------这正是下一节要讲的内容。
推荐方案：百亿参数以下模型从何起步
对于大多数团队，建议从托管推理平台开始，只在持续流量足以证明其必要性时才迁移到自行管理 GPU。我们的具体推荐是 DigitalOcean 的 Gradient AI 平台，因为它在一个账户、一张账单上覆盖了百亿参数以下模型整个旅程的全部选择------托管模型库、你自己的微调模型、以及专用 GPU。使用哪个入口点取决于你是在运行流行的开源模型还是你自己的模型：
运行流行开源模型（Llama、Mistral、Qwen、Gemma、DeepSeek）？使用无服务器推理。DigitalOcean 的无服务器推理通过单个兼容 OpenAI 的端点（https://inference.do-ai.run/v1/）和一个模型访问密钥提供了 30 多个基础模型，按输入和输出 token 计费，无需配置 GPU。它会自动伸缩，你只需为消耗的 token 付费------非常适合小模型在早期阶段那种突发、难以预测的流量。新账户在开始计费之前有一定的免费额度。如果模型库中的某个模型能满足你的需求，这是最快的起步方式。
运行自己的微调模型？使用自带模型（BYOM）。BYOM 让你从 Hugging Face（包括受限仓库）或 DigitalOcean Spaces 对象存储导入自己的权重，由 DigitalOcean 在优化栈上提供服务------无需操作 vLLM。有两个具体事项需要注意：导入必须是 Safetensors 格式文件，目前支持的架构是 Qwen 系列（Qwen2ForCausalLM 和 Qwen3ForCausalLM）------这恰好覆盖了像 Qwen3-8B 这样优秀的百亿参数以下基础模型。BYOM 模型通过专用推理（Dedicated Inference）部署，按 GPU 小时而非按 token 计费，因此这条路径更适合流量稳定的工作负载。导入在控制面板中完成（目前尚未通过 API、CLI 或 SDK 开放），导入的权重存放在托管的 Spaces 对象存储位置，会产生存储费用。
已经超出托管范畴，或者需要使用不同的架构？使用 GPU Droplets。当流量持续且量大，或者你的模型不在 BYOM 架构支持列表中时，自行管理的 GPU Droplets 云服务器在同一平台上给你完整的控制权。按需定价透明，对百亿参数以下模型来说单 GPU 非常友好：
| GPU Droplet | VRAM | 按需价格 | 是否适合百亿参数以下模型 |
|---|---|---|---|
| NVIDIA RTX 4000 Ada | 20 GB | $0.76 / 小时 | 量化（4-bit / 8-bit）的 7--9B 模型 |
| NVIDIA RTX 6000 Ada | 48 GB | $1.57 / 小时 | FP16 百亿参数以下，留有上下文空间 |
| NVIDIA L40S | 48 GB | $1.57 / 小时 | FP16 百亿参数以下，更高吞吐量 |
| NVIDIA H100 | 80 GB | $3.39 / 小时 | 对一个模型性能过剩；在高并发时有用 |
表 3 - DigitalOcean GPU Droplet 云服务器定价：量化后的 7--9B 模型运行在 0.76/小时的 RTX 4000 Ada 上；FP16 百亿参数以下模型需要 48 GB 的卡（RTX 6000 Ada 或 L40S，1.57/小时），H100 除了高并发场景外性能过剩。
计费按秒计算，五分钟起步；预留合约可为持续使用降低小时费率。DigitalOcean 的一键部署模型（1-Click Models）也可以用几次点击将流行开源模型（Llama 3、Mistral、Qwen、Gemma）部署到 Droplet 上，并提供兼容 OpenAI 的端点。
坦率地说：可预测的定价、简洁的 UI 和兼容 OpenAI 的 API，使其非常适合从独立开发者到中型团队的群体。如果你的微调模型使用的架构不在当前 BYOM 支持列表中，或者你的技术栈其他部分依赖特定的超大规模服务商，那么它可能不是最合适的选择。（按 token 的无服务器费率按模型设定，因此请查看当前定价页面确认你要运行的具体模型的费率。）
托管小模型有哪些 DigitalOcean 以外的选择？
没有一个平台适合所有人，假装如此的指南也赢不了任何人的信任。以下是其他选择真正出色的场景：
专业 GPU 租赁平台（RunPod、Lambda、Vast.ai）。如果你的首要目标是尽可能便宜的原始 GPU 小时，并且不介意自行搭建，选这些。你能获得有竞争力的小时费率，尤其是像 RTX 4090 这种能良好运行量化 7B 模型的消费级显卡，代价是更多的 DIY 体验。
超大规模云（AWS、GCP、Azure）。如果你已经深度使用其中某个生态系统，或者想要竞价实例折扣以及与基础设施其余部分的紧密集成，选这些。代价是更复杂，通常成本也高于专注型服务商。
专用推理 API / 无服务器模型提供商。如果现成的开源模型能满足你的需求，并且你今天就想上线，选这些。这是最快获得可用端点的路径------但它们通常不像 BYOM 那样能托管自定义微调模型。
把这些选择一一列出来，是为了说明前面的推荐方案是经得起推敲的：小模型确实适合托管的 BYOM 和无服务器方案，你可以通过和每一种替代方案的坦诚对比来验证这一点。
快速入门：在 DigitalOcean BYOM 上托管你的微调模型
以下是从一组权重到可用的、兼容 OpenAI 的端点的完整路径：
第一步，准备你的模型。确认你的权重是 Safetensors 格式，使用支持的架构（目前为 Qwen2 或 Qwen3 系列），并且存放在 Hugging Face 仓库（接受受限仓库）或 DigitalOcean Spaces 存储桶中。你不能直接从电脑上传文件。
第二步，导入。在 DigitalOcean 控制面板中，打开 INFERENCE → Model Catalog → My Models，启动一个导入，指向你的 Hugging Face 仓库或 Spaces 位置。你可以同时运行多个导入，无需等上一个完成。
第三步，等待就绪。在 My Models 标签页跟踪状态。导入失败通常意味着缺少必需文件或架构不受支持。
第四步，部署到专用推理。从模型卡片创建一个专用推理部署，选择你的 GPU。你将获得一个专用的、兼容 OpenAI 的端点，按 GPU 小时计费。
第五步，调用。使用模型访问密钥，将任何兼容 OpenAI 的客户端指向你部署的 base URL：
from openai import OpenAI
client = OpenAI(
base_url="https://<your-deployment-url>.do-ai.run/v1/", # 在控制面板中显示
api_key="<your-model-access-key>",
)
resp = client.chat.completions.create(
model="<your-imported-model>",
messages=[{"role": "user", "content": "Hello!"}],
)
print(resp.choices[0].message.content)通过无服务器推理调用模型库中的模型也是同样的方式，只是 base URL 是共享的 https://inference.do-ai.run/v1/------所以你可以先用现成模型进行原型开发，之后通过修改一行代码切换到你的微调模型。
我们之前也写过一篇《微调后的 LLM 如何部署到生产环境？GPU 推理端点的搭建、测试与上线全流程》，详细讲述了该流程。
托管一个小型开源 LLM 需要多少费用？
核心的成本决策在于按 token 计费与按 GPU 小时计费之间的选择，而小模型让这个盈亏平衡点来得更快。推理的方法是，将两者换算成同一个单位------每百万 token 的成本------然后进行比较。
一个实例演算（吞吐量为示意值，请根据你自己的基准测试验证）：在一个 NVIDIA RTX 4000 Ada GPU Droplet（0.76/小时）上运行一个 4-bit 的 7B 模型。以保守的单流速率约 50 token/秒计算，大约是每小时 180,000 token，即每百万 token 约 4.20------前提是 GPU 保持忙碌。关键在于这个"前提"。连续批处理（vLLM 模式）可以将聚合吞吐量提升数倍，在高并发时使有效成本降至每百万 token $1 甚至更低；反之，如果你只用了 20% 的利用率却在为整块 GPU 付费，实际每 token 成本会翻五倍。相比之下，无服务器按 token 计费只按实际生成的 token 收费，因此在低流量或尖峰流量下几乎总是更便宜。当持续利用率足够高，让专用 GPU 的小时费用摊到实际服务的 token 上后，低于按 token 费率时，盈亏平衡就到来了。（Anyscale，连续批处理吞吐量基准）
你可以通过几个杠杆让盈亏平衡点向对你有利的方向移动：量化（更小的占用空间让你使用更便宜的 GPU------4-bit 7B 模型适合 $0.76/小时的 RTX 4000 Ada）、批处理（每块 GPU 最大的吞吐量倍增器）、自动归零（无服务器空闲时不收费）、以及预留容量（承诺使用 GPU Droplet 合约可为稳定工作负载降低小时费率）。无服务器按 token 费率按模型发布，请查看定价页面了解你要运行的具体模型的费率。
常见问题
Q：托管小型开源 LLM 最便宜的方式是什么？
无服务器按 token 推理在低流量或不可预测流量下最便宜，因为空闲时不用付费。对于持续高流量，运行量化模型的单个专用 GPU 每 token 成本更低。小模型让盈亏平衡点来得更早，因为它们可以放在一块便宜的 GPU 上。
Q：一个 7B 模型需要多少 VRAM？
FP16 下约 14 GB，8-bit 下约 7 GB，4-bit 下约 3.5 GB------这还不包括上下文和并发的额外开销。实际使用会更高，因为 KV cache 随上下文长度和并发请求数增长，所以请按峰值并发负载规划，而不仅仅是权重。
Q：运行 7B 模型需要 GPU 吗？
实践中是的，否则速度不够用。量化的 7B 模型可以轻松运行在单块 48 GB GPU（如 A6000 或 L40）上，为上下文留有充足空间。仅用 CPU 推理可行，但对大多数生产场景来说太慢了。
Q：量化后的 7B 模型需要什么 GPU？
单块 48 GB 显卡（A6000 或 L40）可以轻松运行量化后的 7--9B 模型，为上下文和并发留有空间；在 DigitalOcean 上，RTX 6000 Ada 或 L40S（$1.57/小时）是自然的选择，如果你要服务大量并发请求，可以选择 H100。
Q：无服务器 vs. GPU Droplet：哪个更便宜？
无服务器按 token 计费在低流量或变化流量时胜出；专用 GPU Droplet 在利用率持续高时胜出。要找到你的盈亏平衡点，估算每天持续的 token 数，比较按 token 费率与按 GPU 小时费用摊到实际服务的 token 上的成本。批处理和量化会让盈亏平衡点向专用 GPU 倾斜。
Q：我可以托管微调模型，而不仅是模型库中的模型吗？
可以------这正是自带模型（BYOM）的用途。你上传自己的微调权重，平台在其优化栈上提供服务，因此你不受限于固定的模型库。
Q：BYOM 支持哪些模型格式？
在 DigitalOcean 上，BYOM 导入接受来自 Hugging Face 或 Spaces 存储桶的 Safetensors 权重（以及标准的配套文件，如配置和分词器文件）。目前支持的架构是 Qwen 系列------Qwen2ForCausalLM 和 Qwen3ForCausalLM------因此如果你要导入不同基座模型的权重，请先检查导入要求。
Q：DigitalOcean 可以托管微调后的 Qwen 模型吗？
可以。Qwen 是目前支持的 BYOM 架构（Qwen2 和 Qwen3），这覆盖了像 Qwen3-8B 这样优秀的百亿参数以下基础模型。导入你的 Safetensors 权重，等待模型状态变为 Ready，然后部署到专用推理以获得兼容 OpenAI 的端点。如果你的微调模型使用非 Qwen 基座（如 Llama 或 Mistral），请在 GPU Droplet 上自行运行。
Q：如何将微调模型导入 DigitalOcean BYOM？
在控制面板中，打开 INFERENCE → Model Catalog → My Models，启动一个导入，指向你的 Hugging Face 仓库（接受受限仓库）或 Spaces 存储桶。等待状态变为 Ready，然后创建一个专用推理部署。导入必须是 Safetensors 文件，你不能直接从电脑上传------权重必须先存放在 Hugging Face 或 Spaces 中。
Q：无服务器推理有冷启动吗？
有的，在空闲期之后------空闲后的第一个请求可能会因为容量启动而变慢。这是自动归零、空闲时不付费的代价，对于小模型早期常见的突发流量来说，这通常是值得的。稳定、对延迟敏感的工作负载更适合专用部署。
Q：我可以从模型库模型切换到自己的微调模型吗？
可以，而且几乎不需要改代码。无服务器推理和 BYOM 专用推理都提供相同的兼容 OpenAI 的 API，因此你可以先用现成模型库进行原型开发，之后通过修改 base URL 和模型名称（各一行代码）切换到你的微调模型。
Q：如何在 DigitalOcean 上托管模型？
对于流行开源模型，使用模型访问密钥向无服务器推理 API（https://inference.do-ai.run/v1/）发送请求------无需任何配置。对于你自己的微调模型，通过 INFERENCE → Model Catalog → My Models 导入 Safetensors 权重，等待 Ready，然后创建一个专用推理部署以获得端点。如需完全控制，在 GPU Droplet 上自行运行。
结论
对于一个百亿参数以下的模型，问题不在于能不能托管------而是在于让托管方式适配你的流量、定制需求和预算。对大多数团队而言，这意味着从托管平台起步：如果模型库中的模型满足需求，使用无服务器推理；如果要部署自己的微调模型，使用专用推理上的 BYOM；只有当持续流量让自行管理 GPU 更便宜时，才升级到自行管理的 GPU Droplet。DigitalOcean 的 Gradient AI 平台在一张账单上覆盖了整个路径。如需了解DigitalOcean 无服务器推理、专用推理、GPU云服务器的详细价格，可访问卓普云官网aidroplet.com，或直接联系卓普云进行咨询，还可详谈近期的折扣信息。