SnowPro Specialty: Gen AI Question 197
Single answerUsing Snowpark Container ServicesA company wants to deploy a custom LLM inference service inside Snowflake so that sensitive prompts and responses never leave the Snowflake environment. The model requires GPU acceleration, and the data science team wants to expose the model as a low-latency API that can be called by internal applications. They also want Snowflake-managed scaling and isolation rather than managing Kubernetes directly. Which approach best meets these requirements?
- A
Package the model in a container image, deploy it as a service on Snowpark Container Services using a compute pool with GPU instances, and expose the service through a Snowflake endpoint for internal access.
- B
Create a Python UDF that loads the model weights from an internal stage and relies on a standard virtual warehouse to provide GPU acceleration automatically.
- C
Deploy the model to an external Kubernetes cluster and call it from Snowflake through an external function, because Snowflake does not support running containerized inference workloads internally.
- D
Use a Streamlit in Snowflake app as the inference backend, because Streamlit apps can directly provide GPU-backed model serving endpoints for production APIs.
Show answer and explanation
Correct answer: A
Explanation
The best answer is to use Snowpark Container Services with a GPU-enabled compute pool and deploy the model as a service from a container image. This is the Snowflake-native pattern for hosting custom containerized AI/ML inference workloads while keeping data inside Snowflake boundaries. It also aligns with the requirement for Snowflake-managed scaling and isolation. By contrast, Python UDFs are not a substitute for a long-running containerized inference service, external Kubernetes violates the requirement to avoid external infrastructure and data egress, and Streamlit in Snowflake is for app front ends rather than model-serving back ends. Refer to Snowflake documentation for Snowpark Container Services concepts such as compute pools, services, and support for running containerized applications, including AI/ML inference workloads.
- A. Correct.
Correct. Snowpark Container Services is designed for running containerized workloads inside Snowflake, including inference services for AI/ML use cases. A service can be deployed from a container image onto a compute pool, and GPU-capable compute pools are the right choice when the model requires GPU acceleration. This approach keeps data and inference inside Snowflake’s environment and provides Snowflake-managed infrastructure rather than requiring the team to manage Kubernetes directly.
- B. Incorrect.
Incorrect. Python UDFs are useful for in-database logic, but they are not the right mechanism for hosting a custom low-latency GPU-backed inference API. Standard virtual warehouses do not automatically provide GPU acceleration for UDF execution, and UDFs are not the same as a persistent model-serving endpoint managed as a containerized service.
- C. Incorrect.
Incorrect. External Kubernetes plus external functions could integrate with Snowflake, but it fails the stated requirement to keep prompts and responses inside the Snowflake environment and avoid managing external infrastructure. The misconception is assuming Snowflake cannot host containerized inference internally; Snowpark Container Services exists specifically for such workloads.
- D. Incorrect.
Incorrect. Streamlit in Snowflake is intended for interactive applications and dashboards, not as a production-grade GPU-backed inference serving backend. It is not the appropriate mechanism for hosting a custom containerized model inference API.