Relais et proxy d'API Embedding : lots, facturation et migration (2026)

Un relais d'API Embedding est souvent présenté comme un simple changement d'adresse, un peu moins cher. Mais la vectorisation est une tâche par lots : une migration peut porter sur des centaines de milliers de textes. Si le relais limite le débit, tronque les entrées ou change discrètement de modèle, la perte ne se limite pas à une requête : c'est la fiabilité de tout l'index qui est en jeu.

Cet article traite quatre questions : les formes que prend un relais, la conception des requêtes par lots, la vérification de la facturation, et la migration avec ses contrôles. Les modèles et tarifs applicables sont ceux de la page Tarifs des modèles.

Remarque : OpenAI et les autres noms de modèles et de services sont des marques de leurs détenteurs respectifs. Cet article n'a aucun lien de rattachement avec les fournisseurs cités et ne constitue pas une recommandation d'un service en particulier. Le marché des relais évolue rapidement.

1. Relais, proxy et passerelle ne sont pas synonymes

• Proxy réseau : il ne règle que l'accessibilité réseau et transmet les requêtes HTTP ou HTTPS ; la clé reste gérée par vous.
• Relais commercial : le fournisseur transmet vers l'amont, éventuellement avec facturation, quotas, journaux et factures ; il existe aussi des formes de clés partagées ou revendues, dont la stabilité dépend de l'exploitant.
• Passerelle IA unifiée : elle offre un point d'entrée compatible OpenAI, agrège plusieurs modèles, délivre des clés distinctes et fournit une console avec statistiques d'usage.
• Proxy auto-hébergé : vous déployez vous-même un reverse proxy ou une passerelle ; le contrôle est maximal, mais l'exploitation et les comptes amont restent à votre charge.

Avant de signer, vérifiez quel niveau de service est fourni, à qui appartient la clé et où passent les données. Sans cette clarification, toutes les comparaisons qui suivent perdent leur sens.

Critère	Accès direct	Proxy auto-hébergé	Relais commercial	Passerelle IA unifiée
Base de facturation	Facture de l'éditeur, règles claires	Facture amont plus coûts internes	Dépend de l'exploitant, rapprochement nécessaire	Facturation unifiée sur la plateforme
Débit par lots	Limité par le compte	File d'attente possible, limite amont	Pool partagé possible, à vérifier	Selon quotas et ordonnancement
Propriété de la clé	Vous la détenez	Vous la détenez	Partagée ou revendue possible	Généralement clé dédiée
Périmètre des données	À évaluer vous-même	Sous votre responsabilité	Conditions et conservation à auditer	Conditions et qualifications à auditer
Factures et contrat	Selon l'entité	Pas de contrat tiers	Selon le fournisseur	Facturation généralement possible
Coût d'exploitation	Moyen	Élevé	Faible à moyen	Faible

2. Requêtes par lots : tester avant de parler prix

Le débit d'Embedding dépend de trois variables : le nombre d'éléments par requête, la longueur de chaque texte et le niveau de concurrence. Les fournisseurs imposent des plafonds sur le nombre d'éléments, le total de tokens et la taille du corps de requête. Au-delà, la réponse peut être une erreur de paramètre, ou une troncature silencieuse par une couche intermédiaire.

Les tests de charge doivent utiliser des données de production. Prenez un lot réel de fragments de documents, assemblez-les en petites, moyennes et grandes requêtes, puis observez la durée par lot, la latence P95, la proportion de 429 et les types d'erreur. Un lot plus gros n'est pas toujours meilleur : en cas d'échec, la reprise coûte plus cher et le délai d'expiration est plus difficile à maîtriser.

Procédure de découpage recommandée :

1. Analysez d'abord la distribution des longueurs de texte et estimez en tokens plutôt que de découper au nombre d'éléments.
2. Fixez un plafond par lot en gardant une marge pour les textes longs.
3. Démarrez avec une concurrence faible, augmentez à chaque tour et notez le débit et le taux d'erreur.
4. Arrêtez d'augmenter la concurrence une fois le débit cible atteint, pour ne pas saturer la marge.
5. Enregistrez sur disque l'empreinte de chaque entrée, la consommation de tokens et les résultats, pour le rapprochement et la reprise.

3. Reprises et échecs partiels

Les requêtes Embedding sont des opérations en lecture seule : une reprise ne crée pas d'écriture en double, mais elle transforme un échec en facture. Les 429 et les 5xx transitoires justifient un backoff exponentiel avec gigue aléatoire ; les 401, 403, 404 et les erreurs de paramètre doivent arrêter immédiatement le traitement, le temps de corriger la clé, l'adresse ou le corps de requête.

Les échecs partiels se traitent séparément. Si 3 éléments sur 200 sont refusés pour dépassement de longueur, ne relancez pas le lot entier indéfiniment : isolez les textes problématiques, corrigez-les ou tronquez-les, puis soumettez-les à part, tandis que le reste est indexé normalement. Utilisez un hachage du contenu comme clé d'upsert pour qu'une reprise ne crée pas de doublons.

import hashlib
import os
import time
from openai import OpenAI

client = OpenAI(
    api_key=os.environ["RELAY_API_KEY"],
    base_url=os.environ["RELAY_BASE_URL"],
    timeout=60.0,
    max_retries=0,
)
MODEL = os.environ["EMBEDDING_MODEL"]

def key_of(text):
    return hashlib.sha256(text.encode("utf-8")).hexdigest()

def embed_with_retry(batch, attempts=4):
    for i in range(attempts):
        try:
            resp = client.embeddings.create(model=MODEL, input=batch)
            store = {
                key_of(batch[d.index]): d.embedding
                for d in resp.data
            }
            return store, resp.usage
        except Exception as exc:
            if i == attempts - 1:
                raise
            time.sleep(min(2 ** i, 30))

texts = ["Premier extrait", "Deuxième extrait", "Troisième extrait"]
store, usage = embed_with_retry(texts)
print(len(store), len(next(iter(store.values()))), usage)

4. Transparence de la facturation

Embedding est généralement facturé aux tokens d'entrée, sans tokens de sortie, ce qui diffère des modèles de conversation. Pour le rapprochement, demandez explicitement :

• comment les tokens sont comptés et si le découpage correspond au tokenizer de l'éditeur ;
• si les requêtes en échec et les reprises sont facturées ;
• s'il existe des remises sur les lots, du cache ou des paliers ;
• si l'usage peut être exporté par projet, par clé et par modèle ;
• si le prépaiement a une durée de validité et si le solde est remboursable ;
• comment sont déterminés le contenu, la devise et le taux de conversion des factures.

Un « multiplicateur bas » ne signifie pas un coût total bas. Si le relais facture aussi les reprises échouées, ou si les statistiques d'usage ne correspondent pas au champ usage des réponses, l'économie est absorbée par des pertes invisibles. Les prix et règles applicables sont ceux de la page Tarifs des modèles et de la facture du fournisseur ; ne vous fiez pas aux promesses orales.

5. Risques liés aux clés et périmètre des données

Le point le plus souvent négligé avec un relais est la propriété de la clé. Une clé partagée, des crédits revendus ou un solde d'origine incertaine peuvent poser quatre problèmes : l'activité s'interrompt avec le blocage du compte amont ; le partage entre plusieurs locataires fait que les limitations de débit se répercutent mutuellement ; le contenu des requêtes passe par un tiers, avec des journaux et une conservation opaques ; si les conditions interdisent la revente, les litiges manquent de base contractuelle.

Lors du choix, vérifiez au minimum l'entité juridique, les conditions de service, la politique de confidentialité, le lieu de conservation des données, la capacité de facturation et le contact en cas d'incident. Ne transmettez pas de textes contenant des données personnelles, des contrats ou des secrets à un relais incapable d'expliquer où vont les données. Pour les contextes très réglementés, évaluez en priorité l'accès direct, le déploiement privé ou un service acceptant un accord de traitement des données.

6. Liste de migration

Pour passer de l'accès direct à un relais ou à une passerelle, procédez dans l'ordre :

1. Inventoriez les modèles, dimensions, paramètres de lots et structure d'index existants, et relevez le taux de succès et la latence P95 de référence.
2. Exécutez un échantillon fixe en accès direct et conservez les vecteurs, l'usage et les durées.
3. Créez une clé de test avec un budget et des alertes ; ne réutilisez pas directement la clé de production.
4. Ne changez que base_url et api_key, puis validez la requête minimale en préproduction.
5. Appelez le relais avec le même échantillon et comparez dimensions, nombre d'éléments, usage et similarité cosinus.
6. Faites passer 5 % à 10 % des tâches par lots en production pendant 3 à 7 jours, en conservant l'accès direct comme repli.
7. Après la migration complète, rapprochez pendant une semaine la facture, le nombre d'éléments indexés et les reprises.
8. Conservez au moins une version de l'ancien index avant de le supprimer, une fois la qualité de recherche confirmée.

Si le relais change de modèle, les anciens vecteurs ne peuvent pas être mélangés aux nouveaux. Créez un index parallèle, recalculez tout, comparez la qualité de recherche, puis décidez de la bascule.

7. Comment vérifier la fiabilité d'un relais

• Cohérence des vecteurs : envoyez la même entrée en direct et via le relais, puis comparez dimensions et similarité cosinus ; en cas d'écart net, cherchez d'abord un changement de modèle ou une troncature.
• Cohérence de l'usage : rapprochez le champ usage des réponses et la facture, lot par lot, en vérifiant surtout la double facturation des échecs et des reprises.
• Latence et taux d'erreur : testez aux heures de pointe avec des lots réels et notez P50, P95, 429 et 5xx.
• Plafonds par lot : vérifiez les limites de nombre d'éléments, de tokens totaux et de taille du corps pour éviter la troncature en production.
• Isolation des clés : confirmez que la clé est dédiée, qu'elle peut être renouvelée et que quotas et limitations ne sont pas partagés avec d'autres clients.
• Contrat et support : examinez l'entité, les conditions, la facturation et le délai de réponse aux tickets ; un simple contact personnel ou un refus de fournir le détail d'usage sont des signaux d'alerte.

Le champ model renvoyé dans la réponse ne suffit pas comme preuve : il peut être réécrit. Une vérification combinée est plus fiable qu'un contrôle isolé.

8. Quand il ne faut pas utiliser de relais

Un relais n'est pas forcément rentable lorsque les données sont sensibles et que la conservation ne peut pas être auditée, lorsque vous avez besoin du support direct de l'éditeur, lorsque le volume d'appels est très faible, ou lorsque l'équipe n'a personne pour le rapprochement de facturation. Un relais ne contourne pas non plus les limitations ni les conditions d'utilisation de l'amont. Pour une vectorisation occasionnelle à petite échelle, l'accès direct avec un script simple est souvent plus serein.

Si vous avez besoin d'un point d'entrée unifié et d'une comparaison entre modèles, vous pouvez créer une clé de test sur ZSQH AI Gateway, vérifier la cohérence des vecteurs sur un échantillon fixe, puis migrer les tâches par lots ; les modèles disponibles et les modalités de facturation figurent sur la page Tarifs des modèles.

Pour aller plus loin :

• Erreurs de l'API Embedding : diagnostic et reprises
• Clé API Embedding : création et sécurité
• Tarifs des modèles

Questions fréquentes

Quelle différence entre un relais Embedding et un relais de chat ?

Un relais de chat privilégie le flux en continu et la latence du premier token ; un relais Embedding privilégie le débit par lots, les plafonds par requête, la reprise après échec et la cohérence des vecteurs. Pour le rapprochement, notez aussi qu'Embedding ne facture en général que les tokens d'entrée.

Peut-on mélanger les vecteurs renvoyés par un relais et ceux de l'accès direct ?

Uniquement avec le même modèle et la même version. Les espaces vectoriels de modèles différents ne sont pas compatibles, même à dimensions égales. Avant une migration, comparez la similarité cosinus sur un échantillon fixe.

Que faire si la moitié d'un lot échoue ?

Identifiez d'abord le type d'échec : limitation de débit et 5xx transitoires peuvent être réessayés avec backoff ; dépassement de longueur ou erreur de paramètre imposent d'isoler les textes concernés. Utilisez un hachage du contenu comme clé d'idempotence et ne complétez que les éléments manquants.

Sur quelle base la facturation d'un relais est-elle calculée ?

Le plus souvent sur les tokens d'entrée, mais le mode de comptage, la facturation des échecs et des reprises, et l'existence de remises varient. Faites foi sur la facture et le détail d'usage, et consignez ces points dans votre tableau comparatif avant de signer.

Faut-il revectoriser après une migration vers un relais ?

Avec le même modèle et la même version, ce n'est généralement pas nécessaire ; avec un autre modèle, la reconstruction de l'index est obligatoire. Même sans recalcul, conservez l'ancien index, une voie de repli et une validation de cohérence sur échantillon fixe.