AI 2.0 时代的大模型推理：从模型到硬件的协同优化

如果无法正常显示，请先停止浏览器的去广告插件。

1. AI 2.0 时代的大模型推理：从模型到硬件的协同优化曾书霖

2. 目录 01 以智能革命引领大模型推理范式变革 02 以弹性算力集群驱动云侧智能升级 03 面向华为昇腾的推理优化部署实践 04 以有限算力架构释放终端应用潜能 05 以大模型推理技术创新融合人工智能产业创新

4. 01 以智能革命引领大模型推理范式变革

5. 以人工智能为代表的第四次工业革命（智能革命）极大提升人类生产力信息技术电力蒸汽机提升各产业生产力加速工业发展解放农业生产力人工智能智能化应用创造价值第一次机械革命第二次电气革命体力密集型生产生产100米布/人日体力密集型生产组装一辆汽车/人日 1800 1825 1850 1875 1900 世界GDP增速第四次智能革命第三次数字革命创造性劳动药物发现未知时间→月量级重复性脑力工作 100阶线性方程组求解 1800人小时→0.05人小时 1925 1950 1975 2000 世界GDP总量 2025 Future

6. 生产工具与驱动方式的创新工业革命机械革命电气革命数字革命智能革命工具创新蒸汽机内燃机互联网智能算法人类生产力水平与认知边界不断突破替代劳动体力重复劳动流程化劳动知识管理劳动创造性劳动驱动方式蒸汽动力火电动力知识信息半导体芯片

7. 模型推理：技术协同的中枢与产业价值的放大器智能革命智能算法 “人工智能+”制造 “人工智能+”金融 “人工智能+”能源 “人工智能+”医疗 … 产业价值放大器模型训练模型推理创造性劳动半导体芯片替代技术协同的中枢用户请求调度云平台计算图优化推理框架模型压缩算子优化调度优化端侧设备

8. 自2012 年以来生成模型发展的关键节点国外标 2017年谷歌提 2019年谷 Transformer 歌提出T5 志出 Transformer架构奠架构性定了LLM基础，开验证"Text- 节启大模型时代 to-Text"范式在NLP任务中点的通用性 2017 2019 国内标志性 2016年商汤、旷世崛起节以计算机视觉技术为核心，推动AI 点在安防等领域的落地 2020年OpenAI 2022年提出GPT-3 OpenAI 展示LLM强大的的 InstructGPT 2023年 OpenAI ChatGPT爆火少样本学习能力，提出利用RLHF讲引爆全球生成式AI 引发业界对大模型 LLM与人类对应用，标志AI进入的研究热潮齐，ChatGPT的大规模普及阶段基础 2020 2021 2022 2023年 Meta开源 Llama 后续逐步成为全球第一大大模型开源模型及生态 2023 2024年OpenAI SORA爆火 2024年OpenAI 提出O1系列模型火爆全球的视频生成软件，首次实现1分钟长视频的生成，且画面一致性较高将长思维链推理技术带入主流，总结Test Time Scaling，显著提升模型的推理能力 2024 2021年百度推出ERNIE-3.0 智谱推出 ChatGLM 在多项NLP任务中超越GPT-3 第一个国产大模型后续逐步成为继 Meta Llama之后的全球第二大大模型开源模型及生态阿里通义千问开源 2025 2025年 2024年生数推百模大战国内多家公司 DeepSeek开源出ViDU 相继发布自研 R1推理模型生数科技发布国内大模型，API 首个文生视频模服务价格降低型，距离Sora发布 10倍以上仅2个月比肩OpenAI O1算法性能的同时，成本仅为5%～10%

9. 尺度定律(Scaling Law)逐步转向推理规模扩展 Intelligence 国外标 2017年谷歌提 2019年谷 Transformer 歌提出T5 志出 Transformer架构奠架构性定了LLM基础，开验证"Text- 节启大模型时代 to-Text"范式在NLP任务中点的通用性 2017 2019 2020年OpenAI 2022年提出GPT-3 OpenAI 展示LLM强大的的 InstructGPT 2023年 OpenAI ChatGPT爆火少样本学习能力，提出利用RLHF讲引爆全球生成式AI 引发业界对大模型 LLM与人类对应用，标志AI进入的研究热潮齐，ChatGPT的大规模普及阶段基础 2020 2021 2022 2023 2023年 Meta开源 Llama 2024年OpenAI SORA爆火 2024年OpenAI 提出O1系列模型火爆全球的视频生成软件，首次实现1分钟长视频的生成，且画面一致性较高将长思维链推理技术带入主流，总结Test Time Scaling，显著提升模型的推理能力 Test-Time Scaling “Reasoning” 后续逐步成为全球第一大大模型开源模型及生态推理规模扩展 2024 2025 国 Post-Training Scaling 内补充增强训练规模扩展标智谱推出 2021年百度推阿里通义千问 2025年志 2024年生数推百模大战 Pre-Training Scaling ChatGLM 国内多家公司 DeepSeek开源出ERNIE-3.0 开源性出ViDU 第一个国产大模型后续逐步成为继相继发布自研 R1推理模型在多项NLP任务中 2016年商汤、旷世崛起预训练规模扩展生数科技发布国内节以计算机视觉技术为核心，推动AI 大模型，API 超越GPT-3 Meta Llama之后比肩OpenAI O1算首个文生视频模服务价格降低 Compute 的全球第二大大模点在安防等领域的落地法性能的同时，成型，距离Sora发布型开源模型及生态 Ref：NVIDIA CEO Jensen Huang Keynote at CES 2025 仅2个月 10倍以上本仅为5%～10%

10. 模型推理计算范式转变导致计算需求激增 GPT - o1的计算范式变化：CoT + 强化学习推理阶段 GPT-4 Post-Training GPT-4o o1-mini o1 GPT-4o mini 80% RLHF Base model 70% o1 基础能力 GPT-4 o1 RLHF Base model RL Safety 增强逻辑 Think 内容安全 Answer Think&Summary 思考/CoT摘要 Answer 生成答案 60% 训练阶段 Pre-Training 增加模型的推理迭代次数，计算量增加2个量级 10x 50% ~60x 40% 30% ~100x 20% 10% 0% 0 20 40 60 80 100 归一化算力需求成本* 678x 47410 1E+4 1E+2 69.93 1E+0 原模型 *ref：OpenAI o1-mini | OpenAI 原模型+推理缩放定律

11. Deepseek 等模型推动应用落地加速带来推理需求爆发未来推理算力需求或是预训练需求的百倍以上推理算力需求“喷发式增长” 预训练时代即将结束 Ilya，NeurIPS 2024 黄仁勋，GTC 2025 步入2025 年，受限于预训练数据、大模型迭代周期、硬件成本等因素为了保持模型的响应速度，让用户不会因等待而失去耐心，我们现在需要将计算速度提高10倍，黄仁勋表示：整体计算需求轻松增长至100倍 Pre-Training Scaling 收益正在衰减 70% 中国亿级用户APP 已有进行了“AI转型” 共962个传统APP备案了深度合成算法 Ref：QuestMobile A产业洞察研究院 2025年1月推理模型需要在回答之前进行多轮内部推理，因此计算需求大得多，响应时间也更长。

12. 大模型推理系统形态 AIPC 手机 100-1000 token/s * 应用需求： 5-10 token/s 现有实现： 20-25 现有实现： token/s 模型：Qwen2.5-7B 硬件设备：骁龙8 Gen1 推理框架：llama.cpp+OpenCL 模型：Qwen2-7B 硬件设备：AMD Krackan 推理框架：llama.cpp 端侧推理系统 *前沿应用——机器人智能的基本需求，参考自Deray, Jeremie, Joan Sola, and Juan Andrade-Cetto, “Joint on-manifold self-calibration of odometry model and sensor extrinsics using pre- integration.” 2019 European Conference on Mobile Robots (ECMR). IEEE, 2019. 一体机云服务 25-30k token/s/节点 + 理论值：现有实现：～8000 现有实现：～14.8k token/s token/s/节点模型：DeepSeek-R1 硬件设备：8xH20 推理框架：SGLang 模型：DeepSeek-R1 硬件设备：22台H800 推理框架：DeepSeek 云侧推理系统 + 理论估计上界可达性，假设集群配置为计算瓶颈，考虑计算量和网络延迟计算上界

13. 大模型推理系统形态端侧推理系统手机 AIPC 一体机云服务优化目标：降低延时核心特点：单用户、少请求 * 100-1000 token/s 请求应用需求： 5-10 token/s 用户现有实现： 20-25 现有实现： token/s 模型：Qwen2.5-7B 硬件设备：骁龙8 Gen1 推理框架：llama.cpp+OpenCL 端侧设备模型：Qwen2-7B 硬件设备：AMD Krackan 推理框架：llama.cpp 端侧推理关键问题：资源受限端侧推理系统 *前沿应用——机器人智能的基本需求，参考自Deray, Jeremie, Joan Sola, and Juan Andrade-Cetto, “Joint on-manifold self-calibration of odometry model and sensor extrinsics using pre- integration.” 2019 European Conference on Mobile Robots (ECMR). IEEE, 2019. 理论值： 25-30k token/s/节点 + 现有实现：～8000 现有实现：～14.8k token/s token/s/节点模型：DeepSeek-R1 硬件设备：8xH20 推理框架：SGLang 模型：DeepSeek-R1 硬件设备：22台H800 推理框架：DeepSeek 云侧推理系统 + 理论估计上界可达性，假设集群配置为计算瓶颈，考虑计算量和网络延迟计算上界

14. 大模型推理系统形态端侧推理系统手机 AIPC 一体机云侧推理系统云服务优化目标：降低延时优化目标：满足用户延时要求，提升吞吐率核心特点：单用户、少请求核心特点：多用户、多请求 * 100-1000 token/s 请求应用需求： 5-10 token/s 用户现有实现： 20-25 现有实现： token/s 模型：Qwen2.5-7B 硬件设备：骁龙8 Gen1 推理框架：llama.cpp+OpenCL 端侧设备模型：Qwen2-7B 硬件设备：AMD Krackan 推理框架：llama.cpp 端侧推理关键问题：资源受限端侧推理系统 *前沿应用——机器人智能的基本需求，参考自Deray, Jeremie, Joan Sola, and Juan Andrade-Cetto, “Joint on-manifold self-calibration of odometry model and sensor extrinsics using pre- integration.” 2019 European Conference on Mobile Robots (ECMR). IEEE, 2019. 25-30k token/s/节点请求理论值： + 现有实现：～8000 用户1 token/s ... 现有实现：～14.8k 模型：DeepSeek-R1 硬件设备：8xH20 用户N 推理框架：SGLang token/s/节点模型：DeepSeek-R1 计算集群硬件设备：22台H800 推理框架：DeepSeek 云侧推理关键问题：资源调度云侧推理系统 + 理论估计上界可达性，假设集群配置为计算瓶颈，考虑计算量和网络延迟计算上界

15. 大模型推理系统的效率挑战端侧推理系统云侧推理系统优化目标：降低延时优化目标：满足用户延时要求，提升吞吐率核心特点：单用户、少请求核心特点：多用户、多请求重叠传输延时开销小规模负载计算（利用率： 50%→90%）协同挑战多处理器硬件资源协同处理存储需求（存储量 100GB→10GB）大规模负载并行计算计算挑战提升生成式模型的计算利用率满足用户目标延时调度挑战不同用户间资源竞争及延时需求存储挑战同时存储大量请求的KV cache 提升显存利用效率（利用率 70%→90%）

16. 02 以弹性算力集群驱动云侧智能升级

17. 挑战：云侧大模型推理 ① 计算挑战 Prefill阶段计算密集型 Decode阶段访存密集型 ③ 调度挑战 ② 存储挑战云侧集群存储容量大推理服务存储利用率低用户需求低延时 input = "用python实现冒泡排序" 输入的prompt Prefill 只服务我延时最低 output = "def" 第1个token 系统需求高吞吐率服务多请求以提升吞吐率 Decode output = "def bubble" 第2个token Decode output = "def bubble_" 第3个token 集群存储 TB量级请求不等长存储碎片造成利用率低（~70%）计算集群请求 …… Prefill和Decode两阶段计算特性不同需分别针对性优化计算请求动态生成引入存储碎片导致系统存储利用率低用户间存在资源竞争在满足用户目标前提下提升系统吞吐率

18. 背景：云侧大模型核心技术云侧推理服务：多用户、多请求计算挑战提升生成式模型的计算利用率存储挑战同时存储大量请求的KV cache 调度挑战不同用户间资源竞争及延时需求算子和计算图优化分页式存储前缀缓存批处理、请求顺序、阶段间并行优化 FlashAttention FastServe Splitwise (NeurIPS 22) 降低注意力的存储量和访存量 Transformer计算的必需算子 (arXiv 23) 面向LLM请求顺序优化多级队列近似最短剩余时间策略开启关于请求顺序方面的研究 (ISCA 24) LLM推理服务 P/D分离式计算去除了阶段间延时干扰 Orca vLLM Sarathi-Serve SGLang (OSDI 22) 连续批处理方法 LLM推理服务的基本调度方法 1个数量级吞吐率提升 (SOSP 22) KV cache分页式存储 LLM推理服务的基本存储方法 2-4倍吞吐率提升 (OSDI 24) P/D请求混合批处理融合式架构基本批处理方式 2倍吞吐率提升云侧推理服务技术Milestone (NeurIPS 24) 前缀缓存技术复用请求间重复的KV cache 6倍吞吐率提升

19. 背景：融合式与分离式实例融合式实例：P/D计算和存储共享资源 Prefill 请求单个融合实例 Decode 请求分离式实例：P/D计算和存储资源分离 Prefill Prefill 实例请求计算融合 GPU SMs 计算分离 GPU SMs 存储融合 GPU HBM 存储分离 GPU HBM 请求的Prefill和Decode阶段均在相同实例进行计算和存储代表框架 [1] W. Kwon, et al. ” Efficient Memory Management for Large Language Model Serving with PagedAttention.”, SOSP, 2023. [2] L. Zheng, et al. “SGLang: Efficient Execution of Structured Language Model Programs”, NeurIPS, 2024. Decode 请求 Decode 实例 GPU SMs KV cache GPU HBM 请求在Prefill实例上完成Prefill阶段后，传输KV cache至 Decode实例进行计算代表框架 [3] DeepSeek-AI. “DeepSeek-V3 Technique Report”, arXiv, 2025. [4] R. Qin, et al. “Mooncake: Trading More Storage for Less Computation”, FAST, 2025.

20. 思路：融合式与分离式实例分析融合式实例：P/D计算和存储共享资源 Prefill 请求单个融合实例 GPU SMs 存储融合 GPU HBM 请求的Prefill和Decode阶段均在相同实例进行计算和存储代表框架 [1] W. Kwon, et al. ” Efficient Memory Management for Large Language Model Serving with PagedAttention.”, SOSP, 2023. [2] L. Zheng, et al. “SGLang: Efficient Execution of Structured Language Model Programs”, NeurIPS, 2024. Decode请求请求1，2，4 请求3，5 不同阶段请求互相等待 Decode 请求计算融合 Prefill请求计算劣势存储优势请求混合批处理或请求1，2，3，4，5 由编译器调度计算资源 P/D间请求延时干扰严重 P/D计算资源配比不可控 P/D计算之间无需传递KV cache KV cache能使用所有存储资源

21. 思路：融合式与分离式实例分析计算优势 P/D隔离计算无延时干扰可以通过GPU数配比计算资源存储不均衡 Prefill 实例 KV cache生成后即传输存储劣势分离式实例：P/D计算和存储资源分离 Decode 实例长期存储KV cache 实例切换需转移存储 Decode 实例1 切换 Prefill 实例1 Decode 实例2 P/D实例间KV cache存储不均衡（例，P: 23% v.s. D: 72%*）资源调整涉及存储搬移开销 *Llama3-70B, Prefill实例TP=4, Decode实例TP=4, ShareGPT数据集 Prefill Prefill 实例请求计算分离 GPU SMs 存储分离 GPU HBM Decode 请求 Decode 实例 GPU SMs KV cache GPU HBM 请求在Prefill实例上完成Prefill阶段后，传输KV cache 至Decode实例进行计算代表框架 [3] DeepSeek-AI. “DeepSeek-V3 Technique Report”, arXiv, 2025. [4] R. Qin, et al. “Mooncake: Trading More Storage for Less Computation”, FAST, 2025.

22. 思路：融合式与分离式实例分析融合式实例：P/D计算和存储共享资源计算劣势存储优势 P/D间请求延时干扰严重计算优势 P/D计算资源配比不可控 P/D计算之间无需传递KV cache 分离式实例：P/D计算和存储资源分离 ✓ KV cache能使用所有存储资源 *Llama3-70B, Prefill实例TP=4, Decode实例TP=4, ShareGPT数据集存储劣势 P/D隔离计算无延时干扰可以通过GPU数配比计算资源 P/D实例间KV cache存储不均衡（例，P: 23% v.s. D: 72%*）资源调整涉及存储搬移开销 ✓

23. 方案：semi - PD 实例计算分离 & 存储融合：P/D计算资源隔离，但是共享存储资源计算优势 Prefill 请求 Decode 请求 P/D计算资源隔离且分为不同数据流 P/D隔离计算无延时干扰可以通过GPU数配比计算资源计算融合存储融合 GPU SMs GPU HBM 但是共享相同的存储资源 P/D计算之间无需传递KV cache KV cache能使用所有存储资源单个semi-PD实例存储优势

24. 方案：semi - PD 技术细节技术细节：计算分离 & 存储融合技术细节：低开销资源调整机制 Prefill进程计算分离 GPU SMs 挑战请求1，2，4 P/D间资源调整模型权重重载、KV cache拷贝开销，造成请求阻塞 GPU SMs 请求3，5 Decode进程 P/D阶段的计算分别由不同的进程（抽象为worker）完成进程间实现SM粒度的计算资源划分优化前 Prefill进程请求1，2，4 请求3，5 Decode进程 GPU SMs 计算资源调整重载+拷贝请求1，2，4 重载+拷贝请求3，5 常驻进程（为新进程广播存储地址）存储融合原子化显存分配查询地址，更新存储量， Prefill 请求存储原子化显存分配查询地址，更新存储量， Decod e请求通过原子化的显存分配避免P/D worker显存管理的冲突优化后方案请求1，2，4 Prefill进程请求3，5 Decode进程请求1，2，4 请求3，5 引入常驻进程管理模型权重和KV cache存储，无需重载和拷贝

25. 方案：semi - PD 应用适配实例推理场景集群推理场景每张GPU上的P/D worker独立、异步地与并行组进行通信，通信总量不变 semi-PD实例作为可选实例之一，与P/D实例共同参与请求路由单个semi-PD实例用户请求 API server 请求路由请求 KV cache Prefill 实例 Decode 实例 semi-PD 实例分布式KV cache存储和传输管理 *以TP=2, PP=2为例

26. 效果：更低的延时更高的吞吐率 8000 测试配置 DeepSeek-V3模型 FP8, TP8, H200 输入均值2k, 输出均值256 同时取得10%的吞吐率提升和2倍的延时降低 rr=3.0 6621tps 吞吐率（token/s, semi-PD+SGLang结果 SGLang结果 rr=3.5 7197tps rr=2.0 4504tps 4000 2000 0 0.00 rr=5.0 7276tps rr=5.0 7024tps rr=4.0 6736tps rr=4.5 6859tps rr=2.5 5588tps rr=2.0 4510tps rr=1.5 3405tps rr=1.0 2287tps rr=4.5 7310tps rr=3.5 6704tps rr=3.0 6637tps rr=2.5 5578tps 6000 rr=4.0 7323tps rr=1.5 3410tps rr=1.0 2288tps 20.00 40.00 60.00 80.00 100.00 端到端延时-中位数（s） 120.00 140.00

27. 效果：首Token 延时和Token 平均延时对比 semi-PD+SGLang结果 SGLang结果 120 2.5 P99 TTFT 系统中99%请求的首Token延时不超过的值 2 80 60 40 降低78% 1.5 降低 5.6倍 1 0.5 20 P99 ITL 系统中99%请求的 Token间平均延时不超过的值测试配置 DeepSeek-V3模型 FP8, TP8, H200 输入均值2k, 输出均值256 TTFT（s） 100 0 0 1 1.5 2 2.5 3 3.5 4 4.5 5 1 1.5 2 2.5 3 3.5 4 4.5 5 请求率（req/s）请求率（req/s）

28. 效果：请求完成率实时对比完成请求比率随时间变化测试配置 DeepSeek-V3模型 FP8, TP8, H20 输入均值2k, 输出均值256 输入请求率=4.0 request/s semi-PD+SGLang结果 SGLang结果时间（s）

29. 03 面向华为昇腾的推理优化部署实践

30. 推理部署趋势的关键词关键词：超节点、大EP、长文本智能变化 ① 模型规模↑ Llama3系列：405B DeepSeek-V3：671B Kimi-K2：1T… ② MoE专家数目↑ Mixtral-8x7B：8个专家 DeepSeek-V3：256个专家 Kimi-K2：384个专家… ③ 上下文长度↑ 对话：<1k Test-time scaling [1] ：~8k Agent [2] ：>50k [1] DeepSeek team, “DeepSeek Technical Report”, arXiv preprint arXiv. 2412.19437 (2024). [2] Q. Wu et al, “AutoGen: Enabling Next-Gen LLM Applications via Multi-Agent Conversation”. arXiv preprint arXiv. 2308.08155 (2023). 推理部署 “超节点” 多卡间通信瓶颈需要超节点架构 “大EP” 专家拆分至不同卡实现高并发计算 “长文本” 多卡间通信瓶颈需要超节点架构

31. 昇腾怎么从能用到好用？能用好用 910B tokens/s/NPU 首个支持大EP 、PD 分离功能的国产芯片 700-800 增加15倍 1. 长文本支持仍有诸多挑战 Prefill阶段注意力计算量平方增长 50-60 实例推理离好用仍有距离 Decode阶段 Vector单元计算压力大 Attention和MoE 对计算访存分歧呈更大剪刀差集群推理 2. 超节点高性能、低灵活性 910C 大量定制优化，社区和学术界难以基于良好的软件 1943 tokens/s/NPU 基础自发开展创造 CloudMatrix 384 超节点规模和模型规模难以灵活匹配

32. 能用：性价比昇腾 vs 英伟达 1）性价比比肩英伟达；2）910B性价比不低于910C Method Batch Size KV Length TFLOPS TPOT Throughput Throughput Throughput per TPLOPS per TPLOPS DeepSeek (Blog) on H800 N/A 4,989 1979 (FP8) ~50.0 1,850 DeepSeek (Profile) on H800 128 4,096 1979 (FP8) ~50.2 2,325 SGLang (Simu. MTP) on H100 128 Max Power per Node (KW) Max Power per GPU(KW) 0.93 0.93 10-13 1.25-1.63 1.17 1.17 10-13 1.25-1.63 Tokens per J Tokens per J 1.48 1.48 1.86 1.86 4,000 1979 (FP8) ~55.6 2,172 1.10 1.10 10-13 1.25-1.63 1.74 1.74 CloudMatrix- 96 Infer 4,096 1504 (INT8) 49.4 1,943 1.29 1.29 15-16 1.87-2 1.03 1.03 Atlas 800I A2 (910B) - 626 (INT8) 100.0 766 1.22 1.22 5-6 0.63-0.75 1.21 1.21 -

33. 好用：长文本推理仍有诸多挑战长文本的需求：数据、应用与能力集群使高效长文本推理成为可能单Token的内存占用：约1MB *DeepSeek-V3，考虑激活存储复用推理能力具身智能回应用户前产生很长的内部思维链实例推理 Token存储（激活和cache）约占40% 模型权重约占60% 仅能支持4k左右上下文更多空间用于Token存储随着思考时间（思维链总长度）增加，强推理模型表现会持续提高 [1] 有长程记忆的模型通过与环境的交互，逐渐发展出新的认知能力 [2] 集群推理 [1] OpenAI. "Learning to Reason with LLMs." OpenAI, www.openai.com/index/learning-to-reason-with-llms/. Released 12 Sept. 2024. [2] Jiang, Xun et al. “Long Term Memory: The Foundation of AI Self-Evolution.” (2024). Token存储（激活和cache）约占95%！模型权重约占5%

34. 长文本场景带来的问题跃迁华为昇腾服务器推理部署最佳实践 Prefill阶段注意力计算：呈二次方增长思路：集群的多卡协作优势计算 MLA算子优化 MoE算子优化通信计算-通信重叠框架长文本场景的新挑战 P/D分离式系统上下文长度：2k~4k 序列并行引入权重和KV Cache通信思路：基于超节点优化并行和任务编排策略模型规模和集群规模匹配失衡、 Attention和MoE对计算访存需求失衡思路：利用UB搭建的微服务架构 >100k

35. 面向长文本场景的集群推理问题1 长文本下的计算问题：Attention成为瓶颈对标量核压力增加向量计算在昇腾芯片可能成为新瓶颈 Prefill 阶段Attention计算和上下文呈二次方随长度增加，标量计算对算子需求迅速增长，昇腾AIC、AIV算力悬殊问题凸显 450 400 Attention Feed-Forward 350 300 250 AIV算力紧张，如何协同AIC和AIV成为新问题 200 Time (ms) 150 100 50 0 -50 0 10 20 30 40 Context Length (K) 50 60 70

36. 面向长文本场景的集群推理问题2 长文本加剧KV Cache存储均衡问题，传输KV Cache成为新瓶颈不同卡KV Cache 的Placement 导致计算和存储均衡问题 R i Placement举例如下 KV Cache 第i条请求 … NPU0 KV Cache 0 NPU1 KV Cache 1 R 100 NPU 0 NPU 1 请求少，KV cache多请求多，KV cache少计算利用率不足 query KV Cache R 2 R 1 多卡间KV Cache 传输通信量大，如何掩盖KV Cache 传输延时存储空间不足计算过载延时增加存储利用率低 Attention GB量级传输长文本KV Cache拆分到多卡存储注意力计算时，若传KV cache则数据传输量大

37. 面向长文本场景的集群推理问题3 长文本场景加剧了集群推理中的资源匹配的难度如何灵活自适应匹配节点规模和模型规模注意力部分对计算需求高、MoE阶段对访存需求高复制高频专家 1 1个共享专家复制32份 + 256个路由专家 + 如何匹配注意力和MoE 所需计算资源 2 … N s 𝐾 𝑐𝑎𝑐ℎ𝑒 32个冗余专家 =320份专家权重 𝑄 𝑎𝑡𝑡𝑛_𝑚𝑎𝑝 𝑉 𝑐𝑎𝑐ℎ𝑒 专家并行EP=320（解码阶段），即单实例需要160张NPU 如何匹配？换个模型又该如何 MLA_1 (44.7%) 注意力部分计算富集：计算压力大 𝑖𝑛𝑝𝑢𝑡 Batch size 超节点CloudMatrix384，共384张NPU cache length 𝑤𝑒𝑖𝑔ℎ𝑡 𝑜𝑢𝑡𝑝𝑢𝑡 MoE部分显存需求富集：存储压力大 Batch size=32 Cache length=32k MLA_2 (40.6% )

38. 我们在昇腾基础软件上的技术积累计算：GEMM/Group GEMM 算子优化通信：计算通信重叠FlashOverlap  基于CCE（底层编程语言）实现更精细的计算、数据搬运和流水编排  联合昇腾高性能计算库catlass和通信库hccl完成实践  精细的L2->L1-L0数据搬运和复用策略  相比顺序执行性能提升高达1.35倍  GEMM算子相比aclNN优化性能提升高达1.5倍 Llama3-8B典型矩阵乘法形状相比aclNN提升高达1.5倍 GEMM 算子时间对比 [N=K=4096] aclnn infini speedup 0.6 1.60 1.47 1.50 1.44 1.41 0.4 1.50 1.47 1.40 1.31 0.3 1.30 1.22 1.20 1.19 1.14 0.2 1.06 0.1 1.08 1.06 1.00 1.00 1.00 1.10 1.01 1.00 1.02 1.02 0.99 0.90 0 M 1.50 0.5  基于控制信号实现计算和通信双流并行且解除数据依赖

39. 集群推理方法论输入输出模型规模芯片算力访存带宽显存容量节点规模软硬协同 𝑓 约束：满足SLO 目标：最大化并发图融合等价图替换计算通信重叠方式并行范式：EP/TP 通信 xPyD： PD实例配比框架

40. 长文本场景的集群推理整体方案思路计算、通信、框架设计实现通信/访存量降低和灵活资源匹配全局调度器 Prefill注意力计算量可表示为 NPU0 = R1 请求路由请求路由请求路由以全掩码注意力作为任务划分方式多个全掩码注意力任务分发至多卡计算 R50 … R80 R1 多卡计算Decode注意力仅传输激活而非KV cache + 对角线附近少量计算 … NPU1 NPU0 NPU0 NPU0 NPU0 NPU0 NPU0 NPU0 NPU0 计算：全掩码注意力任务分发提升卡内注意力计算效率注意力实例注意力实例（Prefill）注意力实例（Prefill）（Prefill）注意力实例注意力实（Prefill）例 MoE实例（Prefill）注意力实例注意力实例（Prefill）注意力实例（Prefill）（Decode）激活/KV cache传输激活/KV cache传输 UB 平面框架：以大算子为粒度的微服务架构实现注意力、MoE的计算需求和超节点规模灵活匹配 Prefill实例请求/KV cache路由 NPU0 NPU1 由路由保证卡间存储均衡减少KV cache动态传输通信：KV Cache Placement策略减少KV cache通信

41. 04 以有限算力架构释放终端应用潜能

42. 端侧应用落地迎接爆发亟需强推理能力云端协同释放算力，数十亿终端进入大模型时代基座模型预训练未来泛端侧应用需要>100tokens/s 推理能力泛端侧应用大模型推理性能需求模型微调/推理模型云端部署算力资源优化算力协同及数据返回 • • 经推测，GPT-4o/o1参数量超过200B 实际端侧应用需要4o/o1能力的模型实现100~1000 token/s 的推理性能基座模型及算力调用 GPT-4o/o1 (~200B+强化学习) 端侧协同推理 AI手机年出货 5.52亿台注2 端侧模型部署 AI PC年出货 1.02亿台注3 端侧智能机器人场景增量学习智能汽车年出货近5000万台注4 自动驾驶感知决策 >100 token/s [Tesla HW3] 无人机具身智能路径规划动作决策 >100 token/s >1000 token/s [Nature 2023封面文章] [Jim Fan, NV高级研究科学家]

43. 端侧大模型推理的效率挑战 ① 计算挑战 GPU 算力高计算快 ② 存储挑战 CPU 算力低计算慢云模型模型参数多 0.68s CPU GPU 0.15s 计算大模型 CPU速度比GPU速度慢4倍单处理器无调度低延时多处理器通信+调度 × 各部分计算延时占比 (Llama2-7B GPU16层，CPU16层) 延时端设备内存容量小 ③ 协同挑战 DeepSeek-R1模型约 617GB 参数内存相差 2个数量级单机内存仅12GB 无法在本地运行端侧内存容量与云模型参数量相差2个数量级 GPU Laptop CPU 多处理器协同计算需要复杂的通信和调度

44. 端侧大模型核心技术端侧应用智能：单用户、少请求计算挑战提升生成式模型的计算利用率存储挑战端侧存储难以容纳参数和中间变量协同挑战多处理器硬件资源协同处理投机解码等算法优化编译调度等系统优化模型轻量化设计模型卸载技术任务拆分与并行等异构计算优化 Speculative FlashAttention Decoding （NeurIPS 22）降低注意力的存储量和访存量 Transformer计算的必需算子（PMLR 23）推测解码利用小模型做串行生成、大模型并行验证实现2-3倍加速 AWQ KTransformers （MLSys 24 BP）通道维度权重激活数据均衡方案近无损W3A16量化较FP16有3倍加速（GitHub 25）针对DeepSeek- V3的专家卸载在单张4090上运行DeepSeek-V3 FlexGen PowerInfer （ICML 22）提出大模型卸载技术卸载模型权重和 KV cache 30B模型在16GB GPU上运行（SOSP 24）使用稀疏激活利用 GPU和CPU协同计算 FFN 在消费级台式机上，相较llama.cpp提升5 倍吞吐率 FlexInfer （EuroSys 25）引入基于虚拟内存的张量协调 CPU - GPU 资源用于 LLM 推理相比于mmap速度提升5倍端侧推理应用技术Milestone

45. 单用户下大模型端侧推理关键分析：单用户下大模型推理是底库很大的搜索分类问题单用户 Tokenize 少请求 Prompt Attention FFN Attention FFN Attention FFN 级联计算 where 每一层均是搜索过程 go do can I are good Output …… 数万规模的词表搜索底库（~3万）搜索分类 I 一个词 Attention FFN LM_head

46. 端侧推理引擎：SpecEE 核心思想：利用小参数的LLM作为推测模型缩减搜索底库单用户 Tokenize 少请求 Prompt Attention FFN Attention FFN Attention FFN …… Attention FFN 级联计算 where go do can I are good Output 搜索分类 Thank 推测模型数万规模的词表搜索底库（~3万） It I 底库缩减后词表搜索底库（~3）难度 I 一个词 LM_head

47. 端侧推理引擎：SpecEE 技术核心：基于缩减后搜索底库动态调整单用户下级联计算根据输入动态调整级联计算单用户 Tokenize 少请求 Prompt Attention FFN Attention FFN Attention FFN …… 级联计算计算 where go do can I good Output Attention FFN Thank are 推测模型数万规模的词表搜索底库（~3万） It I 搜索分类底库缩减后词表搜索底库（~3） I 难度一个词 LM_head

48. SpecEE 技术细节：如何高效动态调整级联计算算法：低开销高精度调整级联计算系统：动态调度引擎适配端侧部署 ①调整模型实现低开销词 1 Start 自适应调度引擎概率 pred=MLP(info) T’ = LocalResult 在线调度发生突变 0.5 弹性激活预测器 Correction Alg. pred >threshold 0 N 0 Y 8 16 24 层数 T’=T 20 Forward Y Early Exiting 线下调度 end logits=LM_head(X) T=GlobalResult ②修正算法实现高精度 √××√ 在线调度概率变化取代冗余特征 N 线下调度 16 19 环形队列存储前文早退位置 start 根据前文早退信息，动态调整预测器激活位置 0 5 10 15 20 25 30 根据统计数据，选取早退概率高的预测器 End 预测模型与修正算法双重保障实现低开销高精度引入自适应调度引擎实现弹性激活调整机制

49. SpecEE 结果：推进速度与精度的帕累托前沿 SpecEE 精度 # 速度更快 # 精度更高 llama.cpp 归一化加速比

50. 05 以大模型推理技术创新融合人工智能产业创新

51. 破解推理Scaling时代大模型推理系统的效率挑战端设备云平台优化目标：降低延时优化目标：满足用户延时要求，提升吞吐率核心特点：单用户、少请求核心特点：多用户、多请求重叠传输延时开销小规模负载计算（利用率： 50%→90%）协同挑战多处理器硬件资源协同处理存储需求（存储量 100GB→10GB）大规模负载并行计算计算挑战提升生成式模型的计算利用率满足用户目标延时调度挑战不同用户间资源竞争及延时需求存储挑战同时存储大量请求的KV cache 提升显存利用效率（利用率 70%→90%）

52. 推理系统上云打造云端AI产业生态创新引擎高效集群推理，加速大模型能力注入千行百业等近百家AI应用/企业排队入驻中徐汇模速空间算力生态平台北京海淀公共算力服务平台杭州市算力资源服务平台登上央视1套《新闻联播》投入运营云平台 semi-PD 投入运营投入运营 cloud.infini-ai.com 大模型服务平台全球首创第三代推理集群系统，推理性能行业第一

53. 推理系统入端释放智能终端应用潜能高效端侧推理，软硬协同加速下一代智能终端落地大模型推理引擎端到端性能提高 70% 提升提升 25%+ 70%+ 文生文大模型端模型文生图大模型面向应用场景的微调大模型多模态大模型面向各类智能终端的大模型推理引擎端软件 YOGA Pro 14 元启版自研端侧大模型推理芯片 3D堆叠 ThinkBook 14+ 元启版端设备 SpecEE Prefill Decode 多芯粒互联大模型处理器LPU 端芯片 “端模型+端软件+端IP”智能终端一体化解决方案全球首创推测性早退技术，AI PC推理速度行业第一 • 量产软件合作 • 签订战略合作备忘录 • 建立联合实验室 • 联合定义终端场景

54. 端侧实时守护云侧全局智能端设备云平台实时响应弹性扩展推理系统小规模负载计算传输延时开销协同多处理器硬件资源协同处理存储需求计算提升生成式模型的计算利用率存储同时存储大量请求的KV cache 大规模负载并行计算用户目标延时调度不同用户间资源竞争及延时需求提升显存利用效率

55. 端+ 云推理加速数量级降低大模型落地成本云平台端设备提高端侧硬件能效降低端侧模型参数量提升系统吞吐提高端侧硬件利用率降低请求延时 => 成本模型轻量化存储机制轻量化模型并行调度算法设计高精度模型算法设计硬件数据结构稀疏化剪枝数据表示低比特量化高能效架构前端编译多处理器协同后端算子硬件定制优化用户请求存储优化前缀缓存存储管理分页存储请求调度阶段处理模型并行模型切片计算图算子优化

56. 释放无穹算力，让AGI触手可及基础设施的“魔法” 1995 2025 让民用电走进让大模型成本 10000 个县镇 10000 倍下降

57.

58. THANKS 大模型正在重新定义软件 Large Language Model Is Redefining The Software