Pour utiliser Kimi K2 dans SillyTavern, connectez l’interface à un backend séparé qui sert un checkpoint K2 précisément identifié. SillyTavern prépare le contexte et les messages, mais n’héberge pas le modèle. Vérifiez la version, choisissez un serveur local ou un fournisseur documenté, puis testez une requête simple avant d’ajouter du contexte de jeu de rôle.
Ce guide couvre Kimi-K2-Instruct et une mise à jour K2 seulement si le backend identifie explicitement ce checkpoint. Il ne donne pas de procédure propre à un fournisseur : aucun endpoint hébergé, alias API, prix, quota ou état de disponibilité actuel n’a été vérifié. Le contenu reste un brouillon tant qu’une connexion réelle n’a pas été reproduite.
À retenir
SillyTavern est le client ; un autre backend doit exécuter Kimi K2.
Vérifiez le checkpoint exact, sa révision, sa quantification et son template. La page officielle pointe vers les poids Kimi-K2-Instruct-0905 ; ne mélangez pas les configurations.
L’identifiant Hugging Face n’est pas forcément l’alias API du fournisseur.
Chat Completions et Text Completions décrivent la construction du prompt, pas le choix local/cloud.
Testez séparément la connexion, le modèle, le template et une courte conversation. Aucun backend K2 réel n’a été testé ici.
Les couches de connexion
| Élément | Rôle | À vérifier |
|---|---|---|
| Checkpoint | Fournit les poids et le comportement du modèle | Variante, révision, quantification, licence et template |
| Serveur d’inférence | Charge le modèle et expose une API | Format, version, route, adresse et gestion du template |
| Fournisseur hébergé | Exécute le modèle à distance | Modèle, ID, clé, limites, prix, contexte et traitement des données |
| SillyTavern | Prépare le contexte et envoie la requête | Type d’API et paramètres documentés par le backend |
Une connexion réussie montre seulement que l’endpoint répond. Elle ne prouve ni le checkpoint chargé, ni le template, ni la cohérence sur une longue session.
1. Vérifier le checkpoint
Commencez par la fiche officielle Kimi K2-Instruct, pas par un ancien preset. Elle montre des exemples de service local avec vLLM et SGLang et renvoie à Kimi-K2-Instruct-0905. La page du projet Kimi K2 indique que la mise à jour 0905 modifie les poids et le contexte. Notez le nom et la révision, la quantification, le runtime pris en charge, la couche qui applique le template et l’identifiant attendu par les requêtes.
Les exemples officiels exposent une interface de chat completions compatible OpenAI. Cela ne prouve pas qu’un fournisseur quelconque utilise le même endpoint ou ID. La compatibilité de protocole ne garantit pas les mêmes fonctions, limites, politiques ou résultats.
N’utilisez pas les instructions K2.5, K2.6, K2.7 Code, K2.8 ou K3 pour compléter celles du K2 initial. Consultez séparément Kimi K2.6, Kimi K3 pour SillyTavern et la configuration K3 ; leurs valeurs ne sont pas des presets K2.
\nD’autres guides montrent des parcours distincts ; leurs identifiants et presets ne sont pas interchangeables avec K2. Consultez Mistral 24B, DeepSeek V4 Flash, GLM-5.3 et Gemma 4 pour d’autres modèles. Kimi K3 roleplay concerne une autre génération.\n
2. Choisir un serveur local ou un fournisseur
| Voie | Pour qui | À vérifier dans la documentation actuelle | Inconnu ici |
|---|---|---|---|
| Serveur local | Vous contrôlez le runtime et l’endpoint | Checkpoint, moteur, template et matériel | Pas d’installation ni de test mémoire/vitesse |
| Fournisseur hébergé | Le catalogue nomme le checkpoint voulu | ID, URL, clé, limites, prix, contexte et données | Aucun fournisseur K2 n’a été ouvert et testé |
| Web/App Kimi | Vous voulez seulement son interface | Existence d’une API distincte documentée | Une offre grand public ne prouve pas l’accès API |
En local, vous gérez les fichiers, le matériel et les mises à jour. En hébergé, le fournisseur gère le service mais fixe ses conditions et instructions. Les exemples de la fiche ne dimensionnent pas une machine : quantification, contexte, mémoire et runtime changent le besoin. Ne déduisez pas la configuration à partir du nombre de paramètres actifs.
Pour un fournisseur, consultez le catalogue et le guide de connexion en cours. Si le checkpoint, le format de requête, le champ d’authentification ou l’ID ne sont pas documentés, arrêtez-vous au lieu de deviner.
3. Connecter selon le contrat du backend
La documentation API Connections de SillyTavern précise que Chat Completions sépare les messages par rôle tandis que Text Completions les assemble en texte continu. Ce choix détermine la construction du prompt, pas l’hébergement local ou cloud.
Démarrez le serveur avec les instructions du checkpoint et du runtime choisis, puis attendez son message de disponibilité.
Dans API Connections, sélectionnez le type documenté pour ce backend. La compatibilité OpenAI seule ne permet pas de déduire l’option ou le chemin exact.
Saisissez URL et identifiant dans les champs prévus, à partir des docs actuelles. Ne placez jamais la clé dans une fiche, note, capture ou preset partagé.
Utilisez l’identifiant accepté par le backend ; il peut différer du dépôt Hugging Face.
Déterminez si le serveur ou SillyTavern applique le template. Évitez le double formatage.
Conservez un profil de base avec checkpoint, date, type d’API et responsable du template, si votre version le permet. Le profil mémorise les choix, il ne les valide pas.
Les libellés changent selon les versions ; vérifiez les deux documentations. N’essayez pas une autre API au hasard avec une vraie clé.
Protéger clés et prompts privés
Traitez une clé API comme un mot de passe. Vérifiez qu’un profil ou une capture ne l’exporte pas et faites-la tourner si elle est exposée. Un endpoint local peut être joignable sur le réseau : suivez les réglages de liaison et de pare-feu et n’exposez pas un serveur sans authentification à Internet.
4. Faire un test court
Commencez par une phrase neutre, par exemple : « Réponds en une phrase pour confirmer que tu as reçu ce message. » Vérifiez qu’un texte normal revient. Ensuite, chargez une fiche simple, faites deux échanges, puis mentionnez un détail anodin du tour précédent. Cherchez des marqueurs de template, des rôles dupliqués, une réponse vide ou du texte inattendu. Deux tours ne prouvent pas une mémoire longue.
Ajoutez une couche à la fois : lorebook, note auteur, long message d’accueil ou extension. Une grande fiche peut dépasser le contexte réel ou supposer un autre template. Si le test court marche et la fiche complète échoue, comparez taille et format avant de changer la génération.
| Symptôme | Couche possible | Premier contrôle |
|---|---|---|
| Connexion impossible | Serveur/endpoint | État, URL, chemin, port et réseau |
| Erreur d’authentification | Clé/compte | Champ, validité et autorisations |
| Modèle inconnu | Identifiant | Alias backend contre ID HF |
| Réponse vide | Requête/serveur | Type API, route, journaux et limite de sortie |
| Marqueurs visibles | Template | Client et serveur formatent-ils tous deux ? |
| Répétition | Prompt/réglages | Doublons, lore, contexte et stop |
| Lenteur | Chargement/matériel/queue | Logs, quantification et longueur du prompt |
| Premier tour OK, puis échec | Contexte cumulé | Historique et activation du lore |
Notez checkpoint, versions serveur et SillyTavern, type API, dernier changement et erreur expurgée. Changez un paramètre à la fois. Les logs peuvent contenir du texte privé : examinez-les localement et ne partagez qu’un extrait minimal expurgé.
5. Évaluer le jeu de rôle après la connexion
Une requête API réussie ne mesure pas si le style vous convient. Gardez la même fiche, le même prompt, le contexte et les réglages pour comparer. Évaluez la voix du personnage, la progression de la scène sans contrôle du personnage utilisateur, le respect des limites et l’usage d’un détail récent. Notez un exemple et une limite ; une réponse plaisante n’est pas un score général.
Ne supposez pas qu’un preset K2.6, K3 ou autre modèle convient à K2. Si le backend publie des paramètres pour ce checkpoint exact, notez la source et testez-les après stabilisation de la connexion. Le guide séparé Kimi K2 roleplay porte sur le style.
Un espace de recherche pratique : Tabbit Browser
Vous pouvez garder ouvertes la fiche, les instructions du runtime et la documentation SillyTavern dans Tabbit Browser, puis noter quelle source définit chaque réglage. Tabbit n’a pas été testé avec un serveur K2 ; il n’héberge pas le modèle et ne remplace pas SillyTavern. Utilisez le backend pour l’inférence et SillyTavern pour le contexte. Tabbit ne valide pas les clés ni les endpoints.
Quelle voie choisir ?
| Situation | Étape suivante |
|---|---|
| Matériel compatible et besoin de contrôle | Suivez les docs du checkpoint et du runtime |
| API hébergée souhaitée | Attendez une doc qui nomme checkpoint et endpoint exacts |
| Seulement l’app web Kimi | Vérifiez l’existence d’une API séparée documentée |
| Connexion OK, style mauvais | Gardez les réglages et évaluez modèle/fiche séparément |
| Marqueurs visibles | Vérifiez quelle couche applique le template |
Kimi K2 peut se connecter à SillyTavern via un backend compatible qui sert le checkpoint exact. Vérifiez la version, suivez les sources du backend, testez un message simple puis une petite fiche. Si l’endpoint ou l’ID n’est pas documenté, ne les inventez pas.
Questions fréquentes
SillyTavern exécute-t-il Kimi K2 seul ?
Non. C’est une interface qui prépare les prompts et se connecte à un backend. Il faut un serveur local ou un service hébergé exposant le checkpoint voulu par une API compatible.
Quel ID Kimi K2 saisir ?
Utilisez celui que le backend indique pour le checkpoint ou déploiement exact. Le nom moonshotai/Kimi-K2-Instruct n’est pas nécessairement l’alias API.
Chat Completion ou Text Completion ?
Suivez le format du backend. SillyTavern s’en sert pour construire le prompt ; ce n’est pas une distinction local/cloud.
Kimi K2 peut-il tourner en local ?
La fiche officielle donne des exemples vLLM et SGLang. La faisabilité dépend du checkpoint, de la quantification, du matériel et du runtime ; aucune installation locale n’a été testée ici.
Pourquoi des réponses vides, des marqueurs ou des répétitions ?
Vérifiez endpoint et ID, puis déterminez qui applique le template. Réduisez le prompt et ajoutez le contexte progressivement avant de modifier les paramètres de génération.
Sources et statut
La fiche Kimi K2-Instruct, le projet Kimi K2 et la documentation SillyTavern ont été ouverts dans Tabbit le 2026-09-23. Fournisseur, connexion réelle, sortie, prix/disponibilité, captures communautaires et intégration Tabbit restent non vérifiés. Brouillon maintenu.
Questions fréquentes
SillyTavern exécute-t-il Kimi K2 ?
Non. Il faut un serveur local ou un fournisseur qui expose le checkpoint exact.
Quel identifiant saisir ?
Celui documenté par le backend ; l’ID HF peut différer de l’alias API.
Chat ou Text Completion ?
Suivez le format du backend ; ce choix ne distingue pas cloud et local.
Kimi K2 peut-il tourner en local ?
La fiche donne des exemples ; mémoire et vitesse dépendent du checkpoint et du matériel.
Que vérifier en cas de réponse vide ?
Endpoint, ID, connexion et couche de template, puis refaire un test court.