Hologram Model Hub

Model Hub

トレンドのオープンモデルのカタログです。すべてのファイルのコンテンツアドレスを掲載しています。 hologram-technologies.github.io/hologram-live/model-hub/ をご覧ください。

各モデルのページでは、アドレスごとにファイルを掲載し、Verify を利用できます。ブラウザーが Hugging Face と ModelScope から小さなファイルを取得し、アドレスインデックスと照合してハッシュを確認します。こちらのサーバーは一切関与しません。モデルを hologram-live ノードに取り込むには、Model Hub の .holo アプリケーションを使用します（issue #76、#75 の ADR 023）。

ツールで使用するには：HF_ENDPOINT

export HF_ENDPOINT=https://gethologram.ai
hf download sentence-transformers/all-MiniLM-L6-v2

Hugging Face からダウンロードするものはすべて、この変数を使用します（hf、huggingface_hub、transformers、diffusers、sentence-transformers、llama.cpp の -hf）。そのため、ハブ専用のクライアントは不要です。deploy/hub-resolve.mjs はアドレスインデックスから Hugging Face の形式で応答し、ファイルリクエストをすべて、直近のヘルスプローブに合格したソースへリダイレクトします。優先順位は Hugging Face（CDN が最速）、ModelScope、IPFS です。重みのバイトデータがハブを経由することはありません。main はインデックスに記録されたリビジョンなので、明日ビルドしても同じバイトデータを取得できます。パスの前に /via/ipfs、/via/modelscope、または /via/huggingface を指定すると、最初に選択するソースを固定できます（HF_ENDPOINT=https://gethologram.ai/via/ipfs）。すべてのモデルについて …/resolve/main/SHA256SUMS が生成されるため、sha256sum -c だけでダウンロードを検証できます。クライアント自体は何も検証しません。

この形式は推測ではなく、クライアントから記録したものです（web/qa/hf-dialect/recorder.mjs）。モデル情報、ツリー一覧、resolve への HEAD と GET、Xet 読み取りトークンのルートを記録しています。最後のルートは Hugging Face へのリダイレクトです。huggingface_hub 1.32 は HEAD でこちらのリダイレクトをたどり、そこで Hugging Face の Xet ヘッダーを受け取り、このエンドポイントにトークンを要求します。ユーザーの Hugging Face トークンは、HF_ENDPOINT が指定する宛先に届きます。フロントの Caddy はサービスがリクエストを受け取る前に Authorization と Cookie を削除し、ゲート付きモデルはプロキシせず拒否します。インデックスにないモデルには文を含む 404 を返し、state/resolve/requested.txt に記録します。

2026-09-18 に、公開 URL を対象として python:3.12-slim 内で web/qa/hf-dialect/matrix.sh を使い、huggingface_hub 1.32.0 と 0.36.2 で測定しました。hf download と snapshot_download によるモデル全体のダウンロード（30 ファイルすべてが SHA256SUMS と一致）、キャッシュの再利用、transformers の AutoConfig と AutoTokenizer、通常の GET と Range リクエスト、未知のモデルとリビジョンに対するクライアント独自の型付きエラーを確認しました。同日に測定したフェイルオーバーでは、クライアントコンテナー内で huggingface.co、hf.co、Hugging Face の CDN ホストをブラックホール化し、ハブ上で Hugging Face をダウン状態にしました。その状態で、hf download と snapshot_download によるモデル全体のダウンロードが完了し、30 ファイルすべてが一致しました。transformers による読み込みも含め、ModelScope と IPFS 経由で 110 秒でした。さらに ModelScope もダウンさせた場合、IPFS のみで同じ処理が 126 秒で完了しました（リダイレクトを 135 回記録）。最初の試行では .gitattributes で失敗しました。IPFS アーカイブがドットファイルなしでパックされていたためです（ipfs-car は隠しパスをスキップします）。現在は pin-model.sh でこれらもパックし、11 個すべてのモデルを再度ピン留めしました。単一ファイルではなく、リポジトリ全体をテストしてください。

Ollamaと、その両方を支える設計

ollama pull gethologram.ai/bartowski/MiniCPM5-2B-GGUF:Q4_K_M

同じサービスが、インデックス内のすべてのGGUFリポジトリに対してOllamaのレジストリ方言を提供します。マニフェストのモデルレイヤーには、インデックスに記載されたGGUFファイルのSHA-256を使用します。blobリクエストは有効なソースへの307リダイレクトとなり、Ollamaがダイジェストを検証します。チャットテンプレートとパラメーターはHugging Face独自のマニフェストから取得し、インデックスに記載されたものと完全に同じバイト列を指す場合に限って受け入れます。また、Hugging Faceが利用できない場合もプルが機能するよう保持します（実測：Ollama 0.34.2でモデルをプル、検証、実行。Hugging Faceへの接続を遮断した状態でも、同じプルがModelScopeから完了）。OCIクライアントには、同じルートから同じモデルをCNCF ModelPackアーティファクトとして提供します（oras pull gethologram.ai/hexgrad/kokoro-82m:latest。OCIの要件に合わせて小文字を使用。実測：72個のファイルすべてが一致）。また、エージェントにはhttps://gethologram.ai/mcpでMCP経由の3つのツールを提供します。 GET /api/models?search=…では、Hugging Faceの形式でモデルを一覧表示・検索できます（HfApi.list_modelsが動作）。これはエージェントにとっても手軽な方法です。こうした方言を採用した理由、調査で判明したこと、ルートの対応表、今後の予定については、docs/one-endpoint.mdをご覧ください。

ダウンロード

ダウンロードでは、現在のどのブラウザーでも、サイズを問わずモデル全体を1つの.zipとして保存できます。小さなサービスワーカー（web/src/zip-sw.js。zip/…だけに応答し、ページには応答しません）がストリーミング中にアーカイブを組み立てるため、ブラウザー内蔵のダウンロードマネージャーが実際の進捗バーを表示して保存し、メモリには何も保持されません。zipは非圧縮なので、最初のバイトが届く前に正確なサイズを宣言できます。通過する各ファイルをハッシュ化し、インデックスのアドレスと照合します。バイトが1つでも異なればダウンロードは失敗し、何も保存されません。各ファイルは、最初に応答したソース（Hugging Face、ModelScope、IPFS）から取得します。接続が切れた場合は、同じソースまたは次のソースから、中断したバイト位置から再開します。ボタンの横にあるメニューでは、zipのソースを1つに限定できます。すべてのzipにはSHA256SUMS（sha256sum -c SHA256SUMSで、いつでもオフライン検証できます）とHOLOGRAM.json（モデル、リビジョン、インデックスマニフェスト、各ファイルを配信したソース）が含まれます。リンクはzip/<org>/<name>/auto.zipで、ファイル一覧はdata/files/<org>/<name>.jsonから読み込みます。サービスワーカーを利用できない場合、ページはファイルピッカーのストリーム（Chrome、Edge）にフォールバックするか、最大1.5 GBのzipをメモリ内で作成します。

2026-09-18に実測（web/qa/zip-proof、ハブホスト上のDocker）：生成した5.9 GBのzipは、宣言したサイズと正確に一致して保存され、Chromium 131（140秒、ブラウザーメモリ377～471 MB）、WebKit 18.2（38秒、383～419 MB）、標準のFirefox 156（60 MB/sで169秒、コンテナー使用量1 GB未満）で有効でした。ファイルの途中で接続を切断しても再開され、検証も完了しました。誤ったアドレスを意図的に設定すると、3つすべてでダウンロードが失敗し、ディスクには何も残りませんでした。Playwright独自のFirefoxビルドではダウンロードの評価ができません。通常の6 GBのサーバーダウンロードでもメモリを使い果たすためです。node qa/zip-size.test.mjsでは、宣言したサイズと書き込まれたバイト数が一致することを検証します（空のファイル、UTF-8名、65,536件のエントリー、4 GiBを超えるファイル）。

アーカイブ

ヘッダーのピル Index <day> を開くと、Wayback Machineでページの過去を開くように、カタログが記録されたすべての日を表示できます。日付を選ぶと、ブラウズ、フィルター、検索、およびすべてのモデルページがその日のインデックスに切り替わります。ピルは琥珀色になり、バナーに日付が表示され、Back to latest で最新の状態に戻ります。どのページでも ?at=YYYY-MM-DD を指定すると、その日以前で最も近い記録日の状態が開きます。そのため、日付へのリンクは、その日に表示された内容そのものへのリンクになります。

毎日のレジストリへのプッシュ後、deploy/archive.sh によって各日のデータが一度だけ記録されます。その日のファイルはCAR（IPFSアーカイブ）にまとめられ、ルートCIDがローカルで計算されます。Filebaseを通じてピン留めし、Filebaseから報告されたCIDが一致した場合にのみ受け入れます。その日を台帳 archive.json（hologram.model-hub.archive/v1）に追加し、gethologram.ai/archive.json で配信して、それ自体もピン留めします。

フィールド	意味
gateway, mirror, registry	日付のデータの読み取り先です。IPFSでは <gateway><cid>/<path>、ハブのレジストリでは全日分について hologram pull <registry>:<date> を使用します。ハブ上の <mirror><date>/<path> は当日分のみです。ミラーは読み取りを高速化するだけのもので、決して信頼されません
days[].date, cid	日付と、そのディレクトリ（index.json、models.json、モデルごとのJSONファイル）のルートCID
days[].index	その日の index.json のBLAKE3ハッシュ。このファイルには、ほかのすべてのファイルのアドレスが記載されています
days[].prev, prev_ledger	前日のCIDと前の台帳のCIDです。ハッシュチェーンにより、履歴が知らないうちに書き換えられることはありません
days[].models, addressed, files, bytes, source, archived	その日に記録された内容と記録日時

ブラウザーはどのデータソースも信頼しません。index.json を読み込み、そのハッシュを台帳の index と照合してから、各ファイルをインデックスに記録されたアドレスと照合し、すべてを確認してから表示します。検証に失敗したバイト列は拒否され、次のデータソースが試されます（実測では、破損したミラーファイルが拒否され、ゲートウェイのコピーが使用されました）。検証済みのバイト列はコンテンツアドレスをキーとしてCache APIに保存されるため、再訪した日付はすぐに表示され、オフラインでも動作します。Verify とダウンロードは、ライブミラーを確認するため、最新のインデックスを引き続き使用します。at/<date>.json のスタブは、エージェントにその日のCID、インデックスアドレス、読み取り先を提供します。ハブのミラーには今日のデータのみが保存されます。レジストリには各日のタグがすべて保存されます（そのストアにはハブで公開されたオブジェクトも含まれるため、再構築されることはありません）。過去の日付はブラウザーでIPFSから読み込まれ、初回のアクセスではゲートウェイによる取得に1分ほどかかる場合があります（未キャッシュ時のファイルごとの実測値は25～55秒です）。不変なのは、記録とチェーンです。運用者が単一であるものは、毎日の書き込み処理（VPSのcron）と、単一のピン留めプロバイダーです。

ビルド

just model-hub-site   # catalog snapshot (if missing), token lint, static build → apps/model-hub/web/dist
just model-hub-data   # refresh the catalog snapshot

BASE=/path/ を指定すると、パス配下で配信するサイト向けにビルドできます。GitHub Pagesでは .github/workflows/release-docs.yml によってドキュメントと並べて公開されます。公開のタイミングは、apps/model-hub へのプッシュ時、新しいスナップショットを使った毎日の実行時、および手動実行時です。ドキュメント自体は常に最新の docs-v* タグからビルドされます。

カタログは、Hugging Faceのトレンド一覧と、humuhumu33.github.io/hologram-api にあるモデルアドレスインデックスを結合して作成されます（HOLOGRAM_API で上書きでき、HF_TOKEN を設定するとレート制限を回避できます）。

ブランドキット

すべての色、サイズ、余白、角丸、フォントは Hologram-Technologies/hologram-brand-kit に由来し、web/scripts/vendor-kit.mjs によって develop の bce3bdf59（Desktopが使用するリビジョン）からベンダー取り込みされています。3つの余白トークン（--success、--success-foreground、--muted-foreground-subtle）は、キットのオープンなPR #1に由来します。web/scripts/lint-tokens.mjs は、プロダクトコード内にリテラルの色、サイズ、角丸、フォント、またはインラインスタイルがあると失敗します。

ヘッダー

サイトのすべてのページに表示されるトップレベルメニューは「Models」「Registry」「Docs」の1つだけです。現在のセクションには aria-current が設定され、アクセントカラーで表示されます。メニューは web/build.mjs の topNav() で一度だけ作成され、生成されるすべてのページで使用される header() によって描画されます。Registry ページは web/public/registry/ に完成済みの独立したファイルとして置かれているため、ビルドでは別のコピーを作成せず、そのファイル内の2つのマーカー（, ）に同じ header() の出力を挿入します。ページで共有される要素、つまりブランドのエイリアス、リセット、シェル、コントロール、ヘッダー、テーマ切り替え、サインインは web/src/chrome.css と web/src/chrome.js にあります。これらを使う各ページのスタイルは web/src/styles.css にあります。

npm run menu は、2つのテーマと12種類の幅で、あらゆるページ構成を検査します。メニューが異なる場合、セクションのマークが間違っている場合、またはマークのコントラスト比が AA を下回る場合は失敗します。

レイアウト

パス	内容
web/build.mjs	静的ジェネレーター。ランディングページ、ブラウズページ、モデルごとのページ、Registry アーティファクトごとのページ、共有ヘッダーを生成します
web/src/	レンダリング、クライアントコード、スタイル、生成されたブランドトークン。chrome.css と chrome.js は共有ヘッダーです
web/scripts/	data.mjs（カタログのスナップショット）、registry.mjs（ソース API から取得した Registry の各行のプロフィールとロゴ）、vendor-kit.mjs、lint-tokens.mjs
web/vendor/hologram-brand-kit/	ベンダー提供のキットの CSS、トークン、フォント、ロゴ
web/public/wallpapers/	没入感のあるテーマの壁紙
web/qa/	デザインレビューで使用するレイアウト、コントラスト、アニメーションの監査。menu.mjs がトップレベルメニューを検証します