Skip to main content
Il s’agit de profils composites basés sur des modèles de déploiement courants. Chacun capture des compromis réels, des chiffres et des leçons tirées de l’exécution de modèles locaux en production ou pour un usage personnel.

Développeur solo : assistant de codage sur un MacBook

Configuration : Mac Studio M2 Ultra + Ollama + Claude Code via Tokios Modèle : Qwen3-30B Q5_K_M Temps pour obtenir une configuration fonctionnelle : 20 minutes Un développeur full-stack solo souhaitait un assistant de codage qui conserve le code source sur sa machine. Il exécute Ollama sur un Mac Studio M2 Ultra avec 64 Go de mémoire unifiée et pointe Claude Code vers celui-ci via Tokios.
Ce qui a fonctionné : La bande passante mémoire du M2 Ultra gère bien le modèle 30B. Tokios permet à la même configuration de fonctionner depuis un ordinateur portable en déplacement — il suffit de pointer Claude Code vers api.tokios.com. Limite : La longueur du contexte atteint environ 8K tokens sur ce modèle. Pour les grands codebases avec de nombreux fichiers ouverts, le développeur découpe le travail en sessions plus petites plutôt que de fournir l’intégralité des dépôts.
Leçon clé : Si vous possédez déjà une puce Apple Silicon avec 32 Go+ de RAM, un assistant de codage local coûte $0/mois et garde votre code privé. Tokios ajoute un accès distant sans VPN.

Petite équipe : point de terminaison de modèle partagé pour 5 développeurs

Configuration : Station de travail RTX 4090 + vLLM + connecteur Tokios Modèle : Qwen3-72B FP8 (quantification AWQ) Temps pour une première configuration fonctionnelle : 45 minutes Une équipe backend de 5 personnes partage une seule station de travail RTX 4090 en tant que serveur de modèle d’équipe. Ils utilisent vLLM pour le débit et Tokios pour fournir à chaque développeur une clé API avec des permissions définies.
Ce qui a fonctionné : Accès constant au modèle sans limites de débit. Les clés à périmètre défini signifient que chaque développeur dispose de sa propre clé sk-tok-… — la révocation de l’une n’affecte pas les autres. Piège : Le modèle AWQ 72B tient à peine dans 24 Go de VRAM. Lors d’une utilisation simultanée maximale, vLLM déverse le cache KV vers la mémoire CPU, ce qui ralentit le débit. L’équipe a ajouté --max-num-seqs 8 pour limiter les requêtes simultanées et éviter les plantages OOM. What they’d change: Move to a 48 GB A6000 or add a second GPU for tensor parallelism. See Tensor vs pipeline parallelism.
Leçon clé : Un seul GPU grand public peut servir une petite équipe, mais anticipez les pics de concurrence. Limitez --max-num-seqs pour éviter les erreurs OOM et acceptez une latence plus élevée sous charge.

Passionné de homelab : DGX Spark comme serveur d’inférence toujours actif

Configuration : DGX Spark + vLLM + Tokios + Tailscale (pour l’accès LAN) Modèles : Collection rotative — Qwen3-30B pour l’usage quotidien, DeepSeek-R1 pour les tâches de raisonnement, Phi-4 pour la classification rapide Temps pour une première configuration fonctionnelle : 1 heure (incluant les téléchargements de modèles) Un passionné de homelab utilise un DGX Spark 24/7 comme serveur d’inférence personnel. La mémoire unifiée de 128 Go lui permet de garder un grand modèle chargé et de basculer vers d’autres selon les besoins. Tokios expose les modèles à son téléphone, son ordinateur portable et ses scripts d’automatisation domestique.
Ce qui a fonctionné : La mémoire unifiée de 128 Go du DGX Spark convient aux modèles qui nécessiteraient 2–3 GPU grand public. L’exécution de plusieurs instances vLLM sur des ports différents leur permet de servir 3 modèles simultanément. Le routage des modèles Tokios signifie que leur application téléphonique modifie simplement le champ model pour basculer entre le chat quotidien et le raisonnement approfondi. Conseil : Utilisez le routage des modèles pour sélectionner automatiquement un déploiement selon le type de requête. Pointez les clients de chat vers daily et les scripts d’automatisation vers classifier.
Leçon clé : Un DGX Spark en tant que serveur toujours actif coûte 8–15 $/mois en électricité et vous offre une inférence illimitée sur des modèles qui ne tiennent pas sur le matériel grand public. La mémoire unifiée de 128 Go est le véritable facteur différenciant.

Démarrage : modèles locaux pour le traitement des données clients

Configuration : 2x A100 80 Go + vLLM + Tokios Modèles : Llama 3.1 70B pour l’analyse, Phi-4 pour la classification Temps pour la première configuration fonctionnelle : 2 heures (y compris l’infrastructure) Une startup de 10 personne traite des documents clients contenant des données financières sensibles. La conformité exige que ces données ne quittent jamais leur infrastructure. Ils exécutent 2 instances vLLM distinctes — 1 pour l’analyse, 1 pour la classification — et exposent les deux via Tokios.
Architecture : Leur pipeline de traitement envoie les documents au déploiement analyzer pour la résumption et l’extraction d’entités, puis route les champs extraits vers le déploiement classifier pour la catégorisation. Les deux modèles s’exécutent sur des A100s distincts pour éviter la contention de la VRAM. Ce qui a fonctionné : Des déploiements séparés pour différentes tâches signifient qu’ils peuvent mettre à l’échelle, redémarrer ou remplacer les modèles indépendamment. Les clés limitées par scope de Tokios restreignent le service de traitement aux seuls déploiements analyzer et classifier. Ce qu’ils changeraient : Ajouter un 3rd modèle pour la vérification de la qualité. Le pipeline actuel à 2 modèles classe parfois incorrectement les cas limites qu’un modèle de raisonnement plus grand aurait détectés.
Leçon clé : Lorsque la conformité exige des données sur site, les modèles locaux rentrent vite. Des déploiements séparés par tâche offrent une mise à l’échelle indépendante et une isolation des pannes. Cette startup a atteint son seuil de rentabilité en 3 mois par rapport aux coûts de GPU cloud.

Chercheur : évaluation comparative entre différentes quantifications

Configuration : RTX 4090 + llama.cpp + lm-evaluation-harness Tests : Même modèle (Qwen2.5-7B) en Q4_K_M, Q5_K_M, Q8_0, FP16 Temps pour l’ensemble complet des benchmarks : 3 heures Un chercheur en ML a dû mesurer l’impact de la quantification sur les scores d’évaluation pour une tâche spécifique (génération de code). Il a exécuté le même modèle à 4 niveaux de quantification et a comparé la perplexité et les taux de réussite.
Résultat : Q5_K_M a obtenu des scores à 2.2 points de pourcentage près de ceux de FP16 tout en s’exécutant presque deux fois plus vite. Pour les tâches de génération de code de ce chercheur, Q5_K_M est le point idéal. Comment Tokios a aidé : L’enregistrement de chaque quantification en tant que déploiement distinct (bench-q4km, bench-q5km, bench-q8, bench-fp16) a permis au harnais d’évaluation de basculer entre eux en modifiant uniquement le champ model. Les résultats étaient directement comparables car le harnais appelait la même forme d’extrémité pour chaque exécution.
Leçon clé : Q5_K_M est le point idéal pour la plupart des tâches d’évaluation 7B — à 2–3% de la qualité de FP16 à près de 2x la vitesse. Enregistrez chaque quantification en tant que déploiement Tokios distinct pour les tester via une API cohérente.

Modèles courants dans toutes les études de cas

Prochaines étapes

Recettes

Configurations à copier-coller pour 8 configurations courantes de LLM local.

Évaluez votre déploiement

Benchmarks structurés pour comparer vos choix de matériel et de modèle.

Routage de modèle

Enregistrez plusieurs déploiements et basculez entre eux.

Choisissez un modèle local

Sélectionnez le modèle et la quantification adaptés à votre matériel.