NouveauBranchez n’importe quel agent sur UberLLM : une clé, tous les modèles, au prix catalogue ou moins.
UberLLM

Vendeurs

Vous pouvez lister la capacité d'inférence que vous êtes autorisé à revendre sur UberLLM : vos propres GPU, un modèle open-weights auto-hébergé, ou des crédits fournisseur dans le cadre d'un plan qui autorise la revente. Les requêtes d'acheteurs pour un modèle peuvent être acheminées vers votre offre, et vous êtes crédité du montant total payé par l'acheteur pour chaque requête.

Pour lister une offre depuis le navigateur, utilisez la page vendeur : Compte → Vendre de la capacité → Nouvelle offre. Elle vous guide à travers cinq étapes : Fournisseur, Découverte, Test de santé, Tarification, Révision. Rien n'est mis en ligne tant que vous n'avez pas confirmé, et les acheteurs sont dirigés vers une nouvelle offre une fois qu'elle a passé notre vérification du modèle.

Tout ce que la page fait est également une API, donc votre agent peut le faire aussi (voir Pour les agents).

Comment fonctionne une offre

  • Une clé de fournisseur, une base URL, de nombreux modèles. Une offre est un modèle servi via une clé à une adresse. La même clé peut servir autant de modèles que vous le souhaitez, mais vous ne pouvez pas lister le même modèle deux fois avec la même clé et la même adresse — une seconde est refusée avec 409 duplicate_offer_for_credential (et, si l'offre existante est la vôtre, son identifiant dans error.detail.existing_offer_id).
  • Le nom du modèle sur votre serveur peut différer du nôtre (par exemple, nous l'appelons deepseek/deepseek-v4-flash, votre serveur l'appelle deepseek-v4-flash). La découverte les fait correspondre pour vous ; manuellement, envoyez upstream_model.
  • L'adresse de votre serveur doit être publique (https, accessible depuis internet). Les adresses locales, privées et celles d'UberLLM sont refusées.
  • Votre clé est chiffrée au repos, déchiffrée uniquement pour servir une requête qui vous est envoyée, jamais renvoyée par une lecture et jamais journalisée. Une nouvelle clé est testée avant d'être acceptée — si le test échoue, votre ancienne clé reste. La suppression d'une offre efface la clé stockée.

Tarification

Les offres de texte sont tarifées comme une réduction sur le prix catalogue du modèle (le prix qu'un acheteur paierait en allant directement). Envoyez discount_pct (par exemple 45 = 45% de réduction) ou la même chose que multiplier (0.55). Les prix par token (input_usd_per_mtok / output_usd_per_mtok) ne sont plus acceptés pour les modèles de texte.

"match_best": true fixe votre prix à la réduction la plus importante que les acheteurs peuvent obtenir sur ce modèle actuellement. Vous pouvez le modifier à tout moment.

Les acheteurs paient votre prix ; la totalité vous est créditée à chaque fois qu'une requête est complétée. UberLLM ne prend aucune commission sur vos ventes. Votre propre coût est ce que votre fournisseur facture votre clé.

Optionnel daily_cap_usd : une fois que les acheteurs ont dépensé autant sur l'offre en une journée, elle cesse de recevoir des requêtes jusqu'au lendemain.

Santé

La santé est mesurée sur le trafic réel des acheteurs. Les seules autres requêtes que nous envoyons à votre clé sont la requête de test ci-dessous et celles de la vérification du modèle.

  • Lorsque vous listez ou activez une offre, ou changez sa clé, nous envoyons une petite requête de test (elle peut utiliser une infime partie de votre quota).
  • Si une requête d'un acheteur vers vous échoue, l'acheteur est redirigé vers le vendeur suivant et votre offre est retirée du routage pendant un certain temps : 30 s → 1 min → 2 min → 10 min pour les erreurs de serveur et les timeouts, 10 → 20 → 40 → 60 min pour une clé refusée ou un manque de crédit, 15–30 s pour les rate limits. Lorsque l'attente prend fin, votre offre reçoit à nouveau des requêtes ; une requête qui aboutit la réinitialise.
  • Vous l'avez réparé plus tôt ? POST /seller/offers/{id}/reset-health (le bouton Réparé, réessayez) la remet en service immédiatement. Il en va de même pour une nouvelle clé ou adresse qui passe son test.
  • Si votre fournisseur refuse votre clé ou indique que le compte n'a pas de crédit deux fois de suite, nous vous envoyons un e-mail (au maximum une fois par jour) avec les offres concernées.
  • GET /seller/health-log indique, en termes simples, pourquoi une offre a été ignorée et quand elle est revenue.

Vérification du modèle

Les acheteurs paient pour le modèle que vous listez, nous vérifions donc que votre offre le sert réellement.

Les règles

  • Servez le modèle exact que vous listez. Pas un modèle plus petit, moins cher, plus ancien ou différemment réglé, et pas un mélange de modèles.
  • N'ajoutez rien à la requête. Pas d'instructions, de system prompt ou d'outils de votre cru, et rien de coupé de ce que l'acheteur a envoyé. Une application de chat ou un outil de codage revendu qui ajoute ses propres instructions enfreint cette règle.
  • Transmettez les comptes de token inchangés, exactement tels que le modèle les a comptés.

Comment nous vérifions

  • Chaque offre est vérifiée avant qu'un acheteur ne lui soit envoyé. Tant qu'elle n'est pas validée, la page Vente l'affiche comme En vérification ; puis elle passe En ligne. Une nouvelle clé, adresse ou modèle est vérifiée de la même manière.
  • Les offres continuent d'être vérifiées sur le trafic réel tant qu'elles sont listées.
  • Les vérifications utilisent une petite partie de votre quota et sont payées comme toute autre requête.
  • Nous ne publions pas comment les vérifications fonctionnent ni quand elles sont exécutées.

Lorsqu'une offre échoue à une vérification

  • Elle est Mise en pause, et vous ne pouvez pas la réactiver vous-même. Lister la même clé à nouveau comme une nouvelle offre est également refusé.
  • Vos paiements sont retenus pendant que notre équipe l'examine.
  • La page Vente et GET /seller/offers expliquent pourquoi, en termes simples (listing_state: "paused" avec check_reason), et nous vous envoyons un e-mail.
  • Pour la faire vérifier à nouveau, corrigez ce qui sert l'offre, puis écrivez à [email protected].

Lorsqu'un vendeur est surpris en train de servir un modèle différent de celui listé

  • Votre compte vendeur est suspendu et toutes vos offres s'arrêtent immédiatement.
  • Les gains non encore versés sont confisqués et utilisés pour rembourser les acheteurs que vos offres ont servis. Les paiements non encore envoyés sont annulés.
  • Vous ne pouvez plus lister sur UberLLM, avec la même clé de fournisseur, le même serveur, la même adresse de paiement ou le même e-mail.
  • La page Vente l'indique, et GET /seller/offers répond listing_state: "suspended". Écrivez à [email protected] à ce sujet.

Modèles open-weight : indiquez comment vous les exécutez

Les modèles open-weight (GPT-OSS, Qwen, DeepSeek, GLM, Kimi, MiniMax et d'autres dont les poids sont publiés) peuvent être exécutés en pleine qualité ou compressés pour économiser de la mémoire. Une copie compressée répond un peu moins bien, et aucun test ne peut la distinguer de manière fiable du modèle complet. Ainsi, lorsque vous listez un modèle open-weight, vous indiquez comment votre serveur l'exécute, et les acheteurs voient votre réponse sur la page du modèle :

  • Pleine qualité (16-bit) : les poids tels que publiés (bf16 / fp16), ou mieux.
  • 8-bit : fp8 ou int8.
  • Inférieur à 8-bit (6-bit ou 4-bit) : tout ce qui est plus petit.

Une nouvelle annonce d'un modèle open-weight nécessite l'une des trois options. Les offres listées avant 1 novembre 2026 affichent "Précision non indiquée" jusqu'à ce que vous la définissiez (page Vente → l'offre → Prix et précision). Indiquer une précision supérieure à celle que votre serveur exécute réellement est un modèle différent de celui listé : le compte est suspendu, comme ci-dessous. Les modèles fermés (Claude, GPT-5, Gemini…) ne le demandent pas.

Comptes de token gonflés

Lorsque votre serveur signale beaucoup plus de prompt tokens qu'une requête n'en contient réellement, l'acheteur est facturé, et vous êtes payé, pour au maximum environ 2× notre propre compte des prompt tokens de la requête, plus une petite allocation pour les définitions d'outils et les images. En dessous de cela, les requêtes sont facturées exactement comme votre serveur les signale.

Gains et paiements

  • GET /seller/earnings?range=7d|30d|90d|all — gains, ventes et tokens, par modèle, avec le marché autour de chacun de vos modèles (la réduction la moins chère actuellement et la réduction réelle du marché au cours de la dernière heure) afin que vous puissiez voir comment fixer vos prix.
  • GET /seller/payouts — disponible pour paiement (owed_usd), en attente (held_usd, et next_release_at : quand la prochaine partie sera prête), en cours et payé comme des chiffres distincts, où vos paiements sont envoyés (payout_method, null jusqu'à ce que vous le configuriez), plus votre historique de paiements.
  • PUT /seller/payout-method {method, address} — où envoyer votre argent : {"method":"paypal","address":"[email protected]"} (l'e-mail de votre compte PayPal) ou {"method":"usdc_base","address":"0x…"} (votre portefeuille sur Base, 0x et 40 caractères hexadécimaux ; nous envoyons des USDC uniquement sur le réseau Base). Répond au {method, address, set_at} enregistré. Dans la console : Vente → Paiements → Où nous envoyons votre argent.

Les gains sont retenus avant de pouvoir être payés : 14 jours pendant que vous êtes un nouveau vendeur (vos 30 premiers jours, ou jusqu'à ce que vous ayez gagné $500 au total), puis 7 jours. De cette façon, les acheteurs peuvent être remboursés si une offre s'avère ne pas correspondre au modèle qu'elle liste. La page Vente affiche Disponible pour paiement et En attente, avec la date à laquelle la prochaine partie sera prête.

Une fois débloqué, ce qui est disponible est automatiquement inclus dans un paiement dès qu'il atteint $5, ou 72 heures après que votre vente impayée la plus ancienne soit sortie de la période de retenue (vérifié toutes les 10 minutes). Vous pouvez également en demander un à tout moment (POST /seller/payouts/request, le bouton Payez-moi maintenant). Vous avez un seul paiement en cours à la fois : ce que vous gagnez entre-temps reste dû et sera inclus dans votre prochain paiement une fois que le paiement actuel aura été effectué (demander un autre paiement répond à 409 payout_already_on_the_way).

Notre équipe envoie chaque paiement à l'e-mail PayPal ou au portefeuille USDC (Base) que vous avez configuré, généralement dans les 2 jours ouvrables suivant son initiation. Si un paiement est initié avant que vous n'ayez configuré un mode de paiement, nous envoyons un e-mail aux propriétaires de votre compte pour leur demander, et l'envoyons une fois que vous l'avez fait. Un paiement n'est considéré comme payé qu'une fois qu'il a réellement été envoyé ; la référence du paiement s'affiche alors à côté, et nous vous envoyons un e-mail pour vous informer de son envoi.

Si un paiement ne peut pas être livré (par exemple, l'e-mail PayPal ne peut pas recevoir d'argent), il apparaît comme Échec avec la raison. Rien n'est perdu : le montant vous est à nouveau dû et sera inclus dans votre prochain paiement, et nous vous envoyons un e-mail pour vérifier où nous envoyons votre argent.

API

Une fois connecté sur le web, l'API vendeur se trouve à /api/v1/seller. Avec votre clé API UberLLM (celle que votre agent a obtenue lors de la connexion à uberllm), la même API se trouve à /v1/seller :

Appel Fonctionnalité
POST /seller/register {display_name?} Commencer à vendre (une fois). Le nom est facultatif : s'il est omis, vous apparaissez comme « Seller » plus 4 lettres. La page de vente le fait pour vous.
GET /seller/providers Fournisseurs et leurs base URLs.
POST /seller/discover {base_url, api_key} ou {config_id} Les modèles qu'une clé peut servir, mis en correspondance avec les nôtres (open_weights: true = le lister nécessite un precision). Ne coûte aucun quota.
POST /seller/test {base_url, api_key, models[]} Une petite requête de test par modèle.
POST /seller/offers/bulk Lister plusieurs modèles sur une clé : {endpoint_url, api_key, save_config, daily_cap_usd, precision, offers:[{model_id, upstream_model, precision, discount_pct | match_best}]}. precision (full, 8bit ou below8) est requis pour les modèles open-weight ; celui de niveau supérieur s'applique à chaque modèle open-weight du lot. Chaque modèle est testé au moment de sa liste ; celui qui échoue est omis avec la raison.
POST /seller/offers Lister un modèle : {model_id, endpoint_url, api_key, upstream_model, precision, discount_pct, daily_cap_usd}.
GET /seller/offers · GET /seller/offers/{id} Vos offres avec prix, % de réduction, état de santé, statut (listing_state : checking, live, paused ou suspended, avec check_reason lorsqu'il a échoué au model check) et classement en direct (votre position parmi tout ce vers quoi les acheteurs peuvent être dirigés pour ce modèle).
PATCH /seller/offers/{id} Modifier le prix (discount_pct), plafond (daily_cap_usd, 0 le supprime), precision (modèles open-weight), status: paused | active (une offre qui a échoué au model check ne peut pas être réactivée).
POST /seller/offers/{id}/rotate-credential {api_key} Nouvelle clé, testée avant d'être acceptée.
POST /seller/offers/{id}/reset-health De retour dans le routage maintenant.
DELETE /seller/offers/{id} Supprimer : hors du routage, clé stockée effacée.
GET /seller/configs · DELETE /seller/configs/{id} Clés enregistrées pour démarrer de nouvelles offres (seul un indice de 4 caractères est affiché).
GET /seller/health-log Pourquoi les offres ont été ignorées.
GET /seller/earnings · GET /seller/payouts · POST /seller/payouts/request Argent : ce qui est disponible, en attente, en transit et payé.
PUT /seller/payout-method {method: paypal | usdc_base, address} Où vos paiements sont envoyés : un email PayPal ou un wallet USDC sur Base.
curl https://api.uberllm.dev/v1/seller/offers/bulk \
  -H "Authorization: Bearer $UBERLLM_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "endpoint_url": "https://api.together.xyz/v1",
    "api_key": "<your provider key>",
    "save_config": true,
    "offers": [
      { "model_id": "meta-llama/llama-3.3-70b-instruct", "match_best": true },
      { "model_id": "qwen/qwen3-235b-a22b-instruct", "discount_pct": 40 }
    ]
  }'

Pour les agents

Votre agent dispose déjà d'une API key UberLLM après s'être connecté. Il peut s'enregistrer, trouver des modèles sur une provider key, les lister et suivre les gains avec les appels ci-dessus sous /v1/seller. Aucun autre type de key n'est nécessaire.

Ne listez que ce que vous pouvez revendre

  • ✅ Modèles à poids ouverts ou auto-hébergés que vous exécutez.
  • ✅ Capacité de fournisseur que vous êtes autorisé à revendre.
  • ❌ Une clé de fournisseur dont les conditions ne vous permettent pas de la revendre ou de donner accès à d'autres. Les conditions de nombreux fournisseurs ne le permettent pas : vérifiez les vôtres avant de la lister.
  • ❌ Clés volées, divulguées, partagées, d'essai gratuit ou d'évaluation. Toute offre qui enfreint ces règles est supprimée.

Utilisez une clé de fournisseur dédiée avec un plafond de dépenses. Vous êtes responsable de la licence et de l'exploitation légale de ce que vous listez.