Pirate Faceは、消えたモデルをどこまで救えるのか？

ollama pull で落としたモデル、元のHugging Faceのrepoが明日消えたら、同じものをもう一度用意できますか。手元に重みが残ってるから平気、と思った人ほど危ないです。オープンモデルを丸ごとtorrent化して配るPirate Faceを軸に、再現性がどこで切れるのかを整理します。

「ローカルに重みがある」は再現性を保証するのか

保証しません。手元にファイルがあることと、それが何なのかを証明できることは別の話だからです。

チームの誰かが半年前に落としたGGUFがNASに転がっているとします。ファイル名は残っている。でもそれが、どのrepoの、どのリビジョンの、どの量子化なのか。誰かが途中で差し替えていないか。元のハッシュを控えていなければ、どれも答えられません。証明の手段を持たないまま「ローカルにあるから大丈夫」と言っているなら、それは再現性ではなく、ただの在庫です。

モデルが消える引き金は、だいたい作者側にあります

Hugging Faceからモデルが消えるパターンは、そんなに種類がありません。

• 作者が自分で取り下げる。新バージョンを出したタイミングで旧版を整理する、というのが一番多い
• ライセンスを変更する。同じ名前のまま配布条件が変わり、旧条件のファイルだけが消える
• 権利関係や学習データの指摘を受けて非公開になる
• 個人アカウントから組織アカウントへ移管され、repoのパスが変わる

厄介なのは、どれも予告が出ないことです。ある日CIが落ちて、ログを見たら404が返っているだけ。移管なら新しいパスを探せば済みますが、取り下げだと探す先がありません。ここを埋めにきたのがPirate Faceです。

Pirate Faceの二段構え、生きている間はHugging Faceから落ちます

掲げているのは「Turn AI into torrents that live forever」、オープンモデルをtorrentに変えて永続化する、という一点です。

Pirate Face - The permanence layer for sovereign AI

Open models as checksum-verified magnet links. Un-bannable, carried by the swarm.

pirateface.co

仕組みを見て僕が一番うまいなと思ったのがここなんですが、配っているのは普通のtorrentではなく、web-seed付きのtorrentです。BEP-19 で定義されたHTTP/FTPシーディングの仕様で、torrentのメタ情報に url-list としてHTTPのダウンロード元を埋め込めます。クライアントは、ピアからでもそのHTTPサーバーからでも同じピースを取ってこられる。

これが効きます。モデルがHugging Faceにある間は、web-seedがHugging Faceを指しているのでピアがゼロでもそのまま落ちてくる。普通のtorrentにありがちな「シーダーがいなくて永久に0%」が起きません。そしてHugging Faceから消えた日に、web-seedが死んでP2Pのswarmへフォールバックします。サイト側はそれを「Rescued」と表示して、誰かがシードしている限り到達可能な状態として扱います。

検証も手当てされています。全ファイルにHugging Face公式のSHA-256ハッシュが付いていて、落としたバイト列が元と一致するかをその場で確認できる。torrent配布でここが崩れたら全部終わるので当然ではありますが、ちゃんと押さえてきたなという感じです。

救われるのはMITとApache-2.0だけです

ここが一番効いてくる制約です。

同期対象は「MIT and Apache-2.0 only」と明記されていて、例外は承認済みのKimi-K3だけ。対象の母数としてサイトは669,000件超を掲げていますが、逆に言えば、この2つのライセンス以外は最初から救済の対象外です。

じゃあ何が漏れるか。Llamaの重みはLlama Community Licenseで配られていて、MITでもApache-2.0でもありません。GemmaにはGemma Terms of Useがあります。どちらも「オープンウェイト」と呼ばれますが、OSIが認めた意味でのオープンソースライセンスではなく、配布元が条件と裁量を持ったままの契約に近い形です。

気づきましたか。作者や権利者の判断で引っ込む余地が大きいのは、まさにこの独自ライセンス側です。MITやApache-2.0の重みは誰が再配布しても文句を言われにくいから、そもそも消えにくい。一番救済が欲しい領域が構造的に対象外、という逆転がここにあります。Pirate Faceは「消えそうなモデルを守る仕組み」ではなく「再配布が明確に許された範囲を、切れない経路で配り直す仕組み」だと見ておくのが正確です。

ollama pullしたモデルは、この網に入っていません

そしてもう1個、どこにも注意書きのない罠があります。

ollamaのモデル置き場を覗いてみてください。~/.ollama/models/blobs/ の下に sha256- で始まるファイルが並んでいて、~/.ollama/models/manifests/{host}/{namespace}/{model}/{tag} にそれを束ねるマニフェストがある。Dockerのレイヤとほぼ同じ、content-addressableな構造です。

問題は、このダイジェストがollama自身のレイヤに対するハッシュだということ。デフォルトの ollama pull は registry.ollama.ai から引いていて、Hugging Faceのrepoとは別の配信経路です。だから手元のblobのSHA-256と、Pirate Faceが持つHugging Face公式のSHA-256は、中身が実質同じ量子化であっても一致しません。同じ名前のモデルがPirate Face側にあっても「うちが使っていたのはこれです」と言い切れない。

抜け道はあって、ollamaはHugging Face上のGGUFを直接引けます。

ollama run hf.co/bartowski/Llama-3.2-1B-Instruct-GGUF

末尾に :{quantization} を付ければ量子化も指定できます。この形で引いておくと、出どころがHugging Faceのrepoとして特定できる状態になる。社内で使うモデルだけでもこちらに寄せると追跡可能性がまるごと変わるので、今日から変えられるところとしてはここが一番大きいです。

今日やるピン留めは、重みとtokenizerとconfigの3点です

Pirate Faceを待たなくてもピン留めはできます。Hugging Face側がLFSファイルのSHA-256をAPIで返してくれるので、そこから拾います。

curl -s "https://huggingface.co/api/models/{owner}/{repo}?blobs=true" \
  | jq '.sha, (.siblings[] | select(.lfs) | {path, sha256: .lfs.sha256})'

.sha がそのrepoのコミットのハッシュ、siblings[].lfs.sha256 が各ファイルの実体のハッシュです。gitのblob oidを拾わないよう注意してください。あれはLFSポインタファイルのハッシュで、重みそのものとは無関係です。

控えるのは重みだけでは足りません。

重みのハッシュだけ控えて安心している構成をたまに見ますが、生成結果が合わない事故はトークナイザと generation_config.json 側で起きます。ここまで含めて初めて「同じモデルを使っている」と言えます。

運用は、リポジトリに models.lock のようなJSONを1枚置いて、repo名・コミットのハッシュ・ファイルごとのSHA-256を書いてコミットする。ダウンロード時は revision= でそのコミットを明示して引く。実体は自社のオブジェクトストレージに控える。30分あれば1モデル分は終わります。

HF_ENDPOINTを差し替えるだけの日は、まだ来ていません

Pirate Faceが計画として出しているのが、既存パイプラインの向き先を変えるだけで使えるドロップインAPIです。サイトには HF_ENDPOINT=https://pirateface.co を設定すればモデル解決がPirate Face経由になる、と書かれています。

ただしこれは「soon」表記で、まだ提供されていません。シードへの報酬も「planned, not active」で、根拠になるシード実績を計測できてから、という段階です。ハンドルの確保はツイート1本で済みますが、いまできるのは名前の予約と貢献のトラッキングくらいです。

Hacker Newsのスレッドは本記事執筆時点で397ポイント、コメント125件と反応は大きい一方、批判もそれなりに出ています。torrentの作成に手作業が残っていてHugging Faceとの自動連携ができていない、救済というより無検閲モデルの配布先として機能しているのではないか、といった指摘です。登録の導線がXやHacker Newsへの投稿を促す形になっている点にも苦言が付いていました。

つまりPirate Faceは、MITとApache-2.0の重みが消えたときの最後の受け皿として視界に入れておく価値はあるけれど、自社の再現性をここに預けるフェーズにはまだない。

やることは変わりません。使っているモデルのrepoとコミットを固定して、重みとトークナイザと設定のSHA-256を控えて、実体を自分の管理下に置く。ollama経由なら hf.co/ の形に寄せておく。

本当にモデルが1本消えた日に慌てるかどうかは、ここで決まります。