推理优化

大模型推理的KV Cache优化全解 KV Cache是大模型推理中最重要的优化技术，也是最大的内存瓶颈。理解KV Cache的工作原理和优化方法，是构建高效推理服务的基础。 KV Cache是什么 在Transformer的自回归生成中，每生成一个新token，需要计算它对所有之前token的注意力。如果不缓存之前的Key和Value矩阵，每个新token都需要重新计算所有之前token的K和V，计算量随序列长度二次增长。 KV Cache通过缓存之前计算过的K和V矩阵，将每步的计算复杂度从O(n²)降到O(n)。代价是内存占用线性增长——对于Llama-70B模型，生成4K token的KV Cache约占40GB显存。 内存瓶颈 KV Cache的内存占用可以用以下公式计算： KV Cache Size = 2 * num_layers * num_heads * head_dim * seq_len * batch_size * dtype_size 以Llama-70B（80层, 64头, 128维, FP16）为例，单序列4096 token的KV Cache约40GB。这意味着一个80GB显存的A100只能服务两个并发请求——这是制约推理吞吐量的最大瓶颈。 PagedAttention：分页管理 vLLM团队提出的PagedAttention是KV Cache管理的革命性创新。灵感来自操作系统的虚拟内存分页机制。 传统分配的问题 传统方法为每个序列预分配一块连续的KV Cache空间，按最大序列长度分配。这导致严重的内存碎片——大多数序列不会用满预分配的空间，但多余的空间不能被其他序列使用。内存利用率通常只有20-40%。 分页方案 PagedAttention将KV Cache划分为固定大小的"页"（通常16个token），每个序列通过页表映射到物理页。页按需分配——序列增长时才分配新页。 效果是显著的：vLLM的内存利用率提升到90%以上，并发吞吐量提升2-4倍。碎片问题被彻底解决，因为不同序列的页可以散布在物理内存中的任意位置。 页的大小选择 页太小（如1 token）会增加页表开销，页太大（如256 token）则回到预分配的问题。16 token是在大多数场景下的最优选择——页表开销不到1%，内存浪费也不显著。 量化缓存 KV Cache的精度对推理质量的影响比模型权重更小——因为KV Cache是中间激活值，其分布更集中，量化误差更容易被后续计算"洗掉"。 FP8 KV Cache 将KV Cache从FP16量化到FP8，内存减半，几乎无损。现代GPU（H100及以后）原生支持FP8运算，所以推理速度也几乎不受影响。这可能是最简单且性价比最高的KV Cache优化。 INT4 KV Cache 更激进的方案是将KV Cache量化到INT4。内存减少到1/4，但精度损失开始显著——在长序列和需要精确注意力的任务上，INT4 KV Cache可能导致输出质量下降。 ...

推理成本：AI落地的最大障碍 一个简单的事实：运行一个70B参数的模型，单张A100 GPU的每小时成本约2-3美元（云服务），每秒处理约50个Token。如果日均100万次请求、每次平均500 Token，一天的GPU成本就超过500美元。 随着用户规模增长，推理成本会线性甚至超线性增长。不做好成本优化，AI项目的商业模式根本不成立。 五层优化框架 我们将推理成本优化分为五个层次，从收益最大到收益递减： 第一层：模型选择优化 选择最小的够用模型。 这听起来简单，但实践中很多团队默认使用最大的模型"以防万一"。 我们的建议是建立模型路由系统： 简单FAQ → 7B模型 一般对话 → 32B模型 复杂推理 → 70B+模型 通过一个轻量级分类器判断请求复杂度，自动路由到合适的模型。在我们的实践中，模型路由可以降低60%以上的推理成本，而用户体验几乎不受影响。 开源vs闭源混合策略。 对于流量大的简单任务用开源模型自建部署，对于低频复杂任务调用闭源API。两者结合可以在成本和质量间取得最优平衡。 第二层：模型压缩优化 量化：INT4量化可以将模型大小和推理成本降低4倍，质量损失控制在2-3%以内（详见我们之前的量化对比文章）。 蒸馏：用大模型蒸馏出一个小模型用于线上推理。对于垂直领域，蒸馏模型可以达到接近大模型的效果但成本只有1/10。 稀疏化：通过剪枝去除不重要的权重。MoE架构本质上就是一种结构化的稀疏化——每次推理只激活部分专家网络。 第三层：推理引擎优化 KV Cache优化：KV Cache是自回归生成的最大显存消耗者。优化手段包括： PagedAttention（vLLM）：将KV Cache分页管理，减少碎片浪费 KV Cache量化：将KV Cache从FP16压缩到INT8，显存减半 KV Cache共享：相同Prefix的请求共享KV Cache 批处理：将多个请求合并处理可以提高GPU利用率。vLLM的Continuous Batching技术可以在不增加延迟的情况下将吞吐量提升3-5倍。 投机解码（Speculative Decoding）：用一个小模型先生成候选Token，大模型并行验证。如果小模型的猜测正确率高，生成速度可以提升2-3倍。 第四层：系统架构优化 缓存层：对相同或相似查询的结果进行缓存。我们采用语义缓存——不只是精确匹配，而是通过嵌入相似度判断是否可以用缓存结果。语义缓存可以命中15-30%的请求。 请求合并：当多个用户问类似的问题时，合并为一个请求，结果分发。这在客服场景特别有效。 异步处理：非实时任务（如批量文档处理）放入队列，在低峰期处理。削峰填谷可以显著降低峰值GPU需求。 自动伸缩：基于请求队列长度和GPU利用率自动伸缩推理节点。配合预加载模型镜像，可以在5分钟内完成新节点启动。 第五层：Prompt优化 Prompt精简：去掉不必要的System Prompt内容，精简指令描述。每个Token都要花钱，冗长的Prompt直接增加成本。 Few-shot优化：与其在Prompt中放5个示例，不如用1个最好的示例加更清晰的指令。Few-shot示例的质量比数量更重要。 输出长度控制：在Prompt中明确要求简洁回答。生成500 Token和生成100 Token的成本差5倍。 实际案例 我们为一个客服场景做了全栈优化： 优化措施 成本降低 质量影响 模型从70B降到32B -45% -2%准确率 INT4量化 -60% -1.5%准确率 vLLM + Continuous Batching -30% 无影响 语义缓存 -22% 无影响 Prompt精简 -15% 无影响 投机解码 -35%（速度提升） 无影响 综合 -85% -3.5%准确率 最终成本降低了85%，而质量损失控制在可接受范围内。 ...

推理成本：AI落地的最大障碍 一个简单的事实：运行一个70B参数的模型，单张A100 GPU的每小时成本约2-3美元（云服务），每秒处理约50个Token。如果日均100万次请求、每次平均500 Token，一天的GPU成本就超过500美元。 随着用户规模增长，推理成本会线性甚至超线性增长。不做好成本优化，AI项目的商业模式根本不成立。 五层优化框架 我们将推理成本优化分为五个层次，从收益最大到收益递减： 第一层：模型选择优化 选择最小的够用模型。 这听起来简单，但实践中很多团队默认使用最大的模型"以防万一"。 我们的建议是建立模型路由系统： 简单FAQ → 7B模型 一般对话 → 32B模型 复杂推理 → 70B+模型 通过一个轻量级分类器判断请求复杂度，自动路由到合适的模型。在我们的实践中，模型路由可以降低60%以上的推理成本，而用户体验几乎不受影响。 开源vs闭源混合策略。 对于流量大的简单任务用开源模型自建部署，对于低频复杂任务调用闭源API。两者结合可以在成本和质量间取得最优平衡。 第二层：模型压缩优化 量化：INT4量化可以将模型大小和推理成本降低4倍，质量损失控制在2-3%以内（详见我们之前的量化对比文章）。 蒸馏：用大模型蒸馏出一个小模型用于线上推理。对于垂直领域，蒸馏模型可以达到接近大模型的效果但成本只有1/10。 稀疏化：通过剪枝去除不重要的权重。MoE架构本质上就是一种结构化的稀疏化——每次推理只激活部分专家网络。 第三层：推理引擎优化 KV Cache优化：KV Cache是自回归生成的最大显存消耗者。优化手段包括： PagedAttention（vLLM）：将KV Cache分页管理，减少碎片浪费 KV Cache量化：将KV Cache从FP16压缩到INT8，显存减半 KV Cache共享：相同Prefix的请求共享KV Cache 批处理：将多个请求合并处理可以提高GPU利用率。vLLM的Continuous Batching技术可以在不增加延迟的情况下将吞吐量提升3-5倍。 投机解码（Speculative Decoding）：用一个小模型先生成候选Token，大模型并行验证。如果小模型的猜测正确率高，生成速度可以提升2-3倍。 第四层：系统架构优化 缓存层：对相同或相似查询的结果进行缓存。我们采用语义缓存——不只是精确匹配，而是通过嵌入相似度判断是否可以用缓存结果。语义缓存可以命中15-30%的请求。 请求合并：当多个用户问类似的问题时，合并为一个请求，结果分发。这在客服场景特别有效。 异步处理：非实时任务（如批量文档处理）放入队列，在低峰期处理。削峰填谷可以显著降低峰值GPU需求。 自动伸缩：基于请求队列长度和GPU利用率自动伸缩推理节点。配合预加载模型镜像，可以在5分钟内完成新节点启动。 第五层：Prompt优化 Prompt精简：去掉不必要的System Prompt内容，精简指令描述。每个Token都要花钱，冗长的Prompt直接增加成本。 Few-shot优化：与其在Prompt中放5个示例，不如用1个最好的示例加更清晰的指令。Few-shot示例的质量比数量更重要。 输出长度控制：在Prompt中明确要求简洁回答。生成500 Token和生成100 Token的成本差5倍。 实际案例 我们为一个客服场景做了全栈优化： 优化措施 成本降低 质量影响 模型从70B降到32B -45% -2%准确率 INT4量化 -60% -1.5%准确率 vLLM + Continuous Batching -30% 无影响 语义缓存 -22% 无影响 Prompt精简 -15% 无影响 投机解码 -35%（速度提升） 无影响 综合 -85% -3.5%准确率 最终成本降低了85%，而质量损失控制在可接受范围内。 ...

量化：让大模型跑得起的关键技术 大模型的推理成本是落地的最大障碍之一。一个70B参数的模型在FP16精度下需要约140GB显存，而INT4量化只需要约35GB——直接让单卡部署成为可能。 但量化不是免费的午餐。精度降低必然带来质量损失，问题是损失多少、哪种方案损失最小。我们在统一环境下对三种主流量化方案进行了系统对比。 三种方案简介 GPTQ：基于二阶Hessian信息的后训练量化方法。通过逐层补偿量化误差来保持模型质量。优势是不需要校准数据量太大，劣势是量化过程较慢。 AWQ（Activation-aware Weight Quantization）：通过分析激活值分布来识别"重要"权重，对重要权重保持高精度，非重要权重进行量化。核心洞察是并非所有权重对模型输出的贡献相同。 INT4（含NF4/FP4变体）：将权重压缩到4比特。NF4（NormalFloat 4）由QLoRA提出，针对正态分布的权重进行了优化。FP4则保留了浮点数的指数-尾数结构。 测试设置 硬件：单张A100 80GB 模型：Llama-3-70B、Qwen-2.5-72B、Mistral-Large 基准：FP16未量化版本 评估数据集：MMLU、HumanEval、GSM8K、C-Eval 测试场景：单序列推理和批量推理 核心结果 质量对比 方案 MMLU HumanEval GSM8K C-Eval 平均损失 FP16 82.1 74.4 88.3 85.7 0% AWQ-INT4 80.8 72.1 86.1 84.3 ~2.0% GPTQ-INT4 80.3 71.5 85.7 83.9 ~2.6% NF4 81.2 72.8 86.9 84.6 ~1.6% INT4-naive 76.5 66.2 80.1 79.3 ~7.8% NF4在质量保持上略优于AWQ和GPTQ，但差异在统计意义上并不显著（除naive INT4外）。三种成熟方案的损失都控制在3%以内，对于大多数应用场景完全可接受。 速度对比 方案 单序列(tokens/s) 批量32(tokens/s) 首Token延迟(ms) FP16 45.2 820 120 AWQ-INT4 112.5 2100 65 GPTQ-INT4 98.3 1850 78 NF4 105.7 1950 70 AWQ在推理速度上领先，这得益于其更优化的内核实现（vLLM的AWQ后端经过深度优化）。GPTQ由于需要额外的反量化步骤，速度略慢。 ...

量化：让大模型跑得起的关键技术 大模型的推理成本是落地的最大障碍之一。一个70B参数的模型在FP16精度下需要约140GB显存，而INT4量化只需要约35GB——直接让单卡部署成为可能。 但量化不是免费的午餐。精度降低必然带来质量损失，问题是损失多少、哪种方案损失最小。我们在统一环境下对三种主流量化方案进行了系统对比。 三种方案简介 GPTQ：基于二阶Hessian信息的后训练量化方法。通过逐层补偿量化误差来保持模型质量。优势是不需要校准数据量太大，劣势是量化过程较慢。 AWQ（Activation-aware Weight Quantization）：通过分析激活值分布来识别"重要"权重，对重要权重保持高精度，非重要权重进行量化。核心洞察是并非所有权重对模型输出的贡献相同。 INT4（含NF4/FP4变体）：将权重压缩到4比特。NF4（NormalFloat 4）由QLoRA提出，针对正态分布的权重进行了优化。FP4则保留了浮点数的指数-尾数结构。 测试设置 硬件：单张A100 80GB 模型：Llama-3-70B、Qwen-2.5-72B、Mistral-Large 基准：FP16未量化版本 评估数据集：MMLU、HumanEval、GSM8K、C-Eval 测试场景：单序列推理和批量推理 核心结果 质量对比 方案 MMLU HumanEval GSM8K C-Eval 平均损失 FP16 82.1 74.4 88.3 85.7 0% AWQ-INT4 80.8 72.1 86.1 84.3 ~2.0% GPTQ-INT4 80.3 71.5 85.7 83.9 ~2.6% NF4 81.2 72.8 86.9 84.6 ~1.6% INT4-naive 76.5 66.2 80.1 79.3 ~7.8% NF4在质量保持上略优于AWQ和GPTQ，但差异在统计意义上并不显著（除naive INT4外）。三种成熟方案的损失都控制在3%以内，对于大多数应用场景完全可接受。 速度对比 方案 单序列(tokens/s) 批量32(tokens/s) 首Token延迟(ms) FP16 45.2 820 120 AWQ-INT4 112.5 2100 65 GPTQ-INT4 98.3 1850 78 NF4 105.7 1950 70 AWQ在推理速度上领先，这得益于其更优化的内核实现（vLLM的AWQ后端经过深度优化）。GPTQ由于需要额外的反量化步骤，速度略慢。 ...

LLM负载均衡的特殊性 传统Web服务的负载均衡（轮询、加权轮询）在LLM场景下效果不佳——LLM请求的长度差异巨大（10 token vs 10000 token），处理时间差异可达100倍。简单的轮询会导致某些节点被长请求占满，而短请求也被迫排队。 策略一：最小连接数 class LeastConnectionsBalancer: def __init__(self, backends): self.backends = {b: 0 for b in backends} # backend -> active_connections self.lock = asyncio.Lock() async def get_backend(self): async with self.lock: backend = min(self.backends, key=self.backends.get) self.backends[backend] += 1 return backend async def release(self, backend): async with self.lock: self.backends[backend] -= 1 策略二：基于队列长度 class QueueAwareBalancer: def __init__(self, backends): self.queues = {b: asyncio.Queue() for b in backends} async def route(self, request): # 选择队列最短的节点 backend = min(self.queues, key=lambda b: self.queues[b].qsize()) await self.queues[backend].put(request) return backend 策略三：延迟感知 class LatencyAwareBalancer: def __init__(self, backends): self.backends = backends self.latency_stats = {b: deque(maxlen=100) for b in backends} def record_latency(self, backend, latency): self.latency_stats[backend].append(latency) def get_backend(self): # 选择平均延迟最低的节点 avg_latencies = { b: sum(lats) / len(lats) if lats else 0 for b, lats in self.latency_stats.items() } return min(avg_latencies, key=avg_latencies.get) 策略四：请求长度路由 class LengthAwareRouter: def __init__(self, short_backends, long_backends, threshold=500): self.short_backends = short_backends # 小模型，处理短请求 self.long_backends = long_backends # 大模型，处理长请求 self.threshold = threshold def route(self, request): input_length = len(request["messages"][-1]["content"]) // 4 if input_length > self.threshold: return self.select_least_loaded(self.long_backends) else: return self.select_least_loaded(self.short_backends) 健康检查 class HealthChecker: def __init__(self, backends, check_interval=10): self.backends = {b: {"healthy": True, "last_check": 0} for b in backends} self.check_interval = check_interval async def check_backend(self, backend): try: async with httpx.AsyncClient() as client: resp = await client.get(f"{backend}/health", timeout=5) return resp.status_code == 200 except: return False async def run(self): while True: for backend in self.backends: healthy = await self.check_backend(backend) self.backends[backend]["healthy"] = healthy if not healthy: logger.warning(f"Backend {backend} unhealthy") await asyncio.sleep(self.check_interval) 结语 LLM负载均衡需要考虑请求长度差异、节点异构性和KV Cache状态。最小连接数+延迟感知的组合策略在大多数场景下表现最佳。配合健康检查和自动故障转移，可以构建高可用的LLM推理服务。 加入讨论 这篇文章有姊妹讨论帖在硅基AGI论坛 — 全球首个碳基硅基认知交流平台。 ...

静态批处理的效率问题 在传统LLM推理中，请求被分成固定大小的batch。当batch中某个请求完成后，其占用的GPU资源（显存、计算单元）在整个batch完成前都无法释放——即使该请求已经生成了EOS token。 这在大语言模型服务中造成了严重的资源浪费。用户请求的长度差异巨大——有的只需生成10个token，有的需要生成1000个token。静态批处理强迫"快请求等待慢请求"，GPU计算能力被大量闲置。 连续批处理的核心思想 连续批处理（Continuous Batching，也称动态批处理）的核心创新是：不再等待整个batch完成，而是在每个生成步骤后动态重组batch。 当一个请求完成时，立即用新请求填充其位置，始终保持GPU满载。 与静态批处理对比 静态批处理（batch_size=4，完成时间120ms）: 时刻0: [Req1, Req2, Req3, Req4] → 开始生成 时刻1: Req1完成（用时20ms），但仍在等待其他请求 时刻2: Req2完成（用时50ms），仍在等待 时刻3: Req3完成（用时80ms），仍在等待 时刻4: Req4完成（用时120ms），batch完成 → 实际吞吐：4个请求 / 120ms 连续批处理: 时刻0: [Req1, Req2, Req3, Req4] → 开始生成 时刻1: Req1完成 → 立即加入Req5 → [Req5, Req2, Req3, Req4] 时刻2: Req2完成 → 立即加入Req6 → [Req5, Req6, Req3, Req4] ... → 实际吞吐：~10个请求 / 120ms（约2.5倍提升！） vLLM中的连续批处理实现 请求状态机 每个请求在vLLM中经历以下状态： class RequestState(Enum): WAITING = 0 # 等待被调度 RUNNING = 1 # 正在生成 PREEMPTED = 2 # 被抢占（显存不足） FINISHED = 3 # 完成 class Request: def __init__(self, prompt, max_tokens): self.state = RequestState.WAITING self.prompt = prompt self.output_tokens = [] self.max_tokens = max_tokens self.current_step = 0 调度循环 vLLM的调度器在每一步动态决定哪些请求参与计算： ...

为什么KV Cache如此重要？ 在自回归生成中，每生成一个新token都需要计算它与之前所有token的注意力。如果不缓存，生成第N个token需要重新计算前N-1个token的K和V，复杂度为O(N²)。KV Cache将已计算的K/V存储起来，使每步生成只需O(N)的计算。 但缓存本身带来了巨大的显存压力。以Llama-3-70B为例，FP16精度下单个token的KV Cache占用约320KB。在32K上下文、batch_size=32的场景下，KV Cache总量达到约320GB——远超模型本身的140GB。 KV Cache的显存构成 单个token的KV Cache大小为： cache_per_token = 2 (K和V) × n_layers × n_kv_heads × head_dim × 2 (FP16字节) 以Llama-3-70B为例： n_layers = 80 n_kv_heads = 8 (GQA) head_dim = 128 FP16 = 2字节 cache_per_token = 2 × 80 × 8 × 128 × 2 = 327,680 bytes ≈ 320KB 理解这个公式是所有优化方案的出发点。 PagedAttention：分页式KV管理 vLLM团队提出的PagedAttention借鉴了操作系统的虚拟内存管理。核心思想： 块式管理 将KV Cache分为固定大小的块（Block），每个块存储若干token的KV。块不需要在物理上连续，通过块表（Block Table）映射逻辑位置到物理位置。 class PagedKVCache: def __init__(self, n_blocks, block_size, n_layers, n_kv_heads, head_dim): self.block_size = block_size # 每块的token数 self.n_blocks = n_blocks # 预分配所有块的存储 self.k_blocks = torch.zeros(n_blocks, n_layers, block_size, n_kv_heads, head_dim) self.v_blocks = torch.zeros(n_blocks, n_layers, block_size, n_kv_heads, head_dim) self.free_blocks = list(range(n_blocks)) self.block_tables = {} # seq_id -> [block_indices] def allocate(self, seq_id, n_tokens): n_blocks_needed = (n_tokens + self.block_size - 1) // self.block_size blocks = [] for _ in range(n_blocks_needed): if not self.free_blocks: raise OOMError("No free KV cache blocks") blocks.append(self.free_blocks.pop()) self.block_tables[seq_id] = blocks def append(self, seq_id, token_idx, k, v): block_idx = token_idx // self.block_size offset = token_idx % self.block_size physical_block = self.block_tables[seq_id][block_idx] self.k_blocks[physical_block, :, offset] = k self.v_blocks[physical_block, :, offset] = v 优势 消除碎片：无需为最大可能长度预分配连续空间 灵活共享：不同序列可以共享相同的块（如系统提示词部分） 按需分配：序列增长时动态分配新块 Prefix Sharing 多个请求共享相同的前缀（如系统提示词）时，PagedAttention可以让这些请求共享同一组物理块。这在对话AI场景中可节省30-50%的显存。 ...

引言 KV Cache（键值缓存）是大模型推理中显存占用的最大头。一个512K上下文的推理，KV Cache可能占用数十GB显存。2026年，KV Cache优化技术已经非常成熟，从vLLM的PagedAttention到DeepSeek的MLA，各种创新层出不穷。本文将全面解析KV Cache的优化技术，帮助开发者深入理解并合理选择。 KV Cache基础 为什么需要KV Cache？ Transformer的自注意力机制： Attention(Q, K, V) = softmax(QK^T / √d_k) × V 问题：生成第t个token时，需要K_1, K_2, …, K_{t-1}和V_1, …, V_{t-1}。如果每次都重新计算，复杂度O(n²)。 解决：缓存历史K和V → KV Cache KV Cache的显存占用 对于Llama 4 70B（32层，hidden_size=8192）： 上下文长度 FP16 KV Cache INT8 KV Cache INT4 KV Cache 2K 512MB 256MB 128MB 8K 2GB 1GB 512MB 32K 8GB 4GB 2GB 128K 32GB 16GB 8GB 512K 128GB 64GB 32GB 关键观察：上下文长度每增加4倍，KV Cache增大4倍。 优化技术全景 技术分类 技术路线 核心思路 压缩比 质量损失 注意力优化 减少KV Cache占用 - - ├─ Multi-Query Attention (MQA) 多查询共享KV 1/n_heads 0% ├─ Grouped-Query Attention (GQA) 分组共享KV 1/group_size <0.5% └─ Multi-Head Latent Attention (MLA) 低维潜在表示 8-10× <1% 分页管理 动态内存管理 - - ├─ PagedAttention 分页管理KV Cache 减少碎片 0% └─ RadixAttention 前缀树缓存 复用公共前缀 0% 量化压缩 降低精度 - - ├─ INT8量化 8-bit量化 2× <1% ├─ INT4量化 4-bit量化 4× 2-3% └─ FP8量化 8-bit浮点 2× <0.5% 稀疏化 只保留重要token - - ├─ StreamingLLM 保留初始+近期token 可变 1-3% ├─ H2O 动态淘汰低注意力token 2-4× 2-5% └─ ScissorHands 基于重要性的稀疏化 2-3× 2-4% 注意力优化 1. Multi-Query Attention (MQA) 原理：所有查询头共享同一组KV。 ...

引言 2026年，MoE（Mixture of Experts）架构已经成为大语言模型的主流选择。三大开源旗舰——DeepSeek V4、Qwen3.5和Llama 4——都采用了MoE架构，但实现方式各有不同。本文将深入对比这三者的MoE架构设计，分析其技术差异、性能表现和工程影响。 MoE架构基础 核心原理 MoE的核心思想是用稀疏激活替代稠密计算： 总参数量大：拥有大量"专家"参数 激活参数少：每次推理只使用少量专家 效果：大模型的知识容量 + 小模型的推理速度 MoE关键指标 指标 说明 影响 总参数量 所有专家参数之和 显存需求 激活参数 每次推理使用的参数 计算量/速度 专家数量 路由可选的专家总数 专业化程度 Top-K 每次选择的专家数 计算量/质量 共享专家 所有token都经过的专家 通用能力 负载均衡 各专家使用是否均匀 效率 三大MoE架构详解 DeepSeek V4：MLA + 细粒度MoE 架构参数： 参数 值 总参数量 671B 激活参数 37B 专家数量 256 Top-K 8 共享专家 4 注意力机制 MLA 2.0 上下文 256K 核心创新： 1. MLA 2.0（多头潜在注意力） DeepSeek V4的核心创新是MLA 2.0： 将KV Cache压缩到低维潜在空间 KV Cache大小减少65%（vs标准MHA） 长序列推理速度提升28% 信息损失比V1降低50% MLA 2.0的KV Cache对比： ...