背景

• 最近项目上涉及到频繁的大模型本地化部署，其中大模型文件的传输还挺让人头疼的，一个模型动辄几十GB的数据量，传输起来比较慢
• 那么有没有一种方式，可以加速大文件（模型文件）传输呢？
  • 第一反应是BT下载、P2P技术
  • 那么有没有类似的、现成的可以应用在文件传输上的协议或者系统呢？答案是，IPFS可以做到

IPFS是什么

• IPFS全称InterPlanetary File System，旨在实现文件的分布式存储、共享和持久化的网络传输协议。它是一种基于内容哈希的去中心化协议，IPFS是P2P系统。

其实早在2018年，公司的一个同事就在宣传IPFS，当时这个项目才启动没多久，也没太关注。

IPFS如何加速大文件下载

• 传统集中式网络结构，用户（客户端）下载文件，往往是从某一台服务器上下载， 当用户下载量变大，服务器的上行带宽（提供文件下载的带宽）就成为了瓶颈，与此同时商用网络带宽又非常的昂贵，很难一味地通过购买带宽来保持用户稳定、快速的文件下载体验
• IPFS使用分布式的P2P网络，基于内容（哈希）寻址，将文件分割为小的块，从多个节点同时下载，利用多个节点的上行带宽，理论上节点如果够多，下载文件的时候可以把客户端的下行带宽跑满，不得不说真香。从某种程度上来说，IPFS是用空间换时间，通过冗余数据（分布在多个节点），让数据传输加速。

总结

• IPFS用来传输大文件，毫不夸张地说，是杀鸡用牛刀，它的目标可谓是星辰大海，是下一代互联网的基石。
• IPFS对于【热数据】友好，也就是大家经常会用到的数据，它的备份就会很多，下载和传播也会很快，相反那些很少用到的【冷数据】，很有可能因为10年都没人用，硬盘直接坏掉了，导致数据永远地丢失。
• IPFS还需要完善【数据持久性】和【安全性】保障机制。
  • 如果单节点的数据没有其他节点拉取，还是会造成【数据孤岛】，也就是说IPFS不会自动对数据做冗余和备份，而是靠其他节点的拉取和参与来保证数据备份和繁荣
• IPFS的并发性能还有待优化
  • 通过内容寻址，往往需要几跳来获取全网的分布式哈希表，加上并发性能不够理想，所以实操的下载速度不一定有理论上那么高。
• 到真正的实用，好用，IPFS还需要一些发展和迭代，保持关注，持续折腾。

思考

• IPFS相当于一个巨大的【分布式wiki】，所有的数据都可以用哈希值去获取到，没有权限控制，实现数据平等。
• 其实IPFS基于内容的寻址，某种程度有点像elasticsearch的倒排索引，一个个的IPFS节点相当于es中待索引的文档，节点中存储的哈希内容块，就像是es中待索引文档分词之后的token，我们es根据token反向去寻找所包含该token的文档集合，就像IPFS根据哈希值，反向寻找存储该哈希值内容块所在的节点地址一样。