Workflow
SGLang
icon
搜索文档
超大模型推理加速2.18倍!SGLang联合美团技术团队开源投机采样训练框架
量子位· 2025-07-26 17:01
开源框架SpecForge - SGLang团队联合美团搜推平台、Cloudsway.AI开源专为超大模型设计的投机采样训练框架SpecForge [1] - 该框架基于Eagle3技术,是首个支持超大模型投机采样训练并开箱即用的框架,与SGLang推理引擎深度集成 [5] - 针对当前开源社区缺乏支持超大尺寸模型训练且与SGLang深度结合框架的痛点 [6] 技术特性 - 集成最先进的投机采样方法Eagle3,通过轻量级草稿模型预测目标模型token分布实现高接受率和性能提升 [7] - 原生支持主流模型架构包括复杂MoE层和Transformer变体 [7] - 采用FSDP和TP并行策略实现GPU集群高效扩展,显著降低大规模训练内存开销 [7][14] - 创新性封装训练时测试(TTT)架构,通过模拟多步生成增强模型健壮性 [9] - 提供在线与离线双重训练模式,动态调整隐藏状态收集策略 [10][17] 性能表现 - 在320K样本数据集上为LLaMA 4训练的草稿模型实现2.18倍推理加速 [15] - 在MT-Bench等行业标准基准测试中表现出色,验证与Eagle3架构的兼容性 [15] - 通过bench_speculative脚本可针对不同硬件调优出最佳性能参数 [16] 应用场景 - 适用于Kimi K2、Qwen Coder等超大型开源模型的推理效率提升 [4] - 在线模式适合快速实验和存储有限场景,离线模式保证实验可复现性 [17] - 未来计划支持更多模型架构包括Kimi K2、Qwen-3 MoE及视觉-语言模型 [22] 资源获取 - GitHub仓库提供完整源代码包括TTT实现细节 [20] - Hugging Face提供LLaMA 4 Scout和Maverick预训练模型 [20]
AI Infra 工程师们如何应对大模型流水线里的“暗涌”?
AI前线· 2025-06-26 13:44
大模型基础设施工程挑战 - 训练任务中断是万卡集群的普遍现象,GPU错误率导致每天必然出现不同故障,同步训练特性使单卡故障可导致整个训练停滞[4] - 硬件故障定位困难,早期依赖人工二分法排查准确率低,误判会导致任务反复重启失败,涉及网络系统、交换机、光模块等多环节问题[4][5] - 损失函数异常飙升成因复杂,需算法团队与Infra团队紧密协作排查硬件差异、算法缺陷或代码错误[7] 推理部署核心问题 - 运行时错误和性能问题是用户最高频反馈,前者涉及显存分配溢出等配置错误,后者常因环境差异导致测试结果无法复现[6] - KV缓存内存分配不足会降低推理批次规模,预填充到解码各环节异常均可能引发延迟偏高或吞吐量下降[7] - 性能剖析工具如PyTorch Profiler和GPU监控系统对定位CUDA算子执行问题至关重要,人工排查效率低下[12] 工程流水线管理难点 - 并行策略兼容性挑战显著,如Multi Token Prediction与数据并行注意力机制存在代码耦合问题,需经历重构阵痛期[8] - 新特性与旧算法冲突时采用分版本独立启用策略,通过持续迭代逐步解决分支冲突,仅靠CI流水线保障不足[9] - 研发环节受资源限制,CI测试无法模拟万卡规模问题,功能更新导致MFU下降时需依赖二分法回退测试定位[10] 成本优化关键技术路径 - MoE架构专家并行可减少单卡权重负载,释放显存用于KV缓存,模型设计与部署需联合规划[14] - 推理缓存策略优化涉及CPU内存KV缓存驱逐机制,需针对Agent工作流等场景定制调度算法[15] - GPU利用率提升依赖计算通信重叠技术,如双批次重叠策略可掩盖通信开销[16] - 大型机柜整合方案通过NVLink拉远技术将跨节点通信带宽提升近节点内水平,显著改善MFU[18] 开源项目运营挑战 - 社区运营需构建用户反馈与开发者贡献的良性循环,超越代码能力成为项目持续进化核心[21] - 平衡公司工作与社区投入依赖开源热情,技术监督委员会运营和全球影响力建设需从零起步[20] - 硬件厂商锁定效应构成壁垒,如昇腾开源项目初期被认知为仅支持特定硬件[21] 异构计算发展趋势 - 预填充与解码阶段硬件需求分化推动异构部署,前者需要高算力芯片后者侧重显存管理[24] - GPU虚拟化依赖厂商支持,英伟达MIG基于SR-IOV技术实现设备级虚拟化资源分配[23] - 智能调度混部技术成熟使CPU/GPU混合部署成为基础设施演进方向[25]
o3-pro通关“推箱子”,人类怀旧小游戏成了大模型新Benchmark
量子位· 2025-06-16 12:50
经典小游戏成为新Benchmark - o3-pro突破推箱子第六关上限并通关所有关卡 表现远超benchmark原有标准[2][8] - 俄罗斯方块测试中o3-pro得分无上限 成绩较前SOTA模型o3直接翻倍[3][14] - 测试采用迭代交互循环模式 结合智能体框架的感知/记忆/推理模块提升稳定性[18][20] Lmgame基准测试体系 - 包含6款游戏:推箱子(1989版)、俄罗斯方块、2048、糖果传奇、马里奥兄弟、逆转裁判[6][18] - 各游戏评估标准差异化:推箱子计算通关关卡数 俄罗斯方块按方块数+10倍消行数计分[7][13][24] - 测试框架开源 支持动态更新游戏关卡(如推箱子从4关扩展至50关)[9][23] 模型性能对比 - 推箱子历史排名:o3-pro > o3 > o4-mini > DeepSeek-R1(0528版)[10] - 俄罗斯方块历史排名:o3-pro > o3 > R1 > o4-mini 与推箱子排名存在差异[14] - o3-pro操作耗时显著 单步决策需数分钟[17] 研究团队背景 - 项目来自UCSD Hao AI Lab 负责人张昊(卡内基梅隆博士)曾参与创立LMSYS[28][29][30] - 实验室获谷歌/英伟达资助 2024年4月接收DGX B200捐赠[34] - 开源项目FastVideo获GitHub 1 5k星标 团队同时开发大模型竞技场等知名框架[32][31] 行业应用延伸 - Gemini模型2024年5月成功通关宝可梦·蓝 谷歌CEO公开宣布成果[26][27] - 测试方法受业界认可 网友认为比大模型竞技场更适合评估模型能力[5]
o3-pro通关“推箱子”,人类怀旧小游戏成了大模型新Benchmark
量子位· 2025-06-16 12:49
经典小游戏成为大模型Benchmark - 核心观点:经典小游戏如推箱子和俄罗斯方块被用作测试大模型性能的新基准,o3-pro模型在该基准上表现优异,突破了原有上限 [1][2][6] - o3-pro在推箱子游戏中通关所有关卡,远超之前仅能完成第六关的benchmark上限 [3][7][8] - 在俄罗斯方块中o3-pro表现持续强劲,游戏需强行终止,其得分计算方式为放置方块数量与清除行数10倍之和 [13][14] - 与前SOTA模型o3相比,o3-pro成绩直接翻倍 [3] Lmgame Benchmark框架设计 - 测试框架包含六款游戏:推箱子、俄罗斯方块、2048、糖果传奇、马里奥兄弟和逆转裁判 [18] - 采用迭代交互循环模式:游戏状态持续反馈给模型,模型生成动作后获得奖励并更新状态 [18] - 引入智能体框架辅助,包含感知、记忆、推理模块,并通过提示标准化确保评估稳定性 [20] - 各游戏评价标准差异化:马里奥兄弟按移动距离、2048按合并方块值对数、糖果传奇按消除数量、逆转裁判按正确动作计数 [24] 模型性能对比与开源生态 - 推箱子历史排名:o3-pro > o3 > o4-mini > DeepSeek-R1(0528) [10] - 俄罗斯方块历史排名:o3-pro > o3 > R1 > o4-mini(与推箱子排名部分倒置) [14] - 测试基准动态更新,GitHub仓库半月前仅四关,原版推箱子含50+关卡 [9] - 项目完全开源,可自行下载测试模型性能 [23] 研究团队背景 - Lmgame由UCSD Hao AI Lab开发,负责人张昊为卡内基梅隆博士、伯克利博士后,曾参与创立LMSYS(大模型竞技场开发方) [28][29][30] - 实验室获谷歌/英伟达资助,2024年4月获赠英伟达DGX B200服务器 [34] - 其他开源项目FastVideo(视频生成加速框架)获GitHub 1.5k星 [32]
SGLang 推理引擎的技术要点与部署实践|AICon 北京站前瞻
AI前线· 2025-06-13 14:42
SGLang 开源推理引擎发展现状 - 截至2025年6月 GitHub Stars达15K 月均下载量突破10万次 [1] - 已被xAI Microsoft Azure NVIDIA AMD LinkedIn 美团等行业巨头采用 [1] - 成为DeepSeek R1官方推荐推理引擎 并实现首个完全开源的大规模专家并行部署方案 [1] 核心技术优势 - 采用PD分离架构控制尾延迟 推测解码提升Token生成速度 KV缓存落盘优化显存 [2] - 实现RadixAttention Overlap Scheduling等高效架构设计 复现PD分离 大规模EP等前沿技术 [3] - 支持离线批处理最大化GPU利用率 线上推理优先保障Token生成速度的差异化部署策略 [4] 并行部署技术挑战 - 专家并行实现中面临通讯与Prefill/Decode传输KV缓存的时间重叠问题 [4] - 网卡资源争抢 CPU负载过大 Python GIL锁释放不及时等工程挑战突出 [4] 社区生态建设 - 开源模式吸引广泛参与 技术分享增强社区认同感 [5] - 超过100k显卡规模的工业部署经验反哺技术演进 [5] 关键技术解析 - PD分离使Decode延迟均匀稳定 允许采用不同并行策略提升资源利用率 [6] - 推测解码通过隐藏层信息一次预测多个Token 显著提升Decode速度 [6] - KV缓存落盘将历史上下文存储至大容量设备 避免重复Prefill计算 [6] 部署实践洞察 - 参数配置调试是影响上线效率的关键环节 需精细化优化而非依赖"开箱即用" [7] - 模型规模持续扩大背景下 多GPU与高效并行策略是实现高性价比部署的必经之路 [7] 行业活动预告 - AICon全球人工智能开发与应用大会将深入解析大模型推理关键技术 [2][7] - 聚焦AI Agent构建 多模态应用 大模型推理优化等前沿议题 [7]
SemiAnalysis:AMD vs NVIDIA 推理基准测试:谁赢了?--性能与每百万令牌成本分析
2025-05-25 22:09
纪要涉及的行业和公司 - **行业**:数据中心AI GPU行业 - **公司**:AMD、NVIDIA 纪要提到的核心观点和论据 性能表现 - **不同工作负载下性能差异**:对于直接拥有并运营GPU的超大规模企业和公司,某些工作负载下英伟达每美元性能更优,其他工作负载中AMD更佳;使用短期至中期租赁服务的客户,通过Neocouds平台租用显卡时,英伟达始终在每美元性能上胜出,原因是缺乏提供AMD M00X、M25X的Neocouds服务商,导致其租赁市场价格居高不下,而英伟达有数百个Neocouds提供相关显卡,租赁市场竞争激烈[6][7]。 - **各型号GPU性能对比** - **M00X**:在大多数测试场景中无法与H200竞争,但对于Lama 05B和DeepSeekv 70B,在绝对性能和每美元性能上击败H100[12]。 - **M25X**:本应是H200的竞争对手,但因发货延迟,多数客户选择B200;在部分场景如高并发下的Llama 70B和Llama 05B测试中有优势,但整体性能受发货时间影响[8][13][74][86]。 - **B200**:软件支持仍未完善,但对于当前可部署的负载和模型占据绝对优势,M25和H200性能远不及它[13]。 - **H200**:解决了H100容量短板,在多数测试中表现出色,采用TensorRT - LLM的H200性能优势明显[22][76][88]。 市场份额 - AMD在数据中心AI GPU市场份额自202年第一季度起持续增长,但2025年第一季度因英伟达推出Backwe架构产品,而AMD对标方案要到2025年第三季度面世,市场份额相应下滑,预计2025年第二季度继续下降,不过随着M55X推出和软件改进,有望在年底或明年初重新夺回部分份额[26][27]。 基准测试方法论 - **强调在线吞吐量与延迟关系**:为接近现实推理工作负载,强调分析特定配置下在线吞吐量与每位用户端到端延迟的关系,而非传统离线基准测试,通过增加并发用户数测量延迟上升,得出反映实际运营和用户体验的吞吐量指标[30][31]。 - **模型选择**:针对现实世界生产负载的密集架构和稀疏混合专家(MoE)架构模型进行测试,分别选择Lama 70B、Lama 05B和DeepSeekV 70B作为代表[45][46][47]。 - **输入/输出令牌长度**:测试三种不同输入输出令牌长度组合,分别代表摘要、翻译或对话、推理密集型任务,以全面了解模型和硬件在不同推理工作负载下的性能[49][50][51][52]。 - **推理引擎**:针对不同模型选择不同推理引擎,如Lama 70B和05B选vLLM,H200平台额外评估TensorRT - LLM;DeepSeek 70B选SGLang[54][55][59][60]。 - **并行策略**:系统性评估每种GPU架构和测试场景下所有可行的张量并行(TP)配置,测量吞吐量和延迟确定最优并行策略[61][62]。 成本分析 - **总拥有成本(TCO)**:AMD的M00X和M25X GPU通常每小时总成本低于NVDA的H100和H200 GPU,但在不同延迟和模型测试场景下,性价比表现不同[110][111]。 - **租赁成本**:在GPU租赁市场,AMD因供应有限、市场竞争不足,租赁价格被抬高,整体成本竞争力削弱,英伟达始终在每美元性能上优于AMD;为使AMD GPU在租赁市场与英伟达竞争,M00X和M25X在不同工作负载下需达到特定租赁价格[158][159][160][167][170][171]。 其他重要但可能被忽略的内容 - **生产延迟问题**:AMD的M25X发货延迟,英伟达的GB200 NVL72也因集成NVLink背板挑战和缺乏调试工具遭遇严重延误[24][25]。 - **软件支持问题**:B200和GB200软件支持不完善,如FP8 DeepSeek V在相关推理框架上无法正常运行;AMD的M55X因量产机型未上市、存在未修复缺陷未进行测试[13][172][174]。 - **基准测试阻碍**:服务框架调优参数标志多、文档不足,代码更新快,无法跨机器并行实验,AMD维护独立代码库分支和配置等问题导致基准测试耗时且困难[182][184][185][186]。 - **持续集成测试问题**:AMD的SGLang持续集成(C)测试覆盖率远不及NVDA,有数十项单元测试缺失,影响软件质量和开发者体验[188][189]。 - **模型准确性问题**:AMD在夜间准确性测试方面此前为零,25%的测试模型在AMD平台上准确性测试失败,同一模型在ROCm上运行答案不如在NVDA上智能[194][195]。
腾讯、华为、微软、阿里专家齐聚一堂,共谈推理优化实践 | AICon
AI前线· 2025-04-23 15:28
大模型推理性能优化技术方向 - 当前优化围绕模型优化、推理加速与工程优化三大方向展开,包括模型量化、剪枝与蒸馏等手段降低计算复杂度,例如DeepSeek-R1-Distill-Qwen-32B采用蒸馏策略显著压缩资源开销 [1] - 依托SGLang、vLLM等高效推理引擎提升生成速度与系统吞吐能力,同时结合实际业务场景优化GPU配置与并发策略 [1] 腾讯混元AngelHCF框架实践 - 腾讯推理架构师向乾彪将分享混元大语言模型推理加速框架AngelHCF的优化实践,该框架在算子设计、通信优化和架构调整方面取得显著成本与性能优势 [1] - 专题演讲将重点解析混元Turbos Hybrid结构下的性能突破路径,展示腾讯在大模型推理加速领域的前沿实践 [2] 华为昇腾推理技术优化 - 华为高级开发工程师张君将探讨昇腾平台在计算、内存及通信瓶颈的解决方案,包括混元模型结构创新、Kernel与显存优化细节 [3] - 针对万亿参数级MoE模型提出混合切分策略、模型压缩和PD分离部署措施,通过智能调度与计算通信重叠提升推理效率 [3][4] 微软KV缓存优化技术 - 微软亚洲研究院姜慧强聚焦长文本推理挑战,围绕KV缓存生成、压缩与检索环节优化,提出动态稀疏注意力等创新方案 [5] - 将展示SCBench基准测试工具对比常规优化方法与KV缓存策略的性能差异,分析各大LLM供应商技术差异 [7] 阿里云跨层优化实践 - 阿里云技术专家李元龙提出从模型层、框架层到算子层的协同优化策略,利用昇腾硬件加速库ATB和图编译技术TorchAir实现性能跃升 [6] - 动态批处理技术与前沿融合算子设计案例展示如何最大化硬件资源效率,系统解析Transformer前向传播核心流程的优化空间 [8][9] AICon大会技术亮点 - 大会将涵盖多模态、Agent、端侧智能等前沿技术,包括跨层协同优化策略与动态计算图等突破算力瓶颈的方案 [10] - 50+行业专家将解析大模型最新进展,涉及AI原生产品落地、多模态训练及硬件终端应用场景等11个细分议题 [11]
与 00 后开源者聊 DeepSeek 开源周:一直开源最强模型,可能是不想赚钱,也可能是想推动更大变化丨开源对话#2
晚点LatePost· 2025-02-27 22:03
开源策略与趋势 - DeepSeek宣布"开源周"计划,连续5天开源5个代码库,包括训练与推理工具,比技术报告和模型权重更深度[5] - 开源正成为行业趋势,部分原闭源公司开始发布首批开源模型,OpenAI CEO称"不开源是站在历史错误一边"[5] - DeepSeek通过详细技术报告(如V3达50多页)建立行业声誉,V3作为基座模型涵盖预训练、微调等完整流程[13][15][17] 开源技术层次 - 大模型开源分为四个层次:技术报告、模型权重(HuggingFace发布)、推理框架(如vLLM)、训练框架(如字节Verl)[19][26] - vLLM推理框架GitHub星数近4万,有840多位贡献者,基于PagedAttention论文优化[20][25] - 训练框架开源较少,因涉及复杂代码规范,字节开源的Verl框架支持强化学习算法如PPO和分布式策略[26][27] 工程优化与效率 - DeepSeek创新聚焦效率提升:V3采用多令牌预测、FP8低精度训练、优化流水线并行减少闲置计算单元[40] - FlashMLA开源项目实现算子层优化,类似FlashAttention通过GPU指令重组提升矩阵运算效率[45][46][48] - 工程实现难度高,如在线训练需同时处理生成与模型更新,对底层框架能力要求极高[49][50][51] 商业考量与行业影响 - 开源策略差异源于商业模式:非盈利机构Ai2开源最强模型+数据集,商业公司可能保留核心模型[54][56] - 开源可能重构行业生态,成为技术标准,但未来AI能力极强时开源最强模型或引发滥用风险[55][59] - 公司转向开源需额外投入:代码规范(如阿里代码规约)、适配外部框架(如ESFT适配耗时一周多)[36][34][35] 社区与开发者价值 - GitHub社区活跃度可通过星数(vLLM近4万)、Issues数(数千)、PR数(数百)衡量[20][25] - 开源项目需持续维护,如DeepSeek计划整合5个库功能并修复潜在bug[52] - 开发者诉求多样,包括支持FP8精度、NPU芯片适配等,反映实际应用场景需求[52]