Servidor local de IA: cómo calcular la concurrencia real antes de prometer un asistente privado para todo el equipo

La cifra de la demo no es la capacidad del servicio

Un modelo que genera texto con rapidez para una sola persona no tiene, por ese hecho, capacidad demostrada para un equipo. La demostración aislada suele partir de una solicitud corta, sin cola, con la caché y el proceso ya calientes y sin otras conversaciones reteniendo memoria. Un servicio compartido opera en condiciones distintas: las solicitudes llegan a ritmos irregulares, tienen entradas y salidas heterogéneas, compiten por la memoria de la GPU y esperan cuando el sistema no puede ejecutarlas de inmediato.

La capacidad útil no debería comunicarse como una única cifra de tokens por segundo. Conviene expresarla como un compromiso condicionado: para unos escenarios de entrada y salida definidos, una concurrencia determinada mantiene objetivos de tiempo hasta el primer token, tiempo total de respuesta y tasa de rechazo o espera. Esa formulación permite contrastar una promesa interna con una prueba repetible y evita extrapolar desde una demo favorable.

En serving de modelos generativos hay métricas separadas para el tiempo en cola, el tiempo hasta el primer token, el tiempo de generación, la latencia entre tokens y la latencia de extremo a extremo. Esa separación importa porque dos configuraciones con el mismo rendimiento medio pueden ofrecer experiencias muy diferentes: una puede empezar a responder pronto pero terminar lentamente; otra puede retrasar el inicio por acumulación de trabajo. Las guías de modelos locales y las comparativas de runtimes deben tratar estas dimensiones por separado antes de recomendar una configuración.

La pregunta operativa tampoco es simplemente «¿cuántas personas hay en la empresa?». Es «¿cuántas solicitudes activas, de qué tamaño y con qué objetivo de latencia deben sostenerse a la vez?». Treinta personas con uso ocasional pueden implicar una concurrencia reducida. En cambio, unas pocas automatizaciones que adjuntan documentos extensos o producen respuestas largas pueden saturar el mismo servidor. La medición debe representar esas cargas, no una noción abstracta de usuario.

Defina el servicio antes de elegir o ampliar el hardware

Empiece por describir la demanda esperada en unidades que el servidor pueda observar. Registre el número de solicitudes activas, no solo usuarios registrados; la distribución de tokens de entrada; el máximo permitido de salida; el tipo de tarea; la tasa de llegadas; y los objetivos de disponibilidad y latencia. Si no existe tráfico histórico, formule hipótesis explícitas y pruebe escenarios conservadores. Una estimación no se convierte en un hecho por expresarse con precisión numérica.

Separe al menos tres clases de trabajo. El chat breve suele tener pocas entradas y salidas moderadas. Una consulta con recuperación aumentada puede incluir fragmentos de documentos y tener una entrada considerable aunque la respuesta sea corta. La redacción, extracción o generación de código puede requerir salidas largas y mantener la conversación activa durante más tiempo. Mezclarlas en un único promedio oculta los casos que consumen más memoria o bloquean la cola.

Para cada clase, defina un presupuesto: tokens de entrada típicos y máximos, tokens de salida típicos y máximos, solicitudes simultáneas previstas y límites de experiencia. El objetivo de latencia debe incluir al menos el tiempo hasta el primer token y el tiempo hasta finalizar. También debe decidir si un usuario puede cancelar una generación, qué sucede cuando alcanza un límite y si hay clases prioritarias. Sin estas reglas, la capacidad depende de decisiones implícitas tomadas por el runtime bajo presión.

La comparación entre modelos locales solo es útil después de fijar este contrato de servicio. Un modelo más pequeño puede permitir una concurrencia mayor o respuestas más previsibles con el mismo hardware; otro modelo puede justificarse por calidad para una carga concreta, pero exigir límites más estrictos. No hay una configuración universalmente suficiente: la decisión debe relacionar la calidad requerida con resultados medidos bajo el patrón de uso propio.

Construya un presupuesto de memoria, pero no lo confunda con una garantía

La memoria disponible para servir un modelo no se reduce al tamaño publicado de sus pesos. Debe coexistir con los pesos cargados, la caché de claves y valores de las conversaciones activas, buffers y espacio temporal de ejecución, estructuras del runtime y una reserva para variaciones y recuperación. La distribución exacta depende del modelo, la cuantización, el runtime, el hardware y la configuración; por tanto, no debe presentarse una fórmula genérica como si fuera una medición universal.

La caché KV es decisiva para la concurrencia. Conserva el estado de atención necesario para continuar una secuencia y crece con los tokens procesados. En un servicio, su ocupación cambia por solicitud: una conversación extensa, una entrada recuperada de gran tamaño o una salida larga pueden retener una parte relevante de la memoria durante más tiempo que una pregunta corta. La investigación sobre PagedAttention identifica la gestión de esta caché, incluida la fragmentación y la duplicación en determinados patrones, como un elemento que condiciona el tamaño de lote efectivo.

Es razonable usar un presupuesto de trabajo para planificar, siempre que se etiquete como estimación. Primero mida la memoria base con el modelo ya cargado y sin tráfico. Después observe cómo cambia al ejecutar cada escenario con longitudes controladas y concurrencia creciente. Reserve capacidad que no se asigne a la carga nominal. Finalmente, valide que la política de admisión evita sobrepasar el límite en una ráfaga. El resultado relevante es el comportamiento observado en la configuración concreta, no un cálculo aislado.

Las métricas del runtime pueden exponer utilización de caché KV, solicitudes en ejecución y solicitudes esperando, además de medidas de prefill y decode. Esas observaciones permiten atribuir un incidente con mayor cautela: no prueban por sí solas una causa física única, pero ayudan a distinguir una cola creciente de una presión sostenida sobre la caché o de una generación lenta. Conserve la configuración que produjo cada serie temporal para que el análisis sea reproducible.

Prefill y decodificación: dos fases, dos posibles cuellos de botella

La petición no consume recursos de la misma forma durante toda su vida. En el prefill, el sistema procesa la entrada para construir el estado que utilizará la generación. En la decodificación, produce tokens sucesivos y actualiza ese estado. Una solicitud con un documento largo puede tener un inicio lento aun cuando su respuesta sea breve; una respuesta extensa puede comenzar pronto y, sin embargo, retener recursos durante mucho tiempo. Medir solo la duración completa borra esta diferencia.

El tiempo hasta el primer token es una señal útil para el usuario y suele reflejar tanto la espera en cola como el trabajo previo necesario para comenzar a generar. La latencia entre tokens, el tiempo por token de salida y el tiempo total aportan otra perspectiva sobre la fase de generación. Conviene registrar también el tamaño real de entrada y salida, porque una variación en estas longitudes puede explicar una variación aparente de latencia sin que haya cambiado el hardware.

El batching continuo puede elevar el aprovechamiento al mezclar trabajo de distintas solicitudes, pero no elimina los límites de memoria ni garantiza justicia entre cargas. Una carga de contexto amplio puede competir con chats breves; las decisiones del planificador afectan a quién inicia antes y a quién permanece en cola. Por eso una prueba representativa debe incluir tanto lotes homogéneos como una mezcla controlada de escenarios, reportados por separado.

No interprete una reducción del rendimiento medio como un diagnóstico automático. Puede deberse a llegadas más rápidas que la capacidad de servicio, a entradas más largas, a un máximo de salida elevado, a presión de memoria o a una política de planificación. La instrumentación debe dar contexto suficiente para identificar correlaciones y, si no puede atribuir la causa, debe declarar la incertidumbre.

De la VRAM a una concurrencia operativa

La concurrencia operativa es el mayor número de solicitudes que puede admitir el servicio para un escenario definido sin incumplir sus objetivos. No debe deducirse directamente de la memoria libre ni de un máximo teórico de contexto. La memoria puede ser suficiente y, aun así, la cola o la latencia exceder el presupuesto. A la inversa, un resultado aceptable a una concurrencia concreta no valida una carga con entradas o salidas mayores.

Construya una matriz de ensayo. En una dimensión, establezca las clases de carga y sus longitudes de entrada y salida. En otra, aumente las solicitudes simultáneas. Para cada celda, repita la prueba tras calentamiento y recoja percentiles de espera, TTFT, latencia de generación y tiempo de extremo a extremo. Anote tokens realmente procesados, uso de caché, solicitudes activas y en cola, cancelaciones, rechazos y errores. Los promedios pueden añadirse, pero no deben sustituir a los percentiles.

La capacidad debe definirse por el peor resultado que se acepta, no por el máximo que llega a completar una ejecución. Si el p95 de inicio supera el objetivo, si la cola crece de forma persistente o si aparecen errores de memoria, esa concurrencia no es una capacidad operativa para ese escenario. Puede conservarse como punto de fallo estudiado, útil para ajustar límites, pero no como una promesa al usuario.

También es importante probar la recuperación después de la presión. Tras una ráfaga, observe si la cola vuelve a niveles normales, si la memoria se libera como se espera y si las solicitudes nuevas recuperan la latencia habitual. Un sistema que completa una prueba breve pero no se recupera con rapidez puede resultar frágil para una API interna.

Use colas y admisión explícita antes de llegar al fallo

La cola no es necesariamente un error: puede ser una decisión controlada para proteger solicitudes ya iniciadas. El problema aparece cuando no hay límite, cuando el usuario no sabe que espera o cuando se sigue aceptando trabajo que no podrá cumplir el presupuesto. Una política de admisión debe decidir, antes de asignar recursos, si una petición puede entrar, esperar, recibir un límite menor o ser rechazada con una respuesta clara.

Los controles habituales incluyen límites por usuario o credencial, un máximo de tokens de entrada, un máximo de salida, un número máximo de solicitudes activas, una longitud máxima de cola y un tiempo máximo de espera. La cancelación debe liberar trabajo y memoria de forma verificable. Si existen clases de prioridad, documéntelas: una prioridad no crea capacidad, sino que distribuye de otro modo una capacidad limitada.

La degradación debe ser explícita y compatible con el caso de uso. Por ejemplo, una interfaz puede pedir al usuario que reduzca documentos adjuntos, aplicar un límite de salida anunciado o posponer una tarea no interactiva. No es apropiado truncar silenciosamente información crítica ni cambiar un modelo sin informar cuando ello altere el resultado esperado. La política debe determinar qué ocurre antes de que el runtime alcance un error por falta de memoria.

Los contadores de solicitudes esperando y ejecutándose, junto con métricas de trabajo de prefill y decode, permiten evaluar si las reglas protegen el servicio. Pruebe deliberadamente una carga superior a la admitida: compruebe que se limita el nuevo trabajo y que la latencia de las solicitudes en curso no se deteriora de forma descontrolada. Este ensayo de sobrecarga es tan importante como la prueba nominal.

Protocolo reproducible en el hardware propio

Una prueba útil debe poder repetirse. Congele y registre la identidad del modelo disponible, su cuantización, el runtime, la versión de controlador, el tipo y cantidad de GPU, los límites de contexto y salida, los parámetros de batching y la política de admisión. Si cualquiera de estas variables cambia, trate el resultado como una nueva medición, no como una continuación automática de la anterior.

Prepare una carga sintética basada en los escenarios definidos, sin usar conversaciones reales salvo que exista una autorización específica y controles adecuados. La carga debe fijar o registrar longitudes de entrada y salida. Ejecute un calentamiento separado de la medición, haga varias repeticiones y mantenga un periodo de observación suficiente para detectar colas que crecen. Informe p50, p95 y p99 cuando el volumen de muestras permita interpretarlos; junto a ellos, indique el número de solicitudes y el intervalo de prueba.

La documentación de benchmarking de vLLM contempla métricas como TTFT, tiempo por token de salida y latencia entre tokens, y advierte que la caché de prefijos puede elevar resultados si no se controla. Si utiliza una caché de prefijos en producción, pruébela de forma representativa y declare si los prompts se repiten; si no representa la carga esperada, desactívela o sepárela en otro escenario. Un resultado que depende de una reutilización irreal no es una estimación prudente de capacidad.

No basta con conservar un panel. Guarde un resumen de configuración, generador de carga, parámetros, resultados agregados y criterios de aceptación. La reproducibilidad permite comparar una actualización del modelo o del runtime y descubrir regresiones. También evita que una decisión de compra o despliegue dependa de recuerdos sobre una demostración anterior.

Decidir con evidencia: límites, cambios de modelo o más hardware

Con los resultados reunidos, decida contra el requisito, no contra la intuición. Conserve la configuración si cumple los escenarios prioritarios con margen y se recupera tras picos. Reduzca el contexto o el máximo de salida cuando el producto pueda hacerlo explícitamente y las pruebas muestren que esa medida recupera los objetivos. Limite la concurrencia si el patrón de demanda admite espera controlada. Separar cargas puede ser preferible cuando las tareas de documentos largos interfieren con el chat interactivo.

Añadir GPU o cambiar de arquitectura es una decisión razonable solo después de identificar qué restricción se pretende aliviar. Si la presión de caché domina, el presupuesto de memoria y la distribución de contexto son centrales. Si el prefill de entradas largas incumple el TTFT, evalúe esa fase por separado. Si la calidad del modelo no satisface la tarea, más concurrencia no resuelve el problema. La evidencia de una prueba no permite inferir automáticamente cuál de estas alternativas será óptima sin medirla.

Cambiar de modelo también requiere repetir la matriz. Dos modelos con una denominación de tamaño parecida pueden usar configuraciones de contexto, cuantizaciones y runtimes distintos. El cambio puede alterar tanto la memoria base como el comportamiento de generación. En una comparativa interna, comunique las condiciones completas y no atribuya al tamaño de pesos una causalidad que no se haya aislado.

Si no existe una configuración que cumpla el requisito con límites aceptables, la decisión honesta puede ser no desplegar todavía el servicio compartido. Es preferible ofrecer un piloto limitado, con alcance claramente definido, que prometer un asistente privado generalista sin presupuesto de capacidad. El inventario de modelos locales y las comparativas deben presentar esa conclusión como una posibilidad operativa, no como un fracaso.

Privacidad, telemetría y checklist de despliegue

La instrumentación de capacidad no debe crear un repositorio paralelo de conversaciones. Las especificaciones de telemetría para IA generativa advierten que los mensajes de entrada, salida, instrucciones y argumentos pueden contener información sensible o datos personales. Para medir concurrencia no suele ser necesario almacenar el texto completo: las longitudes en tokens, marcas temporales, identificadores pseudonimizados, resultado de admisión y métricas de latencia suelen ser suficientes.

Antes de habilitar trazas detalladas, defina qué campos se recogen, para qué diagnóstico, quién accede, cuánto tiempo se retienen y cómo se eliminan. Si se conservan prompts o respuestas para depurar, la excepción debe tener justificación, controles de acceso y un periodo de retención limitado. Revise también si atributos aparentemente inocuos, como nombres de herramientas o argumentos, pueden revelar información de negocio.

La evidencia mínima de un despliegue interno incluye el contrato de servicio, los escenarios, el entorno técnico, el método de carga, percentiles por escenario, comportamiento al superar el límite, política de admisión y tratamiento de la telemetría. Distinga siempre entre lo medido, lo estimado y lo que aún no se ha probado. Esta disciplina permite ajustar el servicio sin convertir una cifra de demostración en una garantía no respaldada.

La capacidad no es permanente. Cambios de modelo, cuantización, controlador, runtime, parámetros de contexto, caché o política de planificación pueden invalidar resultados anteriores. Programe una repetición de la prueba cuando cambien elementos materiales y supervise en producción que las distribuciones reales de entrada, salida y espera no se alejen de los escenarios aprobados.

Continúa explorando

Correcciones y transparencia

Si detectas un dato incorrecto o desactualizado, puedes enviarnos una corrección indicando la página y la fuente que debemos revisar.