7.4 AI/ML Pipelines & Applications: Cortex AI, ML Functions, Snowpark Container Services, Streamlit & Native Apps

Why AI/ML Belongs in an Architecture Exam

Objective 2.3 of the blueprint includes "Outline basic AI/ML pipelines and applications" and names Snowpark Container Services, Snowflake ML functions, Cortex LLM functions, Streamlit, and the Snowflake Native App Framework. The exam does not expect data-science depth; it expects you to pick the right building block for a scenario and to understand its security, cost, and operational implications.

Snowflake Cortex AI Functions

Cortex AI Functions run industry-leading LLMs (from providers such as OpenAI, Anthropic, Meta, Mistral AI, and DeepSeek) inside the Snowflake service perimeter and are called like any SQL function (they are also available in Python):

-- Classify and score support tickets without moving data out of Snowflake
SELECT ticket_id,
       AI_SENTIMENT(body)                                     AS sentiment,
       AI_CLASSIFY(body, ['billing', 'outage', 'feature request']) AS category,
       AI_EXTRACT(body, {'product': 'Which product is mentioned?'}) AS extracted
FROM support.tickets
WHERE AI_FILTER(PROMPT('Is this ticket about a data outage? {0}', body));

Architect considerations:

• Access control: the role needs the account-level USE AI FUNCTIONS privilege and one of the CORTEX_USER or AI_FUNCTIONS_USER database roles.
• Data privacy: models run inside Snowflake's perimeter, and Snowflake does not use customer data to train models offered to other customers.
• Availability and cost: functions and models are available in select regions (cross-region inference can be enabled with CORTEX_ENABLED_CROSS_REGION); usage is billed in credits and appears in usage views under AI service types. Some functions are preview features — check status before production use.
• Related services: Cortex Search (hybrid search for RAG), Cortex Analyst (natural-language questions over semantic models), and Cortex Agents build on the same governed foundation.

ML Functions

ML Functions give SQL users out-of-the-box machine learning:

• Forecasting and Anomaly Detection for time-series metrics.
• Classification to sort rows into classes.
• Top Insights to find dimensions that drive unexpected changes in a metric.

CREATE SNOWFLAKE.ML.FORECAST daily_sales_model(
  INPUT_DATA => SYSTEM$REFERENCE('VIEW', 'analytics.daily_sales_v'),
  TIMESTAMP_COLNAME => 'sale_date',
  TARGET_COLNAME => 'revenue');

CALL daily_sales_model!FORECAST(FORECASTING_PERIODS => 30);

Models are schema-level objects; training and prediction use warehouse compute, and model artifacts incur storage (delete obsolete models). AUTOCOMMIT must be enabled in the session.

Snowflake ML and Snowpark for Custom Models

For custom models, data scientists use Snowpark (Python DataFrames executed in Snowflake) and Snowflake ML — modeling APIs based on popular frameworks, a Feature Store, and a Model Registry for versioning and deploying models. Training can run on Snowpark-optimized warehouses (high memory) or on SPCS compute pools (including GPUs); registered models can serve predictions from SQL or from a service.

Snowpark Container Services (SPCS)

SPCS is a fully managed container platform inside Snowflake (generally available in AWS, Azure, and Google Cloud commercial regions, with some exceptions). You package an application and its dependencies as an OCI image, push it to an image repository in Snowflake, and run it on a compute pool.

CREATE COMPUTE POOL ml_gpu_pool
  MIN_NODES = 1 MAX_NODES = 2
  INSTANCE_FAMILY = GPU_NV_S;

CREATE IMAGE REPOSITORY ml.images.repo;

CREATE SERVICE ml.serving.fraud_model_svc
  IN COMPUTE POOL ml_gpu_pool
  FROM @ml.specs.stage SPECIFICATION_FILE = 'fraud_svc.yaml'
  EXTERNAL_ACCESS_INTEGRATIONS = (model_hub_access);

What it is for:

• Custom runtimes and libraries that UDFs cannot run; GPU workloads such as model training and LLM or model serving.
• Long-running services (APIs, web apps) and job services (batch jobs run with EXECUTE JOB SERVICE).

How it integrates with Snowflake governance:

• Services can run SQL in a virtual warehouse and read staged files.
• Network ingress is governed by network policies; egress requires external access integrations.
• RBAC controls which roles can use a service and how services talk to each other.
• Logs, metrics, and events go to event tables.
• Reader accounts cannot create services, and cross-cloud auto-fulfillment of Native Apps with SPCS is supported only on AWS and Azure.

Streamlit in Snowflake

Streamlit in Snowflake lets developers build and share Python web apps on Snowflake data without moving the data or the code elsewhere:

• The app's source code and environment are stored in a Snowflake object governed by RBAC.
• Snowflake manages compute; apps run on a warehouse runtime or a container runtime.
• Apps work with Snowpark, UDFs, stored procedures, and Native Apps, and can be created in Snowsight, with SQL, or with the Snowflake CLI.

Snowflake Native App Framework

The Native App Framework lets a provider share data and application logic with consumers:

• An application package holds the data content, logic (stored procedures, functions, Streamlit UI, optionally containers), a manifest file, and a setup script that runs when a consumer installs or upgrades the app.
• Providers release versions and patches, test from a single account, and collect logs and events for troubleshooting.
• Apps are distributed through listings — free or paid, on the Snowflake Marketplace or privately to specific accounts — and can use Cross-Cloud Auto-Fulfillment to reach other regions.
• Consumers install the app into their own account, so their data never has to be sent to the provider.

An End-to-End AI/ML Pipeline in Snowflake

Ingest (Snowpipe / Streaming) → Features (dynamic tables, Feature Store)
   → Train (Snowpark ML on Snowpark-optimized WH or SPCS GPU pool)
   → Register (Model Registry) → Score (SQL/Python inference, Cortex AI Functions)
   → Serve UI (Streamlit) → Distribute (Native App via listing)

Every step stays inside Snowflake's security perimeter, so the same RBAC, masking, row access policies, and auditing (Chapters 2–3) govern ML data as govern analytics.