Para la inferencia de LLM cerca del usuario, rara vez hay servidores "pesados" listos. Normalmente es una mezcla de dispositivos Edge, puertas de enlace y nodos fog con diferentes cantidades de memoria y potencia de cómputo. Desplegar un modelo como si siempre cupiera en un solo dispositivo es ignorar la realidad: o el modelo no cabe, o funciona con latencias inaceptables, o deja recursos costosos inactivos. El framework E2LLM ofrece un camino más pragmático para esto.
Por qué el escenario clásico no es adecuado
Los enfoques tradicionales para servir LLM a menudo asumen que todo el modelo vive en una sola máquina. En la nube esto suele funcionar, pero en entornos Edge/Fog los nodos son más débiles y heterogéneos. Algunos dispositivos pueden tener suficiente memoria para los pesos, pero no soportar el cómputo; otros, al contrario, son rápidos pero con capacidad limitada. Si se intenta simplemente "repartir" el modelo entre todos los dispositivos disponibles, comienzan los problemas con la coordinación, la comunicación y la utilización.
Además, en la práctica se necesitan tres cosas a la vez:
- latencia baja predecible,
- uso eficiente de los recursos,
- costo razonable de despliegue.
Estas entran en conflicto entre sí, por lo que se necesita un compromiso, no una optimización unilateral. E2LLM se construye en torno a este compromiso.
Réplicas y roles: cómo E2LLM supera las limitaciones
La idea clave de E2LLM no es dividir un solo modelo entre todos los nodos, sino agrupar dispositivos en réplicas. Dentro de cada réplica se almacena una copia completa del modelo, y luego se distribuye entre los miembros del grupo mediante paralelismo de modelos. Suena como un desperdicio de memoria, pero en la práctica esta duplicación aumenta la tolerancia a fallos y permite atender múltiples solicitudes en paralelo.
Luego entra en juego el conocimiento sobre el funcionamiento de la inferencia de LLM. Tiene dos fases con diferentes perfiles de carga: prefill, cuando el modelo procesa activamente los tokens de entrada y construye el caché de atención, y decode, cuando genera los tokens de salida. Estas fases requieren recursos diferentes: prefill es sensible a la potencia de cómputo máxima, decode lo es al ancho de banda de memoria y a la latencia de transferencia de datos.
En lugar de obligar a cada grupo a hacer ambas cosas, E2LLM asigna roles especializados a las réplicas. Algunas se convierten en réplicas de prefill y procesan más rápido las solicitudes entrantes; otras, en réplicas de decoder, se encargan de la generación fluida. Esta separación permite no gastar recursos en la fase "incómoda" para un hardware específico.
Cómo se forman los grupos de dispositivos
No se puede simplemente tomar los primeros dispositivos que aparezcan y llamarlos réplica. E2LLM primero decide qué nodos vale la pena agrupar. Para ello se utiliza un algoritmo genético: prueba variantes de clústeres y las mejora gradualmente, orientándose al rendimiento final del sistema.
Una vez definido el clúster, dentro de él hay que entender cómo dividir el modelo entre los participantes. Aquí ya funciona la programación dinámica: busca una estrategia de particionado que minimice los "cuellos de botella" en la transferencia de datos entre dispositivos. En otras palabras, el nivel superior se encarga de seleccionar la composición de las réplicas, y el inferior, del corte óptimo del modelo para la composición de hardware específica.
Qué aporta en la práctica
Los autores probaron el enfoque comparándolo con la solución base Splitwise, que también separa prefill y decode, pero trabaja de forma menos flexible con entornos heterogéneos. Los experimentos mostraron que E2LLM se adapta bien a los cambios en la carga de trabajo. Esto es especialmente notable cuando las longitudes de los tokens de entrada y salida difieren mucho: por ejemplo, llegan solicitudes cortas, pero se requieren respuestas largas, y luego la carga cambia drásticamente.
Con alta carga, el nuevo enfoque reduce el tiempo de espera promedio en más del 50% en comparación con Splitwise. Esto significa que los usuarios esperan menos en la cola para la generación, y los propios dispositivos Edge/Fog trabajan de manera más significativa, en lugar de intentar atender ambas fases de la inferencia por igual.
Conclusión
E2LLM demuestra que para ejecutar LLM de manera eficiente en el borde no solo importa la potencia de un dispositivo individual, sino también cómo se agrupan y distribuyen los dispositivos por roles. La duplicación del modelo completo a nivel de réplicas, combinada con la separación de prefill y decode, es un trade-off consciente: en algún punto hay que sacrificar memoria, pero a cambio el sistema obtiene un rendimiento estable y menores latencias.
La conclusión principal para escenarios aplicados: en un entorno heterogéneo no hay que intentar meter todo el modelo en un solo nodo ni distribuirlo uniformemente entre todos. Hay que formar grupos especializados con el hardware disponible y decidir dentro de ellos cómo repartir el cómputo. Así es como la inferencia de LLM se vuelve verdaderamente práctica fuera de los grandes clústeres en la nube.
