大模型推理的本质是预测下一个token，涉及计算、内存和系统调度三大问题。文章详细解析了Prefill和Decode的区别、KV Cache的管理挑战、Paged Attention和Continuous Batching的优化策略，以及vLLM如何整合这些技术提升推理效率。通过系统化的设计，可以有效提升大模型服务的响应速度和并发能力，让模型更好地服务于现实世界。

这模型到底是怎么跑起来的？

同一个模型，有的系统输完字马上就能出结果，有的却要等好几秒；同样一块GPU，有的服务能扛住高并发不崩，有的一上来大量请求就开始卡顿。表面上看，大家都是“调用一个大模型”，说白了，拼的其实是背后推理系统的硬实力。

也正因为这样，像Prefill、Decode、Paged Attention、Continuous Batching、PD分离，还有vLLM这种推理引擎，在工程圈里才变得越来越重要。

很多人对这些概念多少都听过，但理解都比较零散：知道有Prefill和Decode，却不知道为啥非得把它们分开看；知道vLLM跑得很快，却说不清它到底快在点子上；知道一个vllm-openai的镜像就能跑服务，却搞不懂镜像里真正装的是什么东西。

这篇文章就想把这条链路讲明白：从大模型推理的本质开始，一步步说到现代推理引擎为什么会是今天这个样子。

一、大模型推理的本质，不是“回答问题”，而是“预测下一个token”

先把最核心的问题说透。

从我们用户的角度看，大模型就是用来“聊天”“写代码”“翻译”“总结文档”的。但在模型内部，这些任务到最后都被统一成了一件事：

给定前面的内容（上下文），预测下一个token（可以理解成下一个字、词或符号）。

比如你输入一句话：

请用通俗语言解释一下Transformer

模型不会直接“看懂你的需求，然后整段写出答案”。它实际做的是：先根据你输入的这句话，形成一个上下文的理解，然后预测第一个要输出的token；生成第一个之后，再把它加进前面的上下文里，接着预测第二个；就这么循环下去，直到生成完所有内容。

所以大模型推理的本质一点都不神秘，就是一个一步接一步、不断自己迭代的生成过程。难就难在这个过程上：它不是一次性就能完成的，得一直迭代、一直读写前面的上下文、一直调度硬件资源。

也正因为这样，大模型推理从来不是“跑一次计算”那么简单。它背后其实同时牵扯着三类问题：

第一类是计算问题。模型本身就很大，里面的矩阵运算特别多，特别耗算力。

第二类是内存问题。上下文越长，需要缓存的数据就越大，显卡的显存很快就不够用了。

第三类是系统问题。在线服务里，大家的请求长短不一样、发送时间不一样、结束时间也不一样，怎么调度GPU，直接决定了响应速度和能同时处理多少请求。

想理解后面所有的优化方法，先记住一个基本事实：

大模型推理，本质上就是“模型计算 + 内存管理 + 在线调度”这三件事缠在一起的问题。

二、为什么要把推理拆成Prefill和Decode

如果把整个推理过程拆开看，会发现它天生就分成两个阶段，而且这两个阶段对资源的需求完全不一样。

1. Prefill：先把输入“吃进去”

---

我们发过去的提示词（prompt），往往是一整段现成的文本。不管是一句简单的提问，还是几千字的文档摘要请求，模型都得先把这段输入完整处理一遍。这一步，就是Prefill。

Prefill干的事儿其实就两件：

一是把输入的token一层一层送到Transformer里，形成对上下文的理解（也就是上下文表示）；

二是为后面的生成过程，建好历史缓存，也就是咱们常说的KV Cache。

这里最关键的一点是：Prefill阶段的输入是已知的、完整的。

因为一上来就把整段提示词都给模型了，所以模型可以在序列维度上做大规模的并行计算。

也就是说，Prefill更偏向于“耗算力”的阶段：里面的矩阵运算多，GPU的计算单元能充分利用，但相应地，提示词越长，Prefill花的时间就越多。

这也是为什么长上下文的请求，常常会让第一次输出的响应变慢。因为我们看到第一个输出之前，系统必须先把整段输入都处理完。

2. Decode：再一个token一个token地往下写

---

等提示词处理完，模型才会进入真正的生成阶段，也就是Decode。

Decode和Prefill最大的区别，就是它不再处理“一整段已知的输入”，而是每一步只新增一个token。

每生成一个token，模型都得拿这个新token，和前面所有的历史上下文做关联计算（也就是attention），再预测下一个token。

这就意味着，Decode有一个很明显的工程特点：

它天生就是串行的。

后一个token必须等前一个token生成完才能算，所以你几乎不可能像Prefill那样，做大规模的并行计算。

与此同时，随着上下文越来越长，Decode每一步都要频繁读取历史的KV Cache，所以它往往不是“算不过来”，而是“读不过来”——瓶颈更容易出在显存的读写速度和缓存的访问效率上。

这样一来，就有了一个很明显的对比：

• Prefill更像是靠算力撑起来的任务

• Decode更像是靠显存带宽撑起来的任务

这就是为什么在推理系统里，大家不会把它们混在一起处理。它们看着都属于“推理”，但从需要什么资源、该怎么优化来看，其实是两种完全不同的工作负载。

三、为什么说大模型推理的真正难点，不在模型，而在系统

如果只有一个请求，大模型推理其实很好理解：先做Prefill，再做Decode，一步步生成下去就行。

但一旦放到在线服务的场景里，问题就立刻变复杂了。

真实的系统里，请求不会整整齐齐地一起到。有的人只问一句短问题，有的人直接贴一整篇长文；有的请求生成几十个token就结束，有的可能要一直写几千个token。更麻烦的是，这些请求是源源不断进来的，不会等上一批全跑完再写下一批。

所以推理系统必须同时解决几个很现实的问题：

• 新请求来了，什么时候插进去执行？

• 老请求结束了，空出来的GPU位置怎么立刻利用起来？

• 每个请求长短不一样，KV Cache怎么分配，才不会浪费显存？

• 长提示词的请求和短生成的请求混在一起，怎么避免互相拖慢？

这时候你就会发现，决定系统用着顺不顺的，已经不只是“模型计算快不快”，而是系统能不能管好这些乱七八糟的负载。

这也是现在所有高性能推理引擎，都要解决的核心问题：

如何在有限的GPU资源上，同时兼顾第一次输出的速度、生成速度、并发能力和显存利用率。

围绕这个问题，后来才慢慢有了Paged Attention、Continuous Batching、PD分离，还有vLLM这样的系统设计。

四、为什么KV Cache会成为推理时代最重要的显存问题

想搞懂vLLM，必须先搞懂KV Cache。

在Transformer的attention机制里，每个token在每一层都会对应一组Key（键）和Value（值）。生成新token的时候，模型需要拿当前token的Query（查询），和前面所有token的Key/Value做计算。

为了不用每次都重新计算一遍前面的上下文，系统通常会把历史token的K/V存起来，这就是KV Cache。

KV Cache的作用特别大：它能让模型不用每一步都重新处理整个历史序列，不然生成的成本会高到离谱。

但KV Cache也带来了一个很现实的问题：它特别占显存，而且会一直增长。

上下文越长，生成的时间越久，历史token就越多，缓存就越大。如果是多用户同时请求，每个请求都在不断积累自己的KV Cache，显存的压力会很快上来。

到这时候，模型参数本身已经不是唯一的瓶颈了，缓存反而成了服务系统里最紧张的资源之一。

传统的做法，通常是给每个请求分配一块连续的显存，用来存它的KV Cache。这种方式在单机、小规模的场景下还能用，但一旦到了在线高并发的环境，就会暴露几个明显的问题：

第一，请求长度没法预测。一开始你根本不知道一个请求最后会生成多长。

第二，连续分配容易浪费。预留的空间太大，会造成很多空闲的显存；预留太小，中途想扩容又很麻烦。

第三，显存碎片严重。请求忽来忽走、动态结束，显存很容易被切得零零碎碎，没法充分利用。

第四，在动态批量处理（动态batch）的场景下，很难灵活复用显存。

这时候，KV Cache就不只是“一个缓存”了，而是一个标准的动态内存管理问题。而vLLM最有代表性的贡献之一，就是用“分页”的方式，重新解决了这个问题。

五、Paged Attention的本质，是把KV Cache管理变成“虚拟内存”问题

Paged Attention之所以重要，不是因为它发明了attention，而是因为它重新设计了attention背后的缓存管理方式。

它借鉴的是操作系统里一个很经典的思路：分页管理。

操作系统不会要求一个程序的所有内存，在物理上都是连续的，只要求逻辑上连续就行，底层可以拆成多个页面（page），通过页表映射到零散的物理内存。同样的思路，被vLLM用在了KV Cache上。

具体来说，vLLM不再要求一个请求的KV Cache，必须放在一整块连续的显存里，而是把缓存切成固定大小的块（block）或页面（page）。

一个请求在逻辑上，拥有一段连续的上下文，但在物理上，这些KV块可以分散在显存的不同位置，通过映射关系组织起来。

这么做的好处特别直接。

首先，显存利用率会明显提高。因为系统不用再给每个请求预留一整块连续空间，而是按需分配页面。

其次，扩容变得简单。请求继续生成的时候，只需要再申请新的页面就行，不用把整段缓存都挪地方。

再次，释放也更灵活。请求一结束，它对应的页面就能立刻回收，快速分给下一个请求用。

最后，它天生适合动态并发的场景。因为在线服务的请求长度本来就不稳定，分页比“整块连续分配”更适配这种乱七八糟的负载。

之所以叫Paged Attention，是因为attention在读取历史KV的时候，底层的访问方式已经不是“从一段连续的数组里顺着读”，而是按照逻辑块的映射，找到对应的物理块，再完成计算。

说到底，Paged Attention解决的不是模型准不准的问题，而是推理系统在显存层面，能不能持续扩展的问题。

六、Continuous Batching真正改变的，不是batch大小，而是batch的生命周期

另一个对现代推理系统影响很大的概念，是Continuous Batching。

在传统的深度学习训练，或者离线推理里，batch（批量）的概念很简单：收集一批样本，组成一个固定的batch，一起跑完，再处理下一批。

这种模式的问题在于，它默认所有样本的长度差不多、任务边界很清晰，而且不会在执行过程中，不断有新请求插进来。

但大模型在线生成，根本不是这样的。

一个batch里，有的请求可能马上就结束了，有的还得继续生成很久；同时，新的用户请求还在不断进来。

如果非要用静态batch，系统就会变得特别低效：已经结束的请求还占着GPU位置，新请求只能等下一批，GPU经常空转，响应速度和处理能力都上不去。

Continuous Batching的核心思路，不是“把batch做大”，而是：

让batch变成一个动态流动的集合。

在每一轮Decode迭代之后，调度器都会重新检查当前正在运行的请求：

• 已经结束的，就移出去；

• 还没结束的，继续留下来；

• 新到的、符合条件的请求，插进来。

这样一来，batch就不再是一批固定不变的请求，而是一个一直在重组的执行单元。GPU能尽量保持满载，系统也不用等“这一整批都结束”，再接收下一批请求。

这个机制看着只是调度层面的小改动，但在大模型场景下，它本质上提高了推理服务的处理上限。

因为Decode本来就是一步一步推进的，既然每一步都要做一次同步，那顺便在这一步里，完成请求的加入、退出和重新排序，就是很自然的系统设计。

所以Continuous Batching的价值，不只是“能处理更多请求”，更重要的是，它让在线推理第一次真正适配了现实世界的情况——请求长度不确定、到达时间不确定、完成时间也不确定。

七、PD分离为什么会成为更高级的推理架构方向

当你真正搞懂了Prefill和Decode的资源差异，就很容易明白，为什么行业里会出现PD分离——也就是Prefill/Decode Separation（Prefill和Decode分离）。

原因很简单：它们不是同一种负载，却经常被硬放在同一批GPU上一起跑。

Prefill更偏向于耗算力，适合做大规模的矩阵计算；Decode更偏向于对带宽敏感，需要频繁读写缓存。

把这两者混在一起跑，就会出现互相干扰的情况：长提示词的Prefill容易把短请求的Decode压住，而Decode那种高频、小步的迭代，又会拖慢Prefill的处理速度。

于是，更高级的系统就会选择把它们拆开：

• 一组资源专门负责Prefill；

• 另一组资源专门负责Decode。

这么做的好处很明显：资源可以针对性优化，调度逻辑也更清晰，不同的负载不会互相干扰，整个系统的稳定性也会更好。

但这件事并不容易。因为Prefill阶段生成的KV Cache体积不小，如果Prefill和Decode不在同一台机器上，就意味着缓存需要跨节点传输。这背后会带来通信成本、同步难度、资源衔接的延迟，还有更高的系统设计成本。

所以这里要特别强调一点：PD分离是一种部署和架构层面的能力，不是说“用了某个镜像，就自动有了”。

很多人看到vLLM或者某些推理框架，就以为PD分离是引擎自带的特性。更准确的说法是：引擎内部本来就有Prefill和Decode两个阶段，但能不能真正把它们做成物理上分离、跨实例调度，是更高层面的系统设计问题。

八、vLLM到底解决了什么问题

看到这里，再来看vLLM，就清楚多了。

vLLM并没有改变模型本身，它做的事情是：给大模型推理，搭建一个更适合在线服务的执行引擎。

它之所以被大家广泛关注，不是因为它让模型回答得更聪明，而是因为它能让同一个模型参数、在同样的GPU上，服务更多请求、跑更快的速度、更充分地利用显存。

从架构上看，vLLM至少解决了三类关键问题。

第一，它重新设计了KV Cache的管理方式。Paged Attention让缓存从“连续分配”变成了“分页分配”，显存的碎片和浪费大大减少。

第二，它强化了动态调度能力。Continuous Batching让请求在运行过程中，能持续流动、持续补位，而不是被静态batch限制死。

第三，它把“模型的前向计算”，变成了“系统化执行流程”的一部分。也就是说，vLLM不只是一个负责计算的工具，更像是一个懂调度、懂缓存、懂并发的推理运行环境（runtime）。

如果把一个典型的请求放进vLLM，大致会看到这样一条流程：

用户请求进来后，先进入请求队列；调度器判断这个请求，当前应该进入Prefill队列还是Decode队列；

Prefill处理完之后，生成初始的KV Cache，缓存会按照块/页面的方式，落到显存管理层；

随后请求进入持续的Decode循环，调度器在每一轮都会根据请求的活跃状态，重新组织batch；

有的请求结束了，就释放对应的页面；新的请求则可以随时插进来执行。

这里最值得注意的是：vLLM的快，不是某一个单点优化带来的快，而是整个系统协同起来的快。

它快在显存浪费少了，快在请求补位更及时了，快在GPU空转的时间少了，快在同一个资源池里，能同时维持更多活跃的会话。

换句话说，它本质上是把大模型推理，从“简单调用模型”的问题，提升成了“系统资源调度”的问题。

九、一个vLLM Docker镜像，真正封装的到底是什么

很多人在工程落地的时候，第一次接触vLLM，不是从源码开始，而是从一个镜像开始，比如：

vllm/vllm-openai:v0.9.2

或者你在云环境、Kubernetes环境里看到的其他镜像地址。这时候很容易产生一个误解：以为这个镜像本身，就是某种“推理技术”。

其实不是这样的。

镜像只是一个封装载体，它把一整套能直接运行的推理服务环境，打包在了一起。里面通常包括：

• Python运行环境和相关依赖；

• CUDA、PyTorch等底层环境；

• vLLM推理引擎；

• 兼容OpenAI的接口服务；

• 模型加载和采样的逻辑；

• 调度、缓存、batching等系统实现。

所以更准确地说，这类镜像的意义，不是“它等于Paged Attention或者Continuous Batching”，而是：

它把采用了这些机制的推理服务，打包成了一个可以直接部署的单元。

你启动这个镜像之后，真正运行起来的，往往是一个OpenAI风格的HTTP服务——前面接收客户端的请求，后面由vLLM负责调度模型执行。

请求进来后，内部依然要经过Prefill、Decode、KV Cache分配、批处理调度、采样输出等一整套流程。

如果你从Kubernetes的角度去理解，会更清楚：

客户端的流量进入Pod，Pod里的服务进程接收请求，调用vLLM engine，把用户输入整理成推理任务，再把这些任务交给GPU执行。

在这个过程中，镜像只是运行的形态；真正决定性能好坏的，是镜像里封装的那套推理运行环境（runtime）。

因此，面对这类镜像，更准确的理解方式是：

它不是“模型本身”，也不是“某种优化算法本身”，而是一个把高性能大模型推理服务，完整封装好的部署载体。

十、今天谈大模型推理，本质上是在谈“AI时代的操作系统能力”

如果把整篇文章总结一下，你会发现一个很有意思的现象：

这些听上去像是模型技术的概念，最后都指向了系统工程。

• Prefill和Decode，讲的是任务类型的拆分；

• KV Cache，讲的是显存占用和缓存复用；

• Paged Attention，讲的是内存分页与映射；

• Continuous Batching，讲的是动态调度；

• PD分离，讲的是资源池分工与跨节点协同；

• vLLM，则是把这些能力整合起来，做成了一套可运行的执行系统。

所以今天的大模型推理，越来越像是在重演一遍操作系统和数据库的发展逻辑：当负载规模上来之后，核心竞争力不再只是“能不能算”，而是“能不能高效、稳定、可扩展地算”。

这也是为什么，未来真正能拉开差距的，很可能不是谁先把模型API接好，而是谁先把推理系统做成基础设施。

从这个角度看，vLLM的意义不只是一款开源框架。它更像是一个信号：大模型时代，推理层已经从一个工具问题，升级成了基础设施问题。

结语

大模型推理的本质，就是在有限的GPU资源上，围绕“预测下一个token”这件事，做一整套计算、内存和调度的系统设计。

模型能力决定了上限，推理系统决定了实际体验。

Prefill和Decode，解释了推理为什么天生要分阶段；KV Cache，解释了显存为什么会成为核心瓶颈；

Paged Attention和Continuous Batching，解释了现代引擎为什么能把GPU的效率发挥到极致；

而vLLM，就是把这些思路工程化之后，一种有代表性的实现。

当你再看到一个vllm-openai镜像，或者再听到别人聊“大模型推理优化”时，至少能更清楚地知道：大家讨论的从来不是模型本身，而是一整套让模型真正能服务于现实世界的运行机制。

那么如何学习大模型 AI ？

对于刚入门大模型的小白，或是想转型/进阶的程序员来说，最头疼的就是找不到系统、全面的学习资源，要么零散不成体系，要么收费高昂，白白浪费时间走弯路。今天就给大家精心整理了一份全面且免费的AI大模型学习资源包，覆盖从入门到实战、从理论到面试的全流程，所有资料均已整理完毕，免费分享给各位！

核心包含：AI大模型全套系统化学习路线图（小白可直接照做）、精品学习书籍+电子文档、干货视频教程、可直接上手的实战项目+源码、2026大厂面试真题题库，一站式解决你的学习痛点，不用再到处搜集拼凑！

👇👇扫码免费领取全部内容👇👇

1、大模型系统化学习路线

学习大模型，方向比努力更重要！很多小白入门就陷入“盲目看视频、乱刷资料”的误区，最后越学越懵。这里给大家整理的这份学习路线，是结合2026年大模型行业趋势和新手学习规律设计的，最科学、最系统，从零基础到精通，每一步都有明确指引，帮你节省80%的无效学习时间，少走弯路、高效进阶。

2、大模型学习书籍&文档

理论是实战的根基，尤其是对于程序员来说，想要真正吃透大模型原理，离不开优质的书籍和文档支撑。本次整理的书籍和电子文档，均由大模型领域顶尖专家、大厂技术大咖撰写，涵盖基础入门、核心原理、进阶技巧等内容，语言通俗易懂，既有理论深度，又贴合实战场景，小白能看懂，程序员能进阶，为后续实战和面试打下坚实基础。

3、AI大模型最新行业报告

无论是小白了解行业、规划学习方向，还是程序员转型、拓展业务边界，都需要紧跟行业趋势。本次整理的2026最新大模型行业报告，针对互联网、金融、医疗、工业等多个主流行业，系统调研了大模型的应用现状、发展趋势、现存问题及潜在机会，帮你清晰了解哪些行业更适合大模型落地，哪些技术方向值得重点深耕，避免盲目学习，精准对接行业需求。值得一提的是，报告还包含了多模态、AI Agent等前沿方向的发展分析，助力大家把握技术风口。

4、大模型项目实战&配套源码

对于程序员和想落地能力的小白来说，“光说不练假把式”，只有动手实战，才能真正巩固所学知识，将理论转化为实际能力。本次整理的实战项目，涵盖基础应用、进阶开发、多场景落地等类型，每个项目都附带完整源码和详细教程，从简单的ChatPDF搭建，到复杂的RAG系统开发、大模型部署，难度由浅入深，小白可逐步上手，程序员可直接参考优化，既能练手提升技术，又能丰富简历，为求职和职业发展加分。

5、大模型大厂面试真题

2026年大模型面试已从单纯考察原理，转向侧重技术落地和业务结合的综合考察，很多程序员和新手因为缺乏针对性准备，明明技术不错，却在面试中失利。为此，我精心整理了各大厂最新大模型面试真题题库，涵盖基础原理、Prompt工程、RAG系统、模型微调、部署优化等核心考点，不仅有真题，还附带详细解题思路和行业踩坑经验，帮你精准把握面试重点，提前做好准备，面试时从容应对、游刃有余。

6、四阶段精细化学习规划（附时间节点，可直接照做）

结合上述资源，给大家整理了一份可直接落地的四阶段学习规划，总时长约2个月，小白可循序渐进，程序员可根据自身基础调整节奏，高效掌握大模型核心能力，快速实现从“入门”到“能落地、能面试”的跨越。

第一阶段（10天）：初阶应用

该阶段让大家对大模型 AI有一个最前沿的认识，对大模型 AI 的理解超过 95% 的人，可以在相关讨论时发表高级、不跟风、又接地气的见解，别人只会和 AI 聊天，而你能调教 AI，并能用代码将大模型和业务衔接。

• 大模型 AI 能干什么？
• 大模型是怎样获得「智能」的？
• 用好 AI 的核心心法
• 大模型应用业务架构
• 大模型应用技术架构
• 代码示例：向 GPT-3.5 灌入新知识
• 提示工程的意义和核心思想
• Prompt 典型构成
• 指令调优方法论
• 思维链和思维树
• Prompt 攻击和防范
• …

第二阶段（30天）：高阶应用

该阶段我们正式进入大模型 AI 进阶实战学习，学会构造私有知识库，扩展 AI 的能力。快速开发一个完整的基于 agent 对话机器人。掌握功能最强的大模型开发框架，抓住最新的技术进展，适合 Python 和 JavaScript 程序员。

• 为什么要做 RAG
• 搭建一个简单的 ChatPDF
• 检索的基础概念
• 什么是向量表示（Embeddings）
• 向量数据库与向量检索
• 基于向量检索的 RAG
• 搭建 RAG 系统的扩展知识
• 混合检索与 RAG-Fusion 简介
• 向量模型本地部署
• …

第三阶段（30天）：模型训练

恭喜你，如果学到这里，你基本可以找到一份大模型 AI相关的工作，自己也能训练 GPT 了！通过微调，训练自己的垂直大模型，能独立训练开源多模态大模型，掌握更多技术方案。

到此为止，大概2个月的时间。你已经成为了一名“AI小子”。那么你还想往下探索吗？

• 为什么要做 RAG
• 什么是模型
• 什么是模型训练
• 求解器 & 损失函数简介
• 小实验2：手写一个简单的神经网络并训练它
• 什么是训练/预训练/微调/轻量化微调
• Transformer结构简介
• 轻量化微调
• 实验数据集的构建
• …

第四阶段（20天）：商业闭环

对全球大模型从性能、吞吐量、成本等方面有一定的认知，可以在云端和本地等多种环境下部署大模型，找到适合自己的项目/创业方向，做一名被 AI 武装的产品经理。

• 硬件选型

• 带你了解全球大模型

• 使用国产大模型服务

• 搭建 OpenAI 代理

• 热身：基于阿里云 PAI 部署 Stable Diffusion

• 在本地计算机运行大模型

• 大模型的私有化部署

• 基于 vLLM 部署大模型

• 案例：如何优雅地在阿里云私有部署开源大模型

• 部署一套开源 LLM 项目

• 内容安全

• 互联网信息服务算法备案

• …

👇👇扫码免费领取全部内容👇👇

3、这些资料真的有用吗？

这份资料由我和鲁为民博士(北京清华大学学士和美国加州理工学院博士)共同整理，现任上海殷泊信息科技CEO，其创立的MoPaaS云平台获Forrester全球’强劲表现者’认证，服务航天科工、国家电网等1000+企业，以第一作者在IEEE Transactions发表论文50+篇，获NASA JPL火星探测系统强化学习专利等35项中美专利。本套AI大模型课程由清华大学-加州理工双料博士、吴文俊人工智能奖得主鲁为民教授领衔研发。

资料内容涵盖了从入门到进阶的各类视频教程和实战项目，无论你是小白还是有些技术基础的技术人员，这份资料都绝对能帮助你提升薪资待遇，转行大模型岗位。

这份完整版的大模型 AI 学习资料已经上传CSDN，朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】