1.3.llm_archs

训练框架

mfu(Model Flops Utilization)模型算力利用率是分布式训练效率的优化目标。

一个模型定义好之后，前向和反向的计算量就是固定（不考虑动态图的话）的，除以每个step的latency就是mfu。以nanoGPT中的代码为例：

def estimate_mfu(self, fwdbwd_per_iter, dt):
    """ estimate model flops utilization (MFU) in units of A100 bfloat16 peak FLOPS """
    # first estimate the number of flops we do per iteration.
    # see PaLM paper Appendix B as ref: https://arxiv.org/abs/2204.02311
    N = self.get_num_params()
    cfg = self.config
    L, H, Q, T = cfg.n_layer, cfg.n_head, cfg.n_embd//cfg.n_head, cfg.block_size
    flops_per_token = 6*N + 12*L*H*Q*T
    flops_per_fwdbwd = flops_per_token * T # 计算量（T是序列长度）
    flops_per_iter = flops_per_fwdbwd * fwdbwd_per_iter # 每个step的flops * 每一次更新梯度要多少个step
    # express our flops throughput as ratio of A100 bfloat16 peak flops
    flops_achieved = flops_per_iter * (1.0/dt) # per second 一轮的计算量/一轮的耗时
    flops_promised = 312e12 # A100 GPU bfloat16 peak flops is 312 TFLOPS
    mfu = flops_achieved / flops_promised
    return mfu

##...
def xxx():
    # timing and logging
    t1 = time.time()
    dt = t1 - t0 ## 一次gradient_accumulation_steps后 更新梯度
    t0 = t1
    if iter_num % log_interval == 0 and master_process:
        # get loss as float. note: this is a CPU-GPU sync point
        # scale up to undo the division above, approximating the true total loss
        # (exact would have been a sum)
        lossf = loss.item() * gradient_accumulation_steps
        if local_iter_num >= 5: # let the training loop settle a bit
            mfu = raw_model.estimate_mfu(batch_size * gradient_accumulation_steps, dt)
            running_mfu = mfu if running_mfu == -1.0 else 0.9*running_mfu + 0.1*mfu
        print(f"iter {iter_num}: loss {lossf:.4f}, time {dt*1000:.2f}ms, mfu {running_mfu*100:.2f}%")
    iter_num += 1
    local_iter_num += 1

一般分布式训练参数量越多->卡数越多->通信占比越高->MFU越低，所以要优化通信效率。

优化设置

batchsize：通常用比较大的batchsize，提高训练稳定性和吞吐量。GPT-3和PaLM在训练时动态增加batshzie，最终达到百万级别，batchsize从3.2w逐渐增加到320w个token。
优化器：
- Adam和：基于一阶梯度优化的低阶矩自适应估计，用于GPT-3等，超参 $\beta_1=0.9, \beta_2=0.95, \epsilon=10^{-8}$ 。
- ：在训练过程中节省显存，用于PaLM、T5等，超参 $\beta_1=0.9, \beta_2=1.0-k^{-0.8}$
学习率：
- 预热（warm-up）：在训练的初始0.1%到0.5%的steps中，用线性预热策略逐渐增加学习率到最大值（ $5 \times 10^{-5}$ 到 $1 \times 10^{-4}$ 之间，GPT-3是 $6 \times 10^{-5}$ ）
- 衰减（decay）：后续steps中余弦衰减，逐渐降低到最大值的约10%，直到收敛
稳定训练：
- 权重衰减和梯度裁剪：权重衰减率设为0.1，梯度裁剪阈值设为1.0
- 梯度检查点：容易出现loss突增，PaLM和OPT从发生突增前的一个ckpt重新开始训练，并跳过可能有问题的数据
- 缩减emb梯度：GLM发现emb的异常梯度通常会导致loss突增，故缩减emb梯度以缓解

混合精度训练

FP16

提出了用16位float（FP16）训练，减少内存使用和通信开销。A100等GPU具有的FP16计算单元是FP32的两倍，故FP16的计算效率能进一步提高。

推理（预测）：所有参数都是fp16，相对fp32，存储变成一半，速度提升1倍。
训练：参数和梯度用fp32存储，但是在计算前会转成fp16，计算后再转回fp32。主要为了防止溢出，loss要乘一个scale，然后在fp16的梯度要除以scale。

以adam优化器为例，对于每1个参数来说，fp16的训练占用20bytes显存，包括（详见：）

fp16的参数：2bytes
fp16的梯度：2bytes
优化器状态（optimizer state）：16bytes
- fp32参数（4bytes）
- fp32梯度（4bytes）(里提到的，用于reduce之类操作时需要的fp32内存，以1.5B的gpt2为例，需要6GB内存，倒推回来，就需要6/1.5byte=4byte)
- fp32 variance【历史梯度平方和】（4bytes）
- fp32 momentum【历史梯度滑动平均】（4bytes）

而在预测时只要存一个fp16的参数(2bytes)就行，所以预测的显存是训练的1/10，对应1.3B参数量的gpt2-xl，训练要占用 $20B\times 1.3\times 10^9=26GB$ ，预测只要2.6GB

BF16

FP16可能导致计算精度的损失从而影响模型性能，BLOOM里用BF16(brain floating point)比FP16分配更多指数位和更少的有效位，在准确性方面更好

bf16的指数位和fp32一样多

可扩展的训练

需要提高训练吞吐量和加载更大模型到显存中

3D并行

如下三种并行（数据并行、流水线并行、张量并行）的组合

数据并行（Data Parallelism）

将模型参数和优化器状态复制到多个GPU上，每个GPU只处理分给它的数据，不同GPU算出的梯度进行聚合得到batch的梯度，再更新所有GPU上的模型。高度可扩展，增加GPU数就能提高训练吞吐。

torch的ddp

from torch.nn.parallel import DistributedDataParallel as DDP

ddp = int(os.environ.get('RANK', -1)) != -1 # is this a ddp run?
if ddp:
    init_process_group(backend=backend)
    ddp_rank = int(os.environ['RANK'])
    ddp_local_rank = int(os.environ['LOCAL_RANK'])
    device = f'cuda:{ddp_local_rank}'
    torch.cuda.set_device(device)
    # this process will do logging, checkpointing etc.
    master_process = ddp_rank == 0
    seed_offset = ddp_rank # each process gets a different seed

# wrap model into DDP container
if ddp:
    model = DDP(model, device_ids=[ddp_local_rank])

可以一起搞的技巧——梯度累积，当显存不够跑较大的batchsize时，训练效果可能会很差，可以先跑多个mini-batch的前向和反向，把梯度累积起来，再更新一次参数，在数学上等价于跑一个较大的batchsize。

# forward backward update, with optional gradient accumulation to simulate larger batch size
# and using the GradScaler if data type is float16
for micro_step in range(gradient_accumulation_steps):
    if ddp:
        # in DDP training we only need to sync gradients at the last micro step.
        # 最后一个micro step才要sync梯度
        model.require_backward_grad_sync = (micro_step == gradient_accumulation_steps - 1)
    with ctx:
        logits, loss = model(X, Y)
    loss.backward() # 只是计算梯度，并不真的更新
optimizer.step()
optimizer.zero_grad(set_to_none=True)

也可以用torch的no_sync()：

ddp = torch.nn.parallel.DistributedDataParallel(model, pg)
with ddp.no_sync():
    for input in inputs:
        ddp(input).backward()  # no synchronization, accumulate grads
ddp(another_input).backward()  # synchronize grads

流水线并行（Pipeline Parallelism）

将LLM的不同层分配到多个GPU上，一般Transformer模型中会将连续的层加载到同一GPU上，以减少在GPU间传输已计算的隐层状态或梯度的成本。简单的实现会导致GPU利用率降低，因为每个GPU要等前一个完成计算，导致不必要的气泡开销，如下方法可以提高流水线效率：

GPipe：
PipeDream：，填充多个数据batch+异步梯度更新？看下paper先。。。

1) GPipe

Gpipe主要思想：

图a：把模型不同layers顺序放在4张卡上，0->3卡流水线前向计算loss，3->0再反向计算gradients
图b：从时间顺序上看，每张卡有3/4时间是空闲的，GPU利用率非常低
图c：配合梯度累积，多个mini-batch可以同时跑在流水线里面，每张卡则有3/(3+4)的时间空闲（Bubble）

流水线并行的问题是中间有Bubble。当卡数 $K$ ，梯度累积次数 $M$ ，则 $Bubble=(K-1)/(K-1+M)$

GPT里用提升效果，输入和输出共享vocab embedding

2) 重计算

即gradient checkpointing，重计算(recomputation)是对于pipeline parallelism非常重要的一个优化，最开始在一文中提到，在flash attention中也用了。

因为要做pipeline+梯度累积，前向过程中的激活值要保存，以留给反向过程使用，保存很多份的激活值对显存造成了很大压力。recomputation(也叫checkpointing)用时间来换空间（反向的时候进行一次激活值的重计算），可以缓解显存问题。

pytorch的。大致逻辑是包了一个autograd.Function，前向时保存一些inputs/rng_state(RNG state是Random Number Generator state的缩写，随机数生成器的状态。在深度学习和其他计算任务中，随机数生成器用于初始化参数、决定正则化技术如dropout的行为，以及在训练过程中选择样本等。RNG状态是指随机数生成器当前的内部状态，它可以用来在需要时重现或恢复特定的随机数序列，确保实验或模型训练的可重复性)，反向时重新计算

深度更深的时候，一般效果更好

cpu offload：层数很深的时候，可能可以把一些计算挪到cpu上去，再搞回gpu

张量并行（Tensor Parallelism）

分解LLM的张量（参数矩阵），例如矩阵乘法 $Y=X A$ ， $A$ 可以按列分成两个子矩阵 $A_1$ 和 $A_2$ ，从而改为 $Y=\left[X A_1, X A_2\right]$ ，将 $A_1$ 和 $A_2$ 放到不同GPU上，然后就可能通过跨GPU通信将两个GPU的结果merge。

Megatron-LM：能扩展到更高维度的张量
Colossal-AI：
- 为更高维度的张量实现了张量并行，、和
- 特别针对序列数据提出序列并行()，详见下一节

参考

原始矩阵乘法是[m,k], [k, n] -> [m, n]，有如下两种矩阵分解的等效：

列并行（column parallelism）：第一个矩阵不变，第二个矩阵竖着劈成两半，即 $B=[B_1, B_2]$
- [m,k], [k, n/2] -> [m, n/2]
- concat([m, n/2], [m, n/2]) -> [m, n]
行并行（row parallelism）：两个矩阵都横着劈成两半，即 $A=\left[\begin{array}{l}A_1 \\A_2\end{array}\right],B=\left[\begin{array}{l}B_1 \\B_2\end{array}\right]$ 。从2推广到k，其实就是split-k算法，把两个矩阵都分成k个小块，两两相乘后，最后reduce_sum一下。因为每个线程计算的矩阵更小了，开销小，可以通过加大线程数来提升并行效率。
- [m, k/2], [k/2, n] -> [m, n]
- elemwise_add([m, n], [m, n]) -> [m, n]

行并行还可以扩展到推荐里，假设user有k/2维，item也是k/2维，concat在一起，然后过一个k*d的mlp，即[1,k] * [k, d] -->[1,d]，那么可以按行并行的方法，拆成2个[1, k/2]和[k/2,d]相乘，再相加。这样item侧的[k/2,d]可以把全库缓存过来，在线实时算user，排序时把对应item向量抽出来，和user加起来就行

megatron对transformer进行了如下优化：

MLP第一个nn按列分割，第二个nn按行分割，中间省了一次通信
Attention按照head来分割(类似列分割)，后面接的nn按行分割，中间也省了一次通信

图里面的通信算子

$f$ 是前向identity，反向all-reduce
$g$ 是前向all-reduce，反向identity

综合来看，一层transformer layer如下

具体的计算量可以参考：

ZeRO

zero的思想：减少显存，搜广推大部分还是数据并行，所以模型参数是复制多份的，所以zero比较有用

fp16那一节中，optimizer state的显存占用，在前向和反向的时候都不用，只有最后optimizer step的时候才用。

===>zero的思想：把optimizer state分shard存在不同的卡上，只在最后gather时才用。

ZeRO（Zero Redundancy Optimizer）在DeepSpeed库中提出，解决数据并行中的内存冗余问题。数据并行其实并不需要每个GPU都存整个模型、梯度和优化器参数，ZeRO在每个GPU仅保存部分数据，当需要其余数据时从其他GPU检索。3种解决方案：

优化器状态分区：zero1，对显存最大开销的部分进行shard
梯度分区：zero2
参数分区：zero3

前两种方案不会增加通信开销，第三种方案增加约50%通信开销，但能节省和gpu数成比例的内存。

详见官方博客：

import deepspeed
import argparse
parser = argparse.ArgumentParser()
parser.add_argument("--local_rank", type=int, default=0)
deepspeed.add_config_arguments(parser)
args = parser.parse_args()

model, optimizer, _, _ = deepspeed.initialize(args=args,
                                              model=model,
                                              model_parameters=model.parameters())
X, Y = get_batch('train')
logits, loss = model(X, Y)
model.backward(loss)
model.step()

需要指定deepspeed的配置：

{
  "train_batch_size": 64,
  "gradient_accumulation_steps": 1,
  "optimizer": {
    "type": "Adam",
    "params": {
      "lr": 6e-4,
      "weight_decay": 1e-2,
      "betas": [0.9, 0.95]
    }zer
  },
  "scheduler": {
    "type": "WarmupLR",
    "params": {
        "warmup_min_lr": 6e-5,
        "warmup_max_lr": 6e-4,
        "warmup_num_steps": 2000
    }
  },
  "bf16": {
    "enabled": true
  },
  "zero_optimization": {
    "stage": 1
  }
}

启动：

deepspeed --num_gpus=8 train.py --deepspeed_config xx.json

facebook的开源库FSDP(full sharded data parallel)()里基于pytorch实现了类似ZeRO的技术。

from torch.distributed.fsdp import FullyShardedDataParallel as FSDP, ShardingStrategy
model = FSDP(model)  #, sharding_strategy=ShardingStrategy.SHARD_GRAD_OP)

还有一些paper也能降低内存，如

序列并行

序列并行()，可以进一步分解Transformer的注意力操作。

这个也是

对比TP：

SP：

综合对比各种并行

几个缩写：params（p）/gradients(g)/optimizer states(os)/activation(a)

并行方法

显存效率

计算效率

限制

DP（数据并行）

p/g/os都复制在每张卡上，显存效率很低

计算和通信可以overlap，如果都在一个minipod内扩展性很好；梯度累积可以提高计算效率

batchsize不能太大，否则模型效果有损；batchsize/dp不能太小，不然打不满tensorcore

ZeRO（解决DP的显存冗余）

zero1/2/3把os/g/p分别shard到每张卡上，显存效率很高

需要做prefetch来减少通信对计算效率的影响

同DP

PP（流水线并行）

切分p，提高显存效率；a需要存多次，降低显存效率

通信次数最少，只发生在多层之间的切分点，但是有Bubble

每个Stage之间需要负载均衡，对模型结构和卡数有限制

TP（张量并行）

p/g/os/a被shard在每张卡上，显存效率也很高；有些层如layernorm是复制的，可以用sequence parallel优化

梯度不需要同步，提高计算效率；每层插入了4次通信，而且是跟计算有依赖的，会降低计算效率；每层的计算量进行了切分，也会降低计算效率

一般是单机内8卡使用nvlink时用TP

把神经网络看成是输入 $X$ 和权重 $W$ 的矩阵乘法 $XW$ ，那么，DP和PP其实是对 $X$ 的拆分，而TP则是对 $W$ 的拆分

整体对比可以看

一般这么整合：

把机器分成N组，不同组之间用DP
一组机器有M台机器，不同机器之间用PP
一台机器有K张卡，不同卡之间用TP

编译优化

pytorch的TorchDynamo

最简单的用法torch.compile()

flash attention

FlashAttention其实是对 $softmax(QK^T)V$ 的一种加速实现。

一般的实现：需要先用矩阵 $C$ 存 $QK^T$ 的结果，然后对 $C$ 按行做softmax得到新的 $C$ ，再用 $C$ 乘以 $V$ 得到最后结果。

FlashAttention通过一些特殊技巧，不需要算出 $C$ 这个临时变量，通过分块计算，让临时变量总是可以放在cache里，从而

减少Global Memory的大小
加速attenttion的计算，因为读cache比访问Global Memory快多了。

flexattention

训练稳定性

学习率+batchsize的一些经验：

另外，swiglu会让act_norm变大，得加一些方式让模型能训动，一种方法是把weight_decay调小：

loss会变高==>，正则项变大，L+norm中的L相对影响变小了，所以会变大，即为了防止过拟合，但可能eval的时候会更好
act_norm会降低20-30%，因为正则项更重要了，会让权重更接近0

层数加深时的稳定性调优：

数据/训练策略

综述

高质量数据

制造人工合成数据，通过控制数据中知识的数量和类型，来严格调控数据中的知识比特数 (bits)。使用不同大小和架构的 LLM 在人工合成数据上进行训练，并给出数学定理，来精确计算训练好的模型从数据中学到了多少比特的知识。有如下几个发现：

如果训练时间充足，不论使用何种模型架构，模型的存储效率均可以达到2bit/param（即平均每个模型参数可以存储2比特的信息）。而且发现transformer中的知识并非主要存储在MLP层，因为即便移除所有MLP层，模型仍能达到 2bit/param 的存储效率。
如果训练时间不充足，GPT2模型能比LlaMA/Mistral存储超过30%的知识，主要是因为GatedMLP(MoE)会导致训练不稳定，因此对同样的知识，需要更长的训练时间。
压缩/量化的影响：将训练好的模型从float32/16压缩到int8，对知识的存储毫无影响。LLM可以达到“信息论极限”的1/4——因为int8只有8比特，但平均每个参数可以存储2比特的知识。
高质量数据的影响：如果我们的预训练数据中，有1/8来自高质量知识库（如百度百科），7/8来自低质量数据（如common crawl或论坛对话，甚至是完全随机的垃圾数据），会发现：
- 即使对高质量数据的训练时间保持一致，低质量数据的存在本身可能会让模型对高质量知识的存储量下降20倍，即便将高质量数据的训练时间延长 3倍，知识储量仍会降低3倍
- 解法：只需给所有的预训练数据加上自己的网站域名token即可，模型的知识存储量可以立即回升10倍，模型不需要任何先验知识来识别哪些网站上的知识是金子，而可以在预训练过程中，自动发现高质量知识的网站，并自动为这些高质量数据腾出存储空间。

DSIR

大致思路：

输入语料样本 $z_i$

学习语料的特征分布（target data是 $\hat{p}$ ，raw data是 $\hat{q}$ ）
利用语料样本衡量样本间的重要性权重 $w_i=\frac{\hat{p}\left(z_i\right)}{\hat{q}\left(z_i\right)}$
根据权重进行无放回的采样，兼顾多样性和分布一致性

DoReMi

NeurIPS2023的spotlight

使用初始的reference domain weights来训练一个小的reference model $p_{ref}$ ，可以用简单的方式合并，例如用样本量加权
用reference mnodel来指导一个小的proxy model的训练，proxy model使用group DRO（group distributionally robust optimization）来得到domain weights，即让最大的loss gap最小化

\min _\theta \max _{\alpha \in \Delta^k} L(\theta, \alpha):=\sum_{i=1}^k \alpha_i \cdot\left[\frac{1}{\sum_{x \in D_i}|x|} \sum_{x \in D_i} \ell_\theta(x)-\ell_{\mathrm{ref}}(x)\right]

domain weights: $\alpha$
proxy model参数： $\theta$
domain语料： $D$
$\ell_\theta(x)=-\log p_\theta(x)$
使用tune完的domain weights来训练大模型
可以重复这个过程，用新的domain weights重新训练ref_model，迭代下去

dataset decomposition

LLM的训练语料大都是相同长度的sequence，一般是多篇文档concat到一起，然后再切分成等长的sequence，有可能一个sequence里有不同的毫不相关的文档，这样算attention就不太适合了。方法

将数据划分为多个桶，每个桶中的序列长度均为 $2^i$ ，保证每个序列仅来自同一个文档
训练时可以给定一个固定的batch_len，即直接从某个桶里采样，也可以用特定长度策略，从多个桶里采样，组合为特定长度

RHO-1

把语料中的无用token从loss里删了

训练ref_model，挑选少量高质量语料，建模语料的整体loss分布情况
拿ref_model在整个预训练语料上计算每个token的ppl
训练LLM，只关注得分比较高的tokens

infinit lr

linear warmup and cosine decay schedule：

linear warmup阶段：前 $T_{warmup}$ 步线性增加学习率，即直到时间步 $t_{\text {ann }}=T_{\text {warmup }}$ ，学习率设置为 $\eta_t=\eta_{\max } \cdot \frac{t}{T_{\text {warmup }}}$
annealing阶段：对于接下来的 $T_{ann}$ 个时间步，改为cosine annealing方式，即对于时间步 $t_{e n d}=T_{a n n}+t_{a n n}$ ：

\eta_t=\eta_{\min }+\frac{\left(\eta_{\max }-\eta_{\min }\right)}{2} \cdot\left(\cos \left(\pi \cdot \frac{t-t_{a n n}}{t_{\text {end }}-t_{\text {ann }}}\right)+1\right)

infinit lr decay：

linear warmup阶段：同上
cool down阶段：学习率逐渐decay到一个常量 $\eta_{\text {const }}$
常数阶段：学习率保持为这个常数，该阶段结束时的ckpt可以用于新数据集的继续pretrain
annealing阶段：逐渐减小到最小值

\eta_t=\left\{\begin{array}{lll} \eta_{\text {max }} \cdot \frac{t}{T_{\text {warmup }}} & t \in\left[0, t_{c d}\right] & \text { (warm-up) } \\ f_{c d}(t) & t \in\left(t_{c d}, t_{\text {const }}\right] & \text { (cooldown) } \\ \eta_{\text {const }} & t \in\left(t_{\text {const }}, t_{\text {ann }}\right] & \text { (constant) } \\ \eta_{\text {const }} \cdot\left(\frac{\eta_{\min }}{\eta_{\text {const }}}\right)^{\frac{t-t_{\text {ann }}}{t_{\text {end }}-t_{\text {ann }}}} & t \in\left(t_{\text {ann }}, t_{\text {end }}\right] & \text { (annealing) } \end{array}\right.

JEST

现有的大规模预训练数据筛选方法速度慢、成本高，并且没有考虑到批次组成或训练过程中数据相关性的变化，这限制了多模态学习中的效率提升。因此，DeepMind团队研究了联合选择数据批次而非单个样本是否能够加速多模态学习。

挑选好的数据批次比单独挑选数据点更为有效
在线模型近似可用于更高效地过滤数据
可以引导小型高质量数据集以利用更大的非精选数据集

JEST能够在仅使用10%的FLOP预算的情况下超越之前的最先进水平。

硬件的可能影响

大模型训练（如InternLM-7B）实践中，曾经遇到过在A100集群上表现正常的代码和数据，迁移到A800集群却出现了模型准确度下降和梯度范数爆炸的问题。经过调查，我们发现这与A800和A100 GPU的NVLink带宽差异有关。通过在两个集群上使用nanoGPT模型进行的对照实验，我们确认了精度差异的原因在于NCCL的Ring all-reduce算法实现。进一步实验表明，设置环境变量NCCL_ALGO=Tree或使用gloo作为backend可以解决精度对齐问题。最终，我们提出了一个解决方案：在A800集群上设置NCCL_ALGO=Tree，强制使用Tree算法进行all-reduce操作，从而避免了Ring算法带来的精度问题，使得A800集群的模型能够正常收敛，并且与A100集群的训练精度对齐。

fastpersist

pathways

下载了，

这个回答分析得不错

Google的大规模稀疏模型设计

代码：

megatron-lm

deepspeed

ray-llm

Google的几大LLM加速工具

maxdiffusion

JetStream

maxtext

Fire-Flyer AI-HPC

megatron-kwai

DiPaCo

推理框架

KVCache

kvcache的原理：

kvcache的量化：

一些结论：

浅层KV cache相比于深层KV cache，对模型的重要性更大。

量化

和

int8量化：
int4量化：GLM中用了

PPL.LLM

vLLM

As an example, for the 13B parameter OPT model, the KV cache of a single token demands 800 KB of space, calculated as 2 (key and value vectors) x 5120 (hidden state size) x 40 (number of layers) x 2 (bytes per FP16).

对比sglang/trt-llm：，看着和trt-llm差不多，sglang更菜

分布式infer：，Qwen用到了：

使用技巧：

参考看所有特性的兼容性，还有

cudagraph一般来讲会比eager快，所以不要加--enforce-eager
--enable-prefix-caching这个开起来
--enable-chunked-prefill这个也开起来，配合--max-num-batched-tokens一起搞
--max-model-len限制prompt+response的总长度，利于加速，说实话这个是最有效的参数
--max-num-seqs可以设置一下，最好和实际的请求落到这个server实例的qps近似，需要实测
--swap-space其实没啥用，只有一个prompt生成多个response的时候有用，即best_of > 1（参考github issue：），也就是说根本不会用到cpu的kvcache
投机采样说实话比较鸡肋，特别是对于qwen系列模型来讲，因为不同大小的qwen的词表是不一样大的，所以其实用不了，而如果用最简单的ngram，速度又非常慢
请求里的presence_penalty设置一下，不然qwen容易出现死循环输出从而打爆tokens

示例：

import subprocess
import time
import requests
import json
import socket
from concurrent.futures import ThreadPoolExecutor, as_completed

import openai


# 检查端口是否可用
def is_port_open(host, port, timeout=5):
    """
    检查指定端口是否可用
    :param host: 主机地址
    :param port: 端口号
    :param timeout: 超时时间（秒）
    :return: True 如果端口可用，否则 False
    """
    try:
        with socket.create_connection((host, port), timeout=timeout):
            return True
    except (socket.timeout, ConnectionRefusedError):
        return False

# 启动 vLLM 服务
def start_vllm_service():
#        "CUDA_VISIBLE_DEVICES=0 VLLM_WORKER_MULTIPROC_METHOD=spawn \
    port = 12345
    import os
    import tempfile

    # 创建临时目录并设置权限
    temp_dir = tempfile.mkdtemp()
    os.chmod(temp_dir, 0o755)
    
    # 设置环境变量
    env = os.environ.copy()
    env.update({
        "VLLM_WORKER_MULTIPROC_METHOD": "spawn",
        #"CUDA_VISIBLE_DEVICES": "0",
        "TMPDIR": temp_dir,
        "TEMP": temp_dir,
        "TMP": temp_dir
    })
    cur_port = port    
    tp_size = 1
    process = subprocess.Popen(
        ["python3", "-m", "vllm.entrypoints.openai.api_server",
                "--host", "0.0.0.0",
                "--port", str(cur_port),
                "--max-model-len", "2000",
                "--max-num-batched-tokens", "1024",
                "--max-num-seqs", "64",
                "--trust-remote-code",
                "--enable-reasoning",
                "--enable-prefix-caching",
                "--enable-chunked-prefill",
#                "--swap-space", "16",
#                "--speculative_model", "./DeepSeek-R1-Distill-Qwen-7B",
#                "--num_speculative_tokens","5",
#                "--speculative_draft_tensor_parallel_size", "1",
#                "--speculative_model", "[ngram]",
#                "--num_speculative_tokens", "5",
#                "--ngram_prompt_lookup_max", "4",
#                "--enforce-eager",
                "--reasoning-parser", "deepseek_r1",
                "--tensor-parallel-size", str(tp_size),
                "--served-model-name", "deepseek-reasoner",
        "--model", "./DeepSeek-R1-Distill-Qwen-32B-AWQ"
    ],
        #shell=True,
        env=env,
        stdout=open("./out.log", "w"),
        stderr=open("./err.log", "w")
    )
    #--max-num-batched-tokens 65536 
    #    --gpu-memory-utilization 0.97 \
    #    --uvicorn-log-level warning \
    return process

# 发送请求的函数
def send_request(client, model, prompt):
    """
    向 vLLM 服务发送请求
    :param prompt: 用户输入的提示
    :return: 模型生成的响应
    """
    try:
        messages = [{"role": "user", "content": prompt}]
        completion = client.chat.completions.create(
            model=model,
            messages=messages,
            temperature=0.3,
            presence_penalty=1.2,
#            top_p=0.1
            #   max_tokens=8
        )
        print(completion.choices[0])
        content = completion.choices[0].message.content
        reasoning_content = completion.choices[0].message.reasoning_content
        print(content)
        #print("reasoning:")
        #print(reasoning_content)
        return content
    except Exception as e:
        return {"error": str(e)}

# 主函数
def main():
    """
    主函数：启动服务、发送并发请求、处理结果
    """
    # 启动 vLLM 服务
    print("Starting vLLM service...")
    vllm_process = start_vllm_service()

    # 检查端口是否可用
    host = "localhost"
    port =12345 
    print(f"Waiting for service to start on {host}:{port}...")
    while not is_port_open(host, port):
        print("Service not ready yet, waiting...")
        time.sleep(2)  # 每 2 秒检查一次
    print("Service is ready!")

    all_p = []
    with open("./prompts", 'r') as fin:
        for line in fin:
            prompt = line.strip("\n")
            all_p.append(prompt)

    prompts = all_p[:68]

    client = openai.OpenAI(
        base_url=f"http://{host}:{port}/v1", # "http://<Your api-server IP>:port"
        api_key = "sk-no-key-required"
    )

    models = client.models.list()
    model = models.data[0].id

    # 使用 ThreadPoolExecutor 创建线程池并发发送请求
    print("Sending requests concurrently...")
    start = time.time()
    with ThreadPoolExecutor(max_workers=60) as executor:  # 最大线程数为 
        # 提交任务到线程池
        futures = [executor.submit(send_request, client, model, prompt) for prompt in prompts]
        # 获取任务结果
        for future in as_completed(futures):
            try:
                result = future.result()
                print("Response:", result)
            except Exception as e:
                print(f"Request failed: {e}")
    end = time.time()
    cost = end - start
    print(cost)
    # 关闭 vLLM 服务
    print("Stopping vLLM service...")
    vllm_process.terminate()

并行推理方法

medusa

decoder的并行化：

用了tree-attention

CLLM

fasterTransformer/TensorRTLLM

remove padding的逻辑如下，把整个batch的数据变成一行数据，加上offset标注是哪一条样本的

直接有这么个脚本：

关于plugin：

自己加plugins：
已有plugins：

一些参数设置：

--multiple_profiles enables multiple TensorRT optimization profiles in the built engines, it will benefits the performance especially when GEMM plugin is disabled, because more optimization profiles help TensorRT have more chances to select better kernels. However, this feature will increase the engine build time.

trt-llm显存泄露解决

因为用到了kvcache，py的runner的memory管理有问题，改成cpp的runner就行了

huggingface/text-generation-inference

block transformer

MoonCake

MInference(microsoft)

Sarathi-Serve(microsoft)

SGLang(uc berkerley)

LazyLLM

各框架对比

DuoAttention

speculative-decoding

综述

在auto-regressive decoding的过程中先采用更小的draft model猜词，然后送给target model并行验证，以通过在访存限制的情况下充分利用算力，提升模型的推理效率；并且保证decoding的分布与target model一致；

几篇比较早期的

EAGLE系列

prompt-lookup decoding & REST

prompt-lookup decoding：

LayerSkip

DISTILLSPEC

Graph-Structured Speculative Decoding

算子加速

Triton

Mirage

deepseek开源list

FlashMLA

DeepEP

DeepGEMM

DualPipe

EPLB

profile-data

3fs

在3fs上的数据处理框架：

推理系统

中文版：

对应英文版：

优化目标：更大的吞吐，更低的延迟。方案：大规模跨节点专家并行(Expert Parallelism, EP)

EP好处：

增加batchsize，提高gpu矩阵乘法效率，提升吞吐
专家分散在不同GPU，每个GPU只计算少量专家，访存更少，降低延迟

EP的复杂性：

引入了跨节点传输，需要设计合理计算流程使计算和传输可以同步进行
因为多节点，需要DP（数据并行），不同DP间要负载均衡

大规模跨节点专家并行

V3/R1的结构：从第4层开始是MOE，每层有1个共享专家和256个路由专家，每次激活8个路由专家，即8 in 256，稀疏度很高，因此需要用更大的overall batchsize，才能给每个专家提供足够的专家batchsize

Prefill：
- 路由专家EP32
- MLA和共享专家DP32
- 一个部署单元是4节点（32卡），每张卡包括：
  - 9个路由专家（共9*32=288个专家），其中：
    1个冗余专家，共1*32=32个
    8个路由专家，共8*32=256个
  - 1个共享专家，共1*32=32个
Decode：
- 路由专家EP144
- MLA和共享专家DP144，
- 一个部署单元是18节点(18*8=144卡)，每张卡包括：
  - 2个路由专家，共2*144=288
    总共32个冗余专家
    总共288-32=256个正常的路由专家
  - 1个共享专家，共1*144=144个

计算通信重叠

多机多卡的EP会引入较大的通信开销，可以用双batch重叠来掩盖通信开销，提升整体吞吐：

prefill阶段：2个batch的计算和通信交错进行，一个batch计算时可以掩盖另一个batch的通信开销。即attn->dispatch->mlp->shared/combine这4步（这里是shared和combine并行）

decode阶段：不同阶段的执行时间有差别， attention部分拆成了两个stage（图中的attn-0（attn前的一些proj操作等）和attn-1（核心的attn计算等）），共5个stage的流水线（attn0->attn1->dispatch/shared->mlp->combine）来实现计算和通信的重叠（这里是shared和dispatch并行）。

细节可以参考

尽可能地负载均衡

尽可能为每个GPU分配均衡的计算负载+通信负载

prefill load balancer：
- 问题：不同DP实例上的请求数、长度不同，导致core-attention的计算量、dispatch发送量不同
- 目标：
  - 各GPU的计算量尽量相同==>core-attention计算负载均衡
  - 输入的token数量尽量相同==>dispatch发送量负载均衡，避免部分GPU处理时间过长
decode load balancer：
- 问题：不同DP实例上的请求数量、长度不同，导致core-attention计算量（与 KVCache 占用量相关）、dispatch发送量不同
- 目标：
  - 各GPU的KVCache占用量尽量相同==>core-attention计算负载均衡
  - 请求数量尽量相同==>dispatch发送量负载均衡
expert-parallel load balancer：
- 问题：对于给定MoE模型，存在一些天然的高负载专家，导致不同GPU的专家计算负载不均衡
- 目标：每个GPU上的专家计算量均衡==>最小化所有GPU的dispatch接收量(即MOE的输入)的最大值

架构图

prefill和decode拆了2个service，并且每个前面有负载均衡，内部有EP的负载均衡

线上效果

H800，精度和训练一致：

矩阵计算和dispatch传输用fp8
core-attn计算和combine用bf16

白天用所有节点部署服务，晚上减少节点，峰值278节点（每个节点8卡H800，共278 * 8=2224卡，前面提到了prefill要32卡，decode要144卡，其实就是32x+14y=2224），平均占用226.75个节点，每张卡2美金1小时，那就是2 * 226.75 * 8 * 24 = 87072美金/天

输入总token数608B，有342B命中kvcache缓存，命中率56.3%
输出总token数168B，平均输出速度20~22tps(tokens per second)，这里指的应该是单请求的生成速度，平均每输出一个token的KVCache长度是4989。
平均每台H800(8卡)的吞吐量：
- prefill任务：输入吞吐约 73.7k tokens/s（含缓存命中）。
  - 推测：每秒每8卡输入的token数是608000000000 / 226.75/86400=31k，好像对不太上这个73.7k，可能猜测：缓存那部分非常快，非缓存很慢，而这31k是假设全天流量不变的平均值
- decode任务：输出吞吐约 14.8k tokens/s。
  - 推测：每秒每8卡输出的token数是168000000000 / 226.75 /86400=8575，前面提到了每个请求每秒的输出token数是20~22，那就相当于每8卡机器每秒能处理有8575/21=408个请求，所以总的返回qps大概是408 * 226.75=9.25k

上一页1.2.llm_intro 下一页1.4.llm_sft_and_usages

最后更新于3天前

这有帮助吗？