Inkling は手元では動かない — 1bit 量子化で 270GB という現実と、個人開発者の入口

ローカルで LLM を動かしている人にとって、「オープンウェイトで公開」という言葉は「手元で動かせる」とほぼ同義だった。Thinking Machines Lab が2026年7月15日に公開した Inkling は、その等式が成り立たない側にある。1bit まで量子化しても270GB だ。

目次

1. 何が出たのか
2. ライセンスは素直に強い
3. ただし、手元には載らない
4. ベンチマークの位置づけを正直に見る
5. 音声をそのまま食べる
6. 入口は Tinker になる
7. ファインチューンの流れを具体的に
8. MoE の総パラメータ数がディスクを決める
9. 筆者ならこう扱う
10. 参考

何が出たのか

元 OpenAI CTO の Mira Murati が率いる Thinking Machines Lab の初モデル。総パラメータ975B、アクティブ41B の疎な MoE で、66層の decoder-only 構成。

ルーティングの説明が各所で簡略化されているので補足しておく。「256エキスパート中6個」と書かれることが多いが、正確には 256個の routed エキスパートに加えて2個の shared エキスパートがあり、トークンごとに routed の6個が発火する。記事や資料に書くなら「6+2」が正しい。ルーターは sigmoid で、補助損失を使わないロードバランシングを採用している。

コンテキストは最大100万トークン。テキスト・画像・音声・動画を合わせた45兆トークンで事前学習されたネイティブ多モーダルモデルだ。入力の仕様は、テキストが UTF-8、画像が 40px から 4096px、音声が WAV 16kHz で最長20分となっている。

ライセンスは素直に強い

Hugging Face のモデルカードで確認したところ、Apache 2.0 だった。商用利用可、再配布可、ファインチューンと派生モデルの作成可、帰属表示や「Inkling」の冠名義務なし。Llama 系や Gemma 系のようなカスタムライセンスの制約が付いていない。

別途 Acceptable Use Policy がリンクされているが、内容は違法行為・CSAM・兵器・なりすましの禁止列挙で、商用や派生や再配布の制限は含まれない。実務上の義務として残るのは「エンドユーザー向け製品に組み込む場合、既知の重大な限界とリスクを開示すること」の1点だけだ。

この開示義務は、アプリに載せるつもりなら実際に効く。ヘルプなり利用規約なりに「このモデルには次の限界がある」と書く欄を用意しておく必要がある。

米国発の Apache 2.0 オープンモデルとしては、現時点で最上位クラスに入る。ここは素直に評価していい。

ただし、手元には載らない

ここが今回いちばん伝えたい部分だ。

まず前提の訂正から。軽量版の Inkling-Small は重みが公開されていない。 Hugging Face の thinkingmachines 組織にあるのは Inkling と Inkling-NVFP4 の2つだけで、モデルカードにも記載がない。276B / アクティブ12B という仕様は発表記事のプレビュー言及のみで、テスト完了後に公開予定という段階だ。現時点でローカルに落とせる軽量版は存在しない。

では本体はどうか。コミュニティが作った GGUF 版のサイズを見ると分かりやすい。

1bit 量子化ですら270GB。BF16 で約2TB、NVFP4 でも約600GB（しかも Blackwell 世代が必須で、BF16 は Hopper 以降が要る）。llama.cpp なら RAM と VRAM へのオフロードで理論上は動くが、270GB を積める個人環境はまず無いし、あっても実用的な速度は出ない。

重量級モデルは E: ドライブに1実体だけ置いて全プロジェクトから参照する運用にしている。同じモデルを複数の場所にコピーしないためだ。その E: をもってしても、この規模は対象外になる。

参考までに、動かすとしたらこの形になる。

# 推論サーバ（GPUクラスタ前提）
vllm serve thinkingmachines/Inkling --tensor-parallel-size 8 --served-model-name inkling

python3 -m sglang.launch_server --model-path thinkingmachines/Inkling \
  --tp-size 8 --served-model-name inkling --host 0.0.0.0 --port 30000

# llama.cpp（270GB 以上を積める環境なら）
llama serve -hf unsloth/inkling-GGUF:UD-Q4_K_XL

GGUF は公式配布ではなくコミュニティ製だ。品質保証はベンダー側にない。1bit 量子化は公称スコアを再現しないので、ベンチマーク値と並べて紹介すると読者を誤誘導する。

細かい話だが、Hugging Face の組織ページに表示されるパラメータ数は 952B、NVFP4 版は 553B となっていて、公称の 975B と一致しない。自動カウントの都合と思われるが、数字を引用するときは注意したい。

ベンチマークの位置づけを正直に見る

公表値を並べる。

数字だけ見れば十分に強い。ただしモデルカード自身の比較列を見ると、Claude Fable 5 が SWEBench 95.0%、AIME 99.9%、SimpleQA Verified 68.3%（Inkling は43.9%）となっている。クローズドのフロンティアには明確に届いていない、というのが正直な位置づけだ。

SimpleQA の差が大きいのは注目していい。事実知識の正確さで20ポイント以上の開きがある。RAG を挟まずに素の知識を当てにする使い方だと、この差がそのまま出る。

同社も「現時点で最強のモデルではない」と述べたうえで、自社の Tinker プラットフォームでファインチューニングする起点として位置づけている。この自己申告は正確だと思う。

音声をそのまま食べる

個人開発者として面白いのは音声のネイティブ入力だ。

messages = [{
    "role": "user",
    "content": [
        {"type": "text",  "text": "Transcribe the speech"},
        {"type": "audio", "audio": audio_url}
    ]
}]
inputs  = processor.apply_chat_template(messages, tokenize=True, return_tensors="pt")
outputs = model.generate(**inputs, max_new_tokens=512)

音声を dMel スペクトログラムで離散トークン化し、テキストと同じ隠れ空間に射影して単一のデコーダで処理する。文字起こしを挟んで LLM に渡す2段構成では失われる韻律や話者の違い、言い淀みを保ったまま推論できる。

筆者は録音からローカル Whisper を通して Word に落とすアプリを作って公開している。スレッド処理、ハルシネーション対策、入力デバイスの選択まで自分で書いた構成だ。あれと比べると、棲み分けはこうなる。

長い会議録を安く回すなら Whisper のまま。短い音声を「何を言ったか」に加えて「どう言ったか」まで含めて扱いたい場面が Inkling 側になる。

具体的には、問い合わせ音声から温度感を判定したい、面接の録音から言い淀みの位置を拾いたい、といった用途だ。文字に落とした時点で消える情報を使いたいなら、2段構成では届かない。

入口は Tinker になる

ローカル実行が現実的でない以上、個人開発者の入口は同社の Tinker プラットフォームでの利用とファインチューンになる。

チェックポイント保管は $0.10/GB/月。64K と 256K は別モデルではなく、Tinker 側の課金コンテキスト階層で、モデル自体の上限は100万トークンのままだ。キャッシュ済みの prefill は80%引きになる。

使い方は uv pip install tinker tinker-cookbook から入り、ServiceClient を作って LoRA の TrainingClient を取り、forward_backward() と optim_step() のループを回す形になる。

評価できるのは、学習した重みを取り出せる点だ。tinker_cookbook.weights の download() や publish_to_hf_hub() で HF 形式にエクスポートできる。プラットフォームに閉じ込められない。

なお料金表には「Limited-time 50% discount」と表示されているが、期限日の記載がない。第三者ブログには7月17日に値上げしたという記述もあるが、本稿執筆時点で公式ページは割引表示のままで、裏が取れなかった。契約前に自分で確認してほしい。

ファインチューンの流れを具体的に

Tinker が入口になるなら、どう使うのかを見ておきたい。

uv pip install tinker tinker-cookbook

ServiceClient を作って LoRA の TrainingClient を取り、forward_backward() と optim_step() を回す。学習ループを自分で書く形なので、既存の PyTorch のコードに近い感覚で組める。

出口が用意されている点が効く。tinker_cookbook.weights の download() でローカルに落とせるし、publish_to_hf_hub() で Hugging Face に上げられる。学習した成果がプラットフォームの中に閉じない。

この設計は評価していい。ファインチューンのサービスは、学習した重みを取り出せないものが少なくない。取り出せないと、料金が上がったときにもサービスが終了したときにも動けなくなる。

費用の見当をつけるなら、64K の Train が100万トークンあたり $5.61。手元の小さなデータセットが10万トークン程度なら、数エポック回しても数ドルの範囲に収まる。試すだけなら現実的な額だ。

MoE の総パラメータ数がディスクを決める

個人には載らないと分かったうえで、この規模の設計を眺めておくのは無駄ではない。

アクティブが41Bというのは、推論時に実際に計算されるパラメータ数だ。総量975Bのうち大半は使われないまま待機している。エキスパートを増やして総量を積み、トークンごとに少数だけ発火させることで、計算量を抑えながら知識量を増やす。

shared エキスパートを2つ常時発火させる構成も特徴だ。どのトークンでも共通して要る処理をここに集め、残りを routed 側で切り替える。全部を routed にすると、共通処理が各エキスパートに重複して学習される。

そしてこの設計の代償が、ディスクとメモリに出る。使わないパラメータも保持しなければならないので、270GB という数字になる。計算量は減らせても、置き場所は減らない。

個人開発者にとっての含意は単純だ。MoE のアクティブパラメータ数を見て「41B なら動くかも」と考えると外す。 見るべきは総パラメータ数のほうで、そこがそのまま必要な容量になる。

筆者ならこう扱う

できることはローカル完結で作るのが好みで、機密を含むデータを外に出さない構成を優先してきた。Inkling はその方針とは相性が悪い。重みが公開されていても、手元では動かないからだ。

それでも注目する価値はあると考えている。Apache 2.0 でここまでの規模が出たこと自体が前例になるし、Inkling-Small の重みが実際に公開されれば話が変わる。276B / アクティブ12B なら、量子化次第で手が届く可能性がある。

筆者なら今は待つ。Tinker で少額の実験を1本回して感触を見つつ、Small の公開を待つのが、費用対効果としては素直だと思う。試すなら、自分の手元にある小さなデータセットで LoRA を1回だけ回して、素の Inkling との差を見るところまでで十分だ。それで元が取れる手応えが無ければ、Small を待てばいい。

ローカルでの音声文字起こしについてはWhisperで音声を文字起こしするアプリの制作記事で扱っている。手持ちの環境で何が動いて何が動かないかを把握しておくと、こういう発表を冷静に読める。

参考

• Introducing Inkling（公式）
• Inkling（Hugging Face）
• Tinker ドキュメント