你的多模态RAG不是慢在模型上，而是慢在"瞎选"和"蛮算"上：一份从Embedding选型到推理引擎调优的"避坑+提速"完全指南，看完至少省下一半GPU预算。

文字目录

• 要点一：Embedding模型选型：不是越大越好，而是越"配"越好
• 要点二：视觉编码器与VLM主干：分辨率与架构的隐形博弈
• 要点三：量化与知识蒸馏：给模型"瘦身"的科学姿势
• 要点四：KV-Cache与显存管理：别让显存成了性能天花板
• 要点五：Continuous Batching与请求调度：榨干GPU的最后一滴算力
• 要点六：多模态索引与流水线解耦：从"串行阻塞"到"并行飞起"

---

嗨，大家好呀，我是你的老朋友精通代码大仙。接下来我们一起学习 《大模型RAG生成式AI开发实战》39.[第4章 多模态RAG] 多模态RAG性能优化：模型选择和推理加速。

咱们程序员圈里有句话特别真实：“小孩才做选择，大人全都要。” 但放在多模态RAG这件事上，如果你不做取舍、不讲策略，搞不定"既要效果又要速度"的平衡，那最后的结果很可能是一个都要不到。很多新手同学刚搭起一个能跑通的多模态RAG demo，就急着上线，结果发现 GPU 风扇转得跟直升机似的，QPS 却低得可怜，用户问一个问题要等五秒以上，体验直接崩盘。你是不是也这样？看着满屏的 CUDA out of memory 和高达几秒的延迟，心里拔凉拔凉的，甚至开始怀疑是不是自己的显卡太垃圾？

别慌，今天咱们就把这事儿掰开了、揉碎了讲清楚。性能优化不是玄学，而是一门"把钱花在刀刃上"的工程手艺。接下来这六个关键要点，都是我从一个个坑里爬出来后总结的干货。坐稳了，咱们发车。

---

要点一：Embedding模型选型：不是越大越好，而是越"配"越好

点题

多模态RAG的第一步，就是把图片、文本甚至音频变成机器能读懂的向量。这个"翻译官"就是多模态Embedding模型。选得好，后续检索事半功倍；选错了，后面接再强的生成模型也是白搭。很多新手在这里有一个根深蒂固的误区：参数越大、名气越响的模型，效果一定越好。

痛点分析

我见过太多同学一上来就搬出 OpenAI 的 CLIP ViT-L/14，或者最大号的 SigLIP，觉得"大即是正义"。想法可以理解，但坑也埋得稳稳的。第一个坑是场景错配。CLIP 这种通用模型，它见过的数据是互联网上的通用图文对，你拿它去检索专业领域的细粒度图片，比如医疗影像里的 CT 切片、工业质检里的零件瑕疵图、电商领域的 SKU 商品图，它的语义粒度根本对不上。张三做过一个电商商品图检索系统，用 CLIP ViT-L/14，想搜"红色连衣裙"，结果 Top3 里混进来一个"红色消防栓"。为啥？因为通用模型学到的"红色"是一个宏观概念，它不懂电商场景下的"款型、材质、领型"这些细粒度属性。

第二个坑是资源错配。ViT-L/14 这种级别的大 Embedding 模型，单卡显存占用能干到 12GB 以上，推理延迟高，QPS 根本上不去。你本来想做个高并发的检索服务，结果 Embedding 服务成了瓶颈，GPU 全被它吃光了，后面的大模型连汤都喝不上。

# 新手的暴力选型：只看名字带Large就冲
from transformers import CLIPModel, CLIPProcessor

model = CLIPModel.from_pretrained("openai/clip-vit-large-patch14").cuda()
processor = CLIPProcessor.from_pretrained("openai/clip-vit-large-patch14")

# 在自己的工业零件数据集上直接提取特征
# 结果：Top5 准确率不到 40%，单卡 QPS 只有 5，显存爆了

解决方案/正确做法

Embedding 选型，本质上是相亲，合适比优秀重要一百倍。第一步，先认清你的场景。如果是通用图文检索，SigLIP、EVA-CLIP-CLIP 这些确实不错；但如果是垂直领域，优先去找领域专用模型。比如做时尚电商，有 Fashion-CLIP；做中文多模态，有 BGE-VL 系列；做文档理解，有 ColPali、ColQwen 这种 Late Interaction 模型。这些模型要么在垂直数据上预训练过，要么架构上更适合细粒度对齐。

第二步，轻量化优先，微调跟上。很多场景下，一个 300MB 的小模型经过你的数据微调后，检索效果能吊打 3GB 的通用大模型。不要迷信零样本能力，RAG 系统里最不缺的就是你自己的业务数据，拿它来做个对比学习微调，收益极高。

# 聪明人的选型：按场景匹配，轻量+可微调
from sentence_transformers import SentenceTransformer

# SigLIP-base 在多数任务上已经足够，且速度快 3 倍以上
model = SentenceTransformer("sentence-transformers/siglip-base-patch16-224")

# 如果有垂直数据，接一段对比学习微调
# 训练后在自己的测试集上评估 Recall@5 和 QPS
# 结果：显存降到 3GB，QPS 提到 50+，准确率反而涨了 15%

这样做的好处显而易见：省下的显存可以留给后面的生成模型，省下的延迟可以直接转化为用户体验。而且维护一个轻量模型，后续迭代、部署、横向扩容都轻松得多。

小结

Embedding 选型不是选美比赛，是相亲。别只看参数量和论文标题，要看它懂不懂你的业务，能不能在你的硬件上跑得欢。

---

要点二：视觉编码器与VLM主干：分辨率与架构的隐形博弈

点题

图片进入大模型的"眼睛"，全靠视觉编码器（Vision Encoder）。选什么骨干网络、喂多高分辨率、产生多少视觉 Token，这三个因素像一张看不见的网，直接把下游 VLM 的推理速度和理解能力捆绑死了。新手往往只关注 LLM 部分的参数量，却忽略了视觉端才是拖慢推理的隐形杀手。

痛点分析

最普遍的误区叫**“分辨率崇拜”**。很多人觉得，图片分辨率越高，模型看得越清楚，回答就越准。于是 224x224 的不敢用，非要上 336x336，甚至 448x448、672x672。但他们没算过一笔账：在 ViT Patch Size=14 的情况下，一张 336x336 的图片会产生 (336/14)^2 = 576 个视觉 Token；如果拉到 672x672，就是 2304 个 Token。这什么概念？LLM 处理这些视觉 Token 的计算量和显存占用，是跟着 Token 数线性甚至平方级增长的。你的 Context Window 本来能塞 5 篇检索回来的文档，结果一张大图直接占掉一半，文本没地方放了，生成速度还暴跌。

李四就踩过这个坑。他的多模态 RAG 处理 PDF 文档截图，用了 LLaVA-1.5 的 336x336 配置。结果一张满屏表格产生 500 多个视觉 Token，加上检索回来的文本和 Prompt，输入长度直接超长。TPOT（Time Per Output Token）从 50ms 涨到 200ms，用户每等一个字都像过了一年。而且他还分不清 ViT、ConvNeXt、SAM 这些骨干网的特性，只觉得"能用就行"，结果选的模型视觉端又重又慢，LLM 部分反而成了陪衬。

# 痛点的典型代码：一股脑高分辨率，所有图一视同仁
from transformers import LlavaNextProcessor, LlavaNextForConditionalGeneration

processor = LlavaNextProcessor.from_pretrained("llava-hf/llava-v1.6-34b-hf")
# 不管输入是简单图标还是复杂表格，全部强制 resize 到 336x336
inputs = processor(images=[image1, image2, image3], return_tensors="pt", padding=True)
# 小图标也被拉成 336x336，产生大量无意义 Token

解决方案/正确做法

核心策略是按需分配，动态压缩。现在的先进模型，比如 Qwen2-VL、InternVL2、Mini-Monkey，都支持动态分辨率。简单说，系统会根据图片本身的复杂度和尺寸，自动决定切成几块、每块多大，而不是暴力拉伸到固定尺寸。简单图标可能只用 224x224 甚至更低，复杂表格才启用高分辨率。这样视觉 Token 的平均数量能下降 30%-50%，速度直接起飞。

其次，关注视觉投影层的设计。很多早期 VLM 是视觉 Token 直接硬塞进 LLM，Token 数完全由分辨率决定。而新架构里，Perceiver Resampler、Pixel Shuffle、或 Q-Former 这类压缩层，可以把几百个视觉 Token 压缩到几十个甚至几个，让 LLM 的负担大幅减轻。如果你的业务里图片信息密度不高（比如 LOGO 识别、简单图标理解），优先选带 Token 压缩机制的模型。

# 正确姿势：拥抱动态分辨率
from transformers import Qwen2VLForConditionalGeneration, AutoProcessor

model = Qwen2VLForConditionalGeneration.from_pretrained(
    "Qwen/Qwen2-VL-7B-Instruct",
    torch_dtype="auto",
    device_map="auto"
)
processor = AutoProcessor.from_pretrained("Qwen/Qwen2-VL-7B-Instruct")

# Qwen2-VL 内部会根据原图尺寸计算最优 Token 数
# 简单图可能只有 64 个视觉 Token，复杂表格自动切分到 448x448
# 实测：视觉 Token 平均减少 40%，推理速度提升 2 倍，准确率不降反升

小结

视觉编码器的核心矛盾是"看得清"和"算得快"。拒绝暴力高分辨率，拥抱动态分辨率与 Token 压缩，你的 VLM 才能真正"眼明手快"。

---

要点三：量化与知识蒸馏：给模型"瘦身"的科学姿势

点题

7B 的 VLM 在单卡 A100 上跑已经有点吃力，34B 的更是直接劝退。但业务要求必须快、必须省显存，怎么办？量化和蒸馏就是两大科学减肥法。问题是，很多新手要么不敢用，要么用得太粗暴，直接把模型性能给"减残"了。

痛点分析

第一个误区是闻量化色变。有些同学觉得 INT8、INT4 就是"偷工减料"，精度肯定崩。其实现代量化技术（AWQ、GPTQ、SmoothQuant）已经相当成熟，但很多新手不知道怎么针对多模态模型做分层量化。多模态模型里，视觉编码器对数值精度极其敏感，因为它的特征是浮点矩阵乘法累加出来的，低 bit 很容易把颜色、纹理、空间关系的细节给抹平。王五就吃过这个亏：他把 Qwen-VL-Chat 7B 用 GPTQ 做了暴力 INT4 量化，LLM 和 Vision Encoder 一起砍。结果模型体积确实减半了，但做 RAG 增强问答时，把图表里的"蓝色曲线"识别成"绿色曲线"，把数字"3.14"读成"3.11"。因为视觉端的激活值分布本来就很分散，低 bit 量化直接把边界特征给吃了。

第二个误区是不知道蒸馏该蒸哪。多模态模型的知识不光在 LLM 里，还在视觉-语言对齐层（Projection Layer）里。你拿 GPT-4V 生成一堆答案，然后只去蒸馏学生模型的文本生成能力，而不管图片怎么映射到文本空间，那学生还是"睁眼瞎"。

# 错误示范：暴力全量化，视觉+文本一起砍
# 用 AutoGPTQ 加载后直接推理
from auto_gptq import AutoGPTQForCausalLM

model = AutoGPTQForCausalLM.from_quantized(
    "Qwen-VL-Chat-7B-GPTQ-int4",
    device="cuda:0"
)
# 推理时发现：颜色错乱、图表数字识别错误、细粒度图文对齐失效

解决方案/正确做法

正确的量化策略叫**“分区保护”**。视觉编码器尽量保持 FP16 或至少 INT8，而对计算量大、鲁棒性强的 LLM 部分做 INT4/INT8 量化。AWQ（Activation-aware Weight Quantization）因为考虑了激活值分布，对多模态场景更友好。在实际部署中，vLLM、LMDeploy 这些推理框架都支持加载 AWQ/GPTQ 模型，而且会自动处理分区加载。

如果你不想自己折腾量化，更省心的办法是直接选用已经蒸馏好的轻量 VLM。比如 TinyLlava、MobileVLM、Bunny 系列，它们通常基于 Phi-2、StableLM 这类小 LLM，配合轻量视觉编码器（如 SigLIP-base），在 2B-3B 参数规模下能达到 7B 模型 85%-90% 的能力。多模态蒸馏的关键，是要用强教师模型（GPT-4V、Qwen-VL-Max）生成高质量的指令微调数据，然后在训练学生模型时，不光蒸馏文本输出，还要对齐视觉到文本的映射空间。

# 正确姿势：LLM 量化，视觉保精度；或直接用小模型
from vllm import LLM

# AWQ 量化只作用于 LLM，视觉编码器内部自动保持 FP16
llm = LLM(
    model="Qwen2-VL-7B-Instruct-AWQ",
    quantization="awq",
    dtype="auto",
    gpu_memory_utilization=0.85
)

# 或者直接用 Bunny-3B 这类蒸馏小模型
# 推理速度快 3 倍，显存占用 1/3，标准 benchmark 达 7B 模型 90% 性能

小结

量化不是无脑砍精度，而是"哪里耐砍砍哪里"；蒸馏不是照抄答案，而是"偷师学艺取其精华"。保护视觉端的敏感神经，你的小模型也能有大智慧。

---

要点四：KV-Cache与显存管理：别让显存成了性能天花板

点题

做过 LLM 推理的同学都知道，模型参数只占显存的一部分，真正的大户是 KV-Cache。在多模态 RAG 里，这个矛盾更尖锐：视觉 Token 加长文本 Token，再加上检索回来的上下文，KV-Cache 能把你的 A100 直接撑爆。不会管显存，就像开着法拉利却堵在早高峰——马力再强也白搭。

痛点分析

新手写推理服务，最常见的姿势是直接调用 HuggingFace 的 model.generate()。这种方式的 KV-Cache 管理非常原始：要么随用随扔（无法复用历史对话），要么连续分配（产生大量显存碎片）。当你想同时服务多个用户时，每个请求都要占一大块连续显存存 Key 和 Value，结果来了三四个请求就 OOM，只能串行处理。赵六就遇到过这种事：他用 vLLM 跑多模态 RAG，但没去调 gpu_memory_utilization，默认 0.9。多模态场景下，图片经过 Vision Encoder 后的 feature 矩阵先占一大块，再加上暴涨的 KV-Cache，服务一压测就崩。他原以为是 7B 模型太大，想升级硬件，其实是显存管理没入门。

另一个隐形杀手是注意力架构。如果你用的是传统的 MHA（Multi-Head Attention），每个头都有独立的 K 和 V，显存占用随头数线性增长。而 MQA（Multi-Query Attention）和 GQA（Grouped-Query Attention）能大幅压缩这部分开销。很多新手选型时不看这个细节，选了老架构的模型，白白浪费显存。

# 痛点代码：HF 原生推理，KV-Cache 无管理
from transformers import AutoModelForVision2Seq

model = AutoModelForVision2Seq.from_pretrained("some-vlm").cuda()
# 每次 generate 都重新分配 KV-Cache，无法共享，无法分页
outputs = model.generate(**inputs, max_new_tokens=512)
# 并发一高就 OOM，GPU 利用率不到 30%

解决方案/正确做法

modern 的解法就两个词：PageAttention 和 GQA。PageAttention 是 vLLM 提出的核心创新，它把 KV-Cache 从连续的显存块改成非连续的"页"（Page），像操作系统的虚拟内存一样按需分配、动态映射。这样显存碎片几乎为零，同一个 batch 里能塞的请求数翻几倍。vLLM、SGLang、LMDeploy 都已经内置了 PageAttention 或改进版的 RadixAttention。

在多模态场景下，你还需要特别关注 max_model_len 和 max_num_batched_tokens 的配置。视觉 Token 往往很长，如果设得太保守，GPU 算力用不满；设得太激进，显存又扛不住。建议根据你的平均输入图片尺寸和文本长度，实测一个甜点值。另外，选型时优先挑支持 GQA/MQA 的 VLM，比如 Qwen2-VL、LLaMA 3.2 Vision、InternLM-XComposer2，它们的 KV-Cache 占用只有传统 MHA 的 1/8 到 1/4。

# 正确姿势：vLLM + PageAttention + 合理显存预算
from vllm import LLM, SamplingParams

llm = LLM(
    model="Qwen2-VL-7B-Instruct",
    tensor_parallel_size=1,
    gpu_memory_utilization=0.85,  # 留出 15% 缓冲，防止多模态 feature 爆显存
    max_model_len=4096,           # 根据业务实测调整
    enforce_eager=False           # 启用 CUDA Graph，进一步降低延迟
)

sampling_params = SamplingParams(temperature=0.2, max_tokens=512)
# 同样 A100，并发从 4 路提升到 32 路，TTFT 从 2s 降到 300ms

小结

KV-Cache 不是负担，是没被管好的资源。PageAttention 加上 GQA，就是多模态 RAG 推理的"显存管家"。

---

要点五：Continuous Batching与请求调度：榨干GPU的最后一滴算力

点题

你的 GPU 算力很贵，每一秒闲置都是在烧钱。但传统的推理方式，却让 GPU 把大量时间浪费在"等数据"和"等队友"上。Continuous Batching 和智能调度，就是让你的算力从"单线程"升级到"高并发"的关键。

痛点分析

最经典的反模式叫静态批处理（Static Batching）。服务层攒够 8 个请求才打包发给模型，如果第 8 个请求来得慢，前 7 个就得干等着。更离谱的是，一个 batch 里各个请求的生成长度不一样，短的早就做完了，却必须等最长的那个一起收尾，GPU 空转。多模态场景下还有额外暴击：不同请求的图片分辨率天差地别。钱七的系统里，有人传了 1MB 的 8K 截图，有人传了几十 KB 的小图标。静态 batching 为了张量对齐，会把所有图片 padding 到最大尺寸，小图标明明只需要 64 个视觉 Token，硬被 padding 到 1024，七分之八的计算都喂了空气。

另一个坑是长请求堵塞。一个用户扔了本 50 页的 PDF，Prefill 阶段要算好几秒。如果是传统的"一个 batch 跑完再跑下一个"，后面所有用户都得排队等这位大爷算完，P99 延迟直接爆炸。

# 静态批处理的伪代码：低效且浪费
def static_batch_infer(requests):
    # 攒够 batch_size 才发车
    while len(buffer) < 8:
        wait()
    
    # 为了对齐，所有图片 padding 到最大分辨率
    padded_images = [pad_to_max(req.image) for req in buffer]
    # 小图也按大图算，大量无效计算
    outputs = model.generate(padded_images)

解决方案/正确做法

modern 推理框架（vLLM、TGI、SGLang）都支持 Continuous Batching，也叫 In-flight Batching。它的核心思想是：新请求随时插进正在跑的 batch，先完成的随时撤。GPU 永远有活干，不会有"等齐人"的空窗期。再配合 Chunked Prefill，把长请求的 Prefill 阶段拆成一小块一小块，跟 Decode 阶段交错执行，一个长请求再也堵不住整条路了。

在多模态 RAG 里，还有一层优化叫异步预处理。图片的 resize、normalize、OCR 这些操作，别放在 GPU 主线程里干。扔给 CPU 的线程池或者独立的预处理服务，处理完了再把干净的张量喂给 GPU。这样 GPU 只做它最擅长的矩阵乘法，不被图像解码拖累。

# 正确姿势：vLLM AsyncLLMEngine + Chunked Prefill
from vllm import AsyncLLMEngine, AsyncEngineArgs

engine_args = AsyncEngineArgs(
    model="Qwen2-VL-7B-Instruct",
    enable_chunked_prefill=True,   # 长请求不堵路
    max_num_batched_tokens=2048,   # 控制 batch 粒度
    max_num_seqs=64                # 最大并发序列数
)

# 图片预处理异步化，不占用 GPU 主线程
# 实测：峰值吞吐量从 12 req/s 提升到 85 req/s，P99 延迟下降 60%

小结

GPU 的算力很贵，别让它在等数据和等队友上浪费生命。Continuous Batching 加上异步预处理，才能让每一毫秒的算力都花在刀刃上。

---

要点六：多模态索引与流水线解耦：从"串行阻塞"到"并行飞起"

点题

RAG 的全链路延迟，有时候最大的瓶颈不在生成，而在"找"的过程和"传"的过程。多模态索引怎么建、流水线怎么串，决定了你的系统能不能从 demo 级别跃升到生产级别。

痛点分析

很多新手做多模态 RAG，直接照搬纯文本那套：图片扔给 CLIP 出一个向量，文本扔给 BERT 出一个向量，然后只跑向量检索。这套打法有两个致命伤。第一，语义粒度太粗。一张 PDF 整页截图只出一个向量，用户问"第三段说的销售额是多少"，召回的却是整页向量，噪声里裹着金子，生成模型根本找不着北。第二，检索手段单一。遇到"找一张红色圆形按钮的截图"这种带颜色、形状、位置的细粒度需求，纯向量检索完全抓瞎，因为它学的是语义相似度，不是视觉属性。

孙八就栽在这里。他的系统处理 10MB 的 PDF，先整页转图片，再整张图扔给 CLIP，一页一个向量。用户问细节问题，召回的上下文全是整页噪声，准确率惨不忍睹。而且他的架构是单体式：上传→OCR→Embedding→入库→检索→生成，全在一个进程里串行。用户上传一张图，端到端等 5 秒以上，数据库阻塞、模型阻塞、文件 IO 阻塞，全部搅在一起。

# 痛点架构：单体式串行处理
def handle_request(image):
    text = ocr(image)              # 阻塞 1s
    vec = embedding(image)         # 阻塞 500ms
    store_to_db(vec)               # 阻塞 200ms
    context = retrieve(vec)        # 阻塞 100ms
    answer = generate(context)     # 阻塞 3s
    return answer                  # 总延迟 > 5s，任何一步卡住全完

解决方案/正确做法

检索层要升级到混合检索。不要只依赖向量，要加入属性过滤（颜色、标签、文档页码）、关键词检索（BM25）、甚至多向量列（图片一个向量、文本一个向量、表格结构化数据单独存）。文档类场景，先经过布局分析（Layout Analysis），把 PDF 切成段落、表格、图片块，分别建索引。图片块用多模态 Embedding，文本块用 BGE-M3 这类支持稀疏+稠密+多语言的模型，表格走专用 Parser 转成 HTML/Markdown 再入向量库。召回时多路齐发，重排序（Rerank）阶段再精排。

架构层要做微服务解耦。用消息队列（Redis Stream、RabbitMQ、Kafka）把流水线拆开：上传服务→预处理服务→OCR 服务→向量化服务→入库服务，各管一段，异步进行。用户查询时，走独立的高并发检索链路，和入库链路完全隔离。这样系统吞吐不再受最慢环节拖累，而且可以单独扩容瓶颈节点。

# 正确架构：混合索引 + 异步流水线
# 1. 布局分析切分文档（Unstructured / PP-Structure）
chunks = layout_analysis(pdf_page)  # 切出段落、表格、图片

# 2. 多路向量入库
# 文本块 -> BGE-M3（支持稀疏+稠密）
# 图片块 -> SigLIP / ColQwen（Late Interaction，细粒度对齐）
# 表格块 -> 结构化数据 + 文本混合

# 3. 检索时多路召回 + Rerank
# 向量召回 Top20 + BM25 召回 Top20 -> Cross-Encoder 重排 -> Top5 送入 VLM

# 4. 微服务异步解耦，端到端延迟从 5s 降到 1.2s，支持百倍并发扩容

小结

检索是 RAG 的"地基"，流水线是 RAG 的"血管"。从单线程思维升级到分布式混合检索，你的系统才能真正扛住生产流量。

---

写在最后

看到这里，你应该发现了，多模态 RAG 的性能优化，从来不是某一个"银弹"能搞定的。它是一场从模型选型、架构设计到推理工程的全链路战役。Embedding 选错了，后面全白搭；视觉分辨率暴力拉升，LLM 直接喘不上气；量化不分区，模型变"色盲"；KV-Cache 不管理，A100 也白给；没有 Continuous Batching，GPU 总在干等；索引和流水线不拆解，并发一上来就全线崩盘。

但好在，这些坑都是有人趟过的。你不需要从零开始摸索，只要记住今天这六个要点：场景匹配优先、动态分辨率、分区量化、PageAttention、Continuous Batching、混合检索+异步解耦。把这六张牌打出去，你的多模态 RAG 至少能从"能跑"进化到"跑得又快又省"。

编程之路不易，但每一步成长都算数。多模态这阵风才刚刚刮起来，现在把这些底层功夫扎牢，半年后你会感谢今天没偷懒的自己。保持好奇，持续动手，你也能成为那个在团队里一言九鼎、指点江山的技术大腿。加油，咱们下篇见！

关注私信备注：“资料代找获取”，全网计算机学习资料代找：例如:
《课程：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 智能体项目实战开发课》
《课程：大模型训练营配套补充资料》