La frontera eficiente de la inferencia de LLM: cómo equilibrar costo, latencia y calidad

The efficient frontier of LLM inference

La frontera eficiente de la inferencia de LLM: cómo equilibrar costo, latencia y calidad

En la industria de la IA, el término 'frontera eficiente' se usa para describir el equilibrio entre costo y capacidades de los modelos. En la ingeniería de inferencia, esta frontera se manifiesta en el balance entre latencia y rendimiento, y puede desplazarse mediante técnicas como el ajuste del tamaño de lote, la paralelización, la cuantización y la decodificación especulativa. Este artículo distingue entre técnicas que permiten moverse a lo largo de la frontera y aquellas que la expanden por completo, ofreciendo una guía práctica para optimizar despliegues de LLM como GLM-5.3 o Kimi K3.

La frontera eficiente es muy irregular: en lugar de una línea continua y suave entre resultados, pequeños cambios pueden tener grandes impactos.
  1. kgeist

    Actualmente estoy intentando escribir un motor de inferencia que combine los beneficios de llama.cpp (despliegue en un solo binario, buen soporte para cómputo heterogéneo no-centro de datos, amplio soporte de cuantización) con los beneficios de vLLM/SGlang (cosas como atención paginada adecuada para una mejor utilización de VRAM y alta concurrencia).

    El hardware de centro de datos es caro y escaso, pero llama.cpp es lento/no optimizado para uso concurrente, mientras que vLLM/SGLang fallan fácilmente en configuraciones no comunes (cosas como, si haces paralelismo de pipeline para RTX5090+RTX4090, fallan aleatoriamente con el caché de RAM habilitado o seleccionan kernels incorrectos porque generalmente asumen que cada rango es del mismo tipo de dispositivo; tampoco soportan Q5-Q6).

    Para mí, lo más interesante es optimizar la inferencia para la falta de buen hardware de centro de datos y cómo optimizarla mejor. He estado ejecutando un servidor de IA en la oficina, y hasta ahora he encontrado que estas técnicas son las más importantes para el uso concurrente en hardware barato: paralelismo de pipeline (para adaptarse a PCIe), caché de RAM (para restaurar rápidamente contextos en VRAM), decodificación especulativa (incluyendo n-gramas específicos del dominio, que ya pueden acelerar considerablemente la generación de código sin la sobrecarga de un modelo borrador), buenos kernels altamente optimizados para un dispositivo específico, soporte para Q5-Q6 (casi tan bueno como Q8), contextos FP8 (más contexto para caber), atención paginada (para una mejor utilización de VRAM), caché de prefijos, batching continuo (esto es el estándar en todas partes).

    Hasta ahora, el principal […]

  2. jumploops

    > La decodificación especulativa es el proceso de adivinar qué tokens podría generar un modelo, y luego validar esas suposiciones.

    Como ingeniero informático, siempre es interesante ver optimizaciones aplicadas en diferentes niveles de la pila.

    La ejecución especulativa se volvió bastante popular en los años 90, eventualmente usada en prácticamente todos los diseños x86.

    Luego, a mediados de los 2000, el artículo Speculator[0] llevó ese concepto a los sistemas distribuidos, en los que todavía vemos trabajo[1][2].

    Todo lo viejo es nuevo otra vez (:

    [0]https://www.cs.princeton.edu/courses/archive/fall07/cos518/p...

    [1]https://www.usenix.org/system/files/osdi25-shen-weihai.pdf

    [2] https://www.microsoft.com/en-us/research/publication/distrib...

  3. amelius

    ¿Cómo sabes con certeza que te mantienes en una frontera eficiente cuando cambias un parámetro?

    Creo que esta presentación dice más sobre qué perillas puedes girar y en qué dirección se moverá el resultado (puede ser peor que un competidor) que sobre fronteras.

  4. armcat

    Creo que pronto podemos incluir la estrategia de "profundidad recursiva" que Astra está empleando, que (sospecho) usa cambios recursivos de estado interno en el transformer en lugar de pase completo hacia adelante + muestreo, que ha sido tradicionalmente el caso con el pensamiento/CoT. Un método similar se usó aquí (pero en un contexto diferente: codificar herramientas dentro de los pesos del transformer para una ejecución rápida): https://www.percepta.ai/blog/can-llms-be-computers

  5. copperwire

    La cuantización y la decodificación especulativa desbloquearon ahorros importantes para nuestros modelos más pequeños. Todavía persiguiendo esa relación costo/rendimiento ideal.

Más de este día

2026-09-02