Points clés
- Les poids du modèle nécessitent environ 2 octets par paramètre en 16-bit, 1 en 8-bit et 0,5 en 4-bit, plus de la place pour le cache de contexte.
- Un GPU loué facture chaque heure d'allumage, tandis qu'une API facture uniquement les tokens envoyés et reçus.
- À $0,15 par 1M de tokens d'entrée et $0,50 par 1M de tokens de sortie, 20 000 conversations par jour de 1 500 entrées et 500 sorties coûtent $285 par mois.
- L'hébergement autonome gagne quand vous avez besoin d'un fine-tuning, d'un modèle différent, d'une utilisation hors ligne ou d'un volume élevé et constant.
La réponse courte : cela dépend de votre volume
Si vous vous demandez comment héberger des poids LLM vous-même, la synthèse honnête est qu'il est facile de faire répondre un modèle sur votre propre machine et difficile de le faire tourner à moindre coût pour d'autres personnes. Un laptop ou un GPU de bureau suffit pour un usage personnel. Un service qui doit répondre à de nombreux utilisateurs à la fois, à toute heure, a besoin de plus de mémoire, de plus de réglages et de quelqu'un pour le maintenir en activité.
L'alternative est d'appeler un endpoint compatible OpenAI hébergé et de payer par token. Pour les charges de travail petites et moyennes, c'est presque toujours moins cher, car vous ne payez jamais pour le temps GPU inactif. Pour les charges de travail très importantes et stables, ou pour les tâches nécessitant votre propre modèle fine-tuné, posséder le matériel commence à avoir du sens. Les sections ci-dessous donnent des chiffres des deux côtés pour que vous trouviez votre propre point d'équilibre.
Il n'y a pas de plan gratuit. Vous pouvez activer un crédit d'essai unique de 0,50 $ sur la page clé API après vous être connecté, puis ajouter du crédit prépayé à partir de 20 $. Le crédit d'essai suffit pour effectuer un test réel de vos propres prompts avant de prendre une décision.
Ce que nécessite réellement l'hébergement d'un modèle
Un modèle de langage est un gros fichier de nombres, les poids, qui doit résider en mémoire rapide pendant l'exécution du modèle. La taille de ce fichier est la première contrainte, et vous pouvez la calculer vous-même : paramètres multipliés par octets par paramètre.
| Taille du modèle | Poids 16-bit | Poids 8-bit | Poids 4-bit |
|---|---|---|---|
| 8B paramètres | 16 Go | 8 Go | 4 Go |
| 32B paramètres | 64 Go | 32 Go | 16 Go |
| 70B paramètres | 140 Go | 70 Go | 35 Go |
Ce sont uniquement des poids. En plus, vous avez besoin de mémoire pour le cache clé-valeur, qui augmente avec la longueur de chaque conversation active, et d'une marge pour le moteur d'exécution. Un modèle qui tient théoriquement dans 24 Go peut manquer de mémoire dès que vous demandez un contexte long ou plusieurs utilisateurs simultanés. La quantification en 4 bits réduit le fichier, mais elle modifie légèrement la qualité des sorties, et l'effet varie selon le modèle.
Ensuite, il y a le côté logiciel. Vous avez besoin d'un serveur d'inférence tel que llama.cpp, Ollama ou vLLM, d'une couche HTTP pour que vos applications puissent l'appeler, d'un moyen de le redémarrer en cas de crash, et de la surveillance pour remarquer quand il tombe en panne. Rien de tout cela n'est difficile isolément. Tout cela prend du temps, et le temps fait partie du coût.
Option 1 : le faire tourner sur votre propre ordinateur
Le moyen le moins cher de commencer est la machine que vous possédez déjà. Des outils comme Ollama et llama.cpp téléchargent un modèle et exposent un serveur local, et beaucoup d'entre eux offrent également un endpoint de style OpenAI, donc le code que vous écrivez contre eux peut plus tard pointer vers une API hébergée en changeant deux paramètres.
L'hébergement local est un bon choix quand :
- vous êtes une seule personne à expérimenter, et quelques secondes par réponse sont acceptables ;
- les données ne doivent jamais quitter la machine ;
- vous voulez essayer rapidement plusieurs modèles ouverts différents ;
- vous avez un GPU avec suffisamment de mémoire et il est inactif la plupart du temps de toute façon.
C'est un compromis faible lorsque vous devez servir d'autres personnes, lorsque le modèle que vous souhaitez est plus grand que votre mémoire, ou lorsque vous voulez des contextes longs. Notre propre comparaison des modèles uncensored locaux et des API hébergées examine plus en détail les compromis, y compris les différences de qualité des réponses entre les petits modèles locaux et les plus grands modèles hébergés.
L'électricité est une ligne de coût réelle mais faible pour un utilisateur unique. Le coût plus important est le matériel que vous avez dû acheter, que vous l'utilisiez ou non. Si vous le possédez déjà, le coût marginal est faible et l'hébergement local est difficile à battre pour des expériences privées.
Option deux : louer un serveur GPU
Quand votre propre machine ne suffit pas, l'étape suivante est un GPU loué. Les fournisseurs facturent à l'heure une machine avec une quantité donnée de mémoire GPU. Les prix varient beaucoup entre les fournisseurs et changent souvent, donc vérifiez leur tarification actuelle au lieu de faire confiance à n'importe quel nombre que vous lisez dans un article, y compris celui-ci.
Ce qui compte est la forme de la facture. Un serveur loué facture chaque heure où il est allumé, qu'il réponde à une requête ou non. Si vous le laissez allumé tout le mois, l'arithmétique est simple : un mois a environ 730 heures (8 760 heures par an divisées par 12). Supposons, purement comme un exemple supposé et non un devis, qu'un serveur adapté coûte $1 par heure. Le faire tourner 24h/24 coûte alors 730 × $1 = $730 par mois avant d'ajouter le stockage, la bande passante et votre propre temps.
Vous pouvez éteindre le serveur quand vous ne l'utilisez pas, mais alors vous payez avec des délais : charger un grand modèle en mémoire prend du temps, et le premier utilisateur après une pause attend qu'il soit chargé. Les configurations autoscaling réduisent cela, et elles ajoutent leur propre complexité.
Le point d'équilibre contre une API découle du prix. Un million de tokens d'entrée plus un million de tokens de sortie coûtent $0,15 + $0,50 = $0,65 sur cette API. Votre serveur supposé de $730 équivaut à 730 ÷ 0,65 ≈ 1 123 de ces paires, ou environ 1,1 milliard de tokens d'entrée et 1,1 milliard de tokens de sortie en un mois. En dessous de ce volume, l'API coûte moins cher. Au-dessus, un serveur bien utilisé peut gagner, à condition qu'il puisse effectivement suivre ce trafic, ce qui dépend du modèle, du GPU et de la façon dont vous réglez le serveur.
Option trois : utiliser une API hébergée
L'API supprime le matériel, le serveur et le temps d'inactivité. Vous envoyez une requête, vous obtenez une réponse, et vous payez pour les jetons qui ont été utilisés. La tarification est ici de 0,15 $ par 1 M de jetons d'entrée et de 0,50 $ par 1 M de jetons de sortie, avec paiement à l'usage à partir d'un crédit prépayé, sans abonnement. Le crédit n'expire jamais, et les requêtes échouées ou refusées ne sont pas facturées.
Voici à quoi cela ressemble à trois volumes réalistes. Un tour de chat typique est supposé utiliser 1 500 tokens d'entrée (prompt système plus historique) et 500 tokens de sortie.
- Une requête : 1 500 tokens d'entrée coûtent 0,0015 × $0,15 = $0,000225, et 500 tokens de sortie coûtent 0,0005 × $0,50 = $0,00025. Ensemble, cela fait $0,000475.
- 1 000 conversations par jour, 30 jours : 1 000 × $0,000475 = $0,475 par jour, ou $14,25 par mois.
- 20 000 conversations par jour, 30 jours : 20 000 × $0,000475 = $9,50 par jour, ou $285 par mois.
- Un lot de 100 000 requêtes avec 2 000 tokens d'entrée et 400 tokens de sortie chacun : l'entrée est de 200M de tokens, donc 200 × $0,15 = $30 ; la sortie est de 40M de tokens, donc 40 × $0,50 = $20. Le total est $50.
Au chiffre du milieu, l'API coûte $285 par mois, ce qui est bien en dessous des $730 supposés pour un serveur toujours allumé. Au plus grand chiffre, vous auriez besoin de beaucoup plus de trafic avant qu'un serveur loué rattrape son retard. Vos propres prompts décident des chiffres réels, donc mesurez un échantillon au lieu de deviner. Le bloc d'utilisation qui revient avec chaque réponse vous indique les comptes exacts de tokens.
Le crédit d'essai de $0,50 couvre environ 1 052 requêtes de la taille 1 500 entrées, 500 sorties (0,50 ÷ 0,000475 ≈ 1 052), ce qui est largement suffisant pour un test. Ensuite, vous rechargez avec n'importe quel montant entier de $20 à $500. Les recharges plus importantes comportent un bonus : +5% à partir de $50, +10% à partir de $100 et +15% à partir de $200, donc une recharge de $100 donne $110 de crédit. Les détails sont sur la page de tarification. Le paiement se fait par carte (Visa, Mastercard, Apple Pay, Google Pay) ou crypto (USDT sur TRC20, USDC sur Base).
Ce à quoi vous renoncez en n'hébergeant pas
Une API n'est pas exempte de compromis, et il vaut mieux les connaître avant de construire dessus.
- Un seul modèle. Vous obtenez un seul modèle à poids ouverts, désigné sous
uncensored. Vous ne pouvez pas en changer ni charger vos propres poids. - Pas de fine-tuning et texte uniquement. Il n'y a pas d'endpoint d'entraînement, pas d'embeddings et pas de génération d'images, d'audio ou de vidéo.
- Limites. Une clé complète permet 8 requêtes simultanées et 300 requêtes par minute. Une clé d'essai permet 2 et 60. Cela convient à la plupart des applications, mais un lot très important nécessite une file d'attente de votre côté.
- Contexte. La fenêtre est de 100 000 tokens pour le prompt plus la complétion.
- Vos données quittent votre réseau. Les prompts ne sont pas utilisés pour l'entraînement, mais ils voyagent vers un tiers. Si cela n'est pas acceptable pour un jeu de données donné, hébergez localement.
L'auto-hébergement est le meilleur choix lorsque l'une de ces conditions est une exigence stricte : fine-tuning sur vos propres données, un modèle spécifique non proposé par l'API, un fonctionnement entièrement hors ligne, ou un volume régulier suffisamment élevé pour que votre propre matériel reste sollicité en continu.
Essayez l'API avant d'acheter du matériel
Un test d'une heure coûte moins d'une seule heure de la plupart des serveurs loués et vous indique si le modèle répond bien à vos prompts. L'endpoint est compatible OpenAI, donc si vous avez déjà du code qui communique avec un serveur local, vous modifiez uniquement l'URL de base, la clé et l'ID du modèle. Ce script indique également le coût de chaque appel, en utilisant les données d'utilisation dans la réponse :
from openai import OpenAI
client = OpenAI(
base_url="https://api.uncensoredllmhub.com/v1",
api_key="YOUR_API_KEY",
)
resp = client.chat.completions.create(
model="uncensored",
messages=[{"role": "user", "content": "Summarise the pros and cons of self-hosting an LLM."}],
)
u = resp.usage
cost = u.prompt_tokens / 1_000_000 * 0.15 + u.completion_tokens / 1_000_000 * 0.50
print(resp.choices[0].message.content)
print(f"in={u.prompt_tokens} out={u.completion_tokens} cost=${cost:.6f}")Exécutez-le sur quelques dizaines de vos vrais prompts, additionnez les lignes de coût et multipliez par votre volume quotidien prévu. Cela vous donne un chiffre que vous pouvez comparer à l'estimation matérielle. Si vous voulez les détails d'installation, la documentation liste les paramètres pris en charge, y compris le streaming, l'appel de fonctions et le mode JSON.
