Què és el límit de peticions? Una guia en llenguatge senzill per a creadors d'apps

El límit de peticions és una regla que restringeix quantes peticions pot fer algú a un sistema en un temps determinat; per exemple, 5 intents d'inici de sessió per minut o 100 crides d'API per hora. Quan s'arriba al límit, les peticions següents es rebutgen (normalment amb el codi d'error 429 Too Many Requests) fins que la finestra de temps es reinicia. Protegeix les apps de l'abús, evita que un usuari molt intensiu alenteixi l'app per a tothom i frena les despeses descontrolades.

Hi ha límits de peticions en dues direccions: els serveis que crides et limiten a tu, i la teva pròpia app hauria de limitar els seus usuaris.

Per què importa el límit de peticions quan crees amb IA

Les apps creades amb IA sovint es connecten a serveis de pagament —models d'IA, correu, SMS, mapes—, i cada crida costa diners. Això fa que el límit de peticions sigui alhora una funció de seguretat i de pressupost.

• Control de costos. Si la teva app té una caixa «pregunta a la IA» i no hi ha límit, un bot pot enviar-hi milers de peticions durant la nit. Pagues per cadascuna.
• Seguretat. Sense límit al formulari d'inici de sessió, un atacant pot provar milers de contrasenyes contra un compte. Un límit de pocs intents per minut ho fa impracticable.
• Mantenir-se en línia. Un script que es comporta malament —de vegades el teu propi codi atrapat en un bucle— pot sobrecarregar la base de dades i tombar l'app.
• Respectar els límits d'altres serveis. Quan la teva app crida una API externa massa sovint, tu reps els errors 429 i les funcionalitats fallen per als teus usuaris.

Els creadors d'apps amb IA construiran el que els demanes. Si no esmentes límits, sovint no hi són.

Una analogia del dia a dia

Pensa en la política de recàrrega gratuïta d'una cafeteria: «Una recàrrega gratuïta per client i visita».

• No impedeix que ningú gaudeixi del cafè.
• Impedeix que una persona es passi tot el dia al taulell recarregant un termo per a tota l'oficina.
• Quan algú demana una quarta recàrrega, el cambrer diu educadament «ara no»: això és el 429.

Un bon límit és invisible per als clients normals i només es nota en algú que fa alguna cosa inusual.

Com funciona el límit de peticions

Un limitador necessita tres coses:

Quan arriba una petició, l'app comprova el recompte d'aquell «qui». Per sota del límit: la petició passa i el recompte augmenta. Per sobre del límit: la petició es rebutja.

Hi ha alguns mètodes habituals per comptar:

Els recomptes han d'estar emmagatzemats en algun lloc ràpid i compartit. En un servidor petit, la memòria funciona. Quan una app s'executa en diverses màquines, el comptador normalment viu en un emmagatzematge compartit com Redis o la base de dades; si no, cada màquina compta per separat i el límit real es multiplica per diverses vegades.

Com és una resposta amb límit

Quan una petició supera el límit, una API ben dissenyada respon amb:

• Codi d'estat 429 Too Many Requests.
• Sovint una capçalera Retry-After, que indica quants segons cal esperar.
• De vegades capçaleres que mostren el teu límit i quantes peticions et queden en aquesta finestra (els noms varien segons el proveïdor).

L'app hauria de respondre a un 429 esperant i tornant a intentar-ho més tard, idealment amb backoff exponencial: esperar una mica més després de cada intent fallit (1 segon, després 2, després 4) en lloc de bombardejar el servei.

Un exemple resolt: un assistent d'escriptura amb IA

Suposem que has construït una app on els usuaris enganxen text i reben una reescriptura feta per IA.

Sense límits: algú escriu un script que envia 20.000 peticions durant la nit. La factura del teu proveïdor d'IA es dispara i el teu compte arriba al límit del proveïdor, així que els usuaris reals veuen errors tot el matí.

Amb límits sensats:

1. Per usuari connectat: 30 reescriptures per hora al pla gratuït, 300 al de pagament. Si se supera el límit, l'usuari veu: «Has arribat al límit d'aquesta hora. Torna-ho a provar d'aquí a 12 minuts, o fes un upgrade.»
2. Per adreça IP al formulari de registre: 5 registres per hora, per evitar que els bots creïn milers de comptes gratuïts per saltar-se el límit per usuari.
3. Un límit de despesa configurat al panell del teu proveïdor d'IA, com a última línia de defensa si tot l'altre falla.
4. Gestionar els límits del proveïdor: si el proveïdor d'IA retorna un 429, el teu servidor espera i torna a provar una o dues vegades, i després mostra un missatge amable de «ocupat, torna-ho a provar».

Els límits es comproven al servidor. Un límit que només existeix al navegador —per exemple, desactivar el botó després de 30 clics— es pot saltar per qualsevol que cridi directament la teva API.

Termes clau

Idees equivocades habituals

• «El límit de peticions només és per a apps grans». Les apps petites també són objectiu, perquè els bots escanegen tota la xarxa buscant formularis i endpoints d'IA oberts. El cost de l'abús no depèn de la mida de la teva app.
• «Amagar el botó n'hi ha prou». Els límits al navegador són una cortesia, no una protecció. Els límits reals s'han d'aplicar al servidor.
• «Els límits per IP són sempre justos». Moltes persones poden compartir una mateixa adreça IP: una oficina, una escola, una xarxa mòbil. Els límits per usuari són més justos quan la gent ja ha iniciat sessió.
• «Un 429 vol dir que el servei està trencat». Vol dir que el crides massa sovint. Revisa el teu codi per veure si hi ha bucles, i guarda en memòria cau els resultats que no canvien sovint; mira què és la memòria cau.
• «El límit de peticions substitueix el límit de despesa». Usa-ho tot dos. Els límits a la teva app poden tenir errors; el límit de despesa del proveïdor és el teu últim recurs.

Què demanar al teu creador d'apps amb IA

• «Afegeix límit de peticions al servidor per a l'inici de sessió, el registre, el restabliment de contrasenya i l'endpoint d'IA. Suggereix límits sensats.»
• «Limita cada usuari connectat a [N] peticions d'IA per hora, i mostra un missatge clar amb el temps d'espera quan arribi al límit.»
• «Quan una API externa retorni 429, torna a intentar-ho amb backoff exponencial fins a 3 cops, i després mostra un error amable.»
• «On s'emmagatzemen els comptadors del límit? Continuaran funcionant si l'app s'executa en més d'una màquina?»
• «Registra cada vegada que un usuari o una IP arriba a un límit, perquè pugui detectar abusos.»
• «Quins serveis externs crida aquesta app i quins són els seus límits de peticions?»

El límit de peticions a Mythex

La documentació de Mythex és clara sobre això per a les funcionalitats d'IA: els límits de peticions, la seguretat i els controls de costos de les apps que construeixes són cosa teva i els has de dissenyar tu; mira Crear una app d'IA. Demana a l'agent que afegeixi límits al mateix missatge en què demanes la funcionalitat. Al Pro, un servei publicat pot executar-se en fins a tres màquines quan hi ha molt trànsit (mira Límits d'allotjament), així que demana comptadors que visquin a la base de dades en lloc de a la memòria d'un sol servidor.

Lectura relacionada: què és una API, com usar les APIs de LLM i la llista de seguretat per a apps creades amb IA.

Preguntes