
Inkling-Smallを30秒で
| 発売 | 2026年7月30日、Inklingから15日後 |
| 開発元 | Thinking Machines Lab(ミラ・ムラティ) |
| サイズ | 総パラメータ276B、アクティブ12B、42層 |
| ライセンス | Apache 2.0、ウェイトはHugging Faceで公開 |
| コンテキスト | モデルカードでは100万トークン、OpenRouter経由では524K |
| 入力 | テキスト、画像、音声(16kHz WAV) |
| API価格 | 入力0.30〜0.50ドル、出力100万トークンあたり1.20ドル |
| セルフホスト下限 | 2ビット量子化で89GB |
| 得意分野 | コーディング、ツール利用、エージェントループ、長文コンテキスト |
| 苦手分野 | 検索(リトリーバル)なしでの事実の想起 |
Inkling-Smallとは実際どういうモデルか
興味深いのはアーキテクチャの部分で、そこが結果の両面を説明している。
Inkling-Smallは42層のデコーダー専用トランスフォーマーで、スパースなmixture-of-expertsのフィードフォワード構成を持つ。各トークンは256個のエキスパートのうち6個に加え、すべてのトークンで必ず発火する共有エキスパート2個にルーティングされる。総パラメータは276Bだが、トークンあたりでアクティブになるのはそのうち12Bだけだ。モデルカードによれば、ローカル・グローバル両方のハイブリッドなアテンション層、BF16とNVFP4の数値表現、そしてNVIDIA GB300 NVL72システム上での学習が確認されている。
親モデルと比較してみよう。Inklingは総パラメータ975B、アクティブ41B、66層で、ルーティングの構造は同じだが、総量はおよそ4分の1、アクティブ量は3分の1未満に抑えられている。Thinking Machines自身はこの結果を「Inklingと同等の性能を、そのサイズの4分の1で実現した」と表現している。
このサイズの比率こそが、すべての話の核心だ。総パラメータとアクティブパラメータの比率が大きいことがモデルを安価に提供可能にする一方、総パラメータ数そのものが小さいことがモデルを忘れっぽくする。Inkling-Smallは前者を強く推し進め、その代償を後者で払った格好だ。この仕組み自体の一般的な話は、ベンチマーク表抜きでカスタムAIモデルが扱っている。
入力はテキスト、次に画像(40〜4096ピクセルが最適)、そして音声は16kHzのWAVで、2分以内が理想だ。出力はテキストのみとなる。推論の強度は0から0.99までのダイヤルで調整でき、低は0.2、中は0.7、最大は0.99で、呼び出しごとに思考トークンとレイテンシのトレードオフを調整できる。
このリストの中で最も珍しいのがネイティブの音声入力で、これがこのモデルが音声関連の会話で話題に上る理由だ。ただし限界も指摘しておく必要があり、音声は入力できても音声合成の機能は一切ない。その部分まで完結させているベンダーについてはAI音声企業でカバーしている。
Inkling-Smallはどの用途に向いているのか?
答えはワークロード次第で大きく変わり、それぞれについて開発元自身の表が証拠を示している。実際に抱えている用途を選んでみてほしい。
ベンチマーク:本当に親モデルを上回っている
蒸留・縮小されたモデルは通常、元となったフラッグシップに少し及ばないところに落ち着くものだ。しかしInkling-Smallは違う、少なくとも大半の人がモデルを選ぶ理由となるカテゴリーにおいては。

コーディングではSWEBench Verifiedで80.2%対77.6%、SWEBench Proで55.9%対54.3%、Terminal Bench 2.1で64.7%対63.8%と勝っている。エージェント面ではToolathlon Verifiedで54.4%対45.5%、MCP Atlasで79.6%対76.0%を上回り、GDPval-AA v2のEloも1269対1238で勝る。一般的な推論ではGPQA Diamondで89.5%対87.2%、Humanity's Last Examではテキストのみで31.6%対29.7%だ。
親モデルのカードには一切記載のない数値も出している。SciCode 48.7%、CritPt 8.3%、そしてARC-AGI-1が84.0%、ARC-AGI-2が40.1%。指示追従についてはIFBenchが82.2%対79.8%で、システムプロンプトを確実に守る必要があるあらゆる用途にとって、これは見た目以上に重要だ。この軸を重視するなら、AIエージェント対ルールベースのチャットボットが、本番環境では従順さが生の知能に勝る理由を解説している。
推論面での負けは本物だが、幅は狭い。AIME 2026は97.1%から95.5%に下がる。Tau 3 Bankingは23.7%から15.5%に下落し、これはエージェント系ブロック全体で最も鋭い後退であり、ワークロードが構造化された金融フローに近いなら留意すべき点だ。
もうひとつ見逃されがちな結果に触れておく。多言語テストであるGlobal-MMLU-Liteは88.7%から86.7%へと落ちる。2ポイントの下落なので劇的ではないが、事実性の数値と同じ方向を指しており、削減されたのは「知識の広さ」だったことを示している。複数言語でサービスを提供しているなら、集計値を鵜呑みにせず各言語でテストすべきで、そのテストの実際のやり方は多言語対応サポートエージェントで扱っている。
第三者機関のArtificial Analysisは、Intelligence Indexで101モデル中15位の40点をこのモデルに与え、フル版のInklingは13位の41点だ。サイズが4分の1で、インデックスの差はわずか1ポイント。開発元によるスコアリングと第三者機関のスコアリングが同じ結論に着地するのは珍しく、これこそがこのレビューの中で最も強力な事実だ。
あなたを立ち止まらせるべき、たった一つの数字
ここからは、発売時の投稿には書かれていなかった部分だ。
モデルが短い事実に基づく質問に答えられるかを測るSimpleQA Verifiedは、Inkling-Smallで20.6%、Inklingで43.9%だ。半分以下ということになる。そして正しい答えと自信満々の間違った答えを差し引きするAA Omniscienceは、親モデルの+2.1に対してこちらは**-9.0**だ。
マイナスのOmniscienceスコアは、モデルが正しいことより間違ったことを自信満々に述べる回数の方が多いことを意味する。これは「わかりません」と言うモデルではない。空白を埋めてしまうモデルだ。Thinking Machines自身も既知の制限事項としてこれを挙げており、「もっともらしいが事実として不正確、または裏付けのないコンテンツを生成するハルシネーション」と「長い複数ターンの会話でのパフォーマンス低下」を挙げ、さらなるファインチューニングなしに医療・法務・安全性が絡む用途への展開は推奨しないとしている。多くのラボがわざわざ公開しない、率直な制限事項セクションであることは評価すべき点だ。
コーディングエージェントにとってこれはほとんど問題にならない。コンパイラがファクトチェッカーの役割を果たすからだ。しかし顧客対応の用途では話が大きく変わり、私自身、本番環境でこの失敗パターンを目にしたことがある。私が関わったあるサポートチームは、ナレッジベースに「すべての車種に対応している」と書かれていたため、ボットは自社のデータベースに存在しない車のブランドについても平然と対応可能だと答えてしまっていた。劇的な意味でのハルシネーションが起きたわけではない。モデルはただ、空白をもっともらしい何かで埋めただけだ。そのチームは初期の運用を「最初は試行錯誤だった」と表現していた。
Omniscienceが-9.0のモデルは、まさにこの同じ失敗パターンの音量を上げたようなものだ。対処法自体は既知でありありふれたもので、自社が管理するソースに基づくリトリーバル、人間が検証できる引用、そして拒否経路の3つだ。サポートにおけるAIハルシネーションで対処法の全体像を、より実務的な短縮版はAIハルシネーションの防止でカバーしている。
価格と速度:本当に気にすべき理由
ここが小型モデルが自分の居場所を証明する部分だ。
| Inkling-Small | Inkling | |
|---|---|---|
| 入力(100万あたり) | $0.30〜$0.50 | $1.00 |
| 出力(100万あたり) | $1.20 | $4.05 |
| ブレンド単価(AA) | $0.22 | $0.72 |
| 出力速度 | 131.1 tok/s | 84.8 tok/s |
| 最初のトークンまでの時間 | 1.65秒 | 1.82秒 |
| プロバイダー数 | 2 | 4 |
| AA Intelligence Index | 40 | 41 |
出力トークンは3.4倍安く、1.5倍速く届く。知能の差はわずか1インデックスポイントだ。出力トークンが課金の大半を占め、数十ターンにわたってレイテンシが積み重なるエージェントループにおいて、これはわずかな差ではない。この差はサポートチームが実際に追う数値にも表れる。初回応答が速くなることは初回接触解決率を押し上げ、そこから派生するカスタマーサービスの指標全体にも影響する。
予算を組む前に、2つ注意点がある。入力価格はまだ確定していない。Artificial Analysisは100万あたり0.30ドルとしているが、OpenRouterの掲載は0.45ドル、APIの返り値は0.50ドルとなっているため、自分が使うルートで確認してほしい。また、現時点でプロバイダーは2社しかなく、親モデルの4社に対して薄い状況で、フェイルオーバーが必要なら心もとない。
2つ目の注意点はより驚くべきものだ。モデルカードには100万トークンのコンテキストとあるが、OpenRouterでは現在524,288トークン、つまりちょうど半分しか提供されていない。ウェイト自体はフルウィンドウをサポートしているが、ルーティングされたAPI側がまだそれを公開していないだけだ。100万トークンがこのモデルを選ぶ理由だった場合は、セルフホストするか、まずプロバイダーに確認してほしい。コンテキストウィンドウのサイズは、公称値と実際に使える値がこれほど乖離しがちな理由を扱っている。
Thinking Machinesの実際のビジネスは、ホスト型のLoRAファインチューニングプラットフォームであるTinkerであり、Inkling-Smallもそこでサポートされている。チェックポイントのストレージは1GBあたり月0.10ドルで、トークン単位の学習料金は概要ページには公開されていない。
Inkling-Smallを自分で動かす
セルフホストは親モデルに対する最もわかりやすいアップグレードで、ここでは数値の差が歴然としている。

Unslothの数値によれば、Inkling-SmallはBF16で543GB、4ビットで132〜170GB、3ビットで128GB、そして2ビットで89GBだ。フル版のInklingはBF16で1,900GBを必要とし、1ビット量子化でも270〜285GBを求められる。モデルカードは同じことをハードウェアの観点でも説明しており、BF16では集約VRAM600GB(B300×4またはH200×8)、NVFP4チェックポイントなら180GB、つまりB300が1台、あるいはH200が2台で済むとしている。
この89GBという数字こそが、誰がこれを動かせるかを変える。128GBのユニファイドメモリ搭載マシンに収まるということは、データセンターではなくワークステーションの購入で済むということだ。しかもトークンあたりアクティブになるのは12Bパラメータだけなので、大幅に量子化したビルドでも使い物にならないほど遅くなることはない。
推奨されるサンプリング設定はtemperature 1.0、top_p 1.0、min_p 0.0で、コンテキストは1,048,576トークンだ。発売初日からtransformers、vLLM、SGLang、TokenSpeed、Unsloth、Docker Model Runnerに対応し、量子化ビルドはllama.cpp、Ollama、LM Studio、Janを通じて利用できる。ひとつ注意点として、llama.cppはPR #25731のマージが必要だ。より幅広いセルフホストの選択肢は最良のオープンソースAIエージェントにまとめている。
メリットとデメリット
良い点
- 3.5倍のサイズを持つモデルを上回る、コーディングとツール利用、さらに指示追従において
- 出力100万トークンあたり1.20ドルで、親モデルより3.4倍安い
- 1秒あたり131トークンと、意味のある速さの向上
- Apache 2.0なので商用セルフホストに制限がない
- 量子化すれば89GBで動作し、ワークステーションの範囲内
- この価格帯ではまだ珍しい、ネイティブの音声・画像入力
- 開発元自身による率直な制限事項セクション
そうでない点
- SimpleQA Verifiedが20.6%で、親モデルの半分以下
- AA Omniscienceが-9.0で、正しい答えより自信満々の間違った答えの方が多い
- 紙の上では100万トークンのコンテキストだが、OpenRouter経由では現在524K
- APIプロバイダーが2社のみで、フェイルオーバーが心もとない
- Tau 3 Bankingが23.7%から15.5%に下落
- 音声関連の3つのテストすべてで親モデルにわずかに劣る
- テキスト出力のみで、画像や音声の生成はできない
コミュニティの反応
反応は親モデルの発売時よりもかなり控えめで、親モデルはHacker Newsで1,200ポイント以上を集めたのに対し、Inkling-Smallのスレッドは33ポイントにとどまった。最初の反応は、他モデルとの位置づけを測るものだった。
"better than haiku 4.5 smaller than nemotron 3 ultra"
もうひとつのコメントは、オープンウェイトの明白なライバルと並べて評価しており、"About the same size as DeepSeek Flash 4, but also supports audio and image input."と指摘していた。的確な見立てだ。DeepSeek V4 Flashはトークン単価が安く、テキスト専用なので、音声・画像対応こそがここでの本当の差別化ポイントであり、その詳細な比較はFlashレビューにまとめてある。
最も鋭いコメントは、量子化版が出る前、Hugging Faceへの投稿に対して寄せられていた。
"I didn't see a gguf yet, going to be most interesting if there's a quant that fits nicely into about 90 [GB] so it can run in 128GB unified memory. It's 12B active so should hopefully be pretty fast at 2 bit quant if it fits"
Unslothの2ビットビルドは89GBに着地した。ローカル推論コミュニティは、リリースが存在する前からその目標数値を言い当て、そして実際にそれが的中した。発売から最初の1か月で、Hugging Faceのリポジトリは15,500回のダウンロードを記録している。
ひとつ気づいたことがある。それらのスレッドの中で、事実性の後退について言及している人が誰もいなかったことだ。発売時のフレーミングが速度とサイズだったため、話題もそこに集中した。
チケット対応にこれを使いたいなら
ここは率直に言わせてもらう。これは私自身の実際の仕事に直結する部分だからだ。
安くて速いモデルは、サポート用途にとって一見明らかな勝利のように見える。チケット量は多く、返信は短く、100万出力トークンあたり1.20ドルと4.05ドルの差は、規模が大きくなれば本当の金額差になる。これはAIカスタマーサービスのコストの背後にある算術であり、人間対応との比較を動かしているのも同じ計算だ。これを単価として追跡しているチームは、たいてい解決あたりのコストという指標に落ち着く。
しかしサポートは、Omniscienceの-9.0が脚注ではなく失格理由になる、唯一のワークロードだ。コーディングエージェントが存在しないAPIをでっち上げても、返ってくるのはスタックトレースだけだ。サポートエージェントが存在しない返品期限をでっち上げれば、それはそのまま文章として顧客に届き、しかもあなたのロゴが付いた状態で送られる。私が話す買い手はすでにこれを理解しており、真っ先に出てくる懸念点もここだ。あるDTCサプリメントブランドのCXリードは、これ以上ないほど率直にこう言っていた。
"The AI will never be able to answer 100% of the questions... I need an AI who is only handling the tickets that it's confident to handle and all the other ones, leave them alone."
a DTC supplements CX lead, from an eesel sales call
これはモデルへの要望ではなく、層(レイヤー)への要望だ。モデルとキューの間には、次の4つが挟まっている必要がある。
- 自社が保有するソースに基づくリトリーバル。 答えがウェイトの中身からではなく、自社のヘルプセンターや過去のチケットから出てくるようにする。パターンについてはAIナレッジベースチャットボットで、ツール面については最良のAIナレッジベースツールで扱っている。
- 確信度によるルーティング。 モデルが自信のあることだけに答え、残りはエスカレーションする。ルーティング側はAIエスカレーション管理、人間へのスムーズな引き継ぎはエージェントハンドオフで扱っている。
- 本番稼働前のドライラン。 誰かのベンチマークスイートではなく、自社の過去のチケット履歴に対してシミュレーションする。これはチームがつい省略してしまうステップであり、同時に自信満々の間違った答えを捕まえる唯一のステップでもある。
- 自律性の範囲を絞ること。 自分で返信する前に、まずドラフトを書くコパイロットとして始める。AIコパイロットがその入り口で、行き着く先はティア1のデフレクションであり、デフレクション率で測られる。
この4つを実行すれば、Inkling-Smallの事実性のギャップは弱点ではなくなる。なぜなら事実がそもそもモデルから出てこなくなるからだ。これを省けば、手に入れたのは速くて安くて自信満々な、もっともらしい回答の供給源にすぎない。それがAIヘルプデスクエージェントと生のAPIキーとの違いであり、AIエージェント対AIチャットボットが別の角度から到達しているのも同じ結論だ。
これはまた、優れたサポート層がモデルに依存しない設計であるべき理由でもある。Inkling-Smallは、今年「明白な安い定番」になった最初のモデルではないし、最後でもないだろう。単一モデルに固定してしまえば、リーダーボードが動くたびに作り直しになる。これはカスタマーサービスの自動化を運用する上でまずいやり方だ。
結論
ほとんどの用途において、Inkling-Smallは親モデルよりも良い買い物であり、価格面では差は歴然としている。第三者機関のスコアリングでは同じ知能階層に位置し、開発元自身の数値ではコーディングとツール利用で優れており、出力コストは3.4倍安く、速度は1.5倍、ライセンスはApache 2.0、そしてワークステーションでセルフホストできるほど小さい。フラッグシップから15日後、この小型モデルはフラッグシップの存在意義を問うほどの結果を出した。
留意点は明確で言語化しやすい。測定可能なほど知識量が少なく、しかもそれを自覚した振る舞いをしない。コンパイラやツールループ、リトリーバル層を与えれば優秀だ。真実の情報源になれと求めれば、自信満々に間違える。
コードやエージェント用途に使いたいなら、今すぐ採用していい。顧客の近くで使いたいなら、トークン代だけでなく、その上に載せる層の予算も組んでおくべきだ。
このポジションに他にどんな選択肢があるかについては、Inklingの代替候補から見てほしい。価格とサイズで最も近いライバルについては、Kimi K3レビューで個別に扱っている。
そして実際の仕事がコード生成ではなく受信箱の仕分けなら、サポートチケットのトリアージの方が役に立つ内容で、トリアージの後に何が起きるかはチケットデフレクションで扱っている。
Try eesel
Inkling-Smallを選び、いよいよ実際のチケットに安全に答えさせる段階に来ているなら、そのギャップを埋めるのがまさにeeselだ。Zendesk、Freshdesk、Gorgias、あるいはあなたが使っているどのヘルプデスクにも数分でつながり、モデルのウェイトからではなく、解決済みのチケットとヘルプセンターから学習し、自信のあることだけに答えて、それ以外はチームのために残す。実際のキューに触れさせる前に、自社のチケット履歴に対してシミュレーションし、実際にどんな返信を送っていたかを確認できる。これは-9.0という事実性スコアが要求する、譲れないチェックだ。モデルにも依存しないので、次に安いモデルが出てきても、必要なのは設定変更だけで作り直しにはならない。

無料で試せて、使った分だけの課金なので、コミットする前に料金を確認できる。Try eesel、あるいはAIカスタマーサービスソフトウェアとしてどう機能するか見てほしい。
Sources
- Inkling-Small model card
- Introducing Inkling-Small
- Inkling model card
- Inkling-Small on Hugging Face
- Artificial Analysis: Inkling-Small
- Artificial Analysis: Inkling
- Unsloth: running Inkling locally
- OpenRouter: Inkling-Small
- Tinker fine-tuning platform
- Hacker News: Inkling-Small
- Hacker News: Hugging Face submission
よくある質問
Inkling-Smallは使う価値があるか?
Inkling-SmallはInklingより優れているか?
Inkling-Smallの料金はいくらか?
Inkling-Smallをローカルで動かせるか?
Inkling-Smallはカスタマーサポートに向いているか?
Inkling-Smallのコンテキストウィンドウはどれくらいか?
Inkling-Smallは無料でオープンソースか?
thinkingmachines/Inkling-SmallとしてApache 2.0で公開されており、自前でホストして商用利用することも可能だ。ただしダウンロードが無料でも実行が無料になるわけではなく、トークン課金の代わりにハードウェア費用がかかる。Thinking Machinesはホスト型のファインチューニングプラットフォームTinker経由でのアクセスも販売している。Inkling-Smallは誰が作り、いつ発売されたか?

Article by
Alicia Kirana Utomo
Kira is a writer at eesel AI with a Computer Science background and over a year of hands-on experience evaluating AI-powered customer service tools. She focuses on breaking down how helpdesk platforms and AI agents actually work so that support teams can make better buying decisions.







