标题关于大模型训练和推理的一些框架最近不少朋友私信问我说现在大模型相关的框架满天飞今天冒出来一个vLLM明天又火了一个DeepSpeed后台还有个叫LangChain的东西也在刷存在感。光看名字就晕了更别说搞清楚它们到底是干嘛的。我当年入坑的时候也这样今天聊点实在的把大模型训练和推理阶段常用的框架梳理一遍讲清楚它们各自解决什么问题、相互之间是什么关系以及你该怎么选。这篇文章适合刚接触大模型、正准备搭建训练或推理环境以及在框架选型上犹豫不决的开发者。我尽量不堆名词用大白话把原理和实操经验讲透。1. 先看清全局训练和推理框架到底在解决什么问题在聊具体框架之前有必要先想清楚一个事情我们折腾这些框架到底是为了解决什么痛点大模型从无到有本质上是两段工作。第一段是训练也就是把海量文本数据喂给一个巨大的神经网络让它通过反向传播算法不断调整参数最终形成“智能”。第二段是推理也就是把训练好的模型部署到服务器上接收用户的请求实时生成回答。听起来很简单但实际做起来这两段工作都会遇到极其恶心的工程问题。训练阶段的核心痛点说白了就是“装不下”和“算不动”。一个动辄几百亿参数的模型显存根本放不下就算放得下单张显卡算到天荒地老也训练不完。这时候就需要各种并行策略把模型切到多张卡上让它们协同工作。但多卡协同涉及通信开销、显存管理、梯度同步随便哪个环节出错训练就崩了。这些脏活累活就是训练框架要帮你解决的。推理阶段的核心痛点则变成了“响应慢”和“吞吐低”。训练好的模型你得让它跑起来服务用户但大模型的推理是自回归式的一个token一个token地往外蹦天然就慢。而且传统深度学习推理框架比如TensorRT是为固定尺寸的CNN模型设计的对大模型这种动态、变长的生成式推理支持得很差。再加上GPU显存带宽有限如果每个请求都单独加载一遍模型权重并发一高服务器直接就瘫了。推理框架要解决的就是如何让模型在GPU上跑得更快、更稳、并发更高。所以你看训练和推理虽然都叫大模型框架但解决的是完全不同的问题。训练框架比的是谁能让几千张卡训练得更稳定、效率更高推理框架比的是谁能让模型响应更快、吞吐更高、显存占用更少。理解了这一点再去看看这些框架你就能很清楚它们各自的价值在哪。2. 训练框架的主力阵容DeepSpeed、Megatron-LM与PyTorch生态2.1 从PyTorch说起为什么大家都站在它的肩膀上现在市面上几乎所有主流大模型训练框架底层都是基于PyTorch构建的。这并非偶然。PyTorch的动态图机制让研究者可以非常灵活地定义模型结构不用像TensorFlow 1.x时代那样先构建静态图再执行。对于大模型这种结构复杂、经常需要修改的研究场景这种灵活性太关键了。但PyTorch本身只是一个深度学习库它提供了自动求导、张量计算、神经网络层这些基础能力。当你只有一张卡模型也不大的时候用PyTorch原生API就可以搞定训练。问题在于一旦模型超过单卡显存你就需要额外的工具来处理“如何在多卡间切分模型、如何同步梯度、如何节省显存”这些问题。PyTorch自带了一个叫DistributedDataParallelDDP的工具它能实现数据并行——就是每张卡都放一份完整的模型然后喂不同的数据最后同步梯度更新。但DDP只解决了数据并行的问题模型还是得完整放进一张卡里对于大模型还是无能为力。所以我们就需要更高级的训练框架来补足这些短板。2.2 DeepSpeed训练优化中的多面手DeepSpeed是微软开源的一套深度学习优化库。我用它训练过不少模型最大的感受就是“显存优化手段极其丰富”。它有一个核心特性叫ZeRO零冗余优化器思路非常巧妙既然一个模型参数在训练过程中需要保存优化器状态、梯度、参数本身这三份数据而这三份对于每张卡来说都是完整副本那为什么不让每张卡只存一部分用的时候再通信取回来呢这种“存零头、用时再聚合”的思路硬生生把原来需要显存的地方省出了一个数量级。举个例子训练一个70亿参数的模型如果用普通的DDP方式光参数、梯度和优化器状态就要占掉好几百GB显存想都不敢想。但用DeepSpeed的ZeRO Stage 3你可能只需要8张80GB的A100就能跑起来了。除此之外DeepSpeed还提供 offload 功能可以把优化器状态甚至参数暂时挪到CPU内存里进一步降低显卡显存压力。对于个人开发者只有一两张显卡的情况这个功能几乎是救命稻草。不过DeepSpeed也不是银弹。它的配置项非常多什么zero_optimization、gradient_accumulation_steps、train_batch_size这些稍不留神就配置错了。我自己调试的时候经常因为train_batch_size没算对导致OOM。而且它和不同版本的PyTorch、Transformers之间有兼容性问题升级版本的时候经常得一起升。2.3 Megatron-LM大集群训练的工程天花板如果说DeepSpeed是灵活多数派那Megatron-LM就是针对超大规模训练的重武器。它是英伟达开源的专门为几千张卡的集群训练设计。Megatron有一套自己的张量并行和流水线并行实现在集群环境下的通信效率优化得非常好。所谓张量并行就是把一个Transformer层里的矩阵运算拆成多个小块让不同的卡分别计算再拼起来流水线并行则是把网络的不同层分配到不同的卡上数据像流水线一样依次经过。这套东西听起来简单但工程实现极其复杂涉及通信原语、显存调度、负载均衡各种细节。所以业内普遍做法是DeepSpeed和Megatron混合使用——用Megatron处理模型切分的逻辑用DeepSpeed的ZeRO处理优化器状态和数据并行。HuggingFace的Megatron-DeepSpeed就是一个现成的整合方案我自己跑实验的时候也基本是在这个基础上改。那么问题来了我一个小团队就几张卡有必要上Megatron吗我的经验是没必要。Megatron的配置复杂度比DeepSpeed还要高一个档次而且它更倾向于为固定大小、固定结构的模型服务优化。如果你的模型结构经常变化那在Megatron上改代码的成本会让你怀疑人生。建议单机多卡、模型参数量在百亿级别以下的时候把DeepSpeed吃透就够了。2.4 PyTorch原生的FSDP大模型训练的又一选择除了DeepSpeed和MegatronPyTorch这两年也发布了官方原生的FSDPFully Sharded Data Parallel。它的设计思路其实和DeepSpeed的ZeRO Stage 3非常接近也是把参数、梯度、优化器状态分片到不同的显卡上。区别在于FSDP是PyTorch原生的所以它跟torch.nn.Module的结合更自然代码侵入性更低。你只需要把原先的DDP包装改成FSDP包装很多代码几乎不用动。我在实际使用中对FSDP的体验是它在单机多卡场景下的表现其实挺惊艳的性能不比DeepSpeed差而且因为少了一层第三方库的封装出问题的时候排查起来更“贴近底层”。不过FSDP也有一些限制比如它对模型结构和动态图的支持不如DeepSpeed那么灵活某些需要自定义切分策略的场景下DeepSpeed还是会更顺手。所以我的建议是如果你是PyTorch的重度用户且主要跑单机多卡训练可以优先尝试FSDP因为它更干净、更原生在社区的新版本迭代里也很活跃如果你的目标是做大规模集群训练或者需要用到DeepSpeed独有的某些高级特性比如offload到NVMe那还是老老实实选DeepSpeed。3. 推理框架的应用主力vLLM、TensorRT-LLM、SGLang和其它选择模型训完了接下来就是把它跑起来服务用户。跟训练相比推理阶段要考虑的东西其实是反过来的模型参数已经固定不变了这时候框架拼的就是谁能把模型塞得更紧、算得更快、并发撑得更高。3.1 vLLM我目前最常用的推理框架先说vLLM这也是我目前最推荐的入门推理框架。它开源之后迅速成了大模型部署的事实标准之一GitHub星标涨得飞快。vLLM的核心优势在于第一它实现了一个PagedAttention机制可以把显存里的KV Cache像内存分页一样动态管理避免传统方式里因为预分配导致的浪费。第二它内部实现了连续批处理continuous batching不用等一个请求完全生成完再处理下一个而是可以在生成过程中不断插入新请求充分利用GPU算力。用vLLM跑起来一个模型非常简单只需要几行代码。如果你只是想快速验证模型效果直接用官方提供的命令行就可以起一个OpenAI兼容的API服务。我经常是先在本地的几张卡上用vLLM把模型部署好然后写个脚本发几个请求测试输出质量和吞吐确认没问题再放到正式环境上。vLLM有一个config文件里面可以配置很多推理参数比如最大输入长度、采样策略、tensor parallel size等等。对于大部分场景你只需要关注两个维度一个是模型大小和显存的匹配关系另一个是并发请求量的预估据此调整gpu_memory_utilization和max_num_seqs这两个参数。前者决定了缓存KV Cache能占多少显存后者决定了batch的最大并发度。3.2 TensorRT-LLM追求极致性能时的第一梯队如果说vLLM是“方便好用”那TensorRT-LLM就是“极致压榨”。它是英伟达推出的推理框架基于TensorRT做深度优化能对模型进行编译、量化、层融合等一系列操作。简单说它能把模型的计算图优化到极致推理延迟能做到最低吞吐能做到最高。但是它有个明显的缺点——使用门槛比较高。TensorRT-LLM需要你先将模型转换为TensorRT的engine文件这个过程包含图优化和量化校准可能耗时很长时间而且一旦模型结构或推理配置有变化整个转换流程就得重跑一遍。另外它对HuggingFace模型的支持虽然一直在完善但总有些“水土不服”的情况需要自己调试。所以我个人的习惯是如果你的业务就是追求极致的推理性能和成本优化且模型相对固定、不需要频繁更新那花时间搞定TensorRT-LLM是值得的如果你处于快速迭代阶段还是先用vLLM把业务跑起来更务实。3.3 SGLang在隐性推理能力和复杂场景上更具优势SGLang是一个相对较新的推理框架它的定位很有意思主打的是高性能复杂推理场景。SGLang对结构化输出和复杂提示词的处理更优秀并且支持一些新兴的推理技巧比如压缩上下文、并行解码等。如果你做的是Agent类应用或者需要频繁与外部工具交互、执行复杂逻辑那SGLang比vLLM在这些高级特性上更占优。我在一些多轮对话和代码生成任务中对比过两者的表现vLLM在常规场景下够用但SGLang在长上下文场景里对显存的管理更精细响应速度也相当不错。不过SGLang的社区规模和成熟度目前还不如vLLM用的时候遇到问题可能需要自己翻源码排查。3.4 其他值得留意的推理引擎除了上面三个还有一些值得留意的推理引擎。比如HuggingFace的Text Generation InferenceTGI它是HuggingFace自家推出的推理服务和Transformers库的兼容性最好在HuggingFace生态里使用起来最顺手。还有针对特定硬件的方案比如英伟达的FasterTransformer已被TensorRT-LLM整合、针对苹果芯片的MLX、针对CPU的llama.cpp等等。llama.cpp让我印象很深它能把模型量化后在纯CPU机器上跑起来虽然速度慢但胜在随处可用、零门槛适合拿来研究模型行为特性。整理一张表格让大家直观感受一下框架核心优势适用场景上手难度vLLM吞吐高、部署快、生态成熟通用大模型在线服务简单TensorRT-LLM延迟最低、极致性能模型相对固定、追求极致性能的线上生产较复杂SGLang复杂推理、结构化输出、高级特性Agent应用、复杂逻辑推理中等TGI与HuggingFace生态无缝集成HuggingFace用户快速部署简单llama.cpp轻量、无GPU依赖本地CPU推理、边缘设备简单4. 微调与对齐场景LoRA训练和Agent框架的关键配套现在跑大模型很少有人直接从头预训练一个模型更常见的做法是拿一个大模型做微调Fine-tuning或者对齐Alignment让它适配特定的领域或任务风格。在这个环节框架的作用也相当关键。4.1 LoRA训练用极低的成本微调大模型先聊LoRALow-Rank Adaptation。它的核心思想是在训练大模型时冻结原始模型参数不动额外在模型的某些层旁边加一组低秩矩阵。训练的时候只更新这些低秩矩阵大大减少需要训练的参数量。举例来说一个70亿参数的模型全量微调要更新70亿个参数显存占用巨大但用LoRA可能只需要更新几千万个参数显存占用一下降到了原来几分之一甚至更低。LoRA训练目前已经跟训练框架紧密整合在一起。最常见的技术栈是用PEFTParameter-Efficient Fine-Tuning库定义LoRA配置用Transformers库加载模型和数据用DeepSpeed或FSDP来支撑多卡训练。这套组合拳是如今大模型微调的“标配动作”。如果你想用LoRA微调一个本地模型我建议直接用这种标准化路径不要自己造轮子。我个人在LoRA训练中踩过的坑主要有两个。一是Rank值的设置Rank太小会限制模型的学习能力Rank太大又容易过拟合且占显存通常从8、16、32这几个值开始实验比较稳妥。二是目标模块的选择LoRA默认通常加到query和value层上但如果任务比较难有时还需要加到key和output层上需要根据实际效果调整。4.2 Agent框架让大模型在推理中会使用工具除了传统微调现在大量应用其实是大模型外部工具的Agent模式。大模型负责理解用户的意图、拆解任务、生成决策Agent框架则负责让模型真正去调用工具、访问外部知识库、执行代码。这类框架非常多从最著名的LangChain到AutoGPT、MetaGPT再到各大厂商自家的API工具调用方案。从技术实现角度看Agent框架本质上是在大模型的推理循环外面包了一层“工具调度系统”。它会把用户的请求传给模型让模型决定需要调用哪个工具、传什么参数然后框架负责实际执行工具并返回结果再把结果交给模型做下一步决策。这个过程反复迭代最后生成完整的回答。这套东西和大模型推理框架之间的关系其实非常紧密。Agent应用的特点是高并发、短上下文、频繁的工具调用对推理引擎的稳定性和吞吐要求非常高。我做过一个实际项目用vLLM部署了一个模型来支撑一个Agent服务刚开始发现只要工具调用一多推理服务的并发就上不去后面把vLLM的最大并发数调大、调整了KV Cache的复用策略之后才有明显改善。所以如果要做Agent务必把底层推理框架的性能参数调优也纳入考虑。5. 框架选型的理性建议从场景和资源出发做决策聊到这里你应该发现了大模型训练推理框架的选型本质上没有一个“最好”的答案只有“最合适”的方案。我根据自己实际跑过的场景梳理一套选型的思路供你参考。5.1 个人开发者和实验室场景如果你只有一两张消费级显卡比如RTX 4090或A6000主要目的是跑实验、做验证、写论文那我的建议最简单训练用PyTorch DeepSpeed就好最多再加上FSDP做对比实验推理用vLLM就足够了。这套组合的社区资料最全出问题能搜到大量现成的解决方案。消费级显卡的显存有限建议把DeepSpeed的CPU offload和量化技巧学好能帮你在有限的硬件上跑起更大的模型。5.2 创业团队和中小型业务团队如果你的团队要搭建一个面向真实用户的模型服务而且业务有一定的并发压力我的建议是训练阶段继续沿用DeepSpeed FSDP的组合保持模型迭代的灵活性推理阶段则要精细化一些优先用vLLM把服务跑稳定监控好显存、吞吐、延迟这几个核心指标。如果后面发现延迟成为瓶颈再考虑用TensorRT-LLM做专项优化。另外一定要把量化方法比如AWQ、GPTQ纳入考察同样一张卡4 bit量化后能撑起的模型大小和并发数会给你惊喜。5.3 大模型原生业务和资源充足的团队如果你的团队资金雄厚拥有几十上百张卡而且业务对性能有极致要求那就值得在训练阶段上Megatron-DeepSpeed在推理阶段上TensorRT-LLM和SGLang的组合拳。对这种情况我反而会提醒一句把时间花在业务需求理解上而不是一味追求新框架。大规模集群的运维复杂度已经很高了框架用得越复杂隐性维护成本就越高。很多时候一个从“够用”出发的简单方案反而比一个从“炫技”出发的复杂方案更能带来商业价值。5.4 几个“避坑”心得最后分享几个我在实际选型和使用中总结出来的经验希望能帮你避开一些坑。第一个是关于版本管理的。大模型框架的迭代速度极快而且框架之间往往存在依赖关系——比如Transformers版本会影响PEFTPEFT会影响DeepSpeed的兼容性。我强烈建议你现在就用conda或者venv把不同项目的环境彻底隔离并且把requirements.txt或者environment.yml文件严格记录好。不要相信“先升级一下试试”很多时候一升全部就要重新调损失的时间成本非常大。第二个是关于显存评估的。很多人上来直接跑结果发现OOM。我一般建议在部署模型之前先按参数总量估算显存占用模型参数占用的显存大致是参数量乘以字节数比如一个70亿参数的模型用FP16格式权重大约占14GB但推理时还有一个“大头”——KV Cache它跟并发的序列数量以及上下文长度成正比稍不留神就会把显存挤爆。所以配置vLLM时gpu_memory_utilization这个参数我一般会留出8%~15%的余量避免系统不稳。第三个是关于数据格式的。训练框架吃的是token id序列推理框架输出的是token id序列再解码成文字所以分词器必须和模型严格匹配。很多人图省事用不同的分词器去加载模型结果出来的中文多多少少有乱码或者语义漂移。用模型原本训练时的分词器是最基本原则。6. 从实际项目看训练与推理框架的打通前面讲了很多框架的分工但实际项目中训练和推理必须形成一个闭环。我拿一个自己最近做的实际项目来串一串。项目的背景是自己收集了一批领域语料想基于一个开源基座模型微调出一个领域内问答助手。训练阶段我用的就是DeepSpeed ZeRO Stage 2加上LoRA8张老款GPU凑合着扛下来了。整个训练跑下来最花时间的是排查数据质量问题框架本身倒没出什么大岔子。训练完之后我先把LoRA的权重合并回原模型导出成一个完整的HuggingFace格式模型再拿vLLM加载并启动一个OpenAI兼容的服务。这个过程中我踩了一个坑刚开始直接把LoRA模型用vLLM加载结果vLLM报错说模型结构不匹配。后来才知道vLLM加载LoRA需要通过它自己的适配机制而不是直接加载PEFT训练产物。最简单的办法是先合并权重再加载完整模型。改了之后服务秒起效果也正常。所以说训练和推理框架虽然各管一摊但模型格式、分词器、权重结构这些环节是它们之间的“高速公路”。打通这条高速公路项目的交付才算是真正完成。最后再分享一个小技巧如果你想把本地部署的模型接入到自己的应用、脚本或者办公工具里一定要优先选支持OpenAI接口协议的框架部署方式。因为现在的生态工具比如各类Agent框架、脚本库几乎都默认兼容OpenAI接口格式你起一个本地OpenAI兼容服务就能无缝接入现有工具省去大量适配工作。我目前给所有本地模型起的服务全是走这条路。大模型训练和推理框架这个领域还在快速演进中今天聊的这些很可能过不了多久又有新变化。但底层的那几条主线——显存怎么省、并行怎么做、吞吐怎么提——短时间内不会变。把这几个核心点吃透不管框架怎么换你都能快速上手。