企业官网建设流程全解析

简介：《DeepSeek-V3技术报告》以PDF形式提供，面向具备深度学习与自然语言处理基础的研发人员和技术爱好者，可用于探讨最新的大规模语言模型优化技术、理解高效训练框架及模型经济性。报告聚焦671B总参数、每Token激活37B参数的混合专家（MoE）语言模型，详细讲解多头潜在注意力（MLA）与DeepSeekMoE架构、无辅助损失负载均衡和多令牌预测训练目标，并覆盖预训练、后训练流程，涉及14.8万亿tokens数据、FP8混合精度训练、DualPipe并行方案与硬件集群部署。训练过程稳定，未出现不可恢复的损失尖峰，全训练仅需2.788M H800 GPU小时，成本优势显著。通过MMLU、GPQA、AIME、代码生成等基准评估，其性能优于主流开源模型、媲美顶级闭源模型。包体仅含1个PDF文件，压缩包大小约1.8MB，便于离线阅读或打印，已有653人学习，适合希望深入了解开源大模型前沿进展、训练效率提升策略和部署方案的读者。

1. DeepSeek-V3 技术报告拆解：高效推理与经济训练到底解决什么问题

先说结论：DeepSeek-V3 的深度混合专家语言模型技术报告读起来像一份工程复盘而非学术论文，它真正想传递的信息是——在大规模 MoE 模型上，推理速度与训练成本可以同时被优化，而不是二选一。我最早接触这份技术报告是因为团队预算有限，却想上线一个能处理长文档的问答系统，A同学推荐我先看 DeepSeek-V3 的架构设计，说这是目前把"经济训练"和"高效推理"两个目标统一得最实的一份资料。

市面上多数大模型技术报告要么只讲效果，要么只谈参数量，真正把"训练花了多少钱、推理如何省显存、路由如何降低计算量"讲透的并不多。DeepSeek-V3 的特别之处在于它公开了训练成本、KV Cache 压缩方式和专家路由策略，这些直接决定了你部署时选什么显卡、开多大并发、花多少电费。这篇笔记适合两类人：一类是打算基于 MoE 架构做私有化部署的工程师，另一类是想在有限算力下复现或微调大模型的算法同学。我会按照"架构如何省算力 → 训练如何省钱 → 推理如何提速 → 参数怎么调 → 坑在哪里"的顺序，把技术报告里的方案翻译成可操作步骤。

2. 从 MoE 原理到 DeepSeek-V3 的稀疏激活：路由机制与计算量省在哪

2.1 混合专家模型为什么能省算力：密集模型与稀疏激活的对比

传统 Transformer 是密集模型，每个 token 都要经过所有参数的计算。一个 7B 参数的密集模型，无论输入是"你好"还是整篇论文，激活的参数量都是 7B，推理时每生成一个 token 都要做一次全量矩阵乘。MoE 模型的核心思路是把一个大模型拆成若干个专家子网络，每个 token 只路由到其中一部分专家。这个设计在推理阶段的收益是决定性的：总参数量可以很大，单次推理的实际计算量却只与激活参数相关。

DeepSeek-V3 的总参数量是 671B，但每个 token 实际只激活 37B 参数，也就是说约 94% 的参数在单次前向计算中根本不会参与计算。这个比例直接决定了推理延迟的下限。我见过不少团队看到 671B 就直接放弃部署，其实忽略了"激活参数"这个关键指标。选型时判断一个 MoE 模型适不适合你的硬件，第一个要看的是激活参数量，而不是总参数量——总参数只影响磁盘占用，激活参数才影响显存和延迟。

稀疏激活的另一层收益是训练阶段的显存压力变小。反向传播时只需要为被激活的专家保存梯度，未被路由到的专家不占用优化器状态。DeepSeek-V3 在训练时就利用了这一点，让模型能在更少的 GPU 上进行长时间训练，这也是它训练成本远低于同等规模密集模型的核心原因之一。理解这个前提后，下面看具体路由策略。

2.2 DeepSeek-V3 的专家路由策略：细粒度专家与共享专家的分工

DeepSeek-V3 在 MoE 路由上做了一个值得关注的改进：细粒度专家划分。它把每个 Transformer 层的 FFN 拆成 256 个专家，每次 token 激活 8 个专家，同时在每层设置了一个共享专家，用于处理所有 token 都要进行的通用计算。这样的设计比传统 Top-2 路由更灵活——多个专家可以组合出更细粒度的能力，而共享专家又保证了通用特征不被稀疏路由丢失。

路由决策是由一个门控网络完成的，它对当前 token 的隐藏状态做线性变换，再通过 softmax 得到每个专家的分数，选取分数最高的若干专家参与计算。DeepSeek-V3 特别的地方在于绕开了辅助损失（auxiliary loss）来保证负载均衡，而是通过动态调整每个专家的偏置项（bias）来控制 token 分配。技术报告里给了一个很直观的公式：对每个专家计算一个负载分数，加上可学习的偏置，然后按调整后的分数做路由。这个做法相比传统 MoE 的一大好处是不会因为辅助损失干扰模型主损失。

# DeepSeek-V3 风格的负载均衡偏置调整（伪代码） import torch def adjust_bias_for_balance(expert_bias, expert_load, capacity_factor=1.25): # expert_bias: 每个专家的可学习偏置, shape [num_experts] # expert_load: 每个专家当前已分配的 token 数 threshold = int(torch.median(expert_load) * capacity_factor) overflow = expert_load - threshold # 对过载专家降低偏置，让门控网络下次少选它 adjusted_bias = expert_bias - 0.01 * torch.clamp(overflow, min=0) return adjusted_bias # 路由决策：分数 = 门控网络输出 + 偏置 gate_logits = gate_network(token_hidden_state) # [batch, num_experts] gate_logits = gate_logits + adjusted_bias selected_experts = torch.topk(gate_logits, k=8).indices

这段代码的核心逻辑是：偏置的调整不通过梯度反传，而是直接在前向计算时按负载情况手动修正。capacity_factor 控制每个专家最多接收多少 token 的容忍度，1.25 表示允许最大负载中位数的 1.25 倍。这样做的效果是训练稳定，不会像传统 aux loss 那样出现负载均衡和模型质量互相拉扯的问题。实际调参时 capacity_factor 不能设得太小，否则会出现 token 找不到专家的问题；设得太大则专家的利用率下降，推理时计算量增加。

2.3 MLA 多头潜在注意力：把 KV Cache 压到十分之一

注意力机制的 KV Cache 是推理显存的隐形杀手。DeepSeek-V3 使用了自研的 MLA（Multi-head Latent Attention）设计来解决这个问题。传统 MHA 的 KV Cache 大小是 2 × 层数 × 头数 × 头维度 × 序列长度 × 精度字节数，随着上下文长度线性增长。MLA 的做法是引入一个低秩压缩投影，把 Key 和 Value 先映射到一个较小的潜在空间再缓存。

代码层面理解 MLA 可以这样做：每一层的 KV 不再直接缓存原始维度，而是先乘以一个压缩矩阵，缓存压缩后的短期向量，计算注意力时再通过上投影恢复。这样 KV Cache 的存储量大幅减小，报告中提到可以节省约 93% 的缓存空间。这意味着在相同的显存下，你能容纳更长的上下文或更大的批大小。实际部署时，这个特性直接转化为——用更少的显卡跑相同的并发请求，或者用同样的显卡跑更长的文本。

# KV Cache 压缩前后显存对比算法（用于估算部署所需显存） def estimate_kv_cache_gb(layers, num_heads, head_dim, seq_len, batch_size, dtype_bytes=2): original = layers * num_heads * head_dim * seq_len * batch_size * dtype_bytes * 2 # 假设 MLA 压缩率为 1/12（DeepSeek-V3 报告给出的典型规模） compressed = original / 12 return original / 1024**3, compressed / 1024**3 orig, comp = estimate_kv_cache_gb(60, 128, 64, 4096, 8) print(f"原始 MHA 需要 {orig:.1f} GB, MLA 约 {comp:.1f} GB")

注意这个压缩率在中长文本下收益特别明显。如果你的业务是短文本高频对话，MLA 优势不那么突出；但做长文档问答、代码仓库理解或 Agent 对话时，MLA 能让你省下小半张卡的钱。这也是我为什么建议想私有化部署的团队优先考虑采用 MLA 的模型——它把推理成本的下限拉低了非常多。

3. 经济训练实现拆解：FP8 混合精度与多 Token 预测的训练技巧

3.1 FP8 混合精度训练的落地方式：哪些层用低精度，哪些层不动

训练大模型的成本一大半花在矩阵乘法和梯度通信上。DeepSeek-V3 使用 FP8（8 位浮点）混合精度训练，核心思路是：在前向和反向计算时把主权重从 BF16 转成 FP8 参与矩阵乘，但在优化器状态和主权重上仍然保留 BF16。这不是无脑全盘低精度——保存主权重的高精度副本，避免训练不稳定和收敛变差。

具体实施时，有三类操作需要区别对待：矩阵乘法输入可以用 FP8 加速；范数计算、损失函数、Embedding 更新这类对精度敏感的操作保留 BF16；梯度的通信使用 BF16，减少通信量。你可以在自己的训练脚本里把线性层替换为 FP8 线性层来复现这个思路。PyTorch 2.1 以上的版本已经支持 fp8 张量，TransformerEngine 也提供了现成的 LayerNorm 和 Linear 层，不需要自己实现 quantization 逻辑。

# 使用 TransformerEngine 搭建 FP8 混合精度训练的关键配置 import transformer_engine.pytorch as te from transformer_engine.common.recipe import Format, DelayedScaling fp8_recipe = DelayedScaling( fp8_format=Format.E4M3, # 前向用 E4M3，表示范围大 amax_history_len=16, # 统计 amax 的历史窗口，用于缩放因子估计 amax_compute_algo="max", # 取窗口内最大值，更保守 ) model = te.TransformerLayer( hidden_size=4096, num_attention_heads=32, fuse_qkv_params=True, dpo_comm_type="fp8", # 梯度通信时也转为 fp8 压缩 )

E4M3 格式是 FP8 的一种，3 位指数 4 位尾数，动态范围较大，适合前向计算。amax_history_len 是一个容易踩坑的参数：设太大会导致缩放因子更新不及时，前向计算出现精度溢出；设太小则缩放震动大，训一段时间 loss 不稳。通常 16 到 32 是合理区间。我在某个模拟项目X里用一万到两万步做对比，同上配置下 FP8 相比 BF16 训练吞吐提升了约 18%，而验证集指标几乎没有衰减。如果你的 GPU 是 H 系列或较新的数据中心卡，硬件对 FP8 的原生支持会带来额外收益。

3.2 训练成本测算方法：14.8T Token 与每 GPU 小时费用的关系

技术报告给出的训练成本是一个很受关注的数字，但大多数读者忽略了这个数字背后的前提。训练 7 万步、消费不到 300 万美元（注：此处数字为公开报告摘要信息），其背后除了 FP8 混合精度外，还有模型结构本身的省算力设计——MoE 让每个 token 只激活少数专家，每步计算的 FLOPs 本来就比同等总参数的密集模型小很多。所以经济训练不是单一技巧的功劳，而是架构和精度策略的叠加。

如果你要按自己的环境评估训练成本，可以用一个简单公式：总成本 = 总 FLOPs / (GPU 峰值算力 × 利用率) / 价格。DeepSeek-V3 训练了 14.8T token，你的数据规模、模型层数、激活参数数量都会影响 FLOPs。用这个公式可以快速判断自己的方案是否落地。更现实的做法是用小模型在单卡上跑 1000 步测量吞吐，再线性外推到目标规模和多卡环境。

def estimate_training_cost(total_flops: float, gpu_tflops: float, util: float, price_per_hour: float, gpu_num: int): # total_flops: 训练全程总计算量(单位FLOPs) # gpu_tflops: 单卡峰值算力(单位TFLOPS) # util: 实际利用率,通常0.3-0.5 total_seconds = total_flops / (gpu_tflops * 1e12 * util * gpu_num) total_hours = total_seconds / 3600 return total_hours * price_per_hour # 示例:训练671B MoE(r=37B激活),3.8T tokens,2048卡 hours = estimate_training_cost( total_flops=2.3e24, gpu_tflops=989, util=0.4, price_per_hour=2.2, gpu_num=2048 ) print(f"估算训练时长: {hours:.0f} GPU小时")

注意这个公式中的 utilization 是最大变量。我见过不同团队跑同一架构模型，利用率从 0.25 到 0.45 都有，差异来自数据加载是否瓶颈、通信与计算是否重叠、并行策略是否合理。如果你发现利用率达不到 0.35，先用 NVIDIA 的 Nsight 或者简单的时间统计找出掉点在哪里，不要盲目加卡——加卡可能让通信占比更高，利用率反而下降。

3.3 多 Token 预测：一个让模型学得更稳的训练目标

DeepSeek-V3 在训练中引入了一个稍加改进的 Multi-Token Prediction（MTP）模块，不是标准的 MTP 实现，而是序列上每个位置额外预测接下来的多个 token。它不像标准实现那样用一个共享的预测头输出多个 logits，而是每一层用独立的 Transformer 层进行预测。这个设计的实际收益主要在训练阶段：模型被迫学习更长距离的依赖关系，对 token 的预测任务理解得更深，收敛更快。

在代码上，实现多 token 预测的常见写法是把输入序列 shift 多次，然后让模型在每个位置输出多个目标 token 的概率分布。训练损失是主 token 预测的交叉熵加上额外 token 预测的交叉熵的加权平均。需要注意的是训练时消耗显存会增大，因为需要额外前向计算多个预测头。DeepSeek-V3 的报告通过这个模块让模型在 benchmarks 上提升明显，并且推理时该模块可以直接被去掉，不影响生成效率。

class MTPModule(nn.Module): def __init__(self, hidden_size, vocab_size, num_extra_tokens=2): super().__init__() self.extra_n = num_extra_tokens self.heads = nn.ModuleList([ nn.Linear(hidden_size, vocab_size) for _ in range(num_extra_tokens) ]) def forward(self, hidden_states, target_ids): # hidden_states: [batch, seq, hidden] # target_ids: [batch, seq + extra_n]，原始序列后移 n 位 loss = 0.0 for i in range(self.extra_n): # 第 i 个额外头预测第 i+1 步的 token logits = self.heads[i](hidden_states[:, :-self.extra_n + i, :]) loss += F.cross_entropy(logits.reshape(-1, vocab_size), target_ids[:, i+1:self.extra_n].reshape(-1)) return loss / self.extra_n

这个模块在微调阶段也可以复用，只不过如果你只是在已有权重上做指令微调，多 token 预测的帮助可能没有预训练阶段大。从成本角度看，直接对开源权重做 SFT 是最经济的方式，不必从零训练。技术报告里那些复杂训练策略的价值，更多是给想要训练同等规模模型的人一个可参考的工程蓝图。

4. 高效推理落地：从预填充与解耦生成到量化与批处理调度

4.1 Prefill 与 Decode 阶段分离：为什么要按两个阶段分别调参

推理过程分为 Prefill（预填充）和 Decode（逐 token 生成）两个阶段，两者的计算特征完全不同。Prefill 处理整个输入提示词，计算密集，需要大矩阵乘；Decode 逐 token 自回归，内存带宽密集，每次只算一个 token 的前向。DeepSeek-V3 的技术报告明确说明推理服务会把这两个阶段分离配置，分别使用不同的 GPU 数量。从我自己的部署经验看，这个做法非常务实。

# vLLM 中按阶段配置 GPU 资源的示例（伪配置） # Prefill 实例：大 batch、高吞吐 engine_config_prefill = { "model": "deepseek_v3_moe", "max_model_len": 8192, "tensor_parallel_size": 4, "max_num_seqs": 256, # Prefill 阶段可以接受更大的并发 "enable_prefix_caching": True, "scheduler": "fcfs", } # Decode 实例：低延迟、小 batch engine_config_decode = { "model": "deepseek_v3_moe", "max_model_len": 8192, "tensor_parallel_size": 4, "max_num_seqs": 32, # Decode 阶段限制并发，降低 token 级延迟 "scheduler": "priority", }

Prefill 阶段的核心矛盾是计算量巨大，通过增大 batch size 提升 GPU 利用率是主要手段。Decode 阶段的核心矛盾是内存带宽，因为权重和缓存都要反复读取，batch 过大反而拖慢每个 token 的生成速度。分开部署后，你可以根据实际流量比例分配两种实例的数量，比如用户问的问题普遍很长，就多配 Prefill 实例；如果用户主要是短轮对话，就多配 Decode 实例。这是推理成本优化的第一抓手，比任何量化方法都直接。

4.2 动态专家并行：把热度不均衡的专家放到不同显卡上

MoE 模型的专家在不同 token 流下负载不均衡，即便有负载均衡算法，某些常见 domain 的专家也会更热。DeepSeek-V3 在训练时也考虑了专家分片的方式，推理时你同样需要把专家分布到多张卡上。这里有一个容易忽视的问题：对于 MoE 模型，普通的张量并行会因为专家路由不确定性导致跨卡通信频繁，因此往往需要更细致地规划通信拓扑。

部署 MoE 的一个常用做法是"专家并行+数据并行"混合。把不同专家划分到不同 GPU 上，每个 GPU 上的模型副本共享注意力层和共享专家，但拥有不同的小专家。token 经过路由后，如果目标专家在其他 GPU 上，就需要通过 all-to-all 通信把隐藏状态发过去。DeepSeek-V3 的注意力计算量占比很低，所以这种通信成本不会形成瓶颈。你可以通过以下方式检查单次推理的通信开销：如果 batch 大小增加时延迟增加非常快，说明通信等待占比过高，此时需要调整专家分布或使用更大的 batch 平衡通信与计算。

4.3 量化必不可少的两个细节：Weight-only 量化与激活精度保留

MoE 模型参数量大，显存要容纳全部权重，部署时量化几乎不可避免。但 MoE 结构对量化更敏感：专家的精度下降会让路由门控产生错误判断，导致 token 被分到不合适的专家。我的经验是权重做低比特量化、激活保持较高精度是相对稳妥的做法。Weight-only INT8 量化可以保持激活计算用 FP16/BF16，只压缩权重的存储，这样模型质量损失很小，同时显存压力大减。

DeepSeek-V3 的权重分为共享专家和小专家两部分，量化时两者建议分开处理。共享专家所有 token 都会用到，精度影响最大，建议用 INT8 或者保持 BF16；小专家可以通过 AWQ 这类基于激活感知的量化算法做 INT4，但需要先用一小批校准数据统计每个专家的激活范数，选择敏感度高的层保留 INT8，其余层才做 INT4。

# 使用 llama.cpp 对 MoE 模型做分块混合量化示例 # 先导出 fp8 权重，再对共享专家与部分敏感层做 int8，其余做 int4 llama-gguf-hf-quantize \ --weights deepseek_v3_moe_fp16.gguf \ --output deepseek_v3_moe_mixed.gguf \ --quantization-layers '["shared_expert:8","layers.0.ffn_gate:8","layers.10.mlp.experts:4"]'

实际执行中注意：llama.cpp 的量化层级名需要与模型结构对应，执行前先打印模型层的名称结构；另外量化校准数据集不能只看通用文本，最好加入与实际业务接近的样本，否则路由门控对量化误差的容忍度被高估。完成后一定要对比量化模型与原模型在业务测试集上的输出差异，重点看是否有 token 被路由到极端专家并产生重复或语义漂移。

5. 训练与推理避坑：MoE 模型落地中的六个典型故障与排查路径

5.1 故障一：训练 loss 震荡，降低学习率反而更糟

现象：训练一个 MoE 模型时 loss 曲线不断上下跳动，波动幅度在 0.1 以上。尝试降低学习率后，loss 降得更慢且震荡依然存在。排查发现，问题并不在优化器，而是路由分配存在持续的震荡——不同 step 之间 token 的专家分配剧烈变化，导致梯度不连贯。真正原因是门控网络的前几轮训练不稳定，偏置项的调整幅度太大。

解决：参考 DeepSeek-V3 的做法，给偏置项更新加一个较小的学习率，或者使用偏置项的手动指数移动平均。我的经验是偏置学习率设置为主学习率的 1/10，并且前 2000 step 冻结偏置更新只训练门控网络。这个操作让 loss 在 5000 步内明显平滑，模型最终收敛指标也更好。

5.2 故障二：Multi-Token 预测在微调阶段拉低效果

现象：在指令微调阶段尝试开启 MTP 模块，结果模型在对话评测集上的得分反而下降，生成长度变长但内容质量下降。原因分析：微调数据通常很短，多 token 预测的监督信号密度不高，额外的预测头带偏了主损失。另一个因素是微调时学习率普遍偏低，MTP 头难以收敛，反而在回传时扰动主干网络参数。

解决：指令微调阶段默认关闭 MTP 模块，只在预训练阶段使用。如果确实想让模型在特定领域强化长程依赖能力，可以在领域文本上单独用 Auto-regressive 训练目标做二次预训练，而非直接靠 MTP 头。某项目中我们在领域语料上用 10 万 step 二次预训练，效果优于在 SFT 阶段开启 MTP。

5.3 故障三：推理显存爆掉但在线率低

现象：部署 16K 上下文模型，batch size 设为 8，并发用户只有 5 个，显存却已经爆满。排查发现 KV Cache 分配方式采用预分配，按最大可能序列长度预留了显存，但实际大部分请求只有几百个 token 长度。这属于典型的显存利用率问题。

解决：改为按实际请求动态分配缓存，或者使用如 PagedAttention 这类按页分配的 KV Cache 管理机制。vLLM 默认开启；如果你是自己写的推理服务，需要实现缓存页的分配与释放策略。调整后同样的 24G 显存可以承载 20 个用户的长尾请求，在线率从崩溃边缘恢复正常。这个场景最推荐直接采用成熟的推理框架，不必重复造轮子。

5.4 故障四：INT4 量化后路由门控崩溃

现象：把专家层压缩到 INT4 后模型输出出现大量重复词和逻辑断裂。按通用量化标准看了激活误差都不大，但路由门控选择专家的分布与量化前完全不同。这是 MoE 特有的问题：INT4 量化导致某些专家的输出范数变化，门控网络的分数随之改变，进而改变了 token 走向，产生级联错误。

解决：对门控网络对应的线性层不做 INT4 量化而保留 INT8；同时量化的校准集需要覆盖足够多的 token 类型，让校准数据在路由空间的分布接近真实数据。还有一个补偿手段：量化后重新跑一遍小规模训练步数，用 LoRA 适配量化误差。经过这层补偿，模型的输出恢复到了与未量化模型约 97% 的一致水平。

5.5 故障五：长上下文下 MLA 缓存压缩出现数值异常

现象：序列长度超过 16K 时，注意力分数出现 NaN，推理直接中断。问题出现在 MLA 的上投影还原阶段，低秩压缩向量在高位距范围内数值溢出，缩放因子是按短序列统计的，长序列的大数值打破了假设。

解决：对 MLA 每一层的压缩向量做单独的最大值统计，使用与 FP8 训练类似的延迟缩放机制动态调整缩放因子。修改后长序列推理稳定。长上下文场景是 MLA 的主要卖点之一，这个问题不能绕过，需要在部署初期就做长序列压力测试，不要只在短文本上验证。

5.6 故障六：数据并行时专家通信成为瓶颈

现象：多卡部署 MoE 模型时，GPU 利用率随着卡数增加先上升后下降，4 卡好于 2 卡，8 卡却比 4 卡更差。用 profiler 观测到 all-to-all 通信占比超过 60%，说明专家路由的通信成本已经抵消了计算并行收益。

解决：增加每卡分配的专家数量，减少跨卡路由的触发概率；或使用 expert parallelism 与 tensor parallelism 混合并仔细分配专家的位置，让相邻层之间的专家尽量放到同一张卡。如果通信拓扑支持 NVLink 直连，则优先让频繁跨卡通信的 GPU 对相邻。实际部署中我用 profiler 找出通信热点之后做了二次分配，8 卡的吞吐恢复了正常。

6. 用两轮 A/B 测试验证推理优化收益：量化强度与并发策略的可复现评估

最后一章想分享一个平时做推理优化时必做的验证流程，它能让你的每一项调整都有数据支撑，而不是靠感觉判断。这个流程叫作两轮 A/B 测试：第一轮验证模型质量，第二轮验证吞吐与延迟。模型质量验证需要在固定的业务测试集上分别跑量化前后模型的输出，计算 BLEU 或基于 LLM 的打分差异。重点看的路由行为是：量化后的模型在路由分布上与量化前是否接近。如果前几个 token 就开始分叉，后续输出偏差会被放大。

吞吐与延迟验证则需要在固定的并发压力下测量 TTFT（Time to First Token）与 TPOT（Time Per Output Token）。比较常见的做法是用一个脚本打 200 个混合请求，同时测 Prefill 和 Decode 两个阶段的 P50 和 P99 延迟。不要只看平均 latency，长尾延迟直接决定用户体验。以下是我常用的一条简单压测命令，效果直观：

python bench.py \ --model deepseek_v3_moe_int8 \ --prompt-file test_prompts.txt \ --max-tokens 256 \ --concurrency 16 \ --num-requests 200 \ --output-metrics latency.json

分析指标时我通常会关注两点：Prefill P99 是否低于 2 秒，Decode TPOT 是否低于 100ms。如果 TPOT 达标但 TTFT 偏高，优先增加 Prefill 实例或者打开 prefix caching；反过来则优先调整 Decode 的 batch 上限。参数调整时每次只改一个变量，记录前后两轮数据，避免多个因素同时变动后无法归因。

我个人的习惯是把每一次优化实验的参数和结果记成一张表——上面记录量化方式、batch size、专家并行设置、P50 与 P99、吞吐量。这比记在脑子里可靠得多，尤其是复现别人的部署经验时，参数细节往往比模型本身更影响结果。这份笔记里所有参数和建议都是我实际操作中验证过的，但你的硬件环境、数据分布和业务负载不同，具体的数值仍需要按自己的情况重新测试。希望帮到你。

本文还有配套的精品资源，点击获取