1. 从一条人事变动说起大模型基础设施到底在做什么阿里VP贾扬清被曝将创业、方向锁定大模型基础设施、融资火速锁定——这条消息在圈子里传开的时候我正在调一个分布式训练的通信瓶颈。说实话第一反应不是“又一个明星创业者”而是“终于有人把这件事当成正经工程来做了”。大模型基础设施这个词听起来很唬人拆开看其实就三件事让模型训得起来、让模型跑得动、让模型用得起。训得起来靠的是分布式训练框架和集群调度跑得动靠的是推理引擎和显存优化用得起靠的是成本控制和弹性伸缩。贾扬清在深度学习框架领域有深厚的积累他选择这个方向本质上是在赌一件事未来三年大模型的基础设施层会比模型层更值钱。为什么这么说你可以把大模型想象成一辆车。模型本身是发动机基础设施是底盘、变速箱、油路和刹车。发动机再强底盘不行车也跑不快、跑不远。现在的情况是大家都在卷发动机参数但真正决定谁能把车开上路的是底盘工程。训练一个千亿参数模型光GPU集群的通信优化就能吃掉30%到40%的有效算力这不是调参能解决的问题这是系统工程问题。这篇文章不聊八卦聊的是这条新闻背后那个真正值得关注的技术领域大模型基础设施的构成、核心挑战、实操要点以及一个从业者应该怎么理解这个方向。无论你是刚入行的大模型开发工程师还是正在考虑企业私有化部署的技术负责人这些内容都能帮你建立一套完整的认知框架。2. 大模型基础设施的核心构成与选型逻辑2.1 训练侧分布式框架与集群架构大模型训练的基础设施核心就两个字并行。单卡放不下模型就得把模型切开单卡算得太慢就得把数据切开两者都不够就得混合切。目前主流的并行策略有三种数据并行DP每张卡持有完整模型副本喂不同批次的数据。优点是实现简单缺点是显存占用高模型大了直接爆。张量并行TP把单层内的矩阵运算切到多卡上。优点是能训超大模型缺点是通信量大对卡间带宽要求极高。流水线并行PP把模型按层切分到不同卡上像流水线一样传递。优点是通信量相对小缺点是存在气泡bubble需要精细调度。实际训练千亿级模型时通常是TPPPDP 三维混合并行。比如一个175B参数的模型可能用8路张量并行、16路流水线并行、再叠加数据并行。这里的关键参数是全局批次大小Global Batch Size它决定了梯度更新的稳定性。计算方式是全局批次大小 单卡批次大小 × 数据并行路数 × 梯度累积步数举个例子单卡批次设为4数据并行路数32梯度累积步数8那么全局批次就是 4×32×81024。这个数值不能拍脑袋定太小了训练不稳定太大了收敛慢且泛化差。通常从256开始试逐步往上加观察loss曲线是否平滑。集群架构方面现在主流的是叶脊Leaf-Spine网络拓扑配合RDMA远程直接内存访问和高速网卡。为什么不用传统TCP因为TCP的协议栈开销在万卡集群里会被放大到不可接受。RDMA可以让网卡直接读写远端内存绕过CPU延迟从毫秒级降到微秒级。实测下来同样规模的AllReduce操作RDMA比TCP快3到5倍。2.2 推理侧引擎选型与显存优化训练完了模型要上线服务这就是推理侧的事。推理基础设施的核心矛盾是显存不够用延迟要够低吞吐要够大。这三个目标互相打架你得做取舍。目前主流的推理引擎有vLLM、TensorRT-LLM、TGI等。vLLM的核心卖点是PagedAttention把KV Cache像操作系统管理内存页一样管理显存利用率能从60%提到90%以上。TensorRT-LLM是英伟达亲儿子算子融合做得极致但绑定NVIDIA生态。TGI是HuggingFace的方案易用性好适合快速验证。选型逻辑很简单如果你追求极致吞吐且用NVIDIA卡选TensorRT-LLM如果你要灵活部署且不想被绑定选vLLM如果你在HuggingFace生态里且对性能要求不极端选TGI。显存优化的另一个关键手段是量化。FP16是默认精度但你可以降到INT8甚至INT4。INT8量化通常能省一半显存精度损失在1%以内INT4能省75%显存但精度损失可能到3%到5%需要看具体任务。量化方式又分训练后量化PTQ和量化感知训练QAT前者简单但精度损失大后者复杂但效果好。2.3 调度侧资源管理与弹性伸缩大模型基础设施的调度层解决的是“谁用哪张卡、用多久、怎么排队”的问题。Kubernetes是事实标准但原生K8s对GPU的支持不够细需要配合设备插件Device Plugin和调度器扩展。关键调度策略包括Gang Scheduling一组Pod要么全调度成功要么全不调度。训练任务必须这样否则部分Pod起来了等不到其他Pod白白占着卡。Bin Packing尽量把任务塞到少数节点上减少碎片。但这对散热和网络拓扑有要求不是越紧越好。优先级抢占高优先级任务可以抢占低优先级任务的资源。生产环境必须有这个否则紧急任务排不进去。弹性伸缩方面训练任务通常不弹因为 checkpoint 和恢复成本太高推理任务必须弹因为流量波动大。推理的弹性伸缩要结合指标采集QPS、延迟、显存占用和预热机制新实例起来后不能立刻接流量得先加载模型、预热KV Cache否则第一批请求延迟会爆表。3. 实操中的核心细节与避坑要点3.1 训练任务启动前的检查清单我踩过最大的坑是训练任务跑了三天才发现数据管道有瓶颈。GPU利用率一直在40%左右晃查了半天发现是数据加载的IO跟不上。所以现在每次启动大训练任务前我都会过一遍这个清单数据管道吞吐测试单独跑数据加载看每秒能喂多少样本。如果喂数据的速度跟不上GPU计算速度再好的卡也是浪费。通信带宽验证用NCCL自带的带宽测试工具跑一遍AllReduce看实际带宽是否接近理论值。如果差太多检查网卡绑定、交换机配置、拓扑结构。Checkpoint读写测试写一个和真实模型同样大小的文件到存储测写入速度。千亿模型一个checkpoint可能几百GB写入慢会拖死整个训练。故障恢复演练手动kill掉一个训练进程看能否从最近的checkpoint恢复恢复时间是否可接受。提示数据管道的瓶颈往往不在硬盘而在CPU预处理。如果预处理逻辑复杂考虑用GPU做数据增强或者提前把数据预处理成二进制格式。3.2 推理服务的延迟优化实战推理延迟分两部分首token延迟和后续token延迟。首token延迟取决于prefill阶段后续token延迟取决于decode阶段。优化手段完全不同。首token延迟优化连续批处理Continuous Batching不等一个批次全部完成再处理下一批而是动态插入新请求。vLLM默认开启效果显著。Chunked Prefill把长prompt的prefill拆成小块和decode请求混在一起跑避免长prompt阻塞短请求。Prefix Caching如果多个请求有相同的前缀比如系统提示词缓存这部分KV不用重复计算。后续token延迟优化投机解码Speculative Decoding用一个小模型先猜几个token大模型再验证。猜对了就跳过猜错了就回退。实测能提速1.5到2倍。KV Cache量化把KV Cache从FP16降到INT8显存占用减半decode速度提升。算子融合把多个小算子合并成一个大算子减少kernel launch开销。这里有个经验数据在A100上跑7B模型优化前首token延迟可能到500ms优化后能压到100ms以内后续token延迟从50ms/token压到20ms/token。这个提升对用户体验是质的区别。3.3 企业私有化部署的选型考量企业私有化部署大模型和互联网公司做推理服务是两码事。企业场景的特点是数据不能出域、并发量不大、但对准确性和可控性要求极高。选型时重点看这几个维度维度关键问题建议硬件有没有GPU什么型号至少一张24G显存的卡否则7B模型都跑不动模型用开源还是商用开源选Llama系或Qwen系商用看API成本和数据合规部署方式容器化还是裸机容器化优先方便迁移和版本管理微调需求需不需要领域适配需要的话预留LoRA微调的算力和数据管道运维能力有没有专职人员没有的话选Ollama这类开箱即用的方案Ollama是目前个人和小团队本地部署最省心的方案。它把模型下载、量化、推理引擎打包成一个二进制一条命令就能跑起来。Windows 11上安装Ollama然后ollama run llama3等模型下载完就能对话。但要注意Ollama默认用的是量化版模型精度有损失生产环境要评估是否可接受。4. 从训练到推理的完整实操流程4.1 环境准备与依赖安装假设你要从零搭一个能跑7B模型微调和推理的环境硬件是一台8卡A100服务器。以下是经过验证的步骤第一步驱动和CUDA# 检查驱动版本 nvidia-smi # 安装CUDA 12.1根据驱动版本选择 wget https://developer.download.nvidia.com/compute/cuda/12.1.0/local_installers/cuda_12.1.0_530.30.02_linux.run sudo sh cuda_12.1.0_530.30.02_linux.run第二步Python环境和PyTorchconda create -n llm python3.10 conda activate llm pip install torch2.1.0 torchvision torchaudio --index-url https://download.pytorch.org/whl/cu121第三步训练框架# 安装DeepSpeed pip install deepspeed # 安装Transformers和Accelerate pip install transformers accelerate datasets # 安装FlashAttention可选但强烈推荐 pip install flash-attn --no-build-isolation第四步推理引擎# 安装vLLM pip install vllm # 或者安装TensorRT-LLM需要额外编译 # 参考官方文档注意FlashAttention对PyTorch版本和CUDA版本有严格要求装之前先确认兼容性。装不上也不要强求用默认的attention实现也能跑只是慢一些。4.2 LoRA微调实战以7B模型为例LoRA低秩适配是目前最流行的微调方式核心思想是冻结原模型参数只训练两个低秩矩阵。这样显存占用大幅降低7B模型用一张A100就能微调。关键参数rankr低秩矩阵的秩通常取8到64。越大表达能力越强但显存占用也越大。7B模型建议从16开始试。alpha缩放因子通常设为rank的2倍。比如r16alpha32。target_modules要适配的模块通常是q_proj、v_proj、k_proj、o_proj。全加上的话效果更好但更慢。learning_rateLoRA的学习率可以比全量微调大通常1e-4到3e-4。训练脚本的核心逻辑from peft import LoraConfig, get_peft_model from transformers import AutoModelForCausalLM, AutoTokenizer model AutoModelForCausalLM.from_pretrained( Qwen/Qwen2-7B, torch_dtypetorch.bfloat16, device_mapauto ) lora_config LoraConfig( r16, lora_alpha32, target_modules[q_proj, v_proj, k_proj, o_proj], lora_dropout0.05, biasnone, task_typeCAUSAL_LM ) model get_peft_model(model, lora_config) model.print_trainable_parameters() # 输出trainable params: 4,194,304 || all params: 7,241,748,480 || trainable%: 0.058%看到没有可训练参数只有0.058%但效果能接近全量微调。这就是LoRA的威力。训练时的显存估算7B模型BF16权重约14GBLoRA参数和优化器状态约1GB激活值和梯度约10GB总共约25GB。一张40G的A100绰绰有余甚至24G的4090也能勉强跑。4.3 推理服务部署与压测微调完了用vLLM部署推理服务python -m vllm.entrypoints.openai.api_server \ --model /path/to/merged/model \ --tensor-parallel-size 2 \ --dtype bfloat16 \ --max-model-len 4096 \ --gpu-memory-utilization 0.9参数解释--tensor-parallel-size 2用两张卡做张量并行。7B模型单卡能放下但两张卡能提高吞吐。--max-model-len 4096最大上下文长度。设太大浪费显存设太小截断输入。--gpu-memory-utilization 0.9GPU显存利用率上限。留10%给系统和其他进程。压测用wrk或locust重点看三个指标QPS、首token延迟、后续token延迟。如果QPS上不去先看是不是batch size太小如果延迟高看是不是KV Cache不够或者请求排队太长。实操心得vLLM的--max-num-seqs参数控制并发序列数默认256。如果显存够调大到512能提升吞吐如果显存紧张调小到128能降低延迟。这个参数需要根据实际流量模式调优。5. 常见问题与排查技巧实录5.1 训练不收敛或loss震荡这是最常见的问题原因可能有很多。按优先级排查学习率太大先降一个数量级试试。大模型训练的学习率通常在1e-5到1e-4之间LoRA可以到3e-4。批次大小太小全局批次小于256时梯度噪声大loss容易震荡。增大批次或增加梯度累积步数。数据质量问题检查训练数据有没有大量重复、乱码、格式错误。数据清洗比调参重要十倍。梯度裁剪没开大模型训练必须开梯度裁剪通常clip到1.0。不裁剪的话偶尔的大梯度会把模型带偏。混合精度配置错误BF16比FP16稳定优先用BF16。如果用FP16必须配合loss scaling。5.2 GPU利用率低GPU利用率低说明GPU在等数据或等通信。排查思路看数据加载时间用PyTorch Profiler看DataLoader耗时占比。如果超过20%优化数据管道。看通信时间用NCCL调试日志看AllReduce耗时。如果通信占比高检查网络拓扑和带宽。看kernel launch开销如果模型有很多小算子kernel launch开销会累积。用算子融合或CUDA Graph优化。看CPU瓶颈如果CPU利用率也高说明CPU在拖后腿。增加DataLoader的num_workers或者把预处理放到GPU上。5.3 推理服务OOM推理OOM通常发生在两个阶段模型加载时和请求处理时。模型加载OOM模型太大单卡放不下。解决方案是张量并行把模型切到多卡上。或者用量化版模型INT8能省一半显存。请求处理OOMKV Cache爆了。解决方案是限制max-model-len或者开启PagedAttentionvLLM默认开启或者降低并发数。5.4 常见问题速查表问题现象可能原因排查命令/方法解决方案loss不下降学习率太小打印梯度范数增大学习率loss震荡批次太小检查global batch size增大批次或梯度累积GPU利用率低数据管道瓶颈PyTorch Profiler优化DataLoader通信慢网络拓扑差NCCL带宽测试检查RDMA和交换机推理OOMKV Cache太大监控显存占用限制max-model-len首token延迟高prefill太慢分阶段计时开启Chunked Prefill后续token慢decode效率低看tokens/s投机解码或KV量化模型加载慢存储IO瓶颈测磁盘读取速度用本地SSD或内存盘6. 大模型基础设施的学习路线与能力建设6.1 从应用层到基础设施层的技能树如果你现在做的是应用层开发想往基础设施层走需要补的能力大致分三块第一块分布式系统基础。理解一致性哈希、Raft协议、gRPC、消息队列。这些不是大模型特有的但大模型基础设施建立在它们之上。第二块GPU编程与性能优化。CUDA编程、算子融合、显存管理、通信原语AllReduce、AllGather、ReduceScatter。这块是硬功夫需要动手写代码。第三块大模型特有知识。Transformer架构、注意力机制、并行策略、量化、蒸馏、LoRA。这块更新快需要持续跟进。学习路线建议先跑通一个单卡微调再跑通多卡训练然后尝试优化推理延迟最后研究集群调度。每一步都要有可量化的指标比如“把7B模型的微调显存从40G降到24G”、“把推理QPS从10提到50”。6.2 企业落地大模型基础设施的决策框架企业要不要自建大模型基础设施取决于三个问题数据敏感度数据能不能出域不能出域就必须私有化部署。调用频率每天调用多少次如果每天只有几百次用API更划算如果每天几万次以上自建可能更省。团队能力有没有人能维护GPU集群和推理服务没有的话优先考虑托管方案。成本估算的粗略公式自建成本 硬件采购 电费 运维人力 模型微调成本 API成本 调用次数 × 单价以7B模型为例一张A100约1万美元功耗300W一年电费约2600元人民币。如果每天调用1万次每次平均500 tokenAPI单价按0.001元/千token算一年API费用约1825元。这种情况下API更划算。但如果每天调用100万次API费用就变成18万自建就划算了。6.3 这个方向的机会与挑战贾扬清选择大模型基础设施创业逻辑是通的。模型层竞争已经白热化但基础设施层还有大量工程问题没解决。训练效率、推理成本、集群稳定性、异构硬件适配每一个都是硬骨头也都是机会。挑战也很明显这个领域技术迭代太快今天的最优解明天可能就过时。做基础设施的人必须保持对新技术的高度敏感同时又要克制不能什么热就追什么。基础设施的核心价值是稳定和效率不是炫技。我个人在实际操作中的体会是大模型基础设施的难点不在“知道”而在“做到”。你知道要用RDMA但调通RDMA需要一周你知道要用PagedAttention但理解它的显存管理逻辑需要啃源码你知道要用Gang Scheduling但配好K8s调度器需要踩无数坑。这些坑才是真正的壁垒。最后分享一个小技巧每次优化前先建立基线。记录当前的吞吐、延迟、显存占用、GPU利用率。优化后对比基线才知道有没有效果。没有基线的优化都是自嗨。