从"大力出奇迹"到"四两拨千斤"：DeepSeek用MoE架构上演了一场算力界的"穷人翻身记"——当OpenAI还在烧钱堆GPU时，这家中国公司已经找到了用1/10成本干翻巨头的秘密武器。本文将带你拆解MoE的魔法原理，看清稀疏激活如何让模型既聪明又省钱，彻底搞懂为什么DeepSeek-R1能以557万美元的训练成本，让硅谷巨头们彻夜难眠。

文章目录：

1. 痛点：大模型训练的算力悬崖——为什么Dense架构走到了死胡同？
2. 核心：稀疏激活的魔法——MoE如何让模型"按需用脑"
3. 对比：MoE vs Dense的生死战——参数效率与通信开销的博弈
4. 实战：DeepSeek的MoE设计——256个专家如何协同作战
5. 进化：从GShard到DeepSeek-V3——MoE架构的十年长征
6. 展望：MoE的下一站——动态专家与硬件协同的未来

---

嗨，大家好呀，我是你的老朋友精通代码大仙。接下来我们一起学习 《DeepSeek极简入门与应用》，震撼你的学习轨迹！推荐朋友B占UP：个人快速成长/精进学习

---

“钱不是万能的，但没钱是万万不能的。”

这句老话放在AI大模型领域，简直扎心到骨子里。你是不是也这样——每次看到GPT-4、Claude这些顶尖模型的惊艳表现，心里痒痒的想自己搞一个，但一查训练成本，瞬间被劝退？OpenAI训练GPT-4据说花了1亿美元以上，Anthropic的Claude 3.5也是烧钱大户。作为普通开发者、小团队，甚至是中等规模的AI公司，这种"大力出奇迹"的路线根本玩不起。

更可怕的是，这还不是最糟的。Dense架构（稠密架构）的 scaling law 告诉我们：模型性能提升，需要参数、数据、算力同步指数级增长。这意味着什么？意味着AI正在变成巨头的专属游戏，创业公司的天花板被锁死了。

但就在大家以为"没钱就别玩大模型"的时候，DeepSeek横空出世了。557万美元训练出DeepSeek-V3，性能比肩GPT-4o；R1模型更是让硅谷巨头们彻夜难眠。他们的秘密武器，就是今天要聊的 MoE（Mixture of Experts，混合专家）架构。

搞懂MoE，不仅能让你理解DeepSeek的技术底气，更能看清大模型未来的演进方向。哪怕你现在用不上，知道"四两拨千斤"是怎么做到的，也能在团队讨论、技术选型时多一分底气。咱们这就开始！

---

一、痛点：大模型训练的算力悬崖——为什么Dense架构走到了死胡同？

点题：Dense架构的"全脑激活"困境

传统的大模型，比如早期的GPT-3、LLaMA，用的都是Dense架构。简单说，就是每次推理，模型的所有参数都要参与计算。就像一个学霸做题，不管题目是数学、语文还是英语，他都要把脑子里所有知识全部调动起来。

这种"全脑激活"听起来很猛，但问题也很致命：参数越多，计算量越大，成本越高，而且很多计算其实是浪费的。

痛点分析：新手容易踩的三个大坑

坑一：误以为"参数多=性能好"就是唯一路径

很多刚接触大模型的同学，看到GPT-4万亿参数、LLaMA-3 405B参数，就本能觉得：我也要堆参数！但 Dense 架构下，175B参数的GPT-3训练成本就要1200万美元，405B的LLaMA-3更是天文数字。更惨的是，推理成本也跟着暴涨——每次请求都要跑完整套参数，GPU内存和计算时间都是硬开销。

举个具体例子：假设你用Dense架构训了一个100B参数的模型，推理时需要A100显卡80GB显存，batch size只能开到1，延迟2秒。用户稍微多一点，服务器就扛不住了。这就是很多小团队模型"训出来却用不起"的尴尬。

坑二：忽视"有效参数"与"总参数"的区别

Dense架构有个隐藏陷阱：模型虽然大，但每个token其实只需要特定领域的知识。比如翻译任务，模型不需要调动数学推理能力；写代码时，诗歌创作的知识也是闲置的。但Dense架构不管这些，统统激活，算力浪费严重。

我见过有团队用Dense架构做垂直领域模型，比如法律AI。他们花了大价钱训练，结果发现模型在回答法律问题时，还在"思考"怎么写诗、怎么做菜——这些参数激活了，但对当前任务零贡献。

坑三：scaling law的绝望感

OpenAI的scaling law告诉我们：模型性能提升，需要算力、数据、参数同步增长。Dense架构下，性能提升10%，可能需要算力提升100%。这让很多团队陷入绝望：不烧钱就落后，烧钱又烧不起，怎么办？

解决方案：MoE的"按需激活"思路

MoE的核心洞察很朴素：与其让一个巨型模型什么都学，不如让多个专家各自专精，按需调用。

就像医院里的科室分诊：看病先挂对应科室，而不是让所有医生围着你一个人检查。MoE架构中，输入数据先经过一个"门控网络"（Gating Network），由它决定激活哪些专家，然后只让被选中的专家参与计算。

这样做的好处立竿见影：

• 训练成本：同样性能，MoE只需要激活10%-20%的参数，训练成本大幅下降
• 推理效率：虽然总参数可能更大（比如DeepSeek-V3有671B总参数），但每次只激活37B，实际计算量可控
• 扩展性：增加专家数量，不线性增加计算成本，可以"无痛"扩容

DeepSeek-V3的训练成本只有557万美元，而GPT-4级别的Dense模型可能要1亿美元以上。这就是MoE带来的算力民主化——小团队也能玩大模型了。

小结

Dense架构的"全脑激活"正在把AI变成巨头的游戏，而MoE的"按需激活"打破了这一困局。理解这一点，你就抓住了DeepSeek技术路线的核心逻辑。

---

二、核心：稀疏激活的魔法——MoE如何让模型"按需用脑"

点题：MoE的三层核心机制

MoE不是简单的"分模块"，而是一套精密的协作系统。核心有三层：专家网络（Experts）、门控路由（Router）、负载均衡（Load Balancing）。

痛点分析：新手对MoE的典型误解

坑一：以为MoE就是"多模型集成"

很多人第一次听MoE，以为是像投票机制那样，多个独立模型各出结果再综合。这是错的！MoE的专家网络共享底层表示，门控路由是端到端训练的，不是后期拼装的。如果把MoE当成简单集成，会完全误解它的优势来源。

有个经典反例：早期有团队真的做了"多模型集成版MoE"——训练5个独立小模型，再搞个分类器决定用哪个。结果参数没少多少，推理还更慢了，因为5个模型都要加载到内存。这就是没理解MoE的"稀疏激活"本质。

坑二：忽视门控网络的关键作用

门控网络是MoE的"大脑中的大脑"，但新手常觉得它只是个"开关"，随便做做就行。实际上，门控网络的质量直接决定MoE的上限。如果路由策略糟糕，专家分工混乱，模型性能可能还不如Dense架构。

比如，如果门控网络总是把数学题目路由给"诗歌专家"，把翻译任务路由给"代码专家"，那专家再强也没用。更糟的是，这种错误会在训练中自我强化——错误路由导致专家训练数据偏差，进一步恶化路由质量。

坑三：不懂负载均衡的隐性成本

MoE有个天然风险：专家崩溃（Expert Collapse）——少数热门专家被过度使用，多数专家闲置。如果不加干预，模型会退化成"伪MoE"，实际只用到几个专家，稀疏优势荡然无存。

我见过一个开源MoE实现，作者没加负载均衡损失，训练后发现80%的token被路由到了同一个专家。这相当于花了MoE的成本，得到了Dense的性能，血亏。

解决方案：理解MoE的正确姿势

第一，把握"条件计算"的本质

MoE的核心是条件计算（Conditional Computation）：根据输入动态决定计算路径。这与Dense的"无条件全计算"形成鲜明对比。理解这一点，你就明白为什么MoE能在参数爆炸的同时控制计算量。

具体实现上，门控网络输出一个概率分布，表示每个专家的"相关性得分"。然后选择Top-K个专家（通常是Top-2），用softmax归一化后的权重对专家输出加权求和。

# 简化的MoE前向传播逻辑（示意）
def moe_forward(x, experts, gate):
    # x: 输入 [batch, hidden_dim]
    # gate: 门控网络
    # experts: 专家列表
    
    # 1. 计算路由分数
    router_logits = gate(x)  # [batch, num_experts]
    
    # 2. Top-K选择
    weights, selected_experts = torch.topk(
        torch.softmax(router_logits, dim=-1), 
        k=2  # 通常选Top-2
    )  # weights: [batch, 2], selected_experts: [batch, 2]
    
    # 3. 只计算选中的专家
    output = torch.zeros_like(x)
    for i, expert in enumerate(experts):
        mask = (selected_experts == i).any(dim=-1)  # 哪些样本选了这个专家
        if mask.any():
            expert_input = x[mask]  # 只取相关样本
            expert_output = expert(expert_input)
            # 加权聚合
            expert_weights = weights[mask][selected_experts[mask] == i]
            output[mask] += expert_weights.unsqueeze(-1) * expert_output
    
    return output

第二，重视负载均衡的工程细节

DeepSeek-V3用了多种技巧保证负载均衡：

• 辅助损失（Auxiliary Loss）：惩罚路由不均衡，鼓励均匀使用专家
• 专家容量限制（Expert Capacity）：每个专家每轮最多处理多少token，超出的被跳过
• 本地组限制（Local Grouping）：减少跨设备通信

这些细节看似琐碎，但决定了MoE能否在分布式训练中高效运行。DeepSeek团队在这方面做了大量工程优化，是他们能以低成本训练大模型的关键。

第三，理解"稀疏度"的权衡

不是越稀疏越好。激活专家太少（比如Top-1），模型容量受限；激活太多（比如Top-8），计算成本上升。DeepSeek-V3选择Top-6（从256个专家中选6个），是在性能和效率之间的精心平衡。

小结

MoE的魔法在于"条件计算"——用智能路由实现按需激活。门控网络是大脑，负载均衡是保障，两者缺一不可。搞懂这层，你就超越了80%的"听说过MoE"的人。

---

三、对比：MoE vs Dense的生死战——参数效率与通信开销的博弈

点题：两种架构的全方位PK

MoE不是银弹，它和Dense架构各有优劣。理性选择需要看清 trade-off。

痛点分析：盲目选择架构的代价

坑一：只看总参数，不看激活参数

这是最常见的对比错误。有人说"MoE模型参数太大，部署不了"，但部署成本取决于激活参数，不是总参数。DeepSeek-V3总参数671B，但推理时只加载37B到显存，配合量化技术，单节点就能跑。

反过来，Dense架构的405B模型，是真的要加载405B，显存需求是10倍以上。很多新手被"671B"这个数字吓到，反而错过了更优方案。

坑二：忽视通信开销的"隐形税"

MoE的代价是跨设备通信。专家分散在不同GPU上，路由决策后需要把数据发送到对应设备，这引入了额外延迟。如果集群网络带宽不足，MoE的推理速度可能反而不如Dense。

有个真实案例：某团队用MoE训了个模型，单卡测试很快，但多卡部署后速度暴跌。排查发现是InfiniBand网络配置有问题，专家间通信成了瓶颈。他们花了两周优化网络拓扑，才把性能调上来。

坑三：训练稳定性的幻觉

MoE训练比Dense更不稳定。门控网络的梯度、专家间的负载波动、路由决策的离散性，都增加了训练难度。很多团队低估了这一点，以为"换了架构就能省钱"，结果训练发散、loss震荡，反而浪费了更多资源。

解决方案：理性决策框架

场景一：预算有限，追求性价比 → 选MoE

如果你的目标是"用有限预算获得最强性能"，MoE几乎是必选项。DeepSeek、Mistral、Qwen等主流开源模型都选择了MoE路线，这不是巧合。

具体操作建议：

• 总参数量可以设大（比如100B+），激活参数控制在10-40B
• 重视基础设施：高速网络（RDMA/InfiniBand）是MoE的刚需
• 从小规模验证开始：先用7B-activated的MoE验证流程，再扩展

场景二：延迟敏感，简单任务 → 选Dense

如果应用场景对延迟极度敏感（比如实时对话），或者任务本身很简单（比如文本分类），Dense架构可能更合适。小模型（<7B）的Dense架构，在边缘设备部署上仍有优势。

场景三：已有Dense模型，想升级 → 考虑Upcycling

有个折中方案：把训练好的Dense模型"升级"成MoE。具体做法是把Dense的FFN层替换成MoE层，冻结其他参数继续训练。这样可以复用已有投入，逐步迁移。

关键指标对比表

维度	Dense (405B)	MoE (671B总/37B激活)
训练成本	~$100M+	~$5M
推理显存	需要多节点	单节点可部署
峰值吞吐量	受限于总参数量	可并行更多专家
长尾延迟	稳定	受路由波动影响
微调难度	较低	需要特殊技巧

小结

MoE和Dense不是简单的"新胜旧"，而是不同约束下的最优解。看清自己的场景需求，才能做出理性选择。DeepSeek的成功，正是选对了架构+工程优化到位的结果。

---

四、实战：DeepSeek的MoE设计——256个专家如何协同作战

点题：DeepSeek-V3的架构创新

DeepSeek-V3不是简单的"用MoE"，而是在MoE基础上做了大量原创设计。最核心的是：细粒度专家划分 + 共享专家机制 + 无辅助损失的负载均衡。

痛点分析：常规MoE的瓶颈

瓶颈一：专家颗粒度 dilemma

传统MoE（如Switch Transformer）用较大颗粒度的专家（比如每个专家是标准FFN）。这样专家数量少，路由决策简单，但每个专家的容量受限，难以处理复杂多样的子任务。

如果反过来，专家数量多、每个很小，路由决策更精细，但路由网络负担加重，且容易出现"选择困难"——太多相似专家，门控网络难以区分。

瓶颈二：专家知识的冗余浪费

常规MoE中，所有专家都是"平等"的路由目标。但实际情况是，很多基础知识（如语法、常识）每个专家都需要，造成大量冗余。这就像每个科室都配一个全科医生，资源浪费。

瓶颈三：辅助损失的设计困境

负载均衡通常靠辅助损失实现，但这引入了一个超参数——损失权重。权重太小，均衡没效果；权重太大，干扰主任务学习。调参痛苦，且不同训练阶段最优权重可能不同。

解决方案：DeepSeek的三板斧

第一板斧：细粒度专家划分

DeepSeek-V3把专家切得更细：256个路由专家，每个只有传统FFN的1/8大小。但激活时选Top-6，总计算量相当。

这样做的好处：

• 路由精度提升：更多专家=更细粒度的 specialization
• 组合灵活性：6个小专家可以组合出更多功能模式
• 容错性更好：单个专家失效影响更小

类比一下：传统MoE像"选科室"，DeepSeek像"选医生组"——更精细的分工，更灵活的组合。

第二板斧：共享专家机制

DeepSeek-V3设置了1个共享专家，始终激活，不参与路由竞争。这个专家负责学习通用、跨领域的知识，让路由专家可以专注于各自专长。

这就像医院里的"基础医疗部"——常规检查、通用处理走这里，专科专家只处理复杂病例。共享专家的存在，显著减少了路由专家间的知识冗余，提升了参数效率。

实测表明，加入共享专家后，在相同总参数量下，模型下游任务性能提升2-3个百分点，同时路由专家的 specialization 更明显。

第三板斧：无辅助损失的负载均衡

这是DeepSeek最硬核的创新。他们设计了一种纯路由策略的负载均衡机制，不需要辅助损失：

1. 序列级负载均衡：在序列维度上统计专家使用频率，动态调整路由偏置
2. 设备级负载均衡：考虑专家在不同设备的分布，优先选择本地专家减少通信
3. 通信优化：结合EP（Expert Parallelism）和TP（Tensor Parallelism），最小化跨节点流量

具体实现上，门控网络的输出会加上一个可学习的偏置项（bias），这个偏置根据历史负载动态调整。热门专家的偏置降低，冷门专家的偏置提高，自然达到均衡。

这样做的好处是不干扰主任务梯度，训练更稳定。DeepSeek-V3的训练曲线非常平滑，没有常见MoE的震荡问题。

工程细节：DeepSeek的并行策略

• EP=64：256个专家分布在64个节点，每个节点4个专家
• TP=8：每个专家内部用8路张量并行
• DP=16：数据并行度16，全局batch size = 16 × 单节点batch

这种配置下，DeepSeek-V3在2048块H800上高效训练，MFU（Model FLOPs Utilization）达到42%，在MoE模型中属于顶尖水平。

小结

DeepSeek-V3的MoE不是照搬论文，而是针对工程实践做了大量创新。细粒度专家、共享机制、无辅助损失均衡，三板斧下去，实现了性能与效率的双赢。理解这些细节，才能真正学到"中国速度"背后的技术底气。

---

五、进化：从GShard到DeepSeek-V3——MoE架构的十年长征

点题：MoE的技术演进史

MoE不是新概念，但直到近年才在大模型时代焕发新生。看清演进脉络，才能预判未来方向。

痛点分析：历史教训与认知误区

误区一：以为MoE是"新发明"

很多文章把MoE包装成2020年后的新东西，这是错误的。MoE的思想可以追溯到1991年Jacobs等人的论文，甚至Hinton在2017年就提出了现代MoE的雏形。真正的新东西是"大规模分布式MoE的工程实现"，不是概念本身。

这种误解会导致低估工程优化的价值——以为换个架构就能成功，忽视了DeepSeek在并行策略、通信优化、负载均衡上的大量工作。

误区二：忽视Google的开源贡献

国内有些声音把MoE的功劳全归于DeepSeek，这不公平。Google的GShard、Switch Transformer、GLaM系列奠定了现代MoE的基础框架，论文和代码都开源了。DeepSeek是在巨人肩膀上创新，不是从零开始。

认清这一点，有助于我们理性学习：既要学DeepSeek的优化技巧，也要读Google的原始论文，构建完整的知识体系。

误区三：过度关注参数规模，忽视效率指标

早期MoE竞赛陷入"参数越大越好"的误区。Google的1.6T Switch Transformer确实震撼，但推理效率并不理想。后来的演进证明，激活效率、通信开销、实际吞吐才是更关键的指标。

解决方案：站在历史肩膀上的学习路径

阶段一：理解GShard的奠基意义（2019）

GShard的核心贡献：

• 证明了MoE可以扩展到数千亿参数
• 提出了Expert Parallelism的分布式方案
• 设计了首个大规模负载均衡机制

关键论文：《GShard: Scaling Giant Models with Conditional Computation and Automatic Sharding》

阶段二：学习Switch Transformer的简化哲学（2021）

Switch Transformer把MoE简化到极致：

• 每个token只路由到1个专家（Top-1）
• 专家容量直接等于batch size / 专家数
• 辅助损失设计更简洁

这种简化降低了训练不稳定风险，但代价是表达能力。后来的工作（包括DeepSeek）又回归Top-K，但Switch的简化思想值得学习。

阶段三：研究DeepSeek的本土化创新（2023-2024）

DeepSeek的几篇关键论文：

• 《DeepSeek-V2: A Strong, Economical, and Efficient Mixture-of-Experts Language Model》（MLA注意力机制）
• 《DeepSeek-V3 Technical Report》（完整MoE设计）

核心创新点对比：

特性	Switch Transformer	DeepSeek-V3
专家数	2048	256
激活策略	Top-1	Top-6 + 共享专家
负载均衡	辅助损失	无辅助损失
注意力	标准MHA	MLA（多头潜在注意力）
训练成本	未公开	557万美元

阶段四：关注R1的推理优化（2025）

DeepSeek-R1在MoE基础上，进一步针对推理场景优化：

• 推理时扩展（Inference-time scaling）
• 强化学习驱动的路由策略
• 长思维链（CoT）的高效生成

这标志着MoE从"训练效率优化"走向"全生命周期优化"。

小结

MoE的演进是一部"从学术概念到工程落地"的奋斗史。DeepSeek的成就，是站在Google等先驱肩膀上，结合中国工程团队的成本意识和优化能力，实现的弯道超车。学技术要懂历史，才能预判未来。

---

六、展望：MoE的下一站——动态专家与硬件协同的未来

点题：MoE的三个前沿方向

MoE架构还在快速演进，三个方向值得关注：动态专家数量、硬件协同设计、开源生态普惠。

痛点分析：当前MoE的未解难题

难题一：专家数量的僵化

现在的MoE，专家数量是训练前固定的。但不同输入的复杂度差异巨大：简单问候不需要动用专家，复杂推理可能需要更多专家协作。固定专家数是一种浪费。

难题二：硬件利用的错配

GPU/TPU的设计假设是"密集计算"，但MoE是"稀疏激活+频繁通信"。这种错配导致：专家并行时，GPU计算单元闲置等数据；数据并行时，通信带宽成为瓶颈。我们需要"为MoE设计的芯片"。

难题三：MoE的"贵族化"趋势

虽然DeepSeek降低了训练成本，但MoE的高效实现仍需要高端集群、高速网络、专业团队。小团队、个人开发者、边缘场景，还是难以享受到MoE的红利。技术民主化尚未完成。

解决方案：前沿探索与可行路径

方向一：动态专家架构（Dynamic MoE）

研究热点包括：

• 输入自适应路由：根据输入复杂度，动态决定激活专家数量。简单输入用1个专家，复杂输入用8个甚至更多。
• 层级化专家：底层用少量大专家处理通用模式，上层用大量小专家处理细分任务，形成"专家树"。
• 持续学习扩展：训练后遇到新领域，动态添加新专家，不遗忘旧知识。

DeepSeek已经在探索相关方向，R1的某些设计体现了"动态计算图"的思想。

方向二：硬件协同优化

几个值得关注的硬件趋势：

• 专家感知芯片：如Groq的LPU、SambaNova的RDU，针对稀疏计算优化内存访问模式
• 近存计算（PIM）：把计算放到HBM内存旁边，减少专家权重的搬运开销
• 光互连网络：用光纤替代电信号，解决专家并行的通信瓶颈

DeepSeek与国产芯片厂商（如华为昇腾）的合作，也在探索MoE的本土化部署方案。

方向三：开源生态的MoE普惠

让MoE惠及更多开发者的实践：

• 小型MoE模型：如Qwen的0.5B-activated MoE，手机端可运行
• MoE微调框架：如Hugging Face的Megablocks、Fairseq的MoE组件，降低上手门槛
• 领域专用MoE：针对法律、医疗、教育等垂直场景，预训练专用专家组合

给开发者的行动建议

1. 短期（3-6个月）：用DeepSeek-R1或Qwen-MoE做项目，体验MoE的实际效果
2. 中期（6-12个月）：学习MoE的微调技巧，尝试领域适配
3. 长期（1-2年）：关注动态MoE和边缘部署进展，准备技术迁移

小结

MoE的未来不是"更大"，而是"更聪明"——动态适应、硬件协同、普惠开源。DeepSeek打开了一扇门，门后的世界需要更多人一起探索。

---

写在最后

聊完MoE的前世今生，我想和你分享一个感受。

AI领域这几年变化太快，快得让人焦虑。GPT-4还没消化完，Claude 3.5来了；Claude还没用熟，DeepSeek-R1又炸了。很多开发者问我：“大仙，我是不是永远追不上了？”

我的回答是：技术浪潮一波接一波，但底层的认知积累是永恒的。

今天学的MoE，不只是"一个架构技巧"。它代表了一种思维方式：面对资源约束，如何通过智能设计实现突破。这种思维，在Dense架构时代用不上，但在MoE时代是核心；未来出现新架构，这种思维依然有价值。

DeepSeek的故事特别励志。一家中国公司，没有OpenAI的算力储备，没有Google的人才密度，硬是靠着对MoE的深度理解和工程极致优化，做出了世界级模型。这证明了一件事：在AI领域，聪明比有钱更重要，理解比堆砌更值钱。

作为开发者，我们可能没有训练千亿参数模型的机会，但理解MoE的原理，能让我们：

• 在技术选型时做出更理性的判断
• 在使用开源模型时发挥更大效能
• 在团队讨论时贡献更有价值的见解
• 在技术浪潮来临时更快抓住本质

编程之路不易，但每一步成长都算数。MoE架构从1991年走到今天，经历了无数次"这玩意儿没用"的质疑，最终在大模型时代证明了自己。你的学习积累也是如此，那些看似无用的深度理解，终将在某个时刻发光。

保持好奇，持续学习，你也能成为代码高手。咱们下篇见！

---

推荐朋友B占UP：个人快速成长/精进学习资料
+微辛备注：“资料代找获取”，全网计算机学习资料代找：例如:
《课程：2026 年多模态大模型实战训练营》
《课程：AI 大模型工程师系统课程 (22 章完整版 持续更新)》
《课程：AI 大模型系统实战课第四期 (2026 年开课 持续更新)》
《课程：2026 年 AGI 大模型系统课 23 期》
《课程：2026 年 AGI 大模型系统课 21 期》
《课程：AI 大模型实战课 8 期 (2026 年 2 月最新完结版)》
《课程：AI 大模型系统实战课三期》
《课程：AI 大模型系统课程 (2026 年 2 月开课 持续更新)》
《课程：AI 大模型全阶课程 (2025 年 12 月开课 2026 年 6 月结课)》
《课程：AI 大模型工程师全阶课程 (2025 年 10 月开课 2026 年 4 月结课)》
《课程：2026 年最新大模型 Agent 开发系统课 (持续更新)》
《课程：LLM 多模态视觉大模型系统课》
《课程：大模型 AI 应用开发企业级项目实战课 (2026 年 1 月开课)》
《课程：大模型智能体线上速成班 V2.0》
《课程：Java+AI 大模型智能应用开发全阶课》
《课程：Python+AI 大模型实战视频教程》
《书籍：软件工程 3.0: 大模型驱动的研发新范式.pdf》
《课程：人工智能大模型系统课 (2026 年 1 月底完结版)》
《课程：AI 大模型零基础到商业实战全栈课第五期》
《课程：Vue3.5+Electron + 大模型跨平台 AI 桌面聊天应用实战 (2025)》
《课程：AI 大模型实战训练营 从入门到实战轻松上手》
《课程：2026 年 AI 大模型 RAG 与 Agent 智能体项目实战开发课》
《课程：大模型训练营配套补充资料》