Inicio / Artículos / LLMOps para modelos de lenguaje pequeños: frameworks de servicio y guías para producción.

LLMOps para modelos de lenguaje pequeños: frameworks de servicio y guías para producción.

Por qué los SLM ganan en costo y privacidad, cómo se comparan vLLM, SGLang, TGI, llama.cpp, Ollama, WebLLM, ONNX y TensorRT-LLM, y cómo cuantificarlos, evaluarlos y enrutarlos en producción.

4127 palabras

LLMOps prácticos para modelos de lenguaje compactos: cuándo la inferencia local o en el dispositivo supera a las APIs de vanguardia, qué stacks de servidores se adaptan a qué limitaciones de hardware y cómo mantenerlos en buen estado después del primer intento exitoso con curl.

Introducción

Entre la opción de “afinar el modelo más grande para todo” y la de “ejecutar un modelo con menos de mil millones de parámetros en un teléfono”, las prioridades en la producción han cambiado. Muchas tareas, como la clasificación de intenciones, el enrutamiento de herramientas, la extracción estructurada y el reordenamiento con RAG, no necesitan modelos de nivel avanzado una vez que un SLM sólido está cuantizado y se sirve adecuadamente.

El problema: un SLM sin una estrategia de servido es solo un punto de control en el disco. Ejecutarlo en producción plantea cuestiones relacionadas con la memoria de la GPU, el agrupamiento de solicitudes, la fidelidad de la cuantización, las operaciones de reversión y la evaluación, temas que los manuales clásicos de MLOps apenas abordan.

Un modelo que no se puede desplegar, monitorear ni revertir no es un activo de producción: es una carga con puntuaciones de referencia atractivas.

Esta guía aborda el problema, el panorama de los marcos y un manual para producción, en ese orden. El proceso es continuo: un punto de control se convierte en una capacidad solo después de superar las pruebas de servicio, evaluación y operativas.

El problema: por qué “un modelo más grande” dejó de ser la solución por defecto

1. El costo y la latencia se incrementan a escala

Enviar una consulta simple de clasificación de tickets a un modelo de 70 mil millones de parámetros desperdicia capacidad. Los parámetros adicionales brindan capacidades que quizás no se necesiten, al mismo tiempo que multiplican los segundos de uso de la GPU y la latencia en situaciones de concurrencia. A escala de producto, esos costos se vuelven dominantes.

2. La gravedad de los datos y la privacidad impulsan la inferencia hacia el perímetro

Los trabajos de salud, finanzas y consumo en el dispositivo a menudo no pueden enviar texto sin procesar a una API de terceros. Un SLM que cabe en unos pocos gigabytes de RAM puede operar junto a los datos —en GPUs locales, laptops o teléfonos— cumpliendo con los requisitos de residencia que el modelo basado en la nube no puede satisfacer.

3. La infraestructura de servicio tiene sus propios modos de fallo

El servicio de modelos falla de manera diferente a los errores habituales de las aplicaciones: fragmentación de la memoria de GPU debido a una asignación ingenua del caché KV, estrangulamiento del programador bajo tráfico intermitente, incompatibilidades en la cuantización que degradan silenciosamente la calidad, y arranques lentos que incumplen los objetivos de rendimiento tras reducir la escala a cero.

4. LLMOps es una disciplina distinta de MLOps

El enfoque clásico de MLOps asume formas relativamente estables y puntuaciones deterministas. LLMOps añade versiones no determinísticas de texto, prompts y herramientas, además de consideraciones económicas relacionadas con los tokens y filtros de seguridad. La regresión ya no se refiere solo a “una disminución del 2% en la precisión”, sino también a “una menor adhesión al esquema JSON” o “una caída en los tokens por segundo después de una actualización del controlador”.

¿Qué es LLMOps y en qué se diferencia de MLOps?

LLMOps abarca cómo los equipos despliegan, alojan, monitorean y mejoran modelos de lenguaje en sistemas en tiempo real, con la misma seriedad operativa que se aplica a cualquier otro servicio crítico.

Mientras MLOps se pregunta si la precisión ha regresado, LLMOps también se pregunta:

¿El motor de servicio utiliza la memoria de GPU de manera eficiente bajo condiciones de concurrencia?
¿El artefacto cuantizado mantiene suficiente fidelidad para esta tarea?
¿Las versiones de prompts/herramientas están fijadas y permiten una reversión?

¿Puede el tráfico cambiar entre modelos sin necesidad de reescribir el cliente?

¿Muestran los registros el costo de los tokens y la latencia por ruta?

El resto de esta guía responde a esas preguntas específicamente para los SLMs.

El panorama de los marcos de despliegue de SLM

En cuanto al rendimiento bruto de la GPU, vLLM es una opción común para altos niveles de solicitudes por segundo, con una API compatible con OpenAI en GPUs NVIDIA o AMD. SGLang compite cuando es importante el reuso de prefijos y la generación estructurada. Hugging Face TGI es adecuado para equipos que ya están estandarizados con el Hub y los charts Helm.

En el ámbito portátil, llama.cpp / GGUF funciona en CPUs, Apple Silicon y muchas GPUs para consumidores. Ollama encapsula todo esto para ofrecer una experiencia local con solo dos comandos. LM Studio añade una interfaz gráfica de escritorio para la evaluación. MLC-LLM / WebLLM se compilan para navegadores y dispositivos móviles. ONNX Runtime GenAI está orientado a Windows/NPU y a los estándares empresariales ONNX. TensorRT-LLM + Triton busca el máximo rendimiento en las placas NVIDIA tras una compilación previa.

Cada uno convierte un punto de control en respuestas; difieren en las suposiciones sobre el hardware, el peso de las operaciones y el diseño de concurrencia.

Análisis en profundidad de los frameworks

vLLM

vLLM popularizó PagedAttention, gestionando la caché KV de forma similar a la memoria virtual para que las secuencias concurrentes gasten menos RAM en la GPU. El agrupamiento continuo mantiene un alto nivel de utilización.

# Install vLLM
pip install vllm

# Serve using VLLM
vllm serve Qwen/Qwen2.5–1.5B-Instruct - port 8000 # fully OpenAI-compatible endpoint


# Make Request
curl http://localhost:8000/v1/chat/completions \
-H 'Content-Type: application/json' \
-d '{
  "model": "Qwen/Qwen2.5–1.5B-Instruct",
  "messages": [{"role": "user", "content": "Write a haiku about model quantization"}]
}'

# Python Script for vllm

from openai import OpenAI
client = OpenAI(base_url="http://localhost:8000/v1", api_key="not-needed")
resp = client.chat.completions.create(
    model="Qwen/Qwen2.5–1.5B-Instruct",
    messages=[{"role": "user", "content": "Summarize LLMOps in one sentence."}],
)
print(resp.choices[0].message.content)

Mejor para: servidores backend de alto QPS y servicios RAG que necesitan endpoints compatibles con OpenAI. Ventajas: rendimiento, cobertura de modelos, formatos de cuantización (AWQ/GPTQ/FP8). Desventajas: centrado en GPU; aún requiere orquestación para alta disponibilidad.

SGLang

SGLang se basa en RadixAttention para compartir cachés de prefijos entre solicitudes relacionadas, lo que es útil en bucles de agentes con prompts del sistema repetidos; además incluye un DSL sgl.function para generación estructurada.

# Installation
pip install "sglang[all]"

# SGLang launch server
python -m sglang.launch_server \
 - model-path Qwen/Qwen2.5–1.5B-Instruct \
 - port 30000


# CURL Request
curl http://localhost:30000/v1/chat/completions \
-H 'Content-Type: application/json' \
-d '{
  "model": "Qwen/Qwen2.5–1.5B-Instruct",
  "messages": [{"role": "user", "content": "Write a haiku about model quantization"}]
}'

import sglang as sgl

@sgl.function
def classify(s, ticket):
  s += sgl.user(f"Classify this support ticket as billing/technical/other: {ticket}")
  s += sgl.assistant(sgl.gen("label", max_tokens=8))

sgl.set_default_backend(sgl.RuntimeEndpoint("http://localhost:30000"))
state = classify.run(ticket="My invoice charged me twice this month")
print(state["label"])

Mejor para: pipelines de agentes y salidas JSON con restricciones. Ventajas: reutilización de prefijos, salida estructurada. Desventajas: ecosistema más pequeño que vLLM; solo funciona con GPU.

Hugging Face Text Generation Inference (TGI)

TGI se integra al ecosistema Hub con un empaquetado compatible con Docker/Kubernetes.

docker run - gpus all -p 8080:80 \
-v $PWD/data:/data \
ghcr.io/huggingface/text-generation-inference:latest \
 - model-id microsoft/Phi-3.5-mini-instruct \
 - quantize bitsandbytes-nf4

from huggingface_hub import InferenceClient
client = InferenceClient("http://localhost:8080")
print(client.text_generation("Explain quantization in one line.", max_new_tokens=64))

Mejor para: equipos centrados en Hub y arquitecturas reguladas que buscan un camino de servicio con soporte. Ventajas: integración con Hub, opciones de cuantización, soporte mediante Helm. Desventajas: algunas cargas de trabajo siguen prefiriendo vLLM por su mayor rendimiento bruto; revise los términos de la licencia con el tiempo.

llama.cpp / GGUF

Creado para ejecutar LLaMA en la CPU de una MacBook, llama.cpp sienta las bases de gran parte del mundo de modelos locales y en el perímetro mediante la cuantización GGUF.

# macOS: brew install llama.cpp   |   or build from source:
# git clone https://github.com/ggml-org/llama.cpp && cd llama.cpp && cmake -B build && cmake --build build

# Pull a quantized SLM straight from Hugging Face and serve an OpenAI-compatible endpoint
llama-server -hf Qwen/Qwen2.5-0.5B-Instruct-GGUF:Q4_K_M \
    --port 8090 -c 4096 -ngl 999   # -ngl offloads layers to GPU if available (Metal/CUDA)

curl http://localhost:8090/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{"messages":[{"role":"user","content":"What is GGUF?"}]}'

Mejor para: servidores con CPU, Apple Silicon, y dispositivos Pi o de perímetro sin CUDA. Ventajas: portabilidad, escalera madura de cuantización, licencia MIT. Desventajas: su rendimiento concurrente es inferior al de las arquitecturas nativas para GPU.

Ollama

Ollama integra llama.cpp en una experiencia de desarrollo sencilla de arrastrar y ejecutar, con una API HTTP local.

ollama pull qwen2.5:1.5b
ollama run qwen2.5:1.5b "Write a haiku about model quantization"

import requests
r = requests.post("http://localhost:11434/api/chat", json={
  "model": "qwen2.5:1.5b",
  "messages": [{"role": "user", "content": "Give me 3 LLMOps metrics to track"}],
  "stream": False,
})
print(r.json()["message"]["content"])

Mejor para: desarrollo local, prototipos y autohospedaje en equipos pequeños. Ventajas: experiencia de desarrollo y configuraciones predeterminadas. Desventajas: no está diseñado para la programación de tareas en entornos de producción con alta concurrencia.

LM Studio

Una interfaz gráfica de escritorio que utiliza motores locales similares para permitir la navegación, descarga y comunicación; además incluye un servidor compatible con OpenAI con un solo clic para demostraciones. Es ideal para evaluar antes de crear manifiestos de despliegue; no es un componente de infraestructura que se pueda implementar a gran escala.

MLC-LLM / WebLLM

Basado en Apache TVM, MLC compila modelos para diversos backends; WebLLM se ejecuta completamente en el navegador.

pip install mlc-llm

mlc_llm chat HF://mlc-ai/Qwen2.5-1.5B-Instruct-q4f16_1-MLC

// WebLLM: fully in-browser inference, no backend server
import * as webllm from "@mlc-ai/web-llm";

const engine = await webllm.CreateMLCEngine("Qwen2.5-1.5B-Instruct-q4f16_1-MLC");
const reply = await engine.chat.completions.create({
  messages: [{ role: "user", content: "Explain WebGPU inference simply." }],
});
console.log(reply.choices[0].message.content);

Mejor para: aplicaciones móviles, inferencia en el cliente que protege la privacidad y funciones sin conexión. Ventajas: compilación multiobjetivo; no se necesita servidor para WebLLM. Desventajas: complejidad en la compilación; limitaciones del dispositivo en los navegadores.

ONNX Runtime GenAI

La API GenAI de Microsoft amplía ONNX Runtime para la generación autoregresiva con gestión de caché KV a través de Windows DirectML y NPUs.

pip install onnxruntime-genai

python -c "
import onnxruntime_genai as og
model = og.Model('phi-3.5-mini-onnx-directml')
tokenizer = og.Tokenizer(model)
tokens = tokenizer.encode('Explain ONNX Runtime GenAI briefly.')
params = og.GeneratorParams(model)
params.set_search_options(max_length=200)
generator = og.Generator(model, params)
generator.append_tokens(tokens)
while not generator.is_done():
    generator.generate_next_token()
print(tokenizer.decode(generator.get_sequence(0)))
"

Mejor para: aplicaciones nativas de Windows y empresas que utilizan el estándar ONNX. Ventajas: portabilidad tras la exportación. Desventajas: dificultades en la conversión; comunidad más pequeña que las engines nativas de PyTorch.

NVIDIA TensorRT-LLM + Triton Inference Server

TensorRT-LLM compila con antelación engines con núcleos fusionados; Triton gestiona flotas de múltiples modelos.

# Build a TensorRT-LLM engine for a small model (simplified)
trtllm-build --checkpoint_dir ./qwen2.5-1.5b-checkpoint \
    --output_dir ./qwen2.5-1.5b-engine \
    --gemm_plugin float16

# Serve via Triton
tritonserver --model-repository=/models

Mejor para: el máximo rendimiento de flotas NVIDIA y rutas críticas en cuanto a latencia. Ventajas: rendimiento óptimo una vez compilado. Desventajas: los motores son específicos por SKU y formato; se deben reconstruir tras cambios en el hardware o los perfiles de lote.

Elegir un framework: Una guía de decisión

Un modelo mental: Tres preguntas, no una lista de características

Pregunta 1: ¿Dónde debe ejecutarse físicamente el modelo? Navegador o teléfono sin llamada a red → WebLLM/MLC. CPU/Apple/edge sin CUDA → llama.cpp/Ollama. Solo entonces considerar motores de centro de datos con GPU.

Pregunta 2: ¿Se trata de un servicio en producción o de exploración por parte de usuarios? Exploración → LM Studio u Ollama. API para producción → vLLM/SGLang/TGI/TensorRT según la siguiente pregunta.

Pregunta 3 (solo producción de GPU): ¿Cuál es la forma del tráfico y cuánto presupuesto de ingeniería existe? Completaciones independientes de un solo uso → vLLM como opción predeterminada. Prefijos de agentes altamente repetitivos / salidas estructuradas → SGLang. Optimización máxima de NVIDIA con inversión en plataforma → TensorRT-LLM + Triton. Comodidad en entornos Hub/Helm → TGI.

Búsquedas comprimidas:

Rendimiento máximo de la API de GPU → vLLM (o SGLang si es para agentes o tareas repetitivas)
Pico absoluto de NVIDIA con presupuesto para compilación → TensorRT-LLM + Triton
CPU/Apple/dispositivos periféricos → llama.cpp; envoltorio DX → Ollama
Navegador/cliente sin conexión → WebLLM/MLC
Windows/NPU/estándar ONNX → ONNX Runtime GenAI
Evaluación con un clic → LM Studio

Sistemas de agentes empresariales frente al resto

El tráfico de solicitud/respuesta de un solo turno favorece el procesamiento en lotes continuos en vLLM. Los agentes empresariales pueden llamar al modelo decenas de veces por tarea: planificación, elección de herramientas, observación, replaneamiento; por lo que el caché de prefijos y las salidas estructuradas son esenciales. Esas implementaciones suelen basarse en SGLang o TensorRT-LLM + Triton en GPUs autohospedadas, con TGI como alternativa cuando la integración con Hub es más importante que el rendimiento máximo.

Las plataformas de agentes multiinquilinos también necesitan cuotas por usuario, seguimiento de las llamadas a herramientas y una reversión clara conjunta de pares de prompts y modelos; son preocupaciones relacionadas con LLMOps que trascienden a cualquier motor en particular.

Guía de implementación en producción

Hacer que algo funcione representa aproximadamente una quinta parte del trabajo. El resto consiste en mantenerlo correcto, económico y seguro.

Considere la cuantización, el registro, la evaluación, los canarios y el enrutamiento como un ciclo que atraviesa cada versión del modelo:

1. Estrategia de cuantización. En muchos escenarios de SLM en producción, la opción predeterminada es AWQ-4bit o GGUF Q4_K_M; generalmente, las métricas de las tareas en FP16 difieren solo un par de porcentajes si se evalúan cuidadosamente, y es necesario confirmar que el motor elegido sea compatible con dicho formato. La cuantización no es una conversión única; finaliza en un punto de evaluación, no con la orden de conversión.

2. Versionado y registro de modelos. Considere los ajustes finos y los artefactos cuantizados como objetos inmutables y versionados; nunca sobrescriba directamente en su lugar. MLFlow, repositorios de Hugging Face Hub con resúmenes de integridad o un registro interno OCI de artefactos funcionan bien siempre que los resúmenes estén especificados en los manifiestos de despliegue.

3. Puntos de evaluación. Mantenga un conjunto estándar para la tarea: F1 en clasificación, precisión en los campos extraídos, tasa de validez del esquema, exactitud en las rechazos y límites de latencia. Impida el paso a producción cuando fallen estos puntos de evaluación, incluso si las pruebas preliminares parecen mejores.

4. Topología de servicio. Separe los tokenizadores/preprocesadores basados en CPU de los trabajadores GPU cuando sea útil; escale automáticamente según la profundidad de la cola y el uso del GPU, no solo según los RPS. Mantenga un grupo de procesos listo para ejecutarse si los arranques en frío violan los SLOs.

5. Observabilidad. Exporte la latencia de las solicitudes, la cantidad de tokens entrantes y salientes, las tasas de acierto en el caché, el tamaño de los lotes y los conteos de errores de memoria insuficiente o intentos de reintentar. Extraiga muestras de las solicitudes con cuidado, respetando la política de privacidad.

6. Retrocesos. Utilice estrategias de tipo blue/green o canary basadas en el resumen del modelo y la versión de la solicitud como unidad. Revierta inmediatamente ambos componentes cuando la calidad disminuya bruscamente.

7. Pruebas A/B y enrutamiento multimodelo

Enruté las tareas según su tipo: utilice modelos SLM para la clasificación y extracción; emplee modelos más grandes para la generación abierta. Dirija tráfico de prueba a los modelos candidatos antes del cambio completo. Registre el costo por tarea completada con éxito, no solo los tokens, para que un modelo más económico que requiera dos intentos de reintentar no sea considerado “ganador” de forma errónea.

Las banderas de funcionalidad deben vincular las rutas del cliente con los puntos finales del modelo nombrados detrás de la pasarela, de modo que los cambios no requieran lanzamientos de la aplicación.

Plantillas por dominio

Aplicaciones de consumo/móviles

Preferir SLMs en el dispositivo o cerca de él mediante MLC/WebLLM o GGUF en entornos de ejecución del dispositivo. Gestionar cuidadosamente la memoria; transmitir tokens para mejorar la experiencia de usuario; mantener una solución alternativa en la nube para consultas complejas con consentimiento claro.

Otros dominios (copilotos de soporte, RAG interno, pasarelas periféricas) siguen el mismo patrón: primero elegir la realidad del hardware, luego el motor, y finalmente el ciclo de cuantización+y evaluación.

Patrones antiétnicos

Lanzar en formato FP16 “por cuestiones de calidad” sin medir una línea de referencia cuantizada en tareas reales
Usar topologías de Ollama/LM Studio para entornos de producción con alto número de solicitudes por segundo sin un motor de servidores diseñado para la concurrencia
Sobrescribir los archivos del modelo directamente, lo que hace que las reversiones sean imposibles

Evaluar únicamente mediante pruebas de ambiente en lugar de conjuntos completos de datos.
Ignorar las métricas de KV-cache y por lotes hasta que se agoten los recursos de las GPU en producción.
Tratar los cambios en los prompts como algo gratuito mientras se fijan las versiones del modelo, o al revés.

Puntos clave

Los SLMs son ventajosos cuando las tareas son específicas, los datos no pueden salir de la infraestructura, o los presupuestos de costo y latencia impiden el uso de modelos avanzados.
LLMOps amplía las capacidades de MLOps mediante eficiencia en el servicio, fidelidad en la cuantización, control de versiones de prompts y herramientas, y consideraciones económicas relacionadas con los tokens.
Elija los motores según el lugar de ejecución (dispositivo/CPU/GPU), la etapa del proceso (exploración vs. servicio) y el tipo de tráfico (un solo uso vs. agente).
El éxito en producción sigue un ciclo: cuantizar → registrar → evaluar → probar con versión preliminar → observar → revertir.
Combine resúmenes fiables de los modelos con un sistema de enrutamiento similar al de timbres para que los clientes mantengan estabilidad mientras evolucionan los servidores.

Referencias

Consulte la documentación oficial de cada proyecto para conocer las banderas de instalación y los valores fijos de versión: vLLM, SGLang, Hugging Face TGI, llama.cpp, Ollama, LM Studio, MLC-LLM/WebLLM, ONNX Runtime GenAI y NVIDIA TensorRT-LLM/Triton. Las guías de hardware de NVIDIA y los documentos de Apple Metal complementan los archivos README de los motores a la hora de ajustar los tamaños de lote y la cuantización.

Tenga un manual interno que registre qué procesos de análisis se ejecutaron con qué conjuntos de datos en qué modelos GPU; este documento es lo que convierte esta guía general en una plataforma operativa.

Anexo: Operación de SLMs de la semana dos a la semana veinte

Después del primer intento exitoso con curl contra un servidor local, surgen las preguntas difíciles: ¿quién se encarga del soporte en tiempo real?, ¿cómo se programan las actualizaciones del controlador CUDA? y, ¿qué ocurre cuando una campaña de marketing triplica los QPS durante la noche? Responda a ellas por escrito antes del primer lanzamiento de prueba.

La planificación de capacidad para los SLMs aún necesita margen para el crecimiento del caché KV a medida que aumenta la longitud del contexto. Un modelo de 1,5 mil millones de parámetros que parece pequeño con un contexto de 2 k puede ejercer presión sobre la memoria cuando los clientes abren ventanas de 32 k. Es necesario hacer un seguimiento por separado de los tokens de contexto en el percentil 95 y de la tasa de solicitudes.

Las revisiones de seguridad deben abarcar la cadena de suministro del modelo: verificación de checksum al descargarlo, quién puede publicar en el registro y si los prompts del sistema que contienen información confidencial llegan alguna vez a los paquetes de los clientes. Los modelos locales necesitan canales de actualización tan cuidadosos como las versiones de aplicaciones móviles.

Las revisiones de costos deben comparar el costo total de propiedad: alquiler de GPU, tiempo de los ingenieros para reconstruir modelos con TensorRT e incidentes de calidad causados por una cuantización excesiva. A veces, un SLM ligeramente más grande en formato de 8 bits es más económico que un modelo muy pequeño que obliga a intervenciones manuales.

Es importante capacitar al equipo. Ofrezca a los ingenieros de aplicaciones un camino preparado: un chart Helm o un archivo Compose, una URL base estándar compatible con OpenAI y paneles de control ya configurados. Proporcione a los ingenieros de ML un camino claro para publicar resúmenes que cumplan con los requisitos. La mayoría de los fallos ocurren en la transferencia de responsabilidades entre estos grupos.

Finalmente, revise cada tres meses la tentación de utilizar “modelos más grandes” con datos concretos. Si la puntuación del conjunto de referencia de un SLM se estanca mientras las tareas de los usuarios se vuelven más complejas, proceda a una actualización selectiva —según el caso— en lugar de reemplazar todo el sistema de la noche a la mañana. El LLMOps para SLMs se trata tanto de moderación como de aceleración.

Nota operativa: fije las versiones exactas de los componentes CUDA en archivos de bloqueo, y registre la versión del controlador junto a cada versión de prueba exitosa para poder identificar las causas de los problemas en los niveles de software y firmware durante los incidentes.

Nota operativa: fije las versiones exactas de los paquetes CUDA en los archivos de bloqueo, y anote la versión del controlador junto a cada versión de prueba exitosa para poder dividir las regresiones entre las capas de software y firmware durante los incidentes.

Lecturas relacionadas

Servir Qwen3.8-27B en un RTX 3090 con vLLM y DFlash2 parcheados — Cómo una versión modificada de vLLM 0.28.0 con embeddings requantizados y la técnica DFlash2 permite ejecutar un modelo híbrido de 27 mil millones de parámetros en una tarjeta de 24 GB, y por qué los contextos largos ralentizan su funcionamiento.
Los modelos pequeños y especializados están superando en silencio a los LLMs gigantes — Vea cómo un modelo lógico de 3 mil millones de parámetros supera a uno de 120 mil millones en razonamiento formal con hardware común, y por qué la adecuación al tarea es más importante que el tamaño bruto del modelo.

Métricas de inferencia de vLLM: De TTFT y TPOT a KV Cache y Goodput — Una guía práctica para las métricas de vLLM en Prometheus: tasas de éxito, percentiles de latencia, relación IO de tokens, interrupciones, relleno previo por bloques, DPD y aceptación de decodificación especulativa.

Todos los artículos Enviar el brief