Snowflake launches Arctic, an open model for enterprise SQL

Snowflake released Arctic on April 24, 2024, an open language model aimed at SQL generation, coding and instruction following. The attention-grabbing figure, 480 billion parameters, needs a second number: only about 17 billion participate in computing each token. Arctic uses a mixture of experts to reduce inference work, but it remains an enormous model. Understanding that distinction makes it possible to read any launch that promises the capability of a giant at the cost of a small model.

Snowflake's launch announcement presented Arctic as an enterprise model and released its weights under the Apache 2.0 licence. The company published base and instruction-tuned variants, code and research materials. The attraction for an organisation is clear: it can download the artefacts, run them inside its own infrastructure and adapt them instead of relying exclusively on a closed API.

480 billion total is not 17 billion in memory

A dense model uses all its main blocks to process each token. A mixture of experts, or MoE, contains several specialised networks, and a router decides which ones participate. Arctic combines a 10-billion-parameter dense transformer with 128 experts of 3.66 billion and a gate that selects two. The official Snowflake Arctic repository gives the result: 480 billion total parameters and 17 billion active parameters.

Active describes computation per token, not download size or the memory required to retain the model. To choose two experts, the system needs access to the weights and must route each token to them. The architecture can reduce operations compared with activating all 480 billion, but it still stores and moves a large parameter collection. It also introduces communication costs across accelerators and possible load imbalance when too many tokens select similar experts.

The original instruction-model card grounds the scale better than the slogan. Its inference example recommends an instance with eight H100 GPUs and FP8 quantisation. That recommendation does not define the only possible deployment, but it prevents active parameters from being mistaken for a model that comfortably fits on a laptop. Compute, memory, bandwidth, latency and cost per token are separate axes.

Why SQL is an attractive and deceptive test

SQL looks like an ideal use case for a language model. The input can be an ordinary request, such as net sales by region during the quarter, and the output is structured text that a database understands. A query can also be executed and its syntax validated. Snowflake grouped SQL, coding and instruction following into its own enterprise intelligence measure.

Its launch technical report constructed that measure by averaging HumanEval+ and MBPP+ for coding, Spider for SQL and IFEval for instructions. According to the results published by the company, Arctic competed with open models trained with more compute on this aggregate. The comparison is useful evidence about the selected tests, not a general certification that the model understands an enterprise.

The jump from Spider to a corporate database is semantic. A query can be syntactically perfect and answer the wrong question. Sales may mean invoiced, collected or net of returns. Active customer may depend on a time window and rules that vary by department. Tables contain historical names, duplicates, time zones, missing values and relationships not present in the user's request.

The evaluation unit should therefore be the complete business question, not SQL text alone: supplied schema, metric definition, generated query, returned rows and explanation. A model that gets the syntax right but mixes order date with payment date can produce an answer that is convincing and materially false.

A vendor benchmark needs coordinates

Interpreting a chart requires identifying who defined the aggregate, which model versions were compared, which prompt templates were used and how many attempts were allowed. Averaging several tests creates a manageable summary, but it also decides how much each skill weighs. A coding advantage can offset a SQL weakness inside the average even when the buyer needs only SQL.

The sound practice is to disaggregate. First inspect the relevant benchmark and its metric. Then consider contamination: test examples may have appeared in training data. Finally, build a private set that preserves real difficulties without exposing sensitive information. It should include easy queries, deliberate ambiguity, impossible requests, schema changes and cases where the correct response is to ask for clarification.

Execution should be measured, not merely textual similarity. Two different queries can return the same result; two nearly identical ones can diverge because of one filter. Evaluation can compare results on a controlled copy, inspect the query plan and penalise dangerous operations. Before any test, the model's account should be read-only and limited to authorised views.

Apache 2.0 grants rights, not fitness

Snowflake released Arctic's weights and code under Apache 2.0. The licence text grants broad rights to use, reproduce, modify and distribute, includes a contributor patent grant under its conditions, and requires preservation of notices in redistribution. It also says that the work is supplied without warranties and that users are responsible for determining its appropriateness.

This separates four questions often compressed into the word open. Can the weights be downloaded? Does the licence permit the intended use? Is there enough code and information to run and modify the system? Is the required infrastructure within the team's reach? Arctic answers the first three favourably for the released artefacts, but the fourth depends on resources. A permissive licence does not pay for eight accelerators or turn a complex installation into a maintained service.

A software licence also does not automatically settle rights in prompts, outputs or corporate data. The team must review what information it gives the model, where that information is logged and which obligations apply. Openness enables inspection and self-hosting; it does not replace security, privacy, evaluation or support.

A data assistant needs less power than it appears

A natural-language-to-SQL system should not receive an administrator account. The safer pattern is read-only access to minimal views, blocking write statements, imposing row and time limits, and logging the question, available schema, query and result. Actions with consequences should require human confirmation. The model proposes; a deterministic layer enforces permissions.

Accuracy improves when the system receives a semantic model: approved metric definitions, table relationships, synonyms and reviewed examples. If a column is missing or a request has two plausible readings, it should be able to abstain and ask. That behaviour is more valuable in production than always completing a query.

To compare Arctic with another option, a team can build a table with five measures: execution accuracy, reviewed semantic accuracy, correct clarification rate, latency and total cost. It then adds hosting resources, licence permissions, auditability and maintenance. Parameter count describes only one part of the system.

The transferable skill is to read a MoE model through two inventories and evaluate SQL end to end. Total parameters anticipate storage and memory; active parameters approximate part of the compute per token. A public benchmark guides, while private schemas and definitions decide. Arctic made a large enterprise-oriented model more accessible, but its usefulness is not proven by counting experts. It is proven by obtaining the right figure with permission, traceability and a cost the organisation can sustain.