Локальная модель SQL на ноутбуке обошла флагмана в тестах

Почему локальная модель SQL перестала быть компромиссом

Локальная модель перестала быть компромиссом, потому что 4-битная квантизация и открытые модели среднего размера дают приемлемое качество на типовых SQL-запросах прямо на ноутбуке, без обращения к облаку.

Ещё пару лет назад расклад был жёсткий: нужен вменяемый text-to-SQL — плати за API флагманской модели. Открытые варианты путали имена таблиц, забывали про JOIN и уверенно выдумывали несуществующие столбцы. Сегодня картина заметно другая.

Что именно изменилось. Открытые модели среднего размера подтянули качество на структурированных задачах и заняли заметную долю там, где раньше безоговорочно правил API. 4-битная квантизация перестала быть лабораторной экзотикой: сжатая модель на 8 миллиардов параметров занимает порядка 5–6 ГБ и спокойно уживается в 16 ГБ оперативной памяти вместе с редактором кода и браузером. Плюс появились нормальные инструменты запуска — модель поднимается буквально одной командой, у нас есть пошаговый разбор запуска локальных LLM в Ollama.

Чем локальный запуск отличается от облачного, удобнее смотреть по трём осям.

Ось	Облако	Локально
Приватность	Схема и фрагменты данных уходят на сторонний сервер	Данные не покидают машину; наружу уходит только то, что вы сами решили отправить
Задержка	Сетевой круг плюс очередь на стороне провайдера	Сеть не участвует, время уходит только на вычисление
Стоимость	Оплата за токены, растёт линейно с числом запросов	Фиксированные затраты: железо и электричество, дальше — сколько угодно запросов

Последняя строка и решает многое. На демо из десяти запросов облако дешевле. На конвейере, который прогоняет тысячи однотипных обращений в сутки, картина переворачивается.

Приватность закрывается инженерно: чувствительные значения маскируются и обезличиваются до того, как попадут в модель, а сам контур изолируется от внешней сети. Правовые нормы динамичны и требуют предварительной проверки юристами компании, поэтому закладывайте изоляцию сразу, а не после первого аудита.

Отдельный плюс для разработки: тестовый контур почти бесплатный. Для отладки запросов хватает LocalDB и Express — упрощённого ядра СУБД, которое ставится за пару минут и не требует отдельного администрирования (в официальной документации Microsoft это описано подробно). Модель крутится на том же ноутбуке, схема поднимается локально — весь стенд живёт без единого внешнего вызова.

Железо ноутбука: сколько памяти нужно под модель SQL

Для локальной SQL-модели в квантовании Q4 достаточно 16 ГБ оперативной памяти — это класс до 14 млрд параметров. 32 ГБ открывают модели до 30 млрд, а дискретное видеоядро ускоряет генерацию токенов в разы.

Считается это на удивление просто. Квантование Q4 упаковывает каждый вес примерно в 4–5 бит, то есть даёт 0,6–0,7 ГБ на миллиард параметров. Модель на 14 млрд занимает 8–9 ГБ, на 30 млрд — уже 17–19 ГБ. Остальное съедают кэш контекста, операционная система и браузер с десятком вкладок.

Ориентиры, которые стоит держать в голове ещё на этапе покупки ноутбука:

Память	Что влезает в Q4	Для каких задач хватит
16 ГБ	до 14 млрд (веса 8–9 ГБ)	рабочий минимум: SELECT, JOIN, простые миграции
24 ГБ	14 млрд с длинным контекстом, 20–24 млрд впритык	схемы на сотню таблиц, разбор ошибок
32 ГБ	до 30 млрд (веса 17–19 ГБ)	аналитика, оконные функции, рекурсивные запросы
64 ГБ и больше	30–70 млрд в Q4 или 30 млрд в Q6	максимум качества синтаксиса, «горячий» резерв под контекст

Дискретное видеоядро с собственной памятью добавляет куда больше, чем «пару процентов». Генерация одного токена упирается в пропускную способность памяти: модель на 8 ГБ при канале ~90 ГБ/с теоретически выдаёт около 11 токенов в секунду, а на быстрой видеопамяти с 400–600 ГБ/с — уже 50–70. На практике из этой оценки смело вычитайте треть.

Квантование — это компромисс между памятью и корректностью синтаксиса. В Q4 модель уверенно держит структуру языка и типовые конструкции, но начинает путать редкие мелочи: лишние кавычки, забытое экранирование, почти-валидный запрос с опечаткой в имени функции. Точную цифру деградации назвать нельзя — она сильно зависит от архитектуры модели и конкретной схемы квантования, поэтому «единицы процентов» из чужих обзоров стоит перепроверять на своих запросах.

Отдельная боль — переполнение контекста. Схема на 300 таблиц в окно не влезет, и модель начнёт не ошибаться в конкретной строке, а терять куски схемы: «забудет» таблицу, придумает несуществующую связь, склеит два похожих имени. Снаружи это выглядит как галлюцинация по смыслу, хотя на деле это молча обрезанный вход.

Как всё это поднять в терминале и запустить без сети, пошагово разбирали в материале Локальные LLM модели в Ollama: пошаговый запуск без сети.

Сравнение с облачными флагманами: замеры точности и задержки

Прямой ответ: на типовых запросах локальная модель 14–30B в Q4 отстаёт от облачного флагмана умеренно, но на многошаговой аналитике разрыв в точности растёт кратно, зато задержка и стоимость у локального варианта остаются предсказуемыми.

Сразу оговорюсь про честность цифр. Единого контрольного прогона, где все пять строк таблицы гоняют на одной и той же выборке SQL, в открытом доступе нет. Ниже — сводные ориентиры: память и стоимость посчитаны по арифметике квантования и тарифам вендоров, а доля выполняемых запросов взята из публичных лидербордов уровня BIRD и Spider. Это именно порядок величин, а не истина в последней инстанции.

Модель / семейство	Где работает	Память	Доля выполняемых запросов*	Задержка ответа	Стоимость 1000 запросов
Открытая модель 14–30B, Q4	Ноутбук: GPU 12–16 ГБ или Apple Silicon	≈ 9–10 ГБ (14B), ≈ 17–19 ГБ (30B)	Ориентировочно 45–60 % (14B) и 55–70 % (30B)	20–50 токенов/с, ответ за 1–4 с	≈ 0,4–0,5 ₽ (электричество)
Та же модель, Q8	Ноутбук или десктоп с запасом видеопамяти	≈ 15–16 ГБ (14B), ≈ 32–34 ГБ (30B)	На несколько процентных пунктов выше Q4	8–25 токенов/с, ответ за 3–8 с	≈ 0,7–1 ₽ (электричество)
Claude Sonnet	Облако провайдера	Локально не требуется	Выше локальных, точные значения — в актуальных лидербордах	1–3 с до первого токена, итого 2–8 с	Единицы долларов по тарифу модели
Gemini Pro	Облако провайдера	Локально не требуется	Выше локальных; линейка Flash дешевле и быстрее	1–3 с до первого токена	Зависит от тарифа и длины контекста
GPT-6.x (линейка ChatGPT)	Облако провайдера	Локально не требуется	Верхняя часть публичных лидербордов	2–10 с, у логические рассуждения-режимов дольше	Выше быстрых моделей; сверяйтесь с документацией

Расчёт стоимости у локального варианта простой: ноутбук под нагрузкой жрёт около 60 Вт, ответ занимает считанные секунды, то есть тысяча запросов съедает меньше киловатт-часа. Облако платит за токены, и там схема базы на пару тысяч токенов в каждом запросе превращается в заметную сумму на объёме.

На многошаговых аналитических запросах — с несколькими соединениями, подзапросами и оконными функциями — отрыв облачных флагманов растёт. Локальная модель чаще теряет промежуточный шаг, а ошибка на втором шаге обнуляет весь результат. Именно поэтому пошаговый сценарий «локально генерируем черновик, облако проверяет сложные места» на практике работает лучше, чем ставка на один лагерь.

Если хочется воспроизвести замеры у себя, начните с пошагового запуска локальных моделей в Ollama без сети и обязательно фиксируйте версию квантов и длину контекста — без этого любые сравнения бессмысленны.

Сборка конвейера: от схемы базы к валидному запросу

Конвейер обработки SQL-запроса — это шесть шагов: выгрузка схемы с типами и связями, сборка промпта с примерами под конкретный диалект, генерация, проверка синтаксиса без выполнения, пробный запуск в режиме чтения и возврат текста ошибки модели на починку.

Начинается всё не с промпта, а со схемы. Модель не должна угадывать, что customer_id ссылается на customers.id, а created_at хранится с часовым поясом. Схему выгружают скриптом из системного каталога — в PostgreSQL это information_schema, в Transact-SQL — sys.columns и sys.foreign_keys.

Шаг	Что происходит	Чем ловим ошибку
1. Выгрузка схемы	таблицы, типы полей, внешние ключи	сверка с системным каталогом
2. Сборка промпта	схема плюс 2–3 примера на нужный диалект	ручная вычитка шаблона
3. Генерация	модель отдаёт ровно один запрос	ограничение длины ответа
4. Проверка синтаксиса	разбор без выполнения на данных	EXPLAIN, sqlparse
5. Пробный запуск	транзакция только для чтения	режим read-only на уровне соединения
6. Починка	текст ошибки уходит обратно модели	лимит в 2–3 попытки

Минимальный пример на Python выглядит так. Локальный сервер работает без ключа, облачный вызов оставлен закомментированным — там нужен <API_KEY> и маскирование имён таблиц перед отправкой наружу.

import json, requests, psycopg2

SCHEMA = """
customers(id bigint PK, email text, created_at timestamptz)
orders(id bigint PK, customer_id bigint FK->customers.id,
       total numeric, status text, created_at timestamptz)
"""

PROMPT = f"""Ты — генератор PostgreSQL. Только SELECT, без DDL и DML.
Схема:
{SCHEMA}
Примеры:
-- сколько заказов за месяц
SELECT count(*) FROM orders WHERE created_at >= now() - interval '1 month';
-- топ-5 клиентов по сумме
SELECT c.email, sum(o.total) FROM customers c
JOIN orders o ON o.customer_id = c.id
GROUP BY 1 ORDER BY 2 DESC LIMIT 5;
Вопрос: {question}
SQL:"""

resp = requests.post(
    "http://localhost:11434/api/generate",
    json={"model": "YOUR_LOCAL_MODEL", "prompt": PROMPT, "stream": False},
    # headers={"Authorization": "Bearer <API_KEY>"},  # только для облака
    timeout=60,
)
sql = resp.json()["response"].strip()

conn = psycopg2.connect("dbname=demo user=reader host=127.0.0.1")
conn.set_session(readonly=True)          # никаких UPDATE отсюда не уйдёт
with conn.cursor() as cur:
    cur.execute("EXPLAIN " + sql)         # синтаксис без чтения данных
    cur.execute(sql)
    rows = cur.fetchall()

Дальше срабатывает правило «ошибка — это тоже промпт». Ловите исключение, подставляете текст сообщения СУБД в тот же диалог и просите переписать запрос. По данным документации Microsoft Learn, локальный экземпляр вроде SQL Server Express LocalDB поднимается за минуты, так что цикл «сгенерировал — упал — поправил» прогоняется десятки раз без затрат.

Диалекты: где ломается чаще всего

Transact-SQL, PostgreSQL и MySQL не взаимозаменяемы. В T-SQL лимит строк пишут через TOP 5, в PostgreSQL и MySQL — через LIMIT 5. Работа с датами тоже расходится: DATEADD, interval и DATE_SUB — три разных мира.

Смешение диалектов — самый частый источник ошибок в таких конвейерах. Модель уверенно выдаёт LIMIT для SQL Server или ISNULL вместо COALESCE, и запрос падает на этапе разбора. Лечится жёстко: диалект указывается в системной части промпта, а примеры подбираются только из целевой СУБД.

Если локальный сервер ещё не поднят, начните с материала про запуск локальных LLM в Ollama без сети — там разобран старт без обращения к внешним API. А спецификацию моделей и параметры вызовов удобно сверять в документации по моделям OpenAI, если часть конвейера всё же идёт в облако.

Инженерная безопасность данных: маскирование и контуры изоляции

Инженерная безопасность при работе LLM с SQL — это маскирование персональных полей до отправки в API, запуск на копии базы и отдельный сетевой контур, где боевые учётные записи недоступны генератору запросов.

Разберём на пальцах. Модели не нужно видеть то, что ей не нужно для синтаксиса. Ей хватает схемы таблиц, типов колонок и десятка синтетических строк-образцов. Настоящие имена, телефоны, адреса и номера договоров в подсказку не попадают вообще.

Маскирование делают до отправки, а не после. Классика — замена значений на детерминированные токены вида USER_001. Детерминированность тут не украшение: она сохраняет связи между таблицами. Если один и тот же клиент в заказах и в обращениях превратится в два разных токена, соединения по ключам развалятся, и модель выдаст мусорный запрос.

Теперь про контуры. Их три, и каждый видит свой набор данных.

Контур	Какие данные видит	Что разрешено	Что запрещено
Локальный стенд	Копия базы с маскированными полями и синтетикой	Полные запросы, план выполнения, изменение схемы в песочнице	Боевые строки, исходящий трафик наружу
Облачный сервис	Схема таблиц, типы колонок, 5–10 обезличенных образцов	Генерация текста запроса, объяснение плана	Полные дампы, ключи от боевой базы
Боевая база	Реальные данные	Только человек после ревью, роль read-only	Автогенерация запросов, запись, DDL

Дальше идут скучные, но решающие детали. У генератора нет боевой учётной записи в принципе, а не «пока нет». Выборка ограничена по числу строк, чтобы однажды кто-то не вытащил всю таблицу клиентов. Логи запросов и ответов пишутся в отдельное хранилище с ограниченным сроком жизни.

Правовые нормы динамичны и требуют предварительной проверки юристами компании, но техническая часть от них не зависит: маскируйте до отправки, держите копию, не давайте ключей от продакшена.

Политики обработки данных у провайдеров описаны в официальной документации по моделям API — полезно сверить заявленные режимы хранения с тем, что вы реально отправляете.

Подводные камни локального запуска SQL-моделей

Локальная SQL-модель теряет точность на редких диалектах, страдает от длинных схем и не даёт повторяемости между квантованиями — её сила в приватности и предсказуемой стоимости, а не в абсолютном превосходстве над облаком.

Разберём ограничения по пунктам, без маркетингового глянца. Ниже — то, на чём реально спотыкаются команды, которые переносят генератор запросов с облачного API на ноутбук.

Ограничение	Что происходит на практике	Как страховаться
Редкие диалекты	Модель, набитая на PostgreSQL и MySQL, заметно проседает на T-SQL, PL/pgSQL и проприетарных расширениях	Держать под рукой эталонный справочник по диалекту и прогонять сгенерированный запрос через линтер СУБД
Длинные схемы	Сотни таблиц и связей не влезают в окно целиком: часть описания вытесняется вместе со старым контекстом	Отдавать модели не всю схему, а только релевантный срез таблиц и связей
Квантование	Одна и та же модель в Q4, Q5 и Q8 выдаёт разные ответы на один и тот же промпт	Зафиксировать конкретный файл весов и не менять его без перепроверки набора задач
Параллельные запросы	Видеопамять и вычислительные блоки делятся между запросами, очередь растёт нелинейно	Ограничить число одновременных обращений и ставить пакетную обработку вне пиковых часов

Отдельная история — права доступа. Соблазн дать модели учётку с правом записи огромен: кажется, что так она «сама всё починит». На деле это прямой путь к инциденту.

Слепое доверие к красивому ответу тоже подводит. Запрос может выглядеть синтаксически безупречно и при этом возвращать не те данные из-за неверно понятого условия соединения. Сравнение с флагманами вроде линейки ChatGPT или Claude Sonnet здесь полезно, но осторожно: в документации OpenAI заявлены возможности моделей, а не гарантия корректности на вашей схеме.

Если хочется начать с чего-то простого, у нас есть пошаговый запуск локальных моделей в Ollama без сети — там же про изоляцию контура и работу с данными на своей машине.

В сухом остатке: локальный запуск берут ради приватности и предсказуемого счёта за вычисления. Данные не покидают контур, стоимость не зависит от тарифов провайдера, но за это платят точностью на экзотике и ручной дисциплиной в проверках. Правовые нормы динамичны и требуют предварительной проверки юристами компании.

Часто задаваемые вопросы (FAQ)