文章来源：https://www.pyspur.dev/blog/deepseek_open_source_week
DeepSeek 的"开源周"，宛如一颗重磅炸弹，在全球AI领域激起千层浪。然而，DeepSeek"开源周"带来的影响远不止技术层面，它如同导火索，引发了大模型开源与闭源之争这一行业热议话题。在大模型领域，开源与闭源一直是两种不同的发展路径，各有拥趸，而DeepSeek的开源举动，让这场争论更加激烈。
DeepSeek 在其 "开源一周" 活动中，发布了六个软件库，这些库分别针对不同的问题：
第 1 天：FlashMLA - 多头潜在注意力解码 CUDA 内核 第 2 天：DeepEP - 用于 MoE 模型内部专家并行性的 CUDA 内核 第 3 天：DeepGEMM - FP8 矩阵乘法 (GEMM) 库 第 4 天：DualPipe 和 EPLB - 管道并行性和负载均衡器策略 第 5 天：3FS 和 Smallpond - 用于高吞吐量数据访问的并行文件系统 第 6 天：DeepSeek-V3/R1 - 如何以 545% 的利润率运营
虽然其中许多技术都出现在早期的 DeepSeek 论文中，但最终看到实际代码公开发布还是令人欣喜。对于像我们这样的研究人员和开发人员来说，这意味着我们现在有了具体的示例和工具来构建更高效、可扩展的 LLM 管道。
希望这种开放态度能激励其他团队（你知道我指的是哪些团队）分享更多他们的基础设施。想象一下，如果更多实验室采用这种方法，这个领域会发展得多么快。
第一天：FlashMLA - 高效的多头潜在注意力
在讨论 FlashMLA 之前，让我们先了解为什么键值 (KV) 缓存优化对于 LLM 推理至关重要。
当语言模型在推理过程中生成文本时，它每次生成一个 token，并且每个新 token 都需要考虑之前生成的所有 token。如果不进行任何优化，这意味着每个 token 的注意力计算量会呈二次增长z^2—导致整体复杂性在z^3 生成整个序列。KV 缓存通过存储先前计算的键和值来帮助解决此问题，因此每个新 token 只需要针对这些存储的值计算一次注意力。这降低了每个 token 的复杂度为z,总复杂度降低至z^2完整序列。但代价是需要更多内存来存储这些缓存值。
为了减少 KV 缓存的内存负担，已经提出了几种方法。与之前通过共享注意力头来减少内存使用量的方法（如多查询注意力 (MQA) 或组查询注意力(GQA)）不同，MLA采用了一种巧妙的低秩潜在压缩技术，可以保留多个注意力头的优势。
FlashMLA 是多头潜在注意力 (MLA) 的高效实现，专为 Hopper GPU 设计，并针对生产环境中的可变长度序列进行了优化。FlashMLA 提供了一个可实现卓越性能的 CUDA 内核：在 H800 GPU 上，内存限制性能高达 3 TB/s，最大带宽为 3.36 TB/s [ 4 ]，这意味着 FlashMLA 可实现近 90% 的可用内存带宽利用率。如此高的利用率与之前的注意力实现（如 FlashAttention 2 和 3）相比有显著的改进，后者的带宽利用率通常为 35% 到 75% [ 5 ]。
FlashMLA 实现的一个特别有趣的方面是其对共享键/值张量的双缓冲方法。虽然双缓冲是一种标准的优化技术，但 FlashMLA 的实现在处理压缩潜在表示的方式上是独一无二的。为了清晰起见，我们在下面分享了一个简化的代码示例，该示例结合了受实际实现各个部分启发的元素。
FLASH_ASSERT(params.k_ptr == params.v_ptr); // Shared_KV
// ...
if (n_block % 2 == 1) {
// Double buffer for sK
constexpr int sK_offset = size(sK);
tSrK.data() = tSrK.data() + sK_offset / 8;
tOrVt.data() = tOrVt.data() + sK_offset / 8;
}
这种实现很巧妙，原因如下。首先，表明 Key 和 Value 张量巧妙地共享相同的内存空间，立即将内存需求减半。其次，该条件以最少的逻辑实现乒乓缓冲，只需根据块号奇偶校验进行切换（当一个缓冲区用于计算时，另一个可以加载数据）。第三，两个指针调整（和）中的除以 8 直接实现了 MLA 的潜在压缩比，允许代码使用压缩表示，同时保持正确的内存对齐。最后，通过同时调整 Key 和 Value 张量指针相同的偏移量，即使在切换缓冲区后，每个键也会与其对应的值匹配。
FLASH_ASSERT(params.k_ptr == params.v_ptr)if (n_block % 2 == 1)tSrK.data() + sK_offset / 8tOrVt.data() + sK_offset / 8
FlashMLA 支持 BF16 和 FP16 精度，并采用块大小为 64 的分页 KV 缓存，这意味着每个内存块可以存储 64 个令牌的键值数据。这种分页方法将 KV 缓存划分为固定大小的块，这些块可以动态分配和释放，从而能够更高效地处理可变长度序列。64 个令牌的块大小是专门为 H800 等 Hopper GPU 选择的。
第二天：DeepEP - 专家并行通信库
混合专家 (MoE) 模型是一种功能强大的架构，它使用多个专门的子网络（称为"专家"）来扩展语言模型，每个子网络都旨在处理特定类型的输入。虽然 MoE 模型可以显著提高性能，但它们带来了复杂的通信挑战，尤其是在跨多个 GPU 和节点部署时。
DeepEP 是一个专门的通信库，它优化了 MoE 模型中的关键通信模式，特别是"调度"和"组合"操作，这对于在 GPU 之间路由数据至关重要。
在 MoE 架构中，每个输入 token 都会根据其特征路由到多个专家。例如，DeepSeek-V3 有6710亿个参数，分布在 257 个专家（1个共享专家和 256个路由专家）中。每个 token 可激活 8 个不同的专家，但为了管理通信成本，每个 token 最多只能访问 4 个节点上的专家。
此路由过程引入了两个关键的通信操作：
调度：这涉及将令牌嵌入从其原始 GPU 发送到承载选定专家的 GPU。 合并：专家处理完 token 后，此步骤将结果收集回其原始 GPU。 如果不仔细优化，这些通信步骤很快就会成为主要的性能瓶颈。例如，如果我们是否有GPU，并且每个 GPU 都需要将令牌路由到可能位于其他每个 GPU 上的专家。此外，如果通信与计算不重叠，GPU 将经历空闲期，从而浪费宝贵的资源。
为了应对这些挑战，DeepEP 引入了多项优化：
首先，DeepEP 优化了NVLink 和 RDMA 流量。NVLink 支持同一节点内 GPU 之间的高速数据传输，而 RDMA（远程直接内存访问）则可实现跨不同节点 GPU 之间的高效直接内存传输，完全绕过 CPU 的参与。对于前者，它们引入了将数据从 NVLink 域转发到 RDMA 域的指定内核。为了减少跨节点 RDMA 流量，DeepEP 将每个令牌限制为最多访问四个节点上的专家。
其次，它提供了针对训练和推理工作负载量身定制的不同通信内核。对于训练和预填充任务，它使用结合了 NVLink 和 RDMA 转发的标准内核。这些内核在节点内通信中实现了理论最大 NVLink 带宽的大约 95%（160 GB/s 中的 153-158 GB/s），在节点间通信中实现了最大 RDMA 带宽的大约 90%（50 GB/s 中的 43-47 GB/s）。对于推理场景，DeepEP 采用纯粹依赖于 RDMA 的专门的低延迟内核。值得注意的是，即使从 8 个专家扩展到 256 个专家，这些内核也表现出极小的延迟增加 - 尽管规模增加了 32 倍，但调度延迟仅增加了约 19%。此外，组合延迟在所有规模上保持稳定（在 318-369μs 之间），始终实现 80% 至 92% 的高 RDMA 带宽利用率。
此外，DeepEP 仅对每个 GPU 可用的 132 个流多处理器 (SM) 中的 20 个进行硬编码以处理通信任务。这使得大多数 SM 可以专注于计算。
此外，它们还提供了一个基于 PyTorch 钩子的接口，用于重叠通信和计算，其中实际数据传输直到您明确调用钩子时才会完成。这允许您尽早启动数据传输，在数据传输时执行其他计算，并在实际需要数据时稍后调用钩子。
def low_latency_dispatch(hidden_states: torch.Tensor, topk_idx: torch.Tensor, num_max_dispatch_tokens_per_rank: int, num_experts: int):
global _buffer
# Do MoE dispatch, compatible with CUDA graph (but you may restore some buffer status once you replay)
recv_hidden_states, recv_expert_count, handle, event, hook = \
_buffer.low_latency_dispatch(hidden_states, topk_idx, num_max_dispatch_tokens_per_rank, num_experts,
async_finish=False, return_recv_hook=True)
# NOTES: the actual tensor will not be received only if you call `hook()`,
# it is useful for double-batch overlapping, but **without any SM occupation**
# If you don't want to overlap, please set `return_recv_hook=False`
# Later, you can use our GEMM library to do the computation with this specific format
return recv_hidden_states, recv_expert_count, handle, event, hook
def low_latency_combine(hidden_states: torch.Tensor,
topk_idx: torch.Tensor, topk_weights: torch.Tensor, handle: Tuple):
global _buffer
# Do MoE combine, compatible with CUDA graph (but you may restore some buffer status once you replay)
combined_hidden_states, event_overlap, hook = \
_buffer.low_latency_combine(hidden_states, topk_idx, topk_weights, handle,
async_finish=False, return_recv_hook=True)
# NOTES: the same behavior as described in the dispatch kernel
return combined_hidden_states, event_overlap, hook
FP8 精度原生支持调度操作，从而减少了内存占用和通信带宽要求。
最后，引入流量隔离和自适应路由，以动态管理网络路径并隔离关键通信流。流量隔离将不同的工作负载（正常内核、低延迟内核和其他工作负载）隔离在不同的虚拟通道上，以防止干扰。自适应路由在多个网络路径之间动态分配流量以避免拥塞。
第 3 天：DeepGEMM - FP8 矩阵乘法
在优化注意力机制和专家并行性之后，DeepSeek 转向了两者的基础运算：矩阵乘法。通用矩阵乘法(GEMM) 运算是 LLM 的计算支柱，几乎无处不在。
DeepGEMM 是专为 Hopper GPU 设计的 FP8 矩阵乘法专用库。尽管它紧凑地实现了约 300 行 CUDA 代码，但与 NVIDIA 的 GEMM 库CUTLASS相比，它的性能令人印象深刻：
对于小型或不规则矩阵，加速高达 2.7 倍（对于推理尤其重要） 对于大型计算密集型矩阵，加速 1.0×-1.7× MoE 分组 GEMM 的速度提高了 1.1 倍至 1.2 倍
实现这一目标的关键技术：
细粒度 FP8 量化
DeepGEMM在 DeepSeek-V3 论文[ 10 ]中使用，其概念灵感来自 Rouhani 等人[ 11 ]，它采用细粒度量化策略来解决 FP8 精度的有限动态范围问题，而这一问题通常会导致上溢和下溢问题。DeepGEMM 不会应用单个全局缩放因子，而是以更精细的级别应用缩放，从而显著提高量化精度和数值稳定性。
具体来说，DeepGEMM 使用不同粒度的单独缩放因子来量化激活和权重。激活按 128 个通道组（1 × 128 个图块）按标记量化，而权重按 128 个输入通道乘以 128 个输出通道（128 × 128 个块）进行量化。
与简单的 FP8 量化相比，这种细粒度量化方法提高了数值稳定性。首先，通过调整缩放因子以适应较小的元素组，该方法可以有效地适应激活异常值。最后，中间 FP8 结果会定期在 CUDA 核心上提升到 FP32 精度，从而减轻累积误差。
专家混合支持
DeepGEMM 为混合专家 (MoE) 模型提供专门支持，利用两种针对模型使用不同阶段量身定制的优化分组 GEMM 实现。第一种是专为训练和预填充阶段设计的连续布局，其中分配给每个专家的标记被连接起来以实现高效处理。第二种是用于推理场景的屏蔽布局，特别是在使用 CUDA 图时，允许模型高效地仅处理每个专家的有效标记。
根据 DeepSeek-V3 论文[ 10 ]中提出的评估，这种专门的 MoE 支持带来了显著的性能提升，与经过专业调整的 CUTLASS 实现相比，速度提高了 1.1-1.2 倍。
未对齐的块大小
与大多数使用 2 的幂次方块大小（128、256）的 GEMM 库不同，DeepGEMM 支持未对齐的块大小，例如 112。这种看似微不足道的优化显著提高了推理中常见的不规则矩阵形状的 GPU 利用率。例如，使用，可以使用 128 个 SM，而不仅仅是 112 个。
SM 利用率提高 12.2% 直接转化为性能提升。
即时编译
DeepGEMM 在运行时生成专门针对每个矩阵乘法的维度定制的内核。与传统的 GEMM 库不同，传统的 GEMM 库会预编译用于处理任意矩阵形状的通用内核，因此会产生分支、循环和额外逻辑的开销，而 DeepGEMM 的方法可以精确优化给定的操作维度。通过将矩阵维度 (M、N、K) 视为编译时常量，编译器可以完全展开循环、消除边界检查，并实现完全针对特定形状定制的最佳寄存器分配。
此外，DeepGEMM 还会自动确定每种矩阵形状的理想参数，包括最佳块尺寸（例如 112 等未对齐大小），以最大限度地提高 GPU 利用率、基于算术强度的最佳管道级数以及最合适的张量内存加速器 (TMA) 集群大小。这种细粒度优化可显著提高性能，特别是对于推理过程中经常遇到的小矩阵，其中通用内核通常会将计算周期浪费在不必要的逻辑上。
指令级优化
在最底层，DeepGEMM 优化了 CUDA 指令调度。具体来说，它直接在编译的二进制文件中修改 FFMA（融合乘加）指令的产量和重用位，这是一种通过精确的指令交错来增强 warp 级并行性的技术。
每条 CUDA 指令都包含影响调度行为的控制位：让出位决定流多处理器 (SM) 在执行指令后是否可以让出当前 warp，而重用位则指示寄存器是否可以立即重用或必须等待。通过基于通过二进制分析识别出的模式系统地调整这些指令位，DeepGEMM 可以控制执行计划。这种方法允许内存操作（例如加载矩阵元素）与张量核心执行的计算操作无缝重叠，而后者又与涉及 CUDA 核心累积的提升操作重叠。这种精确的计时非常有用，因为 GPU 硬件包含能够同时执行这些操作的独立单元，但前提是明确指示这样做。由此产生的操作同步和重叠使所有 GPU 单元保持积极参与，从而消除了空闲等待期。
第 4 天：优化并行策略（DualPipe 和 EPLB）
在优化了 LLM 的核心计算构建块之后，我们现在开始应对在多个 GPU 上高效协调这些操作的挑战。第 4 天介绍了两种互补的技术：用于高效管道并行的 DualPipe 和用于平衡专家分布的 EPLB。
DualPipe：双向管道并行
DualPipe 引入了双向流水线并行算法，实现了前向和后向计算通信阶段的完全重叠，显著减少了流水线气泡。
在传统的流水线并行中，大型神经网络被拆分到多个 GPU 上，每个 GPU 负责处理模型的不同部分。问题在于，GPU 经常需要等待——要么等待前向传播过程中较早阶段的数据，要么等待反向传播过程中较晚阶段的梯度。这些空闲时间就是我们所说的"流水线泡沫"，它们会浪费宝贵的 GPU 资源。
这是一个简单的例子。假设一个模型分布在 2 个 GPU 上，其中 GPU 2 无法开始处理批次 A 的前向传递，直到 GPU 1 完成其部分。在反向传播期间，同样的问题反过来发生 - GPU 等待来自下游 GPU 的梯度。这些等待期会在管道中产生空闲间隙或"气泡"。管道阶段越多（例如在非常大的模型中），气泡就越多，从而使扩展效率低下。
DualPipe 通过同时向前和向后运行微批次来解决此问题。这意味着新批次的前向传递与先前批次的后向传递重叠。通过将 GPU 到 GPU 的通信与计算重叠，它可以有效地减少空闲时间。
该图显示了 DualPipe 调度，其中有 8 个流水线并行等级和 20 个微批次在两个方向上运行。共享黑色边框的单元格表示重叠的计算和通信。
为了将通信和计算重叠起来，DualPipe 将数据传输拆分成更小的块（"微批量流式传输"），允许计算从第一个块开始，而后面的块仍在传输。通过使用多个 CUDA 流，通信和计算可以在单独的 GPU 线程上异步运行。此外，反向传递被拆分成两个不同的部分：输入梯度计算要传递到上游的梯度，而权重梯度计算用于更新当前层参数的梯度。
通过分离这些，输入梯度可以立即发送到上游，从而加快早期管道阶段的反向传递。
EPLB：专家并行负载均衡器 使用专家并行时，一个常见的挑战是确保计算负载均匀分布在 GPU 上。专家并行负载均衡器 (EPLB) 通过复制工作量大的专家来解决此问题。然后，这些重复的专家将被策略性地分配到 GPU，以帮助平衡整体计算需求。
EPLB 根据具体情况提供两种不同的策略：
第一种方法是分层负载平衡，适用于服务器节点数均匀划分专家组的情况。此方法最初将专家组均匀分布在节点之间，以平衡节点工作负载。在每个节点内，负载过重的专家会被复制并分配给各个 GPU，以进一步平衡负载。这种方法与DeepSeek-V3 [ 10 ]中的组限制专家路由技术密切相关，该技术将令牌路由限制在特定组内的专家，以本地化计算。EPLB 会尽可能将同一组的专家放在同一节点上，从而显著减少跨节点通信开销。通常，这种分层方法在预填充阶段很有用，因为此时专家并行规模较小。
第二种是全局负载平衡，用于分层方法不可行的场景。在这种方法中，专家的复制不考虑其原始组，并且这些副本在 GPU 上全局分布。此策略在解码阶段特别有效，因为此时专家并行规模往往较大。
下图显示了 EPLB 如何跨节点和 GPU 分配专家：
在此示例中，我们有一个两层的 MoE 模型，每层包含 12 位专家。通过每层添加 4 位冗余专家，我们最终总共拥有 16 个专家副本。这些副本分布在 2 个节点上，每个节点有 4 个 GPU，从而实现平衡的计算负载并最大限度地减少通信开销。
第 5 天：3FS 和 Smallpond - LLM 的数据基础设施
随着我们从计算转向数据管理，第 5 天介绍了两个互补的工具，用于解决大规模 LLM 训练和推理的数据基础设施挑战：Fire-Flyer 文件系统 (3FS) 和 Smallpond。
Fire-Flyer 文件系统 (3FS)
在处理分布在多个节点上的海量数据集时，HDFS 或 Lustre 等传统文件系统并不适用，因为它们依赖于数据局部性，要求计算节点在物理上靠近其数据。这会使扩展变得复杂并限制灵活性。
3FS 通过采用完全分解的架构解决了这个问题。它聚合了数百个存储节点上数千个高速 SSD 的带宽和存储容量，使计算节点能够快速访问数据，而无需担心数据的准确位置。这大大简化了集群管理。
该图显示了 180 节点 3FS 集群随时间变化的读取吞吐量，峰值约为 7 TiB/s。这种出色的性能使 3FS 成为训练和推理期间高吞吐量数据访问的理想选择。
3FS 的另一个关键优势是其强大的一致性模型，由带分配查询的链式复制 (CRAQ)提供支持。与传统的链式复制不同，后者会在尾节点处造成读取瓶颈，而 CRAQ 允许链中的任何节点直接提供读取服务。节点同时维护完全提交（"干净"）和正在进行（"脏"）的数据版本。干净的数据可以立即提供，而脏数据会触发尾节点的快速版本检查。这种设计可确保高吞吐量和强一致性 - 这对于 AI 工作负载至关重要，因为数据不一致可能会导致细微的错误或降低模型性能。
从性能方面来看，热心的读者现在可能已经猜到了，3FS 确实令人印象深刻：
在 180 节点集群上实现约 6.6 TiB/s 的总读取吞吐量。 每个客户端节点为 KVCache 查找提供高达 40 GiB/s 的速度，非常适合推理工作负载。图：KVCache 读取吞吐量性能显示峰值读取速度达到每个客户端节点 40 GiB/s（虚线）和 30 分钟内的平均读取速度（实线）。一致的高峰值性能证明了 3FS 能够高效处理密集推理工作负载。
3FS 尤其适用于：
Dataloaders：跨多个节点高效随机访问训练样本，简化数据加载逻辑。
检查点：快速、并行的检查点对于训练大型模型至关重要。
用于推理的KV 缓存：基于 DRAM 的缓存的经济高效替代方案，提供高吞吐量和更大的存储容量。这种方法使计算节点能够以最小的延迟损失从 3FS 动态获取缓存的键值对，无需将所有数据存储在 RAM 中。 假设您正在使用 10 TB 的文本数据集训练语言模型。如果没有 3FS，您可能必须将此数据集分片到每台训练机器上的本地磁盘，并确保每个 GPU 从其本地存储获取数据以避免网络变慢。使用 3FS，您可以将所有 10 TB 放入文件系统，并让每个节点随意读取它：
在每台训练机器上（假设有 16 台），安装 3FS 。/data
在您的训练代码中，您从中加载文件（其中 X 可以是数据集的一部分）。每个 DataLoader 工作器将通过 3FS 打开一个文件，读取一个数据块。3FS 内部将从适当的存储服务器（如果文件的块跨服务器，则可能并行从多个服务器）获取该块。/data/my_corpus/shardX.txt
如果每台服务器的速度为 50 GB/s，而您有 10 台服务器，则总计可提供 500 GB/s。理论上，如果需要，16 个节点中的每一个都可以拉动 >30 GB/s。实际上，也许每个节点可能会使用 5-10 GB/s 来使 GPU 饱和。3FS 可以轻松提供这一点。
训练在进行时不会出现数据不足的情况。GPU 100% 忙于计算，而不是有时等待 CPU/磁盘加载。
在检查点时，每个节点上的训练器将其模型分区保存到 中的文件中。所有节点同时执行此操作。3FS 将每次写入定向到可能不同的存储目标（以分散负载），并且写入并行进行。结果是，您可能在 30 秒内完成检查点，而以前在 NFS 上需要 5 分钟。/data/checkpoints/epoch10_rank7.ckpt
第六天：DeepSeek-V3/R1 - 大规模跨节点专家并行以及如何以 545% 的利润率运营
在最后一天，DeepSeek 发布了有关 DeepSeek-V3/R1 推理系统的详细信息——这是一次前所未有的、近距离的对大规模服务于 LLM 的生产系统的观察。鉴于 DeepSeek-V3/R1 的高稀疏性（每层256 位专家中只有 8 位被激活），高效的并行策略至关重要。在预填充期间，系统采用Routed Expert EP32和MLA/Shared Expert DP32并行性，每个部署单元跨越四个节点。每个 GPU 管理九个路由专家和一个共享专家。相比之下，解码阶段使用Routed Expert EP144和MLA/Shared Expert DP144并行性，将部署单元扩展到十八个节点，每个 GPU 处理两个路由专家。
系统采用与训练一致的精度格式，具体来说，前馈矩阵乘法和调度传输采用FP8 格式，核心 MLA 计算和组合传输采用BF16 格式。这种精度策略确保与训练过程保持一致。
为了优化吞吐量，DeepSeek 采用了复杂的双批次重叠策略，该策略专门用于缓解大规模跨节点专家并行 (EP) 带来的大量通信开销。在预填充阶段，每批请求被分成两个微批次，交替执行。这种交替执行允许一个微批次的通信延迟有效地隐藏在另一个微批次的计算之后，从而显著提高整体吞吐量。在解码阶段，不同阶段的执行时间本质上是不平衡的。为了解决这个问题，DeepSeek 将注意力层细分为两个不同的计算步骤，并将它们集成到精心编排的五阶段管道中。这种管道结构确保计算和通信的无缝重叠，进一步减少延迟并最大限度地提高 GPU 利用率。这种细致的设计对于保持高吞吐量和低延迟至关重要，尤其是考虑到 DeepSeek-V3/R1 推理工作负载的复杂性和规模。
DeepSeek 还采用了专门的负载平衡策略：预填充负载平衡器均衡令牌数和计算需求，解码负载平衡器管理 KVCache 使用中的差异，专家并行负载平衡器在 GPU 之间复制负载重的专家以缓解不平衡。
DeepSeek 的推理系统根据每日负载模式动态扩展资源，在高峰时段最大化 GPU 利用率，在非高峰时段重新分配资源。这种方法显著提高了成本效率和性能。在 24 小时统计期内，V3 和 R1 推理服务的合并峰值节点占用率达到278 个节点，平均占用率为226.75 个节点（每个节点包含 8 个 H800 GPU）。假设一个 H800 GPU 的租赁成本为每小时 2 美元，则每日总成本为87,072 美元。
在典型的 24 小时内，系统可以高效处理大量工作负载：
总输入 token 数：608B，其中342B（56.3%）命中磁盘 KV 缓存 总输出token：168B 平均产出速度：每秒20-22个代币 每个输出令牌的平均 KVCache 长度：4,989 个令牌 每个 H800 节点的平均预填充吞吐量：~73.7k 个令牌/秒（包括缓存命中） 每个 H800 节点的平均解码吞吐量：~14.8k token/s
关键在于，这让 DeepSeek 实现了 545% 的成本利润率，同时比 OpenAI 的 o1 便宜约 96%：
对于缓存命中的输入令牌，R1 成本为每百万 0.14 美元 对于缓存未命中的输入令牌，R1 的成本为每百万 0.55 美元，而 o1 的成本为每百万 15.00 美元 对于输出代币，R1每百万成本为 2.19 美元，而 o1 每百万成本为 60.00 美元
然而，DeepSeek 指出，他们的实际收入远低于这些理论计算，因为：
DeepSeek-V3 的定价明显低于 R1 仅一部分服务实现盈利（网页和APP访问仍然免费） 非高峰时段自动应用夜间折扣。
感谢你看到这里，也欢迎点击关注下方公众号并添加公众号小助手加入官方读者交流群，一个有趣有AI的AIGC公众号:关注AI、深度学习、计算机视觉、AIGC、Stable Diffusion、Sora等相关技术，欢迎一起交流学习💗～
没有评论:
发表评论