finalmente trabajo.
Llaman herramientas, razonan a través de flujos de trabajo y, de hecho, completan tareas.
Entonces llega la primera factura API real.
Para muchos equipos, ese es el momento en que aparece la pregunta:
"¿Deberíamos ejecutar esto nosotros mismos?"
La buena noticia es que el alojamiento autónomo de un LLM ya no es un proyecto de investigación ni un esfuerzo masivo de infraestructura de aprendizaje automático. Con el modelo correcto, la GPU adecuada y algunas herramientas probadas en batalla, puede ejecutar un LLM de nivel de producción en una sola máquina que controle.
Probablemente estés aquí porque sucedió algo de esto:
Su factura OpenAI o Anthropic explotó
No puede enviar datos confidenciales fuera de su VPC
Los flujos de trabajo de sus agentes queman millones de tokens al día
Quieres un comportamiento personalizado de tu IA y las indicaciones no son suficientes.
Si eres tú, perfecto. Si no, sigues siendo perfecto 🤗
En este artículo, lo guiaré a través de un manual práctico para implementar un LLM en su propia infraestructura, incluido cómo se evaluaron y seleccionaron los modelos, qué tipos de instancias se evaluaron y eligieron y el razonamiento detrás de esas decisiones.
También le proporcionaré un patrón de implementación sin costo de cambio para su propio LLM que funcione para OpenAI o Anthropic.
Al final de esta guía sabrás:
Qué puntos de referencia realmente importan para los LLM que necesitan resolver y razonar a través de problemas agentes, y no reiterar el último teorema de cuerdas. Qué significa cuantificar y cómo afecta el rendimiento Qué tipos de instancias/GPU se pueden usar para el alojamiento de una sola máquina1 Qué modelos usar2 Cómo usar un LLM autohospedado sin tener que reescribir una base de código basada en API existente ¿Cómo hacer que el autohospedaje sea rentable3?
1 Se evaluaron los tipos de instancias entre los “tres grandes”: AWS, Azure y GCP.
2 todos los modelos están actualizados a partir de marzo de 2026
3 Todos los datos de precios están actualizados a marzo de 2026.
Nota: esta guía se centra en la implementación de LLM orientados a agentes, no en modelos de frontera de propósito general, de billones de parámetros y que lo abarquen todo, que son en gran medida excesivos para la mayoría de los casos de uso de agentes.
✋Espera… ¿por qué volvería a organizar mi propio LLM?
+++ Privacidad
Probablemente esta sea la razón por la que estás aquí. Datos confidenciales: registros médicos de pacientes, código fuente propietario, datos de usuarios, registros financieros, RFP o documentos de estrategia interna que nunca pueden salir de su firewall.
El autohospedaje elimina la dependencia de API de terceros y alivia el riesgo de una infracción o de no conservar o registrar datos de acuerdo con estrictas políticas de privacidad.
++ Previsibilidad de costos
El precio de la API aumenta linealmente con el uso. Para las cargas de trabajo de los agentes, que normalmente son más altas en el espectro de tokens, operar su propia infraestructura de GPU introduce economías de escala. Esto es especialmente importante si planea realizar razonamiento de agentes en una empresa mediana a grande (más de 20 a 30 agentes) o proporcionar agentes a clientes en cualquier tipo de escala.
+ Rendimiento
Elimine las llamadas API de ida y vuelta, obtenga valores razonables de token por segundo y aumente la capacidad según sea necesario con el escalado elástico de instancia puntual.
+ Personalización
Se pueden utilizar métodos como LoRA y QLoRA (que no se tratan en detalle aquí) para ajustar el comportamiento de un LLM o adaptar su alineación, eliminando, mejorando, adaptando el uso de herramientas, ajustando el estilo de respuesta o ajustando datos de dominios específicos.
Esto es de vital utilidad para crear agentes personalizados u ofrecer servicios de inteligencia artificial que requieren un comportamiento o estilo específico adaptado a un caso de uso en lugar de una alineación de instrucciones genéricas mediante indicaciones.
Un aparte sobre el ajuste
Métodos como LoRA/QLoRA, ablación de modelos (“abliteración”), técnicas de realineación y estilización de respuestas son técnicamente complejos y están fuera del alcance de esta guía. Sin embargo, el autohospedaje suele ser el primer paso hacia una personalización más profunda de los LLM.
¿Por qué una sola máquina?
No es un requisito difícil, es más por simplicidad. La implementación en una sola máquina con una sola GPU es relativamente simple. Una sola máquina con múltiples GPU es factible con las opciones de configuración correctas.
Sin embargo, depurar la inferencia distribuida en muchas máquinas puede ser una pesadilla.
Este es su primer LLM autohospedado. Para simplificar el proceso, nos centraremos en una sola máquina y una sola GPU. A medida que sus necesidades de inferencia crezcan, o si necesita más rendimiento, amplíelo en una sola máquina. Luego, a medida que madure, podrá comenzar a abordar implementaciones de múltiples máquinas o estilo Kubernetes.
👉¿Qué puntos de referencia son realmente importantes?
El panorama de LLM Benchmark es ruidoso. Hay docenas de tablas de clasificación y la mayoría de ellas son irrelevantes para nuestro caso de uso. Necesitamos reducir estos puntos de referencia para encontrar LLM que se destaquen en tareas de estilo agente.
Específicamente, estamos buscando LLM que puedan:
Seguir instrucciones complejas de varios pasos Usar herramientas de manera confiable: llamar a funciones con argumentos bien formados, interpretar resultados y decidir qué hacer a continuación Razonar con restricciones: razonar con información potencialmente incompleta sin alucinar una respuesta segura pero incorrecta Escribir y comprender código: no necesitamos resolver problemas SWE de nivel experto, pero interactuar con las API y poder generar código sobre la marcha ayuda a expandir el espacio de acción y generalmente se traduce en un mejor uso de las herramientas
Estos son los puntos de referencia a los que realmente hay que prestar atención:
Nota: desafortunadamente, es difícil obtener puntuaciones de referencia confiables en todos estos modelos, especialmente en los modelos cuantificados. Tendrá que utilizar su mejor criterio, asumiendo que el modelo de precisión total cumple con la tabla de degradación del rendimiento que se describe a continuación.
🤖Cuantización
Esta no pretende de ninguna manera ser una guía exhaustiva para la cuantificación. Mi objetivo es brindarte suficiente información para que puedas navegar por HuggingFace sin quedar bizco.
Lo basico
Los parámetros de un modelo se almacenan como números. Con total precisión (FP32), cada peso es un número de coma flotante de 32 bits: 4 bytes. La mayoría de los modelos modernos se distribuyen en FP16 o BF16 (media precisión, 2 bytes por peso). Verás esto como la base para cada modelo.
La cuantificación reduce la cantidad de bits utilizados para representar cada peso, lo que reduce el requisito de memoria y aumenta la velocidad de inferencia, a costa de cierta precisión.
No todos los métodos de cuantificación son iguales. Existen algunos métodos inteligentes que mantienen el rendimiento con una precisión de bits muy reducida.
BF16 contra GPTQ contra AWQ contra GGUF
Verás mucho estas siglas cuando compres modelos. Esto es lo que quieren decir:
BF16: simple y llanamente. 2 bytes por parámetro. Un modelo de parámetros de 70B le costará 140 GB de VRAM. Este es el nivel mínimo de cuantificación. GPTQ: significa “cuantización generativa de transformadores preentrenados”, cuantificada capa por capa utilizando una codiciosa aproximación “consciente de errores” del hessiano para cada peso. Reemplazado en gran medida por AWQ y métodos aplicables a los modelos GGUF (ver más abajo) AWQ: significa "cuantización de peso consciente de la activación", cuantifica los pesos utilizando la magnitud de la activación (a través de canales) en lugar del error. GGUF: no es un método de cuantificación en absoluto, es un contenedor LLM popularizado por llama.cpp, dentro del cual encontrará algunos de los siguientes métodos de cuantificación: K-quants: nombrados por bits por peso y método, por ejemplo, Q4_K_M/Q4_K_S. I-quants: versión más nueva, aumenta la precisión a velocidades de bits más bajas (4 bits e inferiores)
Aquí hay una guía aproximada sobre lo que la cuantización afecta al rendimiento:
Donde realmente duele la cuantización
No todas las tareas se degradan por igual. Las cosas más afectadas por la cuantificación agresiva (Q3 y siguientes):
Cálculo numérico preciso: si su agente necesita realizar ponderaciones aritméticas exactas (a diferencia de las llamadas a herramientas), una menor precisión perjudica. Recuperación de conocimientos raros/especializados: la “cola larga” del conocimiento de un modelo se almacena en ponderaciones menos activadas, que son las primeras en perder fidelidad. Secuencias de cadena de pensamiento muy largas: los pequeños errores se combinan en cadenas de razonamiento extendidas. Fiabilidad de salida estructurada: en el tercer trimestre y en adelante, el cumplimiento del esquema JSON y el formato de llamada de herramientas comienzan a degradar. Esto es un asesino para las canalizaciones de agentes.
💡Protip: Cíñete a Q4_K_M y superiores para los agentes. Cualquier problema de confiabilidad de resultados y razonamiento contextual largo y bajo pone en riesgo las tareas de los agentes.
🛠️Hardware
GPU (aceleradores)
Aunque hay más tipos de GPU disponibles, el panorama en AWS, GCP y Azure se puede resumir principalmente en las siguientes opciones, especialmente para implementaciones de una sola máquina y una sola GPU:
Las mejores compensaciones entre rendimiento y costo se encuentran en la gama L4, L40S y A100, siendo el A100 el que ofrece el mejor rendimiento (en términos de capacidad del modelo y cargas de trabajo agentes multiusuario). Si las tareas de su agente son simples y requieren menos rendimiento, es seguro bajar a L4/A10. No actualice al H100 a menos que lo necesite.
Los 48 GB de VRAM que proporciona el L40S nos dan muchas opciones de modelos. No obtendremos el rendimiento del A100, pero ahorraremos en costes por hora.
En aras de la simplicidad, voy a enmarcar el resto de esta discusión en torno a esta GPU. Si determina que sus necesidades son diferentes (menos/más), las decisiones que describo a continuación lo ayudarán a navegar por la selección de modelos, la selección de instancias y la optimización de costos.
Nota sobre la selección de GPU: aunque tenga su corazón puesto en un A100 y las finanzas para comprarlo, la capacidad de la nube puede restringirlo a otra instancia/tipo de GPU a menos que esté dispuesto a comprar “Bloques de capacidad” [AWS] o “Reservas” [GCP].
Punto de control de decisión rápida
Si está implementando su primer LLM autohospedado:
Tipos de instancias recomendados
He compilado una lista no exhaustiva de tipos de instancias de los tres grandes que pueden ayudar a delimitar los tipos de máquinas virtuales.
Nota: toda la información sobre precios se obtuvo en marzo de 2026.
AWS
AWS carece de muchas opciones de instancias de una sola GPU y está más orientado a grandes cargas de trabajo de múltiples GPU. Dicho esto, si desea comprar bloques de capacidad reservados, ofrecen un p5.4xlarge con un solo H100. También tienen un gran bloque de tipos de instancias L40S que son excelentes para instancias puntuales para cargas de trabajo agentes predecibles/programadas.
Haga clic para revelar los tipos de instancias
Plataforma en la nube de Google
A diferencia de AWS, GCP ofrece instancias A100 de una sola GPU. Esto convierte a a2-ultragpu-1g en la opción más rentable para ejecutar modelos 70B en una sola máquina. Pagas sólo por lo que usas.
Haga clic para revelar los tipos de instancias
Azur
Azure tiene el conjunto más limitado de instancias de GPU única, por lo que prácticamente estás configurado en Standard_NC24ads_A100_v4, que te ofrece un A100 por ~$3,60 por hora, a menos que quieras optar por un modelo más pequeño.
Haga clic para revelar los tipos de instancias
‼️Importante: no minimices la caché KV
La caché de valor clave (KV) es un factor importante a la hora de dimensionar los requisitos de VRAM para los LLM.
Recuerde: los LLM son modelos grandes basados en transformadores. Una capa de transformador calcula la atención mediante consultas (Q), claves (K) y valores (V). Durante la generación, cada nuevo token debe atender a todos los tokens anteriores. Sin el almacenamiento en caché, el modelo necesitaría volver a calcular las claves y los valores de toda la secuencia en cada paso.
Al almacenar en caché [almacenar] las claves y valores de atención en VRAM, los contextos largos se vuelven factibles, ya que el modelo no tiene que volver a calcular claves y valores. Tomando generación de O(T^2) a O
Los agentes deben lidiar con contextos más largos. Esto significa que incluso si el modelo que seleccionamos se ajusta a la VRAM, también debemos asegurarnos de que haya suficiente capacidad para la caché KV.
Ejemplo: un modelo cuantificado de 32 B puede ocupar alrededor de 20 a 25 GB de VRAM, pero la caché KV para varias solicitudes simultáneas en un contexto de 8 k o 16 k puede agregar otros 10 a 20 GB. Es por eso que las GPU con 48 GB o más de memoria generalmente se recomiendan para la inferencia de producción de modelos de tamaño mediano con contextos más largos.
💡Consejo profesional: además de servir modelos con una caché KV paginada (que se analiza a continuación), asigne entre un 30 y un 40 % adicional de los requisitos de VRAM del modelo para la caché KV.
💾Modelos
Entonces ahora sabemos:
la VRAM limita el objetivo de cuantificación, los puntos de referencia que importan
Esto reduce el campo de modelos de cientos a sólo un puñado.
De la sección anterior, seleccionamos la L40S como GPU, lo que nos brinda instancias a un precio razonable (especialmente instancias puntuales, de AWS). Esto nos sitúa en un límite de 48 GB de VRAM. Recordar la importancia del caché KV nos limitará a modelos que caben en ~28 GB de VRAM (ahorrando 20 GB para el almacenamiento en caché de múltiples agentes con ventanas de contexto largas).
Con la cuantificación Q4_K_M, esto nos coloca al alcance de algunos modelos muy capaces.
He incluido enlaces a los modelos directamente en Huggingface. Notarás que Unsloth es el proveedor de los cuantos. Unsloth realiza análisis muy detallados de sus cuantificaciones y pruebas exhaustivas. Como resultado, se han convertido en los favoritos de la comunidad. Pero siéntase libre de utilizar cualquier proveedor cuantitativo que prefiera.
🥇Rango superior: Qwen3.5-27B
Desarrollado por Alibaba como parte de la familia de modelos Qwen3.5.
Este modelo 27B es una arquitectura de transformador híbrido denso optimizada para razonamiento de contexto prolongado y flujos de trabajo de agentes.
Qwen 3.5 utiliza un híbrido Gated DeltaNet + Gated Attention para mantener un contexto prolongado al tiempo que preserva la capacidad de razonamiento y minimiza el costo (en VRAM).
La versión 27B nos brinda una mecánica similar a la del modelo fronterizo y conserva el razonamiento, brindándole un rendimiento sobresaliente en llamadas de herramientas, SWE y pruebas comparativas de agentes.
Dato curioso: la versión 27B funciona ligeramente mejor que la versión 32B.
Enlace al cuanto Q4_K_M
https://huggingface.co/unsloth/Qwen3.5-27B-GGUF?show_file_info=Qwen3.5-27B-Q4_K_M.gguf
🥈Contendiente sólido: GLM 4.7 Flash
GLM‑4.7‑Flash, de Z.ai, es un modelo de lenguaje de mezcla de expertos (MoE) de 30 mil millones de parámetros que activa solo un pequeño subconjunto de sus parámetros por token (~3 B activos).
Su arquitectura admite ventanas de contexto muy largas (hasta ~128.000-200.000 tokens), lo que permite un razonamiento extendido sobre entradas de gran tamaño, como documentos extensos, bases de código o flujos de trabajo de agentes de múltiples turnos.
Viene con “modos de pensamiento” basados en turnos, que admiten un razonamiento más eficiente a nivel de agente, se desactivan para ejecuciones rápidas de herramientas y se activan para un razonamiento extendido sobre el código o la interpretación de resultados.
Enlace al cuanto Q4_K_M
https://huggingface.co/unsloth/GLM-4.7-Flash-GGUF?show_file_info=GLM-4.7-Flash-Q4_K_M.gguf
👌Vale la pena comprobarlo: GPT-OSS-20B
Los modelos de código abierto de OpenAI, las versiones de 120B de parámetros y 20B de parámetros, siguen siendo competitivos a pesar de haber sido lanzados hace más de un año. Funcionan constantemente mejor que Mistral y la versión 20B (cuantificada) se adapta bien a nuestro límite de VRAM.
Admite niveles de razonamiento configurables (bajo/medio/alto) para que pueda equilibrar la velocidad con la profundidad del razonamiento. GPT‑OSS‑20B también expone toda su cadena de razonamiento, lo que facilita la depuración y la introspección.
Es una opción sólida para las tareas de inteligencia artificial de los agentes. No obtendrá el mismo rendimiento que los modelos fronterizos de OpenAI, pero el rendimiento comparativo junto con un bajo requisito de memoria aún justifican una prueba.
Enlace al cuanto Q4_K_M
https://huggingface.co/unsloth/GLM-4.7-Flash-GGUF?show_file_info=GLM-4.7-Flash-Q4_K_M.gguf
Recuerde: incluso si está ejecutando su propio modelo, aún puede usar modelos de frontera
Este es un patrón agente inteligente. Si tiene un gráfico dinámico de las acciones de los agentes, puede activar la costosa API para Claude 4.6 Opus o GPT 5.4 para sus subgrafos complejos o tareas que requieren razonamiento visual a nivel de modelo de frontera.
Comprima el resumen de todo el gráfico de su agente usando su LLM para minimizar los tokens de entrada y asegúrese de establecer la longitud máxima de salida al llamar a la API de frontera para minimizar los costos.
🚀Implementación
Voy a presentar 2 patrones, el primero es para evaluar su modelo en un modo que no es de producción, el segundo es para uso de producción.
Patrón 1: Evaluar con Ollama
Ollama es la ejecución acoplable de inferencia LLM. Envuelve llama.cpp en una CLI limpia y una API REST, maneja las descargas de modelos y simplemente funciona. Es perfecto para desarrollo y evaluación local: puede tener una API compatible con OpenAI ejecutándose con su modelo en menos de 10 minutos.
Configuración
# Instalar Ollama curl -fsSL https://ollama.com/install.sh | sh # Tirar y ejecutar un modelo ollama pull qwen3.5:27b ollama run qwen3.5:27b
Como se mencionó, Ollama expone una API compatible con OpenAI desde el primer momento. Acceda a http://localhost:11434/v1.
from openai import Cliente OpenAI = OpenAI( base_url="http://localhost:11434/v1", api_key="ollama" # requerido pero no utilizado) respuesta = client.chat.completions.create( model="qwen3.5:27b", mensajes=[ {"role": "system", "content": "Eres un androide paranoico."}, {"role": "user", "content": "Determina cuándo eventualmente aparecerá la singularidad consumirnos"} ] )
Siempre puedes compilar llama.cpp directamente desde el código fuente [con los indicadores de GPU activados], lo que también es bueno para las evaluaciones. Ollama simplemente lo simplifica.
Patrón #2: Producción con vLLM
vLLM es bueno porque maneja automáticamente el almacenamiento en caché de KV a través de PagedAttention. Intentar ingenuamente manejar el almacenamiento en caché de KV conducirá a una subutilización de la memoria a través de la fragmentación. Si bien es más eficaz con RAM que con VRAM, sigue siendo útil.
Si bien es tentador, no uses Ollama para la producción. Utilice vLLM ya que es mucho más adecuado para la simultaneidad y la supervisión.
Configuración
# Instalar vLLM (se requiere CUDA) pip install vllm # Servir un modelo con el servidor API compatible con OpenAI vllm server Qwen/Qwen3.5-27B-GGUF –dtype auto –quantization k_m –max-model-len 32768 –gpu-memory-utilization 0.90 –port 8000 –api-key your-secret-key
Banderas de configuración clave:
Escucha:
vLLM expone un punto final /metrics compatible con Prometheus
# prometheus.yml configuración de scrape scrape_configs: – nombre_trabajo: 'vllm' static_configs: – objetivos: ['localhost:8000'] ruta_métricas: '/métricas'
Métricas clave a tener en cuenta:
vllm:num_requests_running: solicitudes simultáneas actuales vllm:num_requests_waiting: solicitudes en cola (si consistentemente > 0, necesita más capacidad) vllm:gpu_cache_usage_perc: utilización de caché KV (valores altos = acercándose a los límites de memoria) vllm:avg_spawn_throughput_toks_per_s: su rendimiento real
🤩 ¿Costos de cambio cero?
Sí.
Utiliza la API de OpenAI:
La API que utiliza vLLM es totalmente compatible.
Debe iniciar vLLM con la llamada a herramientas habilitada explícitamente. También necesita especificar un analizador para que vLLM sepa cómo extraer las llamadas a la herramienta de la salida del modelo (por ejemplo, llama3_json, hermes, mistral).
Para Qwen3.5, agregue las siguientes marcas cuando ejecute vLLM
–enable-auto-tool-choice –tool-call-parser qwen3_xml –reasoning-parser qwen3
Utiliza la API de Anthropic:
Necesitamos agregar un paso más, algo complicado. Agregue un proxy LiteLLM como "phantom-claude" para manejar solicitudes con formato Anthropic.
LiteLLM actuará como una capa de traducción. Intercepta las solicitudes formateadas por Anthropic (por ejemplo, API de mensajes, bloques de uso de herramientas) y las convierte al formato OpenAI que espera vLLM, luego asigna la respuesta para que su cliente Anthropic nunca sepa la diferencia.
Nota: Agregue este proxy en la máquina/contenedor que realmente ejecuta sus agentes y no en el host LLM.
La configuración es fácil:
model_list: – model_name: claude-local # El nombre que usará su cliente Anthropic litellm_params: model: openai/qwen3.5-27b # Le dice a LiteLLM que use el adaptador compatible con OpenAI api_base: http://yourvllm-server:8000/v1 # aquí es donde está sirviendo vLLM api_key: sk-1234
Ejecute LiteLLM
pip install 'litellm[proxy]' litellm –config config.yaml –puerto 4000
Cambios en su código fuente (llamada de ejemplo con la API de Anthropic)
import anthropic client = anthropic.Anthropic( base_url="http://localhost:4000", # Apunte al proxy LiteLLM api_key="sk-1234" # Debe coincidir con su clave maestra LiteLLM) respuesta = client.messages.create( model="claude-local", # modelo proxy max_tokens=1024, mensajes=[{"role": "user", "content": "¿Cuál es el ¿clima en Nueva York?"}], herramientas=[{ "name": "get_weather", "description": "Obtener el clima actual", "input_schema": { "type": "object", "properties": {"location": {"type": "string"}} } }] ) # LiteLLM traduce la respuesta de vLLM nuevamente a un Anthropic ToolUseBlock print(response.content[0].nombre) # Salida: 'get_weather'
¿Qué pasa si no quiero usar Qwen?
Volverse pícaro, es bastante justo.
Solo asegúrese de que los argumentos para –tool-call-parser y –reasoning-parser y –quantization coincidan con el modelo que está utilizando.
Dado que está utilizando LiteLLM como puerta de enlace para un cliente de Anthropic, tenga en cuenta que el SDK de Anthropic espera una estructura muy específica para "pensar" frente a "uso de herramientas". Cuando todo lo demás falla, canalice todo a la salida estándar e inspeccione dónde está el error.
🤑 ¿Cuánto va a costar esto?
Un sistema de agente de producción típico puede consumir:
200 a 500 millones de tokens/mes
Al precio de API, eso a menudo se ubica entre:
$2,000 – $8,000 por mes
Como se mencionó, la escalabilidad de costos es importante. Voy a proporcionar dos escenarios realistas con estimaciones de tokens mensuales tomadas de escenarios de producción del mundo real.
Escenario 1: equipo mediano, carga de trabajo de producción de múltiples agentes
Configuración: Qwen 3.5 72B (Q4_K_M) en un GCP a2-ultragpu-1g (1x A100 80GB)
Costo de API comparable: 20 agentes ejecutando cargas de trabajo de producción, con un promedio de 500 000 tokens/día:
500K × 30 = 15 millones de tokens/mes por agente × 20 agentes = 300 millones de tokens/mes A ~$9/M de tokens: ~$2,700/mes
Casi equivalente en costo, pero con el autohospedaje también obtienes: sin límites de velocidad, sin datos que salen de tu VPC, latencia del primer token inferior a 20 ms (frente a 200-500 ms API de ida y vuelta) y la capacidad de realizar ajustes.
Escenario 2: Equipo de investigación, experimentación y evaluación
Configuración: varios modelos en una instancia puntual A100, funcionando 10 horas al día entre semana
Esto le brinda experimentación ilimitada: intercambie modelos, pruebe niveles de cuantificación y ejecute evaluaciones por el precio de una factura de API moderadamente pesada.
Estar siempre optimizando
Utilice instancias puntuales y haga que sus agentes sean "reprogramables" o "interruptibles": Langchain proporciona funciones integradas para esto. De esa manera, si alguna vez lo desalojan, su agente puede continuar desde un punto de control cada vez que se reinicie la instancia. Implemente una verificación de estado a través de AWS Lambda u otro para reiniciar la instancia cuando se detenga. Si sus agentes no necesitan ejecutarse durante la noche, programe paradas e inicios con cron o cualquier otro programador. Considere instancias de uso comprometido/reservadas. Si es una startup que planea ofrecer servicios basados en IA en el futuro, esto por sí solo puede generarle ahorros de costos considerables. Supervise sus métricas de uso de vLLM. Compruebe si hay señales de sobreaprovisionamiento (solicitudes en cola, utilización). Si solo estás usando el 30% de tu capacidad, baja de categoría.
✅Resumiendo las cosas
Autohospedar un LLM ya no es un esfuerzo de ingeniería masivo, es un patrón de implementación práctico y bien comprendido. El ecosistema de modelos de peso abierto ha madurado hasta el punto en que modelos como Qwen 3.5 y GLM-4,7 rivalizan con las API de vanguardia en las tareas que más importan a los agentes: llamada de herramientas, seguimiento de instrucciones, generación de código y razonamiento de múltiples turnos.
Recordar:
Elija su modelo basándose en puntos de referencia agentes (BFCL, τ-bench, SWE-bench, IFEval), no en clasificaciones de tablas de clasificación generales. Cuantifique a Q4_K_M para obtener el mejor equilibrio entre calidad y eficiencia de VRAM. No baje del tercer trimestre para los agentes de producción. Utilice vLLM para inferencia de producción. Las instancias A100 de GPU única de GCP son actualmente el mejor valor para los modelos de clase 70B. Para los modelos de clase 32B, L40, L40S, L4 y A10 son alternativas capaces. El cruce de costos de API a autohospedado ocurre entre 40 y 100 millones de tokens por mes, según el modelo y el tipo de instancia. Más allá de eso, el autohospedaje es más barato y más capaz. Empiece de forma sencilla. Una sola máquina, una sola GPU, un modelo, vLLM, systemd. Póngalo en funcionamiento, valide su canal de agentes E2E y luego optimícelo.
¡Disfrutar!