Árbol de conocimiento
Seguridad ofensiva
Shells
Transferencia de archivos
Aplicaciones web
APIs de modelos
Una aplicación suele utilizar un modelo de esta forma:
- Llama a un endpoint.
- Indica el modelo, el input y algunos parámetros.
- Recibe el output.
- Consulta metadata como el usage.
- Si hace falta, procesa streaming o tool calls.
La API define cómo se representan esas piezas. El modelo es quien realiza la inferencia.
Ejemplo con LM Studio
LM Studio puede exponer un modelo local mediante endpoints OpenAI-compatible. Esto permite utilizar el SDK de OpenAI cambiando el base_url:
from openai import OpenAI
client = OpenAI(
base_url="http://localhost:1234/v1",
api_key="lm-studio",
)
response = client.chat.completions.create(
model="model-identifier",
messages=[
{"role": "user", "content": "Resume los cambios de este diff."}
],
temperature=0.2,
)
print(response.choices[0].message.content)
print(response.usage)model-identifier debe coincidir con el modelo cargado. El cliente envía la request a LM Studio, LM Studio ejecuta la inferencia y devuelve una respuesta con la forma que espera el SDK.
El ejemplo utiliza Chat Completions porque muestra directamente la estructura de messages que ya aparece en muchos clientes locales. LM Studio también documenta /v1/responses y su propia API REST.
Request y response
La request necesita un identificador de modelo y el input. Puede añadir límites de output, parámetros de sampling o definiciones de tools.
La response no siempre es solo texto. También puede contener el motivo de parada, usage o una tool call. El código debe leer la estructura documentada por la API en lugar de asumir que el primer campo visible contiene todo el resultado.
El usage suele incluir input y output tokens. Es la medida más útil para entender cuánto procesó realmente la llamada y calcular su coste. Las categorías adicionales dependen del proveedor.
Streaming
Con streaming, la respuesta llega en eventos o fragmentos. El cliente puede mostrar texto a medida que se genera en vez de esperar al final.
También puede tener que reconstruir argumentos de una tool call que llegan por partes. El usage definitivo suele estar disponible al final del stream, según la API.
Streaming cambia cómo se entrega la respuesta. Las fases de inferencia siguen siendo prefill y decode.
Tools
Una request puede incluir definiciones de tools. En vez de devolver texto final, el modelo puede responder que quiere ejecutar una función con ciertos argumentos.
La aplicación valida y ejecuta esa operación, y después devuelve el resultado al modelo para continuar. Uso de herramientas explica ese recorrido. En la API hay que respetar los IDs y objetos que relacionan cada call con su resultado.
Estado de conversación
Algunas APIs requieren reenviar los mensajes relevantes en cada request. Otras permiten referenciar una response o conversación anterior.
En ambos casos, el estado de la aplicación puede seguir viviendo en otro lugar: una base de datos, un repositorio o el propio harness. Que el proveedor permita continuar una conversación no convierte ese estado en la única fuente de la tarea.
OpenAI-compatible
OpenAI-compatible significa normalmente que otro servidor implementa endpoints o formatos con la forma de OpenAI para reutilizar clientes existentes.
No garantiza que todo se comporte igual. Un endpoint puede aceptar messages y temperature pero diferir en modelos disponibles, tools, reasoning, usage o parámetros ignorados. Hay que probar las capacidades que utiliza la integración, no solo comprobar que una request sencilla responde.