静态 batching 要求所有请求长度相同、batch 大小固定。动态 batching 把多个不同长度的请求拼成一个 batchNPU 并行处理。在昇腾NPU上动态 batching 是提升吞吐的关键——batch1 的 GEMM 利用率只有 7%batch32 能到 65%。动态 Batching 的原理时刻 T1收到请求 Aprompt_len128 时刻 T2收到请求 Bprompt_len256 时刻 T3收到请求 Cprompt_len64 静态 batching等 batch 满 32 个才处理A 等了 200ms 动态 batching每 50ms 把当前所有 pending 请求拼成一个 batch 处理动态 batching 的权衡等待时间 vs batch 大小。等待越久batch 越大NPU 利用率越高但首 token 延迟越高。ATB 的动态 BatchingATB 的 LLM 接口内置动态 batchingfromatbimportLLM,DynamicBatchingConfig modelLLM(meta-llama/Llama-2-7b-hf,devicenpu:0,dynamic_batchingDynamicBatchingConfig(max_wait_ms50,# 最多等 50ms 凑 batchmax_batch_size32,# 最大 batch 大小max_seq_len4096,# 最大序列长度))# 并发发送多个请求ATB 自动做动态 batchingimportconcurrent.futureswithconcurrent.futures.ThreadPoolExecutor(max_workers32)asexecutor:futures[executor.submit(model.generate,prompt)forpromptinprompts]results[f.result()forfinfutures]Padding 策略不同长度的请求拼成 batch 需要 Padding 到相同长度。两种策略策略 1Padding 到最大长度# 请求 A: 128 tokens → padding 到 256# 请求 B: 256 tokens → 不用 padding# Batch 大小: [256, 256]缺点短请求浪费计算Padding token 也过了 Attention策略 2分桶Bucket# 预设几个桶128, 256, 512, 1024, 4096# 请求 A (128) → 放入 128 桶# 请求 B (256) → 放入 256 桶# 不同桶的请求不混批优点减少 Padding 浪费 缺点桶内请求少时 batch 大小受限ATB 默认用分桶策略。max_batch_size是每个桶的最大 batch 大小。动态 Batching 的吞吐提升Llama2-7BAtlas 800I A232 并发请求Batching 策略吞吐 (tokens/s)首 token 延迟 (ms)静态 batch115035静态 batch898035等 batch 满动态 batching (max_wait10ms)2,10045动态 batching (max_wait50ms)2,80085动态 batching (max_wait200ms)3,200235max_wait_ms是核心参数小 → 延迟低但吞吐低大 → 延迟高但吞吐高。在线服务一般取 50-100ms。离线批量推理可以取 500-1000ms不关心延迟只要吞吐。跟 KV Cache 的配合动态 batching 要求 KV Cache 能容纳不同 batch 大小的请求。Paged KV Cache 正好解决这个问题——不需要预分配固定 batch 大小的 KV Cache。modelLLM(meta-llama/Llama-2-7b-hf,devicenpu:0,kv_cache_dtypefp16,paged_kv_cacheTrue,# 必须开启dynamic_batchingDynamicBatchingConfig(max_wait_ms50),)如果不开启 Paged KV Cache动态 batching 的 KV Cache 显存浪费 30-50%因为要按最大 batch 预分配。实际部署配置在线对话服务QPS50延迟敏感configDynamicBatchingConfig(max_wait_ms50,# 平衡延迟和吞吐max_batch_size16,# 在线服务 batch 不用太大max_seq_len4096,)离线批量推理不关心延迟configDynamicBatchingConfig(max_wait_ms2000,# 等 2 秒凑大 batchmax_batch_size64,# 离线可以开大 batchmax_seq_len8192,)动态 batching 是昇腾NPU推理服务的标配——把 batch 从 1 提到 16-32吞吐提升 10-20×。关键参数max_wait_ms根据业务延迟要求调整。仓库在这里https://atomgit.com/cann/ATB
CANN-昇腾NPU-动态batching-怎么把多个请求合并成一个batch
静态 batching 要求所有请求长度相同、batch 大小固定。动态 batching 把多个不同长度的请求拼成一个 batchNPU 并行处理。在昇腾NPU上动态 batching 是提升吞吐的关键——batch1 的 GEMM 利用率只有 7%batch32 能到 65%。动态 Batching 的原理时刻 T1收到请求 Aprompt_len128 时刻 T2收到请求 Bprompt_len256 时刻 T3收到请求 Cprompt_len64 静态 batching等 batch 满 32 个才处理A 等了 200ms 动态 batching每 50ms 把当前所有 pending 请求拼成一个 batch 处理动态 batching 的权衡等待时间 vs batch 大小。等待越久batch 越大NPU 利用率越高但首 token 延迟越高。ATB 的动态 BatchingATB 的 LLM 接口内置动态 batchingfromatbimportLLM,DynamicBatchingConfig modelLLM(meta-llama/Llama-2-7b-hf,devicenpu:0,dynamic_batchingDynamicBatchingConfig(max_wait_ms50,# 最多等 50ms 凑 batchmax_batch_size32,# 最大 batch 大小max_seq_len4096,# 最大序列长度))# 并发发送多个请求ATB 自动做动态 batchingimportconcurrent.futureswithconcurrent.futures.ThreadPoolExecutor(max_workers32)asexecutor:futures[executor.submit(model.generate,prompt)forpromptinprompts]results[f.result()forfinfutures]Padding 策略不同长度的请求拼成 batch 需要 Padding 到相同长度。两种策略策略 1Padding 到最大长度# 请求 A: 128 tokens → padding 到 256# 请求 B: 256 tokens → 不用 padding# Batch 大小: [256, 256]缺点短请求浪费计算Padding token 也过了 Attention策略 2分桶Bucket# 预设几个桶128, 256, 512, 1024, 4096# 请求 A (128) → 放入 128 桶# 请求 B (256) → 放入 256 桶# 不同桶的请求不混批优点减少 Padding 浪费 缺点桶内请求少时 batch 大小受限ATB 默认用分桶策略。max_batch_size是每个桶的最大 batch 大小。动态 Batching 的吞吐提升Llama2-7BAtlas 800I A232 并发请求Batching 策略吞吐 (tokens/s)首 token 延迟 (ms)静态 batch115035静态 batch898035等 batch 满动态 batching (max_wait10ms)2,10045动态 batching (max_wait50ms)2,80085动态 batching (max_wait200ms)3,200235max_wait_ms是核心参数小 → 延迟低但吞吐低大 → 延迟高但吞吐高。在线服务一般取 50-100ms。离线批量推理可以取 500-1000ms不关心延迟只要吞吐。跟 KV Cache 的配合动态 batching 要求 KV Cache 能容纳不同 batch 大小的请求。Paged KV Cache 正好解决这个问题——不需要预分配固定 batch 大小的 KV Cache。modelLLM(meta-llama/Llama-2-7b-hf,devicenpu:0,kv_cache_dtypefp16,paged_kv_cacheTrue,# 必须开启dynamic_batchingDynamicBatchingConfig(max_wait_ms50),)如果不开启 Paged KV Cache动态 batching 的 KV Cache 显存浪费 30-50%因为要按最大 batch 预分配。实际部署配置在线对话服务QPS50延迟敏感configDynamicBatchingConfig(max_wait_ms50,# 平衡延迟和吞吐max_batch_size16,# 在线服务 batch 不用太大max_seq_len4096,)离线批量推理不关心延迟configDynamicBatchingConfig(max_wait_ms2000,# 等 2 秒凑大 batchmax_batch_size64,# 离线可以开大 batchmax_seq_len8192,)动态 batching 是昇腾NPU推理服务的标配——把 batch 从 1 提到 16-32吞吐提升 10-20×。关键参数max_wait_ms根据业务延迟要求调整。仓库在这里https://atomgit.com/cann/ATB
