2026 API MLX LOCALE
MACMLX_
BATCH_
MATRIX.
Pour brancher Cursor ou vos agents sur un endpoint OpenAI-compatible local, deux piles MLX coexistent : macMLX (Swift, sans Electron) et les serveurs type mlx-batch-server avec réglages MLX_BATCH_*. Les deux exposent /v1, mais la sémantique de concurrence, la RSS et les journaux divergent. La mémoire unifiée subit Xcode, le navigateur et VideoToolbox—les benchmarks doivent figer l’empreinte charge. LiteLLM aide aux clés API, pas à la bande passante Metal. Croiser avec API OpenAI + launchd et vllm-mlx multi-agents.
1. Points douloureux — deux piles MLX, deux SLA possibles
1) Enveloppe d’exécution : macMLX garde l’inférence Swift native pour minimiser la friction bureau ; mlx-batch-server aligne plutôt mlx-lm avec agrégation HTTP explicite — les journaux et incidents ne sont pas débogués pareil.
2) Sémantique concurrente : les coordinateurs batch empilent les requêtes dans une fenêtre glissante (souvent 50–200 ms). Pour les jobs offline c’est idéal ; pour le streaming IDE cela peut augmenter la variance du TTFT et retarder le premier octet SSE si la même instance porte tout.
3) Mémoire unifiée : Xcode, Chromium et VideoToolbox consomment la même enveloppe que MLX ; sans captures RSS contextualisées on croit à une régression modèle alors que c’est du swap ou du thermique.
4) LiteLLM : rotation des clés et quotas cloud d’abord ; aucune création de bande passante Metal. N’offload vers un Mac distant que lorsque les fenêtres minimales échouent encore sur TTFT p95/p50.
2. Tableau comparatif — contrôle bureau vs plan de données batch
| Axe | macMLX | mlx-batch-server |
|---|---|---|
| Profil | GUI + CLI partagées ; swaps à froid entre pondérations | Slots HTTP concurrents, endpoints de stats batch |
| Ports indicatifs | :8000/v1 | :10240/v1 (configurable) |
| Réglages | couches KV / pin modèle | MLX_BATCH_BATCH_WINDOW_MS, MLX_BATCH_MAX_BATCH_SIZE |
| Télémesure | RSS + caches KV | Histogrammes batch, profondeur file |
| Déclencheur Mac distant | Garder l’IDE local, déporter pics | Charge soutenue dépassant budget thermique portable |
Pour les équipes créatives françaises, Apple Silicon demeure la passerelle la plus fluide entre pipelines vidéo et agents MLX — tant que l’on sépare « contrôle créatif macMLX » et « pipelines batch nocturnes » documentés comme tout paramètre SLO. La Direction Artistique comprendra « fenêtre 80 ms » plus vite que « instabilité mystérieuse » si vous reliez le chiffre à une latence utilisateur.
Côté conformité (RGPD / ISO), les pondérations locales permettent encore de tracer qui accède aux artefacts ; lorsque les fenêtres batch déclenchent swap prolongé ou bourdonnement thermique constant, un Mac distant loué à l’heure absorbe la charge sans multiplier les fournisseurs cloud ni casser la traçabilité des quantifications MLX.
3. Cinq étapes d’acceptation — formaliser fenêtre, RSS et queues
Étape 1 — Isoler les charges
Ne jamais tuner streaming (stream:true) et batch offline dans la même série ; sinon impossible d’attribuer quoi que ce soit à MLX_BATCH_*.
Étape 2 — Trois nombres obligatoires
Fenêtre en millisecondes, nombre maximal de slots et RSS rapportée à la RAM physique ; relevez la première apparition de swap durable (>512 MB).
Étape 3 — Regarder les queues
Pour l’interactif : TTFT et premier paquet SSE ; pour le batch : tok/s par slot en p95 — évite de confondre débit global et équité par utilisateur.
Étape 4 — Dégradation contrôlée
Faites glisser la fenêtre de 50 ms à 200 ms pour observer la cassure UX ; figez cette valeur comme plafond interne.
Étape 5 — Artefacts ticket
Révision MLX, SKU Apple Silicon et captures Grafana dans le même incident ; sinon aucune relecture possible un mois après.
4. Matrice décisionnelle — local / LiteLLM / Mac distant
| Déclencheur | Action prioritaire | Secours | À éviter |
|---|---|---|---|
| RSS >82 % RAM pendant ≥10 min | Réduire slots ou déplacer le modèle le plus lourd | Mac distant dédié inférence | Croire qu’un proxy résout la mémoire GPU |
| TTFT p95/p50 >2,8× malgré fenêtre minimale | Séparer interactif/offline | Deuxième instance macMLX « chat only » | Augmenter aveuglément la taille du modèle |
| Besoin multi-fournisseurs audités | LiteLLM avec liste de repli signée | Débordement cloud contractualisé | Cascade de gateways non révisés |
| OOM récurrent | Analyse swap / thermal log | PoC Mac distant avant tout achat CAPEX | Rajouter RAM sans données |
Trois seuils « copier-coller wiki » : swap >768 MB pendant 90 s ⇒ palier suivant interdit ; TTFT p95/p50 >2,8 après minimisation ⇒ split obligatoire ; deux OOM/semaine ⇒ PoC distant avant budget additionnel.
5. Cas client — studio quatre créateurs sur un seul MacBook Pro
Une fenêtre à 180 ms poussait le tok/s agrégé jusqu’à faire hurler les ventilateurs ; le SSE jitterait pendant les démos. Déplacer uniquement la couche batch sur un Mac mini distant a stabilisé les flux pendant que Cursor restait branché sur macMLX local.
La racine n’était pas le checkpoint mais le partage de processus entre complétions streamées et jobs offline. Une fois les workloads séparés, la même pondération MLX suffisait — mais le vocabulaire SLA (« interactif » vs « offline ») est devenu exploitable financièrement : les dirigeants comparent désormais coût horaire Mac distant vs attente humaine.
Apple Silicon conserve son avantage créatif (mémoire unifiée pour montage + agents), mais les pics batch 24/7 appartiennent à du matériel refroidi pour du duty-cycle prolongé — ce que les cafés Wi-Fi ne garantissent jamais.
6. Lecture industrielle — LiteLLM après la gouvernance, MLX mesuré
macMLX réduit la friction bureau ; mlx-batch-server finance la densité de requêtes. LiteLLM doit intervenir lorsque les politiques de routage sont écrites — jamais comme rustine VRAM. Comparé au cloud pur, MLX sur Mac préserve les preuves de quantification ; comparé aux laptops surequipés, la location horaire de Mac distants aligne dépense et pics réels.
MACGPU cible cette hybridation : louer du Apple Silicon prévisible quand les courbes RSS/swap prouvent que le portable ne doit plus absorber la charge — sans transformer un hotspot Wi-Fi public en contrat SLA.
En conclusion : prototypez vite avec du MLX natif ; industrialisez avec fenêtres batch mesurées et seuils explicites d’offload. Si thermiques et swap résistent encore après minimisation des fenêtres, basculez vers un Mac distant avec alimentation stable — plus fiable que multiplier tunnels SSH ou passerelles opaques.
7. FAQ — malentendus fréquents
Faut-il LiteLLM dès le POC ? Non—fixez d’abord les métriques locales et les seuils d’offload. LiteLLM intervient lorsque plusieurs clés et politiques coexistent réellement.
Même poids MLX sur portable et Mac distant ? Oui, tant que les checksums et profils de quantification sont synchronisés ; évitez les dérives d’ENV implicites.
Quand « ajouter de la RAM » échoue ? Lorsque thermiques ou swap restent critiques malgré des fenêtres batch minimales—le goulot est alors refroidissement ou alimentation, pas la capacité brute.