Le code promis par Perplexity est maintenant public

Perplexity avait présenté Lily le 1er septembre 2026 comme le moteur d’inférence locale de son approche Hybrid Compute sur Mac. L’annonce promettait une publication prochaine. Celle-ci est devenue vérifiable le 2 septembre : l’entreprise a ajouté au dépôt public pplx-garden quelque 16 000 lignes consacrées au runtime, aux noyaux Metal, aux tests et aux benchmarks, sous licence Apache 2.0.

Ce passage du discours au code change la portée de l’information. Il permet d’inspecter les conditions d’exécution, de reproduire une partie des mesures et, surtout, de voir ce que Lily ne prend pas encore en charge. Le projet public est un prototype très spécialisé, pas un remplaçant général de MLX-LM, llama.cpp ou d’une application locale prête à l’emploi.

Graphique officiel Perplexity annonçant 4 156 tokens par seconde en prefill et 170 tokens par seconde en décodage pour Lily.
Ce graphique du billet initial compare Lily à une version antérieure de MLX-LM. Il s’agit de mesures Perplexity sur une seule machine, pas d’un test indépendant.

Une spécialisation assumée pour un modèle et une puce

MLX et MLX-LM doivent servir plusieurs architectures. Lily prend l’option inverse : un runtime Rust coordonne directement la structure d’un seul modèle, ses phases de préremplissage et de décodage, puis des noyaux Metal écrits pour les formes de calcul attendues. Ni PyTorch ni MLX ne se trouvent dans son chemin d’exécution. Cette étroitesse autorise des choix que ferait plus difficilement une pile généraliste.

Le modèle visé est exactement Qwen3.6-35B-A3B converti en poids MLX affines sur 4 bits, par groupes de 64. Lily valide l’architecture et le format au chargement. Le dépôt refuse les variantes Qwen plus petites ou denses, le BF16, GGUF, AWQ, GPTQ, int8 et fp8. L’avantage potentiel vient donc avec une portabilité presque nulle à ce stade.

Schéma officiel comparant la pile généraliste MLX-LM au runtime spécialisé Lily.
Perplexity oppose ici la composition généraliste de MLX-LM à une exécution Lily façonnée pour un modèle et une famille de GPU.

Le nouveau rapport réduit l’écart face à MLX 0.32.2

Le billet de lancement revendique en moyenne 1,23 fois le débit de préremplissage et 1,35 fois le débit de décodage de MLX-LM, sur dix longueurs allant de 256 à 128K tokens. Le protocole utilise un seul MacBook Pro doté d’un M5 Max, d’un GPU à 40 cœurs et de 128 Go de mémoire unifiée, en lot 1. Ces chiffres restent des mesures du concepteur et ne décrivent ni la latence HTTP complète, ni le chargement du modèle, ni la tokenisation.

Le dépôt contient désormais un rapport daté du 2 septembre qui compare Lily à MLX 0.32.2 et mlx-lm 0.31.3. Il est plus nuancé. En décodage, Lily conserve une avance comprise entre 1,236 et 1,319 fois selon la longueur testée. En préremplissage, l’écart va de 1,130 fois à 256 tokens à seulement 1,030 fois à 2K, puis MLX-LM passe devant à 32K, 64K et 128K. À 128K, Lily atteint 1 792,7 tokens par seconde contre 2 237,5 pour MLX-LM.

Les auteurs précisent aussi que les moteurs ne calculent pas exactement le même graphe : MLX-LM produit un vecteur complet de probabilités que le banc jette, tandis que Lily sélectionne directement le token glouton. Les trajectoires de génération peuvent différer. La comparaison mesure donc le débit de deux moteurs en production selon leur propre chemin, pas l’efficacité d’opérations strictement identiques.

Courbes officielles Perplexity montrant le débit de Lily et de MLX-LM selon la longueur de prompt ou de contexte.
Le graphique initial montre une avance à tous les points avec l’environnement alors utilisé. Le rapport MLX 0.32.2 publié ensuite doit être lu séparément.

Un Mac très récent et un point de contrôle de 19,4 Go

Le dépôt autonome exige une famille de GPU Apple 10 ou ultérieure, soit un M5 ou plus récent, ainsi que macOS 26 au minimum pour les opérations tensorielles Metal. Le benchmark reproductible a été exécuté sous macOS 27.0. Le point de contrôle Qwen quantifié occupe 19,4 Go, contre environ 70 Go en bfloat16 selon Perplexity. Posséder assez de stockage ne suffit donc pas à rendre un ancien Mac compatible.

La recommandation pratique de mémoire n’est pas publiée sous la forme d’une configuration minimale certifiée. Le modèle, son cache KV, l’état récurrent, les activations et le système partagent la mémoire unifiée. Les 128 Go du banc ne prouvent ni qu’ils sont nécessaires, ni qu’un Mac 24 ou 32 Go reproduira les résultats. Une évaluation indépendante sur plusieurs M5 reste indispensable avant de conseiller un achat.

Schéma officiel du chemin de préremplissage de Lily entre registres GPU et mémoire unifiée.
Lily conserve les poids Q4 compressés jusqu’au calcul et maintient plusieurs états sur le GPU pour limiter les transferts.

Les gains viennent surtout des mouvements de données

Qwen3.6-35B-A3B est un mélange d’experts : environ 3 milliards de ses 35 milliards de paramètres sont activés pour chaque token. Lily garde le routage des experts sur le GPU, déquantifie les poids au sein du calcul matriciel groupé et transporte l’état récurrent dans les registres. Pour les longs prompts, il travaille par fragments afin de plafonner les activations temporaires sans supprimer le contexte antérieur.

Au décodage, le token sélectionné reste disponible dans un emplacement GPU pour l’étape suivante. Le runtime décrit les dépendances afin que certains noyaux puissent se chevaucher, fusionne des chaînes d’opérations et partage mieux les lignes du cache KV entre têtes de requête. Perplexity rapporte aussi un résultat négatif utile : son essai de décodage spéculatif a ralenti cette charge de 18 %, preuve qu’une technique efficace en centre de données ne se transpose pas automatiquement à un Mac.

Schéma officiel du chemin parcouru par un token dans la boucle de décodage de Lily.
Le schéma détaille la résidence GPU du token, l’ordonnancement par dépendances et la réutilisation du cache KV.

L’API publique reste volontairement minimale

Lily expose POST /v1/chat/completions, GET /v1/models et GET /health. La ressemblance avec l’API OpenAI s’arrête là : le serveur public accepte du texte, un nombre maximal de tokens, stream réglé sur false et une clé optionnelle de cache de préfixe. Il décode toujours de façon gloutonne, avec le raisonnement du modèle désactivé. Le streaming, les outils, les formats structurés, le multimodal, l’échantillonnage et le décodage spéculatif sont rejetés.

Le billet technique décrivait un moteur interne capable de diffuser des tokens. Le README publié est plus strict ; c’est lui qui fait foi pour le code disponible aujourd’hui. Son cache de session ne garde que deux états et ne les réutilise que si la séquence précédente est un préfixe exact du nouveau prompt. Cette prudence limite les usages, mais rend le périmètre testable et réduit le risque de promettre des fonctions absentes.

Une démonstration d’ingénierie, pas encore un choix universel

L’intérêt immédiat de Lily est méthodologique : le dépôt montre jusqu’où une équipe peut pousser un couple modèle-matériel connu. Il offre du code, des tests, des identifiants de versions et un protocole reproductible. L’Apache 2.0 permet aussi d’étudier et de réutiliser le travail dans les limites de la licence.

Pour un utilisateur, les réserves dominent encore : Mac M5 requis, un seul point de contrôle, aucune interface grand public, fonctions de génération réduites et absence de mesures indépendantes multi-machines. Lily ne démontre pas que MLX-LM est dépassé ; il illustre le prix et le bénéfice d’une spécialisation extrême. Les extensions annoncées à d’autres modèles et puces devront être jugées lorsqu’elles seront effectivement publiées.

Sources