このドキュメントは AI によって自動翻訳されています。不正確な部分がある場合は、英語版 を参照してください。
カスタムモデル とは、自分でデプロイまたは設定する LLM を指します。このガイドでは、Xinference を例に、カスタムモデルを モデルプラグイン に統合する方法を説明します。
デフォルトでは、カスタムモデルは モデルタイプ と モデル名 の 2 つのパラメータを自動的に含むため、プロバイダー YAML ファイルで追加の定義は必要ありません。
プロバイダー設定ファイルに validate_provider_credential を実装する必要はありません。実行時、Dify はユーザーが選択したモデルタイプとモデル名に基づいて、対応するモデルレイヤーの validate_credentials メソッドを呼び出します。
カスタムモデルプラグインの統合#
カスタムモデルの統合は 4 つのステップに分かれます。
- モデルプロバイダーファイルの作成:カスタムモデルに含めるモデルタイプを特定します。
- モデルタイプごとのコードファイルの作成:モデルタイプ(例:
llmやtext_embedding)ごとに別々のコードファイルを作成します。各モデルタイプをそれぞれの論理レイヤーに保つことで、保守と今後の拡張が容易になります。 - モデル呼び出しロジックの開発:各モデルタイプモジュール内で、そのモデルタイプの名前を付けた Python ファイル(例:
llm.py)を作成します。ファイル内に、システムのモデルインターフェース仕様に準拠したモデルロジックを実装するクラスを定義します。 - プラグインのデバッグ:新しいプロバイダー機能のユニットテストと統合テストを作成し、すべてのコンポーネントが意図どおりに動作することを確認します。
1. モデルプロバイダーファイルの作成#
プラグインの /provider ディレクトリに、xinference.yaml ファイルを作成します。
Xinference ファミリーのモデルは LLM、Text Embedding、Rerank モデルタイプをサポートしているため、xinference.yaml にはこれら 3 つすべてを含める必要があります。
例:
次に、provider_credential_schema を定義します。Xinference はテキスト生成、エンベディング、リランキングモデルをサポートしているため、以下のように設定できます。
Xinference のすべてのモデルには model_name が必要です。
Xinference はローカルでデプロイされるため、ユーザーはサーバーアドレス(server_url)とモデル UID も指定する必要があります。
これでカスタムモデルプロバイダーの YAML 設定は完了です。次に、設定で定義した各モデルのコードファイルを作成します。
2. モデルコードの開発#
Xinference は llm、rerank、speech2text、tts をサポートしているため、/models 下に各タイプのディレクトリを作成し、それぞれに機能コードを含めます。
以下は llm タイプのモデルの例です。llm.py という名前のファイルを作成し、__base.large_language_model.LargeLanguageModel を拡張するクラス(例:XinferenceAILargeLanguageModel)を定義します。このクラスは以下のメソッドを実装する必要があります。
LLM 呼び出し#
LLM を呼び出すためのコアメソッドで、ストリーミングと同期応答の両方をサポートします。
ストリーミングと同期応答は、それぞれ別々の関数として実装します。Python は yield を含む関数を Generator を返すジェネレータとして扱うため、分離することで戻り値の型が明確になります。
入力 token の事前計算#
モデルが token カウントインターフェースを提供していない場合は、0 を返します。
または、AIModel 基底クラスから self._get_num_tokens_by_gpt2(text: str) を呼び出すこともできます。これは GPT-2 トークナイザーを使用します。これは近似値であり、モデルと正確に一致しない場合がある点に注意してください。
モデル認証情報の検証#
プロバイダーレベルの認証情報チェックと似ていますが、対象は単一のモデルに限定されます。
動的モデルパラメータスキーマ#
事前定義モデル とは異なり、モデルがサポートするパラメータを定義する YAML ファイルはないため、パラメータスキーマを動的に生成する必要があります。
例えば、Xinference は max_tokens、temperature、top_p をサポートしています。他のプロバイダー(例:OpenLLM)は、特定のモデルでのみ top_k などのパラメータをサポートする場合があるため、スキーマは各モデルの機能に合わせて適応させる必要があります。
エラーマッピング#
モデル呼び出し中にエラーが発生した場合、ランタイムの InvokeError タイプのいずれかにマッピングすることで、Dify が異なるエラーを統一的に処理できるようにします。
InvokeConnectionErrorInvokeServerUnavailableErrorInvokeRateLimitErrorInvokeAuthorizationErrorInvokeBadRequestError
インターフェースメソッドの詳細については、モデルドキュメント を参照してください。
このガイドで説明した完全なコードファイルは、GitHub リポジトリ を参照してください。
3. プラグインのデバッグ#
開発が完了したら、プラグインをテストして正しく動作することを確認します。詳細は以下を参照してください。
4. プラグインの公開#
プラグインを Dify マーケットプレイスに掲載するには、「Dify マーケットプレイスへの公開」を参照してください。
さらに探索#
クイックスタート:
プラグインエンドポイントドキュメント:
- マニフェスト 構造
- エンドポイント 定義
- Dify サービスの逆呼び出し
- ツール
- モデル