Cuestionario vinculado a una guía · Medio Nivel

Prueba de equilibrio de carga y enrutamiento de inferencia de LLM

Comprueba el enrutamiento de réplicas y modelos, la afinidad de caché, la telemetría en vivo, el costo de token variable y el goodput consciente de la latencia para la inferencia de LLM.

Pregunta 1 de 8

¿Por qué la operación por turnos suele ser una mala estrategia de equilibrio de carga para la inferencia de LLM?

Vista previa de cada pregunta8 preguntas

Las respuestas y explicaciones aparecen a medida que realiza el cuestionario.

  1. ¿Por qué la operación por turnos suele ser una mala estrategia de equilibrio de carga para la inferencia de LLM?
    • Las solicitudes varían enormemente en costo y las réplicas contienen cachés KV fijos
    • Es ilegal en la mayoría de los países.
    • El round-robin solo funciona para bases de datos
    • Requiere una GPU para ejecutarse
  2. ¿Qué intenta lograr el enrutamiento de 'afinidad de caché de prefijo'?
    • Envío de cada solicitud a una GPU aleatoria
    • Enrutar una solicitud a la réplica que ya almacenó en caché su prefijo de solicitud
    • Cifrar el mensaje antes de enviarlo
    • Comprimir los pesos del modelo
  3. En el enrutamiento de modelos basado en dificultad, ¿qué sucede normalmente con una consulta sencilla?
    • es rechazado
    • Se envía al modelo más grande disponible.
    • Se envía a un modelo pequeño y más económico.
    • Está en cola durante 24 horas.
  4. ¿Qué señal en vivo es más útil para un balanceador de carga compatible con LLM?
    • La longitud del nombre de host del servidor
    • El color del estante
    • La zona horaria del usuario únicamente
    • Profundidad de la cola y ocupación de caché KV de cada réplica
  5. ¿Qué proporciona una herramienta como LiteLLM en una configuración de múltiples proveedores?
    • Un único proxy que equilibra y conmuta ante fallos entre muchos proveedores de modelos
    • Una nueva arquitectura de transformador
    • Un sistema de refrigeración GPU
    • Un reemplazo para el tokenizador
  6. ¿Por qué una solicitud de salida larga puede pesar más que muchas solicitudes cortas a la hora de equilibrar?
    • Las producciones largas no utilizan recursos
    • Cada token de salida cuesta un pase directo completo, por lo que la carga total del token importa más que el recuento de solicitudes
    • Las solicitudes cortas siempre son más lentas
    • El enrutador no puede ver la longitud de salida en absoluto
  7. A serving system reports goodput rather than raw request count. What does goodput usually emphasize?
    • El número total de parámetros del modelo.
    • Only the number of HTTP connections opened
    • Requests served while meeting the specified latency or service-level targets
    • The fraction of requests that use the largest model
  8. A gateway first chooses a small or large model, then chooses a replica of that model. What are these two decisions?
    • Tokenization followed by decoding
    • Training followed by fine-tuning
    • Prefill followed by prompt construction
    • Model routing followed by replica load balancing