Kimi K3-256k

 (kimi.com)
1 points par GN⁺ 2 시간 전 | 1 commentaires | Partager sur WhatsApp
  • Kimi K3-256k est un modèle pour le codage au quotidien qui conserve la qualité des résultats de K3 dans un contexte de 256k, tout en consommant environ deux fois moins de quota que k3 avec un contexte de 1M
  • Kimi Code propose K3 et K2.7 Code via 4 ID de modèles ; k3 prend en charge 2,8T de paramètres et jusqu’à 1M de contexte, tandis que kimi-for-coding-highspeed offre une sortie environ 5 à 6 fois plus rapide au prix d’une consommation de quota multipliée par 3
  • Lors du passage de k3 à k3-256k, si le contexte existant dépasse 256k ou contient une vidéo, il faut d’abord exécuter compact afin de préserver les informations essentielles tout en maintenant la compatibilité
  • Changer de modèle ou de reasoning_effort invalide le cache de contexte existant et impose un nouveau préremplissage, ce qui peut augmenter l’usage ; il est recommandé de basculer dans une nouvelle session
  • Les modèles et contextes disponibles varient selon l’abonnement ; si vous dépassez vos droits, un 401 est renvoyé. Dans les outils tiers, il faut configurer directement l’ID de modèle exact, la taille de contexte et l’intensité de raisonnement

Configuration des modèles de Kimi Code

  • Kimi Code propose Kimi K3 et Kimi K2.7 Code via 4 ID de modèles
    • k3 : modèle de codage flagship de 2,8T de paramètres, prenant en charge jusqu’à 1M de contexte avec les abonnements supérieurs
    • k3-256k : version à contexte 256k de Kimi K3, axée sur la réduction de la consommation
    • kimi-for-coding : Kimi K2.7 Code, adapté à la complétion de code et aux tâches de développement courantes
    • kimi-for-coding-highspeed : K2.7 Code HighSpeed, qui offre une sortie environ 5 à 6 fois plus rapide avec les mêmes capacités de codage
  • Les spécifications et conditions d’accès par modèle sont les suivantes
    • k3
      • Fonctionne à vitesse normale et offre jusqu’à 1M de contexte aux membres des abonnements supérieurs
      • reasoning_effort prend en charge low, high et max, avec high comme valeur par défaut
      • Disponible à partir de Moderato ; le contexte 1M est proposé à partir d’Allegretto
      • Accepte les images et les vidéos en entrée
    • k3-256k
      • Fonctionne à vitesse normale et son contexte est fixé à 256k
      • reasoning_effort prend en charge low, high et max, avec high comme valeur par défaut
      • Disponible pour les membres Moderato et supérieurs
      • Accepte uniquement les images en entrée ; la vidéo n’est pas prise en charge
    • kimi-for-coding
      • Offre une vitesse normale et un contexte de 256k, et est disponible pour tous les membres
      • Fonctionne avec Thinking:ON et prend en charge les images et les vidéos
    • kimi-for-coding-highspeed
      • Produit des sorties environ 6 fois plus vite dans un contexte de 256k, mais consomme 3 fois plus de quota
      • Disponible à partir d’Allegretto, avec prise en charge de Thinking:ON et des entrées image/vidéo

Usages de K3-256k et changement de modèle

  • k3-256k fournit les mêmes résultats que k3 dans une fenêtre de contexte de 256k, tout en consommant environ deux fois moins de quota que la version 1M
  • Il convient aux questions-réponses courantes, à la complétion de code, au développement de fonctionnalités générales et à l’édition de fichiers uniques ou de petits ensembles de fichiers, mais ne prend pas en charge les entrées vidéo

  • Passer de K3 à K3-256k

    • Si le contexte de la session actuelle dépasse 256k, certains outils comme Kimi Code CLI et Claude Code effectuent eux-mêmes un compact
    • Comme le traitement varie selon les outils d’agent, il est recommandé d’exécuter manuellement un compact une fois avant la bascule afin de compresser le contexte sous 256k
    • Cela permet de conserver les éléments essentiels du travail tout en maintenant la session
    • Après la bascule, le quota pourra être utilisé plus longtemps
    • Si l’historique de conversation contient un fichier vidéo, il est impossible de passer directement à k3-256k ; il faut d’abord exécuter compact

  • Passer de K3-256k à K3

    • Si k3-256k approche de la limite de 256k et que vous voulez éviter une perte d’information due au compact, vous pouvez basculer directement vers k3 1M
    • Dans la version actuelle, le passage de 256k à 1M n’affecte pas le cache

Gestion du cache et de l’usage

  • Changer de modèle fait que le cache de contexte construit par le modèle précédent ne correspond plus, et ce contexte doit être prérempli à nouveau
  • C’est pourquoi l’usage peut sembler augmenter juste après la bascule. Lorsque vous utilisez un nouveau modèle, démarrer une nouvelle session est préférable pour de meilleurs résultats et une consommation plus faible

  • Coût du changement d’intensité de raisonnement

    • Changer reasoning_effort invalide aussi le cache de contexte existant et impose un nouveau préremplissage
    • Il est recommandé de choisir l’intensité de raisonnement adaptée à la tâche, puis de la conserver de manière cohérente au sein d’une même session
    • Si une autre intensité de raisonnement est réellement nécessaire, mieux vaut démarrer une nouvelle session plutôt que de basculer à répétition dans une longue session

Droits d’abonnement et erreur 401

  • Même avec le bon ID de modèle, si la fonctionnalité demandée dépasse les droits de l’abonnement, le serveur renvoie 401
    • Pas d’accès à K3 : les abonnements inférieurs à Moderato ne peuvent pas appeler k3 ni k3-256k
    • Pas d’accès à 1M : avec Moderato, k3 prend en charge jusqu’à 256k ; le maximum de 1M est disponible à partir d’Allegretto
    • La limite de contexte de k3-256k est fixée à 256k, quel que soit l’abonnement
    • Pas d’accès à HighSpeed : kimi-for-coding-highspeed nécessite Allegretto ou supérieur
  • Le message d’erreur complet et les méthodes de traitement sont disponibles dans Error Reference

Pourquoi HighSpeed peut ne pas sembler rapide

  • L’ID de modèle HighSpeed doit être exactement kimi-for-coding-highspeed
    • En cas de saisie incorrecte, la requête est remplacée sans erreur par le kimi-for-coding standard, et aucune accélération n’apparaît
  • HighSpeed accélère uniquement la sortie du modèle
    • La lecture/écriture de fichiers, les appels de commandes et l’exécution de scripts ne sont pas accélérés
    • Si une tâche contient une forte proportion d’exécution d’outils ou de scripts, le gain de vitesse global peut sembler limité

Changer de modèle dans les clients

  • Changer l’ID de modèle invalide le cache de contexte. Pour éviter une consommation supplémentaire de tokens et obtenir la meilleure expérience, il est recommandé de démarrer une nouvelle session
  • Lors de l’appel, il faut saisir l’un des ID de modèles suivants, et non le nom de version du modèle
    • k3
    • k3-256k
    • kimi-for-coding
    • kimi-for-coding-highspeed
  • Saisir un nom de version comme Kimi K3 ou K2.7 Code fait échouer l’appel
  • Si vous désactivez Thinking sur K3 ou K2.7, la requête est routée vers K2.6 ; pour utiliser K3 ou K2.7 Code, Thinking doit être activé

  • Clients officiels

    • Dans Kimi Code CLI, vous pouvez saisir /model pour changer de modèle sans modifier la configuration
    • Si le dernier modèle n’apparaît pas dans la liste, reconnectez-vous avec /logout puis /login
    • Dans Kimi Code for VS Code, sélectionnez le modèle dans le menu déroulant du champ de saisie
    • Si le modèle ne s’affiche pas, redémarrez VS Code ou réinstallez l’extension

Configuration des outils tiers

  • Après avoir créé une API Key dans Kimi Code Console, saisissez la Base URL et l’ID de modèle dans l’outil
  • L’API Kimi Code prend en charge à la fois le protocole compatible OpenAI et le protocole compatible Anthropic
  • Les méthodes de configuration par outil sont disponibles dans les documents suivants
    • Claude Code : assistant de codage en ligne de commande d’Anthropic
    • OpenCode : agent de codage basé sur le terminal
    • Codex : agent de codage d’OpenAI

  • Configuration du contexte K3

    • Le contexte par défaut de certains outils tiers est inférieur au maximum de K3, soit 1M
    • Pour utiliser jusqu’à 1M de contexte, il faut configurer directement le champ context-window sur 1048576

  • Mapping de l’intensité de raisonnement K3

    • K3 prend en charge low, high et max, et les valeurs envoyées par les outils sont mappées comme suit
    • null ou undefined : valeur par défaut high
    • Autre valeur inconnue : erreur HTTP 400
    • ultra, max, xhigh : max
    • high, medium : niveau recommandé high
    • low, minimum, light : low
    • none : thinking.type est désactivé

À lire aussi

1 commentaires

 
GN⁺ 2 시간 전
Avis sur Hacker News

  • Codex exploite très bien le contexte de 256k. 1M offre de la marge, mais reste cher et semble inutile par défaut

  • Les LLM deviennent rapidement une commodité généraliste, et le moat des labos d’IA américains comme OpenAI s’affaiblit. Au final, les hyperscalers et propriétaires de datacenters capables de vendre des tokens bon marché ont de fortes chances de gagner

    • Je n’ai pas essayé beaucoup d’autres produits, mais le harness Codex est suffisamment convaincant pour rendre difficile tout changement. Je me demande s’il existe d’autres acteurs proposant un harness de cette qualité
    • Je suis profondément reconnaissant envers les entreprises d’IA frontier qui ont investi énormément de capital et de R&D complexe dans chaque modèle. Il est déjà facile d’oublier à quel point arriver jusqu’ici a coûté cher

  • k3-256k est sorti et fournit les mêmes résultats dans un contexte de 256k. k3 (1M) consomme environ deux fois plus de quota que k3-256k

  • C’est une bonne évolution. En général, j’essaie de garder le contexte sous les 200k

    • Dans le fil Reddit de cette annonce, la phrase tout en haut des commentaires est exactement la même
      https://www.reddit.com/r/kimi/s/BFa1TR9vNg
    • Cela dépend du périmètre de travail, mais je pense que le bon compromis est sous les 500k. Avec Claude, 500 000 tokens permettent de construire un projet d’une taille assez importante tout en conservant tout le contexte du début jusqu’au moment présent
    • « 256k devrait suffire à tout le monde »

  • Je me demande donc si tous les utilisateurs vont soudain utiliser Kimi à moitié prix jusqu’à ce que le contexte atteigne 256k. Si c’est vrai, c’est un énorme changement

    • Comme il s’agit d’un modèle distinct, je pensais qu’en utilisant k3-256k puis en basculant vers le modèle 1M à 256k, le cache serait invalidé, et qu’il faudrait aussi repayer les 256k tokens existants au tarif du modèle 1M
      Mais c’était faux : il est possible de passer au modèle 1M à l’approche de la limite de contexte sans invalidation du cache. Dans la version actuelle, passer de k3-256k à k3 (1M) n’affecte pas le cache
    • Ce n’est pas comme ça que je le comprends. L’idée semble plutôt être qu’avec une fenêtre de contexte plus petite, le nombre de tokens d’entrée accumulés au fil du temps est plus faible, ce qui revient généralement moins cher

  • Cet article a été publié il y a 38 minutes, et depuis 20 minutes plusieurs services d’Anthropic sont indiqués en panne majeure. Ce n’est probablement pas lié, mais ça m’a un peu fait rire

  • Le modèle lui-même semble être le même ; il s’agit apparemment seulement d’un changement au niveau de l’API

  • C’est fonctionnellement similaire à la manière dont OpenAI change de palier tarifaire au-delà d’une certaine longueur de contexte. Le seuil est aussi autour de 272k, c’est-à-dire près de 2^18 ou de 256k
    À mesure que le contexte actif augmente, la quantité de calcul nécessaire par token de sortie et le nombre d’octets à lire augmentent, donc il est logique de répercuter ce coût sur l’utilisateur. En revanche, il est surprenant qu’ils n’aient pas utilisé une courbe de prix progressive plutôt qu’un seuil par paliers

    • Il est probable qu’ils opèrent deux configurations d’infrastructure selon la longueur maximale de séquence, donc un seuil par paliers n’est pas surprenant
      Une configuration à contexte court nécessite moins de nœuds dédiés au prefill par instance et n’a pas besoin de prendre en charge un grand cache KV, ce qui permet aussi de réduire le nombre total de nœuds. Avec l’inférence désagrégée, on peut également ajuster séparément la part de calcul allouée au prefill et au décodage

  • J’espère que ce changement réduira la charge sur l’infrastructure. Dernièrement, tous les modèles sont devenus nettement plus lents et l’équipe support ne réagit pas. Je soupçonne qu’une bonne partie des requêtes est traitée par des modèles quantifiés

    • Les théories du complot sans fondement ont peut-être leur place sur Reddit, mais pas sur HN

  • Je me demande s’il ne s’agit pas d’un modèle quantifié, mais simplement d’une fenêtre de contexte limitée à 256k

    • Une fenêtre de contexte de 256k et le fait qu’un modèle soit quantifié ou non sont deux choses distinctes. Comme c’est difficile à vérifier directement de l’extérieur, on ne peut pas non plus exclure qu’il ait effectivement été quantifié