README.md のことで、何かをダウンロードする前に確認すべき場所です。多くのカードは長文ですが、このページではローカルでモデルを実行する際にどのフィールドが重要で、どの部分を軽く読み流せばよいかを説明します。
Hugging Face がカードに含めるべき内容についての公式ガイダンスは、Hub モデルカードのドキュメントに記載されています。実際には、モデルがハードウェアに適合するかどうかを判断する際に、いくつかのフィールドが大部分の役割を果たします。
パラメータ数
通常、モデル名自体（7B、30B など）に含まれているか、カードの上部付近に記載されています。これはメモリ要件を決定する最大の要因です — パラメータ数が VRAM 数値にどのように変換されるかは、メモリとオフロードを参照してください。
アーキテクチャ：デンス vs. エキスパートの混合（MoE）
カードがモデルを デンス（dense） か エキスパートの混合（mixture-of-experts, MoE） として記述しているかを確認します。デンスモデルは、すべてのトークンに対してすべてのパラメータを実行します。一方、MoE モデル（30B-A3B のような名前付けで、合計 30B のパラメータのうち 3B がアクティブであることを意味します）は、トークンごとに「エキスパート」パラメータのサブセットのみを実行するため、同じ合計サイズのデンスモデルよりもデコードが高速です。ただし、どのトークンも異なるエキスパートにルーティングされる可能性があるため、アクティブなパラメータだけでなく、すべてのパラメータを保持するのに十分なメモリが必要です。
カードの両方の数値を確認してください：合計パラメータ数（保存に必要なもの）とアクティブパラメータ数（トークンあたりの速度を決定するもの）。
コンテキスト長
モデルが単一の会話で保持できるトークンの最大数で、通常は「128K コンテキスト」のような表記や、設定内のmax_position_embeddings としてリストされています。これは二重に重要です：一度にモデルに送信できる量を制限し、KV キャッシュメモリの上限を直接設定します。より長いコンテキストがなぜより多くの VRAM を必要とするかは、KV キャッシュとコンテキストを参照してください。
モデルの最大宣伝コンテキストと、その信頼できるコンテキストは必ずしも同じではありません。一部のモデルは、記載された制限に達するずっと前に、記憶力が低下します。長いコンテキストがユースケースにとって重要であれば、見出しの数値を信頼するのではなく、検証してください。
ライセンス
モデルの上に何かを構築する前にライセンスフィールドを確認してください — それは、出力を商用利用できるか、ファインチューニングを再配布できるか、あるいは製品で実行できるかを決定します。ライセンスはファミリー間で大きく異なります：完全に寛容なもの（Apache 2.0、MIT）から、使用制限を伴うものや帰属を要求するものまであります。これは、Hugging Face がそのモデルカードのドキュメントに従ってカード上に直接表示するメタデータです。ファイルとリポジトリ：safetensors vs. GGUF
単一のモデルは、複数のリポジトリやファイル形式にわたって公開されることがよくあります：safetensorsファイルは、元の（または変換された）重みで、通常は完全精度（FP16/BF16）で提供され、または他の量子化形式を伴います。これらは vLLM などのバックエンドが通常ロードする形式です。GGUFファイルは、llama.cppベースのバックエンド（Ollama や LM Studio を含む）がロードする形式です。GGUF リポジトリは通常、同じモデルのいくつかの量子化バリエーションを別々のファイルとして提供します。
…Q4_K_M.gguf のようなファイル名は、一目で三つのことを教えてくれます：それは Q4（4 ビット）量子化であり、K-quant ファミリーに属し、そのファミリー内の M（中程度）のサイズ/品質ポイントです。命名スキームの残りの部分の読み方とバリエーションの選び方については、量子化を参照してください。
チャットテンプレート
ほとんどのインストラクションチューニング済みモデルは、プロンプトが特定のチャットテンプレート（システム/ユーザー/アシスタントのターンを示す特殊トークン）でラップされることを期待しています。モデルを提供するバックエンド — Ollama、llama.cpp、vLLM — は、モデルにバンドルされたメタデータから正しいテンプレートを自動的に適用しますが、生プロンプトを自分で構築している場合は、カードで期待される形式を確認してください。間違ったテンプレートを使用すると、エラーを発生させることなく、出力品質が静かに低下します。意図された用途
カードは通常、モデルが何のためにチューニングされたか — 一般的なチャット、コーディング、思考、指示の追従 — を明記し、時にそれが弱いと知られているものも記載します。タスクに適合しないモデルにハードウェアをコミットする前に、軽く読み流す価値があります — モデルをタスクにより体系的にマッチさせる方法については、どのタスクにどのローカルモデル？を参照してください。Tokios を通じて提供した際に重要なこと
ローカルモデルを Tokios デプロイメントとして登録する際、モデルカードの二つのフィールドがセットアップの決定に直接変換されます：- アップストリームモデル ID vs. デプロイメント名。 バックエンドが提供する ID（例えば、Ollama のタグや llama.cpp サーバーが起動されたパス）は、Tokios で付与する公開デプロイメント名とは異なります — カードは前者を伝え、後者はあなたが選択します。
- コンテキスト長とライセンス は、どのクライアントが呼び出すかに関係なく、デプロイメントの使用に関する制約として引き継がれます。
さらに深く学ぶ
モデル名の読み方
カードを開く前に、パラメータ数、量子化ラベル、アーキテクチャサフィックスをデコードします。
量子化
GGUF 量子化名前を読み、適切なサイズ/品質のトレードオフを選びます。
量子化とハードウェア
どの重み形式がどのハードウェアで実行されるか。
一つを選び、実行した後
カードを読むことで、モデルが何ができるかがわかります。ダウンロードしてlocalhost でリクエストに応答し始めたら、次のステップはそれを到達可能にすることです。
安定したエンドポイントを付与する
Tokios はモデルを選んだり、ホストしたり、ファインチューニングしたりしません — ローカルで実行されると、Tokios はそれをどこからでも呼び出せる安定した認証済みエンドポイントに変換します。