9月9日、Together AIが「The Open Source AI Stack」と題した記事を公開した。クローズドソースモデルからオープンソースモデルへ移行する開発者が把握すべきAIスタックの全体像について、実践的な観点から詳しく解説している。
クローズドからオープンへ——なぜ今なのか
オープンソースモデルの品質がクローズドソースモデルに追いつきつつある。DeepSeekやKimiといったモデルの台頭により、コスト・制御性・所有権を理由にオープンモデルへの移行を検討する開発者や組織が増えている。
Together AIの記事が強調するのは、「オープンモデルを使うためにGPUラックを買ったり、機械学習の専門家になる必要はない」という点だ。アプリケーション開発者の視点では、クローズドモデルの利用と構造的にほぼ同じである。既存のAIコーディングツールの使い方を知っているなら、オープンモデルへの移行は思っているより近い。
MIGHTスタックとは何か
記事では、オープンモデルを活用するスタックを 「MIGHT」 という頭字語で整理している。
- Model：プロンプトを解釈し、何をすべきかを判断するコンポーネント
- Inference：モデルが実際に動作するインフラ・推論プロバイダー
- Gateways and routers：コスト・速度・能力のバランスを取りながら、どのモデル・プロバイダーにリクエストを振るかを決めるレイヤー
- Harness：会話を管理し、モデルにツールアクセスを与え、コードベースと接続するアプリケーション
- Tools（Skills and MCP）：モデルが特定タスクをこなすための知識・ツール群
これらのレイヤーは互いに独立しており、新しいモデルが登場したときに、ワークフロー全体を作り直すことなく数分でモデルだけ切り替えられる。
モデル選択が最大の意思決定ポイント
記事の中で最も実践的な内容がモデル選択だ。「大きいモデルが常にベター」ではなく、タスクの曖昧さに応じて使い分けるという考え方が提示されている。この判断が、コストとパフォーマンスの両立において最も影響が大きい。
大規模モデル：曖昧なタスクに強い
大規模モデルの代表例として挙げられているのが **Kimi K3**（総パラメータ数1.8T、アクティブパラメータ104B）。Mixture-of-Experts（MoE）アーキテクチャを採用しており、全パラメータのうち一部だけを各トークン生成時に活性化する設計だ。見かけ上のパラメータ数よりも推論コストを抑えられるのが特徴である。
大規模モデルが向くタスクの例：
- 既存の認証システムのリファクタリング
- コードベースの新フレームワークへの移行
- プルリクエストのレビュー
- SQLデータベースのパフォーマンス劣化の原因調査
複数の制約を同時に追いながら判断を下す「マルチステップ推論」が得意で、エージェント型のワークフローとの相性がよい。
小規模モデル：明確なタスクはコスパ最強
一方、**GLM 5.3 Flash（総パラメータ320B、アクティブパラメータ18B）は、元記事によればKimi K3の約6分の1のサイズで、約20分の1のコスト**で動作するとされている。
タスクが明確に定義されているなら、小規模モデルで十分なケースが多い：
- 特定の関数に引数を追加する
- あるファイルのテストを書く
- 50行の関数のバグレビュー
- APIのリネームと呼び出し元の更新
「大きいモデルが上位互換」ではなく、用途の異なる2種類のツールとして捉えるべき、というのが記事の主張だ。
モデルの探し方
新モデルは毎週リリースされており、全て自前で評価するのは現実的ではない。The Open FrontierやArtificial Analysisのリーダーボードが発見の起点として有用だ。ただし、「ベンチマーク1位を探すことに時間をかけすぎるな」とも釘を刺している。ベンチマークは多様な挙動を1スコアに圧縮しており、実際の業務タスクとの相関は必ずしも高くないためだ。
記事執筆時点での人気オープンモデルとして、GLM 5.3 Flash、DeepSeek V4 Flash（0731）、Kimi K3、MiniMax M3 が挙げられている。
推論プロバイダー、ゲートウェイ、ハーネス
推論プロバイダー
Together AIのようなクラウド推論プロバイダーは、APIキーを作ってモデル名を指定するだけで推論を実行できる。費用はトークン数に応じた従量課金だ。同じモデルを異なるプロバイダーで動かした場合、モデルバージョンとサンプリング設定が同じなら結果はほぼ同等になる。
ゲートウェイ・ルーター
すべてのモデルが全プロバイダーに展開されているわけではないため、単一プロバイダーでは賄えないケースが生じる。OpenRouterやVercel AI Gatewayのようなクラウドゲートウェイは、複数バックエンドを単一APIに集約し、コードを変えずにモデルを切り替えられる。自前でルーターを立てたい場合はLiteLLMが選択肢となる。
ハーネス
ハーネスはユーザーとモデルの間に立つアプリケーションで、会話管理・ツール実行・コードベースとの接続を担う。モデルは「何をすべきか」を判断するだけで、実際にファイルシステムを検索したりシェルコマンドを実行するのはハーネス側だ。同じモデルでも、ハーネスが違えば使用感は大きく変わる。
Claude CodeやCodexのようなクローズドソースハーネスに対して、TogetherLinkを使うことでオープンウェイトモデルを接続することも可能だ。ただし、記事におけるこの言及はあくまで接続手段の一例として紹介されており、オープンソースハーネスへの移行全般が記事の主題である。
ToolsレイヤーとMCP
ハーネスは Skills（特定タスクの実行方法を伝える再利用可能な指示）と MCP（Model Context Protocol）サーバー で拡張できる。MCPはAnthropicが策定したオープン仕様で、AIエージェントを外部ツールやデータソースに接続するための共通インターフェース規格だ。特定ベンダーに依存しない形でツール連携を標準化することを目的としており、対応するサーバーやクライアントがエコシステムとして広がりつつある。コミュニティのSkillsはskills.sh、MCPサーバーはmcp.soで探せる。Together AI独自のMCPサーバーはドキュメントで公開されている。
詳細はThe Open Source AI Stackを参照していただきたい。
