Чукча вообще не писатель, я тут десяток лет ничего не писал, да и комментирую редко, просто тема достаточно мне близкая, но подумаю, как структурировать знания в общем виде, а не в виде каких-то кусков наработок. Основная проблема с нейронками сейчас в том, что всё настолько быстро меняется, что любая глобальная статья выйдет уже устаревшей. Надо подождать годик-другой, чтобы знания настоялись, появились какие-то best practice, отмер миллион инструментов и остались только самые-самые. Сейчас идёт зарождение нового формата работы для многих, каждый день появляются новые подходы, и то, что можно описать сейчас, через пару месяцев будет устаревшим и неприменимым.
Тут сложно ответить однозначно: каждый выстраивает такую схему под себя и под свой профиль работы. Я SRE, и у меня вся эта конструкция дополнительно обвязана еще десятком MCP, которые ходят в рабочие системы: GitLab, мониторинг, агенты на серверах, Jira, Confluence, NetBox, Ansible и так далее.
То есть, если мне нужно опробовать какой-то новый инструмент, например плагин для VSC, я просто подключаю его к API LiteLLM, и все его запросы сразу начинают идти через всю эту обвязку - с роутингом и обогащением данных через MCP. Точно так же туда подключаются чат, консоль и прочие интерфейсы.
Например, в LibreChat я могу написать что-то вроде: “Какие серверы с DDR5-памятью сейчас утилизированы по памяти более чем на 80%?” - и получить список. Затем следующим сообщением спросить: “Какие из них стабильно растут по утилизации на протяжении полугода и какие наиболее ресурсоемкие процессы сейчас на них запущены? Сделай таблицу по убыванию”. После этого я могу просмотреть результат, при необходимости что-то уточнить через агентов, а затем в том же окне чата попросить поставить задачу в jira на закупку памяти с перечислением серверов и недостающих объемов.
При этом в ту же самую связку, из окна VSC, я могу попросить написать скрипт, добавить информацию о нем в Confluence, положить его в репозиторий GitLab и выкатить плейбуком на нужный inventory, который нейросеть получит из NetBox по имени проекта.
Можно ли сделать то же самое через набор агентов в стиле OpenClaw? Да, конечно, можно. Но в таком случае каждая мини-задача, скорее всего, потребует отдельного агента, и каждый инструмент должен будет понимать, к какому именно агенту обращаться. Для моих задач это не всегда удобно, потому что они не так уж часто повторяются - иначе я бы их уже давно автоматизировал. Почти каждая новая задача немного отличается от предыдущей, и под нее пришлось бы каждый раз дорабатывать или перенастраивать агентов.
Если сравнивать с обычным производством, то агенты - это конвейер, где каждый сотрудник хорошо делает несколько конкретных операций, но ничего не знает о работе соседа. Моя же схема - это скорее универсал, который, возможно, будет выполнять работу чуть дольше и местами чуть менее эффективно, зато способен провести ее от начала до конца, не дергая остальных.
У меня 5090 покупалась для игр, комп в дуалбуте, днем в рабочее время крутится убунта со всем этим комбайном для нейронок, вечером я на нем в игрушки играю.
У меня это работает как: Клиент -> внешний оркестратор -> qwen-classifier -> LiteLLM model_name -> внутренний router LiteLLM -> провайдер/локальная модель -> fallback при ошибке
Схема работы такая: клиент отправляет запрос во внешний оркестратор, оркестратор сначала вызывает qwen-classifier, получает от него решение о маршрутизации, после этого выбирает нужный model_name в LiteLLM, LiteLLM через свой внутренний роутер выбирает конкретный backend, отправляет запрос в локальную модель или внешний провайдер, а при ошибке применяет retries и fallback.
Логика простая. Оркестратор получает запрос пользователя и не пытается сразу отдать его в финальную модель. Сначала он делает отдельный вызов в qwen-classifier, который используется только как классификатор. Этот вызов нужен для того, чтобы понять, какой тип задачи пришел, насколько она сложная, критичная, требует ли размышления, кода и длинного контекста. В ответ qwen-classifier возвращает JSON, например такой:
После этого оркестратор валидирует этот JSON и уже на его основе выбирает alias для основного вызова в LiteLLM. Маппинг примерно такой: fast_local -> qwen-local, infra_ops -> qwen-infra, balanced_external -> gpt-5.4, premium_reasoning -> claude.
Смысл тут в том, что qwen-classifier, qwen-local и qwen-infra — это одна и та же локальная модель на одном и том же backend, но с разными параметрами вызова и разным execution profile. qwen-classifier используется только для классификации и никогда не отдает пользователю финальный ответ. qwen-local используется для быстрых ответов без глубокого анализа. qwen-infra используется для инженерных и инфраструктурных задач, где нужен более серьезный разбор. gpt-5.4 — это внешний маршрут среднего уровня по цене и качеству. claude — самый сильный и дорогой маршрут для сложных или критичных задач.
После выбора alias оркестратор формирует профиль вызова для основной модели. То есть он подставляет нужный system prompt, temperature, max_tokens, timeout и, если это локальная модель, включает или отключает размышление через think=true/false. Дальше оркестратор делает обычный HTTP-вызов в LiteLLM, например в /v1/chat/completions, и ставит в запросе model: “qwen-infra” или другой выбранный alias.
LiteLLM сам смотрит в config.yaml, находит, какой backend и какая реальная модель стоят за этим model_name, и дальше работает уже как прокси. Если под alias только один deployment, он сразу вызывает нужный backend. Если deployment несколько, включается внутренний router LiteLLM и выбирает конкретный backend по своей стратегии.
Когда backend отвечает, LiteLLM возвращает результат оркестратору. Оркестратор может сделать постобработку: проверить, что ответ не пустой, что структура валидная, что модель не вернула мусор или поломанный JSON, если он ожидался. Если ответ нормальный, он уходит клиенту.
Если backend вернул ошибку, сначала отрабатывают retries и fallback внутри самого LiteLLM. Если это не помогло или если ответ пришел, но не прошел проверку качества на стороне оркестратора, оркестратор может сам повысить маршрут и повторить запрос через более сильный alias.
Дополнительная policy-логика обычно такая. Если route=fast_local, выбирается qwen-local. Если route=infra_ops, выбирается qwen-infra. Если route=balanced_external, выбирается gpt-5.4. Если route=premium_reasoning, выбирается claude. Если needs_reasoning=true и выбран локальный маршрут, включается think=true. Если needs_reasoning=false и выбран быстрый локальный маршрут, включается think=false. Если needs_code=true и complexity=high, маршрут можно сразу поднять на один уровень. Если needs_long_context=true, запрос не должен идти в qwen-local. Если criticality=high, можно вообще запретить qwen-local и qwen-infra для финального ответа и сразу отправить запрос во внешнюю модель. Если локальная модель ответила плохо, запускается escalation по цепочке qwen-local -> qwen-infra -> gpt-5.4 -> claude.
Полный проход запроса выглядит так. Клиент отправляет запрос в оркестратор. Оркестратор делает первый вызов в qwen-classifier. qwen-classifier возвращает JSON с route и флагами. Оркестратор валидирует классификацию, выбирает alias основной модели, формирует execution profile и отправляет основной запрос в LiteLLM. LiteLLM по model_name ищет deployment, внутренний router выбирает backend, запрос уходит в локальную модель или внешний провайдер. Если backend ответил успешно, LiteLLM возвращает результат оркестратору. Оркестратор выполняет контроль ответа и отдает его клиенту. Если backend вернул ошибку, LiteLLM применяет retries и fallback. Если и это не помогло, или если результат неудовлетворительный, оркестратор может повторить запрос через более сильную модель. Финальный ответ после этого возвращается клиенту.
Для примера, если приходит запрос: «Спроектируй и напиши функцию определения проблем в Ceph», оркестратор сначала отправляет его в qwen-classifier. Классификатор, скорее всего, вернет что-то вроде:
Дальше оркестратор видит, что задача инженерная, сложная, требует код и длинный контекст. Базовый выбор тут будет qwen-infra, но из-за criticality=high и needs_long_context=true policy может сразу поднять маршрут до gpt-5.4 или даже claude. После этого оркестратор делает основной вызов в LiteLLM уже с нужным alias. LiteLLM выбирает backend, выполняет запрос и возвращает ответ. Если ответ плохой или вызов завершился ошибкой, включается fallback или escalation.
Ух вот это я простыню накатал, надеюсь хоть чуть-чуть понятно, вообще начни с базового функционала https://docs.litellm.ai/docs/proxy/auto_routing а там уже можно расширять по мере надобности. Сюрпризы бывают, но достаточно редко, у меня еще и бюджетирование настроено, чтоб в минус по деньгам не уйти случайно на простых задачах, ошибки в основном вида отдал в локальную модель, получил вывод не проходящий тесты, отдал в платную, тесты ОК, но у меня промтами подперто еще так , чтоб запросы сразу в самую дорогую не шли, если не попытался решить в более дешевой, исключение триггер на слово архитектура, такие запросы сразу в клод.
Как раз локальная LLM сейчас это qwen3.5:35b на 256К контекста через настроенный Auto Routing в LiteLLM плюс оркестратор, там одностраничник на питоне, четко на GPU влезает, если не в одну калитку использовать, а делить на несколько человек, то 27b будет с большим запасом по памяти. Промт для оркестрации примерно такой:
Ты классификатор запросов. Верни только JSON. Допустимые route: local_fast, infra_ops, deep_reasoning, safe_review. Оцени complexity: low, medium, high. Поставь sensitive: true/false.
Для себя пришел к схеме собственного сервака дома (RTX 5090), на котором развернута связка LibreChat (Собственно для работы в режиме чата) -> LiteLLM -> ollama с локальной моделью плюс оркестрация и бюджетирование, выходит удобная схема, когда простые запросы обрабатываются локально бесплатно и в большинстве случаев приемлемо, более сложные уходят на дешевые или бесплатные облачные LLM, самые сложные и архитектурные на дорогие, а вот тесты снова можно гонять на дешевых или локально. Итого имеем единый интерфейс для агентов, единый чат, единую точку подключения MCP и скилов и можно один раз настроить инструмент для подключения к LiteLLM, а дальше уже работать со всем комбайном сразу, так и токены экономятся сильно и качество не страдает и не надо каждый раз переключать инструменты на новую схему, чтоб потестить какую-то модель.
У человека, не медика, не то чтоб большой выбор, можно спросить у нейронки и попытаться вникнуть в вывод, походить по источникам, узнать на сколько они релевантные и признаются в научном мире и то не гарантия, о чем говорят куча отозванных статей в том же саинс. Можно положиться на мнение терапевта в районной поликлинике и, к сожалению, получить в качестве назначения как заведомо не работающие препараты так и вредные в комбинации. Тут выбор из 2х зол и далеко не всегда живой человек в доступе даст рекомендации лучше. Для себя вывел подход, читаю назначение врача, каждый препарат пытаюсь проверить по доказательной базе, нейронка в этом сильно помогает. Какой еще путь для человека, не имеющего личных контактов среди реальных светил медицины?
Самое забавное то, что если скормить нейронке анализы и попросить рекомендации, то в рекомендациях не будет фуфломицинов, бадов, пробиотиков, гомеопатии и остальной фармы с сомнительной эффективностью, а терапевты уж очень этим злоупотребляют. Да и будут ссылки на исследования, по которым можно пройти и ознакомиться с доказательной базой назначений.
Отсекает огромную аудиторию не специалистов, одно дело скопировать ссылку и скинуть другу, совсем другое раскопать конфиг в недрах приложения, плюс многие околовпн каналы банят за любую инфу по выковыриванию реальных ссылок из подписки.
Естественно запуск на тестовой, потом запуск на не критичных, примерно 10% от всех, прошло гладко - запуск на оставшихся, с таким же успехом собственноручно сделанный скрипт точно так-же может что-то не то сделать, если ошибиться. Ну и бэкапы никто не отменял. Зато правильно подключенные MCP позволяют без необходимости не вникать в тонны документации не очень нужного тебе инструмента для разовой задачи. У нейронок дохрена минусов, если относиться к ним как к интеллекту, но если относиться как к понятному инструменту ускорения рутинных разовых задач, то не вижу ничего плохого. Я застал еще времена когда использовать IDE с подсказками считалось не тру, а настоящий программист должен был писать в блокноте, но сейчас никто не представляет себе работу без IDE, через несколько лет так же будет и с нейронками.
Аналогично, но если на данный момент все мои потребности закрыты и код выполняет возложенное на него, зачем мне вникать и лезть в то, что там нагенерила система, да потратив какое-то время, я скорее всего смогу разобраться, вникнуть и что-то поправить руками и даже доработать, но зачем, вот недавно мне нужна была система миграции виртуалок из гипервизора А в гипервизор Б на лету и виртуалок несколько тысяч, навайбкодил, смигрировал, положил на память себе готовый скрипт в репу, с полным пониманием, что он мне больше никогда в жизни не пригодится. То-есть нейронка закрыла мою задачу за пол часа, сам бы с чтением доки по API обоих систем я бы убил пару дней на эксперименты, на качество кода внутри скрипта мне глубоко плевать, он выполнил то, что должен был выполнить и больше не нужен. Таких задач намного больше бывает в работе, чем вдумчивая разработка нужного всем инструмента с коммерческим потенциалом - это круто и экономит время, а на звезды в гитхабе как-то плевать.
Так это нормально, раньше было лень делать какой-то минипроект под себя, особенно не программисту соответствующей специализации, разобраться с документацией, модулями, популярными паттернами и особенностями языка, чтоб сделать одноразовый инструмент только для себя, а теперь загрузил в нейронку, за пару часов получил приемлемый результат и используешь с радостью без целей дистрибуции и развития.
Самое сложное в таких проектах научиться отключать голову и делать тупо то, что в задаче, не пытаясь сделать лучше и не проявлять инициативу, платили хорошо, а от полного отупения спасали пет проекты. Лично меня всегда удивляло, что при всех аудитах и прочих инструментах анализа и бигдаты эти решения всегда получали апрув от верховного руководства.
Работал с таким руководителем, из всех вариантов решения задачи выбрать максимально всратое и кривое, угробить на него кучу человекочасов, расширить под него команду, обложить костылями, не успеть к дедлайну, перетащить инженеров с других задач, наплодить еще больше костылей и абстакций, наконец запустить этого монстра в прод, еще пол года подпирать костылями, провести пару рефакторингов, написать миллион красивых отчетов, перейти к следующей задаче по тому же принципу. Через год узнать, что старое решение невозможно поддерживать и торжественно похоронить его, взяв под решение задачи следующий по всратости подход и повторить цикл, зато все при деле и можно много красивых диаграмм на верх владельцам бизнеса слать и бюджеты выбивать под поддержание на плаву этих решений. Всеx, кто предлагают взять работающий простой инструмент и закрыть задачу быстро - перевести в саботажники.
Как же все поменялось. В далеком 18 году проходил собеседование в ВК (тогда еще Mail.ru) и весь процесс занял от первого созвона с HR до получения оффера что-то около недели, я еще был приятно удивлен процессу, созвон с HR, созвон с инженерами от предполагаемых коллег, личная встреча в офисе, оффер на следующий день после встречи, позиция сеньорская. Тогда еще мысленно похвалил службу рекрутинга за четкую структуру и отсутствие лишней бюрократии, в отличии от Яндекса с их десятком этапов, где каждый следующий ничего не знает о предыдущих. Но из текста понял, что эта дурость с затягиванием процесса настигает все больше компаний.
Для всех метрик использую викторию, т.к. умеет нормально жать данные и можно хранить часто меняющиеся метрики очень долго не забивая место на карте памяти, для остального мария, т.к. она все равно нужна для других целей мне удобней все держать в одной базе и бэкапить целиком. Хотелось бы конечно плагин для работы с ClickHouse чтоб иметь единую базу и для метрик и для данных, но тут вариант только напилить самому, т.к. комьюнити это не особо интересно.
Там такое количество нюансов, история с nginx тому подтверждение, что я даже скрипты на гит не выкладываю во избежание лишней головной боли. Опять же скажу исключительно за себя, отработав над рабочим проектом у меня желание отдыхать в дали от компа, так что свободное время и хобби не связаны с IT, но может быть кому-то важно, тут не спорю.
Ну про "бам бам и в продакшн" - это жизнь, везде такое встречал да и на текущем месте хватает. Вот в токсичные коллективы не попадал, ну либо сам достаточно токсичный и для меня это норм. Но такого перекоса в сторону кумовства как в госке не встречал нигде больше, то-есть если я профи и хорошо делаю свою работу, то у комерса я всегда буду иметь хорошую зп, плюшки и регулярные повышения вне зависимости от того с кем из его родственников я бухал на праздниках и если что-то не так, то я уйду и через неделю буду работать с такими-же или лучшими условиями у другого комерса. А в госке унылое болото, где 100500 начальников не могут взять на себя ответственность и принять решение, зато будут ежедневные совещания с некомпетентными "заслуженными" работниками и прочими кадрами, кто чей-то брат\сват\любовник. Все делается не для решения задачи, а для вылизывания зада вышестоящего, на эффективность всем класть. Уж простите мой опыт и многих моих коллег и знакомых с гос аппаратом только негативный.
Интересно. Для меня например полная удаленка была большим преимуществом чем зп +100К, но офис, ничего другого, что влияло бы значительно на выбор как-то в голову даже не приходит.
Нет в госке таких ЗП даже близко, т.к. самый не эффективный мереджмент какой только можно придумать, на профессиональные качества там плевать, главное кумовство и вылизывание зада вышестоящего, имел опыт 8 лет назад очень не долго поработать в госке, когда получил первую зп в 4 раза меньше чем договаривались просто ушел одним днем, но за этот месяц насмотрелся на дефективное руководство так, что теперь туда ни на какую зп ни ногой.
Чукча вообще не писатель, я тут десяток лет ничего не писал, да и комментирую редко, просто тема достаточно мне близкая, но подумаю, как структурировать знания в общем виде, а не в виде каких-то кусков наработок. Основная проблема с нейронками сейчас в том, что всё настолько быстро меняется, что любая глобальная статья выйдет уже устаревшей. Надо подождать годик-другой, чтобы знания настоялись, появились какие-то best practice, отмер миллион инструментов и остались только самые-самые. Сейчас идёт зарождение нового формата работы для многих, каждый день появляются новые подходы, и то, что можно описать сейчас, через пару месяцев будет устаревшим и неприменимым.
Тут сложно ответить однозначно: каждый выстраивает такую схему под себя и под свой профиль работы. Я SRE, и у меня вся эта конструкция дополнительно обвязана еще десятком MCP, которые ходят в рабочие системы: GitLab, мониторинг, агенты на серверах, Jira, Confluence, NetBox, Ansible и так далее.
То есть, если мне нужно опробовать какой-то новый инструмент, например плагин для VSC, я просто подключаю его к API LiteLLM, и все его запросы сразу начинают идти через всю эту обвязку - с роутингом и обогащением данных через MCP. Точно так же туда подключаются чат, консоль и прочие интерфейсы.
Например, в LibreChat я могу написать что-то вроде: “Какие серверы с DDR5-памятью сейчас утилизированы по памяти более чем на 80%?” - и получить список. Затем следующим сообщением спросить: “Какие из них стабильно растут по утилизации на протяжении полугода и какие наиболее ресурсоемкие процессы сейчас на них запущены? Сделай таблицу по убыванию”. После этого я могу просмотреть результат, при необходимости что-то уточнить через агентов, а затем в том же окне чата попросить поставить задачу в jira на закупку памяти с перечислением серверов и недостающих объемов.
При этом в ту же самую связку, из окна VSC, я могу попросить написать скрипт, добавить информацию о нем в Confluence, положить его в репозиторий GitLab и выкатить плейбуком на нужный inventory, который нейросеть получит из NetBox по имени проекта.
Можно ли сделать то же самое через набор агентов в стиле OpenClaw? Да, конечно, можно. Но в таком случае каждая мини-задача, скорее всего, потребует отдельного агента, и каждый инструмент должен будет понимать, к какому именно агенту обращаться. Для моих задач это не всегда удобно, потому что они не так уж часто повторяются - иначе я бы их уже давно автоматизировал. Почти каждая новая задача немного отличается от предыдущей, и под нее пришлось бы каждый раз дорабатывать или перенастраивать агентов.
Если сравнивать с обычным производством, то агенты - это конвейер, где каждый сотрудник хорошо делает несколько конкретных операций, но ничего не знает о работе соседа. Моя же схема - это скорее универсал, который, возможно, будет выполнять работу чуть дольше и местами чуть менее эффективно, зато способен провести ее от начала до конца, не дергая остальных.
У меня 5090 покупалась для игр, комп в дуалбуте, днем в рабочее время крутится убунта со всем этим комбайном для нейронок, вечером я на нем в игрушки играю.
У меня это работает как: Клиент -> внешний оркестратор -> qwen-classifier -> LiteLLM model_name -> внутренний router LiteLLM -> провайдер/локальная модель -> fallback при ошибке
Схема работы такая: клиент отправляет запрос во внешний оркестратор, оркестратор сначала вызывает qwen-classifier, получает от него решение о маршрутизации, после этого выбирает нужный model_name в LiteLLM, LiteLLM через свой внутренний роутер выбирает конкретный backend, отправляет запрос в локальную модель или внешний провайдер, а при ошибке применяет retries и fallback.
Логика простая. Оркестратор получает запрос пользователя и не пытается сразу отдать его в финальную модель. Сначала он делает отдельный вызов в qwen-classifier, который используется только как классификатор. Этот вызов нужен для того, чтобы понять, какой тип задачи пришел, насколько она сложная, критичная, требует ли размышления, кода и длинного контекста. В ответ qwen-classifier возвращает JSON, например такой:
{ “route”: “infra_ops”, “complexity”: “medium”, “criticality”: “medium”, “needs_reasoning”: true, “needs_code”: false, “needs_long_context”: false }
Если задача сложная, ответ может быть таким:
{ “route”: “premium_reasoning”, “complexity”: “high”, “criticality”: “high”, “needs_reasoning”: true, “needs_code”: true, “needs_long_context”: true }
После этого оркестратор валидирует этот JSON и уже на его основе выбирает alias для основного вызова в LiteLLM. Маппинг примерно такой: fast_local -> qwen-local, infra_ops -> qwen-infra, balanced_external -> gpt-5.4, premium_reasoning -> claude.
Сами модели можно держать так:
model_list:
model_name: qwen-classifier litellm_params: model: openai/qwen3.5:35b-a3b-q4_K_M api_base: http://ollama:11434/v1 api_key: ollama temperature: 0 max_tokens: 300 timeout: 15
model_name: qwen-local litellm_params: model: openai/qwen3.5:35b-a3b-q4_K_M api_base: http://ollama:11434/v1 api_key: ollama temperature: 0.1 max_tokens: 800 timeout: 20
model_name: qwen-infra litellm_params: model: openai/qwen3.5:35b-a3b-q4_K_M api_base: http://ollama:11434/v1 api_key: ollama temperature: 0.2 max_tokens: 3000 timeout: 90
model_name: gpt-5.4 litellm_params: model: openai/gpt-5.4 api_key: os.environ/OPENAI_API_KEY temperature: 0.2 max_tokens: 5000 timeout: 120
model_name: claude litellm_params: model: anthropic/claude api_key: os.environ/ANTHROPIC_API_KEY temperature: 0.2 max_tokens: 8000 timeout: 180
Смысл тут в том, что qwen-classifier, qwen-local и qwen-infra — это одна и та же локальная модель на одном и том же backend, но с разными параметрами вызова и разным execution profile. qwen-classifier используется только для классификации и никогда не отдает пользователю финальный ответ. qwen-local используется для быстрых ответов без глубокого анализа. qwen-infra используется для инженерных и инфраструктурных задач, где нужен более серьезный разбор. gpt-5.4 — это внешний маршрут среднего уровня по цене и качеству. claude — самый сильный и дорогой маршрут для сложных или критичных задач.
После выбора alias оркестратор формирует профиль вызова для основной модели. То есть он подставляет нужный system prompt, temperature, max_tokens, timeout и, если это локальная модель, включает или отключает размышление через think=true/false. Дальше оркестратор делает обычный HTTP-вызов в LiteLLM, например в /v1/chat/completions, и ставит в запросе model: “qwen-infra” или другой выбранный alias.
LiteLLM сам смотрит в config.yaml, находит, какой backend и какая реальная модель стоят за этим model_name, и дальше работает уже как прокси. Если под alias только один deployment, он сразу вызывает нужный backend. Если deployment несколько, включается внутренний router LiteLLM и выбирает конкретный backend по своей стратегии.
Когда backend отвечает, LiteLLM возвращает результат оркестратору. Оркестратор может сделать постобработку: проверить, что ответ не пустой, что структура валидная, что модель не вернула мусор или поломанный JSON, если он ожидался. Если ответ нормальный, он уходит клиенту.
Если backend вернул ошибку, сначала отрабатывают retries и fallback внутри самого LiteLLM. Если это не помогло или если ответ пришел, но не прошел проверку качества на стороне оркестратора, оркестратор может сам повысить маршрут и повторить запрос через более сильный alias.
Дополнительная policy-логика обычно такая. Если route=fast_local, выбирается qwen-local. Если route=infra_ops, выбирается qwen-infra. Если route=balanced_external, выбирается gpt-5.4. Если route=premium_reasoning, выбирается claude. Если needs_reasoning=true и выбран локальный маршрут, включается think=true. Если needs_reasoning=false и выбран быстрый локальный маршрут, включается think=false. Если needs_code=true и complexity=high, маршрут можно сразу поднять на один уровень. Если needs_long_context=true, запрос не должен идти в qwen-local. Если criticality=high, можно вообще запретить qwen-local и qwen-infra для финального ответа и сразу отправить запрос во внешнюю модель. Если локальная модель ответила плохо, запускается escalation по цепочке qwen-local -> qwen-infra -> gpt-5.4 -> claude.
Полный проход запроса выглядит так. Клиент отправляет запрос в оркестратор. Оркестратор делает первый вызов в qwen-classifier. qwen-classifier возвращает JSON с route и флагами. Оркестратор валидирует классификацию, выбирает alias основной модели, формирует execution profile и отправляет основной запрос в LiteLLM. LiteLLM по model_name ищет deployment, внутренний router выбирает backend, запрос уходит в локальную модель или внешний провайдер. Если backend ответил успешно, LiteLLM возвращает результат оркестратору. Оркестратор выполняет контроль ответа и отдает его клиенту. Если backend вернул ошибку, LiteLLM применяет retries и fallback. Если и это не помогло, или если результат неудовлетворительный, оркестратор может повторить запрос через более сильную модель. Финальный ответ после этого возвращается клиенту.
Для примера, если приходит запрос: «Спроектируй и напиши функцию определения проблем в Ceph», оркестратор сначала отправляет его в qwen-classifier. Классификатор, скорее всего, вернет что-то вроде:
{ “route”: “infra_ops”, “complexity”: “high”, “criticality”: “high”, “needs_reasoning”: true, “needs_code”: true, “needs_long_context”: true }
Дальше оркестратор видит, что задача инженерная, сложная, требует код и длинный контекст. Базовый выбор тут будет qwen-infra, но из-за criticality=high и needs_long_context=true policy может сразу поднять маршрут до gpt-5.4 или даже claude. После этого оркестратор делает основной вызов в LiteLLM уже с нужным alias. LiteLLM выбирает backend, выполняет запрос и возвращает ответ. Если ответ плохой или вызов завершился ошибкой, включается fallback или escalation.
Ух вот это я простыню накатал, надеюсь хоть чуть-чуть понятно, вообще начни с базового функционала https://docs.litellm.ai/docs/proxy/auto_routing а там уже можно расширять по мере надобности. Сюрпризы бывают, но достаточно редко, у меня еще и бюджетирование настроено, чтоб в минус по деньгам не уйти случайно на простых задачах, ошибки в основном вида отдал в локальную модель, получил вывод не проходящий тесты, отдал в платную, тесты ОК, но у меня промтами подперто еще так , чтоб запросы сразу в самую дорогую не шли, если не попытался решить в более дешевой, исключение триггер на слово архитектура, такие запросы сразу в клод.
Как раз локальная LLM сейчас это qwen3.5:35b на 256К контекста через настроенный Auto Routing в LiteLLM плюс оркестратор, там одностраничник на питоне, четко на GPU влезает, если не в одну калитку использовать, а делить на несколько человек, то 27b будет с большим запасом по памяти.
Промт для оркестрации примерно такой:
Для себя пришел к схеме собственного сервака дома (RTX 5090), на котором развернута связка LibreChat (Собственно для работы в режиме чата) -> LiteLLM -> ollama с локальной моделью плюс оркестрация и бюджетирование, выходит удобная схема, когда простые запросы обрабатываются локально бесплатно и в большинстве случаев приемлемо, более сложные уходят на дешевые или бесплатные облачные LLM, самые сложные и архитектурные на дорогие, а вот тесты снова можно гонять на дешевых или локально. Итого имеем единый интерфейс для агентов, единый чат, единую точку подключения MCP и скилов и можно один раз настроить инструмент для подключения к LiteLLM, а дальше уже работать со всем комбайном сразу, так и токены экономятся сильно и качество не страдает и не надо каждый раз переключать инструменты на новую схему, чтоб потестить какую-то модель.
У человека, не медика, не то чтоб большой выбор, можно спросить у нейронки и попытаться вникнуть в вывод, походить по источникам, узнать на сколько они релевантные и признаются в научном мире и то не гарантия, о чем говорят куча отозванных статей в том же саинс. Можно положиться на мнение терапевта в районной поликлинике и, к сожалению, получить в качестве назначения как заведомо не работающие препараты так и вредные в комбинации. Тут выбор из 2х зол и далеко не всегда живой человек в доступе даст рекомендации лучше. Для себя вывел подход, читаю назначение врача, каждый препарат пытаюсь проверить по доказательной базе, нейронка в этом сильно помогает. Какой еще путь для человека, не имеющего личных контактов среди реальных светил медицины?
Самое забавное то, что если скормить нейронке анализы и попросить рекомендации, то в рекомендациях не будет фуфломицинов, бадов, пробиотиков, гомеопатии и остальной фармы с сомнительной эффективностью, а терапевты уж очень этим злоупотребляют. Да и будут ссылки на исследования, по которым можно пройти и ознакомиться с доказательной базой назначений.
Отсекает огромную аудиторию не специалистов, одно дело скопировать ссылку и скинуть другу, совсем другое раскопать конфиг в недрах приложения, плюс многие околовпн каналы банят за любую инфу по выковыриванию реальных ссылок из подписки.
Естественно запуск на тестовой, потом запуск на не критичных, примерно 10% от всех, прошло гладко - запуск на оставшихся, с таким же успехом собственноручно сделанный скрипт точно так-же может что-то не то сделать, если ошибиться. Ну и бэкапы никто не отменял. Зато правильно подключенные MCP позволяют без необходимости не вникать в тонны документации не очень нужного тебе инструмента для разовой задачи. У нейронок дохрена минусов, если относиться к ним как к интеллекту, но если относиться как к понятному инструменту ускорения рутинных разовых задач, то не вижу ничего плохого. Я застал еще времена когда использовать IDE с подсказками считалось не тру, а настоящий программист должен был писать в блокноте, но сейчас никто не представляет себе работу без IDE, через несколько лет так же будет и с нейронками.
Аналогично, но если на данный момент все мои потребности закрыты и код выполняет возложенное на него, зачем мне вникать и лезть в то, что там нагенерила система, да потратив какое-то время, я скорее всего смогу разобраться, вникнуть и что-то поправить руками и даже доработать, но зачем, вот недавно мне нужна была система миграции виртуалок из гипервизора А в гипервизор Б на лету и виртуалок несколько тысяч, навайбкодил, смигрировал, положил на память себе готовый скрипт в репу, с полным пониманием, что он мне больше никогда в жизни не пригодится. То-есть нейронка закрыла мою задачу за пол часа, сам бы с чтением доки по API обоих систем я бы убил пару дней на эксперименты, на качество кода внутри скрипта мне глубоко плевать, он выполнил то, что должен был выполнить и больше не нужен. Таких задач намного больше бывает в работе, чем вдумчивая разработка нужного всем инструмента с коммерческим потенциалом - это круто и экономит время, а на звезды в гитхабе как-то плевать.
Так это нормально, раньше было лень делать какой-то минипроект под себя, особенно не программисту соответствующей специализации, разобраться с документацией, модулями, популярными паттернами и особенностями языка, чтоб сделать одноразовый инструмент только для себя, а теперь загрузил в нейронку, за пару часов получил приемлемый результат и используешь с радостью без целей дистрибуции и развития.
Самое сложное в таких проектах научиться отключать голову и делать тупо то, что в задаче, не пытаясь сделать лучше и не проявлять инициативу, платили хорошо, а от полного отупения спасали пет проекты. Лично меня всегда удивляло, что при всех аудитах и прочих инструментах анализа и бигдаты эти решения всегда получали апрув от верховного руководства.
Работал с таким руководителем, из всех вариантов решения задачи выбрать максимально всратое и кривое, угробить на него кучу человекочасов, расширить под него команду, обложить костылями, не успеть к дедлайну, перетащить инженеров с других задач, наплодить еще больше костылей и абстакций, наконец запустить этого монстра в прод, еще пол года подпирать костылями, провести пару рефакторингов, написать миллион красивых отчетов, перейти к следующей задаче по тому же принципу. Через год узнать, что старое решение невозможно поддерживать и торжественно похоронить его, взяв под решение задачи следующий по всратости подход и повторить цикл, зато все при деле и можно много красивых диаграмм на верх владельцам бизнеса слать и бюджеты выбивать под поддержание на плаву этих решений. Всеx, кто предлагают взять работающий простой инструмент и закрыть задачу быстро - перевести в саботажники.
Как же все поменялось. В далеком 18 году проходил собеседование в ВК (тогда еще Mail.ru) и весь процесс занял от первого созвона с HR до получения оффера что-то около недели, я еще был приятно удивлен процессу, созвон с HR, созвон с инженерами от предполагаемых коллег, личная встреча в офисе, оффер на следующий день после встречи, позиция сеньорская. Тогда еще мысленно похвалил службу рекрутинга за четкую структуру и отсутствие лишней бюрократии, в отличии от Яндекса с их десятком этапов, где каждый следующий ничего не знает о предыдущих. Но из текста понял, что эта дурость с затягиванием процесса настигает все больше компаний.
Для всех метрик использую викторию, т.к. умеет нормально жать данные и можно хранить часто меняющиеся метрики очень долго не забивая место на карте памяти, для остального мария, т.к. она все равно нужна для других целей мне удобней все держать в одной базе и бэкапить целиком. Хотелось бы конечно плагин для работы с ClickHouse чтоб иметь единую базу и для метрик и для данных, но тут вариант только напилить самому, т.к. комьюнити это не особо интересно.
Там такое количество нюансов, история с nginx тому подтверждение, что я даже скрипты на гит не выкладываю во избежание лишней головной боли. Опять же скажу исключительно за себя, отработав над рабочим проектом у меня желание отдыхать в дали от компа, так что свободное время и хобби не связаны с IT, но может быть кому-то важно, тут не спорю.
Ну про "бам бам и в продакшн" - это жизнь, везде такое встречал да и на текущем месте хватает. Вот в токсичные коллективы не попадал, ну либо сам достаточно токсичный и для меня это норм. Но такого перекоса в сторону кумовства как в госке не встречал нигде больше, то-есть если я профи и хорошо делаю свою работу, то у комерса я всегда буду иметь хорошую зп, плюшки и регулярные повышения вне зависимости от того с кем из его родственников я бухал на праздниках и если что-то не так, то я уйду и через неделю буду работать с такими-же или лучшими условиями у другого комерса. А в госке унылое болото, где 100500 начальников не могут взять на себя ответственность и принять решение, зато будут ежедневные совещания с некомпетентными "заслуженными" работниками и прочими кадрами, кто чей-то брат\сват\любовник. Все делается не для решения задачи, а для вылизывания зада вышестоящего, на эффективность всем класть. Уж простите мой опыт и многих моих коллег и знакомых с гос аппаратом только негативный.
Интересно. Для меня например полная удаленка была большим преимуществом чем зп +100К, но офис, ничего другого, что влияло бы значительно на выбор как-то в голову даже не приходит.
Нет в госке таких ЗП даже близко, т.к. самый не эффективный мереджмент какой только можно придумать, на профессиональные качества там плевать, главное кумовство и вылизывание зада вышестоящего, имел опыт 8 лет назад очень не долго поработать в госке, когда получил первую зп в 4 раза меньше чем договаривались просто ушел одним днем, но за этот месяц насмотрелся на дефективное руководство так, что теперь туда ни на какую зп ни ногой.