数百の社内LLMを、人からもシステムからも探せるように - モデルカタログを2ヶ月で作った話

こんにちは。SB Intuitions MLプラットフォームチームの 鶴田 ・伊勢です。

MLプラットフォームチームでは、国産生成AI「Sarashina」の開発を加速するための MLOps/LLMOps 等、各種プラットフォームエンジニアリング活動を行っています。

今回は、その中の一つである、「モデルカタログ」の施策について紹介します。

社内では日々多くの LLM モデルが開発されており、そのメタデータは GitHub 上の YAML モデルカードとして数百モデル、丁寧に記録・蓄積されてきました。この蓄積をさらに活用しやすくするために、モデルカタログを立ち上げ、数百のモデルを条件で検索できるように、そして人だけでなくシステムからも参照できるようにしました。あわせて、5種類の学習 config からの自動ロードで登録の手間も削減しています。さらに、1つ数十〜数百GB にもなるモデル実体の配置も、カタログを起点に計算クラスタ側で非同期に行えるようにしています。本記事では、その設計判断と2ヶ月の軌跡を紹介します。

1. はじめに: 何を作ったか、2ヶ月でどうなったか

model-catalog は、社内で開発される LLM モデルのメタデータを一元管理するカタログです。モデル名やタグはもちろん、パラメータ数・コンテキスト長・精度（bf16 など）といったアーキテクチャ諸元、学習手法、ストレージ上の配置パス、推奨推論パラメータまでを構造化して保持し、Web UI と REST API の両方から検索・取得できます。

結果から言うと、提供開始時点で数百のモデルが Web UI から検索でき、同じ情報が REST API 経由でプログラムからも取得できる状態になりました。着手から約2ヶ月で提供開始しています。最初の2週間でモックを作ってユーザーの反応を見て、フィードバックを取り込みながら正式リリースまで走り切る、という進め方でした。

カタログがモデル開発のライフサイクルのどこに位置するかを先に示しておきます。

モデル開発 リサーチャー 事前学習 - 事後学習 ×N モデルができるたびに登録 CLI で登録 config 自動抽出 model-catalog モデルメタデータを集約 ・アーキテクチャ諸元 ・系譜（lineage） ・配置パス ・推論パラメータ Web UI / API API API 後段の学習をする人 ベースモデルを探す AIエージェント 系譜を辿って調査する 推論システム パス・推論パラメータを参照 model-catalog が学習パイプラインとサービングの間でモデル情報を集約する リサーチャーがモデルを作成し、CLI でカタログに登録する（事前学習・事後学習のたびに繰り返される）

• 後段の学習をする人が、カタログでベースモデルを探す。AIエージェントも API 経由で同じ検索ができる

• 推論システムを作る人が、サービング時に API でモデル情報（配置パス・推論パラメータなど）を参照する

つまりカタログは、学習パイプラインとサービングの間に立つ、モデル情報の共通の参照点として機能します。

なお、開発プロセスでは AI エージェントを全面的に活用しました。その話は本編と切り分けて、記事の最後に Appendix としてまとめています。

2. Before: YAML モデルカードの世界

もともと社内のモデルは、GitHub リポジトリ上の YAML モデルカードで管理されていました。数百のバージョンが記録されており、GitHub Pages による静的な閲覧ページもありました。まず言っておきたいのは、この仕組みは「モデルの情報を記録として残す」という目的を十分果たしていたということです。数百モデルの記録がきちんと蓄積されていたからこそ、後述するカタログへの移行も短期間で実現できました。ただ、モデル数が増えた結果、次の3つの課題が目立つようになっていました。

課題1: 見つからない

条件に合うモデルを探すには、リポジトリを clone して grep するしかありませんでした。「コンテキスト長が長い 7B クラスのモデル」のような横断的な条件検索は困難です。さらに、ストレージ上の配置パスが載っていないカードもあり、最終的には「作った人に聞く」で解決されていました。

課題2: 連携できない

プログラムからモデル情報を取得する API がなく、パイプラインに組み込めませんでした。モデルの情報は人間が読むためだけのもので、システムから参照する使い方ができない状態です。

課題3: 自動で登録できない

モデルカードは手書きの YAML です。パラメータ数やコンテキスト長といった情報は学習成果物の config.json にすでに書かれているのに、それを人間が転記する必要がありました。書く側の負荷が高いと、記載の粒度もばらつきます。

この3つの課題を、順に解いていきます。

3. 設計の出発点: 走りながら考える、スコープは絞る

最初に決めたのは、解く課題を絞ることでした。方針は「内部の完璧さよりユーザーフィードバック」。

とはいえ、カタログのフィールド設計を勢いだけで進めるとスコープが際限なく膨らみます。そこで、フィールドを入れるかどうかの判断基準として「供給×需要マトリクス」を使いました。

ここでの「供給」は、CLI が config.json やパス、学習ツールの設定ファイルから自動抽出できる項目のこと。「需要」は、モデルを探す人が選定のときに実際に見る項目のことです。需要側はヒアリングと登録シナリオの洗い出しから固めました。

大事なのは「供給も需要もないものは入れない」を徹底したことです。作れるからといって入れると、誰も使わない機能のメンテナンスコストだけが残ります。このマトリクスが「何を入れ、何を入れないか」の共通の判断基準になり、スコープ爆発を防いでくれました。

4. 検索可能なカタログ: スキーマ設計の判断

ここからは課題1「見つからない」の解決です。

検索需要のあるパラメータを選定して、それぞれ個別のフィールドに切り出しました。これにより「コンテキスト長 128K・bf16・GQA・7B クラス」のような条件を一発で絞り込めます。grep の世界では不可能だった横断検索です。

逆に、計算で導出できる値はフィールドとして持たない、という判断もしています。たとえば GQA（Grouped Query Attention)かどうかは、KV ヘッド数と Attention ヘッド数の大小関係から導出できるので、レスポンス時に算出します。保持するデータを最小限にすることで、値の不整合が起きる余地をなくしました。一方で、生の config_json はそのまま保持しています。詳細画面でのプレビューに使えるのと、将来「やっぱりこの項目も検索したい」となったときに再抽出できるからです。

もうひとつの大きな設計判断が、モデル間の系譜（lineage）をカタログ自身が持つことです。事前学習モデルから事後学習モデルへ、そこからさらに派生モデルへ、という親子関係を N:N の DAG（有向非巡回グラフ）として保持します。複数の親モデルを持つ派生にも対応しました。系譜を多段に辿れるので、「このモデルの祖先はどれか」「このベースモデルから派生したモデルはどれか」という両方向の問いに答えられます。これはガバナンスやライセンスの逆引き調査で特に効いてきます。

5. API で連携可能に

次は課題2「連携できない」の解決です。

Web UI と同じ情報を REST API として公開し、モデル情報の検索・取得・登録・編集をすべてプログラムから行えるようにしました。これでカタログは「人間が見るもの」から「システムが参照するもの」に変わります。推論パイプラインがモデルの配置パスを自動で引く、実験管理スクリプトがベースモデルの諸元を取得する、といった組み込みが可能になりました。

API 化にあわせて、メタデータの射程を広げる判断もしています。その代表が推論パラメータの管理です。モデルごとの推奨推論ハイパーパラメータ（temperature、max_tokens、top_p など）をカタログに保持するようにしました。これはリサーチャーの実験管理のためだけではなく、サービング側が推論時に「このモデルの推奨設定」を API で参照できるようにするためです。モデルメタデータの守備範囲を、学習パイプラインからサービングまで広げた設計判断でした。

6. AIエージェントからカタログを使う

課題2の延長線上で、もう一歩進めた話をします。

API で連携可能になったカタログは、人間の書いたプログラムだけでなく、AIエージェントからも叩けるはずです。「このベースモデルを起点まで辿り、学習データ比率はどうなっているか」といった問いに、エージェントがカタログを辿って自力で答えてくれる。そんな使い方ができるはずだと考えて、Agent Skill を試作しました。

構成はとても薄いものです。エージェント向けの API リファレンスとユースケースを記した SKILL.md を1枚書き、curl + jq で API を叩けるようにしただけ。あわせて数十行です。薄くしたのは意図的で、特定の言語やフレームワークに依存せず、中身が透過的で、エージェント自身が内容を読んで振る舞いを組み立てられるからです。

設計判断としてもうひとつ、Skill は Read 系の操作だけに限定しました。カタログへの書き込み、つまり「このモデルを登録する・この情報を書き換える」は人間が意思決定する領域です。Agent Skill の境界線は「参照」に引く、と最初に決めました。

SKILL.md にはユースケースを4本書いています。

• A. 自分のモデルからベースモデルを引き、その詳細を取得する

• B. タグで検索し、系譜を祖先方向に辿り、事前学習モデルの説明文から学習データ構成を読む

• C. モデル名からストレージ上の配置パスを解決する（デプロイ用）

• D. パラメータ数と学習手法でモデルを絞り込む

このうちユースケース B が、実際にAIによる検索が生きる例です。学習データの構成は、ファインチューニングされたモデル自身ではなく、その祖先である事前学習モデルの説明文に書かれています。つまり答えに辿り着くには「検索して、系譜を遡って、読む」という多段の操作が必要で、エージェントはこれを lineage エンドポイントを足場に自力で実行します。単発の検索 API を用意しただけでは生まれない振る舞いが、系譜をカタログ内に持つという4章の設計判断に支えられているわけです。

タグで検索 モデル一覧を取得 GET /models?tag=… モデルを特定 model_id を抽出 （一覧レスポンスから） 系譜を祖先へ辿る lineage を多段で GET /models/{id}/lineage?direction=ancestors 説明文を読む 事前学習モデル GET /models/{id} 学習データ構成 に到達 description から読む 単発の検索では届かない問いに、多段の API 操作で到達する

7. Config 自動ロード

最後は課題3「入力が手間」の解決です。

難しかったのは、学習 config がフレームワークごとに異なる形式を持つことでした。Hugging Face 形式の config.json、内製の事後学習ツールの設定ファイル、OSS の強化学習フレームワーク2種の YAML、事前学習ジョブのシェルスクリプトなど。リリース時点では5種のフォーマットが存在しました。

そこで CLI に inspect という機能を作り、ローカルのファイルを指定するだけで構造化メタデータを自動抽出できるようにしました。フォーマットの違いは CLI が吸収し、アーキテクチャ諸元・ベースモデル・学習データのパスなどを一貫した形で取り出します。

Hugging Face 形式の config.json 事前学習・事後学習の成果物 内製の事後学習ツールの設定 独自フォーマット OSS 強化学習フレームワークの YAML （2種） 事前学習ジョブのスクリプト シェルスクリプト inspect CLI が形式の違いを吸収 構造化メタデータ ・アーキテクチャ諸元 ・ベースモデル ・学習データパス フォーマットの違いは CLI が吸収する — 指定はパス1本で完了

効果を確かめるために、既存の全モデルカードを対象に全件調査をしたところ、記載項目の 98.7% が機械導出可能でした。登録時にユーザーがやることは「パスを指定して Enter」だけ。手書き YAML への転記作業は、ほぼまるごと消えたことになります。これまでモデルカードが丁寧に記録され続けてきたからこそ、既存モデルの初期データ移行もスムーズに行えました。

8. LLM 開発だからこその設計: モデル実体はカタログに入れない

最後にもうひとつ、LLM の開発現場ならではの設計判断を紹介します。モデルの実体、つまり重みファイルをどう扱うか、という問題です。

LLM の重みファイルは1つ数十〜数百GB にのぼり、学習ジョブの産物として計算クラスタの共有ストレージ上に最初から存在しています。転送先のオブジェクトストレージも同じクラスタ側にあるので、出発地も目的地もクラスタ上です。ここでカタログが実体を受け取る設計にすると、巨大なファイルをクラウドに一往復させる遠回りになり、転送時間とコストがかさみます。

そこでカタログは、モデル実体そのものは持たず、メタデータと「置き場所」だけを持つことにしました。登録時にはモデル名から配置先の URI をカタログ側で採番します。「どこに置くか」をカタログが決めることで、配置のバラつき自体を防ぐ狙いもあります。

実体の移動はクラスタ側で非同期に行います。CLI でモデルを登録すると、URI の採番と、その転送専用の短命なトークンの発行が行われ、CLI は計算クラスタへコピージョブを投入してすぐに制御を返します。重いコピー処理はジョブとしてクラスタ上で流れ、進捗はジョブからカタログ API に報告されます。登録者からは「登録コマンドを1回打つ」だけの操作の裏で、メタデータの登録とモデル実体の配置が同時に進む形です。

登録者の CLI モデルを登録する カタログ API（クラウド） メタデータを管理 計算クラスタ 実体が置かれている 1. モデル登録リクエスト（メタデータ） 2. 配置先 URI 採番 + 短命の転送トークン 3. 転送ジョブ