大模型基础设施从零搭建：算力、训练、推理与微调实战指南

1. 从一条人事变动看大模型基础设施的底层逻辑

1.1 为什么一个技术高管的动向能搅动整个圈子

阿里VP贾扬清被曝将创业、方向锁定大模型基础设施、且火速锁定融资——这条消息在技术圈刷屏的速度，比很多产品发布会还快。很多人第一反应是"又一个明星创业者"，但如果你真的在大模型这条链路上摸爬滚打过，就会明白这条消息的分量不在"谁创业"，而在"他选的方向"。

贾扬清这个名字，对做深度学习框架的人来说几乎是绕不开的。Caffe、TensorFlow、PyTorch这几个主流框架的演进史里都有他的身影，后来在阿里又主导了大数据与AI平台的建设。这样一个人出来做"大模型基础设施"，等于是在告诉整个行业：模型本身的热闹是一层，真正决定谁能跑得远的是底下那层地基。

我自己做大模型部署和微调有段时间了，从最早在单卡上折腾7B模型，到后来参与企业私有化部署，踩过的坑基本都集中在"基础设施"这四个字上。模型权重下载下来只是第一步，真正让人头秃的是显存怎么分、推理怎么并发、微调怎么不炸、多卡怎么通信。所以当我看到"大模型基础设施"这个方向时，第一反应是：终于有人把这件事当成一个正经赛道来做了。

这篇文章不打算复述新闻，而是借这个由头，把大模型基础设施到底包含什么、为什么它比模型本身更值得投入、一个从业者如果要自己搭一套能用的环境该怎么做，从头到尾讲清楚。适合正在做大模型应用开发、企业私有化部署、或者单纯想搞明白"大模型背后那套东西"的读者。不管你是刚入门还是已经踩过几个坑，下面这些内容应该都能对上你的实际场景。

1.2 大模型基础设施到底指什么

很多人把"大模型"和"大模型基础设施"混为一谈，其实这是两个层次的东西。模型是"内容"，基础设施是"承载内容的那套系统"。打个比方，模型像是菜谱，基础设施像是厨房——菜谱再好，厨房没有合适的灶台、抽油烟机、冷藏设备，你也做不出一桌菜。

具体拆开来看，大模型基础设施至少包含这么几块：

• 算力调度层：GPU集群怎么组织、任务怎么排队、资源怎么隔离。这一层决定了你的卡是"能用"还是"好用"。
• 训练与微调框架层：分布式训练怎么切分、梯度怎么同步、混合精度怎么配。这一层直接决定你能不能把模型训起来。
• 推理服务层：模型怎么加载、请求怎么批处理、显存怎么复用。这一层决定你的服务能不能扛住真实流量。
• 数据与存储层：训练数据怎么存、怎么读、怎么版本管理。这一层最容易被忽视，但往往是瓶颈。
• 可观测与运维层：指标怎么采、日志怎么看、故障怎么定位。这一层决定你半夜能不能睡好觉。

贾扬清选的方向，大概率是这几层的组合，尤其是训练和推理的框架与调度。因为他在框架层的积累最深，而这恰恰是当前国内最缺"既懂底层又懂工程"的人的地方。

提示：判断一个"大模型基础设施"项目值不值得关注，看它解决的是上面哪一层的问题。如果只是套壳调用API，那不算基础设施；如果能让你在自有硬件上把模型跑得更快更稳，那才是。

1.3 为什么这个时间点做基础设施是对的

现在做基础设施，时机其实非常微妙。一方面，模型层已经卷到白热化，开源模型一个接一个，参数从7B到70B再到更大，大家发现"模型不是问题，跑起来才是问题"。另一方面，企业开始从"试试看"转向"真要用"，私有化部署、数据不出域、成本可控这些需求集中爆发。

我接触过几个做工业AI检测的团队，他们问得最多的问题不是"用哪个大模型"，而是"我这四张卡能不能跑起来""云上跑还是本地跑""微调一次要多久"。这些问题全是基础设施问题。模型选型反而是最后才定的，因为只要基础设施搭好了，换模型就是换个权重文件的事。

所以这个时间点，基础设施的价值被放大了。谁能让企业用更少的卡、更短的时间、更低的门槛把大模型用起来，谁就抓住了真正的痛点。贾扬清火速锁定融资这件事，本质上也是资本对这个判断的认可——模型层的钱已经不好赚了，基础设施层才是接下来几年的硬仗。

2. 大模型基础设施的核心技术点拆解

2.1 算力集群的构成与架构选择

要理解大模型基础设施，先得搞清楚算力集群长什么样。目前主流的AI算力集群，基本是"GPU服务器 + 高速互联 + 存储 + 调度系统"这四件套。

GPU服务器是基本单元，一台机器里塞4卡或8卡是常态。卡与卡之间靠NVLink或PCIe互联，机器与机器之间靠InfiniBand或高速以太网。这里有个关键参数叫互联带宽，它直接决定分布式训练的效率。我见过太多团队卡在"单机8卡跑得好好的，一上多机就慢得离谱"，问题往往就出在机器间带宽不够或者通信库没配对。

存储这块，训练数据的读取速度经常被低估。一个几十GB的数据集，如果存储IO跟不上，GPU就会一直等数据，利用率掉到30%以下都很正常。所以做基础设施的人，一定会把存储和计算放在同等重要的位置。

调度系统则是把上面这些资源管起来的那层。Kubernetes是目前最主流的选择，配合各种GPU插件和调度器。它的好处是资源隔离和弹性伸缩，坏处是学习曲线陡，配置复杂。我个人的经验是，小团队别一上来就上K8s，先用简单的任务队列把流程跑通，等规模上来了再迁移，否则光调调度器就能耗掉你一半精力。

2.2 训练框架与分布式策略

模型训练这块，核心矛盾永远是"模型太大，单卡放不下"。解决办法就是分布式，而分布式又分几种策略，选错了会事倍功半。

数据并行是最常见的，每张卡放一份完整模型，数据切分开。优点是实现简单，缺点是模型必须能塞进单卡。7B模型用混合精度大概14GB，单张24GB卡勉强能放，但再大就不行了。

模型并行是把模型本身切开，不同层放不同卡。这个实现复杂，通信开销大，一般只在模型特别大时用。

流水线并行是模型并行的改良版，把模型分段，像流水线一样处理。它能在一定程度上缓解通信瓶颈，但需要仔细调分段策略。

张量并行是把单个层的计算切开，适合层内计算量大的情况。这个对通信要求极高，通常只在同一台机器内用。

实际生产中，这几种策略往往是组合使用的，也就是所谓的"3D并行"。我试过在4卡上跑一个13B模型的微调，用的是数据并行加梯度累积，效果还行，但吞吐上不去。后来换成张量并行加数据并行，速度明显提升，代价是配置复杂度翻倍。

注意：分布式策略没有银弹，选哪种取决于你的模型大小、卡的数量、卡间带宽。别盲目抄别人的配置，先算清楚自己的显存和带宽账。

2.3 推理服务的性能优化

训练是一次性的，推理是天天要跑的。所以推理服务的优化，直接关系到你的成本。

推理优化的核心就一个字：省。省显存、省算力、省时间。具体手段包括：

• 量化：把FP16降到INT8甚至INT4，显存直接砍半甚至更多。代价是精度可能下降，需要评估。
• 批处理：把多个请求攒一起算，提高GPU利用率。但批太大延迟会上升，要平衡。
• KV Cache优化：大模型推理时KV Cache占显存大头，用PagedAttention这类技术能显著降低浪费。
• 模型并行推理：大模型单卡放不下时，切开放多卡。

我实测下来，一个7B模型用INT4量化后，单张消费级显卡就能跑，速度也能接受。但如果是需要高精度的场景，比如代码生成或者数学推理，量化带来的精度损失就得慎重考虑。

vLLM是目前推理服务里比较火的一个方案，它的PagedAttention和连续批处理做得不错。部署起来也不算复杂，基本是拉镜像、配参数、起服务三步。但它的坑在于版本迭代快，不同版本参数不兼容，升级前一定要看changelog。

2.4 微调技术的选型与实操

微调是大模型落地绕不开的一环。企业用自己的数据把通用模型调成"懂自己业务"的模型，这是刚需。

微调技术大致分几类：

• 全量微调：更新所有参数，效果最好，但显存需求最大，一般企业玩不起。
• LoRA：只训练低秩矩阵，显存需求小，效果接近全量。这是目前最主流的选择。
• QLoRA：在LoRA基础上把基座模型量化，进一步降低显存。单张24GB卡就能微调7B模型。
• Prefix Tuning / P-Tuning：只训练少量前缀参数，更省，但效果波动大。

我个人的经验是，绝大多数企业场景用LoRA就够了。数据量几千到几万条，训练几个小时到一天，效果能明显看出来。QLoRA适合硬件特别紧张的情况，但训练速度会慢一些。

微调最容易被忽视的是数据质量。我见过团队花大力气调参，结果数据里一半是噪声，怎么调都上不去。后来把数据清洗一遍，同样的参数效果直接提升一截。所以做微调，先把数据整明白，再谈技术。

3. 从零搭建一套可用的大模型环境

3.1 硬件选型与成本估算

搭环境第一步是选硬件。这里没有标准答案，只有适不适合。

如果是个人学习或者小团队试水，一张24GB显存的消费级卡（比如4090）就够跑7B模型的推理和QLoRA微调。整机成本大概一两万，性价比很高。

如果是企业私有化部署，要考虑并发和稳定性，通常得上专业卡。A100、H100这些是主流，但价格高，而且供货紧张。四卡起步是比较常见的配置，能跑13B到70B的模型。

成本估算这块，我习惯按"显存总量"来算。经验值是：推理7B模型需要至少16GB显存，13B需要至少32GB，70B需要至少140GB（量化后能降到一半左右）。微调的话，QLoRA微调7B大概需要12GB，LoRA微调7B大概需要20GB。

提示：别一上来就追求顶配。先用现有硬件把流程跑通，搞清楚瓶颈在哪，再决定加什么。我见过太多人卡还没到就先买了一堆，结果发现根本用不上。

3.2 系统环境与依赖安装

硬件到位后，软件环境是下一个坎。大模型这套东西对系统环境挺挑的，驱动、CUDA、Python版本、各种库的版本，一个不对就报错。

基本流程是这样的：

1. 装显卡驱动：去官方渠道下对应型号的驱动，装完用命令验证。
2. 装CUDA和cuDNN：版本要和驱动、框架匹配。这一步最容易出问题，建议直接看框架官方文档推荐的版本组合。
3. 建Python虚拟环境：别用系统Python，用conda或者venv隔离，避免依赖冲突。
4. 装框架：PyTorch是主流，装的时候注意选对CUDA版本。
5. 装推理/微调库：vLLM、transformers、peft、bitsandbytes这些按需装。

# 验证驱动和CUDA nvidia-smi # 创建虚拟环境 conda create -n llm python=3.10 conda activate llm # 安装PyTorch（示例，版本按需调整） pip install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/cu118 # 安装常用库 pip install transformers peft bitsandbytes accelerate

这套流程看着简单，但每一步都可能卡住。我踩过最多的坑是CUDA版本和PyTorch版本不匹配，报错信息还特别隐晦。后来养成习惯，装之前先查官方兼容性表格，能省很多时间。

3.3 模型下载与本地部署

环境好了，下一步是把模型弄下来。模型来源主要是开源社区，下载方式有几种：直接下权重文件、用框架自带的下载工具、或者从镜像站拉。

下载这块要注意的是存储空间和下载速度。一个7B模型的权重文件大概十几GB，70B的能到一百多GB。下载慢的话，挂一晚上都下不完。我的做法是先用小模型验证流程，确认没问题再下大模型。

模型下载下来后，部署方式取决于你的需求：

• 快速验证：用transformers直接加载，写个脚本跑推理。简单直接，但性能一般。
• 生产服务：用vLLM或者类似框架起服务，支持并发和批处理。
• 本地桌面：用Ollama这类工具，一条命令就能跑，适合个人玩。

Ollama这两年挺火，它的好处是把模型管理和运行都封装好了，Windows上也能用。装完之后拉个模型，直接对话就行。缺点是定制性差，企业场景不太够用。

# Ollama示例 ollama pull llama3 ollama run llama3

如果是企业私有化部署，我一般推荐vLLM加Docker的方式。镜像拉下来，配好模型路径和显存参数，起服务，然后前端通过API调用。这套方案成熟度高，社区活跃，遇到问题好找答案。

3.4 微调实战：从数据准备到模型导出

微调这块我展开讲，因为这是企业落地最核心的环节。

第一步是数据准备。数据格式通常是"指令-输入-输出"的三元组，或者"问题-答案"的二元组。数据量不用特别大，几千条高质量数据就能看出效果。关键是质量，要覆盖你的业务场景，答案要准确。

第二步是选基座模型。中文场景一般选中文能力强的开源模型，英文场景选择更多。选的时候看两点：一是基础能力，二是许可证是否允许商用。

第三步是配训练参数。LoRA的关键参数是秩（r）和alpha，一般r取8到64，alpha取r的两倍。学习率别太大，1e-4到5e-5比较稳。批次大小看显存，不够就用梯度累积。

第四步是训练。用peft加transformers就能跑，代码量不大。训练过程中盯着loss曲线，如果一直不降，多半是数据或参数有问题。

第五步是导出和部署。LoRA训练完是一个适配器，可以合并到基座模型里导出成完整模型，也可以分开加载。合并后部署更方便，分开加载更灵活。

# LoRA微调核心配置示例 from peft import LoraConfig, get_peft_model lora_config = LoraConfig( r=16, lora_alpha=32, target_modules=["q_proj", "v_proj"], lora_dropout=0.05, bias="none", task_type="CAUSAL_LM" ) model = get_peft_model(base_model, lora_config) model.print_trainable_parameters()

我实测下来，7B模型用LoRA微调，几千条数据，单张24GB卡跑几个小时就能出结果。效果上，业务相关的问答准确率能明显提升。但要注意，微调不是万能的，如果基座模型本身对这个领域完全没概念，微调也救不回来。

4. 实操中的常见问题与排查技巧

4.1 显存不够怎么办

显存不够是大模型实操里最高频的问题，没有之一。报错通常是CUDA out of memory，然后整个进程挂掉。

解决思路按优先级排：

1. 降精度：FP16换INT8或INT4，显存直接砍半。用bitsandbytes的量化加载就能实现。
2. 减批次：批次大小从8降到4再降到1，配合梯度累积保持等效批次。
3. 用LoRA替代全量微调：显存需求能降一个数量级。
4. 梯度检查点：用时间换空间，显存降了但训练变慢。
5. 模型并行：把模型切开放多卡，最彻底但最复杂。

我一般先试前三个，基本能解决大部分问题。如果还不行，再考虑后两个。

注意：显存不够时别硬扛，先降配置把流程跑通，再逐步往上加。我见过有人非要一次到位，结果调了一周都没跑起来。

4.2 训练loss不降或震荡

loss不降，说明模型没学到东西。可能的原因有几个：

• 学习率太大：loss震荡甚至上升，把学习率降一个数量级试试。
• 数据有问题：格式不对、标签错位、噪声太多。把数据抽样出来人工看几条。
• 批次太小：梯度噪声大，增大批次或梯度累积。
• 模型没加载对：检查基座模型是否正确加载，有没有被意外冻结。

我的排查顺序是：先看数据，再看学习率，最后看模型加载。数据问题占了一大半。

4.3 推理速度慢的优化路径

推理慢，用户体验就差。优化路径大概是：

1. 量化：最直接，速度能提升明显。
2. 换推理框架：vLLM这类专门优化的框架比原生transformers快很多。
3. 批处理：把请求攒起来一起算。
4. KV Cache优化：减少重复计算。
5. 硬件升级：前面都试过了还慢，那就是硬件瓶颈。

我实测过同一个模型，原生transformers和vLLM的吞吐能差好几倍。所以生产环境别用原生推理，一定要上专门的框架。

4.4 常见问题速查表

这张表是我自己踩坑总结的，基本覆盖了八成以上的常见问题。遇到问题先对号入座，能省不少时间。

5. 大模型基础设施的未来走向与个人机会

5.1 从"能用"到"好用"的差距在哪

现在大模型基础设施的状态，有点像早期的云计算——能用，但不好用。部署一套环境要折腾好几天，调参靠经验，故障排查靠猜。这中间的差距，就是机会。

"好用"意味着什么？意味着部署像装软件一样简单，调参有自动化工具，故障能自诊断。这些方向目前都有团队在做，但还没形成标准。贾扬清这类人出来创业，大概率就是冲着把"能用"变成"好用"去的。

对个人来说，这意味着什么？意味着如果你能把这套东西玩明白，你就是稀缺的。现在市场上会调API的人一大把，但能自己搭环境、调性能、排故障的人不多。这个差距，就是你的价值。

5.2 个人开发者如何切入这个方向

个人开发者切入大模型基础设施，我的建议是从"用"开始，别一上来就"造"。

先用现成的工具把模型跑起来，理解每个环节在干什么。然后遇到问题，尝试自己解决，解决不了再看源码。这个过程会逼着你理解底层原理。

具体的学习路径大概是：

1. 跑通推理：用Ollama或vLLM跑一个模型，理解加载、推理、输出的流程。
2. 跑通微调：用LoRA微调一个小模型，理解数据、训练、导出的流程。
3. 优化性能：尝试量化、批处理、并行，理解性能瓶颈在哪。
4. 读源码：挑一个核心库，比如vLLM或peft，读它的实现。
5. 做小项目：把学到的东西整合起来，做一个能用的东西。

这条路我走过，大概花了几个月。关键是别急，一步一步来，每步都动手做。

5.3 企业落地时的取舍与建议

企业做大模型落地，最大的坑是"追求完美"。总想一步到位，结果迟迟上不了线。

我的建议是先上线再优化。先用最简单的方案把业务跑起来，哪怕性能一般、效果一般，先让业务方看到价值。然后根据反馈逐步优化，该加卡加卡，该换框架换框架。

另一个建议是别自己造轮子。开源生态已经很成熟了，能用现成的就用现成的。自己造轮子的成本，往往比想象的高得多。

最后是数据要早准备。模型和框架都是可以换的，数据是换不了的。早点把业务数据整理好，后面无论用什么模型都能用上。

我在实际项目里最大的体会是，大模型落地这件事，技术只占一半，另一半是工程和业务的结合。光懂技术不懂业务，做出来的东西没人用；光懂业务不懂技术，做出来的东西跑不起来。两边都得懂一点，才能把事做成。这个方向后续还可以往多模态、Agent、自动化调优这些方向扩展，每一个都是值得深挖的坑。