Modèle personnalisé

Xinference offre un moyen flexible et complet d’intégrer, gérer et appliquer des modèles personnalisés.

Lancer un modèle personnalisé sans inscription

À partir de la version v0.14.0, si la famille du modèle que vous devez enregistrer est prise en charge en natif par Xinference, vous pouvez directement le lancer via le paramètre model_path de l’interface launch, évitant ainsi les tracas de l’étape d’enregistrement. Cette méthode est désormais fortement recommandée.

Par exemple :

shellcURLPython

xinference launch --model-path <model_file_path> --model-engine <engine> -n qwen1.5-chat

L’exemple ci-dessus montre comment lancer directement le modèle qwen1.5-chat lorsque j’en possède déjà les fichiers.

Pour un scénario distribué, placez votre fichier de modèle sur un worker, puis utilisez les paramètres worker_ip et model_path de l’interface launch pour obtenir un effet de lancement direct.

Note

Pour l’utilisation de l’interface en ligne de commande (CLI), veuillez privilégier --model-path (format séparé par des points-virgules, mélange de majuscules et minuscules). --model_path est compatible avec l’ancienne norme, mais son utilisation est déconseillée.

Définir un modèle personnalisé

Web UI : Analyse automatique de la configuration du grand modèle de langage

Ajouté dans la version v2.0.0.

Lors de l’enregistrement d’un LLM personnalisé via l’interface Web, Xinference peut analyser automatiquement la configuration du modèle et pré-remplir les champs clés pour vous.

Vous avez seulement besoin de fournir :

• Chemin du modèle / ID du modèle (emplacement du modèle, chemin local ou ID central)

• Famille de modèles

Après analyse, l’interface utilisateur peut remplir automatiquement les champs suivants :

• Longueur du contexte

• Modèle de langage

• Capacité du modèle

• Spécifications du modèle

Avant de sauvegarder le modèle personnalisé, vous pouvez consulter et modifier ces champs.

Définissez un modèle personnalisé sur le modèle suivant :

LLMembeddingRerankimageaudioflexible

{
    "version": 2,
    "context_length": 32768,
    "model_name": "custom-qwen-2.5",
    "model_lang": [
        "en",
        "zh"
    ],
    "model_ability": [
        "generate"
    ],
    "model_description": "This is a custom model description.",
    "model_family": "my-custom-qwen-2.5",
    "model_specs": [
        {
            "model_format": "pytorch",
            "model_size_in_billions": "0_5",
            "quantization": "none",
            "model_id": null,
            "model_hub": "huggingface",
            "model_uri": "file:///path/to/models--Qwen--Qwen2.5-0.5B",
            "model_revision": null,
            "activated_size_in_billions": null
        }
    ],
    "chat_template": null,
    "stop_token_ids": null,
    "stop": null,
    "reasoning_start_tag": null,
    "reasoning_end_tag": null,
    "cache_config": null,
    "virtualenv": {
        "packages": [],
        "inherit_pip_config": true,
        "index_url": null,
        "extra_index_url": null,
        "find_links": null,
        "trusted_host": null,
        "no_build_isolation": null
    },
    "is_builtin": false
}

• model_name : le nom du modèle. Le nom doit commencer par une lettre ou un chiffre, et ne peut contenir que des lettres, des chiffres, des underscores ou des tirets.

• context_length : un entier optionnel, la longueur maximale de contexte prise en charge par le modèle, y compris la longueur des entrées et des sorties. Si non défini, la valeur par défaut est de 2048 tokens (environ 1 500 mots).

• dimensions : un entier, utilisé pour définir la taille du vecteur de sortie du modèle d’embedding.

• max_tokens : un entier définissant le nombre maximum de tokens d’entrée que le modèle d’embedding peut traiter en une seule requête.

• model_lang : une liste de chaînes de caractères indiquant les langues prises en charge par le modèle. Par exemple : [“en”] , cela signifie que le modèle prend en charge l’anglais.

• model_ability: une liste de chaînes de caractères définissant les capacités du modèle. Elle peut inclure des options telles que “embed”, “generate” et “chat”. L’exemple indique que le modèle possède la capacité “generate”.

• model_family : une chaîne de caractères obligatoire indiquant la famille de modèles à enregistrer. Ce nom de paramètre ne doit pas entrer en conflit avec aucun nom de modèle intégré.

• model_specs : un tableau d’objets contenant les spécifications de définition du modèle. Ces spécifications incluent :

  • model_format : une chaîne définissant le format du modèle, qui peut être “pytorch” ou “ggufv2”.

• model_size_in_billions : un entier définissant le nombre de paramètres du modèle, en milliards.

• quantizations: Une liste de chaînes de caractères définissant les méthodes de quantification du modèle. Pour un modèle PyTorch, cela peut être « 4-bit », « 8-bit » ou « none ». Pour un modèle ggufv2, la méthode de quantification doit correspondre à la valeur dans model_file_name_template. Certains moteurs prennent également en charge les formats fp4 / fp8 / bnb (pour plus de détails sur la prise en charge du backend, voir Installation).

  • model_id : chaîne de caractères représentant l’identifiant du modèle, qui peut être l’ID du dépôt HuggingFace correspondant à ce modèle. Si le champ model_uri est absent, Xinference tentera de télécharger le modèle depuis le dépôt HuggingFace indiqué par cet ID.

  • model_hub : une chaîne facultative indiquant d’où télécharger le modèle, par exemple HuggingFace ou modelscope.

  • model_uri : chaîne de caractères indiquant l’emplacement du fichier modèle, par exemple un répertoire local : « file:///chemin/vers/llama-2-7b ». Lorsque model_format est ggufv2 , ce champ doit contenir le chemin exact du fichier modèle. Lorsque model_format est pytorch , ce champ doit être un répertoire contenant tous les fichiers du modèle.

  • model_revision : une chaîne de caractères indiquant la version spécifique ou le hash de commit du fichier de modèle utilisé depuis le dépôt.

• chat_template: Si model_ability contient chat, alors cette option doit être configurée pour générer une invite complète appropriée. Il s’agit d’une chaîne de modèle Jinja. Généralement, vous pouvez la trouver dans le fichier tokenizer_config.json du répertoire du modèle.

• stop_token_ids : Si model_ability inclut chat, il est recommandé de configurer cette option pour contrôler raisonnablement l’arrêt de la conversation. Il s’agit d’une liste contenant des entiers, dont vous pouvez extraire les valeurs correspondantes dans les fichiers generation_config.json et tokenizer_config.json du répertoire du modèle.

• stop : Si model_ability contient chat, il est recommandé de configurer cette option pour contrôler raisonnablement l’arrêt des dialogues. Il s’agit d’une liste contenant des chaînes de caractères, vous pouvez trouver la chaîne correspondant à la valeur du token dans le fichier tokenizer_config.json du répertoire du modèle.

• reasoning_start_tag : un token ou prompt spécial utilisé pour indiquer clairement au grand modèle de langage le point de départ de la chaîne de pensée ou du processus de raisonnement dans sa sortie.

• reasoning_end_tag : un token ou prompt spécial, utilisé pour indiquer clairement à un modèle de langage de grande taille le point de terminaison de la chaîne de pensée ou du processus de raisonnement dans sa sortie.

• cache_config: une chaîne de caractères représentant le paramètre du système pour le stockage et la gestion des données temporaires (cache).

• virtualenv: A settings object for model dependency isolation. Please refer to this document for details.

Enregistrer un modèle personnalisé

Enregistrer un modèle personnalisé par le code.

import json
from xinference.client import Client

with open('model.json') as fd:
    model = fd.read()

# replace with real xinference endpoint
endpoint = 'http://localhost:9997'
client = Client(endpoint)
client.register_model(model_type="<model_type>", model=model, persist=False)

En mode ligne de commande

xinference register --model-type <model_type> --file model.json --persist

Remplacez <model_type> dans la partie suivante par LLM, embedding ou rerank.

Liste des modèles intégrés et personnalisés

```python # Exemples de modèles intégrés et personnalisés

registrations = client.list_model_registrations(model_type="<model_type>")

En mode ligne de commande

xinference registrations --model-type <model_type>

Démarrer un modèle personnalisé

Lancement d’un modèle personnalisé via le code

uid = client.launch_model(model_name='custom-llama-2', model_format='pytorch')

En mode ligne de commande

xinference launch --model-name custom-llama-2 --model-format pytorch

Utilisez un modèle personnalisé

Appeler le modèle par code

model = client.get_model(model_uid=uid)
model.generate('What is the largest animal in the world?')

Le résultat est :

{
   "id":"cmpl-a4a9d9fc-7703-4a44-82af-fce9e3c0e52a",
   "object":"text_completion",
   "created":1692024624,
   "model":"43e1f69a-3ab0-11ee-8f69-fa163e74fa2d",
   "choices":[
      {
         "text":"\nWhat does an octopus look like?\nHow many human hours has an octopus been watching you for?",
         "index":0,
         "logprobs":"None",
         "finish_reason":"stop"
      }
   ],
   "usage":{
      "prompt_tokens":10,
      "completion_tokens":23,
      "total_tokens":33
   }
}

Ou en ligne de commande, en remplaçant ${UID} par l’UID réel du modèle :

xinference generate --model-uid ${UID}

Supprimer le modèle personnalisé

Désenregistrer un modèle personnalisé par code.

model = client.unregister_model(model_type="<model_type>", model_name='custom-llama-2')

En mode ligne de commande

xinference unregister --model-type <model_type> --model-name custom-llama-2