Мы измерили 28 моделей на одних и тех же задачах к базе данных. 27 из них работают полностью локально

Я работаю над LibreDB Studio, это SQL-клиент с лицензией MIT. Расскажу про одно измерение, которое мы сделали, и про то, что из него вышло.

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

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

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

Засчитывали только полное прохождение всех шести. Причём критерий был не «модель ответила правдоподобно», а «модель реально вызвала инструмент, прочитала результат и написала отчёт, каждое утверждение которого можно проследить до конкретного запроса». Модели, которые этого не смогли, в список не попали, и мы написали, на каком шаге каждая из них застряла.

Результат: 28 моделей прошли все шесть задач, и 27 из них работают полностью локально через Ollama. Только одна ходит в облачный API.

Неожиданным оказался нижний край. qwen2.5:7b занимает 4,7 ГБ, медиана полного прогона составила 6 секунд, а самый долгий из тридцати прогонов уложился в 21 секунду. Это модель, которая помещается в ноутбук. Самая маленькая из прошедших это qwen3:4b, 2,5 ГБ.

А модели на 27 ГБ быстрее не оказались, они оказались просто больше. Выводы у самой быстрой и у самой медленной совпали, при разнице во времени почти в двадцать раз.

Теперь про то, чем мы занимаемся, раз уж это моя работа и скрывать тут нечего.

LibreDB Studio ставится не на ноутбук, а на сервер рядом с базой, и открывается в браузере: docker run -d -p 3000:3000 ghcr.io/libredb/libredb-studio:latest

Практический смысл в том, что базе больше не нужен порт наружу, потому что то, что к ней подключается, уже находится внутри той же сети. У нас в команде три человека, и это сняло заметную часть возни. Шестнадцать драйверов дают доступ к 42 базам: PostgreSQL, MySQL, SQLite, libSQL, DuckDB, Oracle, SQL Server, MongoDB, Redis, Couchbase, ClickHouse, Apache Druid, Elasticsearch, OpenSearch, Apache Trino и Cassandra.

Про ИИ-часть есть два правила, которые мне кажутся важнее самих моделей.

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

Второе: режим только для чтения держится не на разборе SQL. Разбирать строку запроса это не тот уровень, и именно там живут ошибки. У нас запрещает сама база: на PostgreSQL открывается read-only транзакция, на SQLite перед каждым оператором заново выставляется query_only, на DuckDB это read-only дескриптор. INSERT, UPDATE и DDL отклоняются до того, как дойдут до таблицы.

Все цифры по моделям выложены по каждой отдельно, включая те, что не прошли, и шаг, на котором они сломались: https://github.com/libredb/libredb-studio/blob/main/docs/llms/README.md

Сам проект: https://github.com/libredb/libredb-studio

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