bonsai-1.7b-text2sql

A 1.7B text-to-SQL model fine-tuned from Bonsai-1.7B for SQLite and DuckDB dialects.

Bonsai-1.7B fine-tuned for text-to-SQL on Spider (Yale) + MotherDuck’s DuckDB corpus. Give it a database schema in the system message and it returns a single SQL query. 28.8% exact-match vs 3.4% for the base model.

Model details

Variants

About the 1-bit (:q1_0) variant

Bonsai’s 1-bit format is GGUF Q1_0 (g128) — one sign bit per weight plus a shared FP16 scale per 128 weights (1.125 bpw). Two important facts:

• Post-training quantization of the FP16 fine-tune to Q1_0 does not work. The 1-bit format keeps only each weight’s sign, and the LoRA deltas are too small to flip signs, so a naive llama-quantize ... Q1_0 reverts the model to base behaviour (verified).
• Applying the LoRA on top of the official 1-bit base does work. The :q1_0 tag is built with Ollama’s ADAPTER directive: FROM Bonsai-1.7B-Q1_0.gguf + ADAPTER bonsai-text2sql-lora.gguf. The fine-tune is preserved and inference runs on 1-bit weights.

Producing a single merged 1-bit file would require 1-bit-aware training (QAT) from the FP16 -unpacked weights, which Prism ML has not released tooling for.

Training data

Combined: 30,403 unique examples → 28,448 train / 1,499 validation. Trained for 2 epochs (3,556 steps) on a single RTX 5060 Ti 16 GB in 6 h 22 m.

Evaluation

Greedy decoding, exact string match after normalisation, on the 1,519-example held-out split:

The 1-bit variant retains ~92% of the F16 fine-tune’s accuracy at ~10× smaller size, and is ~7.8× better than the base model.

Exact-match is strict; many “misses” are semantically correct (e.g. START WITH 1 vs START 1, union_by_name vs UNION ALL), so execution accuracy is higher.

Usage

The database DDL goes in the system message; the question goes in the user message.

CLI

ollama run oamazonasgabriel/bonsai-1.7b-text2sql:f16

API

curl http://localhost:11434/api/chat -d '{
  "model": "oamazonasgabriel/bonsai-1.7b-text2sql:f16",
  "stream": false,
  "options": {"temperature": 0},
  "messages": [
    {"role": "system", "content": "You are an expert SQLite data analyst. Given a database schema, write a single valid SQLite query that answers the user question.\n\n### Database schema\nCREATE TABLE \"Payments\" (\"Payment_Method_Code\" TEXT, \"Amount\" REAL);"},
    {"role": "user", "content": "What is the payment method that were used the least often?"}
  ]
}'

Example output:

SELECT Payment_Method_Code FROM Payments GROUP BY Payment_Method_Code ORDER BY COUNT(*) ASC LIMIT 1

Prompt format

<|im_start|>system
You are an expert {dialect} data analyst. Given a database schema, write a single valid {dialect} query that answers the user's question.
Rules:
- Use only tables and columns that appear in the schema.
- Match identifiers exactly as written in the schema.
- Return ONLY the SQL query, with no markdown fences and no explanation.

### Database schema
{schema}<|im_end|>
<|im_start|>user
{question}<|im_end|>
<|im_start|>assistant
{sql}<|im_end|>

Limitations

• Trained on Spider (SQLite) and MotherDuck (DuckDB); other dialects (PostgreSQL, BigQuery, Snowflake) are out of distribution.
• 1.7B parameters — complex multi-join / nested queries can still fail.
• Schema must be supplied by the caller; the model has no database access.
• Training data is CC BY-SA 4.0, so treat derived weights as share-alike.

Attribution

• Yu et al., Spider: A Large-Scale Human-Labeled Dataset for Complex and Cross-Domain Semantic Parsing and Text-to-SQL Task, EMNLP 2018.
• MotherDuck, duckdb-text2sql-25k.
• Prism ML, Bonsai-1.7B.