使用英特尔 Sapphire Rapids 加速 PyTorch Transformers 模型

大约一年以前,我们 展示 了如何在第三代 英特尔至强可扩展 CPU (即 Ice Lake) 集群上分布式训练 Hugging Face transformers 模型。最近,英特尔发布了代号为 Sapphire Rapids 的第四代至强可扩展 CPU,该 CPU 包含了令人兴奋的深度学习加速新指令。

通过本文,你将会学到如何在一个 AWS Sapphire Rapids 集群上加速一个 PyTorch 训练任务。我们会使用 英特尔 oneAPI 集合通信库 (oneAPI Collective Communications Library, oneCCL) 来分布式化训练任务,并使用 英特尔 PyTorch 扩展库 (Intel Extension for PyTorch,IPEX) 来自动使用新指令进行性能优化。因为这两个库均已集成入 Hugging Face transformers 库,我们能够做到在不修改一行代码的前提下开箱即用地运行我们的示例代码。

在随后的另一篇文章里,我们还会探讨如何使用 Sapphire Rapids CPU 进行推理及其性能提升。

为何你应该考虑在 CPU 上训练

在英特尔至强 CPU 上训练一个深度学习模型是一个性价比高且可扩展的方案,在使用分布式训练或者在小数据集或中等数据集上微调模型时尤其如此。

至强 CPU 支持一些先进的特性,如 512 位先进矢量扩展 (Advanced Vector Extensions,AVX-512) 以及超线程 (Hyper-Threading) ,这些特性提高了深度学习模型的并行性和效率,使得我们可以在得到更好的硬件资源使用率的同时训练得更快。

另外,一般而言,相比用于训练大型深度学习模型的专门硬件如 GPU 等而言,至强 CPU 更便宜和易得。至强 CPU 还更容易用于其他生产任务,从网络服务到数据库不一而足,这使得它们成为 IT 基础设施的一个万用且灵活的选择。

最后,云用户还可以通过使用 spot 实例的方式进一步降低在至强 CPU 上的训练成本。Spot 实例使用空闲计算资源,因此以折扣价售卖。与按需实例相比,spot 实例提供了高至 90% 的显著的成本节约。最后同样重要的是,CPU spot 实例一般来讲比 GPU 实例更容易获得。

现在,让我们看一下 Sapphire Rapids 架构引入的新指令。

先进矩阵扩展 (AMX):深度学习新指令

Sapphire Rapids 架构引入了英特尔先进矩阵扩展 (Advanced Matrix Extensions, AMX) 用于加速深度学习工作负载。用户只需安装最新版本的 IPEX 即可受益于新指令,无需更改任何 Hugging Face 代码。

AMX 指令用于加速矩阵乘法,该操作是深度学习批量训练的核心操作。AMX 指令支持 Brain 浮点 (BF16) 和 8 比特整型 (INT8) 数据类型,覆盖不同训练场景的加速需求。

AMX 指令引入了新的 2 维 CPU 寄存器,称作 tile 寄存器。因为这些寄存器在上下文切换时需要保存和恢复,所以需要内核相关支持。在 Linux 上,内核版本需要在 v5.16 及以上方可支持。

现在,让我们看看怎样构建一个 Sapphire Rapids CPU 集群用于分布式训练。

构建一个 Sapphire Rapids CPU 集群

截至本文撰写之时,使用 Sapphire Rapids 服务器的最简单的方式是使用新的亚马逊 EC2 R7iz 实例家族。由于它尚在预览期,你必须 登记注册 以获得访问权限。另外,虚拟机尚未支持 AMX,因此,我们将使用裸金属实例 (r7iz.metal-16xl, 64 vCPU, 512GB RAM) 。

为避免手动设置集群中的每个节点,我们首先建立一个主节点并依此创建一个新的亚马逊机器镜像 (Amazon Machine Image,AMI) ,然后,我们用这个 AMI 启动其他节点。

从网络的角度,我们需要如下设置:

  • 打开 22 端口,用于所有实例上的 ssh 访问创建和调试
  • 配置从主实例 (你启动训练的那个实例) 到所有其他实例 (包含主实例本身) 的免密 SSH 访问。换句话说,主节点的 ssh 公钥必须在所有阶段上被授权
  • 允许集群内的所有网络通信,使得分布式训练可以不受阻碍地运行。AWS 提供了安全组这一安全便捷的方式支持这个功能。我们只需创建一个安全组,确保所有集群内的实例属于同一安全组,并允许同一安全组内的所有网络通信即可,以下是我使用的设置:

让我们开始创建集群的主节点。

设置主节点

我们首先启动一个安装了 Ubuntu 20.04 AMI (ami-07cd3e6c4915b2d18) 并加入了我们之前创建的安全组的 r7iz.metal-16xl 实例,用于创建主节点。该 AMI 虽然只包含了 Linux v5.15.0,但是幸运的是英特尔和 AWS 已经为这个内核版本打上了 AMX 支持的补丁。因此,我们不需要升级内核至 v5.16。

一旦实例运行起来后,我们 ssh 登录上它并通过 lscpu 命令检查 AMX 是否确实已被支持。你应该会在 flags 部分看到如下内容:

amx_bf16 amx_tile amx_int8

然后,我们开始安装本地依赖以及 Python 依赖。

sudo apt-get update 

# Install tcmalloc for extra performance (https://github.com/google/tcmalloc)
sudo apt install libgoogle-perftools-dev -y

# Create a virtual environment
sudo apt-get install python3-pip -y
pip install pip --upgrade
export PATH=/home/ubuntu/.local/bin:$PATH
pip install virtualenv

# Activate the virtual environment
virtualenv cluster_env
source cluster_env/bin/activate

# Install PyTorch, IPEX, CCL and Transformers
pip3 install torch==1.13.0 -f https://download.pytorch.org/whl/cpu
pip3 install intel_extension_for_pytorch==1.13.0 -f https://developer.intel.com/ipex-whl-stable-cpu
pip3 install oneccl_bind_pt==1.13 -f https://developer.intel.com/ipex-whl-stable-cpu
pip3 install transformers==4.24.0

# Clone the transformers repository for its example scripts
git clone https://github.com/huggingface/transformers.git
cd transformers
git checkout v4.24.0

接着,我们使用 ssh-keygen 创建一个新的 ssh 密钥对,命名为 cluster,并保存在缺省位置 (~/.ssh)。

最后,我们用该实例创建一个新的 AMI。

设置集群

一旦 AMI 准备就绪,我们用它启动另外 3 个 r7iz.16xlarge-metal 实例,不要忘了把他们加入之前创建的安全组中。

当这些实例启动的时候,我们 ssh 登录进主节点并完成网络设置。首先,我们编辑位于 ~/.ssh/config 的 ssh 配置文件,使其支持从主节点到其他节点的免密连接,这里我们只需使用它们各自的私有 IP 及之前创建的密钥对即可。以下是我的配置文件。

Host 172.31.*.*
   StrictHostKeyChecking no

Host node1
    HostName 172.31.10.251
    User ubuntu
    IdentityFile ~/.ssh/cluster

Host node2
    HostName 172.31.10.189
    User ubuntu
    IdentityFile ~/.ssh/cluster

Host node3
    HostName 172.31.6.15
    User ubuntu
    IdentityFile ~/.ssh/cluster

到此为止,我们可以使用 ssh node [1-3] 去免密连接任何节点。

在主节点侧,我们创建一个 ~/hosts 文件,并填入集群中所有节点的名称,这些名称已在上面的 ssh 配置文件中定义。我们用 localhost 代表主节点,因为我们会在该节点启动训练脚本。我的文件如下所示。

localhost
node1
node2
node3

集群现已准备就绪,让我们开始训练吧!

启动一个分布式训练任务

在本例中,我们将在 SQUAD 数据集上微调一个用于问答的 DistilBERT 模型。如果你想试试别的示例的话,尽管去做吧。

source ~/cluster_env/bin/activate
cd ~/transformers/examples/pytorch/question-answering
pip3 install -r requirements.txt

我们首先冒个烟,启动一个单实例训练任务。请注意如下几个重要的标志变量:

  • no_cuda 确保使用 CPU 进行训练,忽略 GPU
  • use_ipex 使能 IPEX 库,确保 AMX 和 AVX 指令的使用
  • bf16 使能 BF16 训练
export LD_PRELOAD="/usr/lib/x86_64-linux-gnu/libtcmalloc.so"
python run_qa.py --model_name_or_path distilbert-base-uncased \
--dataset_name squad --do_train --do_eval --per_device_train_batch_size 32 \
--num_train_epochs 1  --output_dir /tmp/debug_squad/ \
--use_ipex --bf16 --no_cuda

不必等到任务完成,我们只运行 1 分钟用于确保所有的依赖已被正常安装。同时,这也给了我们一个单实例训练的基线性能:1 个 epoch 花费大约 26 分钟。供参考,我们测量了同样的任务在一个相当的 Ice Lake 实例 (c6i.16xlarge) 上的性能,基于相同的软件设置,每个 epoch 需要 3 小时 30 分钟。加速比达到 8 倍。我们已经能看到新指令带来的好处!

现在,让我们把训练任务分布式部署到 4 个实例上。一个 r7iz.16xlarge 实例有 32 个物理 CPU 核,我们倾向于直接使用物理核而不是虚拟核 (vCPUs) (KMP_HW_SUBSET=1T)。我们决定分配 24 个核用于训练 (OMP_NUM_THREADS) ,2 个核用于集合通信 (CCL_WORKER_COUNT) ,剩下的 6 个核给内核和其他进程使用。这 24 个训练线程分配给 2 个 Python 进程使用 (NUM_PROCESSES_PER_NODE) 。因此,一个 4 节点的集群上共有 8 (NUM_PROCESSES) 个 Python 进程。

# Set up environment variables for CCL
oneccl_bindings_for_pytorch_path=$(python -c "from oneccl_bindings_for_pytorch import cwd; print(cwd)")
source $oneccl_bindings_for_pytorch_path/env/setvars.sh

export MASTER_ADDR=172.31.3.190
export NUM_PROCESSES=8
export NUM_PROCESSES_PER_NODE=2
export CCL_WORKER_COUNT=2
export CCL_WORKER_AFFINITY=auto
export KMP_HW_SUBSET=1T

现在,我们启动分布式训练任务。

# Launch distributed training
mpirun -f ~/hosts \
 -n $NUM_PROCESSES -ppn $NUM_PROCESSES_PER_NODE  \
 -genv OMP_NUM_THREADS=24 \
 -genv LD_PRELOAD="/usr/lib/x86_64-linux-gnu/libtcmalloc.so" \
 python3 run_qa.py \
 --model_name_or_path distilbert-base-uncased \
 --dataset_name squad \
 --do_train \
 --do_eval \
 --per_device_train_batch_size 32  \
 --num_train_epochs 1  \
 --output_dir /tmp/debug_squad/ \
 --overwrite_output_dir \
 --no_cuda \
 --xpu_backend ccl \
 --bf16

现在,一个 epoch 仅需 7 分 30 秒。

任务如下图所示。图的上半部分是主节点,同时你也可以看到其他 3 个节点每个均有 2 个训练进程在运行。

4 节点的完美线性扩展需要 6 分 30 秒的训练时间 (26 分钟除以 4) 。我们非常接近于这个理想值,这充分展现了该方法很高的扩展性。

结论

如你所见,在一个英特尔至强集群上训练 Hugging Face transformers 模型是一个灵活,可扩展且性价比高的解决方案,特别是在你的数据集和模型是小尺寸或者中等尺寸情况下。

以下列出了一些其他可帮助你起步的资源:

如你有任何问题或反馈,请通过留言方式告诉我们。

感谢阅读!


英文原文: https://huggingface.co/blog/intel-sapphire-rapids

译者: Matrix Yao (姚伟峰),英特尔深度学习工程师,工作方向为 transformer-family 模型在各模态数据上的应用及大规模模型的训练推理。

头图: 茶叶蛋蛋


相关推荐

Transformer 中的专家混合模型 (MoE)

每个设备只加载分配给自己的那部分专家,负责对应的计算,并在最后参与结果的汇总。在专家混合 (MoE) 模型中,每个 token 会被路由到不同的专家。时,模型会从标准的张量并行 (Tensor Parallel, TP) 策略切换为专家并行 (Expert Parallel, EP) 策略,并采用专门的切分 (sharding) 方式。将全局专家索引映射为本地索引,屏蔽不属于当前设备的专家,确保每个设备只使用本地专家进行计算,并通过 all-reduce 在设备之间汇总部分计算结果。欢迎告诉我们你希望在。

Hugging Face 680

在 Hugging Face Hub 上引入 Storage Buckets

在未来的规划中,我们将支持 Buckets 与仓库之间的双向直接传输:例如将最终的 checkpoint 权重提升到模型仓库,或者在数据流水线完成后,把处理好的数据分片提交到数据集仓库。如果你来自 S3 风格的对象存储环境,Buckets 也提供了熟悉的使用模式,同时更适配 AI 产物,并能无缝过渡到 Hub 上的最终发布流程。对于一次性操作,可以使用。提供了原生的存放位置,比如 checkpoint、处理后的数据、Agent trace、日志,以及所有在最终定稿之前仍然有价值的中间产物。

Hugging Face 636

LeRobot v0.5.0 正式发布

成为目前规模最大的一次发布 —— 几乎在所有方向上都实现了扩展:支持更多机器人 (包括首个类人机器人) 、更多策略模型 (包括回归的自回归 VLA) 、更快的数据集处理、可以直接从 Hub 加载的仿真环境,以及基于。:我们将 SO-100 和 SO-101 的实现整合到一个更简洁的代码库中 (包括双臂配置) ,减少重复代码,更易维护,同时保持原有功能。从更严格的类型检查到更健壮的测试基础设施,我们正在持续加强 LeRobot 的基础架构,以支持未来更大规模的发展。这大大降低了分享自定义仿真环境的门槛。

Hugging Face 815

全球开源 AI 生态的未来:从 DeepSeek 到 AI+

资源约束并未限制中国 AI 的发展,相反,在某些方面,它们重塑了其发展轨迹。截至 2025 年中,Qwen 成为 Hugging Face 上衍生模型数量最多的基础模型,已有超过 11.3 万个模型以 Qwen 为基座构建,超过 20 万个模型仓库标注了 Qwen,远高于 Meta 的 Llama(2.7 万)或 DeepSeek(6 千)。通过在更开放的系统中打通模型、芯片与 PaddlePaddle,百度得以在算力、成本和监管等共同约束下,降低成本、吸引开发者并影响行业标准,同时保持自身的战略控制力。

Hugging Face 656

DeepSeek之后:中国开源人工智能生态的架构选择

与此同时,训练侧的信号也开始显现。相比之下,定制化和约束性更强的许可证因为不被熟知、理解成本高,增加了新的法律风险,在实际使用中显著增加了摩擦成本,从而降低了采用意愿,这也直接导致了图中所显示的整体下滑。在统一的能力框架下,根据任务的复杂度与价值,动态激活不同数量的专家,从而在不同请求与部署环境中分配计算资源。例如,在 DeepSeek-V3.2-Exp 发布时,华为昇腾与寒武纪芯片实现了“首日支持”,并非云端演示,而是与模型权重一同发布的可复现推理流水线,使开发者能够直接验证真实世界中的性能表现。

Hugging Face 1000

<span class=“js_title_inner“>DeepSeek之后:中国开源人工智能生态的架构选择</span>

与此同时,训练侧的信号也开始显现。相比之下,定制化和约束性更强的许可证因为不被熟知、理解成本高,增加了新的法律风险,在实际使用中显著增加了摩擦成本,从而降低了采用意愿,这也直接导致了图中所显示的整体下滑。在统一的能力框架下,根据任务的复杂度与价值,动态激活不同数量的专家,从而在不同请求与部署环境中分配计算资源。例如,在 DeepSeek-V3.2-Exp 发布时,华为昇腾与寒武纪芯片实现了“首日支持”,并非云端演示,而是与模型权重一同发布的可复现推理流水线,使开发者能够直接验证真实世界中的性能表现。

Hugging Face 934

推出 AnyLanguageModel:在 Apple 平台统一本地与远程大语言模型的 API

对于 Xcode 项目 (目前还不支持直接声明 trait) , 你可以创建一个内部的 Swift 包,指定所需 trait 依赖 AnyLanguageModel, 然后将这个包作为本地依赖添加到你的项目中。我们在这里做了有意识的取舍, 也许我们现在的设计将来会和 Apple 官方的实现产生冲突, 但这正是废弃警告 (deprecation warnings) 存在的意义。这个项目是一个起点: 你可以 fork 它、扩展它、替换不同的模型, 了解各个模块如何协作,并根据自己的需求进行定制。

Hugging Face 644

使用 Hugging Face 轻松构建并共享 ROCm 内核

自定义内核是高性能深度学习的基础,它让 GPU 操作能完全贴合你的工作负载需求——无论是图像处理、张量变换,还是其他计算密集型任务。然而,要为正确的架构编译这些内核、配置各种编译标志并干净地整合到 PyTorch 扩展中,往往会变成一团乱麻 (CMake/Nix、编译错误、ABI 问题等)。这保证了你的内核既高效、又可移植,还能无缝集成到 PyTorch 中。一旦构建完成,只需上传到 Hugging Face Hub,社区中的其他人就能直接使用你的自定义内核——几行代码即可完成集成,轻松共享高性能成果。

Hugging Face 1356

“DeepSeek 时刻” 一周年

DeepSeek 的 R1 模型降低了获取先进模型能力的门槛,并提供了一种清晰、可供效仿的发展范式,从而解锁了新的发展层级。来自美国机构的重要发布。表面上看似合作的行为,更准确地说,是在共同的技术、经济与监管压力下形成的对齐。这是中国的开源模型首次进入全球主流榜单,并且在随后的一年中,每当有新模型发布时,它都反复被用作重要的参考基准。与 2024 年相比,R1 发布之后,中国的人工智能格局逐步形成了一种新的态势:大型科技公司率先行动,初创公司迅速跟进,来自垂直行业的公司也越来越多地进入这一领域。

Hugging Face 872

Transformers v5 中的分词系统:更简洁、更清晰、更模块化

最糟糕的是,你无法创建一个空的分词器架构。如果你想用自己的数据训练一个 LLaMA 风格的分词器,没有简单的方法可以初始化一个“空白”的 LLaMA 分词器并填入自定义的词表和合并规则。最终得到的分词器将拥有你自定义的词表和合并规则,但在处理文本时的行为将与标准的 LLaMA 分词器完全一致:空格处理、特殊 token 规则、解码行为都相同。这些模型专属的分词器类会根据各自模型的需求,对后端进行配置,包括正确的词表、合并规则、特殊 token,以及标准化设置等,确保分词行为与模型训练时保持一致。

Hugging Face 805

<span class=“js_title_inner“>Transformers v5 中的分词系统:更简洁、更清晰、更模块化</span>

最糟糕的是,你无法创建一个空的分词器架构。如果你想用自己的数据训练一个 LLaMA 风格的分词器,没有简单的方法可以初始化一个“空白”的 LLaMA 分词器并填入自定义的词表和合并规则。最终得到的分词器将拥有你自定义的词表和合并规则,但在处理文本时的行为将与标准的 LLaMA 分词器完全一致:空格处理、特殊 token 规则、解码行为都相同。这些模型专属的分词器类会根据各自模型的需求,对后端进行配置,包括正确的词表、合并规则、特殊 token,以及标准化设置等,确保分词行为与模型训练时保持一致。

Hugging Face 912

构建开放的未来——我们与 Google Cloud 的全新合作伙伴关系

我们非常期待通过与 Google Cloud 的深入合作,让这一愿景加速实现——无论你使用的是 Vertex AI Model Garden、Google Kubernetes Engine、Cloud Run,还是 Hugging Face Inference Endpoints。通过这个 CDN Gateway,Hugging Face 的模型和数据集将直接缓存在 Google Cloud 上,大幅减少下载时间,并提升 Google Cloud 用户在模型供应链方面的稳定性和可靠性。

Hugging Face 656

使用 NVIDIA Isaac 构建医疗机器人:从仿真到部署

该流程通过约 70 个仿真演示和 10–20 个真实演示相结合,在模拟多样场景的同时,也保留真实数据的可靠性。NVIDIA Isaac for Healthcare 是一个专为 AI 医疗机器人开发者打造的框架,提供从数据采集到训练、评估再到部署的全流程工具链,适用于仿真环境与真实硬件。仿真一直是医学影像中弥补数据缺口的重要手段,但在医疗机器人领域,它过去往往速度太慢、系统割裂,或难以迁移到现实应用中。值得一提的是,超过 93% 的策略训练数据来自仿真环境,充分说明仿真技术在缩小机器人数据鸿沟方面的优势。

Hugging Face 1681

Codex 正在推动开源 AI 模型的训练与发布

你可以训练 0.5B 到 7B 参数规模的模型,将它们转换为 GGUF 格式便于本地运行,还可以通过多阶段流程结合不同方法。Trackio 会通过自动运行评估任务,帮助你监控训练和评估的得分,并选择表现最好的模型检查点 (checkpoint)。这里的重点不是“Codex 自己开源模型”,而是让 Codex 作为编码代理,参与并自动化开源模型的训练、评估与发布全流程。我们已经展示了 Codex 如何处理模型微调的完整生命周期,验证数据、选择硬件、生成训练脚本、提交任务、监控进度,以及转换输出。

Hugging Face 880

经同意的语音克隆

每次生成时,系统会随机选择一个日常话题 (如天气、美食或音乐) ,使句子内容丰富多样,也更自然好读,有助于录音清晰、自然,并具备良好的语音质量,同时包含明确的同意声明。换句话说,模型不会擅自“说出”你的声音,除非你亲口同意。也就是说,“同意”成为系统运行的前提条件,让原本抽象的伦理原则变成了具体可操作的系统规则,并形成可追溯、可审核的交互记录:AI 模型只会在明确同意之后才运行。现在很多语音克隆模型只需要一句话就能模仿说话人的声音,因此这句用于表达“同意”的句子,也可以同时作为语音克隆的输入数据。

Hugging Face 1159

流式数据集:效率提升 100 倍!

比如,在 Hugging Face 上传大型数据集时,Xet 的去重机制大幅减少了数据传输量,上传更快;流式加载一直是快速了解数据集的好方法,但在训练模型时,大多数人仍然选择将数据预先下载到本地,或使用 S3 等云存储——我们在训练。包,支持 Spark 直接读写 HF 数据集,内置对 Parquet CDC 和 Xet 的支持,大幅加快大数据处理。在机器学习中,特别是在处理 TB 级别的数据时,数据加载一直是个大难题。库还不支持,或者你希望获得更高的控制权,我们也提供了强大的自定义流式能力。

Hugging Face 975

huggingface_hub 1.0 正式版现已发布:开源机器学习基础五周年回顾

在 Hugging Face Hub 的早期阶段,研究人员和开发者常常面临一个困扰: 训练一个先进的模型不仅耗时、耗资源,而且在训练完成后,模型往往“被困”在个人电脑里,只能通过不稳定的 Google Drive 链接进行分享。不再依赖单一的推理后端,而是与多家无服务器推理平台合作,包括 Together AI、SambaNova、Replicate、Cerebras、Groq 等,用户通过一个统一的 API 即可调用多个后端,路由透明,按请求计费,真正实现了“按需调用,轻松推理”。

Hugging Face 1613

Hugging Face 论文页面功能指南

认领成功后,系统会将你标记为论文的提交者,即可向 Daily Papers 提交论文。在每篇论文的页面右侧,你都能找到相关资源链接,例如模型、数据集、Spaces 以及其他有用的集合。作者只需在相关资源(如模型或数据集)的 README.md 中添加该论文的 arXiv 链接,即可将资源与论文自动关联。论文提交不限于你自己的工作,你也可以分享任何你认为对社区有价值的研究论文。如果你的论文尚未在 Hugging Face 论文页面建立索引,只需点击 index 按钮,即可一步添加。如果你是首次分享论文。

Hugging Face 639

LeRobot v0.4.0 正式发布:全面提升开源机器人的学习能力

LeRobot v0.4.0 为开源机器人领域带来重要升级:引入可扩展的 Datasets v3.0、强大的新 VLA (视觉-语言-动作) 模型如 PI0.5 与 GR00T N1.5,以及全新的插件系统,简化硬件集成。从重构的数据集到灵活的编辑工具、新的仿真环境,以及面向硬件的全新插件系统,LeRobot 正在持续演进,以满足前沿具身智能 (Embodied AI) 不断发展的需求。模型需要在正确设备上的规范化、按批次的张量,而你的机器人硬件则需要特定格式的动作命令。更多细节可阅读我们此前的。

Hugging Face 1789

Gaia2 与 ARE:赋能社区的智能体评测

现有的评测环境通常与特定任务紧密耦合,缺乏真实世界的灵活性,也无法反映开放世界中混乱的现实:模拟页面不会加载失败,事件不会自发发生,也不存在异步混乱。在理想情况下,AI 智能体应当是可靠的助手。当接收到任务时,它们能够轻松处理指令中的歧义,构建逐步执行的计划,正确识别所需资源,按计划执行而不被干扰,并在突发事件中灵活适应,同时保持准确性,避免幻觉。当接收到任务时,它们能够轻松处理指令中的歧义,构建逐步执行的计划,正确识别所需资源,按计划执行而不被干扰,并在突发事件中灵活适应,同时保持准确性,避免幻觉。

Hugging Face 1806

ZeroGPU Spaces 加速实践:PyTorch 提前编译全解析

它高效、灵活,非常适合演示,不过需要注意的是,ZeroGPU 并不能在所有场景下完全发挥 GPU 与 CUDA 栈的全部潜能,比如生成图像或视频可能需要相当多的时间。根据模型的不同,这个过程可能需要几十秒到几分钟,对于 Spaces 中的实际 GPU 任务来说,这显然太慢了。通过提前编译,我们可以在一开始导出已编译的模型,将其保存,然后在任意进程中即时加载。否则,如果存在不兼容问题,就会报错。例如,在 Wan 系列视频生成模型中,如果你希望编译后的模型能够生成不同分辨率的内容,就会遇到这种情况。

Hugging Face 959

开源开发者须知:欧盟《人工智能法案》对通用人工智能模型的最新要求

根据 其第 3 条第 63 款 的定义,GPAI 模型是指:“人工智能模型,包括那些通过大规模自监督方式训练、具备显著通用性,并能够胜任多种不同任务的模型,无论其在市场上的投放方式如何,该类模型都能够被集成到各种下游系统或应用中。虽然《网络弹性法案》的措辞可能对《人工智能法案》的解释不具备约束力,但其中的这一表述以及其他相关措辞确实指向一种理解,即在FOSS 许可下提供的软件,并不总是、也并非本质上就应当被视为《网络弹性法案》意义下的“商业活动”,特别是在生产者未对其进行“商业化”的情况下。

Hugging Face 2111

欢迎 GPT OSS —— 来自 OpenAI 的全新开放模型家族!

在 GPT OSS 中,system 消息遵循严格格式,并包含当前日期、模型身份以及推理强度等级等信息,而 “developer” 消息则更为自由,这 (令人困惑地) 使它类似于其他模型的 “system” 消息。Hugging Face 与 Azure 合作,将最受欢迎的开源开放模型 (涵盖文本、视觉、语音与多模态任务) 直接引入 Azure AI Model Catalog,便于客户在托管在线端点中安全部署,借助 Azure 的企业级基础设施、自动扩缩与监控能力。轻松在多张 GPU 上部署。

Hugging Face 2546

Hugging Face 开源机器人 Reachy Mini 开启预定

无论是 AI 开发者、极客或黑客、科研人员、教育工作者、机器人爱好者,还是与孩子一同学习编程的家长,Reachy Mini 都能帮助你在桌面环境中高效完成 AI 应用的开发、最新算法的测试、项目的实际部署以及创新成果的共享。:通过上传、下载和分享机器人行为,实现行为复用与组合创新,随着 Reachy Mini 社区的发展,可能性将呈指数级扩展。:与 Hugging Face 社区超千万用户一起,上传、分享与下载机器人行为,共同扩展智能机器人的边界。:集成摄像头、麦克风与扬声器,支持基于 AI 的视听交互。

Hugging Face 1800

开源人工智能:数字主权的基石

像 OLMO2(一个相对较小的模型,其训练方法和数据完全透明,性能与 OpenAI 的 o1-mini 相当)或 OlympicCoder(一个更小的模型,在复杂编码任务上性能超过最新的 Claude 模型)这样的开源项目,充分体现了协同创新在构建先进人工智能模型中的潜力。这种能力的积累,不仅有助于形成符合本地价值观与监管要求的人工智能系统,更是面向未来的关键竞争力,在人工智能深度塑造经济、治理与社会结构的时代背景下,具有不可替代的长期战略意义。:确保在一国领土内生成的数据受该国法律和治理结构的约束。

Hugging Face 1275

nanoVLM: 简洁、轻量的纯 PyTorch 视觉-语言模型训练代码库

该模块将视觉主干网络产生的图像嵌入作为输入,并将它们转换为与语言模型嵌入层的文本嵌入兼容的嵌入。减少了图像标记的数量,这有助于降低计算成本并加快训练速度,特别是对于对输入长度敏感的基于 transformer 的语言解码器。下图演示了这个概念。在这篇博客中,我们介绍了什么是 VLM,探讨了支撑 nanoVLM 的架构选择,并详细解释了训练和推理工作流程。,可以帮助你构建和训练一个能够理解图像和文本,并基于此生成文本的模型。如果你尝试了它,并在它的基础上尝试构建,或者你只是有问题,我们都很乐意听到你的反馈。

Hugging Face 1471

HF Papers 直播| AI Insight Talk 强化学习专场

研究方向为多模态通用感知模型、多模态大模型后训练算法,在人工智能国际顶级会议及期刊发表论文十余篇,谷歌学术累计引用超过1900次,作为核心作者(共一二作)参与研发的多模态大模型InternVL-Chat系列模型在HuggingFace社区累计下载量突破1000万次,开源代码在Github获得stars超过8000个。已在 NeurIPS,ICLR,ACL 等国际顶级会议上发表多篇论文,谷歌学术引用量 600+,担任 NeurIPS 等顶级会议审稿人。为了更好的社区互动过,我们在本次直播加入了圆桌讨论环节。

Hugging Face 1257

SmolVLA: 让机器人更懂 “看听说做” 的轻量化解决方案

从左到右: (1) 异步的拾取 - 放置立方体计数,(2) 同步的拾取 - 放置立方体计数,(3) 在扰动下的拾取 - 放置立方体计数,(4) 在真实世界 SO101 上的乐高积木拾取 - 放置任务泛化。与学术基准不同,社区数据集自然地捕捉到了杂乱、现实的互动: 多变的光照、不完美的演示、非常规物体和异质的控制方案。在过去的几年里,Transformers 技术推动了人工智能的显著进展,从能够进行类人推理的语言模型到理解图像和文本的多模态系统。然而,在实际的机器人领域,进展则相对较慢。

Hugging Face 2425

参加 Hugging Face 组织的 Gradio & MCP 智能体主题黑客松

一场以智能体 (Agent) 和模型上下文协议 (Model Context Protocol,简称 MCP) 为核心的全球在线黑客松即将来袭!Model Context Protocol (MCP) 是一个开放协议,旨在标准化应用如何向大语言模型 (LLM) 提供上下文信息。:在 6 月 8 日 23:59 (UTC) 之前提交至对应的 Hugging Face Spaces。构建一个完整的 AI 智能体展示应用 (可使用 MCP,也可以不使用) ,让我们看到它真正能做些什么!

Hugging Face 1603

大模型评估排障指南 | 关于可复现性

它们在标准测试集 MATH-Hard 上预测的答案完全正确,但在 few-shot 简单模板测试中评估得分反而较低,很可能就是过拟合了 GSM8K 数据集 (另一个数学测试集) 的 prompt 和答案格式。,如果不看代码,你可能觉得就是上文提到的那样,直接对比预测结果和参考答案,不过: 如果查看代码会发现,在做对比之前预测结果还多做了一步归一化 (去除标点符号、统一数字格式等),这明显会改变对比得分。(没错不用惊讶,不一致时也会影响结果差异,因为不同模型对不同样本的表现是不一样的)。

Hugging Face 1156
上一篇: 扩散模型课程第一单元第二部分:扩散模型从零到一
下一篇: Hugging News #0106
Hugging Face
Hugging Face Hugging Face 官方账号 Hugging Face 官方账号
博客等级 码龄4年 1861粉丝 378原创
评论 1
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付:10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值