開発者のためのオープンウェイトモデル入門

オープンウェイトモデル（open-weight model）とは、学習済みの重み、つまりファイルとして保存された学習済みパラメータが、通常はそれらを実行するために必要な推論コードとともに公開されている一方で、学習データやそれを生み出した学習パイプラインは公開されていないモデルのことです。

ホスティングされた API を呼び出しながら、パッケージをインストールするようにモデルをダウンロードして実行できるのではないかと考えたことがあるなら、答えは二つに分かれます。ダウンロードは可能です。しかし、それは実行できることを意味しません。本ガイドでは、オープンウェイトのリリースに何が含まれるのか、なぜラベルよりライセンスが重要なのか、モデルを土台にする前に何を確認すべきか、フロンティアモデルをサービングするとは実際どういうことか、そして GPU を持たないアプリケーション開発者が現実的に取り得る 3 つの選択肢について解説します。

オープンウェイトモデルで実際に手に入るものは何か

オープンウェイトのリリースには、重み、通常は推論コード、そしてアーキテクチャを記述した config が含まれますが、モデルがどのように学習されたかについての情報はほとんど含まれません。重みこそがモデルそのものです。数十億もの数値が、16 ビット浮動小数点数や 4 ビット量子化型といった数値形式で保存され、アーキテクチャが期待するテンソルの形に配置されています。推論コードはそれらのテンソルを読み込み、フォワードパスを実行します。その上流にあるもの、すなわち学習コーパス、データフィルタリング、学習スクリプトはすべて公開元の手元に残ります。

この欠落こそが、オープンウェイトをオープンソースから分かつものです。Open Source Initiative が公開した Open Source AI Definition は、重みファイル以上のものを求めています。パラメータ、システムを学習・実行するコード、そして有能なエンジニアが同等のものを再構築できる程度に十分な学習データの説明です。生のデータセットそのものはこのリストには含まれていません。重みと推論コードだけを提供するリリースは、ライセンスがどれほど寛容であってもこの基準を満たしません。

ラベルは何も語らず、ライセンamsがすべてを語る理由

「オープンウェイト」というラベルは何が公開されたかを表すものであり、あなたに何が許可されているかを表すものではありません。条件を定めるのは重みに付随するライセンスであり、その内容は制限のない商用利用から研究目的限定まで幅があり、公開元が自ら書いた独自ライセンスも一般的です。同じハブからダウンロードできる 2 つのモデルが、まったく異なる義務を課していることもあります。

Kimi K3 は具体的な例です。Moonshot は標準的なライセンスではなく、自社で作成したライセンスの下で重みと付随コードを提供しています。Kimi K3 のライセンスファイルは商用利用、改変、再配布を認めていますが、model-as-a-service 事業者に対する収益しきい値と、月間収益または月間アクティブユーザー数がしきい値を超えるデプロイメントに対する帰属表示（アトリビューション）要件を課しています。こうした内容は「オープン」という言葉からは一切見えてきません。ファイルを読んで初めて分かることです。

オープンウェイトのライセンスで確認すべきことは何か

オープンウェイトモデルを土台に開発を始める前に、ライセンスで次の 4 点を確認してください。商用利用が許可されているか、重みを再配布してよいか、ファインチューニングと派生物の公開が可能か、そして利用規定（acceptable-use policy）が何を禁止しているかです。

1. 商用利用。 無条件に認めるライセンスもあれば、収益やユーザー数のしきい値を超えると制限がかかるもの、そもそも禁止しているものもあります。規模に応じて発生する義務がないか確認してください。
2. 再配布。 自社製品やコンテナイメージの中に重みを同梱できるのか、それとも公開元のダウンロード先をユーザーに案内することしかできないのか。
3. ファインチューニングと派生物。 重みを改変してよいことを確認し、派生物にどのライセンスを付す必要があるか、命名に関するルールがあるかを確認してください。
4. 利用制限。 多くのライセンスには、特定の用途を禁止する利用規定の付属文書が付いています。デモではなく、実際の自社製品に照らして読んでください。

リポジトリ内のライセンスファイルを唯一の正典として扱ってください。ハブのメタデータタグやサードパーティによる要約は古くなっていきます。

ダウンロードが無料でも、実行が無料とは限らない

モデルの重みをダウンロードできることと、それをサービングできることは別問題です。パラメータ数が兆単位のモデルでは、後者の答えはノート PC ではなくデータセンターです。

Kimi K3 のモデルサマリーには、mixture-of-experts アーキテクチャで総パラメータ数 2.8 兆、トークンあたりの活性化パラメータ数 1,040 億、896 個のエキスパートのうちトークンごとに 16 個を選択、コンテキスト長 1,048,576 トークンと記載されています。同じ表には数値形式も示されており、MXFP4 の重みと MXFP8 の活性化が、完成後のモデルに適用されるのではなく学習時に固定されています。4 ビットであっても、2.8 兆パラメータは兆単位のストレージを意味します。リポジトリの Files タブを見ると、重みは 96 個の safetensors シャードに分割され、合計約 1.56 TB、テンソル型は F32、BF16、U8 と記載されています。リクエストを高速に処理するには、そのバイトのすべてがアクセラレータメモリ上に常駐していなければならず、「活性化するのは 1,040 億だけ」という事実はこのフットプリントを減らしません。どのエキスパートが発火するかはトークンごとに変わるからです。

このモデルをどう動かすことが想定されているかは、カード自体が教えてくれます。デプロイメントのセクションでは、使用すべきエンジンとして vLLM、SGLang、TokenSpeed を挙げ、ホスティング API を案内しています。このモデル専用の TokenSpeed レシピも存在します。カードにはローカルインストールについての記述は一切ありません。Moonshot は 2026 年 7 月 16 日に Kimi K3 を発表し、その発表で予告した日付どおり、2026 年 7 月 27 日に Hugging Face 上で重みを公開しました。

オープンウェイトモデルを実際にどう動かすか

アプリケーション開発者がオープンウェイトモデルに到達する経路は 3 つあります。公開元のホスティング API、公開された重みを動かすサードパーティのサービングプロバイダ、そして Ollama や LM Studio といったツールでローカルに動かす、より小さな量子化済みコミュニティビルドです。生のフロンティア重みをダウンロードするという選択肢は、上述の理由でリストに入りません。

3 行目については 2 点注意があります。Kimi K3 のコミュニティ量子化版は実際に存在し、Hugging Face には数十もの量子化派生モデルが掲載されていますが、その大半は依然として 2.8 兆パラメータ、あるいは数千億パラメータ規模の枝刈りビルドであり、ノート PC 規模のダウンロードではありません。ローカル経路が機能するのは、それに見合ったサイズのモデルの場合であり、Ollama や Jan.ai のガイドが扱っているのはそちらです。

朗報は、経路の切り替えがほとんど base_url の変更だけで済むことです。Moonshot の Kimi K3 クイックスタートは OpenAI 互換のエンドポイントを公開しており、Ollama のローカルサーバーも同様です。

from openai import OpenAI

# Publisher API
client = OpenAI(base_url="https://api.moonshot.ai/v1", api_key="YOUR_KEY")
# Serving provider (check your provider's docs for its endpoint)
# client = OpenAI(base_url="https://<provider>/v1", api_key="YOUR_KEY")
# Local runtime via Ollama
# client = OpenAI(base_url="http://localhost:11434/v1", api_key="ollama")

response = client.chat.completions.create(
    model="kimi-k3",  # model id differs per route
    messages=[{"role": "user", "content": "Summarise this licence."}],
)
print(response.choices[0].message.content)

互換であることは同一であることを意味しません。たとえば Kimi K3 は推論を決してオフにせず、"low"、"high"、"max" のいずれかを設定する reasoning_effort フィールドを受け取り、reasoning_content フィールドを返します。このフィールドは、同一会話の以降のすべてのターンで一切変更せずに引き継がなければなりません。そのまま差し替えられると考える前に、こうしたフィールドについて公開元のドキュメントを確認してください。

3 つの経路をどう選ぶか

ホスティング API、サードパーティのサービングプロバイダ、ローカルの量子化ビルドのどれを選ぶかは、データがどこへ行くか、製品がどれだけのレイテンシを許容できるか、そしてトークン単位で支払いたいのか稼働させ続けるハードウェアの時間単位で支払いたいのか、という点に帰着します。プロンプトに自社インフラの外に出せないデータが含まれるなら、ローカル経路か、受け入れ可能なデータ処理契約を結べるプロバイダという制約が、他のすべてを決定づけます。機能がインタラクティブなものであれば、公開元の API とサービングプロバイダはデータセンター並みの速度でフルモデルを提供してくれる一方、ノート PC 上の量子化ビルドは能力とスループットを犠牲にしてデータの外部流出をゼロにします。利用量に波があるなら、トークン単位の課金は開始コストが安く、大量利用では高くつきます。逆に安定して大量に使うなら、ハードウェア時間や自前ハードウェアがコストカーブを平坦にします。この 3 つの問いをこの順序で答えれば、経路はたいてい自ずと決まります。

まとめ

オープンウェイトとは、パラメータは手に入るがレシピは手に入らないということであり、自分のハードウェアでそれを扱えるという保証でもありません。リポジトリのライセンスファイルを読み、カードのデプロイメントのセクションを読み、ダウンロードできるかどうかではなく、データ・レイテンシ・コストの形で経路を選んでください。ローカル経路が適しているなら、Jan.ai でモデルをプライベートに実行するガイドから始めるとよいでしょう。ここで述べたことの上に直接積み重なる内容です。

FAQ

Hugging Face 上の safetensors ファイルと GGUF ファイルの違いは何ですか？

safetensors は、公開元がオリジナルの重みに用いる Hugging Face のテンソル保存形式です。テンソルのみを格納するため config と tokenizer は別ファイルとして提供され、pickle ベースのコード実行なしに読み込めます。GGUF は llama.cpp のために作られ、Ollama や LM Studio が使用しているバイナリ形式で、1 つのファイルに量子化済みテンソルと標準化されたメタデータをまとめて格納します。公開元は通常 safetensors を公開し、コミュニティがローカルランタイム向けに GGUF へ変換します。

オープンウェイトモデルのホスティング API を、OpenAI SDK ではなく Anthropic SDK から呼び出せますか？

公開元が Anthropic 互換のエンドポイントを提供していれば可能です。これはオープンウェイトの性質ではなく、プロバイダごとの機能です。Moonshot は提供しています。SDK のベース URL を https://api.moonshot.ai/anthropic に設定すると、kimi-k3 が /anthropic/v1/messages の Messages エンドポイントで応答します。Anthropic の規約が適用されるため、max_tokens は必須で、reasoning effort は output_config.effort（low、high、max）で設定し、すべての thinking ブロックは signature を含め、受け取ったとおりに正確に返す必要があります。

オープンウェイトモデルの量子化済みコミュニティビルドは、オリジナルの重みと同じライセンスが適用されますか？

適用されるものとして扱ってください。コミュニティによる GGUF や MLX の量子化版は公開元の重みから派生したものであるため、実務上は、商用利用条件、帰属表示ルール、利用規定を含む公開元のライセンス条項が、再アップロード者が追加した条件と併せて引き続き適用されます。Hugging Face リポジトリのライセンスタグはアップロードした人物が設定するもので、欠落していたり誤っていたりすることがあるため、派生物のメタデータではなく上流の LICENSE ファイルを読んでください。