Тест за KServe и моделиране на Kubernetes

Отговорите и обясненията се появяват, докато отговаряте на теста.

1. Какво беше предишното име на KServe, преди да стане самостоятелен проект?
   • KFServing
   • KubeML
   • ModelMesh
   • Кнативни модели
2. Кой е основният персонализиран ресурс на Kubernetes, който дефинирате за внедряване на модел с KServe?
   • ModelDeployment
   • InferenceService
   • PredictPod
   • ServingChart
3. Коя възможност позволява на неактивните KServe модели да консумират нула изчисления, докато пристигне заявка?
   • Канарче разгръщане
   • Шардинг
   • Мащаб до нула
   • Пакетно заключение
4. Кой основен проект осигурява управлявано от заявка автоматично мащабиране на KServe?
   • Прометей
   • Шлем
   • Арго
   • Кнатив
5. Как KServe обикновено получава артефактите на модела в обслужваща група при стартиране?
   • Чрез инициализатор за съхранение, който изтегля от хранилището на обект
   • Чрез изпичане на модели само в изображението на контейнера
   • Чрез изпращане на файла с модела по имейл
   • Чрез ръчно kubectl копие
6. Какъв стандарт използва KServe, за да могат клиентите да извикват различни модели по един и същи начин?
   • GraphQL федерация
   • Протоколът за отворен извод
   • САПУН
   • JDBC
7. In KServe’s InferenceService pipeline, which component can apply pre- or post-processing around the predictor?
   • The storage initializer
   • The Knative autoscaler
   • Трансформаторът
   • The Kubernetes scheduler
8. What is a typical trade-off of scaling a model deployment down to zero replicas?
   • The model becomes permanently unavailable
   • Every request avoids model loading
   • The Kubernetes API is replaced
   • Idle compute is reduced, but the next request may incur a cold-start delay