Mistral Large vs Mistral Medium: 本番環境からのCTOノート
3ヶ月前、私はLLM機能をリリースしました。そして、請求書が届きました。
私は間違いに気づきました。Mistral Mediumを使うべきところで、Mistral Largeを使ってしまったのです。その結果、必要以上に4倍近いコストがかかってしまいました。
スタートアップを運営しているなら、「なんとなく」でアーキテクチャの選択をしてはいけません。ROI（投資対効果）に基づいて判断する必要があります。
間違いは単純でした。モデルは大きければ大きいほど常に良いと思い込んでいたのです。それは間違いでした。
現在、私がLLMコストを管理している方法は以下の通りです：
- タスクの複雑さを分類する
- 単純な分類や抽出には、より小さなモデルを使用する。
- 複数ステップの推論が必要な場合にのみ、より大きなモデルを使用する。
- トークン量を予測する
- ログを確認する。
- 成長予測を立てる。
- デプロイする前に計算を行う。
- 実際の評価（evals）で測定する
- 直感を信じない。
- 両方のモデルにテストセットを実行させる。
- プロダクトにとって重要なメトリクスを比較する。
私のタスクの70%において、Mistral Mediumで十分です。サポートチケットの分類も完璧にこなします。コストはLargeの3分の1です。Largeは高度な推論タスクのために取っておいています。
また、ベンダーロックインも避けています。多くのモデルにアクセスするために、統一されたエンドポイントを使用しています。プロバイダーが値上げをしても、数分でモデルを切り替えられます。これがランウェイを守ることにつながります。
CTOへのアドバイス：
- コスト削減のために積極的にキャッシュを活用する。
- ユーザー体験を向上させるためにレスポンスをストリーミングする。
- システムを稼働させ続けるためにフォールバックロジックを構築する。
- プロンプトを最適化する前にモデルを選択する。
- すべてのタスクにおいてコンテキストウィンドウの要件を確認する。
小さなハンマーで済むタスクに、スレッジハンマーを使うのはやめましょう。効率性は競争優位性を生み出します。それによって、ユーザーに対してより優れた機能とより低い価格を提供できるようになるのです。
出典: https://dev.to/gentlenode/mistral-large-vs-mistral-medium-cto-notes-from-production-280f