Les LLM commencent à être utilisés dans une grande variété de cas d'utilisation. Cependant, l'intégration directe de l'API OpenAI dans votre production pose quelques problèmes car elle est relativement récente. Ses API ne fournissent pas de SLA ni de garantie de temps de fonctionnement, ni même de performance du service. Il y a encore des limites de taux sur les tokens par seconde et les requêtes par seconde.

OpenAI recommande d'utiliser diverses techniques pour atténuer ce problème. Examinons-en quelques-unes brièvement.

Backoff exponentiel

Le backoff exponentiel est une stratégie utilisée pour gérer les limites de taux en augmentant progressivement le temps entre les tentatives ultérieures dans le cas d'une erreur de limitation de taux. Voici un exemple en Node.Js :

const axios = require('axios') ; // Assurez-vous d'installer axios avec npm ou yarn. const BASE_URL = 'https://api.openai.com/v1/chat/completions' ; async function makeRequestWithBackoff(endpoint, params, retries = 3, backoffDelay = 500) { try { const response = await axios.post(endpoint, params, { headers : { 'Content-Type' : 'application/json', 'Authorization' : `Bearer YOUR_OPENAI_API_KEY`, }, }) ; return response.data ; } catch (error) { if (error.response && error.response.status === 429 && retries > 0) { // 429 est le code de statut HTTP pour Too Many Requests // Attendez un délai aléatoire qui augmente exponentiellement à chaque tentative const delay = Math.random() * backoffDelay ; console.log(`Rate limit hit, retrying in ${delay}ms`) ; await new Promise((resolve) => setTimeout(resolve, delay)) ; return makeRequestWithBackoff(endpoint, params, retries - 1, backoffDelay * 2) ; } else { // S'il ne s'agit pas d'une erreur de limite de taux ou si nous n'avons plus de tentatives, nous lançons l'erreur throw error ; } } } const params = { messages : [ {role : "user", content : "Hi, Who are you ?" } ] max_tokens : 50, model : "gpt-3.5-turbo" } ; makeRequestWithBackoff(BASE_URL, params) .then(data => console.log(data)) .catch(error => console.error(error)) ;

Vous pouvez même modifier la logique pour remplacer le backoff exponentiel par un backoff linéaire ou aléatoire.

Batching

OpenAI permet également les requêtes par lots sur le point de terminaison /completions. Cela peut fonctionner si vous avez des requêtes par seconde mais que vous n'avez pas de tokens par seconde. Mais n'oubliez pas que cette API est en train d'être dépréciée. En utilisant le même exemple que ci-dessus :

const BASE_URL = "https://api.openai.com/v1/completions" ; const params = { model : "curie", prompts : [ "Il était une fois un chien", "Il était une fois un chat", "Il était une fois un humain" ] } ; makeRequestWithBackoff(BASE_URL, params) .then(data => console.log(data)) .catch(error => console.error(error)) ;

Il existe d'autres techniques que vous pouvez utiliser en plus de celles-ci.

Mise en cache

Souvent, vos utilisateurs font les mêmes requêtes. Une couche de mise en cache simple ou sémantique au-dessus de votre requête peut vous aider à réduire les coûts et le temps de requête. Mais dans ce contexte, cela réduira les appels faits à OpenAI.

Passer d'OpenAI à Azure.

Vous pouvez demander à bénéficier du service OpenAI d'Azure et mettre en place un équilibrage de charge entre les deux fournisseurs. Ainsi, même si l'un d'entre eux est en panne ou lent, vous pouvez passer à l'autre fournisseur.

Réponses en continu

L'API OpenAI fournit une fonction de streaming qui nous permet de recevoir les réponses partielles du modèle en temps réel, au fur et à mesure qu'elles sont générées. Cette approche offre un avantage significatif par rapport aux appels traditionnels sans flux, où vous pourriez ne pas être au courant des délais potentiels jusqu'à ce que la durée totale de la réponse s'écoule, ce qui peut varier en fonction de vos paramètres initiaux tels que la complexité de la demande et le nombre de max_tokens spécifiés.

La diffusion en continu garantit que, quelle que soit la taille de la demande ou le nombre max_tokens défini, le modèle commence à fournir des jetons généralement dans les 5 à 6 premières secondes. S'il y a un délai au-delà de cette brève fenêtre, c'est un indicateur précoce que la demande peut avoir dépassé le temps imparti ou qu'elle n'a pas été traitée comme prévu. Nous pouvons mettre fin à ces demandes et les réessayer.

Mise en place de solutions de repli

Pour les cas d'utilisation spécifiques où il est acceptable d'obtenir des réponses d'autres modèles, vous pouvez mettre en place des fallbacks vers d'autres modèles. Les meilleures alternatives pourraient être Llama-70b, Gemini, ou d'autres modèles plus petits comme MIXTRAL 8X7B, Claude Instant, etc. Il s'agit là de quelques techniques courantes qui peuvent être utilisées pour atténuer les erreurs dans les applications de production.

Merci de votre lecture et suivez-nous sur Merlin @ Twitter Merlin API propose toutes ces fonctionnalités et bien plus encore, avec un choix de plus de 20 modèles. Nous nous concentrons sur la fiabilité de l'API et nous nous chargeons de toutes les opérations de commutation, de repli, de mise en cache et de gestion des limites de débit. Nous fournissons une API unifiée et utilisons un format de réponse unique pour tous les modèles.

Un petit exemple d'utilisation de l'API Merlin avec Node.js :

import { Merlin } from "merlin-node" ; // npm install merlin-node // WARNING : test api key // Replace with your API key from Merlin Dashboard // https://api.getmerlin.in const apiKey = "merlin-test-3b7d-4bad-9bdd-2b0d7db3dcb6d" ; const Merlin = new Merlin({ merlinConfig : { apiKey } }) ; const initChat = { role : "system", content : "Vous êtes un assistant utile". 
} async function createCompletion() { try { const completion = await Merlin.chat.completions.create({ messages : [initChat], model : "gpt-3.5-turbo", // 20+ modèles selon les besoins }) ; } catch (error) { console.error("Error creating completion :", error) ; } } createCompletion() ;