みなさんこんにちは。おそらく Tesslate による omnicoder-9B をご存じの方もいるでしょう。これは Qwen 3.5 アーキテクチャをベースにしており、Qwen3.5 9B の上にファインチューニングされ、Opus 4.6、GPT 5.4、GPT 5.3 Codex、Gemini 3.1 Pro の出力を、特にコーディング用途向けに組み合わせています。
これまでの omnicoder 9B の経験については、卓越している部分もあれば、中程度の印象もあります。まず、卓越している理由から：このモデルは qwen3.5 9B と比べて非常に高速です。私には 12GB の VRAM があり、コンテキストサイズを 100k に設定しても、1秒あたりのトークン数が安定して約 15 であり、PC がクラッシュしたり重くなることなく動作します。また、プロンプト処理も迅速で、プロンプト処理は約 265 トークン/秒です。つまり、中程度のハードウェアでの動作の良さという点では、これまでのところ良い体験です。
さて、次は「なぜ中程度なのか？」という点です。私は新しいモデルが出るたびに、スタンドアロンの HTML ファイルでスーパーマリオのクローンを作る習慣があり、1回限りのプロンプト（ワンショット・プロンプト）を用いています。新モデルごとに開発した各スーパーマリオのゲームを格納する専用のフォルダを一つ持っています。このテストでは Opus 4.6 も試しました。Omnicoder に戻って、これをワンショットできたでしょうか？結論は「いいえ」です。私もそれを期待していませんでした。qwen3.5 も同様にはできませんでした。さらに悪いのは、適切なツール呼び出しを実行できない時があることです。設定済みの MCP サーバーのいくつかからデータを取得できず、最初に実行したときには MCP エラーが出て、良い印象ではありませんでした。Claude code からの書き込みツール呼び出しを正しく実行できず失敗することもありましたが、それは Claude code との互換性の問題かもしれないので、自分で解決していく必要があると考えています。
さて、IDE 内での使用はどうなるでしょうか。LM Studio のみでモデルをテストするのは公平ではないと感じたため、Roo code と Claude code を用いて Antigravity に統合しました。
結果：LM Studio はトークンサイズが大きくなると切断を繰り返しました。最大で 4k まで、これは Roo code と LM Studio の統合の問題だと思います。モデル自体の問題ではありません。他のモデルを試した場合も同じ結果でした。トークンサイズが 2k〜3k の範囲であれば小さなスクリプトの更新や作成は容易に行えましたが、2k〜3k を超えるトークンについてはエラーなしに API リクエストが失敗しました。
次に Claude code でも試しましたが、トークン生成は Roo code と比較して遅いと感じました。出力を生成した後、Claude code での書き込みツール呼び出しの実行に失敗しました。
要約: Omnicoder はかなり高速で、ミッドレンジのハードウェアにも適していますが、IDE 内の公正な環境で適切にテストする必要があります。
また、Roo code や Claude code で私と同じ問題に直面していて、それらを解決する手助けができる方がいれば、感謝します。
私はローカル LLM 用の続行機能やその他の拡張機能も試しましたが、現時点では Roo code が私にとって最良の選択だと思います。
