Локально запущенная Qwen3.8 27B в связке с DuckDB показала результат выше облачной GPT-5.6 Luna Max в SQL-бенчмарке DABstep. Прогон на ноутбуке обошелся менее чем в $0,50 с учетом электричества, прогон Luna Max стоил больше $8. Разница по стоимости превышает 17 раз.
Конфигурации из кейса: 4-битная версия модели работала на MacBook Air с чипом M5 и 32 ГБ оперативной памяти, 3-битная - на MacBook Pro с M1 Pro и 16 ГБ. Скорость генерации составила около 5-7 токенов в секунду, ответ приходил через несколько минут, тогда как облачные модели отвечали за десятки секунд.
Две оговорки, без которых вывод читается неверно. Слой контекста в бенчмарке строила крупная облачная модель, поэтому локальной была только часть цепочки. В результатах есть разброс, и небольшая доработка промптов может сократить разницу в качестве.
Что произошло: локальная Qwen3.8 27B обошла GPT-5.6 Luna Max в DABstep
Кейс разобран в переводной статье «Qwen3.8 27B обошла GPT-5.6 в SQL-бенчмарке». Автор прогнал бенчмарк DABstep на нескольких моделях через собственную обвязку агента и OpenRouter, а Qwen3.8 27B запустил локально на двух ноутбуках.
Логика эксперимента такая: агент получает задачу, строит цепочку шагов, обращается к локальной аналитической базе DuckDB и возвращает результат. Агентская обвязка осталась одинаковой для всех участников, менялся только «мозг» на другом конце.
Кто участвовал в сравнении: Qwen3.8 27B, GPT-5.6 Luna Max и другие модели
- Qwen3.8 27B - модель с открытыми весами, запущенная локально в 4-битном и 3-битном варианте.
- GPT-5.6 Luna Max (OpenAI) - облачная модель, чей прогон в бенчмарке обошелся более чем в $8.
- Gemini-3-Flash - остается самой точной моделью в этом наборе, но стоит в 2,3 раза дороже Luna.
- Kimi K3 - модель с открытыми весами, показывает довольно высокую точность при высокой цене.
- Sonnet 5 - более высокая цена при заметно худшей точности.
Автор кейса отдельно предупреждает: в результатах есть разброс, поэтому разрыв в качестве не стоит считать вечным приговором облачным моделям. Доработка промптов способна его сократить.
Почему результат нельзя считать абсолютной победой локальных моделей
Главная оговорка спрятана в деталях. Слой контекста для бенчмарка строила крупная облачная модель, то есть «локально» относится к инференсу, а не к пайплайну целиком. Убрать облако из схемы полностью не получилось.
Второй момент - скорость: 5-7 токенов в секунду превращаются в минуты ожидания на один ответ. Третий - параллелизм. Локальный запуск обслуживает один запрос за раз, поэтому команду из нескольких аналитиков такой агент не вытянет.
| Параметр | Локальная Qwen3.8 27B | Облачные модели |
|---|---|---|
| Стоимость прогона | менее $0,50 с электричеством | более $8 у Luna Max, Gemini-3-Flash в 2,3 раза дороже Luna |
| Скорость | 5-7 токенов в секунду, ответ за минуты | ответ за десятки секунд |
| Параллельные запросы | нет | есть |
| Память на стороне пользователя | 32 ГБ для 4-битной сборки, 16 ГБ для 3-битной | не требуется |
| Слой контекста | в кейсе его строила облачная модель | входит в работу модели |
Практический вывод простой: тезис «обошла GPT-5.6» верен с условиями. Он работает для конкретного бенчмарка, конкретной обвязки и конкретных квантованных сборок. В рабочем процессе картина зависит от того, что важнее: цена, скорость или приватность.
Сколько это стоит на самом деле: электричество против облачных API
Стоимость прогона локальной Qwen3.8 27B в кейсе - менее $0,50 с учетом электричества. GPT-5.6 Luna Max обошлась более чем в $8, то есть больше чем в 17 раз дороже. В эти полдоллара не входят ни амортизация ноутбука, ни время человека на настройку, отладку и ожидание ответов.
Энергопотребление двух машин из кейса различается втрое: MacBook Air с M5 потребляет 30 Вт против 100 Вт у MacBook Pro с M1 Pro. Если ноутбук молотит запросы часами, разница в счетах за электричество накапливается, и по энергоэффективности Air выгоднее.
Сравнение с облаком не сводится к одной цифре. Gemini-3-Flash точнее всех в наборе, но стоит в 2,3 раза дороже Luna. Kimi K3 дает довольно высокую точность, но и стоит дорого. У Sonnet 5 высокая цена соседствует с заметно худшей точностью, и такое соотношение сложно назвать удачным.
Если внешние API остаются частью схемы, оплата зарубежных сервисов часто упирается в отсутствие подходящей карты. Для таких расчетов используют виртуальную банковскую карту зарубежного банка, которую выпускают дистанционно и пополняют в рублях через СБП. Локальный запуск эту проблему снимает по определению, но только пока хватает железа и терпения.
Когда локальный запуск выгоден, а когда облако дешевле
Локальный запуск выигрывает при больших объемах однотипных запросов, требованиях к приватности и наличии подходящей машины под рукой. Облако выгоднее, когда критична скорость ответа, нужны параллельные запросы или объем задач настолько мал, что счет за API не имеет значения.
Экономику домашнего инференса с реальными затратами на железо, лизинг и VPS разбирали в отдельном материале: локальный AI вместо облака. Там же показано, что ставка на локальный стек сыграет не в каждом сценарии.
Динамику цен и скорости на Apple Silicon удобно смотреть в ретроспективе: от GPT-5 до локальных моделей уровня Qwen3.6-27B. Год назад сопоставимый результат на ноутбуке выглядел иначе.
Какое железо нужно: опыт запуска на MacBook Air M5 и MacBook Pro M1 Pro
Порог входа в кейс оказался невысоким по современным меркам. 4-битная Qwen3.8 27B поместилась в 32 ГБ оперативной памяти MacBook Air с M5. Урезанная 3-битная сборка запустилась на куда более скромном MacBook Pro с M1 Pro и 16 ГБ.
Оба запуска обошлись без дискретной видеокарты: работала объединенная память Apple Silicon. Именно этот факт делает кейс интересным для владельцев ноутбуков, а не только для сборок с RTX.
Что такое квантизация и почему 3-битная версия запустилась на 16 ГБ
Квантизация уменьшает разрядность весов модели. Требования к памяти падают, и модель помещается на машину, которой иначе не хватило бы VRAM. Обратная сторона - возможная потеря качества, в том числе в следовании инструкциям.
Наглядный пример есть в разборе про переход на более крупные локальные LLM: Qwen 3.8 27B в формате NVFP4 на платформе Ninfer справлялась с личными проектами, но провалилась там, где нужна дисциплина, и не следовала инструкциям из AGENTS.md и agent skills. Связь проблемы именно с NVFP4 не подтверждена, автор не сравнивал ту же модель в других форматах. Сам риск понятен: чем агрессивнее сжатие, тем выше шанс, что модель начнет игнорировать правила агента.
Скорость генерации 5-7 токенов в секунду: что это значит на практике
Для чата это терпимо, для интерактивной работы с таблицей - нет. Пять-семь токенов в секунду означают, что простой ответ набирается минутами, а длинная цепочка рассуждений агента растягивается на ощутимое время. Облачные модели в том же бенчмарке отвечали за десятки секунд.
Скорость сильно зависит от железа и рантайма. На другом стенде переход с MacBook на Linux-систему с RTX 3090 поднял скорость с 20 до 100 токенов в секунду: RTX 3090 против MacBook M5 Pro. Плата за такую скорость - отдельная машина, больше энергии и заметно больше настройки.
Как собрать локальный SQL-агент на DuckDB: пошаговая настройка
Последовательность шагов из кейса: поставить DuckDB, поставить LM Studio, скачать квантованную Qwen3.8 27B, включить MTP для ускорения генерации и подключить OpenAI-совместимый эндпоинт к агенту. Точные команды зависят от вашей обвязки, поэтому ниже - уровень действий и то, на что смотреть.
Установка DuckDB и подготовка данных
DuckDB - локальная аналитическая СУБД, которая работает внутри процесса и не требует отдельного сервера. Для SQL-агента это удобно: база лежит рядом, запросы выполняются на месте, данные не уходят наружу. Агент генерирует SQL, DuckDB его исполняет, результат возвращается в цепочку рассуждений.
Запас на рост нагрузки заложен заранее. Если данных станет больше, чем тянет ноутбук, обработку переносят в MotherDuck: в кейсе достаточно изменить одну настройку, чтобы перевести запросы в облако, не переписывая агента.
Запуск Qwen3.8 27B в LM Studio и выбор квантованной модели
LM Studio выступает локальным провайдером: он поднимает модель и отдает ее по сети. Выбор сборки определяется объемом памяти. 32 ГБ позволяют взять 4-битный вариант, 16 ГБ оставляют только 3-битный.
Компромисс предсказуем: экономия памяти оплачивается качеством, и на задачах, где агент обязан строго соблюдать формат и правила, это может выйти боком. Если дисциплина модели критична, лучше взять более мягкую квантизацию и больше памяти. Практический опыт запуска локальных агентов через LM Studio на Apple Silicon разобран здесь: Mac mini M4 Pro как сервер AI-агентов.
Включение MTP для ускорения генерации
MTP (multi-token prediction) заставляет модель предсказывать несколько токенов за один шаг, что сокращает число последовательных проходов и поднимает скорость генерации. В описании кейса включение MTP указано среди шагов настройки, а итоговая скорость на ноутбуках составила те самые 5-7 токенов в секунду.
Ждать, что один переключатель превратит ноутбук в быстрый сервер, не стоит. MTP помогает сгладить разрыв, но не меняет порядок величин: локальный инференс на потребительском железе остается медленнее облачного.
Подключение OpenAI-совместимого эндпоинта к агенту
Смысл связки в том, что агент обращается к локальной модели так же, как к облачной, через OpenAI-совместимый эндпоинт. Это позволяет менять модели без переписывания кода и сравнивать локальный запуск с облачными участниками в одной обвязке.
В редакторе Zed LM Studio настраивается через переменную окружения LMSTUDIO_API_KEY: имена переменных генерируются из идентификатора провайдера в верхнем snake case с суффиксом _API_KEY (документация Zed). Там же указано, что Zed поддерживает кастомные HTTP-заголовки для LM Studio и OpenAI-совместимых провайдеров, а непустые переменные окружения имеют приоритет над значениями из системного keychain. Последнее удобно, когда ключ или адрес эндпоинта нужно переопределить для конкретного запуска.
Ограничения подхода: где локальный SQL-агент ломается
- Требовательность к объему памяти: 32 ГБ на 4-битную сборку, 16 ГБ на 3-битную.
- Низкая скорость генерации: 5-7 токенов в секунду и минуты на ответ.
- Отсутствие параллельных запросов: один ноутбук обслуживает один запрос за раз.
- Зависимость от облачной модели для построения слоя контекста в бенчмарке.
- Разброс результатов: доработка промптов может сократить разницу в качестве.
Память и квантизация: где проходит граница
16 ГБ хватает только на 3-битную сборку, 32 ГБ - на 4-битную. Меньше памяти означает более агрессивное сжатие весов, а вместе с ним растет риск, что модель начнет путать форматы и игнорировать инструкции агента. Пример с NVFP4 на Ninfer показывает, как это выглядит на практике: модель работала, но дисциплины не хватало.
Отсюда простое правило: если агенту нужно строго соблюдать схему запроса и правила вызова инструментов, экономить на памяти не стоит. Лучше взять машину с запасом, чем отлаживать агента, который игнорирует половину инструкций.
Скорость и параллелизм: почему один ноутбук - один запрос
Минуты на ответ против десятков секунд у облака и никакого параллелизма. Для персональной работы это терпимо, для командной - нет: коллеги будут стоять в очереди за одной видеокартой или одним чипом. Сервер на одном ноутбуке не масштабируется добавлением пользователей.
Когда локальный SQL-агент на DuckDB действительно выгоден
Сценарии, где локальный запуск окупается
- Приватная аналитика: данные не покидают машину.
- Регулярная пакетная обработка однотипных SQL-запросов, где минуты ожидания не критичны.
- Эксперименты с агентами без счета за API.
- Отладка пайплайнов и обучение на собственных данных.
Экономия проявляется на объеме. Единичный запрос дешевле отправить в облако, чем разворачивать стек и ждать ответа несколько минут.
Сценарии, где проще и быстрее использовать облачные API
- Интерактивная работа, когда ответ нужен за секунды.
- Командные процессы с параллельными запросами.
- Задачи, где критична максимальная точность: в кейсе самой точной осталась Gemini-3-Flash.
- Разовые запросы без требований к приватности.
Если нагрузка вырастет, локальный DuckDB не придется переписывать: перенос обработки в MotherDuck делается изменением одной настройки, а агент продолжает работать через OpenAI-совместимый интерфейс. GPT-5.6 Luna Max дороже локального запуска в 17 раз, но отвечает за десятки секунд вместо минут. Для рабочих задач, где счет идет на часы, это часто решающий аргумент.
Начните с одного повторяющегося SQL-запроса: если он укладывается в 3-битную сборку на 16 ГБ и готов ждать минуты, локальный вариант окупит настройку. Если нужен быстрый отклик или параллельная работа команды, оставляйте инференс в облаке, а локально держите только базу.