自动驾驶【免费下载链接】autowareAutoware - the worlds leading open-source software project for autonomous driving项目地址https://gitcode.com/GitHub_Trending/au/autoware点击查看免费下载本篇文章以 Autoware 开源仓库 Ansible Collectionautoware.dev_env中的huggingface_clirole 为核心讲解如何在开发环境中安装 Hugging Face 命令行工具hf以及它如何支撑 Autoware 感知模型artifacts与演示地图demo artifacts从 Hugging Face Hub 的自动化下载。读完本文你将掌握huggingface_clirole 的手动与 Ansible 自动化安装方法、hf download在真实 playbook 中的调用方式以及版本固定、HF_TOKEN透传等关键运维细节。一、huggingface_cli role 的定位为 Autoware 工件下载提供hf工具在 Autoware 的开发环境自动化体系中大量运行所需的数据并不随仓库分发而是托管在 Hugging Face Hub 上——包括感知推理模型如 BEV Fusion、CenterPoint、YOLOX 等以及 CARLA 演示地图。这些工件由一个统一的命令行工具hf下载而huggingface_clirole 的作用就是确保目标环境中存在可用的hf命令。该 role 的定位可以从 README 原文 中确认This role installs the Hugging Face CLI (hf) to download model artifacts from the Hugging Face Hub.它是一个零输入参数的 roleREADME 明确标注 Inputs 为 None且 defaults/main.yaml 为空文件只负责一件事把huggingface_hub的 CLI 装好。1.1 谁在使用它两个下游 role 的公共依赖huggingface_cli本身不下载任何数据它被两个数据下载 role 声明为依赖通过 meta/main.yaml 中的dependencies字段生效dependencies: # Runs first: the download task below writes into data_dir as the user, not as root. - role: autoware.dev_env.autoware_data_ownership - role: autoware.dev_env.huggingface_cli即autoware.dev_env.artifacts下载感知模型和autoware.dev_env.demo_artifacts下载演示地图与 rosbag在执行自身下载任务之前都会先触发huggingface_cli保证hf命令已就绪。这也解释了为什么该 role 在 galaxy.yml 声明的autoware.dev_env集合中扮演基础设施角色。二、手动安装一条命令完成hf安装原 README 给出的手动安装方式非常精简只有一条命令但其中蕴含了版本策略值得逐字拆解pipx install --force huggingface_hub1.*pipx在隔离环境中安装并暴露 Python 命令行应用的官方工具。这里使用 pipx 而非pip install --user是为了把hf装进独立的虚拟环境避免污染系统 Python 的 site-packages同时又能把hf可执行文件链接到用户可执行路径。huggingface_hub1.*版本约束被固定在1.x主版本线。原因见下文自动化任务中的注释——主版本边界major bound能保持hfCLI 表面命令、参数的稳定避免跨主版本升级带来的破坏性变更。--force强制重装/覆盖。即便目标环境中已存在一个版本也会重新安装到该约束下使安装结果收敛到当前约束。安装完成后验证hf --help若hf不在 PATH 中需确认 pipx 的 bin 目录已加入 PATHpython3 -m pipx ensurepath可参考 Ansible 安装指南 中的同样做法。三、自动化安装Ansible 任务逐行拆解对应的自动化实现位于 tasks/main.yaml共三个任务逻辑为「检查 → 补装 → 安装/收敛」3.1 任务一检查 pipx 是否已安装- name: Check whether pipx is installed ansible.builtin.stat: path: /usr/bin/pipx register: huggingface_cli__pipx使用ansible.builtin.stat探测/usr/bin/pipx是否存在结果存入huggingface_cli__pipx变量供下一个任务的条件判断使用。注意这里检查的是系统路径/usr/bin/pipx而不是用户级 pipx。3.2 任务二按需安装 pipx- name: Install pipx become: true ansible.builtin.apt: name: pipx state: present update_cache: true when: not huggingface_cli__pipx.stat.existsbecome: true通过权限提升以 root 执行 APT 安装update_cache: true安装前刷新 APT 软件源缓存确保能解析到最新可用的 pipx 包when: not huggingface_cli__pipx.stat.exists仅当第一步检查到 pipx 不存在时才执行保证幂等。这个任务与 Ansible 安装指南 中sudo apt-get -y install pipx的做法一致只是以 Ansible 原语形式落地。3.3 任务三通过 pipx 安装hf# The major bound keeps the hf CLI surface stable. --force makes every run converge to the # bound, so an install that holds an out-of-range version gets corrected. - name: Install huggingface_hub for the hf CLI ansible.builtin.command: cmd: /usr/bin/pipx install --force huggingface_hub1.* changed_when: false这是核心任务源码注释见 tasks/main.yaml明确说明了两个关键设计决策主版本边界major boundhuggingface_hub1.*使hfCLI 的命令表面保持稳定防止上游 2.x 大版本引入的接口变化破坏下游hf download调用--force收敛语义每次运行都会重新安装到该约束下因此即使环境中存在一个超出范围的旧版本如 0.x也会被强制修正确保每次 playbook 执行后hf始终处于约定版本线changed_when: false由于命令具有收敛性、无法简单判断是否发生变更因此统一声明为不触发 changed 状态避免 playbook 结果误报。手动安装命令与自动化命令的唯一区别是显式指定了/usr/bin/pipx的绝对路径——因为该任务可能在不同用户的上下文含 root下执行绝对路径可避免 PATH 解析差异。四、hfCLI 在 Autoware 中的两大实际用途安装hf只是手段它最终服务于两类数据下载任务。这两处调用也是理解该 role 价值的最佳实例。4.1 感知模型工件下载artifacts roleartifacts role 的任务循环中直接调用hf download从AutowareFoundation组织下载感知栈推理模型每个模型都 pin 到固定 tagcmd: - hf download AutowareFoundation/{{ item.repo }} --revision {{ item.revision }} --local-dir {{ data_dir }}/{{ item.dest | default(item.repo) }}当前版本 pin 的模型清单见 artifacts/tasks/main.yaml模型仓库AutowareFoundation 下Revisionyabloc_pose_initializerv1.0bevfusionv2.0camera_streampetrv1.0tensorrt_bevdetv1.0image_projection_based_fusionv5.0lidar_apollo_instance_segmentationv1.0lidar_centerpointv4.1lidar_transfusionv2.1tensorrt_yolox同时包含 whole_image_traffic_light_detector 模型v1.0traffic_light_classifierv4.0diffusion_plannerv3.0 / v3.1 / v4.0 / v5.0tensorrt_vad落盘为vad/v0.1v0.1traffic_light_fine_detectorv3.0simpl_predictionv0.1ptv3v4.0lidar_frnetv2.0calibration_status_classifierv2.0几个值得注意的落盘策略代码注释中明确diffusion_planner 多版本共存四个 tag 指向同一仓库、文件名相同因此必须通过dest分别落到diffusion_planner/v3.0、v3.1、v4.0、v5.0子目录否则会互相覆盖tensorrt_vad 的目录别名落盘目录是vad/v0.1而非仓库名因为节点读取路径是$(var data_path)/vad/v0.1目录名必须与下游代码的读取路径严格对齐默认落盘位置data_dir默认为~/autoware_data/ml_models属于assets/、maps/、ml_models/、recordings/、scenarios/的资产类型目录布局见 artifacts README。4.2 演示地图与 rosbag 下载demo_artifacts roledemo_artifacts role 同样依赖hf用于下载托管在 Hugging Face 上的 CARLA 演示地图数据集并支持--include/--exclude模式裁剪cmd: - hf download AutowareFoundation/{{ item.repo }} --repo-type dataset --revision {{ item.revision }} {% for pattern in item.include | default([]) %}--include {{ pattern }} {% endfor %} {% for pattern in item.exclude | default([]) %}--exclude {{ pattern }} {% endfor %} --local-dir {{ demo_artifacts__autoware_data_dir }}/{{ item.dest }}当前的两个数据集条目map-carla-kashiwanohapin 到 tag0.2.0--exclude *.mp4丢弃演示视频落盘到maps/carla-kashiwanohacarla-ue5-maps暂无 tag因此 pin 到发布Town10HD_Opt的 commit682ddd48b4cf305507646cb2f2e563bbedac4c2e--include autoware_maps/Town10HD_Opt/*只拉取该世界落盘到maps/数据集自带autoware_maps/前缀hf download会保留仓库相对路径。五、在完整 playbook 中运行命令与参数实战在实际开发环境中不需要单独执行本 role而是通过autoware.dev_env.install_dev_envplaybook 的 tag 机制触发见 artifacts README 与 demo_artifacts README。5.1 安装 Ansible 集合cd ~/autoware # 仓库根目录 ansible-galaxy collection install -f -r ansible-galaxy-requirements.yaml当有新 playbook 加入时需重复执行此步骤见 Ansible 集合安装说明。5.2 下载感知模型工件ansible-playbook autoware.dev_env.install_dev_env --tags artifacts \ -e data_dir$HOME/autoware_data/ml_models --ask-become-pass5.3 下载演示地图与 rosbagansible-playbook autoware.dev_env.install_dev_env --tags demo_artifacts \ -e demo_artifacts__autoware_data_dir$HOME/autoware_data --ask-become-pass参数要点--ask-become-pass虽然下载任务本身以运行 playbook 的用户身份执行、不使用 sudo但其两个依赖中autoware_data_ownership会修正 root 拥有的安装目录、huggingface_cli在 pipx 缺失时会用become: true安装 pipx因此只要这两个条件可能成立就应保留该选项见 artifacts README 的说明HF_TOKEN透传下载任务通过HF_TOKEN: {{ lookup(env, HF_TOKEN) }}把环境变量中的令牌传给hf见 artifacts/tasks/main.yaml 与 demo_artifacts/tasks/main.yaml因此如需访问受限模型可在运行前export HF_TOKEN...PATH 注入任务显式把PIPX_BIN_DIR默认~/.local/bin前置到 PATH确保hf命令可被解析见 artifacts/tasks/main.yaml。六、注意事项与最佳实践综合源码与文档使用本 role 时值得留意以下几点版本收敛而非固定锁死huggingface_hub1.*是一个主版本边界约束配合--force实现「每次运行都收敛到 1.x 最新版」。它保证 CLI 表面稳定但不会精确到补丁级别——这与仓库其他环节的严格锁版本策略如 version_lock role 对 APT 包的 pinning形成互补分工。完整性保障模型工件的完整性依赖 Hugging Face Hub 与传输层而非本仓库内 pin 的校验和——artifacts README 明确说明 Their integrity relies on the Hub and the transport, not on checksums pinned in this role。下载归属权所有下载任务以运行 playbook 的用户身份执行工件文件归属于该用户无任务使用 sudo仅前述两个条件性依赖需要提权。幂等与收敛由于changed_when: false且--force重装重复执行 playbook 是安全的且会自动修正版本越界的环境。总结huggingface_clirole 虽小却是 Autoware 开发环境自动化链路中承上启下的关键一环上游承接hf工具的安装手动一条pipx install --force huggingface_hub1.*自动化则拆解为「检查 pipx → 补装 pipx → 收敛安装 hf」三个幂等任务下游支撑 artifacts 与 demo_artifacts 两个 role 对 Hugging Face 模型与地图的批量、固定版本下载。理解它的版本约束策略、--force收敛语义与HF_TOKEN/PATH 传递机制就能在自定义 Autoware 环境或扩展工件清单时正确复用这套现成的下载基础设施。赞分享自动驾驶【免费下载链接】autowareAutoware - the worlds leading open-source software project for autonomous driving项目地址https://gitcode.com/GitHub_Trending/au/autoware点击查看免费下载相关推荐MLX-VLM 本地 Hugging Face 缓存模型清单hf-cache-models 技能与 --model-discovery hf-cache 实战指南MLX VLM 本地 Hugging Face 缓存模型清单hf cache models 技能与 model discovery hf cache 实战指南人工智能大模型多模态模型推理服务本地部署微调模型量化T5 Hugging Face集成PyTorch环境下的快速开发指南T5 Hugging Face集成PyTorch环境下的快速开发指南 探索文本到文本转换的终极解决方案T5Text to Text Transfer Tr人工智能大模型NLP预训练微调Model-Optimizer 模型下载 Agent 实战指南Day 0 工作区中的 Hugging Face 模型获取与交接规范Model Optimizer 模型下载 Agent 实战指南Day 0 工作区中的 Hugging Face 模型获取与交接规范 本篇技术指南聚焦 NVID人工智能大模型模型优化模型量化模型压缩上一篇MiroFish部署指南Docker容器化与源码安装的深度对比与实践下一篇如何用noteDigger零门槛实现音频转乐谱让音乐创作不再困难创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考