patdev commited on
Commit
b3de290
·
verified ·
1 Parent(s): 54e25d3

Upload distill/README.md with huggingface_hub

Browse files
Files changed (1) hide show
  1. distill/README.md +103 -0
distill/README.md ADDED
@@ -0,0 +1,103 @@
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
1
+ # Kimi-K3-Linear-48B-A3B — chaîne de distillation
2
+
3
+ Le modèle n'existe pas : il s'agit de le **construire**, en distillant
4
+ Kimi-K3 dans le socle `Kimi-Linear-48B-A3B-Instruct`. C'est la recette déjà
5
+ validée dans `Kimi-K3-L4-GenAI-TurboQuant` (Qwen3.5-9B + LoRA dérivée de K3,
6
+ 32,3 tok/s et 91 % d'acceptation MTP sur L4), appliquée cette fois à un socle
7
+ qui partage l'architecture `KimiLinearForCausalLM` de K3.
8
+
9
+ ```
10
+ generate.py collecte les reponses de K3 via l'endpoint officiel, budget plafonne
11
+ train_lora.py QLoRA NF4 sur le socle bf16, reprise apres interruption
12
+ service : vllm serve <socle> --enable-lora --lora-modules k3linear=<out>
13
+ ```
14
+
15
+ ## Ce que la chaîne peut et ne peut pas faire
16
+
17
+ **Distillation au niveau séquence uniquement.** L'API de K3 ne rend pas les
18
+ logits : le socle apprend à imiter les *sorties*, pas les distributions. C'est
19
+ moins efficace en tokens qu'une KD sur logits, mais c'est la seule voie sans
20
+ poids K3 locaux — et K3 complet fait 1 499 Gio au minimum, soit une vingtaine
21
+ de cartes.
22
+
23
+ **Le mur matériel, chiffré :**
24
+
25
+ ```
26
+ socle bf16 pour du QLoRA 91,5 Gio (l'AWQ 4 bits est inference seule)
27
+ disque d'un pod standard 100 Go -> ne tient pas avec l'environnement
28
+ poids NF4 en VRAM ~26 Go -> tient sur une A40 de 46 Go
29
+ debit d'entrainement, 1x A40 quelques centaines de tokens/s
30
+ LoRA qui change le comportement quelques millions de tokens
31
+ ```
32
+
33
+ Autrement dit : **une distillation utile ne rentre pas dans 8 $ sur une seule
34
+ A40.** La chaîne est écrite pour reprendre après interruption précisément parce
35
+ que l'entraînement s'étalera sur plusieurs sessions, avec un disque plus grand.
36
+
37
+ ## Les données
38
+
39
+ Les prompts ciblent les écarts *mesurés* entre le socle et K3, pas des tâches
40
+ génériques :
41
+
42
+ - **français technique** — le socle traduit « gate » par « gâteau » ; K3 non
43
+ - **usage d'outils** — traces agentiques, l'essentiel pour Claude Code
44
+ - **édition de code** — le régime réel d'un agent
45
+ - **raisonnement quantitatif** — où la trace de K3 porte sa méthode
46
+
47
+ `generate.py` conserve `reasoning_content` séparément : l'entraîner ou non est
48
+ une décision à prendre en aval (`--keep-reasoning`), pas figée à la collecte.
49
+
50
+ ## Incertitudes à lever avant de lancer le calcul
51
+
52
+ 1. **vLLM sert-il un LoRA sur `KimiLinearForCausalLM` ?** Non vérifié. Si non,
53
+ il faudra fusionner le LoRA dans le socle puis requantifier.
54
+ 2. **Les noms de modules cibles** sont déduits de la géométrie MLA (`q_a_proj`,
55
+ `kv_b_proj`…) ; le script les filtre sur ceux réellement présents et échoue
56
+ avec la liste des modules disponibles plutôt que de deviner.
57
+ 3. **Le tokenizer corrigé** (`patdev/kimi-linear-tokenizer-fix`) est requis :
58
+ l'original casse sur transformers ≥ 5.5.3.
59
+
60
+ ## Économie réelle, mesurée
61
+
62
+ La chaîne a été exécutée de bout en bout sur l'endpoint officiel :
63
+
64
+ ```
65
+ 2 exemples collectes 0,085 $
66
+ extrapolation 42 a 51 $ pour 1000 exemples
67
+ ```
68
+
69
+ K3 est un modèle à raisonnement : il dépense **1200 à 2000 tokens de réflexion**
70
+ avant chaque réponse, tous facturés à 15 $/1M. C'est ce qui domine le coût, pas
71
+ la réponse elle-même.
72
+
73
+ ```
74
+ budget disponible 8 $ -> ~150 exemples
75
+ LoRA changeant le comportement -> plusieurs milliers d'exemples
76
+ collecte d'un jeu utile -> 250 a 1000 $, avant tout entrainement
77
+ ```
78
+
79
+ **Conclusion honnête : la collecte est le mur, pas le calcul.** Puisqu'on paie
80
+ le raisonnement, autant l'entraîner (`--keep-reasoning`) plutôt que de le jeter.
81
+
82
+ ## Trois pièges de l'API, tous rencontrés
83
+
84
+ 1. **`runsync` rend un identifiant de tâche** quand la génération dépasse son
85
+ attente interne. Ne pas le suivre donne une réponse sans `output` : vide,
86
+ sans coût, et sans erreur visible — un symptôme qui ressemble à tort à un
87
+ problème de modèle.
88
+ 2. **`temperature` doit valoir 1.** Toute autre valeur échoue avec
89
+ `invalid temperature: only 1 is allowed for this model`, et l'erreur reste
90
+ invisible tant que la tâche n'est pas suivie.
91
+ 3. **Cloudflare rejette la signature d'urllib** avec un 403 `error code: 1010`.
92
+ Un `User-Agent` explicite suffit.
93
+
94
+ ## Ce que la collecte vise, démontré
95
+
96
+ ```
97
+ K3 "Le mecanisme d'aiguillage (ou routeur) est un petit reseau auxiliaire..."
98
+ Kimi-Linear "...combines via un 'gateau' (un reseau de selection)"
99
+ ```
100
+
101
+ Les outils sont passés dans le champ `tools` de la requête, pas décrits en
102
+ prose : sollicité en prose, K3 répond à juste titre qu'aucun outil ne lui est
103
+ fourni, et l'exemple est inutilisable.