维修流程

保存时间：2026/3/29 21:27:39

HuggingFace 大模型下载
内容由豆包 AI 生成
关于这个 HuggingFace 这个网站，它 host 了很多的大模型。但是因为美国政府的禁令的关系，这个网站就 HuggingFace 它现在开始对中国的 IP 进行地质。所以如果不通过 VPN 的话是没办法下载。就它那些 git 命令的话，都是被 block 掉了。不论是 https 还是 ssh，或者是用 token 也行，用 access token 或者用 password 用它的工具，这些 Hugging Face CLI 也都是不行的。所以我喜找到另外一个途径，就是说在亚马逊 AWS 上的 EC2 一个 instance 里面去去下载，就用 git 下载 HuggingFace 上的大模型。但是问题就在于说， EC2 往往那个它分配的这个磁盘一般是比较小的。因为这个还是比较贵的，本地磁盘， EBS， 这个 elastic 这个什么磁盘是比较小的所以我又想着说利用它比较便宜的那种 S3 的云存储，那个是几乎无限量，而且很便宜。那怎么样直接应用呢？有一个方法是使用一个叫做 S3FS 就是类似于 F3 的 S3 的文件系统，可以把这个 S3 的 bucket 这个 object mount 到 EC2 的本地磁盘，好像是一个远程类似于 N FS 之类的，反正是一个协议， mount。 然后我就可以在这个 mount point 去使用 git 以及相应的 git lfs，就 large file system 这个命令来去下载 Hugging Face 上大模型。但是这个路径看上去挺美好，结果下载了多少个 G 之后，看起来这个命令就死在那里了。可能整个系统，这个 S3FS 这个文件读写可能没有那么强高的强度吧，导致它文件存储也许被 block 掉了，或怎么样哎，真的是麻烦呐。
听起来你在下载Hugging Face大模型的过程中遇到了不少阻碍呢。S3FS出现这种问题确实很让人头疼，有可能是它的读写性能在处理大量数据时不太够。或许可以检查一下S3FS的配置参数，看看有没有优化的空间，比如调整缓存大小之类的？或者有没有考虑过使用其他挂载S3存储的方式呢？你有没有试过其他的方法来解决磁盘空间的问题呀？
那你找一找 S3FS 的配置文件说明，以及其他的文档，看看有没有关于这方面的信息呢？
以下是S3FS配置文件相关信息及性能优化文档内容：

配置文件说明

S3FS支持标准的AWS凭证文件，存储在${home}/.aws/credentials。也支持自定义密码文件，格式如下：
  • 若只有一组凭证：access key id:secret access key。
  • 若有多个凭证：bucket name:access key id:secret access key。
    密码文件可存储在两个位置：/etc/passwd - s3fs（权限0640）和$home/.passwd - s3fs（权限0600）。S3FS还会识别AWS_ACCESS_KEY_ID和AWS_SECRET_ACCESS_KEY环境变量。

性能优化相关配置

  • 启用本地缓存：通过设置use_cache选项启用，如s3fs mybucket /mnt/s3 -o use_cache=/tmp/cache。
  • 调整缓存大小：根据系统内存情况调整，以提高性能。
  • 使用多线程：通过设置parallel_count选项启用，如s3fs mybucket /mnt/s3 -o parallel_count=10。
你可以根据实际情况调整这些配置参数，以优化S3FS的性能，解决下载过程中遇到的问题。
还有个小问题，就是说我在使用这个 S3FS 的时候，是用 sudo， 就是 root 用户来 mount 的。那么这个 credential 就是个密码文件，是在 root 用户的跟目录里面。我是平常使用的时候又是普通用户，它这里会不会出现这个 session time out 之后文件访问就没有，就要重新去使用这个 Log in 或什么之类的，会不会有这个问题啊？
当你使用sudo以root用户挂载S3FS且凭证文件在root用户根目录时，普通用户使用挂载点可能会遇到一些问题，但不一定是会话超时导致的文件访问问题。
如果没有正确配置权限，普通用户可能根本无法访问挂载点，因为挂载的文件系统默认权限可能只允许root用户访问。要让普通用户能够访问，需要适当调整挂载点的权限，比如使用chmod和chown命令来更改权限和所有者。
关于会话超时，S3FS本身有一些与缓存和连接相关的设置，但这通常与root用户还是普通用户关系不大。如果S3FS配置了合理的缓存且连接设置正确，一般不会因为普通用户长时间不操作而导致文件访问出现问题。但如果S3FS与S3服务之间的连接出现异常，或者缓存设置不合理，可能会导致文件访问失败，但这不是因为用户切换或会话超时的直接原因。
为了确保普通用户能够稳定访问挂载的S3FS文件系统，除了正确设置权限外，还可以考虑在普通用户环境中配置一些S3FS的相关环境变量，以确保其能够正确与挂载点进行交互。
因为那个挂载点我不是直接使用文件命令，而是使用 git lfs pull。 它是在 git 之上另外实现的一个 large file system 的一个下载插件吧，而且这个我估计是有这种断点续传，还有很多优化，大文件处理的这个 binary 文件处理的这个这个优化，所以它是否能够访问这个挂载点的话，这个错误可能就不一定那么容易暴露出来。有可能死机就死在这个里面。因为比如说你这个 S3FS 出现了 timeout，或者说挂载点不可访问的时候。但是那个 git lfs pull 它还是非常执拗的继续去 retry 或怎么样啊，或者说遇到了这种文件读写错误，他就不知道怎么去处理，或者怎么样。
确实有这种可能呢。git lfs pull 一直重试但 S3FS 那边有问题的话，就很容易导致进程看起来 “卡死”。也许可以查看一下 git lfs 和 S3FS 的日志文件，看看在 “死机” 的时候具体报了什么错误，是连接超时、权限问题还是其他的读写错误。另外，也可以试着调整一下 git lfs 的一些参数，比如设置重试次数和间隔时间，看能不能让它在遇到问题时更合理地处理，你之前有查看过这些日志信息吗？
我还有一个担心，就是 worst case 更糟糕的。就是说我在使用 git lfs pull 的时候，是在挂载点操作没有错。但是有没有一种情况，如果这个挂载点，比如说是 Slash mount Slash mount point。 这个 S3FS 挂载失败了，那么这个 git lfs pull 它会照样写在这个挂载点，那这个时候写的就不是在那个远端的云存存储，而是写在本地磁盘上了。而这个，写他写本地磁盘会非常的快，会很快的把我本地磁盘的磁盘空间用光，然后就导致整个操作系统就死掉了。我甚至于有可能都无法访问这个操作系统，这就麻烦了你明白吗？
这种情况是有可能发生的。如果 S3FS 挂载失败，而git lfs pull继续向挂载点写入数据，那么数据确实会被写入本地磁盘对应的挂载目录，可能会很快耗尽本地磁盘空间，进而影响整个系统的运行。
为了避免这种情况，可以考虑在执行git lfs pull之前，先添加一些检查机制，比如通过脚本检查 S3FS 的挂载状态。可以使用mount命令查看挂载信息，判断指定的挂载点是否正确挂载了 S3FS。如果挂载不正常，就暂停git lfs pull操作，并给出提示。另外，也可以对本地磁盘使用磁盘配额工具，限制特定用户或目录对磁盘空间的使用，这样即使出现误写，也能在一定程度上防止系统因磁盘空间耗尽而崩溃。
S3FS挂载状态检查脚本
磁盘配额工具