camelAI自托管DeepSeek V4 Flash提供免费API

我们最近推出了一个由自托管 DeepSeek V4 Flash 驱动的免费套餐。我们一直想要一个有意义且不会产生亏损的免费套餐。三个月前，这还让人觉得不可能。自托管模型并不便宜，但它能让我们的免费套餐成本固定。

为了说明我们如何使用它：camelAI 的免费套餐（我们称之为 camelCode 的模型）运行在我们自托管于 AWS GPU 实例上的 DeepSeek V4 Flash 上。请求通过 Cloudflare AI Gateway 路由，如果我们的机器出现故障，它会回退到 Azure 托管的 DeepSeek，并且付费用户在同一硬件上享有比免费用户更高的调度优先级。

我们的整个方案是开源的，以下所有内容都在我们的仓库中：github.com/Vercantez/DeepSeek-V4-Flash-DSpark-RTX4。

选择模型与硬件

我们希望以最低价格获得最强大的设置。这两个目标是相互矛盾的。因此，我们必须确定适合我们产品的最低质量模型，以及我们实际能获得的硬件。

DeepSeek V4 Flash 规模较小。它是一个混合专家模型，总参数为 284B，但每个 token 仅激活 13B，这使得它能够在初创公司负担得起的硬件上提供服务。最初它在性能上有些吃力。但我能够围绕它优化我们的 harness，并将性能提升到足以通过 baseline eval 套件的水平（对免费套餐来说已经足够好）。

DeepSeek V4 Flash 在规模与性能之间达到了最佳平衡点。如果你想要更好的性能，就需要昂贵得多的 GPU。如果选更小的模型，性能会急剧下降。Artificial Analysis 的智能度与每任务成本对比图 将 Flash 置于帕累托前沿。它的能力足够强，以至于为每个免费用户支付 API 价格会让人心疼，而效率又足以让自托管变得可行。

Artificial Analysis 智能度指数与每智能度任务成本对比，显示 DeepSeek V4 Flash 处于帕累托前沿

对于硬件，我们从模型所需 GPU 内存开始，这归结于精度。模型权重是以某种位宽存储的数字。模型通常以 BF16 训练，即每个权重 16 位，训练后权重会被量化到更小的格式，这样模型运行所需的 GPU 内存和内存带宽更少。Flash 的公开检查点已经量化发布，其大部分权重采用 MXFP4，这是一种开放标准的 4 位浮点格式，在约四分之一内存的情况下保持接近 16 位原版的精度。在磁盘上大约为 150-160 GB，而完整 16 位版本则接近 570 GB。量化的检查点是我们唯一能容纳的版本，而且它仍然需要多个 GPU。

量化检查点将我们引向了 NVIDIA。Blackwell 是他们的当前 GPU 代，其 Tensor Core 原生支持 MXFP4，因此 4 位权重可获得全硬件加速，并且 NVIDIA 对开放模型的软件支持总体上最好。AMD 是一个选项，但支持较少，这意味着需要更多工作来寻找配置和自行修复问题。在 Blackwell 中，我们没有配额也没有资金购买 B200 机器，因此 RTX PRO 6000 成为我们实际能获得的最强大的显卡。在 AWS 上，这对应 G7e 实例系列。我们使用 g7e.24xlarge，它有四个 RTX PRO 6000，每个 96 GB，总共 384 GB，足以容纳量化权重并留有服务空间。

寻找方案

我们找到了 一个开源仓库，使用 DSpark 在 Blackwell GPU 上服务 DeepSeek V4 Flash，该模型和 GPU 代与我们在 AWS 上能获得的机器相同。我们的仓库将该工作适配到了四 GPU 机器上。它还包含了一个多用户推测解码所需的并发补丁，因此并非上游 vLLM 的原版。如果你复制我们的设置，请使用仓库中的镜像标签。

如果你计划托管某个模型，开源社区中很可能已经有人在你相近的硬件上服务过你想要的模型。请到 Hugging Face 和 GitHub 上查找参考方案，这些方案通常只是一条针对 vLLM（标准开源推理服务器）的长命令，包含加载哪个模型、使用什么精度以及什么内存设置的标志。

这种搜索也是我们选择 NVIDIA 的原因。大多数方案都是在 NVIDIA GPU 上编写和测试的，因此更多方案无需修改就能运行。

权重存放在区域 S3

竞价实例重启的频率比你想象的要高，因为 AWS 在需要容量时会回收它们。每次重启意味着需要将大约 150 GB 的权重下载到新机器上，所以权重的存放位置很关键。我们没有将它们集成到机器镜像中。相反，我们将不可变版本保存在与 GPU 同一区域的 S3 存储桶中。每次启动时，实例将版本复制到本地 NVMe，验证清单，然后启动 vLLM。

该版本包含权重以及使启动时间可接受的编译缓存。同区域 S3 可以快速可靠地交付所有这些内容，每个替换实例都会下载相同的已知良好工件。本地 NVMe 副本只是临时空间，因此当实例终止时，不会丢失任何内容，下一台机器会获取相同的版本。这对我们来说优于其他方案：回收后从 EBS 快照恢复很慢（因为快照需要充水），而将所有内容集成到机器镜像中会导致漂移（镜像中的缓存与你实际部署的容器不再匹配）。将存储桶放在同一区域远比听起来重要，因为跨区域下载会将短暂的实例替换变成长时间的停机。

使用推测解码提升速度

为了快速响应，我们需要推测解码。一个快速的小型草稿模型提议接下来的几个 token，然后大模型在单次并行传递中验证整个草稿，而不是逐个生成 token。大多数 token 很容易预测，因此大多数草稿会被接受，你可以在每个 GPU 周期内生成多个 token。当 token 难以预测时，加速效果会减弱，因此速度随内容而变化。

对于 DeepSeek V4，我们使用了 DSpark，这是 DeepSeek 自己的推测解码版本。它是一个轻量级的草稿模块，附加在模型权重上，而不是一个单独的模型。在我们的配置中，它只是一个标志：

--speculative-config '{"method":"dspark","num_speculative_tokens":5}'

结合四个 RTX PRO 6000 上的 DSpark，单流解码速度约为每秒 300 个 token。在真实的免费套餐负载下，每个用户每秒看到几十个 token，而随着批处理填满，聚合吞吐量攀升至约每秒 3000 个 token。一台机器最多支持约 64 个活动序列，超过则请求排队。当我们需要更高的并发性和每个用户的速度时，我们会添加另一台机器。

KV 缓存

在我看来，这是最重要的部分。对话中的每个 token 都有键值张量，模型在每个请求中都会重用它们，这些合起来就是 KV 缓存。在生产中，它会占用你大部分 GPU 内存，如果你忽略它，无论你的 GPU 有多快，它都会成为瓶颈。

DeepSeek 在这方面帮了我们，这也是我们选择它进行自托管的一个真正原因。加载模型和服务多个长会话是不同的问题。混合专家设计解决了前者，但我们的大部分流量是后者，因为 agent 会话运行时间很长。一个编码会话会累积工具结果、文件读取和之前的轮次，在大多数模型中，KV 缓存会随着历史记录的每个 token 而增长。少数长聊天会话就能填满 GPU，而其计算资源大部分处于空闲状态。

V4 的 注意力机制设计 避免了在每一层为每个过去的 token 保留完整条目。近期历史被压缩并稀疏地参与注意力，更早的历史被更激进地压缩，而一个短窗口的原始 token 则保持了最新细节的清晰。我们只为巨大的权重文件支付一次费用，之后，服务大量长会话的成本远低于参数数量所暗示的水平。

在我们的在线 worker 上，vLLM 报告大约 270 万个 token 的 GPU KV 缓存，约等于我们 256K 上限下的十个完整会话：

• GPU KV 缓存大小：2,712,968 token
• 每个请求 262,144 个 token 下的最大并发数：10.35x

我们做了三件事：

• 限制上下文窗口。Flash 支持 100 万个 token 的上下文，但长上下文会降低模型性能并占用更多内存。在完整的 1M 上下文下，几个用户就能填满我们整个缓存并阻止其他人，因此我们将每个用户限制在 256K，并在应用中在大约 220K 时压缩对话。
• 量化 KV 缓存。我们的生产配置使用了 DeepSeek 压缩注意力所支持的量化缓存路径，因此每个历史 token 消耗的内存更少。
• 卸载旧缓存。为长对话重新计算 KV 缓存（称为 prefill）会消耗 GPU 时间。但将每个空闲对话保留在 GPU 内存中会阻塞活动请求。vLLM 可以将 KV 缓存卸载到 CPU 内存和磁盘。这些 AWS 机器有大量空闲 RAM 和快速的 NVMe 磁盘，因此较冷的缓存会移动到那里，而不是占用 GPU 空间。卸载只有在用户的下一个请求落在拥有其缓存的机器上时才有效，因此我们在 worker 前面运行了一个粘性路由器，并将每个对话固定到一台机器上。

使其达到生产就绪状态

• 保护端点安全。我们将 GPU 保持在内部，只有我们的后端路径可以访问它们。
• 公平调度。vLLM 允许我们为请求分配优先级（--scheduling-policy priority），因此付费用户优先于免费用户。我们还降低了已经大量使用服务的免费用户的优先级，这样新用户就不需要在他们后面等待。
• 竞价实例恢复。当 AWS 回收实例时，我们的自动缩放组会启动一个替换实例，启动脚本将 S3 版本拉取到本地 NVMe，路由器只有在模型端点报告健康状态后才会发送流量。这一点很重要，因为一个实例在 AWS 中可能显示为 InService，但权重仍在加载中。
• 回退。竞价实例因为 AWS 可以随时回收而便宜，因此我们需要一个回退方案以保持持续正常运行时间。我们在 Cloudflare AI Gateway 后面运行，它为我们处理了这一点。当我们的竞价容量消失时，流量会转到 Azure 托管的 DeepSeek。Azure 比我们自己的机器慢且贵，但它接受我们的 Azure 积分，并且能让免费套餐保持在线。

成本

按需，一个 g7e.24xlarge 每月大约花费 12,000 美元。在竞价模式下，价格会波动，但 24/7 运行下来，在俄亥俄州大约花了我们每月 4,000 美元，在俄勒冈州大约 6,000 美元，竞价报价甚至更低。

具体数字不如成本行为重要。按 token 定价会随着使用量而扩展。给一百万个免费用户每人价值 1 美元的 token，你就得花费一百万美元。自托管的机器在固定规模上是固定成本，当更多人使用时，请求会被批处理或排队，因此服务会变慢而不是更贵。这是我们想要的免费套餐的权衡。免费用户响应变慢是可接受的成本，但随欺诈和滥用而增长的账单则不可接受。仍然随需求扩展的花费是回退方案，以及最终当我们超出当前机器时增加另一台机器。

竞价加上云积分让我们在经济上可行。我们的 AWS 积分支付竞价实例，Azure 积分支付回退，因此在这些积分有效期间，免费套餐在我们成长过程中几乎不花实际现金。

下一步

我们目前正在做两件事。

我们正在评估 Poolside Laguna S 2.1。它比 DeepSeek V4 Flash 小，总参数约 118B，激活参数 8B，而 V4 Flash 是 284B 和 13B，因此如果质量在 agent 工作负载上能保持，它应该更容易适配且更便宜。我们正在通过相同的 harness 运行它，以检查是否如此，以及是否在我们已有的硬件上服务更简单。

我们正在使用为 camelAI 构建的评估集对其自托管模型进行微调。免费套餐只有在模型擅长我们的产品时才有效，而不仅仅在公开基准上表现好。这些评估是我们决定训练内容的方式，也是我们判断像 Laguna 这样的候选模型或 Flash 的微调版本是否对用户更好的依据。

TL;DR

• 我们共同选择了模型和硬件：在 4x RTX PRO 6000 Blackwell（AWS g7e.24xlarge）上的 DeepSeek V4 Flash。
• 我们从社区方案开始并进行了适配。我们的方案在这里。
• 权重存放在同区域 S3，每次启动时复制到本地 NVMe。
• 使用 DSpark 推测解码提升速度。
• KV 缓存最为关键。Flash 的压缩注意力使我们能拥有约 270 万个 token 的 GPU KV 缓存，约等于我们 256K 上限下的十个会话。我们限制了上下文、量化了缓存、卸载了空闲缓存，并将每个对话固定到一个 worker。
• 付费用户优先调度，以及当竞价容量消失时的网关回退。
• 成本：每台机器在竞价模式下每月约 4,000-6,000 美元，按需约 12,000 美元，在固定规模下为固定成本。更多用户意味着服务变慢，而非账单变大。
• 下一步，我们正在评估较小的模型 Laguna S 2.1 进行服务，并使用我们自己的评估集微调 Flash。

• 原文链接： x.com/Vercantez/status/2...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～