Com funciona una passarel·la de LLM? Guia pràctica per a equips d’enginyeria

Una passarel·la d'LLM se situa entre les teves aplicacions i els proveïdors de models que hi connectes, i et dona un únic lloc per gestionar les credencials i fer el seguiment de l'ús.

«Ara mateix, això és una m***a», va escriure a r/LLMDevs de Reddit un enginyer el setembre de 2026.

«Cadascú té el seu propi joc de claus per a Claude, OpenAI, AWS Bedrock i tots els altres proveïdors d'inferència que fem servir.»

L'article de BigGo sobre llm-proxy-tk, una passarel·la lleugera basada en FastAPI, compara aquesta configuració amb convertir els LLM en «aigua corrent corporativa», amb la passarel·la com a clau de pas general de l'edifici.

Però abans de confiar tant en la fontaneria, vegem què estàs instal·lant.

Què és una passarel·la d'LLM?

Una passarel·la d'LLM és un servidor intermediari invers per a les crides a models. Les teves aplicacions envien les sol·licituds a la passarel·la en lloc d'enviar-les directament a OpenAI, Anthropic, Google o qualsevol altre proveïdor d'LLM que facis servir. La passarel·la reenvia aquestes sol·licituds i hi aplica les teves regles pel camí.

Cada proveïdor d'LLM té la seva API, amb el seu propi format de sol·licitud, la seva pròpia autenticació i la seva pròpia manera de retornar errors. A més, cadascun té límits de freqüència i modes de fallada diferents. Doncs bé, si no hi ha cap capa compartida al davant, cada aplicació que crida un proveïdor ho ha de fer tot pel seu compte, i cadascuna ho fa d'una manera lleugerament diferent.

L'analogia de l'aigua corrent té els seus límits, però arriba fins aquí: els proveïdors es connecten a la xarxa una sola vegada, a la passarel·la. A partir d'aquí, cada aplicació té la seva pròpia connexió amb comptador, de manera que pots veure qui fa servir què i tallar qualsevol línia sense tocar les altres.

Passarel·les d'LLM, d'IA, MCP i d'API: quina diferència hi ha?

Com funciona una passarel·la d'LLM?

Segueix una sol·licitud des de la teva aplicació fins al model i de tornada.

1. La sol·licitud arriba a la passarel·la: la teva aplicació envia una sol·licitud de xat d'aspecte normal, sovint en un format compatible amb OpenAI, al punt de connexió de la passarel·la. Des del punt de vista de l'aplicació, aquesta és l'adreça que crida per arribar al model.
2. La passarel·la comprova qui fa la sol·licitud i què té permès fer: abans de reenviar la sol·licitud, en valida les credencials. Sovint es tracta d'una clau virtual assignada a un equip o a un producte. Si has configurat mesures de protecció d'entrada, també es poden analitzar els prompts per detectar-hi dades sensibles o intents d'anul·lar les instruccions del model.
3. La passarel·la comprova si ja té la resposta: si la memòria cau està activada, una sol·licitud coincident que compleixi els requisits es pot respondre amb una resposta desada, sense fer cap altra crida al proveïdor. Algunes passarel·les també ofereixen memòria cau semàntica, que busca sol·licituds prou similars en lloc d'idèntiques. Això pot anar bé per a un trànsit de tipus preguntes freqüents.
4. La passarel·la tria on va la sol·licitud: la sol·licitud pot indicar un model concret o un àlies. La passarel·la cerca la ruta corresponent a la teva configuració. També pots configurar una ruta de reserva: si el proveïdor A no respon a temps, la passarel·la pot provar amb el proveïdor B.
5. La passarel·la prepara la crida i retorna la resposta: la passarel·la converteix la teva sol·licitud al format del proveïdor escollit i autentica la crida sortint. Tan bon punt rep la resposta, la converteix al format que necessita la teva aplicació.
6. La passarel·la registra què ha passat: quan el registre està activat, la passarel·la desa detalls com qui ha fet la crida, quin model l'ha servida, el recompte de tokens, la latència i el cost. Aquest és el registre que no tenia l'enginyer de Reddit de la introducció.

Les 4 coses que has de saber abans de posar una passarel·la en producció

Tot el que s'explica a la secció anterior és possible perquè la passarel·la veu totes les sol·licituds que hi passen. Aquest és l'argument de venda. Però també és una descripció de la superfície d'atac i de la dependència del proveïdor que has de tenir en compte.

La passarel·la és ara la peça més valuosa de la teva infraestructura d'IA

La passarel·la centralitza l'accés i, per tant, també posa moltes credencials a l'abast d'un sol servei. L'equip de seguretat de Microsoft enumera el que pot contenir o obtenir un desplegament de LiteLLM: claus d'API dels proveïdors, la seva pròpia clau mestra, registres de claus virtuals, cadenes de connexió a bases de dades, configuració d'encaminament i polítiques dels inquilins.

L'octubre de 2026, Check Point Research va revelar dues vulnerabilitats d'alt risc a LiteLLM:

• La CVE-2026-35029 permetia als usuaris autenticats, fins i tot als que només tenien accés de lectura, accedir a funcions d'administració i prendre el control de la instància.
• La CVE-2026-59823 permetia als usuaris redirigir les sol·licituds a un servidor que controlaven i capturar les claus dels proveïdors.

Totes dues es van corregir a la versió 1.83.9. Una aplicació que fa servir la passarel·la no n'hauria de poder canviar la configuració.

Les teves mesures de protecció necessiten una política davant de fallades

Una revisió de Pillar Security del 4 d'octubre de 2026 documenta integracions de mesures de protecció de tercers a les principals passarel·les, com ara LiteLLM, Kong, TrueFoundry, Portkey, Azure API Management i Apigee. (Pillar ven mesures de protecció, així que tingues-ho en compte quan llegeixis les seves recomanacions.)

Un hook és un punt del recorregut de la sol·licitud, normalment abans que el prompt arribi al model o després que torni la resposta, on la passarel·la pot passar el contingut a un analitzador extern perquè n'emeti un veredicte. Una comprovació bloquejant espera aquest veredicte abans de deixar que el trànsit continuï. La documentació de Portkey els anomena before_request_hooks i after_request_hooks; TrueFoundry n'executa quatre, amb comprovacions addicionals abans i després de les crides a eines MCP.

Ara cal comprovar dues coses:

• Què passa si falla el mateix analitzador? Si bloqueges la sol·licitud, atures el trànsit no verificat, però pots interrompre la teva aplicació. Si la deixes passar, la teva aplicació pot continuar sense aquesta comprovació. El registre de fallades et mostra després que la comprovació no s'ha fet, cosa que és útil, però no és el mateix que haver-la fet.
• Pots substituir l'analitzador? Si no s'admet un altre proveïdor, potser hauràs d'actualitzar l'aplicació o utilitzar un altre servidor intermediari per connectar-t'hi.

Els hooks MCP de TrueFoundry amplien l'abast de la passarel·la més enllà de les sol·licituds als models, fins a les crides a eines. Però la passarel·la només pot inspeccionar el trànsit que hi passa. Un agent de programació que executa una ordre a la màquina d'un desenvolupador pot quedar fora d'aquest camp de visió.

L'eina de codi obert Numbat, de Perplexity, treballa en aquest àmbit. Numbat es connecta als agents compatibles mitjançant hooks locals i pot inspeccionar les accions previstes, com ara ordres de shell o escriptures de fitxers, abans que s'executin. La funció de bloqueig és opcional i està desactivada per defecte. La passarel·la veu el trànsit de models que passa a través seu. Numbat aporta visibilitat sobre el que fa l'agent amb la resposta.

Has de saber on acaba el control de la passarel·la

Forkast News identifica tres famílies de productes que s'acosten a la passarel·la des de direccions diferents:

• Passarel·les centrades en LLM: LiteLLM i Portkey van començar amb les crides a models: traduir entre proveïdors, encaminar sol·licituds i fer el seguiment dels tokens. Ara hi estan afegint controls per a les crides a eines.
• Plataformes de gestió d'API: Kong, Apigee de Google i Azure API Management van començar amb l'autenticació, els permisos i la gestió del trànsit, i després van afegir compatibilitat amb models i regles específiques per a la IA.
• Infraestructura nativa per a agents: agentgateway, per exemple, es va crear al voltant d'agents que es comuniquen amb models, eines i altres agents, també mitjançant MCP i A2A.

La pregunta clau per triar és què encamines:

• Només crides a models? Una passarel·la centrada en LLM és un bon punt de partida.
• Crides a models dins d'una empresa que ja està plena de regles d'API? Comença amb la plataforma que ja tens.
• Agents que criden eines que criden models? Comprova que aquestes connexions també estiguin cobertes.

Introdueixes un punt de fallada compartit

Posem per cas que el teu xatbot d'assistència fa servir OpenAI i la teva eina de recerca fa servir Anthropic, i que tots dos es connecten a través de la mateixa passarel·la. Si aquesta passarel·la deixa de funcionar, totes dues eines perden l'accés als seus models, encara que OpenAI i Anthropic funcionin amb normalitat.

Això ha passat de debò. Durant la interrupció de Cloudflare del 12 de juny de 2025, la taxa d'errors d'AI Gateway va arribar a un màxim del 97 %. La passarel·la depenia del servei d'emmagatzematge Workers KV de Cloudflare per a la configuració, i aquest servei estava fallant.

Si gestiones tu mateix la passarel·la, mantén una altra còpia en funcionament que pugui prendre el relleu si una falla. Si és un tercer qui allotja la passarel·la, pregunta-li com la manté operativa durant les fallades i què passa amb les teves sol·licituds durant la recuperació.

Les funcions clau que has de buscar en una passarel·la d'LLM

Donaràs a la passarel·la accés a les credencials de tothom, així que has de ser exigent amb el que t'ofereix a canvi.

• Una sola API davant de diversos proveïdors: el teu codi parla un sol format, sovint un de compatible amb OpenAI, i la passarel·la fa la traducció. Els proveïdors d'LLM també hi posen de la seva part. Per exemple, l'Agent API de Perplexity admet la interfície de la Responses API d'OpenAI, de manera que els equips poden reutilitzar les biblioteques client d'OpenAI que ja tenen.
• Claus virtuals amb regles associades: cada equip o producte té la seva pròpia clau, amb regles que regulen els models permesos, els límits de sol·licituds i la despesa.
• Encaminament i alternativa de reserva: la passarel·la envia les sol·licituds als models segons la teva configuració, que pot prioritzar el cost, la velocitat o un proveïdor concret. Si una crida falla, pot provar-ne un altre. L'Agent API de Perplexity et permet indicar fins a cinc models, inclosos models de proveïdors diferents, en l'ordre que prefereixis.
• Memòria cau: una resposta desada et pot estalviar una altra crida al proveïdor. Algunes passarel·les fan coincidir sol·licituds idèntiques; d'altres també poden fer coincidir sol·licituds amb un significat similar. Comprova si les respostes de la memòria cau es poden separar per usuari o per equip, i si pots desactivar la memòria cau per a respostes personalitzades o que depenen del moment.
• Transmissió en temps real i errors coherents: les respostes arriben a mesura que es generen, i els errors dels proveïdors es tradueixen a un format que la teva aplicació pot gestionar. Comprova què passa quan hi afegeixes mesures de protecció d'IA.
• Registre i atribució de costos: la passarel·la registra qui ha fet una crida, quin model l'ha servida, quants tokens ha consumit, quant ha trigat i el seu cost estimat. Comprova si els registres inclouen els prompts i les respostes, i quant de temps es conserven.
• Hooks de mesures de protecció: són punts del recorregut de la sol·licitud on la passarel·la pot enviar contingut a un analitzador extern perquè n'emeti un veredicte. Normalment se situen abans d'una sol·licitud al model o després de la seva resposta. Comprova si les sol·licituds s'aturen o continuen quan l'analitzador falla, i si hi pots connectar un altre analitzador.
• Una interfície d'administració que puguis blindar: la passarel·la gestiona l'accés a les credencials dels proveïdors i a les regles que fa servir tothom. Comprova que pots restringir l'accés d'administració per separat del trànsit de les aplicacions i que els usuaris amb accés només de lectura no poden canviar la configuració. La clau de pas general necessita un pany.

Quines eines pots fer servir per crear la teva passarel·la d'LLM?

Les llistes de funcions se solapen a tot el mercat. En un fil de Reddit sobre l'accés intern als models, l'autor de la publicació preguntava: quina passarel·la no requerirà un enginyer dedicat?

Al nostre parer, aquesta és la pregunta correcta, i té quatre respostes, segons quina part de la feina estiguis disposat a assumir.

Crea-la tu mateix

Una passarel·la mínima s'encarrega d'una llista curta de tasques: acceptar sol·licituds, comprovar la clau de qui fa la crida, afegir la credencial del proveïdor, reenviar la crida i registrar el resultat. Però admetre diferents formats de proveïdor afegeix feina, igual que mantenir-ho tot en funcionament.

Si ja fas servir Envoy, el seu filtre de processament extern et permet connectar un servei que inspecciona i modifica les sol·licituds i les respostes. Tot i així, has de crear i gestionar aquest servei tu mateix.

En un fil de r/LLMDevs sobre si una passarel·la redueix els costos, u/QuanTradin va explicar que registrar els tokens i un indicador d'encert de memòria cau a cada crida els va ajudar a trobar dues tasques que pagaven el preu complet per prompts idèntics.

«...arreglar això va valer més del que hauria valgut qualsevol capa d'encaminament.»

És una experiència explicada per un usuari, i és un bon punt de partida. Esbrina què estàs pagant exactament abans de crear maneres sofisticades d'encaminar-ho.

Allotja tu mateix una passarel·la de codi obert

LiteLLM és una opció habitual en aquest cas: és compatible amb OpenAI, admet una àmplia gamma de proveïdors i té una gran comunitat. Bifrost n'és una alternativa, dissenyada per tenir una sobrecàrrega baixa per sol·licitud. Val la pena fer una ullada a Helicone si l'observabilitat encapçala la teva llista de funcions.

LiteLLM, com qualsevol producte, té limitacions per a alguns equips. En un fil de r/aiagents sobre alternatives a crear-ne una de pròpia, u/Own_Bar_920 va explicar que LiteLLM gestionava bé l'encaminament, però que se'ls quedava curt en el control de versions dels prompts entre equips i en les avaluacions contínues en canviar de model, cosa que els va portar a adoptar una eina independent.

Aquestes funcions van més enllà de l'encaminament bàsic d'una passarel·la, i aquesta és precisament la qüestió: si l'encaminament és la necessitat principal, a ells LiteLLM els va funcionar bé.

Obtens una llista de funcions ja preparada, algunes de les quals depenen de l'edició, i mantens la passarel·la dins de la teva xarxa. També ets responsable d'aplicar-hi els pedaços, cosa que les revelacions de Check Point esmentades abans han deixat clara, i de la disponibilitat de la passarel·la, cosa que ha mostrat la secció sobre el punt de fallada compartit.

Però preveu en el pressupost algú que se'n faci responsable. Una de les preocupacions en un fil de r/LLMDevs sobre passarel·les per a l'accés intern era el manteniment. u/Informal-Writer9685 volia alguna cosa que «no requereixi un enginyer dedicat per mantenir-la» i preguntava si la inestabilitat en les actualitzacions de LiteLLM de què s'havia informat era un problema real a la seva escala o una preocupació exclusiva dels entorns de producció.

Utilitza una passarel·la gestionada

Cloudflare AI Gateway, Vercel AI Gateway, OpenRouter i la passarel·la allotjada de Portkey gestionen el servei per tu. En una aplicació compatible, fer passar la primera sol·licitud pot requerir poc més que canviar una URL i obtenir una clau d'API.

La contrapartida és que ara cada prompt passa per un tercer abans d'arribar al proveïdor. Això suposa un encarregat del tractament de dades més per a la documentació de compliment normatiu, i una interrupció de la passarel·la és un incident del proveïdor: no et correspon a tu resoldre-la.

Per exemple, el 17 i el 19 de febrer de 2026, OpenRouter va patir interrupcions de 38 i 35 minuts, respectivament, després que fallés una dependència de memòria cau. Alguns clients van rebre errors de «User not found» i van dedicar temps a depurar claus d'API perfectament vàlides. L'error era a la infraestructura de la passarel·la.

Ara bé, cal reconèixer que OpenRouter va publicar una anàlisi detallada de l'incident i va afegir proteccions per evitar que una fallada de la memòria cau saturés la seva base de dades. Una passarel·la gestionada com OpenRouter pot simplificar l'accés, però, tal com assenyala u/QuanTradin a r/LLMDevs, unificar les factures no redueix automàticament la despesa.

Amplia la passarel·la d'API que ja tens

Si Kong, Apigee o Azure API Management ja fan de porta d'entrada dels teus serveis, cadascun té funcions específiques d'IA: Kong AI Gateway, les polítiques de passarel·la d'IA d'Apigee i la passarel·la d'IA d'Azure API Management. Pots aprofitar l'autenticació, les regles de xarxa i els procediments operatius que ja tens, i afegir-hi controls de models mitjançant complements o polítiques.

En una gran empresa, aquest pot ser el camí amb menys resistència organitzativa. Les funcions d'IA són més recents que les de les passarel·les independents. Assegura't de provar la limitació de freqüència basada en tokens i la transmissió en temps real amb tot el conjunt de complements o polítiques que tinguis previst fer servir.

Així que, per descomptat, instal·la la vàlvula mestra: la totpoderosa passarel·la. Tot i això, l’enginyer de la introducció té raó. L’accés d’una empresa als models no hauria de dependre de qui tingui per casualitat la clau adequada en un calaix.

Una passarel·la ho resol posant aquestes claus sota control centralitzat, cosa que fa que deixar el calaix obert sigui encara més arriscat. Has de saber de qui és el calaix.

Preguntes freqüents sobre les passarel·les de LLM

La passarel·la de LLM és gratuïta?

Si et refereixes a la categoria, algunes passarel·les de LLM tenen versions gratuïtes.

Les passarel·les de LLM van des de programari de codi obert gratuït fins a plans de pagament a partir d’uns 50 $ al mes, amb preus personalitzats per a implementacions empresarials. I n’hi ha que cobren un percentatge: per exemple, el pla Standard d’OpenRouter afegeix un 5,5 % a les compres de crèdits.

Quina és la millor passarel·la de LLM?

De quina part de la feina et vols fer càrrec?

• Fes una ullada a Bifrost o Helicone si vols allotjar-la tu mateix i controlar-ne la configuració.
• Una opció gestionada com OpenRouter o Vercel AI Gateway és adequada per als equips que volen que algú altre gestioni el servei.
• Si ja fas servir Kong o Azure API Management, comprova primer quines funcionalitats d’IA ofereixen.

Prova les opcions preseleccionades amb les teves pròpies sol·licituds i comprova també què passa quan un proveïdor falla.

AWS té una passarel·la de LLM?

Sí. Amazon Bedrock AgentCore Gateway admet crides a models mitjançant el que AWS anomena «inference targets» (destinacions d’inferència). Permeten que les aplicacions facin servir un únic punt final per accedir a proveïdors com Amazon Bedrock, OpenAI i Anthropic, mentre que la passarel·la gestiona les credencials dels proveïdors i l’encaminament.