179 questions
No questions match those filters.
What's different about containerizing and deploying an...
This is one of the questions in the full AI/ML interview bank. Pro unlocks all 1789 questions; Premium includes the same bank plus the highest daily Practice limit.
See plansThe container mechanics look familiar — multi-stage Docker builds, a Kubernetes Deployment, resource requests and limits — but several defaults that work fine for a stateless web service actively break an AI workload. Model weights are the first trap: copying gigabytes of weights into a Docker image makes builds slow and images bloated, so the better pattern is a lean image that pulls weights from S3 or a model registry at container startup, trading a slower first-request warm-up for a dramatically smaller, faster-to-ship image.
GPU workloads need explicit resource requests against an nvidia-aware node pool, and memory limits deserve real attention — LLM inference can spike memory usage unpredictably, and an underspecified limit means Kubernetes OOM-kills the pod mid-request rather than gracefully degrading. Startup time is the detail most likely to bite a first deployment: an LLM app that needs to load model weights or open persistent connections to an inference provider can take 30-60 seconds before it’s genuinely ready, and a readiness probe with a short or default initial delay routes live traffic into that window, producing a burst of failed requests every time the deployment rolls. Secrets (API keys) belong in Kubernetes Secrets and prompt templates in ConfigMaps — never baked into the image — so either can be rotated or updated without a rebuild.