# Маршрутизируйте по сложности, а не по умолчанию Когда Apple перестроила Siri, она не выбрала одну модель и не отправила в неё всё. Запрос на таймер остаётся в телефоне. Средний запрос идёт на приватные серверы Apple. И только самое тяжёлое рассуждение доходит до гигантской модели Google. Это трёхуровневое разделение — не причуда Apple, а паттерн, к которому сходится каждый серьёзный ИИ-продукт: отправлять каждый запрос в одну большую модель — значит переплачивать на лёгких и переэкспонировать чувствительные. Лечится маршрутизацией, и большинство строителей её пропускают. - **Author:** Фёдор Чищин - **Published:** 2026-06-08 - **Tags:** architecture, ai-native - **Source:** https://fedorthinks.com/ru/blog/route-by-difficulty-not-by-default --- В перестройке Siri зарыто решение об архитектуре, достойное большего внимания, чем заголовок про Gemini. Новая Siri использует [трёхуровневую систему маршрутизации](https://www.techtimes.com/articles/317985/20260608/apple-wwdc-2026-siri-rebuilt-gemini-homeos-previewed-cook-farewell-keynote.htm), которая решает, _где_ обработать каждый запрос. Простое — поставить таймер, включить песню — работает целиком в телефоне, данные с устройства не уходят. Умеренно сложные запросы идут в собственный Private Cloud Compute Apple, обрабатываются и тут же забываются. И только самое тяжёлое рассуждение уходит в гигантскую модель Gemini в облаке Google. Заметьте, чего Apple _не_ сделала: не выбрала одну модель и не направила в неё всё. И это урок, потому что выбрать одну модель на всё — ровно то, что делает большинство строящих ИИ-продукты, — и это тихо неверный дефолт сразу по двум осям. ## Одна модель на всё неверна дважды Отправьте каждый запрос в одну большую модель — и сделаете две ошибки одновременно. Первая — стоимость. Большинство запросов лёгкие. «Переформатируй дату», «спам ли это письмо», «суммируй один абзац» — им передовая модель нужна не больше, чем сложению нужен суперкомпьютер. Маршрутизировать их в самую дорогую модель — значит платить премиальные цены за тривиальную работу, на каждом вызове, вечно. Исследования о маршрутизации по сложности показывают, что вызовы к большой модели можно срезать [примерно на 40% без падения качества](https://www.microsoft.com/en-us/research/publication/hybrid-llm-cost-efficient-and-quality-aware-query-routing/), просто отправляя лёгкое в маленькую модель и эскалируя, только когда правда сложно. Это идея [дешёвой модели на бо́льшую часть работы](/blog/cheap-model-most-of-the-work), превращённая в инфраструктуру. Вторая ошибка — экспозиция. Часть ваших запросов содержит чувствительные данные — здоровье, финансы, личные сообщения. Отправлять их в стороннюю облачную модель нормально для поиска рецепта и серьёзная проблема для медкарты. Одна модель на всё значит, что самые чувствительные данные едут той же дорогой, что и самые тривиальные, — наружу к тому, кто хостит модель. Весь смысл Apple в том, что таймер и приватный запрос _не_ должны ехать одной дорогой. Маршрутизация чинит и то и другое разом. А две оси — насколько это сложно и насколько чувствительно — это и есть весь дизайн. ## Два вопроса, которые решают маршрут Прежде чем запрос попадёт в модель, спросите о нём две вещи: **Насколько он сложный?** Маршрутизируйте по сложности. По умолчанию отправляйте всё в самую дешёвую и быструю модель, что правдоподобно справится, и эскалируйте к большей только когда маленькой не хватает. Это паттерн «каскад»: сначала локальная или дешёвая, повышение к дорогой при неудаче — а не наоборот. Дорогая модель становится исключением, а не дефолтом, и счёт следует за этим. **Насколько он чувствительный?** Маршрутизируйте по данным, а не только по цене. По-настоящему чувствительные запросы должны оставаться на самом приватном уровне, что у вас есть, — на устройстве или своей инфраструктуре — и, что важно, [никогда молча не откатываться в публичное облако](https://tianpan.co/blog/2026-04-20-privacy-preserving-inference-production-llm), если приватный путь занят. Дисциплина здесь — «fail closed»: не можете обработать чувствительное приватно — отказывайте, а не тихо шлите третьей стороне. Apple обеспечивает это анонимизацией и контрактами, запрещающими Google учиться на запросах пользователей; ваша версия может быть проще, но принцип тот же — чувствительность решает путь, а безопасный отказ — это «не надо», а не «всё равно отправь». ## Почему большинство строителей это пропускают Маршрутизация — больше работы, чем вызов одного эндпоинта, так что честная причина пропуска в том, что одна модель на всё _легко_ отгружается. Подключил передовую модель, она обрабатывает каждый случай, готово. Работает — просто дорого и дырявит так, что не видишь, пока не придёт счёт или утечка. Но трёх уровней Apple для выгоды вам не нужно. Окупается даже грубая версия: дешёвая модель как дефолт, эскалация к сильной, когда проверка уверенности или тип задачи говорит «это сложно», и жёсткое правило, что помеченные чувствительными запросы остаются на пути, который контролируете вы. Это несколько часов сантехники, которые ощутимо режут стоимость и одновременно сжимают вашу поверхность экспозиции. Изощрённость придёт позже; важна _форма_ — по умолчанию дёшево и приватно, эскалация намеренно. ## Суть Яркая часть истории Siri — что Apple арендовала мозг Google. Полезная часть — что Apple поставила _перед_ этим мозгом: маршрутизатор, отправляющий каждый запрос в наименьшее и самое приватное место, что справится, и тянущийся к большой дорогой облачной модели, только когда приходится. Это не роскошь Apple. Это паттерн, который выпадает в тот миг, когда всерьёз относишься к стоимости и приватности, и масштабируется до сольного проекта. Так что перестаньте по умолчанию слать всё в одну модель. Задайте два вопроса — насколько сложно, насколько чувствительно — и пусть ответы выберут маршрут. Бо́льшая часть вашего трафика лёгкая и ничем не примечательна, и маршрутизировать её соответственно — это разница между ИИ-продуктом, дешёвым и безопасным по дизайну, и дорогим и открытым по случайности. Одна модель на всё — это не простота. Это дефолт, который вы на самом деле не выбирали.