2024年计算机行业专题研究：国产大模型“凭”什么降价？

拆解大模型推理过程，洞察国产模型降价本质

表现：国产厂商进入 API“价格战”阶段

幻方 DeepSeek V2 引发了国产大模型厂商的降价浪潮。2024 年 5 月 6 日，幻方旗下深度 求索（Deepseek）发布最新 MoE 模型 DeepSeek-V2，并将模型的 API 定价为：每百万 tokens 输入 1 元、输出 2 元（32K 上下文），价格仅为 GPT-4-Turbo 的近百分之一，刷新了大模 型 API 的低价记录。随后，部分国内大模型初创公司、互联网厂商、科技公司等陆续宣布 模型 API 降价，有些甚至将 API 免费提供。

降价甚至免费的模型，不一定是厂商最先进的模型。基于各大模型厂商的降价现象，我们 统计了被降价的模型细节，发现降价甚至免费的，并不是模型厂商最先进的模型，往往是 Lite 轻量版或本身价格较低的模型。我们认为，国产厂商在这波降价中，并不会盲目打“价 格战”，仍然会考虑成本等因素，“循序渐进”。此外，还可以发现，降价幅度较大（80%以 上）的多是国内互联网大厂，拥有自有的云算力基础设施。

对于大批量、高并发、快速率调用 API 的 B 端用户或影响不大。以上所提各厂商降价的模 型，都是按照使用 token 数进行计费，其默认对于 API 并发性和速率等指标（包括 QPS、 RPM、TPM 等）支持有限。以百度问心 ERNIE 模型为例，官方将限制单位时间段内用户 访问 API 服务的次数/消耗 tokens 数的上限，防止 API 滥用。如果要提升 RPM/TPM 配额， 需要购买 TPM 包或者 Tokens 包。对于免费的 ERNIE-Speed / Lite-8K 模型，默认 RPM 为 300、TPM=300K，即 API 每分钟最多可以处理 300 个请求、消耗 30 万 tokens，而对于更 先进的 4.0 系列模型，RPM 和 TPM 更低。若要提高 ERNIE-Speed-8k 的 RPM 和 TPM， 则每提高 10,000 TPM 和 33 RPM，需要￥5/小时或￥1900/月的额外付费。

综上，我们认为，国产厂商降价的逻辑或有以下几点： 1）技术上看，确实能够通过优化 Transformer 架构中的各个部件，实现推理成本的降低。 DeepSeek V2 本身就是典型的实践，其降本逻辑在于：改进的 MoE 架构，降低训练成本； 优化的 KV cache 机制，大幅降低推理成本。我们将在随后详细拆解其相关技术。如果其他 国内模型厂商，同样在底层应用了类似的优化技术，那么降本就是已经发生的过去式， DeepSeek V2 在 5 月的降价或是激发各厂家拿出“技术降本”结果。字节火山引擎总裁谭 待在 5 月豆包发布会上也指明，降价的背后主要原因是技术，未来还有很多手段继续降低 成本，并不亏损。 2）牺牲部分成本，抢占生态或仍然划算。假设短期内，国内模型厂商并没有迅速跟进合适 的降本技术，基于国产模型辨识度并不是特别高、性能差距不是特别大的现实，应用开发 者在选择各家模型 API 时，或具有一定的随意性。在这种情况下，借 DeepSeek V2“技术 降价”引起的大模型降本浪潮，通过压低价格吸引应用开发者，或是培养自身开发者生态 的重要举措。开发者生态的繁荣，是形成“数据和场景→模型迭代→模型性能提升→更多 开发者→更多数据”正向反馈的重要基础，短期牺牲部分成本，长期看或仍然划算。 3）加速出清，实现资源集中度提升。国产模型厂商数量众多，导致资金、算力、数据等资 源分散，头部厂商也无法快速建立如 OpenAI 的龙头或数据飞轮效应。通过降价方式，实现 部分模型厂商出清，或有利于大模型产业的各类资源（包括人才）集中，有可能让剩余厂 商在“百模大战 2.0”阶段，实现模型能力上的跃升。4）API 商业模式的最终形态尚未确立，降价能够促进 AI 进入业务流，加速商业模式迭代。 据极客公园、百度和字节官方数据，截至 24 年 5 月，文心大模型日处理文本 2500 亿 token， 字节跳动日均处理 1200 亿 token 文本，但其中很大一部分是大厂内部业务在调用做 AI 应 用和业务探索，因此，降价本身带给模型厂商的“损失”或有限。我们认为，通过外部调 用 API，并根据调用 token 数量收费的商业模式或还不是 API 的最终商业模式，但是 API 降价却能加速 AI 进入业务流的节奏，加快 API 商业模式迭代。

降价并不是国内“特色”，OpenAI 已经进行了多次降价。OpenAI 的 GPT-3.5 turbo 系列， 从 23 年 3 月问世以来，已经经历了三次降价，最新价格与最初价格相比，输入价格降低了 75%，输出价格降低了 25%，上下文长度提升 4x；GPT-4 系列的 turbo 与 4o 版本出现后， 也在屡次刷新 OpenAI 模型的价格底线。

总结看，我们认为：1）利好应用。大模型 API 降价，对于 ISV 开发者吸引力较大，AI 应 用的开发门槛更低，ROI 更易回正，Super App 问世可能性加大。2）降价产品或蔓延。目 前，模型厂商大幅降价的 API 还不是最强的模型，下一步降价可能会向主力 SOTA（state of the art）模型持续蔓延。3）降价是表，模型能力是里。23 年至今没有出现 Super App 或 者能大规模投入生产的 Agent 智能体，本质原因还是模型的推理正确率不够高，无法保证 多步骤复杂任务流程最终的准确性。模型厂商最终还是要回归模型本质——推理能力。

趋势：长上下文已经成为全球模型的共性发展特点

国内外主流模型厂商均实现了模型对长文本能力的支持。国外较早实现长上下文的厂商是 Anthropic，旗下 Claude 模型在 23 年 11 月，将支持的上下文从 100K tokens 提升到 200K， 同时期的 GPT-4 维持在 128K。24 年 2 月，Google 更新 Gemini 到 1.5 Pro 版本，将上下 文长度扩展到 1M（5 月更新中扩展到 2M），并在内部实现了 10M，是目前已知最大上下文 长度。国内方面，23 年 10 月由月之暗面发布的 Kimi 智能助手（原名 Kimi Chat），率先提 供 20 万字的长上下文支持，24 年以来用户访问量大幅提升。24 年 3 月，阿里通义千问和 Kimi 先后宣布支持 1000 万字和 200 万字上下文，引发国内百度文心一言、360 智脑等厂 商纷纷跟进长上下文能力迭代。全球 LLM 长文本的趋势已经形成。

拆解：当我们使用长上下文时，模型究竟发生了什么？

用户在使用大模型进行长文本推理时，会经历文本预填充、模型响应、用户切换等过程。 以 80G A100 NVLink、50K 上下文（对应 11GB KV cache）、34B 参数（Yi-34B 模型对应 68GB 存储空间）模型为例。其中，每个步骤受限的因素不同，例如 prefill 预填充阶段，决 定预填充速度的主要是 GPU 的 flops 计算能力；模型响应（输出 token）时，输出速度主 要取决于 HBM 的带宽；切换用户的 KV cache 时，由于需要将 HBM 上的 KV cache 卸载， 将 CPU DDR 上的 KV cache 加载，因此速度取决于 PCIE 的带宽。而对于用户并发性，由 于一个用户的 50K 上下文即对应了 11GB 的 HBM 存储（图表 15，100K 上下文所需存储 除以二即得到），加上 Yi-34B 模型参数对应的 68GB 存储，80GB A100 的 HBM 所剩无几， 无法再支持第二个用户。

针对以上过程，首先作出 2 点解释： 1）KV cache 占用多少如何计算。假设模型的超参数如下：Transformer 层数（layer）为 60，多头注意力机制头数（head）为 8 头，Transformer 的隐藏维度（dim，隐藏层向量的 长度）为 128，硬件中采用 bf16 浮点数表示（bf16 比 fp16 更适合加速训练和推理过程）。 选取常见的长上下文窗口 100K，可以计算出 100K 长下文对应的 KV cache 容量是 22.8GB， 50K 上下文对应 KV cache 为 11.4GB，均远高于 4K 上下文对应的 0.91GB。

2）受限于计算能力还是受限于存储带宽，主要由算数强度变量决定。算数强度（arithmetic intensity）定义为每次存储器访问操作（IO）需要执行多少次浮点操作（FLOP），即 arithmetic intensity=FLOP/IO。一般来说，并行性水平越高，FLOP 越高，算数强度越大，该运算越 受限于 GPU 的计算能力。以 A100 为例，其临界算数强度为 156，即当模型一次处理的 token 数（batch 大小）大于 156 时（如预填充阶段一次要处理 50K 上下文），则主要受限于计算 能力，小于 156 时（如推理解码时每次仅输出 1 个 token），则主要受限于 HBM 存储带宽。

我们逐个分析大模型推理长文本过程中涉及的计算细节及消耗的时间。以 80G A100 NVLink、50K 上下文（对应 11GB KV cache）、Yi-34B 模型（对应 68GB HBM）为例。

1）预填充阶段（Prefill），近似耗时 20s

预填充阶段的长文本输入主要受限于 GPU 计算能力。预填充理论上需要的时间为需要的总 FLOP/A100 每秒能提供的 FLOP。对于 50K 上下文，A100 理论上需要 14.1s 来完成预填 充，假设 A100 上能够实现 70%的峰值，得到时间近似为 20s。而如果上下文长度仅为 4K， 同样的方法可得到理论耗时仅 0.89s，可见长上下文带来的预填充延时是较高的。

2）解码阶段（Decoding），近似耗时 12s

解码阶段的长文本主要受限于存储带宽。解码每个 token 理论上需要的时间为内存访问的 字节数/A100 HBM 能提供的带宽，而内存访问的字节数包括模型权重+KV cache。我们假 设模型输出一屏的 token 数为 250，同样对于 50K 上下文长度，理论上计算解码出 250 tokens 需要的时间为 9.8s，再次考虑到实现效率，将时间放宽为 12s。如果上下文长度为 4K，则理论延时为 8.5s。

3）并发用户数随着文本变长而减少

并发用户数的多少主要受限于 HBM 的大小。HBM 一方面要存储模型的权重，这个对于固 定的模型来说也是固定的，例如 Yi-34B 模型大致对应 68GB 的 HBM 存储空间，不随用户 的多少而改变。那么每个用户的长上下文对应的 KV cache，只能存在剩余的 HBM 空间中。 例如 80GB 的 A100，其中 68GB 来存储模型权重，如果用户使用的上下文为 4K（对应 KV cache 0.91GB），则 80G A100 剩余的空间能支持 10+用户的并行。而当每个用户上下文扩 展到 50K 时，对应的 KV cache 为 11GB，仅支持一个用户，并发数量大大降低。

4）上下文切换阶段，近似耗时 2s

由于 80G H100 仅支持 50K 上下文的单个用户，因此在第一个用户闲置时，需要将其 KV cache 从 HBM 转移到 CPU DDR 中，并把下一个用户的 KV cache 上载到 HBM 中。CPU DDR 和 HBM 之间主要靠 PCIE 连接，因此 PCIE 带宽决定了 KV cache 的卸载和上载（即 上下文切换）时间。第四代 PCIE 带宽约每秒 20GB，因此计算出两个 50K 上下文用户的上 下文切换时间约 1.1s，考虑到实际的工程效率，将其放宽到 2s。如果 50K 上下文用户有 20 个，则对应的上下文切换时间约 22~40s。

压缩 KV cache 是优化以上模型推理 4 个过程的关键因素。通过以上 4 个主要过程的计算 方法分析，可以预计出不同上下文长度下，对应的并发性、预填充耗时、解码耗时、上下 文切换耗时。1）并发性随着文本长度增加而减少（图表 19）；2）预填充耗时随着上下文 长度增加呈平方增加（图表 17）；3）解码耗时和上下文切换耗时随着上下文长度增加而线 性增加。其中，KV cache 直接影响了并发性、解码耗时和上下文切换耗时（图表 20），而 预填充也是为了产生 KV cache，因此，优化 KV cache 是优化模型推理成本和效率的重要 因素，而优化 KV cache 最直接就是想办法将其进行有效甚至无损的压缩。

从幻方和微软进展看 KV cache 压缩的典型算法

为了实现对 KV cache 的压缩，可以从 Transformer 层、头、token 和隐藏层入手。1）层 （layer）：即在预填充过程中，有目的的跳过其中的一些层，来减少预填充失败的可能性和 KV cache 的大小，相关研究包括 CALM、CoLT5、LayerSkip、YOCO（微软）等。2）头 （head）：Transformer 的某些头专门用于检索和提升长文本能力，因此可以重点保留这些 “头”，而删去其他“头”，从而减少 KV cache，相关研究包括 GQA、MLA（幻方 DeepSeek V2）等。3）Token：如果可以通过上下文推断出一个 token 的信息，那这个 token 就可以 被删除或合并，从而减少 KV cache，相关研究包括 FastGen、SnapKV、TriForce 等。4） 隐藏层（hidden）：除了通过 KIVI 和 WKVQuant 等量化方法外，隐藏层优化的空间不大， 因为目前隐藏层已经做到 128 了，不太好继续压缩。 我们将近期受关注的两种方法进行详解，来看看如何通过 head和 layer优化，压缩KV cache， 降低推理成本，实现长上下文。

幻方 DeepSeek V2：优化注意力机制来大幅压缩 KV cache

DeepSeek V2引入MLA多头隐注意力机制，大幅降低了 KV cache的大小。幻方DeepSeek V2 是引发本轮国产厂商模型 API“价格战”的导火线，因此很有必要看清其实现方法。 DeepSeek V2 创新主要在两个方面，1）采用改进的 DeepSeekMoE 混合专家架构，通过 细粒度的专家分割（即更多的专家数，实现专业化和准确的知识获取）和共享专家隔离（减 少路由专家的知识冗余）等优化，实现了比传统 MoE 架构更低的训练成本。MoE 和压缩 KV cache 关系不大，不是此处讨论重点。2）引入 MLA 多头隐注意力机制，使用低秩 （low-rank）KV 联合压缩方法，大大减少了推理过程中的 KV cache，降低了推理成本。

MLA 能够大幅压缩 KV cache，核心在于通过压缩的隐向量来表示 KV。对于传统的 Transformer 架构来说，注意力机制采用的是多头注意力（MHA），此时对每一个输入的 token， 都能计算出相应的 Q（query）、K（key）、V（value），而每个 KV 都需要缓存下来用作后 续注意力计算，导致 KV cache 随着文本序列的变长而线性增加。为了减少需要缓存的 KV cache，分组查询注意力（GQA）和多查询注意力（MQA）开始使用，此时 Q 和 KV 不是 一一对应的关系，而是多个 Q 对应一组 KV，相当于 KV cache 被成倍压缩。而 DeepSeek V2 使用了低秩联合压缩思维，对注意力矩阵进行低秩近似，通过将原始注意力矩阵分解为 几个低秩矩阵的乘积，减少计算量。具体说，引入了压缩隐向量 ct，来表示 K 和 V，这样 推理时不需要缓存 KV，只需要缓存 ct 即可，且 ct的维数相比 KV 维数更小，大大压缩了缓 存的用量。

从实验结果上看，MLA 压缩后实现的模型性能优于传统的 MHA。虽然 GQA 和 MQA 也对 传统的 MHA 进行了压缩，但是这两种方法往往使得模型性能受损，表现不如 MHA。而从 实验结果上看，MLA 是优于 MHA 的：1）MLA 所需的 KV cache 相比其他几种注意力机制 更少；2）与 MHA 相比，MLA 在困难测评集上表现更好，且 MLA 的 KV cache 仅为 MHA 的 14%（Small MoE）和 4%（Large MoE）（图表 26）。2）DeepSeek V2 以 21B 的激活 参数（共 236B 参数，每个 token 激活 8 个专家），达到了与开源 Llama 3 70B 可比的水平， 在近似大小开源模型中表现优异。最终，DeepSeek V2 相比其前一代模型 DeepSeek 67B （稠密架构），性能更强，训练成本节省 42.5%，KV cache 降低了 93.3%。

微软 YOCO：通过全局缓存方式来大幅压缩 KV cache

微软 YOCO 通过全局 KV cache 大大降低了所需的缓存空间。微软提出了 YOCO（you only cache once），基于 Decoder-Decoder 堆叠的形式，其中底层的 Decoder 为 Self-Decoder， 利用高效的注意力机制，产生全局的 KV cache；顶层的 Decoder 为 Cross-Decoder，不再 产生 KV cache，而是直接使用底层 Self-Decoder 产生的全局 KV cache 来进行后续的交叉 注意力（cross attention）计算，相当于跳过一些 Transformer 层（layer）不计算 KV cache。 整个模型对外表现和一个单独的 Decoder 相似，符合目前主流大模型的 Transformer Decoder-only 趋势，所需的 HBM 存储大大降低，且预填充（prefill）阶段可以在不进入 Cross-Decoder 的情况下提前结束，减少了预填充的用户等待时间。与 Transformer 相比， YOCO 在不同的模型规模和训练 token 数的情况下都具有较好的性能。

为什么说 YOCO 只需要“cache only once”？“cache only once”主要针对的是 Self-Decoder 部分，这部分会采用高效自注意力机制（图表 29 中 Efficient Self-Attention）， 例如常见的滑窗注意力。这样当用户输入长上下文 N 时，需要缓存的数量为 O(N+CL)，其 中 C 代表滑窗的宽度（也就是只在 C 长度范围内计算注意力），L 为解码器层数。当上下文 N 特别长时，CL 相比于 N 可以忽略，因此复杂度变为 O(N)，即近似于解码器部分只需要 将长上下文 N 缓存一次。而传统的 Transformer 每一层都要缓存 KV，故相对应的缓存数量 为 O(LN)。即 YOCO 的 KV cache 消耗大约仅为普通 Transformer 的 1/L。

YOCO 也能大幅降低预填充时间。降低预填充时间的逻辑主要有：1）由于顶层的 Cross-Decoder 使用的是底层 Self-Decoder 的 KV cache，因此不需要将长上下文预填充到 Cross-Decoder 中，这就节约了至少一半的预填充时间。2）Self-Decoder 采用了高效自注 意力机制（图表 29 中 Efficient Self-Attention），本身预填充就较快。结果上看，对于 512 K 上下文长度，可以将预填充延迟从 180 秒（具有优化推理的 Transformer，例如 Flash 解码 和内核融合）减少到 6 秒以下；即使对于较短的 32 K 长度，YOCO 在预填充时间方面也有 约 3x 提升。

YOCO-3B 在可比大小 Transformer 模型中，取得了相当测评结果。基于 YOCO 架构训练 的参数量为 3B 的模型 YOCO-3B，与 OpenLLaMA-3B-v2、StableLM-base-alpha-3B-v2、 StableLM-3B-41T 等近似大小的模型进行对比，使用 LM Eval SYS 来评估各种下游任务的 zero-shot 零样本性能。YOCO 实现了与经过优化的 Transformer 语言模型相当的结果。

KV cache 压缩技术可复制，模型边际调用成本或接近 0

KV cache 压缩技术直击大模型成本痛点，且可复制性强，有望继续拉低全行业 API 成本。 例如幻方 DeepSeek V2，主要改进点就是 MLA 注意力机制模块，而目前绝大部分大模型 都是基于 Transformer 和注意力机制，理论上 MLA 可以很方便的进行复用。因此，1）对 于基础模型提供商：复用类似技术后，有望进一步降低 API 调用成本，边际成本或接近 0， API 调用付费的商业模式或许不再适合，需要寻求新的商业模式。2）对于 ISV：利好独立 开发者，相当于上游“原材料”成本接近 0，更能繁荣开发生态，更易实现产品 ROI 回正。 3）对于 B 端客户：虽然目前的模型降价策略，还没有太多影响到 B 端客户大规模并行调 用模型的成本，但是随着模型调用边际成本或接近 0，企业的 AI 使用意愿同样变强，更多 的调用意味着头部基础模型厂商能够更好地迭代模型，形成正向循环。4）对于算力：虽然 目前难以定量衡量，但是伴随调用量的增多，我们预计未来整体对算力的需求仍会增加。

AI Agent 或是提高应用表现的下一个关键

AI Agent 能够在大模型本身能力的基础上，使用外部工具和存储，进一步提高应用性能。 OpenAI 安全系统负责人 Lilian 将 Agent 定义为 LLM、记忆（Memory）、任务规划（Planning Skills）以及工具使用（Tool Use）的集合，其中 LLM 是核心大脑，Memory、Planning Skills 以及 Tool Use 等则是 Agents 系统实现的三个关键组件。斯坦福大学教授、Amazon 董事会 成员吴恩达在红杉美国 AI Ascent 2024 提出，如果用户围绕 GPT-3.5 使用一个 Agent 工作 流程，其实际表现甚至好于 GPT-4。我们认为，AI Agent 有望在已有模型能力的基础上， 扩展模型能力边界，增强基于模型的应用表现，成为大模型发展的下一个关键方向。

编辑：火腿肠