Cuestionario de KServe
Referencia: KServe 0.18.0 / Community Distribution 26.03.1.
Preguntas de opción múltiple
¿Cómo se relaciona KServe con Kubeflow?
- A) Evolucionó de KFServing y puede ejecutarse de forma independiente con sus dependencias
- B) Es un nuevo nombre para Katib
- C) Siempre requiere la distribución completa de Kubeflow
- D) Reemplaza a Kubernetes
Mostrar respuesta
Respuesta: A) Evolucionó de KFServing y puede ejecutarse de forma independiente con sus dependencias
Kubeflow completo y la Models Web Application no son requisitos previos para todas las instalaciones de KServe.
¿Qué versiones revisa este capítulo?
- A) Solo la aplicación web en 0.16.1
- B) KServe y la aplicación web 0.18.0 en Community 26.03.1; el KServe más reciente comprobado el 2026-10-12 es 0.21.0
- C) Todos los componentes deben tener versiones diferentes
- D) La etiqueta de la aplicación web determina todos los CRDs instalados
Mostrar respuesta
Respuesta: B) KServe y la aplicación web 0.18.0 en Community 26.03.1; el KServe más reciente comprobado el 2026-10-12 es 0.21.0
El controlador, los CRDs y la aplicación web son artefactos independientes. Se deben registrar su compatibilidad y revisiones reales.
¿Qué componente de InferenceService es obligatorio?
- A) Explainer
- B) Transformer
- C) Predictor
- D) Los tres
Mostrar respuesta
Respuesta: C) Predictor
Transformer y explainer son opcionales; la compatibilidad de runtime/protocolo y las rutas de explicación reales siguen siendo importantes.
¿Al seleccionar Knative todos los predictors inactivos se escalan automáticamente a cero?
- A) Sí, sin configuración
- B) No; KServe establece minReplicas en 1 de forma predeterminada y el escalado a cero requiere configuraciones compatibles de autoscaler/policy, como minReplicas 0
- C) Sí, y la facturación de EC2 se detiene inmediatamente
- D) No se necesita una instalación de Knative
Mostrar respuesta
Respuesta: B) No; KServe establece minReplicas en 1 de forma predeterminada y el escalado a cero requiere configuraciones compatibles de autoscaler/policy, como minReplicas 0
El escalado desde cero incluye carga de capacidad, imagen y modelo. Tener cero Pods no garantiza la terminación de los nodos.
¿Qué afirmación sobre el modo Standard es correcta?
- A) Garantiza una réplica saludable y activa en todo momento
- B) Usa Deployment/Service; el HPA predeterminado conserva al menos 1, mientras que una ruta KEDA configurada puede admitir cero
- C) Siempre requiere Knative
- D) No admite opciones de autoscaling
Mostrar respuesta
Respuesta: B) Usa Deployment/Service; el HPA predeterminado conserva al menos 1, mientras que una ruta KEDA configurada puede admitir cero
KEDA necesita instalación, métricas/triggers válidos y una ruta de activación. La latencia de inicio por restart/rollout/scale-out permanece en ambos modos.
¿Cuáles son los nombres de modo modernos en 0.18.0?
- A) Serverless y RawDeployment son los únicos nombres válidos
- B) Knative y Standard; los nombres antiguos son alias obsoletos
- C) HPA y GPU
- D) Predictor y Transformer
Mostrar respuesta
Respuesta: B) Knative y Standard; los nombres antiguos son alias obsoletos
Inspeccione la annotation y la configuración reales. El fallback del código es Standard; el chart de recursos OCI inspeccionado usa Knative de forma predeterminada.
¿Qué implementa la ruta verificada de canaryTrafficPercent?
- A) El controlador de KServe actúa como proxy de todas las solicitudes por sí mismo
- B) KServe establece los destinos de tráfico de revisión de Knative; las redes de Knative enrutan las solicitudes
- C) Todo Deployment Standard tiene automáticamente la misma división por revisión
- D) Argo Rollouts es obligatorio
Mostrar respuesta
Respuesta: B) KServe establece los destinos de tráfico de revisión de Knative; las redes de Knative enrutan las solicitudes
La actualización gradual de Standard no es el mismo mecanismo de porcentaje por revisión. La promoción/reversión y los artefactos conservados requieren validación independiente.
¿Solicitar nvidia.com/gpu garantiza la inferencia mediante GPU?
- A) Sí, para todos los modelos
- B) No; los drivers, la imagen/backend y la configuración de modelo/dispositivo también deben coincidir
- C) Instala automáticamente todos los drivers necesarios
- D) Elimina la necesidad de capacidad de nodos
Mostrar respuesta
Respuesta: B) No; los drivers, la imagen/backend y la configuración de modelo/dispositivo también deben coincidir
La asignación de recursos y la ejecución real del modelo son distintas. Karpenter proporciona capacidad apta sujeta a policies, cuotas y disponibilidad.
Preguntas de respuesta corta
- ¿Por qué «siempre activo» frente a «escalado a cero» no es una distinción absoluta entre los dos modos?
Mostrar respuesta
Knative puede conservar réplicas activas mediante configuraciones mínimas, y Standard puede usar KEDA con una señal externa adecuada. Ningún modo garantiza disponibilidad ni latencia; pruebe la preparación, la carga, la capacidad y la recuperación.
- ¿Por qué un URI de artefacto por sí solo es insuficiente y cómo se debe tratar TorchServe?
Mostrar respuesta
El runtime, el formato/disposición del modelo, la versión de la biblioteca, las credenciales, los puertos y el protocolo deben coincidir. TorchServe indica que ya no recibe mantenimiento activo ni se planean correcciones de seguridad, por lo que una entrada antigua del catálogo de runtimes no demuestra que sea un valor predeterminado mantenido.
- ¿Cómo interactúan el autoscaling de Pods y el escalado de EC2?
Mostrar respuesta
Knative/HPA/KEDA u otro escalador configurado determina los Pods deseados. La planificación de Kubernetes y las policies de capacidad de Karpenter afectan el aprovisionamiento/la recuperación de nodos. Otras cargas de trabajo o reglas de interrupción pueden mantener facturados los nodos de EC2 después de que los Pods del modelo lleguen a cero.