惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

GbyAI
GbyAI
博客园 - 三生石上(FineUI控件)
S
Securelist
U
Unit 42
The Cloudflare Blog
奇客Solidot–传递最新科技情报
奇客Solidot–传递最新科技情报
Simon Willison's Weblog
Simon Willison's Weblog
让小产品的独立变现更简单 - ezindie.com
让小产品的独立变现更简单 - ezindie.com
cs.CV updates on arXiv.org
cs.CV updates on arXiv.org
Threat Intelligence Blog | Flashpoint
Threat Intelligence Blog | Flashpoint
B
Blog
T
Tenable Blog
The Hacker News
The Hacker News
The Register - Security
The Register - Security
IT之家
IT之家
博客园 - 【当耐特】
Spread Privacy
Spread Privacy
P
Privacy & Cybersecurity Law Blog
博客园_首页
T
Tailwind CSS Blog
人人都是产品经理
人人都是产品经理
C
Cybersecurity and Infrastructure Security Agency CISA
Know Your Adversary
Know Your Adversary
NISL@THU
NISL@THU
OSCHINA 社区最新新闻
OSCHINA 社区最新新闻
阮一峰的网络日志
阮一峰的网络日志
T
Tor Project blog
C
CERT Recently Published Vulnerability Notes
Apple Machine Learning Research
Apple Machine Learning Research
Stack Overflow Blog
Stack Overflow Blog
T
Threat Research - Cisco Blogs
T
The Exploit Database - CXSecurity.com
V
Vulnerabilities – Threatpost
A
Arctic Wolf
cs.CL updates on arXiv.org
cs.CL updates on arXiv.org
V
V2EX
aimingoo的专栏
aimingoo的专栏
大猫的无限游戏
大猫的无限游戏
Scott Helme
Scott Helme
L
LINUX DO - 热门话题
Cyberwarzone
Cyberwarzone
V
Visual Studio Blog
月光博客
月光博客
爱范儿
爱范儿
钛媒体:引领未来商业与生活新知
钛媒体:引领未来商业与生活新知
美团技术团队
G
GRAHAM CLULEY
cs.AI updates on arXiv.org
cs.AI updates on arXiv.org
H
Heimdal Security Blog
K
KPMG report finds enterprise disconnect between AI and its ROI | CIO

人人都是产品经理

为什么你的产品找不到差异化?90%的失败都卡在第一步上(下) – 人人都是产品经理, 3年从30万到1300万用户、获2200万美元融资,这个AI教育产品用“抽卡”破解了获客难题 – 人人都是产品经理, 园区招商系统怎么做才能真正帮到去化?我加了这一个功能,推广链接转发400次阅读过万 – 人人都是产品经理, AI大事件:OpenAI发完网络安全模型又搞药物研发,小鹏汽车要抓”DeepSeek时刻” – 人人都是产品经理, 电商不是卖货,是一场更残酷的产品经理实战 – 人人都是产品经理, 没想到,活动营销又回来了! – 人人都是产品经理, 为何All-in海外KOC:一场关于AI时代窗口期的豪赌 – 人人都是产品经理, 重新理解企业的内部协作 – 人人都是产品经理, 苹果的 AI 战略到底是什么? – 人人都是产品经理, 医疗智能体·第2讲——合规护城河:等保、PIPL与HIPAA的架构实战 – 人人都是产品经理, 向量知识库五步法:从“答非所问”到“精准回复” – 人人都是产品经理, 鸿蒙PC三方库构建总指挥HPKBUILD(sha)库为例 – 人人都是产品经理, 何时该用LLM?AI产品经理的LLM设计指南 – 人人都是产品经理, 医疗信息领域的需求方、决策方、准入方以及关注点(二) – 人人都是产品经理, 即梦涨价:一场被误读的「傲慢」 – 人人都是产品经理, 面试AI PM必答题:Hermes和OpenClaw的区别,如何讲清楚业务价值 – 人人都是产品经理, AI的下一张船票:世界模型——AI产品经理必须理解的技术拐点 – 人人都是产品经理, 小红书做GEO,怎么让AI信你?记住这 3 个重要信息 – 人人都是产品经理, 5 家印度 AI 初创公司,看看印度 AI 再做什么 – 人人都是产品经理, AI项目跨团队协作:产品技术业务如何不打架 – 人人都是产品经理, Agentic Workflow(智能体工作流):让AI从”答案生成器”变成”数字员工” – 人人都是产品经理, lycium_plusplus 项目全景解读:OpenHarmony 三方库构建的“大管家” – 人人都是产品经理, 从爆单救火到前置履约:两套预采策略,把生鲜大促履约效率拉满 – 人人都是产品经理, 什么时候该补货?我用一轮数据做了一个决定 – 人人都是产品经理, 从“机械兜底”到“动态分流”:AI客服重复进线治理的4大底层逻辑 – 人人都是产品经理, 抖音拼效率,红书拼洞察 – 人人都是产品经理, 全民狂欢与退潮——为什么龙虾这波热潮冷却得如此之快? – 人人都是产品经理, Stripe押注!MPP重塑全球支付 – 人人都是产品经理, 小红书GEO:AI引用你的内容,不是因为你对,而是因为你看起来可信 – 人人都是产品经理, 前百度副总裁押注办公Agent,日韩付费爆发,Manus迎来强劲对手 – 人人都是产品经理, 企事业单位数字化的业务供需本质 – 人人都是产品经理, 医疗智能体·第1讲——医疗信息化重构:从“辅助软件”到“自主智能体”的范式转移 – 人人都是产品经理, 粉丝量就是空气!!! – 人人都是产品经理, 用户说“薯片碎了”,机器回“要买吗?”:意图识别的翻车与破局 – 人人都是产品经理, RAG召回准确率从75到90 我做对了这三件事 – 人人都是产品经理, AI大事件:Anthropic改收费、OpenAI发安全版、手术机器人纳入医保、阿里发布”秒悟” – 人人都是产品经理, Chrome 推出 Skills 新功能,Agent 重塑上网方式 – 人人都是产品经理, GitHub前创始人拿了a16z的1700万美元,做Agent时代的Git – 人人都是产品经理 拷贝或克隆其他 Flutter OH 项目到本地后无法运行 – 人人都是产品经理, 优惠券设计:优惠券创建 – 人人都是产品经理, 不用死磕文档!AI 助手 1 小时搞定飞书 CLI 安装 + 配置 + 知识库 – 人人都是产品经理, 用小龙虾做竞品分析报告:从2天到20分钟,我是怎么做到的 – 人人都是产品经理 用小龙虾做市场分析报告:搞懂这3个公式,市场规模不再靠猜 – 人人都是产品经理, 你早就在做 Harness 工程,只是不知道它叫这个名字 – 人人都是产品经理, Think Long就够?你可能想多了! – 人人都是产品经理, 货代SRM实战:供应商准入怎么做,才能让资源池不是通讯录而是可交付网络? – 人人都是产品经理, 如何做好用户调研?详解基本技巧 – 人人都是产品经理, 木鸟、途家、美团对打,平台春天行动开“卷” – 人人都是产品经理, 入职才发现公司不靠谱?小红书从业者求职避坑指南 – 人人都是产品经理, 美国 AI 三巨头联手封堵,中国 AI 突围之路在何方 – 人人都是产品经理, 小红书,放在需求对面的镜子 – 人人都是产品经理, AI 会带来大规模失业吗? – 人人都是产品经理, 从出单到补货前,我第一次犹豫:该不该放大? – 人人都是产品经理, Flutter 三方库鸿蒙化适配:5 种高效检查方式,快速判断是否需要适配 – 人人都是产品经理, 从做产品进阶拿结果:医美机构产品经理转岗科室运营经理 – 人人都是产品经理, 阿里HappyHorse,一场关于“Token经济”的阳谋 – 人人都是产品经理, To B AI:客户留存落地的观察与思考 – 人人都是产品经理, AI产品的“生命线”——数据采集、标注、清洗的产品化设计 – 人人都是产品经理, 谈谈AI Agent(二):当“孩子”能自己“体验世界”时,你该学什么? – 人人都是产品经理, UI/UX设计师的3层能力进阶,前两层让你活下来,第三层…才是真正的分水岭 – 人人都是产品经理, 2分钟 → 30秒,效率提升75%:B端产品经理如何用「规则枷锁」驯服AI幻觉? – 人人都是产品经理, 还没来得及学OpenClaw,来了个更猛的:Hermes Agent – 人人都是产品经理, AI日报:宇树机器人跑出10m/s刷新世界纪录 – 人人都是产品经理, 一文说透基金互金如何用情绪价值引导用户决策做转化 – 人人都是产品经理, 当浏览器开始替你”看”网页:AI 浏览器正在亲手拆掉它脚下的那张网 – 人人都是产品经理, 0代码,一天时间我Vibe Coding了个网站 – 人人都是产品经理, Hermes 和 OpenClaw 之争,Agent 的能力应该“装上去”还是“长出来”? – 人人都是产品经理 视频生成的“桌子”,字节Seedance 2掀完,阿里快乐马掀 – 人人都是产品经理, 从听不懂到完全信任:我的 Codex 深度产品体验 – 人人都是产品经理, 当虚拟偶像有了北京户口,与真人偶像还有什么区别? – 人人都是产品经理, 会说,远远比会做更重要 —— 对 SBTI 爆火现象的五层观察 – 人人都是产品经理, AI产品经理必看:当“搭环境”比“选模型”更重要,你的认知还在2024年吗? – 人人都是产品经理, 2026年AI产品商业化核心逻辑:从功能demo到规模化营收的3个必破卡点 – 人人都是产品经理, 京东围绕供应链,卷起裤腿下场的那些事儿 – 人人都是产品经理, SBTI一夜刷屏:它赢在了“太会说人话” – 人人都是产品经理, 折扣零售的真相:不是便宜,而是价值感! – 人人都是产品经理, 和甲方吵了一架,最后加钱做了——我学到的ToB产品经理生存法则 – 人人都是产品经理, 和几位小红书操盘手聊了8小时,干货全在这 – 人人都是产品经理, 智谱GLM-5.1登场,开源模型首超Opus4.6!!! – 人人都是产品经理 Anthropic收入凭什么反超OpenAI,终于有人把这事说清楚了 – 人人都是产品经理, 史上最有故事感的技术报告——Claude最强模型Mythos 7个极其精彩的细节 – 人人都是产品经理, 模型不是壁垒,Harness 也不是 – 人人都是产品经理, 抖音本地生活业务思考21 – 人人都是产品经理, Superpowers:145k Star的AI编码框架,到底是什么来头? Superpowers:145k Star的AI编码框架,到底是什么来头? – 人人都是产品经理, OpenAI 的路走错了,Anthropic Harness 解法启示:模型需要实践专科生 – 人人都是产品经理, 画原型图的前一步:设计站点地图 – 人人都是产品经理, 给 DeepSeek 的最后一封催更信 – 人人都是产品经理, 手把手教你用 Claude Code 搭建 AI 营销团队:5 个 Agent、12 项技能,独立完成研究、写作、设计全流程 – 人人都是产品经理, 你以为大模型在学语言?不,它在重新发明语言学 – 人人都是产品经理 所谓Skill,不过是AI时代的工业垃圾 – 人人都是产品经理, 聊一聊内容传播的几个方法 – 人人都是产品经理, 当平台开始吃掉生态:从 OpenClaw 被封杀,读懂 Anthropic 的这盘棋 – 人人都是产品经理, 你装了 10 个 AI 插件,Obsidian 还是一个文件夹 – 人人都是产品经理 关于AI智能体架构演进的系统性思考:从单体试水到多体协同的重构 – 人人都是产品经理, 当“人”变成Skill,我们又该何去何从? – 人人都是产品经理 Mythos 事件:前沿 AI 治理的意外实验 – 人人都是产品经理, 货代CRM:信用与风险管理怎么做,才能把坏账风险拦在放货之前? – 人人都是产品经理, 从HR收集自拍照到员工自助录入——我见证了园区人脸识别从”不可用”到”真好用”的全过程 – 人人都是产品经理 千问闯关AI混沌期:阿里画靶,吴嘉张弓,马云射箭? – 人人都是产品经理,
如何设计大规模 AI 系统(上)
TCC翻译情报局 · 2025-12-24 · via 人人都是产品经理

构建大规模 AI 系统需层层递进:先选对 CPU、GPU、TPU 等计算硬件,搭好分布式架构并优化网络通信,再匹配适配的存储方案;在此基础上,还需掌握优化器选择、正则化、并行训练等高级技术,才能实现模型高效训练与部署。

训练一个机器学习模型,或许在基准数据集上达到最先进的准确率,这是一回事。但将该模型进行部署,让它为数百万用户提供服务、处理数 TB 的数据,并能每周 7 天、每天 24 小时可靠运行,则是截然不同的挑战。

从一开始,机器学习模型的训练和部署的每个环节、每个阶段都需要精心规划和合适的工具。

从早期开发到全面部署构建并运行一个 AI 系统,在这个过程中…

强大的软件开发技能变得至关重要,而这正是许多 AI 工程师所欠缺的。

在本博客中,我们将探讨构建一个能够创建大语言模型(LLMs)、多模态模型及各种其他 AI 产品的大规模 AI 系统所需的每个开发阶段。各开发阶段如何相互关联,以及它们各自的职责。

第一阶段:AI 的系统与硬件

构建大规模 AI 系统的第一步,是选择合适的硬件。这会影响模型的运行速度、成本投入以及能耗情况。

在本部分,我们将探讨市面上不同的硬件系统,以及如何提升其成本效益和能源效率。AI 计算硬件

广泛应用于训练或其他 AI 任务的三种最常见硬件类型如下:

AI 硬件可用性

  • 中央处理器(CPUs):它们擅长处理多种不同任务,但核心数量相对较少,因此在深度学习或需要大量并行处理的大型 AI 任务中,速度可能较慢。
  • 图形处理器(GPUs):最初是为处理视频和图形而设计的,如今却成了 AI 领域的宠儿。因为它们的核心数量比 CPU 多得多,这意味着它们可以同时处理大量任务,非常适合训练和运行 AI 模型。
  • 张量处理器(TPUs):这是谷歌专门为深度学习打造的特殊芯片。它们速度极快、效率超高且能耗较低,非常适合大型复杂的 AI 任务。

但最近,由于对 AI 的需求不断增长,一些新型硬件也相继问世。

现场可编程门阵列(FPGAs)就是一个很好的例子。这些芯片很特别,因为它们可以重新编程以适配不同的 AI 任务。这使你能够根据模型需求灵活微调性能,这在快速变化的 AI 项目中非常有用。

还有专用集成电路(ASICs)。它们不像 CPU 甚至 FPGAs 那样具有通用性。相反,它们专为一件事而设计:尽可能快速高效地运行 AI 模型。由于它们是为诸如驱动神经网络这类特定任务而打造的,所以能耗低且运行速度极快。

在选择硬件时,我们通常会认为不管是数据预处理、微调还是大语言模型(LLM)推理,直接选用 GPU 就一定能提升性能,但这种做法并不总是正确的。

然而,性能在很大程度上取决于…

模型架构 + 基础设施选择

从 AI 架构角度来看,模型量化是一种有效的技术,像 Together AI、Nebius AI 等许多现代开源模型 API 提供商都已在使用。这意味着在计算时减少 AI 模型所采用的细节程度,比如使用更小的数据位宽(例如,用 8 位替代 32 位 )。

从基础设施角度而言,云服务和虚拟化常常是最佳解决方案。你无需购买昂贵的硬件,而是可以从亚马逊云服务(AWS)、谷歌云(Google Cloud)或微软云(Azure)等供应商处租用高性能机器。这样一来,你能够依据项目需求灵活地进行资源扩展或缩减,既节省成本又避免浪费

看看谷歌提供的对比图表,它展示了不同模型架构在各类 GPU 上的性能表现。

谷歌在 MLPerf 3.1 基准测试(主要用于衡量系统处理输入的速度)上进行了此项测试。

  • 对于高难度的 AI 任务,配备强大 H100 GPU 的 A3 虚拟机比旧款 A2 虚拟机快得多,速度快 1.7 到 3.9 倍。
  • 如果想在保证一定 AI 性能的同时节省成本,使用 L4 GPU 的 G2 虚拟机是个不错的选择。
  • 测试表明,与类似云服务相比,L4 GPU 每花费一美元可实现高达 1.8 倍的性能提升。

像 Bending Spoons 这样的公司已经在使用 G2 虚拟机,高效地为用户带来新的 AI 功能。

AI 分布式系统

一旦根据需求选定了优化的硬件和模型架构,我们就进入下一阶段,即规划 AI 的分布式系统。

分布式系统的主要原理是…

将一个大任务拆分成多个小部分,让多台计算机同时处理这些小任务。

在 AI 领域,通过分担工作负载,这能够加快数据处理和模型训练速度。

因此,要创建分布式系统,我们需要考虑一些重要因素。我们先从概念上了解,然后再梳理其流程。

在将分布式逻辑应用到 AI 系统中时,我们需要考虑诸多因素。下面来看一下具体流程:

  • 首先,要明确规模。我们处理的数据量是数百、数千还是数百万?尽早了解这一点,有助于我们合理规划系统,确保其能顺利扩展。
  • 接下来,选择合适的工具。根据项目的规模和类型,我们需要合理搭配处理能力、内存和通信方式。云平台能让这一管理过程变得轻松许多。
  • 然后,要确保各部分协同工作。系统的不同部分可能需要并行运行,或者在不同机器上运行。我们的目标是避免出现运行缓慢的情况,保持系统平稳运行。
  • 之后,要保持灵活性。我们应实现资源调整自动化,而非手动操作。像 Kubernetes 这样的工具可以帮助系统根据负载变化自动调整。
  • 我们还需要监控性能。密切关注系统有助于我们尽早发现问题,无论是数据分布不均,还是网络瓶颈。
  • 最后,要确保一切保持同步。随着系统规模的扩大,保证数据和模型在所有部分的一致性至关重要。

网络优化

在确定 AI 系统的分布式架构后,你需要确保所有组件都能正确连接。

各组件之间必须能够顺畅、无故障地相互通信。

若分布式组件无法有效通信,训练代码或生产代码就可能出现问题。

下面来看看如何确保通信顺畅,不出现故障:

我们来详细分析一下:

  • 首先,排查潜在的速度瓶颈。延迟、容量限制或数据丢失会严重影响性能,因此尽早识别这些风险很重要。
  • 接着,减少延迟。为提高速度,我们可采用更快的连接方式、将机器放置得更近,甚至将部分处理任务转移到边缘端。
  • 随后,提升带宽。网络路径狭窄会导致拥堵。我们通过压缩数据、对重要信息进行优先级排序或升级网络来解决这一问题。
  • 之后,选择合适的通信方式。某些协议在处理大量负载方面表现更优。选对协议能确保系统快速高效运行。
  • 我们还要为未来的扩展做好规划。随着系统规模扩大,网络也必须跟上节奏。关键在于采用可按需扩展的灵活架构。
  • 最后,监控网络状况。定期检查有助于我们尽早发现问题。监控工具能在问题导致速度下降前发出警报。

AI 存储解决方案

在确定了用于训练或推理的硬件以及背后的分布式逻辑后,接下来你需要存储来保存训练好的模型,以及用户与 AI 模型交互产生的数据。

我们存储数据的方式不仅要适用于当下,还得能应对未来更多的数据。

我们有三种类型的数据存储系统:

对象存储最适合大数据。在这种存储方式下,你可以不断添加文件,无需担心数据结构。当数据来自多个源头,之后需要整合时,对象存储就非常适用。

文件系统更适合规模较小、结构规整的场景。它就像是你电脑里的文件夹,有助于保持数据规整,在数据量有限且结构良好的情况下最为理想。

而第三种是数据库,当数据具有结构时,数据库很有用。以下是选择合适类型数据库的方法:

  • 关系型数据库(SQL)非常适合规整且相互关联的数据。当数据存在明确的关系,比如用户、订单和产品之间的关系时,就使用关系型数据库。在对准确性和一致性要求较高的复杂任务中,它们表现出色。
  • 非关系型数据库(NoSQL)适用于灵活多变的数据。如果数据无法规整地放入表格,或者增长迅速,像 MongoDB 或 Cassandra 这样的 NoSQL 数据库能提供所需的灵活性和可扩展性。

不过,工具并非唯一重要的因素,如何使用它们同样关键:

  • 数据湖以原始形式存储所有数据。它就像一个巨大的容器,能容纳各种数据,供你日后整理和处理。
  • 数据仓库存储经过清理、可直接使用的数据。这就好比一个组织有序的图书馆,你能迅速找到所需内容。
  • 数据版本控制用于跟踪数据变化。在更新模型或处理随时间变化的数据时,这一点很重要,有助于保持数据有序,防止出错。
  • 混合存储兼顾速度与成本。对常用数据使用快速存储,其余数据使用成本较低的存储。这样既能省钱,又能在必要时快速访问数据。

快速的数据访问对 AI 性能至关重要。

使用 Redis 这样的内存存储来实现快速检索,并应用数据分片来分散负载,避免速度下降。

在某些时候,你需要决定哪种存储设置最适合:云存储、本地存储,还是两者结合。

  • 混合存储赋予你灵活性。你可以将敏感数据存放在自己的服务器上,而其他数据则使用云存储。这有助于平衡安全性与可扩展性。
  • 多云策略提供了更多选择。通过使用多个云服务提供商,你可以避免被单一供应商锁定。这就好比有不同的菜单可供选择,具体取决于你的需求。

第二阶段:高级模型训练技术

到目前为止,我们已经讨论了硬件、存储以及如何充分利用它们。现在是时候看看训练技术的工作原理,以及我们如何对其进行优化。

优化神经网络训练的策略

AI 模型通常构建在神经网络之上,虽然许多模型从基本的梯度下降法起步,但在实际应用场景中,还有更先进的方法能取得更好的效果。

Adam 优化算法是个明智之选。它融合了 AdaGrad 和 RMSprop 的优点,能很好地处理噪声数据和稀疏梯度,因此成为广受欢迎的默认选择。

RMSprop 算法有助于提升学习稳定性。它会依据近期的梯度变化情况来调整学习率,在处理非平稳问题时表现出色。

Adagrad 算法能根据数据进行自适应调整。它针对每个参数分别改变学习率,这对于稀疏数据效果显著,但随着时间推移,可能会导致学习率下降过多。

我们来看一张简单的表格,它能让我们对现有优化器及其适用场景有个宏观了解。

因此,这种对比能帮助机器学习工程师决定选择哪种优化器。

我们完全可以从 Adam 优化器入手。尽管不同优化器之间存在差异,但从实用的方法起步并获取一些初步认知很重要。

大规模训练的框架与工具

接下来是正则化技术,这对于防止过拟合、确保模型能很好地泛化到新数据至关重要。以下是一些能让模型在新数据上良好泛化的常用方法。

带权重衰减的 L2 正则化通过抑制较大的权重,使模型保持简单,从而起到作用。

模型中的 Dropout 层在训练过程中随机丢弃神经元,这样能降低模型过拟合的可能性。

基于验证损失进行早停。如果验证损失不再改善,那就没必要继续训练了。

处理超大型模型会带来新的挑战。以下是一些应对方法,以便让处理过程更可控。

模型并行化是将模型拆分到多个 GPU 上,模型的不同部分在不同设备上进行处理。

数据并行化是将数据分散到多个 GPU 上,PyTorch 的 DataParallel 可自动管理这一过程。

梯度累积能实现更大的批次处理。当内存有限时,它通过在更新前累积梯度来解决问题。

联邦学习将数据保留在本地设备上。模型在各个设备上分别进行训练,仅共享模型更新。

为了在不损失过多性能的前提下提高大型模型的效率,知识蒸馏是一种很好的方法。

利用大型 “教师” 模型来训练小型 “学生” 模型。这有助于在缩小模型规模的同时保持较高的准确率。

通过结合合适的优化器、正则化方法以及训练策略,即便面对大规模数据,我们也能构建出既强大又高效的模型。

我们可以做个对比表,以便更清晰地理解这些内容。

借助 TensorFlow 和 PyTorch 实现规模化

在大规模开展 AI 工作时,框架也起着重要作用。以下是一些热门选择:

最重要的框架

  • TensorFlow 提供了 TensorFlow 分布式策略,有助于在 GPU 和 TPU 上高效扩展训练。
  • PyTorch 以其 PyTorch 分布式功能闻名,支持在多个 GPU 和多台机器上进行扩展。
  • Horovod 可与 TensorFlow、PyTorch 和 Keras 配合使用,提升在 GPU 和 CPU 上的可扩展性。
  • Kubernetes 有助于在大规模运行时平稳部署和管理 AI 工作负载。
  • CUDA 和 cuDNN 可加速 GPU 计算和深度学习性能。
  • NeMo 专注于构建语音和自然语言处理模型。

模型扩展与高效处理

扩展模型是处理大数据集和复杂任务的关键。让我们探索一些简单的方法,对模型和数据进行并行处理、巧妙处理批次,并应对训练过程中的挑战。

模型并行,当模型对于单个 GPU 来说过于庞大时,我们可以将模型拆分到不同设备上。可以按层(纵向)或层的部分(横向)进行划分。目的是减少设备之间的数据传输。

我们可以使用像 NCCL 这样的高速通信库,来减少数据传输时的延迟,还可以

torch.cuda.synchronize () 确保各设备按顺序完成任务。

数据并行:我们可以在多个设备上,对不同的数据块运行相同的模型。当模型可在单个 GPU 上运行,但我们希望并行处理更多数据时,这种方法很有用。

反向传播后,分布式数据并行(DDP)会在各设备间同步梯度,以确保模型权重一致

我们还可以通过梯度压缩来减轻通信负载。以下是一个使用 8 位量化的简单示例:

高效批次处理:我们可以通过调整批次处理方式来提升速度并优化内存使用。

  • 混合精度训练使用半精度(float16)以加快计算速度:

  • 如果你的 GPU 无法处理大批次数据,梯度累积会有所帮助:

我们来了解一下同步训练和异步训练的基本区别:

同步训练:所有工作节点在更新权重前等待交换梯度。这样能确保模型的一致性,但最慢的工作节点会拖慢整体速度。

  • 梯度平均
  • 自适应批次大小
  • 预测等待时间调度

异步训练:工作节点无需等待就更新权重。这能加快训练速度,但梯度可能过时。

  • 使用过时梯度校正
  • 动态调整学习率
  • 维护模型版本控制以跟踪更新

那么,基于目前所学内容,我们用一张表格来进行总结:

撰文:Fareed Khan

本文由人人都是产品经理作者【TCC翻译情报局】,微信公众号:【TCC翻译情报局】,原创/授权 发布于人人都是产品经理,未经许可,禁止转载。

题图来自Unsplash,基于 CC0 协议。