Optimisez LM Studio pour la vitesse et la mémoire

LM Studio est le moyen le plus simple d’exécuter des modèles locaux — téléchargez un modèle, cliquez sur Load, et vous discutez. Sous le capot, il enveloppe llama.cpp (et MLX sur Apple Silicon), et expose des options de configuration qui contrôlent l’utilisation de votre matériel. Les valeurs par défaut fonctionnent pour un usage casual mais laissent des performances significatives sur la table. Ce guide couvre chaque paramètre important et comment le régler pour votre charge de travail.

Last verified: 2026-10-14 — LM Studio v0.3.26 / Bionic 1.1.8.

Apple Silicon uses MLX. Sur les Mac Apple Silicon, LM Studio utilise automatiquement le framework MLX d’Apple plutôt que llama.cpp. MLX offre une inférence substantiellement plus rapide sur les puces série M (voir Apple Silicon and MLX optimization). La plupart des options de configuration de ce guide s’appliquent aux deux backends ; quand le comportement diffère, c’est signalé explicitement.

Réglage de la fenêtre de contexte

La fenêtre de contexte contrôle le nombre de jetons que le modèle peut traiter en une seule requête — votre prompt plus la réponse générée combinés. C’est le facteur le plus important de l’utilisation mémoire après les poids du modèle eux-mêmes.

Comment augmenter la fenêtre de contexte dans LM Studio

LM Studio utilise par défaut une fenêtre de contexte de 2048 jetons pour la compatibilité. La plupart des modèles modernes supportent 8K, 32K, ou même 128K jetons, mais LM Studio n’utilise pas le maximum du modèle par défaut — il utilise 2048 pour garder l’utilisation mémoire prévisible. Définissez-la de 3 façons : Dans l’UI (panneau de chargement du modèle) : Quand vous chargez un modèle, le panneau de chargement affiche un curseur Context Length. Glissez-le à la valeur souhaitée (par ex. 8192, 16384, 32768) avant de cliquer sur Load Model. Par modèle (défaut persistant) : Définissez une longueur de contexte par défaut pour un modèle spécifique afin qu’elle s’applique à chaque chargement. Allez au modèle dans votre bibliothèque, cliquez sur l’icône engrenage, et définissez Context Length sous Per-model Defaults. Consultez Per-model Defaults pour les détails. Via l’API (par requête) :

curl http://localhost:1234/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "llama-3.1-8b-instruct",
    "messages": [{"role": "user", "content": "Summarize this document..."}],
    "context_length": 32768
  }'

Via la CLI :

lms load llama-3.1-8b-instruct --context-length 32768

Coût mémoire de la fenêtre de contexte

Le cache KV croît linéairement avec la longueur de contexte. La formule :

KV cache memory = 2 × num_layers × hidden_dim × num_ctx × precision_bytes

Pour un modèle 7B (32 couches, 4096 dimensions cachées) en précision f16 :

Context length	KV cache memory
2,048 (default)	~1 GB
8,192	~4 GB
32,768	~16 GB
128,000	~64 GB

Définissez la longueur de contexte aussi haute que votre charge de travail en a réellement besoin. Un agent de codage qui envoie des prompts de 2K ne bénéficie pas d’une fenêtre de contexte de 128K — il gaspille juste 64 Go d’espace cache KV qui pourrait servir d’autres requêtes ou accueillir un modèle plus grand.

Flash attention

La flash attention est ce qui se rapproche le plus d’une amélioration gratuite des performances que LM Studio offre. Elle restructure la façon dont le modèle calcule l’attention entre les jetons — au lieu de matérialiser la matrice d’attention complète en mémoire, elle calcule l’attention par blocs empiétés qui tiennent dans la SRAM rapide. Le résultat :

30-50% lower memory usage pour le cache KV — le gain le plus important aux longueurs de contexte élevées.
Faster inference — surtout sur GPU, où le calcul par blocs correspond bien aux tensor cores.
Same output quality — la flash attention est mathématiquement équivalente à l’attention standard, pas une approximation.

Comment activer la flash attention dans LM Studio

Dans l’UI : Quand vous chargez un modèle, le panneau de chargement affiche un toggle Flash Attention. Activez-le avant de cliquer sur Load Model. Par modèle (défaut persistant) : Définissez un défaut pour un modèle spécifique afin qu’il s’applique à chaque chargement. Allez au modèle dans votre bibliothèque, cliquez sur l’icône engrenage, et activez Flash Attention sous Per-model Defaults. Via l’API :

curl http://localhost:1234/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "llama-3.1-8b-instruct",
    "messages": [{"role": "user", "content": "Hello"}],
    "flash_attention": true
  }'

Always enable flash attention. Il n’y a aucune raison de la laisser désactivée sauf si vous rencontrez un problème de compatibilité avec un modèle ou une plateforme spécifique. C’est le paramètre à l’impact le plus élevé dans ce guide.

Sur Apple Silicon avec le backend MLX, la flash attention est activée par défaut et le paramètre n’a pas d’effet — MLX utilise toujours des kernels d’attention optimisés.

Stratégie de délestage GPU

LM Studio déleste automatiquement les couches du modèle sur votre GPU. Quand le modèle complet tient dans la VRAM, chaque couche s’exécute sur le GPU pour une vitesse maximale. Quand la VRAM est serrée, LM Studio répartit les couches entre GPU et CPU — le GPU exécute ce qu’il peut, et le reste revient sur la RAM système.

Comment LM Studio décide des couches GPU

L’ordonnancement GPU de LM Studio fonctionne dans cet ordre :

Full offload — si les poids du modèle + le cache KV tiennent dans la VRAM, toutes les couches vont au GPU. C’est la configuration la plus rapide.
Partial offload — si le modèle ne tient pas entièrement, LM Studio met autant de couches que possible sur le GPU et exécute le reste sur le CPU. Les performances se dégradent car chaque passe avant doit traverser le bus PCIe pour les couches résidentes sur le CPU.
CPU-only — si aucun GPU n’est disponible ou si la VRAM est trop petite même pour quelques couches, le modèle entier s’exécute sur le CPU.

Contrôler le délestage GPU

Le paramètre GPU Offload contrôle le nombre de couches à délester sur le GPU. Définissez-le dans l’UI, les défauts par modèle, ou via l’API : Dans l’UI : Quand vous chargez un modèle, le panneau de chargement affiche un curseur GPU Offload. Vous pouvez le définir sur :

Auto (par défaut) — LM Studio détecte automatiquement la VRAM disponible et déleste autant de couches que possible.
Max — force toutes les couches sur le GPU. Utilisez ceci quand vous savez que le modèle tient.
Off — désactive complètement le délestage GPU (inférence CPU uniquement).
Manual — glissez le curseur pour définir un nombre spécifique de couches.

Par modèle (défaut persistant) : Définissez un défaut pour un modèle spécifique. Allez au modèle dans votre bibliothèque, cliquez sur l’icône engrenage, et définissez GPU Offload sous Per-model Defaults. Via l’API :

curl http://localhost:1234/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "llama-3.1-8b-instruct",
    "messages": [{"role": "user", "content": "Hello"}],
    "gpu": "max"
  }'

`gpu` value	Behavior
`"auto"` (default)	LM Studio auto-detects based on available VRAM
`"max"`	All layers on GPU — use when you know the model fits
`"off"`	No GPU offload — CPU only
`0.0` to `1.0`	Fraction of layers on GPU (e.g., `0.5` = 50% of layers)

Laissez le délestage GPU sur Auto et laissez LM Studio décider dans la plupart des cas. Ne le définissez manuellement que quand vous avez besoin de forcer une répartition spécifique — par exemple, pour réserver de la VRAM pour une fenêtre de contexte plus grande ou pour garder quelques couches sur le CPU pour un modèle qui tient tout juste.

Budgétisation VRAM

Chaque couche délestée consomme de la VRAM pour les poids et le cache KV. Une estimation approximative :

VRAM per layer ≈ (parameters_per_layer × bytes_per_weight) + (KV_cache_per_layer × num_ctx)

Pour un modèle 7B en Q4_K_M (~4.5 bits par poids, ~32 couches) :

Component	Per layer	32 layers total
Weights	~0.19 GB	~6 GB
KV cache (f16, 8K ctx)	~0.13 GB	~4 GB
Total		~10 GB

Laissez 1-2 Go de marge VRAM pour le contexte CUDA et la surcharge.

Quand vous augmentez la longueur de contexte, le cache KV grossit et peut pousser des couches hors de la VRAM. Si vous définissez une fenêtre de contexte de 32K et que LM Studio déleste soudainement la moitié des couches sur le CPU, c’est le cache KV qui a mangé votre budget VRAM. Réduisez la longueur de contexte, utilisez une quantification plus petite, ou activez la flash attention pour réduire le cache KV.

Précision du cache KV

Le cache KV stocke les tenseurs de clés et de valeurs pour chaque jeton dans chaque séquence active. Par défaut, LM Studio utilise f16 (virgule flottante 16 bits). Vous pouvez passer à une précision quantifiée pour réduire l’utilisation mémoire au prix d’une petite perte de qualité. Définissez le type de cache dans le panneau de chargement ou via l’API : Dans l’UI : Quand vous chargez un modèle, développez Advanced Settings et cherchez KV Cache Quantization. Vous pouvez le définir sur :

f16 (par défaut) — pleine précision
q8_0 — quantification 8 bits
q4_0 — quantification 4 bits

Via l’API :

curl http://localhost:1234/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "llama-3.1-8b-instruct",
    "messages": [{"role": "user", "content": "Hello"}],
    "llama_k_cache_quantization_type": "q8_0",
    "llama_v_cache_quantization_type": "q8_0"
  }'

Cache type	Memory per element	Quality	When to use
`f16` (default)	2 bytes	Baseline	Maximum quality; you have plenty of memory
`q8_0`	1 byte	Near-identical to f16	Best balance — halves KV cache memory with negligible quality loss
`q4_0`	0.5 bytes	Slight degradation	Tight memory; long context or many concurrent sequences

Combinez le cache KV q8_0 avec la flash attention pour le gain mémoire le plus important. La flash attention réduit l’empreinte du cache KV de 30-50%, et q8_0 la réduit encore de moitié — ensemble ils peuvent couper la mémoire du cache KV de 60-75% par rapport au défaut.

q4_0 cache KV introduit une perte de qualité mesurable sur les tâches qui reposent sur une attention précise sur un long contexte — la récupération needle-in-a-haystack, la synthèse multi-documents et les longues conversations. Testez votre charge de travail spécifique avant de vous engager avec q4_0.

Réglage de la taille de batch

Le paramètre Eval Batch Size contrôle le nombre de jetons que LM Studio traite à la fois pendant la phase de prefill (ingestion du prompt). La valeur par défaut est 512. Définissez-le dans le panneau de chargement sous Advanced Settings ou via l’API :

curl http://localhost:1234/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "llama-3.1-8b-instruct",
    "messages": [{"role": "user", "content": "Hello"}],
    "eval_batch_size": 1024
  }'

Setting	Effect
`512` (default)	Balanced for interactive chat with short prompts
`1024`	Faster prefill for long prompts — roughly 50-100% faster time-to-first-token
`2048`	Maximum throughput for document ingestion — up to 150% faster prefill
`2048+`	Diminishing returns; higher memory usage without proportional speed gains

Pour le chat interactif avec des invites courtes (moins de 1K jetons), la valeur par défaut 512 convient. Augmentez-la seulement si vous ingérez régulièrement de longs documents et voulez un temps au premier jeton plus rapide.

Les tailles de batch plus grandes consomment plus de VRAM pendant l’ingestion du prompt. Si vous augmentez la taille de batch et rencontrez des erreurs de mémoire, réduisez-la ou diminuez la longueur de contexte.

Gestion de la mémoire des modèles

Garder les modèles chargés avec le TTL

Par défaut, LM Studio décharge un modèle de la mémoire après une période d’inactivité. La requête suivante doit recharger le modèle depuis le disque, ce qui prend des secondes à des minutes selon la taille du modèle et la vitesse du disque. Définissez le TTL (Time To Live) pour contrôler la durée de chargement des modèles : Dans l’UI : Quand vous chargez un modèle, le panneau de chargement affiche un menu déroulant TTL. Définissez-le sur :

Until you close the app — le modèle reste chargé indéfiniment.
Until you unload it — le modèle reste chargé jusqu’à ce que vous le déchargiez manuellement.
Custom duration — le modèle se décharge après la durée spécifiée (par ex. 5 minutes, 1 heure).

Via l’API :

curl http://localhost:1234/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "llama-3.1-8b-instruct",
    "messages": [{"role": "user", "content": "Hello"}],
    "ttl": -1
  }'

Via la CLI :

lms load llama-3.1-8b-instruct --ttl -1

Value	Behavior
Default (5 minutes)	Unload after 5 minutes of inactivity
`-1`	Keep loaded indefinitely — no reload penalty
`0`	Unload immediately after each request
Duration in seconds (`3600`, `86400`)	Keep loaded for that duration after the last request

Pour un serveur d’inférence dédié qui exécute le même modèle toute la journée, définissez le TTL sur Until you close the app ou -1. Le modèle reste en mémoire et chaque requête obtient une réponse instantanée sans pénalité de démarrage à froid.

Serving multi-modèles

LM Studio peut charger plusieurs modèles simultanément. Quand vous chargez un deuxième modèle, LM Studio vérifie s’il y a assez de mémoire. Sinon, il décharge le modèle le moins récemment utilisé pour faire de la place. Pour gérer les modèles chargés : Dans l’UI : Le panneau Models affiche tous les modèles chargés. Cliquez sur le bouton de déchargement à côté d’un modèle pour libérer de la mémoire. Via la CLI :

# List loaded models
lms status

# Unload a specific model
lms unload llama-3.1-8b-instruct

# Unload all models
lms unload --all

Via l’API :

# Unload a specific model
curl -X DELETE http://localhost:1234/v1/models/llama-3.1-8b-instruct

Configuration du serveur local

LM Studio expose un serveur API compatible OpenAI. Par défaut, il écoute sur http://localhost:1234.

Paramètres du serveur

Dans l’UI : Allez à l’onglet Server et cliquez sur Server Settings pour configurer :

Host — adresse de liaison (par défaut : 127.0.0.1). Changez en 0.0.0.0 pour servir sur le réseau local.
Port — port d’écoute (par défaut : 1234).
CORS — active les requêtes cross-origin pour les clients web.
Require API Key — exige un bearer token pour l’authentification.

Via la CLI :

lms server start --host 0.0.0.0 --port 8080

Définir le host sur 0.0.0.0 expose LM Studio à votre réseau local. Ne faites cela que si vous faites confiance à tous les appareils de votre réseau, ou utilisez un pare-feu pour restreindre l’accès. Pour l’accès à distance sur internet, utilisez Tokios à la place — il fournit un accès à distance authentifié sans ouvrir de ports.

Endpoints API

LM Studio supporte ces endpoints compatibles OpenAI :

Endpoint	Purpose
`/v1/chat/completions`	Chat completions (most common)
`/v1/completions`	Text completions (legacy)
`/v1/embeddings`	Generate embeddings
`/v1/models`	List loaded models
`/v1/responses`	Responses API (newer format)
`/v1/decisions`	Decision models (classification, routing)

Exemple : lister les modèles chargés

curl http://localhost:1234/v1/models

Exemple : complétion de chat

curl http://localhost:1234/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "llama-3.1-8b-instruct",
    "messages": [
      {"role": "user", "content": "Hello!"}
    ]
  }'

Formats de modèles supportés

LM Studio supporte 2 formats de modèles principaux :

GGUF (multiplateforme)

GGUF est le format le plus largement supporté. Il fonctionne sur Windows, Linux et macOS — avec ou sans GPU. Les modèles GGUF sont quantifiés pour réduire la taille des fichiers (par ex. Q4_K_M, Q5_K_M, Q8_0). Quand utiliser GGUF :

Vous avez besoin de portabilité multiplateforme (Windows, Linux, Mac).
Vous voulez exécuter le même modèle sur GPU NVIDIA et Apple Silicon.
Vous préférez le plus grand choix d’options de quantification.

MLX (optimisé Apple Silicon)

MLX est le framework de machine learning d’Apple, optimisé pour les puces série M. Sur Apple Silicon, LM Studio utilise automatiquement MLX pour une inférence plus rapide. Quand utiliser MLX :

Vous êtes sur Apple Silicon (M1, M2, M3, M4).
Vous voulez les performances maximales sur Mac.
Vous n’avez pas besoin d’exécuter le même modèle sur du matériel non-Apple.

Sur Apple Silicon, LM Studio sélectionne automatiquement le meilleur runtime (MLX ou llama.cpp) pour votre matériel. Vous n’avez pas besoin de le configurer manuellement.

Optimisation Apple Silicon et MLX

Sur les Mac Apple Silicon, LM Studio utilise le framework MLX d’Apple par défaut. MLX est optimisé pour l’architecture mémoire unifiée d’Apple et offre une inférence substantiellement plus rapide que llama.cpp sur les puces série M.

Gains de performance

Benchmarks issus des tests de la communauté :

Model	Quantization	Tokens/sec (MLX)
Llama 3.1 8B	Q4_K_M	~70-80 tok/s
Gemma 4 12B	Q4_K_M	~46 tok/s
Qwen 2.5 7B	Q4_K_M	~60-70 tok/s

MLX supporte aussi la quantification avancée sur Apple Silicon, qui offre une qualité proche de BF16 avec une empreinte mémoire 4 bits — moitié moins de perte de qualité que la quantification Q4.

Conseils d’optimisation Apple Silicon

Use MLX-optimized models. Quand vous téléchargez un modèle sur Apple Silicon, LM Studio utilise automatiquement le backend MLX. Aucune configuration nécessaire.
Flash attention is always on. MLX utilise des kernels d’attention optimisés par défaut. Le paramètre de flash attention n’a pas d’effet.
Unified memory means full GPU offload. Le GPU d’Apple Silicon peut accéder à l’ensemble du pool de RAM, donc le délestage GPU complet fonctionne tant que le modèle et le cache KV tiennent dans la mémoire unifiée.
Use q8_0 KV cache pour optimiser votre budget mémoire. Réduire le cache KV de moitié vous permet d’exécuter des modèles plus grands ou des contextes plus longs.
Set TTL to “Until you close the app” pour une inférence toujours active. Les modèles restent dans la mémoire unifiée sans pénalité de rechargement.

Si vous avez besoin de portabilité multiplateforme ou voulez exécuter la même configuration sur GPU NVIDIA et Mac, vous pouvez forcer LM Studio à utiliser le backend llama.cpp sur Apple Silicon. Contactez le support LM Studio ou consultez leur documentation pour le paramètre permettant de remplacer la sélection de backend.

Exemples de configurations

Mac Studio M2 Ultra — 128 GB mémoire unifiée

Paramètres UI :

GPU Offload: Max
Context Length: 32768
Flash Attention: Enabled (auto on MLX)
KV Cache Quantization: q8_0
TTL: Until you close the app

Cette configuration exécute un modèle 70B Q4 avec une fenêtre de contexte de 32K. Le pool de 128 Go de mémoire unifiée gère les ~40 Go de poids du modèle, ~16 Go de cache KV en q8_0, et laisse de la marge pour plusieurs modèles. MLX offre le débit maximum sur Apple Silicon.

NVIDIA RTX 4090 — 24 GB VRAM

Paramètres UI :

GPU Offload: Max
Context Length: 16384
Flash Attention: Enabled
KV Cache Quantization: q8_0
Eval Batch Size: 1024
TTL: Until you close the app

Cette configuration exécute un modèle 8B Q4 avec une fenêtre de contexte de 16K. Les 24 Go de VRAM gèrent les ~5 Go de poids du modèle, ~4 Go de cache KV en q8_0 avec flash attention. La taille de batch plus grande accélère l’ingestion de prompts.

Serveur multi-GPU — 2× RTX 4090 (48 GB VRAM totale)

Paramètres UI :

GPU Offload: Max
Context Length: 32768
Flash Attention: Enabled
KV Cache Quantization: q8_0
Eval Batch Size: 2048
TTL: Until you close the app

Cette configuration exécute un modèle 70B Q4 sur 2 GPUs. Les 48 Go de VRAM totale gèrent les ~40 Go de poids du modèle, ~16 Go de cache KV. La grande taille de batch maximise le débit pour les charges de travail par lots.

Serveur CPU uniquement — 64 GB RAM, pas de GPU

Paramètres UI :

GPU Offload: Off
Context Length: 8192
Flash Attention: Disabled
KV Cache Quantization: q8_0
Eval Batch Size: 512
TTL: Until you close the app

Cette configuration exécute un modèle 8B Q4 entièrement sur CPU. La petite taille de batch et la requête parallèle unique maintiennent l’utilisation mémoire gérable. Attendez-vous à 5-10 tok/s — utilisable pour le chat interactif mais pas les charges de travail par lots.

Erreurs courantes et comment les éviter

Erreur 1 : Définir la longueur de contexte trop haute

Problème : Vous avez défini la longueur de contexte à 128K « au cas où », mais vos prompts font moins de 2K jetons. Vous venez de gaspiller 64 Go de mémoire cache KV. Solution : Définissez la longueur de contexte pour correspondre à votre charge de travail réelle. Si vos prompts font moins de 4K jetons, utilisez 4096 ou 8192. Vous pouvez toujours l’augmenter plus tard pour des requêtes spécifiques via l’API.

Erreur 2 : Oublier la flash attention

Problème : Vous utilisez 30-50% de VRAM en plus que nécessaire car la flash attention n’est pas activée. Solution : Activez toujours la flash attention. Il n’y a pas d’inconvénient sur le matériel supporté.

Erreur 3 : Ne pas contrôler le déchargement du modèle

Problème : Vous relancez votre requête après une pause de 10 minutes, et la première requête prend 30 secondes car LM Studio a rechargé le modèle depuis le disque. Solution : Définissez le TTL sur Until you close the app ou -1 pour une inférence toujours active. Le modèle reste en mémoire et chaque requête obtient une réponse instantanée.

Erreur 4 : Ignorer la précision du cache KV

Problème : Vous manquez de VRAM et LM Studio déleste des couches sur le CPU, mais vous n’avez jamais considéré que le cache KV utilise 2× plus de mémoire que nécessaire. Solution : Définissez la quantification du cache KV sur q8_0 pour réduire de moitié la mémoire du cache KV. C’est le meilleur équilibre entre qualité et économie de mémoire.

Erreur 5 : Utiliser le délestage GPU sur un modèle qui ne tient pas

Problème : Vous avez défini le délestage GPU sur Max, mais le modèle ne tient pas dans la VRAM. LM Studio manque de mémoire ou plante. Solution : Définissez le délestage GPU sur Auto et laissez LM Studio décider. Si vous devez le définir manuellement, commencez avec une valeur plus basse et augmentez jusqu’à atteindre la limite.

Dépannage

LM Studio est lent après le démarrage

Cause : Le modèle a été déchargé et a dû être rechargé depuis le disque. Solution : Définissez le TTL sur Until you close the app ou -1 pour garder le modèle chargé indéfiniment.

Erreurs de mémoire insuffisante

Cause : Le modèle + le cache KV dépasse la VRAM ou la RAM disponible. Solution : Réduisez la longueur de contexte, activez la flash attention, définissez la quantification du cache KV sur q8_0, ou utilisez une quantification plus petite.

Le GPU n’est pas utilisé

Cause : LM Studio n’a pas détecté le GPU, ou la VRAM est trop petite même pour quelques couches. Solution : Vérifiez le panneau de chargement pour voir si les couches sont sur le GPU. Pour les GPUs NVIDIA, assurez-vous que les pilotes NVIDIA et le toolkit CUDA sont installés. Pour les GPUs AMD, assurez-vous que ROCm est installé.

Inférence CPU lente

Cause : Couches réparties entre GPU et CPU, ou pas de délestage GPU. Solution : Si possible, délestez plus de couches sur le GPU. Utilisez une quantification plus petite (Q4_K_M ou Q5_K_M) pour faire tenir plus de couches sur le GPU.

Le modèle ne charge pas

Cause : Pas assez de mémoire pour le modèle + le cache KV. Solution : Réduisez la longueur de contexte, réduisez le délestage GPU, ou utilisez une quantification plus petite. Si le modèle est trop grand pour votre matériel, téléchargez un modèle plus petit.

Prochaines étapes

LM Studio remote access

Exposez votre modèle LM Studio à vos coéquipiers et agents via Tokios — sans ouvrir de ports ni servir sur le réseau local.

Hardware reference

Comparez les plateformes matérielles pour l’inférence LLM locale — specs, capacité de modèles et recommandations.

Model fit finder

Trouvez quels modèles fonctionnent sur votre matériel, ou quel matériel peut exécuter votre modèle cible.

Test your deployment

Mesurez la latence et le débit après le réglage pour confirmer l’amélioration.

FAQ

Quel est le meilleur paramètre de délestage GPU ?

Utilisez Auto dans la plupart des cas. LM Studio détecte la VRAM disponible et déleste autant de couches que possible. Définissez-le sur Max seulement quand vous savez que le modèle complet tient dans la VRAM. Définissez-le sur Off pour l’inférence CPU uniquement.

Comment augmenter la fenêtre de contexte ?

Dans le panneau de chargement, glissez le curseur Context Length à la valeur souhaitée (par ex. 8192, 16384, 32768). Vous pouvez aussi définir un défaut par modèle dans les paramètres du modèle, ou passer context_length dans la requête API.

LM Studio supporte-t-il la flash attention ?

Oui. Activez-la dans le panneau de chargement ou les défauts par modèle. La flash attention réduit la mémoire du cache KV de 30-50% et accélère l’inférence. Sur Apple Silicon avec MLX, la flash attention est toujours active.

Comment garder le modèle chargé ?

Définissez le TTL sur Until you close the app ou -1 via l’API. Le modèle reste en mémoire et chaque requête obtient une réponse instantanée sans pénalité de rechargement.

Puis-je exécuter plusieurs modèles à la fois ?

Oui. LM Studio peut charger plusieurs modèles simultanément. Quand la mémoire est serrée, il décharge le modèle le moins récemment utilisé pour faire de la place. Utilisez lms status pour voir les modèles chargés et lms unload pour libérer de la mémoire.

Quel format de modèle dois-je utiliser ?

Utilisez GGUF pour la compatibilité multiplateforme (Windows, Linux, Mac). Sur Apple Silicon, LM Studio utilise automatiquement MLX pour une inférence plus rapide. Vous n’avez pas besoin de choisir manuellement.

Comment servir LM Studio sur le réseau local ?

Dans l’onglet Server, cliquez sur Server Settings et changez le Host en 0.0.0.0. Cela expose LM Studio à votre réseau local. Pour l’accès à distance sur internet, utilisez Tokios à la place.

Quelle est la meilleure quantification du cache KV ?

Utilisez q8_0 pour le meilleur équilibre entre qualité et économie de mémoire. Il réduit de moitié la mémoire du cache KV avec une perte de qualité négligeable. Utilisez q4_0 seulement quand la mémoire est extrêmement serrée et que vous acceptez une certaine dégradation de qualité.

Sources

LM Studio documentation — official documentation on configuration and API
LM Studio per-model defaults — setting persistent configuration per model
LM Studio CLI reference — CLI commands for loading, unloading, and server management
LM Studio OpenAI compatibility — API endpoints and client integration
LM Studio changelog — release notes and new features
GGUF vs MLX on Apple Silicon — performance comparison and format selection
LM Studio GPU offload guide — GPU offload and context size configuration

After changing LM Studio configuration, re-register your Tokios deployment so the connector picks up the new upstream endpoint. See Register Model.

​Réglage de la fenêtre de contexte

​Comment augmenter la fenêtre de contexte dans LM Studio

​Coût mémoire de la fenêtre de contexte

​Flash attention

​Comment activer la flash attention dans LM Studio

​Stratégie de délestage GPU

​Comment LM Studio décide des couches GPU

​Contrôler le délestage GPU

​Budgétisation VRAM

​Précision du cache KV

​Réglage de la taille de batch

​Gestion de la mémoire des modèles

​Garder les modèles chargés avec le TTL

​Serving multi-modèles

​Configuration du serveur local

​Paramètres du serveur

​Endpoints API

​Formats de modèles supportés

​GGUF (multiplateforme)

​MLX (optimisé Apple Silicon)

​Optimisation Apple Silicon et MLX

​Gains de performance

​Conseils d’optimisation Apple Silicon

​Exemples de configurations

​Mac Studio M2 Ultra — 128 GB mémoire unifiée

​NVIDIA RTX 4090 — 24 GB VRAM

​Serveur multi-GPU — 2× RTX 4090 (48 GB VRAM totale)

​Serveur CPU uniquement — 64 GB RAM, pas de GPU

​Erreurs courantes et comment les éviter

​Erreur 1 : Définir la longueur de contexte trop haute

​Erreur 2 : Oublier la flash attention

​Erreur 3 : Ne pas contrôler le déchargement du modèle

​Erreur 4 : Ignorer la précision du cache KV

​Erreur 5 : Utiliser le délestage GPU sur un modèle qui ne tient pas

​Dépannage

​LM Studio est lent après le démarrage

​Erreurs de mémoire insuffisante

​Le GPU n’est pas utilisé

​Inférence CPU lente

​Le modèle ne charge pas

​Prochaines étapes

LM Studio remote access

Hardware reference

Model fit finder

Test your deployment

​FAQ

​Quel est le meilleur paramètre de délestage GPU ?

​Comment augmenter la fenêtre de contexte ?

​LM Studio supporte-t-il la flash attention ?

​Comment garder le modèle chargé ?

​Puis-je exécuter plusieurs modèles à la fois ?

​Quel format de modèle dois-je utiliser ?

​Comment servir LM Studio sur le réseau local ?

​Quelle est la meilleure quantification du cache KV ?

​Sources

Réglage de la fenêtre de contexte

Comment augmenter la fenêtre de contexte dans LM Studio

Coût mémoire de la fenêtre de contexte

Flash attention

Comment activer la flash attention dans LM Studio

Stratégie de délestage GPU

Comment LM Studio décide des couches GPU

Contrôler le délestage GPU

Budgétisation VRAM

Précision du cache KV

Réglage de la taille de batch

Gestion de la mémoire des modèles

Garder les modèles chargés avec le TTL

Serving multi-modèles

Configuration du serveur local

Paramètres du serveur

Endpoints API

Formats de modèles supportés

GGUF (multiplateforme)

MLX (optimisé Apple Silicon)

Optimisation Apple Silicon et MLX

Gains de performance

Conseils d’optimisation Apple Silicon

Exemples de configurations

Mac Studio M2 Ultra — 128 GB mémoire unifiée

NVIDIA RTX 4090 — 24 GB VRAM

Serveur multi-GPU — 2× RTX 4090 (48 GB VRAM totale)

Serveur CPU uniquement — 64 GB RAM, pas de GPU

Erreurs courantes et comment les éviter

Erreur 1 : Définir la longueur de contexte trop haute

Erreur 2 : Oublier la flash attention

Erreur 3 : Ne pas contrôler le déchargement du modèle

Erreur 4 : Ignorer la précision du cache KV

Erreur 5 : Utiliser le délestage GPU sur un modèle qui ne tient pas

Dépannage

LM Studio est lent après le démarrage

Erreurs de mémoire insuffisante

Le GPU n’est pas utilisé

Inférence CPU lente

Le modèle ne charge pas

Prochaines étapes

FAQ

Quel est le meilleur paramètre de délestage GPU ?

Comment augmenter la fenêtre de contexte ?

LM Studio supporte-t-il la flash attention ?

Comment garder le modèle chargé ?

Puis-je exécuter plusieurs modèles à la fois ?

Quel format de modèle dois-je utiliser ?

Comment servir LM Studio sur le réseau local ?

Quelle est la meilleure quantification du cache KV ?

Sources