¿Qué es una API de LLM?

Una API de LLM es un endpoint HTTP hacia un modelo de lenguaje alojado: envías un prompt, recibes texto generado de vuelta y pagas por token. Es una API común con tres propiedades poco comunes — es stateless (reenvías la conversación entera en cada llamada), medida en tokens (entrada y salida con precios separados) y no determinística (el mismo prompt puede devolver textos distintos). Domina esas tres y el resto es la disciplina operativa que las páginas mejor rankeadas omiten: dónde pertenece la llamada, cuánto cuesta y cómo falla.

Puntos clave

Una llamada real, del lado del servidor

// JavaScript — Cloud Code (cloud/main.js)
// The LLM call belongs server-side — the key never reaches the client
Parse.Cloud.define('summarize', async (req) => {
  const res = await Parse.Cloud.httpRequest({
    method: 'POST',
    url: 'https://api.llm-provider.example/v1/chat/completions',
    headers: {
      Authorization: `Bearer ${process.env.LLM_KEY}`, // server-side secret
      'Content-Type': 'application/json',
    },
    body: {
      model: 'default-chat',
      messages: [
        { role: 'system', content: 'Summarize in one sentence.' },
        { role: 'user', content: req.params.text },
      ],
      max_tokens: 80, // cost + latency guardrail, enforced by YOU
    },
  });
  return res.data.choices[0].message.content;
});

// Flutter / Dart — Back4app Flutter SDK
// The client calls YOUR function, never the LLM API directly
final summary = await ParseCloudFunction('summarize')
    .execute(parameters: {'text': longArticle});
print(summary.result);
// The model key stays on the server. If this app called the LLM API
// itself, the key would ship in the binary — one decompile from theft.

// iOS / Swift — Back4app Swift SDK
// The client calls YOUR function, never the LLM API directly
let summary: String = try await Cloud.run(
    name: "summarize", parameters: ["text": longArticle])
print(summary)
// The model key stays on the server. If this app called the LLM API
// itself, the key would ship in the IPA — one decompile from theft.

// Android / Kotlin — Back4app Android SDK
// The client calls YOUR function, never the LLM API directly
val summary = ParseCloud.callFunction<String>(
    "summarize", mapOf("text" to longArticle))
println(summary)
// The model key stays on the server. If this app called the LLM API
// itself, the key would ship in the APK — one decompile from theft.

El formato es portátil — la mayoría de los proveedores acepta el mismo formato de chat completions, así que la solicitud y la respuesta de abajo se leen igual apuntes al modelo que apuntes:

POST /v1/chat/completions            Authorization: Bearer <clave>
{ "model": "default-chat",
  "messages": [
    { "role": "system", "content": "Sé conciso." },          ← define el comportamiento
    { "role": "user",   "content": "Explica los tokens." } ],← la instrucción
  "max_tokens": 200, "temperature": 0.7, "stream": false }

→ { "choices": [ { "message": { "role": "assistant",
                                "content": "Un token es…" },
                   "finish_reason": "stop" } ],
    "usage": { "prompt_tokens": 24, "completion_tokens": 118,
               "total_tokens": 142 } }        ← lo que pagas

Los tokens son la moneda

Un token es un trozo de texto — unos cuatro caracteres, o tres cuartos de una palabra en inglés. Todo el costo de una API de LLM se reduce a contarlos, y dos hechos sorprenden. La salida cuesta más que la entrada — a menudo varias veces más — porque leer tu prompt es barato, mientras que generar cada token de la respuesta es intensivo en cómputo, una predicción a la vez sobre el vocabulario entero. Y el contexto se paga en cada llamada: el modelo es stateless, así que la “memoria” eres tú reenviando los turnos anteriores, y un historial largo o un pasaje recuperado grande se cobra otra vez en cada solicitud. La fórmula mensual aproximada que vale la pena internalizar:

costo mensual ≈ ( solicitudes/día
                  × (tokens_entrada_prom × precio_entrada_por_M / 1_000_000
                   + tokens_salida_prom  × precio_salida_por_M  / 1_000_000) )
                × 30

Las palancas que lo mueven: acota max_tokens, recorta el contexto que reenvías,
elige un modelo más pequeño para tareas fáciles y cachea prefijos de prompt reutilizados.

Los parámetros que importan

Streaming: por qué las UIs de chat se sienten rápidas

Activa la flag stream y la respuesta llega de forma incremental como Server-Sent Events — líneas data:, un bloque de tokens a la vez, terminando en un marcador [DONE] — en vez de un blob único después de varios segundos. La razón es perceptual: el tiempo hasta el primer token es una fracción del tiempo hasta la respuesta completa, así que el usuario ve aparecer palabras en vez de un spinner girando. Es texto unidireccional del servidor al cliente sobre HTTP plano, que es exactamente la forma del SSE y precisamente por eso el streaming de LLM lo usa en vez de WebSockets. La consecuencia en el backend: tu proxy debe dejar el stream atravesar — leyendo el event stream del proveedor y reenviándolo — en vez de bufferizar la respuesta entera y anular el propósito.

Tool calling y salida estructurada

Dos funcionalidades convierten “entra texto, sale texto” en algo programable. Tool calling: describes las funciones disponibles (nombre + schema JSON) en la solicitud, y el modelo — en vez de prosa — devuelve una llamada JSON estructurada nombrando una tool y sus argumentos; tu código la ejecuta y devuelve el resultado (el paso a paso de Fowler es la referencia clara). El modelo nunca ejecuta la función; solo la pide. La salida estructurada, distinta del tool calling y a menudo confundida con él, son tres cosas que vale la pena separar:

El tool calling es el mecanismo que hace posible un agente de IA — la misma solicitud/respuesta, corrida en loop hasta que el modelo deja de pedir tools.

API de LLM vs. autoalojar un modelo abierto

La lectura honesta: la API gana para casi todos casi siempre — cero infraestructura, arranque instantáneo y más barata hasta que el volumen es genuinamente grande y constante. Autoalojar un modelo abierto (con Ollama, vLLM o llama.cpp) solo paga su costo operativo pasado un punto de equilibrio alto, o cuando la residencia de datos es un requisito duro. La mayoría de los productos empieza en la API y revisita la pregunta si la escala algún día lo obliga.

Confiabilidad: los endpoints de LLM son inestables

Trata la API de LLM como una dependencia remota lenta, limitada por tasa y que falla de vez en cuando, porque eso es. Los límites llegan como solicitudes por minuto y tokens por minuto; supera cualquiera de los dos y recibes un 429. La disciplina es la misma que exige toda API con rate limit: ante un 429 o un 5xx, reintenta con backoff exponencial más jitter y respeta el Retry-After; ante un 4xx — autenticación mala, solicitud malformada, rechazo por política de contenido — no reintentes, porque fallará de forma idéntica. Suma timeouts por solicitud (la generación puede estancarse) y recuerda que una llamada no idempotente reintentada cuesta tokens dos veces. Nada de esto es específico de los LLM; todo esto lo omiten los tutoriales que se detienen en el curl del camino feliz.

La regla que los tutoriales entierran: nunca la llames desde el cliente

El hecho operativo más importante, y el que las páginas de glosario omiten: la llamada a la API de LLM pertenece a tu servidor, nunca al navegador ni a la app. Una clave de API de modelo enviada al cliente está a un vistazo a la pestaña de red o a un decompile de binario de ser robada — y, a diferencia de una clave publicable filtrada, una clave de modelo robada es un extraño con tu presupuesto de tokens y sin más límite que tu factura. El patrón es la misma disciplina de proxy que necesita todo servicio con clave secreta: el cliente llama a tu endpoint, tu backend guarda la clave en la configuración del servidor y llama al modelo, y la respuesta vuelve a través de ti. Ese proxy también es donde vive cada otro control de este artículo — topes de costo, reintentos, streaming, recorte de prompts — y por eso “¿a dónde va la llamada?” tiene una sola respuesta.

Casos de uso comunes

• Resumen y extracción — convierte texto largo en datos cortos y estructurados, temperature: 0.
• Chat y asistentes — respuestas en streaming sobre un historial de conversación reenviado.
• Clasificación y etiquetado — Structured Outputs imponiendo tu schema de etiquetas.
• Respuestas con RAG — generación anclada en contexto recuperado, con el costo administrado recortando ese contexto.
• Acciones agénticas — tool calling en loop, cada tool una función de backend con permisos.

¿Deberías usar una API de LLM? Matriz de decisión

Limitaciones y trade-offs

• El no determinismo es el valor por defecto. El mismo prompt varía entre ejecuciones; cualquier cosa que exija repetibilidad exacta necesita temperature: 0 y, a menudo, validación de la salida.
• El costo escala con los tokens, en silencio. Un contexto generoso o un max_tokens sin tope vuelve cara a escala una funcionalidad barata — mide el uso, no lo supongas.
• La latencia es de segundos, no de milisegundos. Las llamadas a LLM son lentas para los estándares de la web; diseña para eso con streaming, patrones asíncronos y estados de carga honestos.
• La dependencia es externa y limitada por tasa. Los outages y el throttling del proveedor son tus outages; los reintentos, los fallbacks y el caché son resiliencia, no pulido.
• Las salidas pueden estar equivocadas y sonar seguras. La API devuelve texto fluido sin importar la verdad; el anclaje (RAG) y la validación son la manera de confiar en ella.

APIs de LLM en Back4app

Back4app es una plataforma open-source de Backend as a Service (BaaS) que combina base de datos gestionada, APIs REST y GraphQL generadas automáticamente, autenticación, almacenamiento de archivos y funciones serverless con Cloud Code. La pregunta “dónde pertenece la llamada” se responde sola aquí: dentro de una Cloud Function, exactamente como muestran las pestañas de código — el cliente llama a tu summarize, la función guarda la clave del modelo en la configuración del servidor y llama a la API de LLM, y la clave nunca toca el dispositivo. Esa única colocación resuelve toda la lista de brechas de una vez: topes de costo (la función define max_tokens y elige el modelo), reintentos y backoff (en la función, contra el endpoint inestable) y entrega de dos maneras — devuelve la respuesta de forma síncrona para una respuesta única, o escríbela en la base de datos y deja que los clientes la vean completarse vía Live Queries, que es streaming sin un socket que hayas tenido que construir. La API de LLM deja de ser un riesgo de integración y se convierte en una llamada server-side más que tu backend ya sabe hacer con seguridad.