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

議論
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をより合理的なものに調整するお手伝いができます。