云基础设施
GPU跳转撞上南墙，一次整合直接拆掉了它
通过将Hugging Face存储作为SkyPilot的一等后端进行挂载（读取时零出站费用），团队现在可以在任何有闲置GPU的云上运行训练和推理，而无需复制数据或按GB支付传输费用。该整合结合了通过hf-mount实现的惰性挂载与Xet驱动的去重技术，以保持数据传输的高效性。
任何曾试图在与数据所在不同的云提供商上训练AI模型的人都知道这个流程：要么将数据集复制到每个供应商的存储桶中，要么每次跨边界拉取数据时支付出站费用（在AWS上约为每GB 0.09美元）。当基础模型达到数十GB、数据集达到TB级别时，成本会迅速累积。AI领域下一个万亿级瓶颈不是算法，而是电力和散热
Hugging Face与SkyPilot之间的新整合直接针对这一痛点。Hugging Face存储（此前作为独立服务）现在成为SkyPilot（开源多云任务调度器）的一等后端。结果是：任何Hugging Face仓库、模型、数据集或存储桶，都可以通过一个单一的hf:// URL挂载到SkyPilot任务中，并且无论GPU运行在哪个云上，读取该挂载点都无需支付出站费用。
整合如何运作
机制很简单。一个SkyPilot任务声明一个包含hf://Qwen/Qwen3.5-4B等源地址的file_mounts块，存储类型为hf。SkyPilot使用Hugging Face的hf-mount FUSE后端将该仓库呈现为容器内的本地文件系统路径。该挂载点对于模型和数据集可以是只读的，对于用作检查点存储的Hugging Face存储桶可以是可读写的。阿里Qwen正在为每一项AI任务构建专属模型，而非一统天下
认证使用大多数团队已配置的HF_TOKEN环境变量。无论任务落在AWS、GCP、Azure、Nebius、Lambda还是Kubernetes集群上，该令牌都有效。无需管理每个云存储桶的密钥。
惰性读取让GPU保持忙碌
一个关键的性能细节：FUSE挂载采用惰性获取。当进程对文件调用read()时，hf-mount仅拉取实际请求的字节，而不是整个文件。训练作业几乎可以立即开始处理数据，第一批数据流式传入的同时，后续数据块仍在获取中。在使用Qwen 3.5-4B模型进行微调的基准测试中，模型在约30秒内即可准备就绪进行训练，峰值吞吐量高达500 MB/s。
惰性方法在第一个epoch时效果最显著，此时本地磁盘缓存为空。对于随后的epoch，hf-mount会保留本地缓存，因此重复读取保持本地化。无论用户指定MOUNT还是MOUNT_CACHED，此缓存行为都相同，这是有别于某些云对象存储后端的有意设计选择。
消除数据引力问题
更深层的影响是组织层面的。如今，GPU容量很少来自单一提供商。团队在超大规模云上预留资源块，在Lambda Labs或Nebius等新型云上预留集群，有时也使用本地机架。SkyPilot正是为在这些异构资源池中进行调度而构建的。但对象存储一直是束缚：数据存在于一个提供商的区域存储桶中，在其他地方运行作业意味着要么移动副本，要么支付出站费用。AI代理在生产环境中隐藏的微妙陷阱
Hugging Face存储的定价为每月每TB 12至18美元，而AWS S3约23美元/TB加上出站费用，这改变了经济性。该存储桶在实践中（而不仅仅是理论上）变得与云无关。团队可以让SkyPilot选择最便宜或最可用的GPU集群，而无需将数据位置纳入考虑。
Xet驱动的去重：一个隐藏的性能杠杆
该存储后端使用Xet，它将文件分割成约64KB的内容定义块，每个唯一块只存储一次。这对于检查点密集型工作负载有切实的好处。来自适配器训练或冻结层微调的增量检查点仅上传发生更改的块。在Hugging Face的测试中，向一个100K行的Parquet表中追加10K行，仅传输约10MB，而不是完整的约106MB。
相同blob的重新上传几乎是即时的。一个已在存储桶中的8.43GB检查点仅需约8秒进行验证，而首次上传需要24秒，因为只需发送块哈希值。仓库与存储桶之间的服务器端复制也通过引用而非字节复制进行。Bing速度背后的12000行秘密：mimalloc如何打破内存分配器的权衡困境
这对多云栈意味着什么
该整合是联合开发的，完全开源。Nikhil Jha贡献了最初的store: hf支持；Hugging Face团队上游合入了非特权容器（Kubernetes上的常见约束）所需的hf-mount FUSE修复；SkyPilot团队将其接入存储后端。NVIDIA NeMo AutoModel 借助专家并行和 DeepEP 将 MoE 微调速度提升 3.7 倍
对于已经同时使用Hugging Face Hub和SkyPilot的团队，改动极小。对于仅使用其中之一的团队，此整合降低了采用另一方的门槛。最大的采用限制是挂载要求：hf-mount需要一个具有glibc 2.34+和/dev/fuse的基础镜像。大多数现代Linux容器都支持这一点，但某些最小化镜像可能不支持。
GPU需求持续超过任何单一提供商的供应能力。将计算视为可替代资源（而存储不再将其拖回单一供应商）的能力可能至关重要。此整合并不能解决所有的多云难题，但它消除了最顽固的痛点之一。