本文深入探讨了线上推理的8个关键点包括压测指标选择、PD分离策略、长上下文处理、MoE模型部署优化、灰度发布技巧、LoRA热加载实践、KV Cache量化方法以及构建在线反馈闭环。内容涵盖了各项技术的原理、实践方法、优缺点分析及实际应用场景旨在帮助开发者提升线上推理服务的性能、稳定性和用户体验。这篇只聊线上推理真正绕不开的几件事压测、PD 分离、长上下文、MoE、灰度、LoRA、KV Cache 量化和反馈闭环。今天这篇文章在聊什么压测怎么跑别只看 tok/s要看 TTFT、TPOT、ITL 和排队PD 分离Prefill 和 Decode 为什么要拆什么时候不值得拆长上下文128K/1M 下 KV Cache 怎么控住MoE 模型部署总参数、激活参数、Expert 并行和负载均衡灰度发布和 A/B 测试流式输出怎么切流量怎么回滚LoRA 热加载一个底座挂多个 LoRA多个业务共用 GPUKV Cache 量化什么时候开 FP8 KV什么时候别开在线反馈闭环把真实用户反馈变成下一轮模型更新压测怎么跑很多推理服务上线前只测tokens/s这个不够。线上更容易出问题的是首 token 慢、流式输出抖、排队堆起来。先看这几个指标指标看什么说明TTFT首 token 延迟用户最先感知到的等待时间TPOT每个输出 token 的平均耗时影响流式输出速度ITLtoken 间延迟看流式输出是否抖动Throughput总吞吐一定要结合并发和请求长度看Queue time排队时间这个上来通常说明服务已经接近极限KV cache usageKV Cache 使用率接近 90% 后OOM 和排队风险都会变高不要只拿平均值。至少看 P50、P90、P99。LLM 服务里P99 往往比平均值更接近用户体感。用什么压vLLMvllm bench serve \ --model /models/Qwen2.5-7B-Instruct \ --dataset-name sharegpt \ --num-prompts 1000 \ --request-rate 10 \ --endpoint /v1/completionssglangpython -m sglang.bench_serving \ --backend sglang \ --host 127.0.0.1 \ --port 8000 \ --dataset-name sharegpt \ --num-prompts 1000 \ --request-rate 10压测流程建议按这个顺序来复制1. 单请求跑 5~10 分钟拿空载 TTFT / TPOT 基线 2. 固定输入输出长度逐步加并发1、2、4、8、16、32、64 3. 换真实数据集例如 ShareGPT 或业务日志采样 4. 阶梯加 QPS每级至少跑 2~5 分钟 5. 找到 P99 TTFT 或队列时间开始明显上升的点 6. 用这个点的 70%~80% 做稳定性压测至少跑 1 小时真实业务里请求长度分布比模型大小更重要。客服场景可能大部分是 1K 以下输入知识库问答可能是 8K~32K代码仓库分析可能直接上 100K。压测数据如果不像真实流量结论基本没用。监控怎么配vllmvllm:num_requests_waiting # 排队请求数 vllm:gpu_cache_usage_perc # KV Cache 使用率 vllm:e2e_request_latency_seconds # 端到端延迟 vllm:time_to_first_token_seconds # TTFT vllm:time_per_output_token_seconds # TPOTsglangsglang:num_running_requests sglang:num_queueing_requests sglang:cache_hit_rate sglang:time_to_first_token_seconds一个经验如果 GPU 利用率不高但请求排队很多通常不是算力不够这么简单可能是 KV Cache、调度、长 prompt 或路由命中率出了问题。PD 分离PD 分离就是把 Prefill 和 Decode 拆开跑。Prefill处理整段 prompt矩阵乘大吃算力Decode一次生成一个 token更吃显存带宽和 KV Cache混在一起跑时一个超长 prompt 的 prefill 可能拖住正在 decode 的短请求。用户看到的就是前几个字出来很慢或者流式输出一卡一卡的。先别急着拆PD 分离不是默认答案。它会引入更多机器、更多网络传输、更多调度逻辑。小集群先做这几件事# vLLM先开 chunked prefill --enable-chunked-prefill # 控制最大上下文别让模型 config 里的 128K/1M 默认生效 --max-model-len 8192如果开了 chunked prefill 后P99 还是被长 prompt 拖住再考虑 PD 分离。三类方案方案思路适合场景Chunked Prefill把长 prefill 切小块别一次堵住 decode单机、小集群同构 PD 分离Prefill/Decode 用同类 GPU但调度分开中等规模集群异构 PD 分离Prefill 用算力强的卡Decode 用带宽/显存更合适的卡大集群流量稳定常见系统DistServePrefill 和 Decode 分在不同 GPU 集群中间传 KV CacheMooncake围绕 KV Cache 做资源池强调缓存复用和分离调度Splitwise讨论同构集群里拆 Prefill/Decode 的收益边界工程落地时看三件事KV Cache 传输成本Prefill 算完要把 KV 给 Decode网络不够快会抵消收益。路由策略同一会话尽量打到能复用 KV 的节点。请求长度分布如果 95% 请求都很短PD 分离可能收益不明显。vLLM 已有实验性参数具体可用性看当前版本vllm serve model --role prefill --kv-transfer-method nccl vllm serve model --role decode --kv-transfer-method ncclSGLang 也在做 disaggregated serving 相关能力。注意DP Attention主要是提高大 batch 下 attention 吞吐不等于 PD 分离。长上下文长上下文的核心问题不是模型权重而是 KV Cache。128K、1M context 下每个请求都会留下很大的 KV。并发一上来显存先被 KV Cache 吃掉模型本身反而不是唯一大头。先把上限管住很多模型 config 写着支持 128K、256K、1M但业务未必真的需要。上线时先按业务设置--max-model-len 8192 # 常规客服 / 简单问答 --max-model-len 32768 # RAG / 长文档摘要 --max-model-len 131072 # 代码仓库、超长文档谨慎开别让推理框架按模型最大长度预分配 KV Cache。处理办法手段作用代价降max-model-len直接减少 KV 上限输入长度受限Chunked Prefill长 prompt 不再一次性堵住 decode不能减少总 KV只改善调度FP8 KV CacheKV 显存约减半少数任务可能有精度影响Prefix Caching重复 system prompt / 历史前缀可复用需要请求前缀稳定CPU/SSD Offload显存不够时用内存或磁盘兜底延迟会上升Token 级压缩H2O、SnapKV、StreamingLLM 等对质量有影响要评测换模型架构GQA、MLA 天然省 KV需要从选型阶段考虑怎么判断该不该上 128K问三个问题用户真的会输入这么长吗还是产品想当然长输入是否真的提升答案质量有没有离线评测128K 请求占用资源后会不会拖垮短请求很多场景用 RAG 分段、摘要、重排比直接把窗口拉到 128K 更稳。MoE 模型部署MoE 容易被误解激活参数少不代表显存只按激活参数算。比如一个 235B 总参、22B 激活的 MoE单 token 计算量接近 22B但权重还是要加载 235B。显存预算按总参数看吞吐再看激活参数。MoE 的几个坑权重大完整 expert 权重都要放进来量化也只是减少权重大小。路由不均有些 expert 热有些 expert 冷GPU 负载会不均。All-to-All 通信Expert Parallelism 下 token 会在卡之间交换拓扑很重要。Batch 不规则不同请求激活 expert 不同CUDA Graph 捕获没 Dense 模型那么舒服。并行方式怎么选并行方式解决什么代价TP把矩阵切到多卡通信稳定但每层都要同步EP把 expert 分到多卡需要 All-to-All网络敏感DP多副本服务不同请求占显存但扩吞吐简单PP按层切流水线调度复杂延迟会增加MoE 大模型通常是 TP EP DP 一起用。比例没有固定答案要看 expert 数、GPU 拓扑、显存和流量。Expert Parallelism 示例python3 -m sglang.launch_server \ --model-path deepseek-ai/DeepSeek-V3-0324 \ --tp 8 \ --ep 8 \ --moe-a2a-backend deepep \ --deepep-mode auto \ --enable-dp-attention \ --trust-remote-code \ --dist-timeout 3600这只是服务形态示例不是通用模板。DeepSeek、Qwen MoE、Kimi K2 的 checkpoint 格式、量化方式、tool parser 都不一样部署前看对应模型卡和框架文档。Expert 负载均衡到底怎么做先分清两件事训练期均衡让 router 学会别总选同几个 expert。常见做法是 auxiliary loss、router bias、group-limited routing 等。推理期均衡模型已经训练完了不能改 router 逻辑太多重点变成 expert 怎么摆、热门 expert 要不要复制、请求怎么分发。线上能做的通常是第二类。1. 先统计 expert 热度每一层 MoE 都有 router。一次 batch 进来后可以统计每个 expert 分到了多少 tokenlayer_12: expert_0: 1821 tokens expert_1: 233 tokens expert_2: 1765 tokens expert_3: 91 tokens这类数据可以在推理框架里打点也可以在离线 replay 里跑出来。只看平均值不够还要看 P99因为高峰时热门 expert 会把某张卡打满。2. 做 expert 到 GPU 的映射这里的放不是你手工把某个.safetensors文件拷到某张卡上而是推理框架在启动时把 MoE 层里的 expert 权重切到不同EP rank上。一个 EP rank 通常就是一个 GPU 进程。假设某层有 16 个 expertEP size 4那么最朴素的平均切法就是EP rank 0 / GPU0: expert 0,1,2,3 EP rank 1 / GPU1: expert 4,5,6,7 EP rank 2 / GPU2: expert 8,9,10,11 EP rank 3 / GPU3: expert 12,13,14,15公式就是每张 GPU 放的 expert 数 num_experts / ep_size复制DeepSeek-V3 这类模型每层有 256 个 routed expert。如果ep_size8默认平均切就是每个 EP rank 放 32 个 expert。router 选中某个 expert 后token 会通过 all-to-all 发到持有这个 expert 的 GPU 上算算完再 combine 回来。但平均切只保证expert 数量平均不保证token 数量平均。如果expert_0和expert_2都很热而它们刚好在同一张 GPU 上这张卡就会比其他卡忙。所以更好的做法是按热度重排GPU0: expert_0(hot), expert_7(cold), expert_9(cold) GPU1: expert_2(hot), expert_4(cold), expert_11(cold) GPU2: expert_5(mid), expert_6(mid), expert_8(mid) GPU3: expert_1(mid), expert_3(cold), expert_10(mid)目标不是每张 GPU 的 expert 数完全一样而是每张 GPU 收到的 token 数接近。vLLM / SGLang 里怎么做vLLM里一般不手写 expert 列表而是开 EP# 官方推荐写法TP1, DP8这样 EP size TP × DP 8 vllm serve deepseek-ai/DeepSeek-V3-0324 \ --tensor-parallel-size 1 \ --data-parallel-size 8 \ --enable-expert-parallelvLLM 启用--enable-expert-parallel后EP size TP × DP。Expert 层按 EP 切分到各 rankAttention 层如果 TP1 就在 DP ranks 间复制权重如果 TP1 就在每个 DP group 内做 TP 分片。没有 EPLB 时expert 默认按 id 均匀切到各 EP rank。如果要让 vLLM 根据运行时负载调整 expert mapping可以开 EPLBvllm serve deepseek-ai/DeepSeek-V3-0324 \ --tensor-parallel-size 1 \ --data-parallel-size 8 \ --enable-expert-parallel \ --enable-eplb \ --eplb-config {window_size:1000,step_interval:3000,num_redundant_experts:2,log_balancedness:true}几个参数说明num_redundant_experts每个 EP rank 上额外放几个冗余 expert给热门 expert 做副本用。DeepSeek-V3 上每个 EP rank 多放一个 expert 约多占 2.4GB 显存。window_size用多少个 step 的 activation 统计做 rebalance 决策。step_interval隔多少个 step 执行一次 rebalance。log_balancedness打印负载均衡指标平均 token/expert ÷ 最大 token/expert。SGLang里也是类似思路显式指定--tp和--ep然后选择 MoE all-to-all 后端。DeepEP 是常见选择python3 -m sglang.launch_server \ --model-path deepseek-ai/DeepSeek-V3-0324 \ --tp 8 \ --ep 8 \ --moe-a2a-backend deepep \ --deepep-mode auto \ --enable-eplb \ --trust-remote-code注意 SGLang 文档里明确写了使用 DeepEP 后端时当前要求ep_size tp_size。如果ep_size lt; tp_size即混合 EPTP只能用none后端。SGLang 的--enable-eplb会基于 expert activation statistics 计算更好的 expert arrangement包括 expert placement 和 expert replication。和 vLLM 一样没有暴露手工指定 expert_0 放 GPU3的接口一般是让 EPLB 自动算。所以落地时可以这么理解默认 EP框架按 expert id 均匀切到 EP ranks EPLB框架统计 expert 热度再重排/复制 expert DeepEP / all-to-all backend负责 token 在 GPU 间分发和合并3. 热门 expert 做副本如果某个 expert 长期很热只换位置还不够就复制一份expert_0 replica A - GPU0 expert_0 replica B - GPU2推理时 router 仍然选择expert_0但调度层可以把 token 分到 A 或 B。这样能摊掉单卡热点。代价是多占一份权重显存。这就是 EPLB 这类方案的核心思路根据线上或离线统计给热门 expert 加副本同时把冷 expert 和热 expert 混着放。4. 定期重排但别太频繁expert 热度会随业务变化。代码任务、数学任务、闲聊任务激活的 expert 分布可能不一样。可以每天或每周根据日志重算一次映射表。但不要每几分钟就换一次。expert 重新摆放涉及权重加载、缓存失效和服务抖动太频繁反而不稳定。5. 请求路由也要配合如果上层有多个 MoE worker路由时不只看 QPS还要看当前节点 KV Cache 是否接近上限当前节点哪些 expert 正忙这个 session 是否能命中 prefix cache这个请求预计输入长度有多长所以 MoE 负载均衡不是一个开关而是三层一起做router 选 expert ↓ expert placement 决定 expert 放哪张卡 ↓ service router 决定请求打到哪组 workerDeepSeek 这类低成本是怎么来的别把便宜理解成某个参数。DeepSeek V3/V4 这类路线通常是几层东西叠出来的MoE 降每 token 计算量总参数很大但每个 token 只激活一小部分 expert。效果接近大模型计算量接近激活参数。MLA 降 KV Cache 成本长上下文推理时KV Cache 是大头。MLA 把 KV 压到低秩空间显存和带宽压力都降下来。FP8 / 更低精度推理H100/H200/GB200 这类卡上FP8 能同时省显存和提高吞吐。V3/V4 都提供了 FP8 或更低精度的 checkpoint本质上是在吃低精度硬件红利。MTP / speculative decoding 降解码延迟低并发或中低 batch 时小步预测多个 token再由主模型验证可以降低 TPOT。但高并发时未必总是赚要压测。EP EPLB 提高 GPU 利用率MoE 最怕某几张卡忙死、其他卡闲着。Expert 复制、重排、All-to-All 优化都是为了把每张卡喂满。Prefix cache / prompt cache 降重复输入成本API 价格里常见缓存命中输入更便宜技术上就是前缀复用。系统 prompt、工具说明、长文档前缀如果能命中prefill 成本会少很多。灰度发布和 A/B 测试LLM 灰度比普通 HTTP 服务麻烦因为它有流式输出和会话状态。三种上线方式方式怎么做适合什么Shadow新旧模型都跑只返回旧模型结果新模型上线前做离线对比Canary少量真实流量切到新模型看延迟、错误率和用户反馈A/B按用户或会话分组比较业务指标例如留存、转化、满意度Shadow Mode新模型不影响用户只把输出记录下来http: - route: - destination: host: llm-v1 weight: 100 mirror: host: llm-v2 mirrorPercentage: value: 100Shadow 要注意成本。一次用户请求会变成两次推理GPU 成本直接上去。通常只抽样一部分流量。Canary先切 1%~5%看几个小时再逐步到 10%、30%、50%。不要一上来切 50%。- route: - destination: host: llm-v1 weight: 95 - destination: host: llm-v2 weight: 5监控至少看TTFT / TPOT / P99 延迟5xx、超时、断流平均输出长度和拒答率用户重新生成率人工抽检通过率A/B 测试按用户 ID 或 session ID 哈希分组保证同一用户一直走同一个模型。多轮对话千万别中途切模型否则上下文、工具调用、KV Cache 都会乱。工程规则流式连接建立后不要切后端同一会话固定路由到同一模型版本回滚要能秒级生效日志里必须带model_version、prompt_hash、user_group评估不要只看延迟还要看业务指标LoRA 热加载LoRA 热加载适合这样的场景一个底座模型服务多个业务每个业务有自己的轻量适配器但不想为每个业务单独起一套模型。启动时注册vllm serve /models/Qwen2.5-7B-Instruct \ --enable-lora \ --lora-modules cs/loras/customer_service med/loras/medical law/loras/legal \ --max-loras 8 \ --max-lora-rank 64运行时加载 / 卸载# 加载 curl -X POST http://localhost:8000/v1/load_lora_adapter \ -H Content-Type: application/json \ -d {lora_name:finance,lora_path:/loras/finance} # 卸载 curl -X POST http://localhost:8000/v1/unload_lora_adapter \ -H Content-Type: application/json \ -d {lora_name:finance}踩坑问题表现处理rank 不一致加载失败或显存超预期--max-lora-rank设成最大 rankLoRA 太多显存碎片、冷启动慢固定上限热门 LoRA 预加载batch 混 LoRA吞吐下降高吞吐业务尽量按 LoRA 分流权限混乱业务 A 调到业务 B 的 LoRAAPI 层做白名单不只靠 model 名回滚慢新 LoRA 效果差还在服务保留上一版 LoRA支持快速切回业务隔离请求里带model或业务标识路由层决定用哪个 LoRA。限流、日志、监控也按业务拆开不然出问题时很难定位。KV Cache 量化KV Cache 量化和权重量化不是一回事。权重量化省模型权重KV Cache 量化省的是每个请求运行时产生的缓存。长上下文、高并发场景KV Cache 往往比权重更先吃满显存。怎么开# vLLM vllm serve model \ --kv-cache-dtype fp8_e5m2 # SGLang python3 -m sglang.launch_server \ --model-path model \ --kv-cache-dtype fp8_e5m2部分模型或硬件对 FP8 KV 的支持不一样先用离线评测集跑质量回归再上线。什么时候值得开场景是否建议8K 以下短请求不一定需要先看显存压力32K~128K 长上下文值得试收益通常明显H100/H200/B200更适合硬件支持 FP8A100 / L40S要看框架实现和性能回退对数值很敏感的任务必须做质量回归架构层的 KV 压缩技术思路代表模型GQA多个 Query 头共享较少的 KV 头Llama-3 系列MQA所有 Query 头共享很少的 KV 头Falcon、PaLM 等MLA把 KV 投到低秩潜在空间DeepSeek V2/V3选模型时就要看这些结构。一个 GQA/MLA 模型天然比传统 MHA 省 KV Cache后面再怎么调参数都不如一开始选对架构。在线反馈闭环上线后模型不会自动变好。要让它变好必须把线上反馈变成可训练、可评估、可回滚的数据流。最小闭环用户请求 ↓ 推理服务返回结果 ↓ 采集反馈点赞/踩、重新生成、人工修改、下游任务成功率 ↓ 清洗成训练/评估数据 ↓ LoRA 微调或 DPO ↓ 离线评估 ↓ 灰度上线反馈信号信号强度备注点赞 / 点踩强少但直接重新生成中说明用户不满意但原因不清楚用户手动编辑输出强很适合做 SFT 数据对话中断弱只能当辅助信号下游任务成功率强比如代码是否通过测试、工单是否解决数据清洗别把所有线上数据都扔进训练。至少做几步去掉隐私信息和敏感字段去重避免高频模板污染数据按业务场景分桶不要混成一锅保留负样本别只收点赞数据给每条数据打上模型版本、时间、业务来源热加载上线如果底座不变只更新 LoRA可以直接热加载def feedback_loop(): data fetch_feedback(days3, min_samples1000) train_data clean_and_format(data) new_lora train_lora(base_model, train_data, rank16, epochs2) if offline_eval(new_lora) offline_eval(current_lora): load_lora(prod_next, new_lora) canary(prod_next, percent5)​最后我在一线科技企业深耕十二载见证过太多因技术更迭而跃迁的案例。那些率先拥抱 AI 的同事早已在效率与薪资上形成代际优势我意识到有很多经验和知识值得分享给大家也可以通过我们的能力和经验解答大家在大模型的学习中的很多困惑。我整理出这套 AI 大模型突围资料包✅AI大模型学习路线图✅Agent行业报告✅100集大模型视频教程✅大模型书籍PDF✅DeepSeek教程✅AI产品经理入门资料完整的大模型学习和面试资料已经上传带到CSDN的官方了有需要的朋友可以扫描下方二维码免费领取【保证100%免费】​​为什么说现在普通人就业/升职加薪的首选是AI大模型人工智能技术的爆发式增长正以不可逆转之势重塑就业市场版图。从DeepSeek等国产大模型引发的科技圈热议到全国两会关于AI产业发展的政策聚焦再到招聘会上排起的长队AI的热度已从技术领域渗透到就业市场的每一个角落。智联招聘的最新数据给出了最直观的印证2025年2月AI领域求职人数同比增幅突破200%远超其他行业平均水平整个人工智能行业的求职增速达到33.4%位居各行业榜首其中人工智能工程师岗位的求职热度更是飙升69.6%。AI产业的快速扩张也让人才供需矛盾愈发突出。麦肯锡报告明确预测到2030年中国AI专业人才需求将达600万人人才缺口可能高达400万人这一缺口不仅存在于核心技术领域更蔓延至产业应用的各个环节。​​资料包有什么①从入门到精通的全套视频教程⑤⑥包含提示词工程、RAG、Agent等技术点② AI大模型学习路线图还有视频解说全过程AI大模型学习路线③学习电子书籍和技术文档市面上的大模型书籍确实太多了这些是我精选出来的④各大厂大模型面试题目详解⑤ 这些资料真的有用吗?这份资料由我和鲁为民博士共同整理鲁为民博士先后获得了北京清华大学学士和美国加州理工学院博士学位在包括IEEE Transactions等学术期刊和诸多国际会议上发表了超过50篇学术论文、取得了多项美国和中国发明专利同时还斩获了吴文俊人工智能科学技术奖。目前我正在和鲁博士共同进行人工智能的研究。所有的视频教程由智泊AI老师录制且资料与智泊AI共享相互补充。这份学习大礼包应该算是现在最全面的大模型学习资料了。资料内容涵盖了从入门到进阶的各类视频教程和实战项目无论你是小白还是有些技术基础的这份资料都绝对能帮助你提升薪资待遇转行大模型岗位。智泊AI始终秉持着“让每个人平等享受到优质教育资源”的育人理念‌通过动态追踪大模型开发、数据标注伦理等前沿技术趋势‌构建起前沿课程智能实训精准就业的高效培养体系。课堂上不光教理论还带着学员做了十多个真实项目。学员要亲自上手搞数据清洗、模型调优这些硬核操作把课本知识变成真本事‌​​​​如果说你是以下人群中的其中一类都可以来智泊AI学习人工智能找到高薪工作一次小小的“投资”换来的是终身受益应届毕业生‌无工作经验但想要系统学习AI大模型技术期待通过实战项目掌握核心技术。零基础转型‌非技术背景但关注AI应用场景计划通过低代码工具实现“AI行业”跨界‌。业务赋能 ‌突破瓶颈传统开发者Java/前端等学习Transformer架构与LangChain框架向AI全栈工程师转型‌。获取方式有需要的小伙伴可以保存图片到wx扫描二v码免费领取【保证100%免费】**​