HuggingFace贡献：模型上传Hub

CH-24-03-002·约 18 分钟·AI实践项目·更新 2026-08-13

想象你是一位大厨，在自家厨房里花三个月研发了一道招牌烤鸭：选鸭、腌料、火候、蘸酱，每一样都反复打磨。菜是好菜，可除了亲友，全城食客都不知道它的存在。这时你听说有一个「云外卖平台」，主厨们把各自的招牌菜搬上去，客人点单、复刻、评价，整个城市瞬间成了你的食客圈。这个平台，就是 HuggingFace Hub——AI 模型界的线上商城。上传模型到 Hub，本质上就是一次「开店营业」：你的模型是招牌菜，仓库是店铺，模型卡片是菜单，Access Token 是店铺钥匙，Git LFS 是冷链运输车，每一次 git push 都是后厨出货。这篇文章就带你把这家店从选址、装修到开业、迭代，完整走一遍。

岗位关联

学会把模型上传到 Hub，是你从「自己闷头炼丹」走向「开源贡献与工程协作」的第一张入场券，也是 AI 工程师简历上最有说服力的作品集。

可视化演示
Hub基本概念：认清你入驻的这家商城
仓库创建：在商城租下你的铺面
认证授权：领取你的店铺门卡
文件传输：Git LFS 冷链车专线
模型卡片：写好你的点单菜单
版本管理：每一版菜谱都存档
社区协作：从单店到联合品牌
AI 应用场景
Python 演示
常见误区
面试题

可视化演示

动态展示Hub模型仓库结构、文件与元数据规范、模型卡片编写与版本发布流程。

本节配有交互动效（进入视口后自动加载，约 3KB）。

Hub基本概念：认清你入驻的这家商城

你决定入驻云外卖平台，第一件事不是急着租铺面，而是先搞清楚平台的规矩：商城开在哪里、能出租哪些业态、物业怎么管水电和客流。Hub 之于 AI 开发者，正如商城之于大厨——只有摸清平台的全貌，后续每一步才走得稳。

HuggingFace Hub 是 AI 圈最大的「食材与菜品集散地」，托管三类资产：模型（Model）、数据集（Dataset）、应用空间（Space）。每类资产都以「仓库」为最小单位，一个仓库对应一道菜，仓库的完整 ID 就是门牌号，例如 bert-base-uncased 或 yourname/my-model，且全局唯一。任何人记住这个门牌号，就能精准找到你的菜。

仓库在底层由三层结构支撑：一个 Git 仓库负责版本与元数据，一套大文件存储（Git LFS）托管动辄几个 GB 的权重文件，一个 Web 渲染层把 README 变成精美的展示页。当你调用 from_pretrained("yourname/my-model") 时，HuggingFace 客户端会根据门牌号自动把三层装配成可直接加载的模型对象，你只管点菜，平台负责出餐。

看清商城的结构后，你心里有底了：接下来要租铺面（创建仓库）、领钥匙（认证授权）、上货（文件传输）、写菜单（模型卡片）。我们一步步来开店。

\text{repo\_id} = \text{namespace} + "/" + \text{model\_name}

仓库 ID 由归属方与模型名拼成，相当于外卖平台上「店铺所属档口 + 店铺名」的组合门牌。

namespace 命名空间仓库归属的账户，可以是个人用户名或组织名，决定了门牌号的「街区」。 $\text{namespace} \in \{ \text{user\_name},\ \text{org\_name} \}$
分隔符斜杠用 / 连接前后两段，让仓库 ID 在全局唯一且可读。 $"/"$
model_name 模型名同一账户下唯一，通常用小写字母、数字与连字符表示。 $\text{model\_name} = \text{lower}(\text{words})\ \text{with}\ "-"$

仓库创建：在商城租下你的铺面

开店第一步是租铺面。你走到商城管理处，工作人员给你一张三栏申请表：第一栏「铺面归属」，第二栏「店铺名称」，第三栏「营业状态」。填完这张表，你的店就在商城地图上有了位置。

在 HuggingFace 上，这张表就是「New Model」页面。第一栏 Owner 选择个人账户或组织账户，相当于决定铺面挂在个人名下还是品牌名下；第二栏 Model name 填写模型名，这一步决定门牌号的后半段；第三栏选择 Public（公开）或 Private（私有），公开店铺所有人都能来，私有店铺只有持钥匙者能进。技术团队还会用 exist_ok=True 参数，让「重复填表」也不报错，这在自动化脚本里非常实用。

一个标准的模型仓库通常由三类文件构成：config.json 记录模型结构参数，相当于菜谱的「主料清单」；model.safetensors 存放训练好的全部权重，是分量最重的「半成品食材」；README.md 是展示给客人的「菜单」，没有它店铺在商城里就没有门面。

铺面租好了，名字也挂上了。但别急着上货——你还缺一把能打开铺面大门的钥匙，这就是下一节要讲的认证授权。

\text{repo} = \{ \text{config.json},\ \text{model.safetensors},\ \text{README.md},\ \dots \}

仓库本质是若干文件的集合，其中配置、权重、说明三类必不可少，其余文件按需添加。

配置字典config.json 记录模型结构参数与版本信息，如同菜谱的主料清单。 $\text{config} = \{ \theta_{\text{layers}},\ \theta_{\text{hidden}},\ \dots \}$
权重文件model.safetensors 存放全部训练参数，属于大文件，需要冷链车运输。 $\text{weights} = \{ W_1,\ b_1,\ W_2,\ b_2,\ \dots \}$
模型卡片README.md 提供展示层信息，让商城前端把仓库渲染成完整店铺页。 $\text{README} \rightarrow \text{card}_{\text{web}}$

认证授权：领取你的店铺门卡

铺面装修好后，你从商城管理处领到一张门卡。门卡不是万能钥匙，而是分等级的：普通员工卡只能进后厨备料（read），店长卡才能开门营业、改菜单、上新菜（write）。门卡一旦丢了，任何人捡到都能冒充你进店。

HuggingFace 的「门卡」叫 Access Token。你可以在 huggingface.co/settings/tokens 页面创建，创建时选择 read 或 write 权限。拿到 Token 后，在终端执行 huggingface-cli login，它会把 Token 存到本地的 ~/.huggingface/token 文件里，之后所有上传下载操作都会自动出示这张门卡。在代码里，更安全的做法是从环境变量读取，例如 os.environ.get("HF_TOKEN")，而不是把钥匙明文写进脚本。

平台校验门卡时，会根据 Token 的权限范围决定放行等级：write 门卡可以推送代码、创建仓库；read 门卡只能下载和浏览；没有门卡的匿名用户，访问公开仓库可以，访问私有仓库则会被拒之门外，返回 401 错误——「请出示有效门卡」。

钥匙到手，接下来就是重头戏——把后厨的大箱小箱运上货架。普通小件自己拎，大件必须呼叫冷链车。

\text{access} = \begin{cases} \text{write} & \text{if } \text{scope} = \text{write} \\ \text{read} & \text{if } \text{scope} = \text{read} \\ \text{denied} & \text{otherwise} \end{cases}

访问权限由 Token 的权限范围决定，write 门卡全通、read 门卡只读、无卡则被拒绝。

write 分支门卡带写权限时，可以执行推送、建仓等写操作，相当于店长卡。 $\text{case}_1:\ \text{scope}_{\text{token}} = \text{write}$
read 分支门卡只读时，能下载模型但不能修改仓库，相当于员工卡。 $\text{case}_2:\ \text{scope}_{\text{token}} = \text{read}$
拒绝分支未携带任何 Token 时，访问受保护仓库被拒绝。 $\text{case}_3:\ \nexists\ \text{token}$

文件传输：Git LFS 冷链车专线

上货这天你才发现，招牌烤鸭的食材量大得惊人：几十公斤的整鸭必须用冷链车运输，小包的酱料则骑电动车就能送。如果硬把整鸭塞进普通快递车，不仅车装不下，还会把车压坏，导致所有订单都送不了。

模型上传正是同样的道理。一个 pytorch_model.bin 或 model.safetensors 动辄几百 MB 甚至几个 GB，如果直接塞进 Git 仓库，仓库会急剧膨胀，克隆慢如蜗牛。Git LFS（Large File Storage）就是那条冷链专线：它把大文件的完整内容存到独立的 LFS 存储端，而 Git 仓库里只放一个极小的「提货单」指针，指针上写着文件内容的 SHA-256 指纹和大小。任何人克隆仓库拿到的只是提货单，真正需要大文件时，客户端凭单据到 LFS 仓取货。

上传方式有三种：小文件可以直接在网页上拖拽上传，相当于骑电动车送小包；整个目录推荐用 git push，但需要先 git lfs install 并执行 git lfs track "*.safetensors" 让大文件走冷链；最省心的是用 Python 的 huggingface_hub 库调用 upload_folder，它会自动判断哪些文件该上冷链车，一次性把整箱货发走。

理解了 LFS，你就明白为什么克隆模型仓库那么快——因为 Git 拉的是提货单，大货在真正需要时才从冷链仓提取。货物上架完毕，接下来要写菜单了。

\text{oid} = H_{\text{SHA256}}(\text{file}), \qquad \text{pointer} = (\text{oid},\ \text{size})

LFS 把大文件压缩成「指纹 + 大小」的二元组指针存入 Git，真实内容留在独立存储端。

SHA-256 哈希对文件内容做密码学哈希，任何一比特改动都会得到完全不同的指纹。 $\text{oid} = H_{\text{SHA256}}(\text{file})$
文件大小记录原始文件的字节数，下载时用于校验完整性。 $\text{size} = \text{len}(\text{file})$
指针替换Git 历史中只存二元组，内容存入 LFS 存储端，克隆时不再搬运大货。 $\text{repo}_{\text{git}} \leftarrow (\text{oid},\ \text{size}), \quad \text{content} \rightarrow \text{LFS}_{\text{store}}$

模型卡片：写好你的点单菜单

货上了架，可如果菜单一片空白，客人路过店铺都不知道你卖的是什么菜。好菜单要有图片、口味描述、配料表和营养成分表。模型卡片（Model Card）就是模型的菜单，它决定了客人愿不愿意点单。

模型卡片对应仓库根目录的 README.md。文件顶部有一段 YAML 格式的元数据，包含 license（开源协议，相当于「是否允许加盟」）、tags（分类标签，相当于「川菜/粤菜」归类）、pipeline_tag（任务类型，如 text-classification，它决定商城能不能提供「一键试吃」的推理 API）。正文部分用 Markdown 写清楚模型简介、训练数据、评估结果与使用示例，让客人三分钟就能判断这道菜合不合口味。

评估指标是菜单上的「营养成分表」。以分类任务最常用的准确率为例，它衡量的是所有预测中猜对的比例：真正例和真负例是「点对了菜」的订单，假正例和假负例是「上错了菜」的订单，准确率就是正确订单占总订单的比值。一个连准确率都不标的模型卡片，就像没有营养成分表的食品，客人很难信任。

菜单写好了，客人开始点单。但开店不是一锤子买卖——你的烤鸭配方还会迭代，这时就需要版本管理出场了。

\text{accuracy} = \frac{TP + TN}{TP + TN + FP + FN}

准确率 = 预测正确的样本数 ÷ 总样本数，是最直观的模型质量「营养成分表」。

正确预测总和真正例与真负例相加，表示所有预测对的结果。 $TP + TN$
样本总数四种结果相加，覆盖全部预测样本，构成分母。 $TP + TN + FP + FN$
比值正确数除以总数，得到 0 到 1 的分数，越高代表越「对味」。 $\frac{\text{correct}}{\text{total}}$

版本管理：每一版菜谱都存档

你的烤鸭配方不是一次定终身的：v1.0 初版反响平平，v1.1 改了蘸酱配方，v2.0 干脆换了鸭种。聪明的你每改一版都在菜谱本上记一笔，客人可以说「我要复刻 v1.1 那版的味道」，后厨就能精确还原。

在 Hub 上，每执行一次 git commit 加 git push，仓库就多了一个不可变的快照。配合语义化版本号（Semantic Versioning），你可以清晰地管理迭代节奏：主版本号（major）在架构不兼容时递增，次版本号（minor）在向后兼容的新功能时递增，修订号（patch）只在修 bug 时递增。客人下载时可以指定 revision：from_pretrained("user/model", revision="v1.1") 就能精确复刻任意一版。

回滚也因此变得轻松——发现 v2.0 的鸭种有问题，直接切回 v1.1 的 revision 即可，完全不需要「重训一个旧模型」。但要注意的是，版本管理解决的是「快照」问题，不是「仓库垃圾」问题：如果把仓库当网盘，每次都把新 checkpoint 往上传，历史快照会越来越臃肿，所以配合 LFS 和清理策略才是上策。

你的店越做越好，口碑传开后，开始有同行厨师想加入一起改良菜谱。这就进入了社区协作的阶段——从单打独斗到联合经营。

v = (v_{\text{major}},\ v_{\text{minor}},\ v_{\text{patch}})

语义化版本用三个数字标记迭代，分别对应不兼容更新、新功能与 bug 修复。

主版本号模型架构发生不兼容变化时递增，相当于换了核心食材。 $v_{\text{major}} \gets v_{\text{major}} + 1$
次版本号新增向后兼容的功能时递增，相当于加了新蘸酱。 $v_{\text{minor}} \gets v_{\text{minor}} + 1$
修订号只修复 bug 时递增，相当于微调火候。 $v_{\text{patch}} \gets v_{\text{patch}} + 1$

社区协作：从单店到联合品牌

店做大后，你决定开放加盟。感兴趣的厨师可以把你的菜谱完整复制一份到自己家里研究（fork），改良后给你提交「加盟申请」（Pull Request），你审核通过后把改进合入主菜谱（merge）。整个流程既保护了原作者的署名权，又让好菜在协作中越做越好。

在 HuggingFace 上，这个流程由 Git 的 fork 与 Pull Request 机制支撑：任何人可以 fork 公开仓库到自己的账户下自由修改，改完提交 PR，仓库维护者在网页上审阅 diff、留言讨论，最终 merge 或关闭。对于团队内部，组织账户（Organization）提供了更精细的权限管理——不同成员拥有不同角色，相当于连锁品牌里总部、店长、店员各司其职。

协作的终点不只是代码，还有生态：把 pipeline_tag 配好的仓库接入 Inference API 后，访客可以直接在网页上试玩你的模型；仓库的 Star 数与下载量就是你的「口碑积分」。一次成功的开源贡献，往往就是从一个高质量的模型仓库开始的——它让全世界的大厨都能复刻并改良你的菜。

从认清商城到联合经营，你的「云外卖店」已经完整走通了全链路。下面我们看看这些技能在实际工作中是怎么派上用场的。

\text{contribution} = \text{fork} \rightarrow \text{commit} \rightarrow \text{pull\_request} \rightarrow \text{merge}

开源协作的标准链路：复刻 → 修改 → 提 PR → 合入，每个环节都有迹可循。

复刻仓库fork 把他人仓库复制到你的账户下，获得独立修改权。 $\text{repo}_{\text{mine}} = \text{copy}(\text{repo}_{\text{theirs}})$
本地修改commit 在本地记录改动，形成可评审的差异。 $\text{diff} = \text{new} - \text{old}$
合并入主线PR 审核通过后 merge，把改动合入主仓库。 $\text{repo}_{\text{main}} = \text{repo}_{\text{main}} \cup \text{diff}$

AI 应用场景

个人模型分享与团队复用

阶段：模型部署与共享阶段

解决的问题：传统方式下，训练好的模型躺在本地磁盘或网盘里，同事想用得等你把文件打包发过去，版本还对不上；分享到社区更是无从谈起。把模型上传 Hub 后，任何人凭 repo_id 一行代码加载，版本、依赖由平台统一管理。

具体案例：NLP 工程师微调了一个中文情感分类模型，在本地目录整理好 config.json、model.safetensors 和写清评估指标的 README.md，用 upload_folder 一键推送到 Hub 公有仓库。团队同事直接 from_pretrained("team/sentiment-zh") 加载，产品线立刻用上了新模型。

开源项目贡献与代码评审

阶段：开源协作与代码评审阶段

解决的问题：以前给开源项目提改进，只能发邮件补丁，维护者难以审阅。Hub 的 fork + Pull Request 流程让每一次改动都可追踪、可讨论、可回滚，贡献者从「发邮件的人」变成「有记录的共建者」。

具体案例：开发者发现 transformers 某个 tokenizer 在边界场景会报错，fork 仓库、写修复代码与测试用例、提交 PR，维护者在 PR 页面逐行评审后合入。这个 commit 成了他简历上最有分量的开源贡献证明。

企业私有模型资产管理

阶段：MLOps 模型注册与版本管理阶段

解决的问题：企业内多个模型散落在不同工程师的电脑上，命名混乱、版本失控、权限不明。用私有仓库 + 组织账户统一收口，配合 CI 流水线自动上传，模型像代码一样有版本、有评审、有回滚。

具体案例：某公司的 MLOps 团队建了一个组织账户，按项目创建私有仓库，CI 脚本在训练完成后自动执行 upload_folder 推送新权重，并打上 v1.1 标签。线上服务通过 revision 灰度切换版本，出问题一键回滚。

Python 演示

python33 行

import osfrom huggingface_hub import HfApi, login, upload_folder # 步骤1: 登录认证 - 出示你的店铺门卡# 实际使用时会读取 HF_TOKEN 环境变量，避免把钥匙写死在代码里# login(token=os.environ.get("HF_TOKEN")) # 步骤2: 创建仓库 - 相当于在平台上开一家店api = HfApi()repo_id = "your-name/my-sentiment-model"api.create_repo(    repo_id=repo_id,    repo_type="model",    private=False,    exist_ok=True,) # 步骤3: 本地模型目录准备 - 把菜备好放上后厨local_dir = "my_model"assert os.path.isdir(local_dir), "请先把模型文件放到 my_model 目录" # 步骤4: 上传整个目录 - LFS 冷链车自动接管大文件result = upload_folder(    repo_id=repo_id,    folder_path=local_dir,    commit_message="上传微调后的情感分类模型 v1.0",    ignore_patterns=["*.log", "checkpoint-*"],)print("上传完成，仓库地址:", result) # 步骤5: 验证仓库文件清单 - 检查货架上的商品for f in api.list_repo_files(repo_id=repo_id):    print("-", f)

目的：演示用 huggingface_hub 自动完成「登录 → 建仓 → 上传 → 验证」的完整模型发布流程。

login(token=os.environ.get("HF_TOKEN"))从环境变量读取门卡，避免硬编码泄露密钥
api.create_repo(repo_id=..., exist_ok=True)开店并保证幂等，重复执行不报错
repo_type="model"声明这是模型仓库，而非数据集或 Space
assert os.path.isdir(local_dir)上传前先确认本地目录存在，避免空跑
upload_folder(repo_id=..., folder_path=...)一键上传整个目录，大文件自动走 LFS
ignore_patterns=["*.log", "checkpoint-*"]过滤日志与中间检查点，防止污染仓库
api.list_repo_files(repo_id=...)拉取远端文件清单，确认上架结果

常见误区

误区我本地 `git init` 之后把模型文件一 `git add`，直接 `git push` 就能推到 Hub，不需要任何额外配置。

正解大文件超过平台限制时 push 会被拒绝，即使成功也会让仓库膨胀到几 GB，所有人克隆都痛苦。必须先用 git lfs install 并 git lfs track "*.safetensors"，让大文件走 Git LFS 冷链车；用 upload_folder 则能自动判断并处理这一切。

为何常见：普通 Git 在 GitHub 上推小项目习惯了，没意识到模型权重的体积是代码的几百倍，冷链车和电动车走的是不同通道。

误区Token 是我自己账号的，脚本只有我看，硬编码进去最方便，反正别人拿不到。

正解一旦脚本被推到公开仓库或分享给同事，Token 就等于把店铺钥匙挂在店门口。攻击者拿到 write 权限 Token 后可以篡改仓库甚至投毒模型。正确做法是 huggingface-cli login 存本地配置，或用环境变量 HF_TOKEN 注入。

为何常见：本地跑通功能时图省事，且对「密钥泄露」缺乏直观感受——直到看见 GitHub 的泄露扫描告警邮件。

误区模型文件传上去才是核心，README 就是给平台凑数的说明文字，越短越好。

正解模型卡片是客人点单前看到的唯一门面。没有它，别人不知道你的模型怎么用、效果如何、允许什么协议，下载量会惨不忍睹。写好 license、pipeline_tag、评估指标和使用示例，模型才会被社区真正用起来。

为何常见：技术人习惯「代码会说话」，忽略了开源协作中「沟通即产品」的规律，菜单没写好，再好的菜也无人问津。

误区我 push 了 v2.0，仓库里只剩新文件了，旧版本被覆盖，再也找不回来。

正解每次 commit 都是独立快照，旧版本永远存在。任何人（包括你自己）都可以通过 revision 参数指定旧 tag 或 commit 拉取，「回滚」只是换一行 revision 的事。这正是版本管理的价值所在。

为何常见：只把仓库当成「最新文件的网盘」，不了解 Git 的快照机制，就像以为改菜单后旧菜谱会被销毁一样。

误区仓库设为 Private 别人就完全看不到了，可以把训练数据也一起传上去。

正解私有只是「外部不可见」，组织内成员按权限可见，平台运维方在协议范围内也可能接触。更重要的是，训练数据可能包含用户隐私，即使私有也不该无脑上传。敏感数据应脱敏后另存合规存储，仓库只放模型与必要配置。

为何常见：把「私有」误解为「绝对安全」，忽略了权限分层和数据合规这两个维度，就像以为锁了店门就没人能透过窗户看见后厨。

面试题

Q1. HuggingFace Hub 上大文件用什么机制存储？

单选题 · easy

A.普通 Git 直接存储
B.Git LFS 指针加独立存储← 正确答案
C.压缩成包再上传
D.外链到其他网盘

答案：B。大文件若塞进普通 Git，仓库会膨胀到数 GB，克隆极慢。Git LFS 采用「指针 + 独立存储」，Git 里只存提货单，实际大货在 LFS 仓，就像冷链车和普通快递分开走。压缩包无法在线预览与差异化更新，外链则失去平台托管能力。

Q2. 创建模型仓库时，以下哪项不是必填项？

单选题 · easy

A.模型的仓库命名
B.所有者个人或组织
C.GPU 型号与显存← 正确答案
D.公开或私有属性

答案：C。创建仓库必须确定 Owner、模型名和可见性，但 GPU 型号不是必填——那是模型卡片里才写的硬件信息。就像开店不用把后厨灶台型号写进营业执照，GPU 属于「菜品营养成分」而非「店铺注册信息」。

Q3. 模型卡片 README 的主要作用是什么？

单选题 · easy

A.增加仓库的代码量
B.描述用途评估用法← 正确答案
C.替代 commit 信息
D.存储训练数据集

答案：B。模型卡片相当于菜单加使用说明书，写明模型用途、评估指标、使用方式与开源协议。它不是代码量、提交信息或数据集容器。食客点不点单，就看菜单写得好不好；一个合格的模型仓库必须有过关的 README。

Q4. Access Token 的 write 权限与 read 权限主要区别？

单选题 · mid

A.可推送代码或建仓← 正确答案
B.可查看私有数据
C.可删除平台账号
D.可绕过磁盘配额

答案：A。write 门卡能执行推送代码、创建仓库等写操作，read 门卡只能下载与浏览。查看私有数据属于授权范围问题，删除账号与绕过配额超出 Token 权限边界。门卡等级越高，能开的门越多，因此 write Token 要像店长钥匙一样保管好。

Q5. 在 Git LFS 中，大文件在 Git 仓库里如何表示？

单选题 · mid

A.完整数据进入历史
B.拆分存放于多处
C.指针含 oid 与 size← 正确答案
D.Base64 编码保存

答案：C。Git LFS 的指针只包含 oid（SHA-256 哈希）与文件大小两项，不含完整内容。A 是普通 Git 的错误做法，D 是另一种编码误解，指针是「提货单」而不是货本身。克隆仓库时只拉提货单，大货在需要时凭单提取。

Q6. 模型更新后想下载旧版本，应该怎么做？

单选题 · mid

A.无法找回旧版本
B.指定 revision 拉取← 正确答案
C.从浏览器缓存找回
D.重新训练一个模型

答案：B。Git 每次 commit 都是独立快照，通过 revision 参数指定旧 commit 或 tag 即可拉取任意版本，如 from_pretrained("user/model", revision="v1.1")。相当于菜谱每版都存档，客人可以点任何一版的味道，A 说无法找回是误解。

Q7. upload_folder 会自动把哪些文件交给 Git LFS 处理？

单选题 · hard

A.所有文本类文件
B.超出阈值的大文件← 正确答案
C.仓库根目录中的 README
D.仅 .png 图片文件

答案：B。upload_folder 会自动识别超过阈值的大文件（如 .bin、.safetensors）走 LFS，这与「大件走冷链车」的逻辑一致。文本、README、小图片则按普通 Git 处理，既不浪费冷链资源，也不让普通快递超载。

Q8. 以下哪些方式可以向 Hub 上传模型？

多选题 · easy

A.网页界面拖拽上传← 正确答案
B.git push 配合 LFS← 正确答案
C.huggingface_hub 上传← 正确答案
D.发送邮件附加文件

答案：ABC。官方提供三种上传渠道：Web 界面拖拽适合小文件快速上架，git push 适合有 Git 习惯的开发者，huggingface_hub 的 upload_folder 适合自动化脚本。邮件附件是干扰项，平台并不支持这种方式。

Q9. 模型卡片 YAML 元数据中可以包含哪些字段？

多选题 · mid

A.license 协议声明← 正确答案
B.pipeline_tag 标记← 正确答案
C.tags 分类标签← 正确答案
D.训练日志全文

答案：ABC。YAML 元数据常见字段包括 license（开源协议）、pipeline_tag（任务类型）、tags（分类标签），它们用于平台分类、搜索和自动渲染推理入口。训练日志属于冗长正文，不应放入元数据，一般写进 README 正文或忽略。

Q10. 关于 Token 安全管理，以下哪些做法正确？

多选题 · hard

A.硬编码进训练脚本
B.使用环境变量存储← 正确答案
C.huggingface-cli 登录← 正确答案
D.写入 README 分享

答案：BC。Token 应通过环境变量 HF_TOKEN 或 huggingface-cli login 管理，前者适合代码运行，后者适合交互式终端。硬编码进脚本或写进 README 等于把钥匙贴在店门口，公开仓库一旦泄露，攻击者便能以你的身份篡改模型，是最基本也最常犯的安全错误。