Como funciona unha pasarela de LLM? Unha guía práctica para equipos de enxeñaría

Unha pasarela de LLM sitúase entre as túas aplicacións e os provedores de modelos que conectas a través dela, e ofréceche un único lugar para xestionar as credenciais e facer o seguimento do uso.

“Polo de agora, isto é unha m***a”, escribiu un enxeñeiro en Reddit, en r/LLMDevs, en setembro de 2026.

“Cada un ten o seu propio conxunto de claves para Claude, OpenAI, AWS Bedrock e todos os demais provedores de inferencia que usamos.”

A reportaxe de BigGo sobre llm-proxy-tk, unha pasarela lixeira baseada en FastAPI, compara esta configuración con converter os LLM en “auga corrente corporativa”, coa pasarela no papel de válvula principal do edificio.

Pero antes de depositar tanta confianza na canalización, vexamos que é o que estás a instalar.

Que é unha pasarela de LLM?

Unha pasarela de LLM é un proxy inverso para as chamadas aos modelos. As túas aplicacións envían as solicitudes a ela en lugar de envialas directamente a OpenAI, Anthropic, Google ou calquera outro provedor de LLM que uses. A pasarela reenvía esas solicitudes e aplica as túas regras polo camiño.

Cada provedor de LLM ten a súa API, coa súa propia estrutura de solicitude, a súa propia autenticación e a súa propia forma de devolver os erros. Cada un ten tamén os seus propios límites de taxa e modos de fallo. Se non hai unha capa compartida diante deles, cada aplicación que chama a un provedor faino todo por si mesma, e faino dunha forma lixeiramente diferente.

A analoxía da auga corrente ten os seus límites, pero serve para isto: os provedores conéctanse á canalización unha soa vez, na pasarela. A partir de aí, cada aplicación ten a súa propia conexión con contador, así que podes ver quen usa que e pechar calquera liña sen tocar as demais.

Pasarelas de LLM, IA, MCP e API: cal é a diferenza?

Como funciona unha pasarela de LLM?

Sigamos unha solicitude desde a túa aplicación ata o modelo e de volta.

1. A solicitude chega á pasarela: A túa aplicación envía unha solicitude de chat de aparencia normal, a miúdo nun formato compatible con OpenAI, ao punto de conexión da pasarela. Desde o punto de vista da aplicación, este é o enderezo ao que chama para chegar ao modelo.
2. A pasarela comproba quen fai a solicitude e que ten permitido facer: Antes de reenviar a solicitude, valida as credenciais. A miúdo, trátase dunha clave virtual emitida para un equipo ou produto. Se configuraches barreiras de protección de entrada, tamén se poden analizar os prompts en busca de datos sensibles ou de intentos de anular as instrucións do modelo.
3. A pasarela comproba se xa ten a resposta: Se a caché está activada, unha solicitude coincidente que cumpra os requisitos pode atenderse cunha resposta gardada, sen outra chamada ao provedor. Algunhas pasarelas tamén ofrecen caché semántica, que busca solicitudes que se consideran o bastante similares, en lugar de idénticas. Isto pode encaixar co tráfico de tipo preguntas frecuentes.
4. A pasarela escolle a onde vai a solicitude: A solicitude pode indicar un modelo concreto ou un alias. A pasarela busca a ruta correspondente na túa configuración. Tamén podes configurar unha ruta de reserva. Se ao provedor A se lle esgota o tempo de espera, a pasarela pode probar co provedor B.
5. A pasarela prepara a chamada e devolve a resposta: Unha pasarela converte a túa solicitude ao formato do provedor escollido e autentica a chamada saínte. En canto recibe a resposta, convértea ao formato que require a túa aplicación.
6. A pasarela rexistra o que pasou: Cando o rexistro está activado, a pasarela anota detalles como quen fixo a chamada, que modelo a atendeu, o número de tokens, a latencia e o custo. Este é o rexistro que non tiña o enxeñeiro de Reddit da introdución.

As 4 cousas que debes saber antes de poñer unha pasarela en produción

Todo o descrito na sección anterior é posible porque a pasarela ve cada solicitude que pasa por ela. Ese é o argumento de venda. Pero tamén é unha descrición da superficie de ataque e da dependencia do fornecedor que tes que planificar.

A pasarela é agora a peza máis valiosa da túa pila de IA

A pasarela centraliza o acceso. E, polo tanto, tamén pon moitas credenciais ao alcance dun único servizo. O equipo de seguridade de Microsoft enumera o que pode almacenar ou obter unha implantación de LiteLLM: claves de API dos provedores, a súa propia clave mestra, rexistros de claves virtuais, cadeas de conexión á base de datos, configuración de enrutamento e políticas de inquilinos.

En outubro de 2026, Check Point Research revelou dúas vulnerabilidades de alto risco en LiteLLM:

• A CVE-2026-35029 permitía que usuarios autenticados, incluídos os de só lectura, accedesen a funcións administrativas e se fixesen co control da instancia.
• A CVE-2026-59823 permitía que os usuarios redirixisen solicitudes a un servidor que controlaban e capturasen as claves dos provedores.

Corrixíronse ambas na versión 1.83.9. Unha aplicación que usa a pasarela non debería poder cambiar a súa configuración.

As túas barreiras de protección necesitan unha política ante fallos

Unha análise de Pillar Security do 4 de outubro de 2026 documenta as integracións de barreiras de protección de terceiros nas principais pasarelas, entre elas LiteLLM, Kong, TrueFoundry, Portkey, Azure API Management e Apigee. (Pillar vende barreiras de protección, así que tenno en conta ao ler as súas recomendacións.)

Un hook (gancho) é un punto do percorrido da solicitude, normalmente antes de que o prompt chegue ao modelo ou despois de que volva a resposta, no que a pasarela pode pasarlle o contido a un analizador externo para que emita un veredicto. Unha comprobación bloqueante agarda por ese veredicto antes de deixar que o tráfico continúe. A documentación de Portkey chámaos before_request_hooks e after_request_hooks; TrueFoundry executa catro, xa que engade comprobacións antes e despois das chamadas a ferramentas MCP.

Agora, dúas cousas que debes comprobar:

• Que pasa se falla o propio analizador? Se bloqueas a solicitude, detés o tráfico sen comprobar, pero podes interromper a túa aplicación. Se a deixas pasar, a túa aplicación pode continuar sen esa comprobación. O rexistro de fallos móstrache despois que faltou a comprobación, o cal é útil, pero non é o mesmo que tela executado.
• Podes substituír o analizador? Se non se admite outro provedor, pode que teñas que actualizar a túa aplicación ou usar outro proxy para conectarte.

Os hooks de MCP de TrueFoundry amplían o alcance da pasarela desde as solicitudes aos modelos ata as chamadas a ferramentas. Pero só pode inspeccionar o tráfico que pasa por ela. Un axente de programación que executa un comando na máquina dun desenvolvedor pode quedar fóra desa visión.

Numbat, a ferramenta de código aberto de Perplexity, ocúpase dese lado. Numbat conéctase aos axentes compatibles mediante hooks locais e pode inspeccionar as accións previstas, como comandos de shell ou escrituras de ficheiros, antes de que se executen. A función de bloqueo é opcional e está desactivada de forma predeterminada. A pasarela ve o tráfico dos modelos que se enruta a través dela. Numbat engade visibilidade sobre o que fai o axente coa resposta.

Tes que saber onde remata o control da pasarela

Forkast News identifica tres liñaxes que se achegan á pasarela desde direccións diferentes:

• Pasarelas centradas en LLM: LiteLLM e Portkey comezaron coas chamadas aos modelos: traducir entre provedores, enrutar solicitudes e facer o seguimento dos tokens. Agora están a engadir controis para as chamadas a ferramentas.
• Plataformas de xestión de API: Kong, Apigee de Google e Azure API Management comezaron coa autenticación, os permisos e a xestión do tráfico, e despois engadiron compatibilidade con modelos e regras específicas para a IA.
• Infraestrutura nativa para axentes: agentgateway, por exemplo, construíuse en torno a axentes que se comunican con modelos, ferramentas e outros axentes, tamén a través de MCP e A2A.

A pregunta clave para clasificalas é que estás a enrutar:

• Só chamadas a modelos? Unha pasarela centrada en LLM é un bo punto de partida.
• Chamadas a modelos dentro dunha empresa que xa está chea de regras de API? Comeza coa plataforma que xa tes.
• Axentes que chaman a ferramentas que chaman a modelos? Comproba que esas conexións tamén estean cubertas.

Introduces un punto de fallo compartido

Supón que o teu chatbot de asistencia usa OpenAI e a túa ferramenta de investigación usa Anthropic, e que ambos se conectan a través da mesma pasarela. Se esa pasarela deixa de funcionar, as dúas ferramentas perden o acceso aos seus modelos, aínda que OpenAI e Anthropic estean a funcionar con normalidade.

Isto xa pasou. A taxa de erros de AI Gateway de Cloudflare chegou a un máximo do 97 % durante a interrupción do servizo do 12 de xuño de 2025. A pasarela dependía do servizo de almacenamento Workers KV de Cloudflare para a configuración, e ese servizo estaba a fallar.

Se xestionas ti mesmo a pasarela, mantén outra copia en execución que poida tomar o relevo se unha falla. Se é un terceiro quen aloxa a túa pasarela, pregunta como a manteñen en funcionamento durante os fallos e que lles pasa ás túas solicitudes durante a recuperación.

As funcións clave que debes buscar nas pasarelas de LLM

Vas darlle á pasarela acceso ás credenciais de todo o mundo, así que deberías ser esixente co que fai a cambio.

• Unha única API diante de varios provedores: O teu código fala un só formato, a miúdo un compatible con OpenAI, e a pasarela tradúceo. Os provedores de LLM tamén poñen da súa parte. Por exemplo, a Agent API de Perplexity admite a interface da Responses API de OpenAI, polo que os equipos poden reutilizar as bibliotecas cliente de OpenAI que xa teñen.
• Claves virtuais con regras asociadas: Cada equipo ou produto recibe a súa propia clave, con regras que rexen os modelos permitidos, os límites de solicitudes e o gasto.
• Enrutamento e alternativas de reserva: A pasarela envía as solicitudes aos modelos segundo a túa configuración, que pode priorizar o custo, a velocidade ou un provedor concreto. Se unha chamada falla, pode probar con outro. A Agent API de Perplexity permíteche indicar ata cinco modelos, incluídos modelos de diferentes provedores, na orde que prefiras.
• Caché: Unha resposta gardada pode aforrarche outra chamada ao provedor. Algunhas pasarelas fan coincidir solicitudes idénticas; outras tamén poden facer coincidir solicitudes cun significado similar. Comproba se as respostas da caché se poden separar por usuario ou equipo e se podes desactivar a caché para respostas personalizadas ou que dependan do momento.
• Streaming e erros coherentes: As respostas chegan a medida que se xeran, e os erros dos provedores tradúcense a un formato que a túa aplicación pode xestionar. Comproba que pasa cando engades barreiras de protección de IA.
• Rexistro e atribución de custos: A pasarela rexistra quen fixo unha chamada, que modelo a atendeu, cantos tokens usou, canto tardou e o seu custo estimado. Comproba se os rexistros inclúen os prompts e as respostas, e durante canto tempo se conservan.
• Hooks de barreiras de protección: Son puntos do percorrido da solicitude nos que a pasarela pode enviar contido a un analizador externo para obter un veredicto. Adoitan situarse antes dunha solicitude ao modelo ou despois da súa resposta. Comproba se as solicitudes se deteñen ou continúan cando falla o analizador e se podes conectar un analizador diferente.
• Unha interface de administración que poidas protexer: A pasarela xestiona o acceso ás credenciais dos provedores e ás regras que usa todo o mundo. Comproba que podes restrinxir o acceso de administración por separado do tráfico das aplicacións e que os usuarios de só lectura non poden cambiar a configuración. A válvula principal necesita un cadeado.

Que ferramentas podes usar para construír a túa pasarela de LLM?

As listas de funcións solápanse en todo o mercado. Nun fío de Reddit sobre o acceso interno a modelos, a persoa que o publicou preguntaba: que pasarela non require un enxeñeiro dedicado?

Na nosa opinión, esa é a pregunta correcta, e ten catro respostas, segundo canto traballo esteas disposto a asumir.

Constrúea ti mesmo

Unha pasarela mínima encárgase dunha lista curta de tarefas: aceptar solicitudes, comprobar a clave de quen chama, engadir a credencial do provedor, reenviar a chamada e rexistrar o resultado. Pero ser compatible con diferentes formatos de provedores supón traballo adicional. E tamén mantelo todo en funcionamento.

Se xa usas Envoy, o seu filtro de procesamento externo permíteche conectar un servizo que inspecciona e modifica solicitudes e respostas. Aínda así, tes que construír e manter en execución ese servizo.

Nun fío de r/LLMDevs sobre se unha pasarela reduce custos, u/QuanTradin contou que rexistrar os tokens e un indicador de acerto na caché en cada chamada lle axudou a atopar dous procesos que pagaban o prezo completo por prompts idénticos.

“...arranxar iso valeu máis do que valería calquera capa de enrutamento.”

Esa é unha experiencia relatada, e un bo punto de partida. Descubre que estás a pagar antes de construír formas elaboradas de enrutalo.

Aloxa ti mesmo unha pasarela de código aberto

LiteLLM é unha opción habitual aquí: é compatible con OpenAI, admite unha ampla variedade de provedores e ten unha gran comunidade. Bifrost é unha alternativa, deseñada para ter unha baixa sobrecarga por solicitude. Paga a pena botarlle unha ollada a Helicone se a observabilidade encabeza a túa lista de funcións.

LiteLLM, como calquera produto, ten limitacións para algúns equipos. Nun fío de r/aiagents sobre alternativas a construír a túa propia pasarela, u/Own_Bar_920 contou que LiteLLM xestionaba ben o enrutamento, pero que no seu caso quedaba curto no versionado de prompts entre equipos e nas avaliacións continuas ao cambiar de modelo, o que os levou a usar unha ferramenta separada.

Esas funcións van máis alá do enrutamento básico dunha pasarela, e esa é precisamente a cuestión: se o enrutamento é a necesidade principal, LiteLLM cumpriu no seu caso.

Obtés unha lista de funcións xa feita, con algunhas funcións que dependen da edición, e mantés a pasarela dentro da túa rede. Tamén es responsable da aplicación de parches, algo que as revelacións de Check Point mencionadas antes deixaron claro, e da dispoñibilidade da pasarela, como mostrou a sección sobre o punto único de fallo.

Pero reserva orzamento para que alguén se faga responsable. Unha das preocupacións nun fío de r/LLMDevs sobre pasarelas para acceso interno era o mantemento. u/Informal-Writer9685 quería algo que “non requira un enxeñeiro dedicado para mantelo” e preguntaba se a inestabilidade nas actualizacións de LiteLLM da que se falaba era un problema real á súa escala ou algo que só preocupa en produción.

Usa unha pasarela xestionada

Cloudflare AI Gateway, Vercel AI Gateway, OpenRouter e a pasarela aloxada de Portkey xestionan o servizo por ti. Para unha aplicación compatible, conseguir que pase a primeira solicitude pode requirir pouco máis ca un cambio de URL e unha clave de API.

A contrapartida é que agora cada prompt pasa por un terceiro antes de chegar ao provedor. Iso supón un encargado do tratamento de datos máis na túa documentación de cumprimento normativo, e as interrupcións da propia pasarela son incidentes do fornecedor: non che corresponde a ti solucionalas.

Por exemplo, os días 17 e 19 de febreiro de 2026, OpenRouter sufriu interrupcións de 38 e 35 minutos, respectivamente, despois de que fallase unha dependencia de caché. Algúns clientes recibiron erros “User not found” e dedicaron tempo a depurar claves de API perfectamente válidas. O fallo estaba na infraestrutura da pasarela.

Pero hai que recoñecerlle a OpenRouter que publicou un informe post mortem detallado e engadiu proteccións para evitar que un fallo da caché saturase a súa base de datos. Unha pasarela xestionada como OpenRouter pode simplificar o acceso, pero, como sinala u/QuanTradin en r/LLMDevs, unificar as facturas non reduce automaticamente o gasto.

Amplía a pasarela de API que xa tes

Se Kong, Apigee ou Azure API Management xa están diante dos teus servizos, cada unha ten capacidades específicas para a IA: Kong AI Gateway, as políticas de pasarela de IA de Apigee e a pasarela de IA de Azure API Management. Podes aproveitar a autenticación, as regras de rede e os procedementos operativos que xa tes, e engadir controis de modelos mediante plugins ou políticas.

Este pode ser o camiño de menor resistencia organizativa nunha gran empresa. As funcións de IA son máis recentes que as das pasarelas independentes. Asegúrate de probar a limitación de taxa baseada en tokens e o streaming con todo o conxunto de plugins ou políticas que teñas previsto usar.

Así que, por suposto, instala a válvula mestra: a todopoderosa pasarela. Con todo, o enxeñeiro da introdución ten a súa parte de razón. O acceso dunha empresa aos modelos non debería depender de quen teña por casualidade a chave axeitada nun caixón.

Unha pasarela soluciona isto ao poñer esas chaves baixo control centralizado, o que, de paso, fai que deixar o caixón aberto sexa bastante máis grave. Tes que saber de quen é o caixón.

Preguntas frecuentes sobre as pasarelas de LLM

A pasarela de LLM é gratuíta?

Se te refires á categoría, algunhas pasarelas de LLM teñen versións gratuítas.

As pasarelas de LLM van desde software de código aberto gratuíto ata plans de pago a partir duns 50 $ ao mes, con prezos personalizados para implementacións empresariais. E algunhas cobran unha porcentaxe no seu lugar; por exemplo, o plan Standard de OpenRouter engade un 5,5 % ás compras de créditos.

Cal é a mellor pasarela de LLM?

Que traballo estás disposto a asumir?

• Bota unha ollada a Bifrost ou Helicone se queres aloxala na túa propia infraestrutura e controlar a configuración.
• Unha opción xestionada como OpenRouter ou Vercel AI Gateway encaixa cos equipos que prefiren que sexa outro quen opere o servizo.
• Se xa usas Kong ou Azure API Management, revisa primeiro as súas capacidades de IA.

Proba as opcións preseleccionadas coas túas propias solicitudes, incluído o que ocorre cando falla un provedor.

AWS ten unha pasarela de LLM?

Si. Amazon Bedrock AgentCore Gateway admite chamadas a modelos mediante o que AWS denomina “destinos de inferencia”. Estes permiten que as aplicacións usen un único punto de conexión para acceder a provedores como Amazon Bedrock, OpenAI e Anthropic, mentres a pasarela xestiona as credenciais dos provedores e o enrutamento.