【要約】OCI Generative AIでGeminiもgpt-ossも呼べたので、7モデルの日本語力を比べてみた [Qiita_Trend] | Summary by TechDistill
> Source: Qiita_Trend
Execute Primary Source
// Problem
開発者がOCIで生成AIを利用する際、リージョンによる可用性の違いや、モデルごとの仕様の差異に直面する。具体的には以下の問題がある。
- ・東京リージョンではAPIが利用できず、502エラーが返る。
- ・モデルごとに
apiFormatが異なり、実装に注意を要する。 - ・Thinkingモデルが
maxTokensを消費し、本文が空になる。 - ・課金単位が「文字」と「トークン」で混在している。
// Approach
筆者は大阪リージョンの環境を構築し、OCI CLIを用いて複数のLLMモデルの性能を比較した。検証の手順は以下の通りである。
- ・大阪リージョンでのモデル一覧取得と、各モデルへのAPIリクエスト検証。
- ・「破天荒」という語彙を用いた日本語能力の比較テスト。
- ・
maxTokens設定による思考モデルの挙動確認。 - ・公式ドキュメントに基づく課金体系の調査。
// Result
大阪リージョンでは多様なモデルが利用可能だが、実装とコスト管理に注意が必要であることが判明した。検証の結果は以下の通りである。
- ・日本語能力ではGemini 2.5 Flash/Pro、Cohere Command A、Llama 4 Scoutが正解。
- ・Thinkingモデル利用時は、思考分を見込んだ
maxTokensの確保が必須。 - ・課金はモデルにより「文字」と「トークン」が混在するため、精緻な試算が必要。
Senior Engineer Insight
> 実戦的な観点から、マルチモデル環境における「仕様の不均一性」が最大の懸念点である。リージョン制約による構成への影響、モデルごとのリクエスト形式の差異、課金単位の混在は、設計時の不確実性を高める。特にThinkingモデルのトークン消費は、レイテンシとコストの両面に直結するため、厳格なパラメータ制御が求められる。