Cuestionario de Ray Serve
Preguntas de opción múltiple
- ¿Cómo se relaciona un Serve Deployment con un Kubernetes Deployment?
- A) Son idénticos
- B) Es una unidad lógica de actor-réplica, no se corresponde uno a uno con Pods
- C) Cada réplica requiere un nodo EC2
- D) Serve no utiliza actores
Mostrar respuesta
Respuesta: B
Un Ray Pod puede alojar varios actores de réplica.
- ¿Cuál es la ubicación predeterminada del proxy en 2.58.0?
- A) Siempre uno en el head
- B) EveryNode en los nodos que alojan réplicas
- C) Cada nodo EC2 incondicionalmente
- D) Siempre Disabled
Mostrar respuesta
Respuesta: B
HeadOnly y Disabled son opciones explícitas. Distinga la documentación de arquitectura desactualizada de la API actual.
- ¿En qué se diferencia el Deployment predeterminado de num_replicas="auto"?
- A) Ambos inician inmediatamente 100 réplicas
- B) Predeterminado fijo en 1; auto aplica mínimo 1/máximo 100/objetivo 2
- C) Predeterminado GPU 1; auto GPU 100
- D) Ninguno admite autoscaling
Mostrar respuesta
Respuesta: B
Un AutoscalingConfig construido directamente establece el máximo predeterminado en 1, así que especifique el límite previsto.
- ¿Cuál es el alcance de max_queued_requests?
- A) Una cola global para todo el cluster
- B) Cada llamador, como un proxy o handle
- C) Capacidad de KV-cache de GPU
- D) Cantidad de RayCluster Pods
Mostrar respuesta
Respuesta: B
El valor predeterminado -1 es ilimitado; exceder un límite configurado puede rechazar solicitudes HTTP o generar un handle BackPressureError.
- ¿Un actor de réplica pendiente siempre crea un nuevo Pod y nodo EC2?
- A) Siempre uno a uno
- B) No; importan la capacidad existente, los límites de grupo, la colocación y la habilitación del autoscaler
- C) Se convierte automáticamente en un modelo de CPU
- D) Serve crea directamente nodos EC2
Mostrar respuesta
Respuesta: B
Inspeccione por separado la colocación de actores, el tamaño del Pod y el aprovisionamiento de nodos.
- ¿Qué se verificó sobre los backends de LLM en 2.58.0?
- A) Solo existe vLLM
- B) Existen los backends vLLM y SGLang; compruebe sus dependencias/configuración por separado
- C) Cada kwarg de motor es idéntico entre los distintos motores
- D) ray[serve] incluye todos los pesos de los modelos LLM
Mostrar respuesta
Respuesta: B
Las dependencias de inferencia y el acceso/descarga de modelos son independientes. Las comprobaciones de CPU no validaron la ejecución de LLM.
- ¿Qué afirmación sobre la actualización de RayService es precisa?
- A) Es obligatoria para cada Deployment de EKS con garantía de ausencia de tiempo de inactividad
- B) Es una ruta de ciclo de vida opcional; valide la estrategia, Gateway, capacidad, preparación y draining
- C) Siempre solo edita la imagen de un Pod existente
- D) Todas las transmisiones largas siempre se preservan
Mostrar respuesta
Respuesta: B
Distinga los cambios de aplicación, las transiciones de cluster y la reconfiguración de actores.
- ¿Qué verificó la prueba local de Echo?
- A) Rendimiento de GPU
- B) Calidad de LLM
- C) HTTP 200 y llamadas a DeploymentHandle
- D) Autoscaling multinodo
Mostrar respuesta
Respuesta: C
Fue una pequeña prueba de CPU de un solo nodo sin un modelo, LLM, GPU ni Deployment en la nube.
Preguntas de respuesta corta
- ¿Por qué distinguir entre el máximo de solicitudes en curso, el objetivo de autoscaling y el límite de cola del llamador?
Mostrar respuesta
Controlan aspectos diferentes: solicitudes asignadas a réplicas, carga objetivo para el escalado y solicitudes en espera por llamador. Una configuración no establece todos los demás límites ni garantías de latencia.
- ¿Por qué los tokens de cluster o ClusterIP no completan la seguridad de la aplicación?
Mostrar respuesta
Verifique por separado TLS, la autenticación/autorización de cada punto de entrada, los permisos de artefactos de modelo, el manejo de solicitudes/registros sensibles y las políticas de recursos/cola/timeout.