# Сначала тянись к маленькой модели Рефлекс — слать каждую задачу в самую большую, самую умную модель. Цифры говорят, что это обычно неверный дефолт. Маленькая модель на 7 миллиардов параметров работает в 10–30 раз дешевле, чем на 70–175B, Phi от Microsoft держит уровень GPT-3.5 при 98% меньшем вычислении, а больше двух миллиардов телефонов уже гоняют годные модели локально без всякого облака. Gartner ждёт, что задачные маленькие модели будут использоваться втрое чаще общих LLM к 2027-му. Вот почему «сначала маленькая» становится умным дефолтом — и когда всё же тянуться к большой. - **Author:** Фёдор Чищин - **Published:** 2026-06-13 - **Tags:** ai-native, business - **Source:** https://fedorthinks.com/ru/blog/reach-for-the-small-model-first --- У большинства строящих с ИИ один рефлекс: слать задачу в самую большую, самую умную доступную модель. Кажется безопасным — зачем отдавать работу модели послабее? Но цифры 2026-го говорят, что этот рефлекс обычно неверный дефолт, и тянуться к маленькой модели первой — вот ход, что тихо побеждает. Начнём с экономики, потому что она не тонкая. Обслуживать маленькую модель на 7 миллиардов параметров [в 10–30 раз дешевле, чем гонять большую на 70–175B](https://iterathon.tech/blog/small-language-models-enterprise-2026-cost-efficiency-guide), а компании, переносящие правильную работу на маленькие модели, [режут расходы на ИИ до 75%](https://iterathon.tech/blog/small-language-models-enterprise-2026-cost-efficiency-guide). И это не жертва качеством ради скидки: Phi-3.5-Mini от Microsoft [держит уровень класса GPT-3.5 при примерно 98% меньшем вычислении](https://iterathon.tech/blog/small-language-models-enterprise-2026-cost-efficiency-guide). Разрыв между «маленькой» и «достаточно хорошей» закрылся, пока все смотрели на передовую. Давайте приведу довод перевернуть ваш дефолт, потому что это меняет и счёт, и архитектуру. ## «Маленькая» перестала значить «слабая» Пару лет назад выбрать маленькую модель значило принять заметно худший вывод. Этого размена для работы, которую большинство приложений реально делает, в основном больше нет. Сегодняшние маленькие модели тянут классификацию, извлечение, маршрутизацию, суммаризацию, задачи со структурированными данными и прямолинейный код с качеством, которое трудно отличить от гиганта, — ровно на тех задачах, что составляют основную массу настоящего продукта. Передовая модель всё ещё лучше на по-настоящему тяжёлом: глубоком многошаговом рассуждении, новых задачах, длинном хвосте краевых случаев. Но вот что большинство приложений упускает — тяжёлое составляет _меньшинство_ вызовов. Вы платите по передовым ценам, чтобы классифицировать тикеты поддержки и переформатировать JSON. Это та же мысль, что и [дешёвая модель делает 90% работы](/blog/cheap-model-most-of-the-work): дорогая модель — это исключение, к которому эскалируешь, а не дефолт, с которого начинаешь. ## Новая суперсила: она работает на устройстве Есть вторая причина, почему «сначала маленькая» важно, и это не только цена. Маленькие модели работают там, где большие не могут. Больше [двух миллиардов смартфонов теперь гоняют годные локальные модели](https://iterathon.tech/blog/small-language-models-enterprise-2026-cost-efficiency-guide), а модель на миллиард параметров влезает примерно в 650 МБ памяти и работает на телефоне со скоростью чтения. Достаточно маленькая модель означает _вообще никакого похода в облако_. Это открывает то, что облачный API никогда не сможет. Данные не покидают устройство — это ответ про приватность и комплаенс, а не только про задержку. Нет счёта за токены, нет лимита запросов, нет простоя, который надо пересидеть, и оно работает в самолёте. Для целого класса фич — ассистентов на устройстве, приватного извлечения, всего чувствительного к задержке или приватности — маленькая локальная модель не бюджетный вариант, а _единственный_ с такими свойствами. Gartner ждёт, что задачные маленькие модели будут использоваться [втрое чаще общих LLM к 2027-му](https://iterathon.tech/blog/small-language-models-enterprise-2026-cost-efficiency-guide), и это большая часть почему. ## Когда всё же тянуться к большой «Сначала маленькая» — это дефолт, а не религия. Тянитесь к передовой модели, когда задача реально этого требует: - **Тяжёлое, открытое рассуждение** — многошаговые задачи, неоднозначные цели, новая работа без чистого паттерна, которому следовать. - **Широта, которую не предсказать** — общий ассистент, отбивающий что угодно, что пользователь может спросить, где задачу не очертить заранее. - **Когда вы ещё не замерили** — прототипируйте на большой модели, чтобы понять, как выглядит «хорошо», потом переносите устоявшиеся повторяющиеся пути вниз, на маленькую. Побеждает паттерн [маршрутизации по сложности](/blog/route-by-difficulty-not-by-default): маленькая модель по умолчанию, эскалация к большой, только когда задача это заслужила. Переворачивается стартовое предположение — с «бери лучшую модель и экономь потом» на «бери самую маленькую модель, что берёт планку, и эскалируй, когда не берёт». ## Суть Инстинкт всегда хватать самую мощную модель — пережиток времён, когда маленькие модели были по-настоящему плохи. Больше нет. Для основной массы реальных задач маленькая модель в 10–30 раз дешевле, часто работает на устройстве вообще без облака и выдаёт вывод, который не отличить от гигантского. Дефолтить на передовую для всего — теперь в основном способ переплачивать и переусложнять. Так что переверните рефлекс. Тянитесь к маленькой модели первой, замерьте, берёт ли она планку — обычно берёт, — и приберегите дорогую модель для меньшинства задач, которым она реально нужна. Команды, что так делают, не жертвуют качеством ради цены. Они подбирают инструмент под работу и получают меньший счёт, меньшую задержку и лучшую приватность как награду.