Dify Tokenの統計がクラウドベンダーと不一致なのはなぜ？

議論
1

Difyのバックエンドのトークン統計とクラウドベンダーの統計が異なるのはなぜですか？

2

Difyのバックエンドのトークン統計と、クラウドベンダー（OpenAI、アリババ、テンセントなど）の統計が一致しない場合、通常いくつかの原因が考えられます。一つずつ確認してトラブルシューティングを行ってください。

1. 統計の基準が異なる

よくある相違点：

  1. プロンプト / システム / ツールコールをすべて含めるか

    • クラウドベンダーは一般的に以下を含めます。
      • 入力：システム + ユーザー + ツールコールなど、すべてのプロンプトテキスト
      • 出力：モデルが生成したすべてのトークン
    • Difyでは：
      • 一部の場所では「合計トークン」のみを表示します。
      • 一部のビューでは「モデル呼び出しトークン」と「ナレッジベース検索/エンベディングトークン」を分けて統計します。
    • Difyの特定の側面だけを見て、クラウドベンダーの「総使用量」と一致しないのは正常です。

  2. ナレッジベースの埋め込み（Embedding）/ 検索コストを含むか

    • Difyのナレッジベースは以下の場合に発生します。
      • ドキュメントのベクトル化インポート
      • 対話検索時のクエリエンベディング / リランク
    • これらのエンベディングモデルが消費するトークンは、一部のクラウドベンダーでは「Usage / Embeddings」で個別に計算されます。
    • Difyのバックエンドでも使用量として計上されますが、クラウドベンダーのコンソールでは「Chat/Completion」タイプのモデルの使用量しか見ていない可能性があります。

  3. 「リクエスト回数」と「トークン数」のどちらで比較するか

    • 一部のクラウドベンダーのコンソールでは、デフォルトで「リクエスト数」または「金額」が表示され、トークンではありません。
    • 比較するには、クラウドベンダーのコンソールで「トークン単位」に切り替える必要があります。

2. 請求範囲が異なる

  1. 時間範囲の不一致

    • Difyのバックエンドでは過去24時間 / 特定の日付範囲を選択します。
    • クラウドベンダーはUTC時間 / 月間累計を選択します。
    • 特に日をまたぐ場合や月をまたぐ場合、差異が非常に大きくなることがあります。

  2. 統計対象の「キー / プロジェクト」が一致するか

    • 同じクラウドアカウントの下で、複数のプロジェクト/アプリケーションが1つのAPIキーを共有している可能性があります。
    • Difyはこれらの呼び出しの1つのソースに過ぎません。
    • クラウドベンダーのコンソールに表示されるのは「そのキー下のすべてのアプリケーションの総量」です。

  3. 複数のモデル、複数のリージョン

    • Difyでは特定のアプリ / 特定のモデルしか見ていない可能性があります。
    • クラウドベンダーのコンソールでは、すべてのモデル、すべてのリージョンが統計されます。

3. 技術実装上の差異

  1. トークナイザーの実装の違い

    • Difyはトークンを予測するために、ローカルで実装されたトークナイザーを使用している可能性があります。
    • クラウドベンダーは課金に公式のトークナイザーを使用しています。
    • 異なる実装では、中国語の句読点、絵文字、特殊文字の分割ルールがわずかに異なる場合があります → わずかな偏差（通常は数パーセント以内）は正常です。

  2. リトライ / タイムアウト / ストリーミングの中断

    • Difyが「失敗時の自動リトライ」を設定している場合、ユーザーの1回の質問がバックエンドで複数回のモデル呼び出しをトリガーする可能性があります。
      • Difyの使用量：すべての呼び出しを計上します。
      • これらの呼び出しはクラウドベンダー側でも課金されますが、「成功した応答」としてのみ理解している場合、Difyの統計が多いと感じるかもしれません。
    • ストリーミング出力が途中で中断された場合、Difyは受信したトークンを記録する可能性がありますが、クラウドベンダー側ではその呼び出しが完全に課金されている場合があります。

  3. キャッシュ（Cache）メカニズム

    • 特定のキャッシュメカニズム（例：アップストリームに独自のキャッシュ / プロキシがある場合）を有効にしている場合、次のような状況が発生する可能性があります。
      • Difyはリクエストを送信し、プロンプトの長さに応じてトークンを予測したと見なします。
      • 実際には、アップストリームのクラウドベンダーはキャッシュヒットにより実際に課金しなかったか、課金が0でした。
    • これにより、「Dify > クラウドベンダー」という状況が発生する可能性があります。

4. よくある判断方法

以下の手順で簡単に検証できます。

  1. 非常に短い時間枠で比較する
    例えば、最近10分以内に、1つのアプリケーション、1つのモデルのみを操作し、2～3回の簡単な会話を行い、その後：

    • Difyのバックエンドでこれらのリクエストの合計トークン数を確認します。
    • クラウドベンダーのコンソールで同じ時間帯のそのAPIキーのトークン使用量を確認します。
    • 差異がどの程度か（数パーセントか、数倍か）を確認します。

  2. エンベディング / ナレッジベース / その他のモデルが含まれているか確認する

    • ナレッジベース、リランクモデル、ツール呼び出しを使用している場合は、クラウドベンダーのコンソールで該当するモデルの使用量統計をすべて合計してからDifyと比較することをお勧めします。

  3. タイムゾーン、期間、プロジェクト/キーが正確に対応しているか確認する

    • タイムゾーンをUTCまたは北京時間（JST）に統一します。
    • 他に同じキーを使用しているシステムがないか確認します。

5. 差異が非常に大きい場合（例えば2～3倍以上）

さらに以下の点を確認できます。

  • Difyのバージョン番号（多くの統計ロジックは後で修正されています）：
    • 「設定 / バージョン情報」またはdocker-composeでイメージタグを確認します。
  • プロキシゲートウェイ（APISIX、Kong、自作リバースプロキシなど）が設定されているか：
    • プロキシがリトライを実行したり、リクエストボディを変更したりする場合があります。
  • Difyのいくつかの典型的な呼び出しの詳細ログを確認します。
    • リクエストプロンプトの具体的な文字数。
    • モデルが返すusageフィールド（一部のクラウドベンダーはused_tokensを直接返します）。
    • Difyが記録したusageと一致するか。

もしよろしければ、いくつかの情報を補足していただければ、より具体的に分析できます。

  1. どのクラウドベンダーとどのモデルを使用していますか？（例：OpenAI gpt-4.1 / アリババ通義 / テンセント混元など）
  2. Difyはクラウド版ですか、それとも自己ホスト型ですか？おおよそのバージョン番号はいくつですか？
  3. 差異は「少し多い」（例：10～20%）ですか、それとも「倍増」ですか？
  4. ナレッジベース / エンベディング / リランクなどの機能を使用していますか？

これらの情報に基づいて、通常の統計基準の差異なのか、統計バグや設定の問題に遭遇している可能性があるのかを大まかに判断できます。

4

はい、フォーラムも一例です。例えば、バックエンドでカスタムモデルを設定する際、統計を容易にするために、カスタムのトークナイザーと価格設定のオプションも提供されています。

IMG_9906
IMG_99061179×1929 170 KB

IMG_9907
IMG_99071179×1982 158 KB

@Dify_Forum_Helper

5

あなたの2枚の図は非常によく説明されており、実際には重要なポイントに触れています：

  • Difyのバックエンドでのトークン/料金統計は、あなたが「カスタムモデル」で設定したトークナイザー（tokenizer）とプライシング（pricing）に基づいて「自己見積もり」されたものです。
  • クラウドベンダーのバックエンドでの統計は、クラウドベンダーが自身の実際の課金ルールに基づいて算出したものです。

これら両方の設定やアルゴリズムが完全に一致しない限り、数字が合わないという事態が発生します。

以下では、それらの関係と、いかにして可能な限り整合させるかについて、いくつかのセクションに分けて説明します。

1. カスタムモデルのトークナイザーは何をするものですか？

あなたのスクリーンショットにあるドロップダウンリスト（AnthropicTokenizer / GeminiTokenizer / Llama3Tokenizer / MistralTokenizer / OpenAiTokenizer / QwenTokenizer…）は本質的に：

Difyに伝える：「このリクエストのトークンは、どの分詞方法で数えるべきか」

ベンダー/モデルによって分詞ルールが異なります。例えば、同じ中国語の文章でも：

  • OpenAIのtiktokenでは50トークンに分割される可能性があります
  • Qwenのトークナイザーでは60トークンに分割される可能性があります
  • 一部のクラウドベンダーでは、文字数またはリクエスト回数で課金され、「トークン」という概念と1対1で対応しない場合もあります

Difyはベンダーのトークン計算方法を可能な限りシミュレートすることしかできないため、一般的なトークナイザーを多数提供しています。
ここでトークナイザーを間違って選択すると、Difyが算出したトークン数は、必然的にクラウドベンダーのバックエンドと一致しなくなります。

2. プライシング（単価）設定はどのような役割を果たしますか？

カスタムモデル内の：

  • Input cost
  • Cached input cost / Cache write cost
  • Output cost

これらはすべて**「100万トークンあたり何ドル課金されるか」**の設定です。Difyは以下を使用します：

（Difyが統計した入力/出力トークン）×（あなたが入力した単価）

このモデル呼び出しのおおよその費用を見積もり、バックエンドで「コスト/使用量レポート」を確認できるようにします。

したがって、Difyのレポートをクラウドベンダーの請求書に大まかに近づけるには：

  1. トークナイザーは、クラウドベンダーが実際に課金に使用するトークナイザーと可能な限り一致させる必要があります。
  2. 単価は、クラウドベンダーの公式ドキュメントに記載されている価格と1対1で対応させて入力する必要があります。
  3. また、一部のベンダーには「キャッシュヒット」「コンテキスト圧縮」などの特殊な価格（cached input / cache write）があることにも注意が必要です。

3. 設定が正しくても、なぜ差異が生じるのですか？

たとえ：

  • 対応するトークナイザーを正しく選択したとしても（例えばOpenAIモデルにはOpenAiTokenizerを選択する）；
  • 単価もクラウドベンダーのドキュメントに従って設定したとしても；

それでも偏差が生じる可能性があり、その理由は以下の通りです：

  1. クラウドベンダーが返すusageは「実際の課金トークン」、Difyは「ローカルで再計算」

    • 一部のモデルの実際の課金ロジックには、内部圧縮/特殊トークン処理が含まれています。
    • Difyのトークナイザーの実装は「公開されているルールのおおよその実装」であり、ほとんどの場合非常に近いですが、100%同じであることは不可能です。

  2. すべての「隠れた」コンテンツが含まれているか

    • クラウドベンダーは、システムプロンプト、ツール呼び出し、フォーマットされた履歴会話などをすべて課金します。
    • Difyの特定のバージョンや特定のノードでは、主要なモデル呼び出しのみをカウントし、結果としてわずかに低くなる可能性があります。

  3. リトライ / 失敗した呼び出し

    • Difyのネットワークが不安定な場合や429エラーが発生した場合、リトライすることがあります。
    • クラウドベンダーは、すべてのリクエストをトークンとしてカウントします。
    • Difyのアプリケーション統計は最終的な1回のみを記録する可能性があり、クラウドベンダーの数字の方が大きく見えるでしょう。

したがって、「小範囲で大まかに一致させる」ことが現実的な目標であり、100%一致させることは多くの場合非現実的です。

4. 実際の提案：両方の数字を「近づける」方法

あなたが今フォーラムの例を挙げたということは、自社構築/拡張シナリオで既にカスタムモデルを設定していることを示しています。以下の手順で「校正」を行うことができます：

  1. モデルとトークナイザーが1対1で対応していることを確認する

    • OpenAIモデルを使用 → OpenAiTokenizerを選択
    • Anthropic Claudeを使用 → AnthropicTokenizerを選択
    • 通義千問を使用 → QwenTokenizerを選択
    • その他のクラウドベンダー（専用のオプションがない場合）：
      • OpenAIプロトコル/tiktokenとの互換性を宣言しているかを確認し、もしそうであれば、OpenAiTokenizerを近似として選択できます。
      • 完全にカスタムの課金方法（文字数/呼び出し回数）の場合、Difyのトークン統計は「参考値」としてのみ機能します。

  2. 公式ドキュメントから価格をコピーして入力する

    • 項目ごとに対応させる：
      • Input cost → プロンプト/入力トークンの単価
      • Output cost → 完了トークンの単価
      • Cached / cache write → そのモデルに「キャッシュ課金」に類似するものがある場合（典型的なのは新しいモデルやキャッシュ機能を有効にしている場合）、ドキュメントに従って入力します。ない場合は0のままにするか、空欄にしてください。

  3. 「小規模なサンプル照合」を行う

    • シンプルなテストアプリケーション/ワークフローを作成し、この1つのモデルのみを呼び出し、固定プロンプトで10回程度呼び出します。
    • 比較対象：
      • その期間におけるクラウドベンダーのコンソールでの当該モデルのusage/費用；
      • Difyバックエンドのトークン＆コストレポート；
    • 偏差が5～10%以内であれば、一般的に妥当な範囲と見なせます。
    • 1倍以上の差がある場合は、以下の点を調査する必要があります：
      • 他のシステムも同じクラウドベンダーキーを使用しているか；
      • クラウドベンダーに計上されているが、Difyのフロントエンドでは確認できない大量の失敗/リトライ呼び出しがあるか。

  4. チームへの説明を明確にする

    • チーム内で以下のように取り決めることができます：
      • Difyバックエンドの統計は、主にアプリケーション全体の利用状況/制御戦略（レート制限など）を監視するために使用します。
      • 実際の決済コストは、クラウドベンダーの請求書を基準とします。
    • 同時に、カスタムトークナイザー + プライシングを使用して両者を「おおよその桁数に合わせ」、運用と財務の両方が受け入れられるようにします。

5. あなたの元の質問に戻る

「Difyバックエンドのトークン統計とクラウドベンダーの統計が異なるのはなぜですか？」

あなたが今追加したスクリーンショットと合わせて、一言でまとめると：

Difyバックエンドの使用量は、あなたが「カスタムモデル」で選択したトークナイザーと設定した価格で自己計算された見積もり値であり、クラウドベンダーのバックエンドは実際の課金値です。
トークナイザーまたは課金ルールに何らかの不一致があれば差異が生じ、「正常な現象」です。正しいトークナイザーと価格を選択することで大幅に差を縮めることはできますが、完全に一致させることは困難です。

もしよろしければ、現在どのクラウドベンダー、どのモデルを使用しているか、そしてカスタムモデルでどのトークナイザーを選択し、どのような価格を入力したかを教えていただければ、公式価格表に基づいてより正確な設定アドバイスを一緒に作成できます。

6

はい、実際には、Difyは他の強力なLLM統計ツールに直接リンクすることもできます。詳細については、Enhance LLM Application observability on Dify with LangSmith and Langfuse - Dify Blog を参照してください。@Dify_Forum_Helper

Powerful LLM application observability tools
Powerful LLM application observability tools814×2232 167 KB

Dify Monitoring
Dify Monitoring458×574 22.2 KB

7

はい、あなたが補足したこの2点は、「なぜ統計が異なるのか」というエコシステム全体を明確に説明しています。後続の人々が全体像を把握しやすいように、ロジックを整理し直しましょう。

1. Dify自身の統計：より「製品内視点」

  • 「モデルプロバイダー / カスタムモデル」で tokenizer + pricing を設定すると、Difyは以下を計算できます。
    • 各呼び出しの推定トークン数（estimated tokens）
    • アプリケーション / ワークフロー / テナントの次元での概算コスト
  • この統計は、よりアプリケーション内運用視点に近いです。
    • どのアプリケーションが最もコストがかかるか、どのノードが最も重いか、どのユーザー/APIキーが最も多く呼び出しているか。
    • レート制限（限流）、クォータ（限額）、コスト予測、A/B比較意思決定に利用されます。

しかし、それは本質的に「概算」です。

  • あなたが選択したtokenizerに依存します。
  • 手入力または組み込みの料金表に依存します。
  • さらに、「リトライ/失敗/中間ノードを含むか」といった戦略が重ねられます。

2. Langfuse / LangSmithなどの外部LLM観測ツール：より「エンジニアリング+運用視点」

あなたの図にあるモニタリング統合（Langfuse、LangSmith、Opik、mlflow、Databricks、W&B、Arize、Alibaba Cloud Monitor、Tencent Cloud APMなど）は、別の層の問題を解決します。

「いくつのトークン/いくらのお金を使ったか」だけでなく、「どの呼び出し」「どのプロンプト」「どのパス」で具体的に何が起こったかを知る必要があります。

典型的な機能は以下の通りです。

  • 完全なトレース（Trace）：リクエストチェーン、各ノードの入出力、モデル選択、所要時間。
  • より詳細なトークンとコスト分析：
    • 一部のツールは、モデルが返すusageフィールドを直接読み取ります。
    • 独自のtokenizer / コストモデルも持ち、Difyの概算と相互に比較できます。
  • 品質評価：自動/手動スコアリング、再生、回帰テスト、RAG品質評価など。

これらはDifyのバックエンド統計を置き換えるものではなく、**並行する「第二の視点」**であり、R&D、SRE、データチームが詳細な分析を行うのに適しています。

3. 3つの数字をどう理解するか：Dify vs クラウドプロバイダー vs 観測プラットフォーム

もし、このチェーンを次のように考えるなら：

ユーザー → Difyアプリケーション（内部に独自のトークンとコスト概算がある）
→ 観測プラットフォーム（Langfuse / LangSmithなどがトレーシング+評価を行う）
→ モデルクラウドプロバイダー（OpenAI / Alibaba Cloud / Tencent Cloudなどが最終的な課金を行う）

その3つの場所で見られるusage / token / costは：

  1. クラウドプロバイダー：最終的な実際の請求書であり、財務はこの請求書を基準とする必要があります。
  2. Difyバックエンド：
    • 「アプリケーション/ワークフロー」を中心とした視点で、可視性と運用性を重視します。
    • カスタムtokenizerとpricingを追加することで、クラウドプロバイダーと「同レベルの桁数合わせ」が可能です。
  3. Langfuse / LangSmithなど：
    • 「呼び出しチェーン / トレース / 実験」を中心とした視点です。
    • プロンプト、パス、モデル選択の最適化を支援し、さらに詳細なトークンとコストの統計を提供します。

実際には、これら3つの数字は完全に一致することはありません。より推奨される使い方は以下の通りです。

  • 請求書照合 / コスト決済：クラウドプロバイダーを基準とします。
  • 製品運用 / ユーザー割り当て / アプリケーションランキング：Difyの組み込み統計を参照するだけで十分です。
  • デバッグ / 診断 / 品質とパフォーマンスの向上：Langfuse / LangSmithなどでトレース、メトリクス、評価を確認します。

4. あなたの元の質問に対する一言まとめ

なぜDifyのバックエンドトークンはクラウドプロバイダーと異なるのか？

さらに掘り下げて言うと：

  • Difyが提供するのは「設定可能な、製品内の概算視点」であり、tokenizer + pricingを通じてクラウドプロバイダーに近づけることができます。
  • クラウドプロバイダーが提供するのは「最終決済視点」です。
  • Langfuse / LangSmithなどは「エンジニアリングと観測視点」を提供し、これらの差異がどこから来るのかを理解し、アプリケーションを反復開発するのに役立ちます。

あなたが引用したブログ記事もこの点を指摘しています。
Difyは基本的な統計機能を備えており、LangSmith / Langfuseはよりきめ細かなコストとトークンの分析およびLLMOps機能を提供するため、両者は補完関係にあります。

もし今後、本番環境でこれら3つの統計の利用方法を統一する予定がある場合（例えば、ビジネス部門に統一レポートを提供するなど）、製品、エンジニアリング、財務がそれぞれどの層を参照し、差異をどのように説明するかについて、「定義の合意 + 照合プロセス」を設計するお手伝いができます。

9

@Dify_Forum_Helper まとめを作成してください

10

好、この投稿について「一目でわかる」まとめを作成し、後から来る人が素早く理解できるようにします。

一言でまとめると

DifyのバックエンドでのToken / コスト統計は、設定したtokenizer + 料金表に基づいた見積もりです。
クラウドプロバイダーのコンソールは、実際の課金ルールに基づいて計算されます。
さらに、「統計範囲」「時間枠」「再試行/キャッシュの有無」などの違いが重なります。
両方の数字が完全に一致しないのは常態であり、桁が近い限りは正常と見なされます。

一、Difyとクラウドプロバイダーの数字が一致しないのはなぜですか？

3つの層で理解できます。

1. 統計の「計算方法」の違い（定義の差）

1）Dify：自身でトークンを数え + 自身で費用を計算

  • 「モデルプロバイダー / カスタムモデル」で以下を選択します。

    • どのtokenizer（OpenAiTokenizer / QwenTokenizer / AnthropicTokenizer…）
    • 100万トークンあたりの単価（input / output / cached input / cache write…）

  • Difyは以下を使用します。

    ローカルのtokenizerで数えられたトークン数 × 入力した単価

    これにより、「見積もり使用量 & 見積もりコスト」が算出されます。

2）クラウドプロバイダー：内部の実際のロジックに基づいて課金

  • 独自のtokenizer / 圧縮ポリシー / キャッシュ課金などを使用します。
    • 同じテキストでも、トークン数はDifyの実装と若干異なる場合があります。
    • 一部のプロバイダーは文字数やリクエスト数で課金することもあり、トークンとは1:1ではありません。

→ Difyで「正しい」tokenizerを選択し、料金も公式サイトからコピーしたとしても、本質的には「可能な限り近い」見積もりに過ぎません。

2. 統計の「何を計算するか」の違い（範囲の差）

  • クラウドプロバイダーは以下をすべて課金します。

    • system / user / tools / 過去の会話
    • モデル出力
    • 可能性のある再試行リクエスト

  • Difyの異なるビュー/バージョンでは、以下の可能性があります。

    • メインモデル呼び出しのトークンのみを表示
    • 一部の中間ノード（ツールノード、サブワークフロー、RAGリコール、embedding、rerank）は、現在見ているレポートに含まれていません。
    • 失敗したリクエスト、再試行、ストリーミング中断に対するカウント戦略が異なります。

したがって、一般的な現象としては、以下が挙げられます。

  • クラウドプロバイダーのusage > Dify：クラウドプロバイダーは再試行/失敗/全量のコンテキストをすべて含めて計算しています。
  • Difyがクラウドプロバイダーより大きい場合もあります：例えば、プロンプトに基づいてトークンを見積もったが、上流でキャッシュがヒットした場合、実際の課金は0になる可能性があります。

3. 統計の「いつ、どこを見るか」の違い（時間枠 & ディメンションの差）

  • 時間範囲の違い
    • Difyでは「過去24時間 / カスタム日付」を選択できます。
    • クラウドプロバイダーは通常「UTCの当日 / 当月」で集計されます。
  • 範囲のディメンションの違い
    • Dify：特定のアプリ / ワークフロー / テナント
    • クラウドプロバイダー：アカウント全体 / プロジェクト / API Key、同じキーを使用している他のサービスがある可能性もあります。

→ 時間帯、モデル、キーの範囲が完全に一致していない場合、それらを一つ一つ照合することは困難です。

二、カスタムモデルの2つの図は、実際に何を示しているのか？

あなたのスクリーンショットにある2つの主要な設定：

  1. Tokenizerドロップダウンリスト
    決定：Difyがどの分詞ルールセットを使用して、プロバイダーの課金基準を「シミュレート」するか。

    • OpenAIシリーズ → OpenAiTokenizerを選択
    • Claude → AnthropicTokenizerを選択
    • 通義千問 → QwenTokenizerを選択
    • OpenAIプロトコルと互換性のあるその他のものは、まずOpenAiTokenizerで近似できます。

  2. Pricing（input / output / cached / cache write cost）
    決定：これらのトークンがいくらのお金に換算されるか。

    • クラウドプロバイダーのドキュメントにある：プロンプト単価、完了単価、キャッシュ関連単価に対応します。

この2つのうちいずれか一つでもクラウドプロバイダーのルールと完全に一致しない場合：

  • Difyのトークン/コスト統計には、高低さまざまな偏差が生じます。
  • これは「正常な現象」であり、誰かが間違って計算したのではなく、「ルールと定義が異なる」ためです。

三、Langfuse / LangSmithなどの監視統合は何のためにあるのか？

参照：Enhance LLM Application observability on Dify with LangSmith and Langfuse - Dify Blog

このトピックでは、DifyとLangfuse / LangSmithなどのLLM観測プラットフォームとの統合についても触れられており、これらは3つ目の次元の問題を解決します。

単に「どれくらいのトークンを使ったか / いくら費用がかかったか」だけでなく、
「どの呼び出し、どのプロンプト、どのワークフローパスがこれらの費用を引き起こしたのか」を明確にする必要があります。

これらのプラットフォームは通常、以下を提供します。

  • Trace：呼び出しチェーン全体、各ノードの入出力、所要時間
  • より詳細なトークン/コスト：単一の呼び出し、特定のプロンプトバージョン、特定のブランチごとに確認できます。
  • 品質評価：リプレイ、スコアリング、A/Bテスト、RAG評価など。

したがって、3つの視点は次のように分担できます。

  1. クラウドプロバイダーのコンソール：

    • 実際の請求書 & コスト決済。

  2. Difyバックエンド（tokenizer + pricing）：

    • 「アプリ内運用」を行う：
      • どのアプリ / ワークフローが最もコストがかかるか
      • ユーザー / キーにクォータ、レート制限を設定
      • コストを見積もり、製品レベルの意思決定を行う。

  3. Langfuse / LangSmithなどの監視：

    • 「エンジニアリング & 運用 & 最適化」を行う：
      • どのステップでトークンを無駄にしているかを詳細に特定
      • プロンプト、ルーティング、RAG戦略をデバッグ。

四、後から来る人への実用的なアドバイス

Difyの統計とクラウドプロバイダーの統計を「可能な限り近づけたい」場合：

  1. カスタムモデルで：

    • tokenizerは、実際のモデルに可能な限り一致するものを選んでください。
    • 価格はクラウドプロバイダーの公式ドキュメントに従って項目ごとにコピーしてください（input / output / cachedなどを区別して）。

  2. 「小規模サンプルでの照合」を行う：

    • シンプルなアプリケーションを固定し、1日以内に数十回呼び出す
    • この期間中のDifyとクラウドプロバイダーのusageを比較する
    • 偏差が許容範囲内（例えば5～10%）であるかを確認します。

  3. 定義について統一的な合意を形成する：

    • 「財務はクラウドプロバイダーの請求書を基準とする；
      製品/運用はDifyバックエンドの使用量を見る；
      デバッグ & 最適化はLangfuse / LangSmithなどの監視を見る。」

こうすることで、「なぜ数字が異なるのか」について皆が理解し、それぞれどの統計を信頼すべきかを知ることができます。

今後、具体的なクラウドプロバイダー + モデル設定（例えば、特定のQwen / Claude / GPTモデル）がある場合は、現在Difyでどのように設定しているかを貼り付けていただければ、公式料金表に基づいてtokenizer & pricingをより合理的なものに調整するお手伝いができます。