10 月 23 - 25 日,QCon 上海站即将召开,现在大会已开始正式报名,可以享受 8 折优惠 了解详情
写点什么

揭秘千卡 GPU 集群如何高效训练多模态大模型:vivo AI 团队实战经验分享|AICon

作者:王兆雄

  • 2025-06-19
    北京
  • 本文字数:8178 字

    阅读完需:约 27 分钟

大小:4.08M时长:23:44
揭秘千卡 GPU 集群如何高效训练多模态大模型:vivo AI 团队实战经验分享|AICon

多模态大模型在智能客服、自动驾驶、AIGC 等领域的应用需求不断增长,但其训练工程面临计算、存储、数据处理、分布式通信等多重挑战。特别是在千卡级 GPU 训练集群上,如何优化数据加载、提升训练稳定性、突破计算与存储瓶颈,成为 AI Infra 需要重点攻克的难题。


在 InfoQ 举办的 AICon 全球人工智能开发与应用大会上 vivo AI 研究院 AI 架构师王兆雄做了专题演讲“千卡级分布式集群上的视觉多模态大模型落地实践”,基于 LLaVA 视觉多模态理解模型和 DiT 文生图模型的训练工程实践,详细解析大规模 GPU 训练集群下的数据存储优化、分布式计算策略、训练容错机制,并探讨如何提升大规模多模态模型的训练效率和稳定性。演讲将重点介绍混合并行训练、数据高效加载、自动容错恢复等技术方案,为业界提供可落地的工程实践经验。


内容亮点


  • 深入理解多模态大模型的训练挑战,尤其是理解模型 vs 生成模型的工程区别

  • 掌握大规模 GPU 训练集群的优化策略,包括数据处理、并行计算、通信优化

  • 学习如何提升训练稳定性,减少长时间训练中的失败率

  • 借鉴 LLaVA 和 DiT 训练的实际优化经验,为自身多模态模型训练提供参考


以下是演讲实录(经 InfoQ 进行不改变原意的编辑整理)。


随着人工智能技术的飞速发展,图文多模态大模型的需求正呈现出快速增长的态势。在 vivo,我们也在积极推动这类模型的产品化落地。例如,我们推出的“小 V 圈搜”功能,能够帮助家长一键圈出题目,快速获取解析,从而让辅导作业变得更加轻松。


此外,我们的“蓝心”AI 中文绘画大模型,它更贴近东方审美,更符合国源语境,为用户带来独特的 AIGC 会话体验。这些功能的背后,主要依赖于我们强大的图文理解与生成模型。


然而,在千卡级 GPU 上完成这类大模型的训练任务,其挑战远不止算力,还涵盖了数据预处理、模型结构设计、分布式调度与通信等多方面的工程问题。今天,我将结合 vivo 在这些产品背后的真实训练工程经验,从问题出发,分享我们是如何在千卡集上顺利完成模型高效落地的。

多模态大模型的训练工程挑战

多模态大模型的训练工程面临着诸多核心挑战。我们先从模型类型的演进谈起。传统的单模态模型,如自然语言处理(NLP)模型仅处理文本,计算机视觉(CV)模型仅处理图像,自动语音识别(ASR)模型仅处理音频,它们互不交集。


而多模态大模型则能够同时处理文本、图像、音频甚至是视频,将它们统一在一个模型架构内,通过下一个 token 预测的方式实现跨模态的理解与生成。这标志着从各自为政走向融合,是迈向更高效、更通用人工智能系统的重要一步。


再来看多模态模型结构的两种典型应用场景。第一类是理解类模型,例如 LLaVA,它类似于一个图像问答助手,处理结构规整的图文输入,训练相对简单,计算开销也较小。第二类是生成类模型,如 DiT,它需要根据文本生成高质量的图像。这类模型不仅计算量大,而且图像分辨率各不相同,对显存提出了更高的要求。


简单来说,理解类模型更侧重于离散 token 的训练,训练稳定性至关重要;生成类模型则更侧重于连续的 latent,其训练复杂度和显存压力都更高。


在具体训练过程中,我们总结了四个核心挑战。首先,是算力压力大。由于模型体积较大,图像分辨率存在差异,kernel 启动频繁导致调度延迟加大,从而降低算力利用率。


其次,存储 I/O 与 CPU 预处理造成的加载延迟。数据量较大导致加载速度慢,IO 不均匀,样本处理流程也较为复杂。第三,数据吞吐受限。多模态样本结构相对复杂,处理 pipeline 较长,容易造成数据通道拥塞。


最后,通信并行调度较为困难。模型增大后需要进行拆分,如 TP、PP、长序列的 CP 等并行策略需要反复调优,网络拓扑与并行分区不匹配时,通信链路负载不均导致跨区域带宽争用。在这些挑战中,我们也曾实际遇到过不少问题。


我们面临的整个训练挑战贯穿了整个训练链路。从最初的数据加载阶段开始,样本结构复杂,解码与预处理耗时较大。


在模型输入阶段,需要进行图文对齐,编码过程也会消耗不少算力。接下来是并行训练阶段,TP、PP、CP 等调度可能不合理,导致 GPU 利用率难以提升。分布式通信则决定了我们能否从百卡到千卡甚至万卡实现线性加速比对。


最后是稳定性问题,一旦中断能否快速恢复,这也是一个很大的挑战。这些看似细微的问题,在千卡级集群中会被放大,成为我们必须解决的关键弱链路。

Al Infra 四大优化方向

我将围绕前面提到的四大优化方向,分享我们在落地过程中的一些优化实践经验。

数据处理优化:让数据流转快起,GPU 不再空等

多模态训练很多时候不是卡在计算,而是“数据先断流”。为此,我们从两个阶段进行了优化。在数据准备与存储阶段,我们将图文数据预处理成多个 shard 小块,每个进程仅加载属于自己的那部分数据,这样 IO 操作就会更加轻量。同时,我们将解码、resize 等操作提前完成,在训练时,只需进行拼接、映射或内存直读等操作,显著提高了加载效率。


在训练阶段的加载优化方面,我们采用异步加载和缓存预取机制,确保每张卡都能即时获取数据,保持数据队列的充足。


对于高频样本,我们进行本地缓存,避免重复跨节点读取。这些优化手段让 GPU 不再干等,从而提升了训练速度。


模型计算优化:发挥每张卡的最大算力价值

图像经过 ViT 编码,文本经过 Tokenizer 编码后与图像特征融合,再通过 Transformer 层输出结果或进行理解、生成等操作。


在这个过程中,存在不少算力浪费点,例如 Block 结构不统一导致 kernel 启动频率高,attention 计算利用率低,调度碎片化;跨模态融合模块可能打断计算流水线;输入数据分布不均导致 batch 无法拉大,浪费显存等问题。针对这些问题,我们进行了优化。


例如,进行算子融合,将多个小操作合并成一个复合操作,减少操作的启动次数;利用高效的 attention 计算,如 Flash attention 等,提升 FLOPs 利用率;采用了混合并行加 Interleaved 1f1b 操作,让每张卡在运行当前阶段(Stage)的计算任务的同时,并行准备下一步的前向(Forward)或反向(Backward)计算,从而打通 pipeline,提升整体吞吐效率;还可以进行激活重算、混合精度等操作,释放显存,进一步拉大 batch size,使每张卡都能充分发挥性能。


分布式通信优化:打通卡问瓶颈,让模型不等通信

节点内通信通常问题不大,但跨节点的 AllReduce 操作容易遇到带宽瓶颈,导致 GPU 空等。多跳网络路径在 checkpoint 写入 / 读取时显著增加延迟,拖慢整体训练。我们归纳出四类常见问题:跨节点带宽受限、通信与计算不重叠、多流调度不均、拓扑与并行策略不匹配。


针对这些问题,我们采用了以下优化:


  • 拓扑感知调度:根据物理交换机层级和机架分布,最小化通信路径长度。

  • 通信 - 计算重叠:在 CUDA Stream 上并行调度 AllReduce 与前向/反向计算。

  • NCCL 多通道:启用多网络接口或多 NVLink 通道并行传输,分散热力学热点。

  • CPU 核绑定:将通信线程绑定至特定 NUMA 节点的 CPU 核心,减少远程访问延迟并提升稳定性。


只有通信顺畅,整个训练才能顺利进行。


训练稳定性建设:让训练跑得久,跑得稳

多模态训练周期长、数据量大、集群规模大,出现中断的概率显著提高,且重启代价高昂。我们围绕以下三方面进行系统性优化:


  • 降低中断概率

  • 分片数据广播后进行一致性校验,防止节点间数据不一致导致训练崩溃。

  • 训练前运行深度健康检查,剔除潜在故障节点。

  • 任务级重试机制,单卡或单节点失败时自动重跑,提升容错能力。

  • 缩短恢复时间

  • 启用 checkpoint 缓存机制,将写入/读取先缓存至本地高速介质,避开网络 I/O 瓶颈。

  • 从缓存中快速加载最近 checkpoint,确保训练恢复秒级启动。

  • 减少重复训练损耗

  • 采用增量 checkpoint,在关键训练步骤或时间间隔内保存状态。

  • 结合并行写入与本地缓存,平衡 I/O 开销与恢复速度。


以上优化结合了 NVMe 加速写入、异步缓存读取和分布式任务重试等业界最佳实践,实现了多模态大规模训练的长跑与稳跑目标。


训练工程案例:LLavA & DiT

接下来,我将通过一些具体的案例,深入探讨图文理解模型 LLaVA 和文本生成图像模型 DiT 的优化实践。这两种模型类型不同,痛点各异,优化路径也各有侧重。通过具体案例的拆解,大家能够更直观地看到它们在工程实践上面临的挑战。

LLavA 训练工程实践

我们对 LLaVA 和 DiT 的模型结构进行了整体对比。LLaVA 的模型结构是从 ViT 抽取图像特征,经过投影对齐到文本空间,最后通过大语言模型进行问答输出。而 DiT 的生成模型则是图像由 VAE encoder 得到 latent,文本由 CLIP/text Transformer encoder 得到 embedding,再逐步还原出最终的图像。


尽管一个是理解模型,另一个是生成模型,但在训练落地时,它们都面临着四大共性挑战:多模态数据对齐难,I/O 压力大;模型结构复杂,融合难度高;通信开销大,容易产生阻塞;训练容易中断,容错要求高。因此,我们从数据处理、模型计算、通信效率提升以及稳定性优化等方面入手,为它们提供保障。


在大规模模型训练中,数据加载往往是第一个瓶颈。如果加载速度慢,GPU 可能会空闲,导致算力浪费;而加载进程过多,又容易占用过多内存,引发系统内存溢出等问题。


我们通过监控 GPU 端数据接收的耗时来发现问题,一般来说,耗时在毫秒级是正常的,如果耗时上升,就可能意味着读取数据出现了问题。数据供应不足会导致整个训练链路变慢。


为此,我们从四个方面对链路系统进行了优化:一是优化任务下发,使其更轻量,主进程统一生成列表,并发地给多个子进程加载,减少调度负担;二是在子进程中进行解码或 resize 操作,避免主进程阻塞;三是启用锁页内存(Pin Memory),让数据流转更高效;四是在拉取数据时,利用本地缓存,避免频繁跨节点读取高频数据,直接从本地缓存拉取。


此外,子进程的数量和预取因子的设置也是我们在实践中踩过坑的地方。这些参数并不是设置得越大越好,而是要结合 GPU 的吞吐能力和 IO 性能动态优化配置。


经过优化,数据加载耗时压缩到了原来的 10% 左右,GPU 几乎满载,训练速度提升了 50%。这种多进程、锁页内存和本地缓存的组合优化,成功打通了数据链路。



在模态融合下的算力利用率优化方面,早期我们采用均匀流水线,但发现存在问题。


例如,Transformer 层有 32 层,如果 PP 设置为 8,每个阶段会分配 4 层。在语言模型中可能没有太大问题,但在多模态模型中,前面还有 ViT、project 等操作,这些也会放到第一个阶段,而后面的 output 则放到最后一个阶段。这就导致前后阶段的算力和显存占用特别满,而中间阶段可能比较空,使得整个 GPU 卡的负载不均。


为此,我们引入非均匀流水线重构,根据每层的参数量和显存占用重新划分,使资源分配更均匀。在读取数据时,我们发现输入的图文对参差不齐,如果在一个 batch 中有长有短,最终都会 padding 到最长的图文对上,导致无效计算。


为了解决这个问题,我们进行了离线数据拼接,将相近的图文对分类,使每个 batch 的图文对长度相对均匀,从而提高算力利用率。我们还配套了流水线并行调度,降低流水线并行的空泡。


因为开启流水线后,仍会存在一些空泡,导致 forward 或 backward 操作中出现延迟。我们通过调整 Micro Batch Size(微批次大小)和 PP 数,尽量让 Micro Batch Size 大于 PP 数,以减少空泡。


此外,我们还进行了算子融合,将多步操作压缩成一步,进一步提高效率。通过这一套优化,我们将 MFU 从 34% 提升到了 45%,在千卡级上的表现还算不错。



在通信层面的优化中,分布式通信是决定我们能否在千卡级甚至更大规模上实现线性扩展的关键环节。


我们在物理级别上进行了一些优化。首先,我们的网络结构可以支持万卡,采用三层胖树结构,并进行了导轨级优化。这样做的核心是让跨节点通信更高效,不同 Pod 的同号 GPU 都连接到接入交换机,AllReduce 操作只需一跳即可完成,无需经过汇聚或核心交换机。


实测结果显示,这种优化使 Pool 内的吞吐量提升了 150%。此外,我们还利用了 RDMA 通信加速,由于我们使用的是 IB(InfiniBand)网络,通信传输无需经过 CPU,直接从网口到 GPU,这也有很大的提升。在并行策略的调度优化方面,我们尽量避免 TP 跨节点,因为 TP 的通信量很大,所以 TP 的切分尽量在一台节点内完成。


同时,PP 也尽量避免跨节点通信,以避免通信拥塞。在软件层面,我们进行了通信计算重叠优化,进一步提升了效率。通过这些优化,通信空等时长下降了 40%,训练速度提升了 20%。



在 LLaVA 训练稳定性方面,我们也进行了一些实践。在训练过程中,如果数据量较大,尤其是预训练数据清洗不够干净,难免会遇到一些异常数据。


此外,由于数据存储可能在远端,拉取数据时也可能出现拉不到的情况。为此,我们设计了异常数据跳过机制。当检测到异常数据或处理数据出现异常时,子进程会将异常上报给主进程进行判断。


如果异常阈值没有超过设定值,我们就跳过该数据,继续获取下一条数据。这样可以避免重复训练,使训练过程更加稳定。由于我们支持异常数据跳过,可能会出现一个问题,即在进行流水线拆分时,某张卡跳过了数据,而其他卡没有跳过,导致切片之间的数据不一致。


针对这个问题,我们在 TP 广播的基础上增加了 PP 广播。在启动时,主节点获取数据并广播到其他卡,从而避免了训练过程中的崩溃。此外,我们还进行了一些任务级的异常检测,以便在出现异常后及时发现集群是否 down 掉,并能自动拉起集群,从最近的 checkpoint 恢复训练,提升训练稳定性。


通过实际落地这一套优化,我们的千卡训练能够稳定运行 139 小时以上,相当于 5 天多,无需人工值守,支持异常自动恢复和任务续跑。


DiT 训练工程实践

在 DiT 图像生成任务中,为了提升生成图像的多样性,在预训练阶段需要使用大量不同分辨率的图像。这样虽然增强了模型的泛化能力,但也带来了训练工程上的一大挑战:图像尺寸高度不一致,导致每个 batch 中图像维度不同,不能直接拼接。


常规的做法是统一 padding,也就是把所有图像补齐到最大尺寸再训练。但问题在于,大量 padding token 实际上不含有效信息,却要耗费完整的显存和计算资源,导致训练效率明显下降。


为了解决这个问题,我们采取了两步式的数据端优化方案:


第一步是图像分桶:


我们将训练集中的图像按宽高比或分辨率进行划分,分成若干个 Bucket,每个 Bucket 内图像尺寸相近。这样在组成 batch 时,padding 大大减少,有效计算比提升显著。


第二步是动态 Batch Size:


由于不同 Bucket 的图像大小不同,对显存的占用也不同。我们根据每个 Bucket 的平均图像尺寸动态分配 Batch Size——小图用大 Batch,大图用小 Batch,在显存范围内尽可能提高吞吐。


通过这套“图像分桶 + 动态 Batch Size”的组合策略,我们将 DiT 的整体训练时长缩短了近一半,训练效率提升接近一倍,是图像生成任务中提升性价比的核心工程优化。



在模型计算优化方面,我们发现要深入提升训练性能,就需要进行算子级别的优化。我们进行了算子融合,例如将三步操作合成一步,减少了 kernel 的启动次数和显存算力的利用,使 batch 可以更大。


此外,我们还进行了编译优化,让计算更高效。激活重算在图像领域,尤其是文生图领域应用较多,因为分辨率和帧数较多时,显存压力很大。激活重算即在前向时不存激活值,反向计算时重新计算,从而节省显存,使 Batch 可以更大。通过这些优化,显存减半,支持更高的 Batch,训练速度提升了 60%。



在通信优化方面,我们主要使用 FSDP 框架。FSDP 的 AllGather 通信原本需要等反向做完再统一进行梯度更新。我们进行了两个优化:一是将 AllGather 拆成多个小段按层触发;二是启用独立的 CUDA 流,让反向传播与梯度并行进行。


优化后,AllReduce 或 AllGather 与反向传播交叉进行。我们还进一步发现,尽管进行了分桶和动态 batch size 优化,但仍有卡间像素计算量的差异。


于是,我们进行了彻底对齐 GPU 负载的优化,通过 Package Shuffle 操作,将一个大 batch 的图像打包成一个 package,使单个 batch 从 package 中获取相同的像素量,且这个像素量是 GPU 的最大算力。


最终,完全对齐了算力,充分利用了 GPU 的算力。优化后,通信等待时长降低了 98%,训练更流畅,卡间的像素对齐进一步提速了 10%。



在训练稳定性方面,我们曾遇到一个案例,原本 7 天可完成的任务,因中断问题最终耗时 15 天,算力利用率很低。


为此,我们进行了优化:一是异步 checkpoint 保存,不占用主进程,节省时间;二是利用分布式缓存,降低 IO,提高速度;三是触发式保存,当检测到异常时触发保存,减少重复训练时间。


落地后,快照保存时间提升了 88%,故障恢复时间下降了 90%,实现了分钟级恢复。



在 LLaVA 和 DiT 模型的训练工程实践中,我们通过一系列的优化措施,实现了显著的性能提升。以下是我们实践的总结。


数据处理优化


优化措施:


  • 对于 LLaVA 模型,我们采用了多进程数据加载架构,支持海量数据训练,减少了 IO 等待时间。

  • 对于 DiT 模型,我们实施了图像分桶和动态 Batch Size 策略,最大化了单卡负载。


落地成效:


  • LLaVA 模型的 GPU 满载率提升,训练速度加快了 50%。

  • DiT 模型的训练时长减少,效率翻倍。


模型计算优化


优化措施:


  • 对 LLaVA 模型,我们进行了流水线并行与离线拼接优化,释放了存储瓶颈,提高了计算密度。

  • 对 DiT 模型,我们融合了算子、激活重算,提升了大模型训练效率。


落地成效:


  • LLaVA 模型的算力利用率(MFU)从 34% 提升至 45%。

  • DiT 模型的显存使用减少 50%,训练吞吐提升约 60%。


分布式通信优化


优化措施:


  • 对 LLaVA 模型,我们引入了 RDMA 加速、TP/PP 优化、AllReduce 融合压缩通信等技术。

  • 对 DiT 模型,我们采用了 FSDP 独立通信流优化,GPU 负载对齐,提升了训练同步效率。


落地成效:


  • LLaVA 模型的通信延时降低,训练加速 20%。

  • DiT 模型通信与计算 overlap 实现率超 98%,训练流程更流畅。


训练稳定性建设


优化措施:


  • 对 LLaVA 模型,我们实施了流水线数据扩播,异常检测与故障自动恢复。

  • 对 DiT 模型,我们采取了异步保存、分布式缓存和触发保护,缩短了恢复时间。


落地成效:


  • LLaVA 模型无需人工值守,支持 139+ 小时千卡稳定训练。

  • DiT 模型故障恢复耗时降低 90%,续训恢复至数分钟。

Al Infra 未来展望

在探讨人工智能基础设施(AI Infra)的未来时,我认为我们需要从三个维度进行展望:数据、算法和算力。


首先,在数据维度上,我们正从海量数据向高质量数据转变。数据并非越多越好,关键在于质量。为此,我们将引入自动化的数据清洗机制,以提高样本的准确性,同时保护用户隐私,例如应用差分隐私技术。在多模态数据方面,我们将加强模态增强和合成,通过智能方式生成更多有用的样本,以支持训练效率的提升。


其次,在算法维度上,我们正在从规模扩展向智能优化转变。在模型结构上,我们将探索更高效的结构,如混合专家模型(MoE)和微分流水线并行等。在训练范式上,我们强调自监督学习和小样本学习,以减少对人工标注的依赖,提高模型的泛化能力。


最后,在算力维度上,我们正从扩展性向高效性转变。通过统一调度和定制加速芯片,我们可以实现资源的最大化利用。此外,我们还将注重可持续发展。


我们的落地路径是围绕这三个方向重构一个真正的平台化 AI 基础设施。从数据准备到算法选择,再到分布式训练,以及评估优化,整个链路将实现高度自动化,形成一个闭环。这样,多模态大模型的训练将进入一个更大规模、更强泛化能力以及更低成本的新阶段。


我的核心认知是,训练工程必须稳定,模型才能走得更远。只有底层链路畅通,保证算力资源长时间稳定运行,模型才能顺利完成迭代。其次,训练链路必须彻底打通,才能实现真正的多模态闭环。


从数据到通信,从模型到调度,只有每个环节都高效协同,整个系统才能高效运转。最后,算法的突破不能仅仅依靠工程来补短板,而是需要工程来推动。即使模型再先进,如果缺乏稳定、高效的工程支撑,也很难真正落地。

嘉宾介绍

王兆雄,曾就职于京东商城和猎豹移动,拥有丰富的大数据分析和游戏服务端研发经验,主导设计并实现了支撑数千万日活用户的轻量级游戏服务端架构。目前在 vivo AI 研究院任职,负责过 vivo 手机智慧桌面信息流和全局搜索服务端的推荐与搜索架构,支撑亿级用户。现负责视觉多模态大模型的训练工程,具备千卡级分布式集群上大模型训练的丰富经验,致力于构建高性能、可扩展的 AI 解决方案。

活动推荐

6 月 27~28 日的 AICon 北京站将继续聚焦 AI 技术的前沿突破与产业落地,围绕 AI Agent 构建、多模态应用、大模型推理性能优化、数据智能实践、AI 产品创新等热门议题,深入探讨技术与应用融合的最新趋势。欢迎持续关注,和我们一起探索 AI 应用的无限可能!



2025-06-19 10:007061

评论

发布
暂无评论

中软协AI沙龙热议:智领云CEO彭锋解读AI大模型技术的应用前景与趋势

智领云科技

容器 AI大模型 大模型 中软协

向量数据库落地实践

京东科技开发者

Web Components实践:如何搭建一个框架无关的AI组件库

京东科技开发者

全方位解析ChatGPT:如何培养 AI 智能对话技能?

霍格沃兹测试开发学社

MES定制开发/云MES制造执行系统解决方案

万界星空科技

制造业 生产管理系统 mes 云mes 万界星空科技

IM技术干货:假如你来设计微信的群聊,你该怎么设计?

JackJiang

即时通讯;IM;网络编程

如何选择合适的系统?MES系统和MOM系统的区别

万界星空科技

制造业 mes 万界星空科技 生产管理 MOM

高柔性第二代扁线定子量产线正式上市

财见

中小型工厂应如何选择生产管理mes系统

万界星空科技

制造业 生产管理系统 mes 云mes 制造业工厂

全面了解龙蜥衍生版 KeyarchOS 在安全、机密计算等方面的实践 | 龙蜥大讲堂浪潮信息专场

OpenAnolis小助手

开源 操作系统 龙蜥社区 龙蜥大讲堂

淘系接口推荐:淘宝天猫实时商品评论数据采集接口

tbapi

淘宝商品评论接口 淘宝评论API 淘宝商品评论采集

漫谈测试策略

阿里技术

效率 测试 质量 测试策略

淘系接口推荐:淘宝天猫实时商品详情页面数据采集接口

tbapi

数据挖掘 淘宝商品详情数据接口 淘宝API接口 天猫商品详情数据接口

月之暗面Kimi智能助手实现200万字长上下文,火山引擎提供云服务支持

新消费日报

如何提升 API 的性能水平

Apifox

程序员 接口 API 开放 API API 性能

解锁AI Studio:玩转大模型应用,开启智能新时代

百度开发者中心

人工智能 深度学习 大模型

容器中的大模型(三)| 利用大语言模型:容器化高效地部署 PDF 解析器实践

智领云科技

容器 PDF 大模型 AI大语言模型

容器中的大模型(二) | 利用大模型,使用自然语言查询SQL数据库

智领云科技

数据库 sql 容器 AI大模型 大模型

探索元宇宙:数字化未来的新前沿

天津汇柏科技有限公司

元宇宙

开发者手机AI来袭

Laval小助手

京东中台化底层支撑框架技术分析及随想

京东科技开发者

基于Sermant的全链路灰度发布在汽车行业DMS系统的应用

华为云开发者联盟

云原生 华为云 汽车 华为云开发者联盟 企业号2024年4月PK榜

通过淘宝开放平台API接口获取商品信息:标题、分类与店铺名称的新方法

技术冰糖葫芦

API 接口 API 文档

首个镜像服务商奖项公布!「Alinux 伙伴招募计划」最佳服务商名单来了

OpenAnolis小助手

镜像 操作系统 龙蜥社区 Alibaba Cloud Linux

免费延期一年!Alibaba Cloud Linux 2 EOL 延保支持计划

OpenAnolis小助手

阿里云 操作系统 Alibaba Cloud Linux

揭秘千卡 GPU 集群如何高效训练多模态大模型:vivo AI 团队实战经验分享|AICon_AI&大模型_InfoQ精选文章