Liquid AI d1 API : hébergé ou local ?

Liquid AI d1 mérite une évaluation lorsque l'application attend une catégorie, une décision oui/non ou une note. L'API hébergée d1 coûte 0,04 dollar US par million de tokens en entrée, sans tokens de sortie générés. En local, d1-3B traite le texte et les images ; d1-omni-600M, plus petit et expérimental, accepte aussi la parole. Une même famille de modèles ne garantit pas une qualité identique.

L'API permet de valider un usage sans exploiter de serveur de modèles. Les poids ouverts deviennent intéressants pour fonctionner hors ligne, maîtriser les flux de données ou réduire la latence sur l'appareil. À ce tarif, économiser des tokens ne suffit pas à justifier l'auto-hébergement.

À quoi sert d1 ?

Liquid a présenté le modèle hébergé le 5 octobre, puis les poids ouverts le 7 octobre 2026. Ces modèles renvoient une décision typée en une passe de calcul, sans rédiger de réponse token après token :

• noul : probabilité d'une réponse « oui », par exemple pour détecter une demande de remboursement.
• choice : choix parmi des catégories nommées, avec leurs probabilités.
• score : position pondérée par les probabilités sur une échelle ordonnée définie à l'avance.

Cela convient au routage des tickets, au reclassement des résultats de recherche et aux contrôles de texte ou d'images. Produire du code, un résumé ou une explication libre reste un travail de modèle génératif. Le guide de migration précise cette frontière. Notre guide Jev présente une autre API de décision et son propre contrat d'intégration.

Comparer les trois options

La fiche du modèle 600M impose des limites : images ou audio par requête, jamais les deux ; avec une image, les textes de l'état et des questions sont tronqués à 896 tokens. L'audio est un extrait mono à 16 kHz, de 30 secondes maximum, entraîné sur des demandes en anglais entre un locuteur et un assistant. Cela ne démontre pas une précision multilingue et ne constitue pas un service de transcription.

Liquid publie 48,57 pour d1-3B et 15,95 pour d1-omni-600M sur Decision Index 0.2.1. Ces résultats utilisent le système officiel de notation, sans soumission au classement. Ils justifient de commencer par le grand modèle si la qualité prime, sans prouver qu'il gagne chaque tâche ni qu'il égale le modèle hébergé.

Ce que facture le tarif de 0,04 dollar

La méthodologie de l'annonce donne ce prix par million de tokens d'entrée. La documentation API précise que chaque question est facturée pour son texte et toutes les images fournies. Regrouper des questions dans une requête HTTP ne signifie donc pas facturer l'entrée commune une seule fois.

Pour 100 000 requêtes hypothétiques, avec 1 000 tokens facturés par question :

• Une question par requête : 100 000 × 1 000 ÷ 1 000 000 × 0,04 dollar = 4 dollars US.
• Trois questions de 1 000 tokens chacune : 12 dollars US.

Ces calculs excluent taxes et autres frais. Longueur des questions et nouvelles tentatives modifient la facture. Consultez usage.input_tokens ; usage.output_tokens reste à zéro malgré la réponse JSON.

Chaque image ajoute, par question, ceil(ceil(width / 32) × ceil(height / 32) × 1.5) tokens. Une image 1024 × 1024 représente 1 536 tokens, soit 0,00006144 dollar US, hors texte. Trois questions représentent 4 608 tokens d'image. Il s'agit de compréhension d'image, pas de génération, ni d'un tarif OmniaKey.

Le déploiement local coûte-t-il moins cher ?

Comptez l'amortissement ou la location du matériel, l'électricité, le travail d'ingénierie, la supervision, la licence éventuelle et le traitement des décisions erronées. Des poids gratuits à télécharger ne rendent pas l'exploitation gratuite.

Un budget local purement hypothétique de 50 dollars US par mois équivaut à 1,25 milliard de tokens d'entrée au tarif hébergé : 50 ÷ 0,04 × 1 000 000. À 1 000 tokens facturés par requête, cela représente 1,25 million de requêtes. Ce n'est ni un devis matériel ni une démonstration d'équivalence des modèles.

Le fonctionnement hors ligne, la maîtrise des données ou la latence peuvent néanmoins justifier le local à plus faible volume. Comparez le coût total par décision acceptée, en conservant le compte des erreurs et des vérifications humaines.

Licence et besoins matériels

Les deux dépôts utilisent LFM Open License v1.0. Le guide de licence décrit un usage commercial gratuit sous 10 millions de dollars US de chiffre d'affaires annuel, avec une licence commerciale distincte au-dessus. À la limite du seuil, confirmez votre éligibilité avec Liquid au regard du texte applicable. La redistribution impose aussi licence, mentions d'attribution, NOTICE le cas échéant et signalement des fichiers modifiés ; les clients en aval doivent examiner leur propre éligibilité. Consultez les licences de d1-3B et du 600M. Des poids ouverts ne signifient pas une licence Apache-2.0 sans restriction.

Le nombre de paramètres multiplié par deux octets donne environ 6,24 Go et 1,174 Go pour les seuls poids en 16 bits, en unités décimales. Ce ne sont pas des minima de RAM ou de VRAM : tampons, activations, traitement des médias et lots ajoutent de la mémoire. La quantification peut aussi modifier la qualité.

La fiche 3B indique 8 ms sur RTX 4090 et 30 ms sur Apple M5 Pro pour une question après préchauffage. Avec un état de 3,4K tokens, les valeurs passent à 102 et 640 ms. La mesure RTX utilise la compilation. Ces mesures du fournisseur ne sont ni des démarrages à froid ni des garanties de latence API. Aucune durée d'inférence n'est publiée pour le 600M expérimental.

Appeler l'API et démarrer en local

Le point d'accès hébergé est POST /decisions/v1/systemone, avec un schéma différent de Chat Completions. Placez une clé créée dans la console Liquid dans LIQUID_API_KEY. Cet exemple commun utilise une demande de support en anglais ; son exécution est facturable :

curl --fail-with-body https://api.liquid.ai/decisions/v1/systemone \
  -H "Authorization: Bearer $LIQUID_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "d1",
    "state": "Please refund the duplicate charge.",
    "questions": {
      "refund": {"type": "noul", "instructions": "Is a refund requested?"}
    }
  }'

La probabilité se lit dans answers.refund.noul. Définissez le seuil sur vos propres exemples annotés. Pour les images, l'API attend des données Base64, pas une URL distante.

En local, utilisez une version récente de llama.cpp prenant en charge d1, puis la recette GGUF officielle :

llama-server -hf LiquidAI/d1-3B-GGUF:Q8_0

Dans un second terminal, appelez le point d'accès local :

curl --fail-with-body http://127.0.0.1:8080/v1/systemone \
  -H "Content-Type: application/json" \
  -d '{
    "state": "Please refund the duplicate charge.",
    "questions": {
      "refund": {"type": "noul", "instructions": "Is a refund requested?"}
    }
  }'

Pour le petit modèle, arrêtez d'abord ce serveur puis suivez la recette 600M :

llama-server -hf LiquidAI/d1-omni-600M-GGUF:Q8_0 -b 4096 -ub 4096

Les tailles de lot doivent contenir une question entière ; la fiche prévoit de les augmenter jusqu'à 16 384 pour les états longs. Nous avons vérifié ces commandes dans la documentation sans les exécuter. Notez modèle, quantification et version du moteur lors de vos essais.

Quelle option évaluer en premier ?

d1 hébergé est un point de départ pratique pour un service connecté à volume faible ou incertain. d1-3B est le premier candidat local pour texte et images au vu des résultats publiés. d1-omni-600M mérite une évaluation distincte si la parole ou l'encombrement prime, en acceptant ses limites expérimentales.

Gardez les mêmes tâches annotées, catégories et critères d'acceptation. Mesurez erreurs de routage, cas manqués, latence p95, mémoire maximale et fréquence du recours à un humain ou à un autre modèle. Des probabilités en sortie ne garantissent pas une bonne calibration dans votre langue et sur vos données.

Le catalogue OmniaKey indique les modèles et tarifs actuels de la passerelle. Cet article documente les options Liquid et locales, sans établir la disponibilité de d1 chez OmniaKey. Pour la génération complémentaire, comparez séparément les modèles du catalogue.