Когда OpenClaw Gateway уже поднят, в продакшене обычно спрашивают, как удержать стоимость и задержку вместе. modelRouting раскладывает трафик по ярусам до апстрим-вызова по оценочному размеру контекста, а не всегда платит цену топ-модели. Этот гайд объясняет, какую проблему он решает, как стоит рядом с agents.defaults и фолбэками в openclaw.json, как сопоставить SLO с лестницей maxTokens, и даёт чеклист выката из шести шагов плюс разбор ошибок конфигурации — в дополнение к статьям об установке, systemd и Docker на этом сайте.
В продакшене запросы OpenClaw часто несут системные промпты, историю чата, вывод инструментов и RAG-чанки. Вечно скармливать всё одному флагманскому моделю раздувает счета и хвост задержки; полагаться только на фолбэки после сбоев значит уже сжечь огромный контекст, прежде чем понять, что путь был неверным. modelRouting оценивает размер контекста в токенах до апстрим-инференса и выбирает ярус, чтобы по умолчанию «малые вопросы шли в малые модели» — не постфактум.
Шесть типичных болевых сигналов — если сходятся несколько, ставьте роутинг в повестку ревью конфигурации, а не только смотрите Grafana:
Хвостовая задержка: p95/p99 отрываются от среднего при том же QPS и следуют длине разговора — перегружены тяжёлые контекстные пути.
Нелинейные расходы: трафик +30%, счёт +100% — часто «каждая сессия по умолчанию на самой большой модели».
Вызовы инструментов раздувают контекст: многошаговый вывод за один ход резко поднимает токены, вызывая тихое усечение или неожиданные ретраи.
Слишком длинные цепочки фолбэков: пользователь ничего не видит, но вы связали модели в одном запросе — задержка и стоимость накапливаются.
Нет наблюдаемости роутинга: логируется только финальное имя модели, не причина яруса — разбор превращается в угадайку.
Слабая мультитенантная изоляция: тяжёлые сессии на общем Gateway тянут SLO лёгких сессий — нужен жёсткий контроль по форме контекста.
После серии установки/деплоя OpenClaw на сайте у вас уже есть «процесс жив, порты/туннели здоровы». Эта статья про выбор модели внутри того же долгоживущего процесса. Она ортогональна удалённому исполнению (самохостные раннеры или выделенные удалённые Mac): роутинг выбирает какой мозг; слой исполнителей — какая машина делает работу.
Миф: modelRouting — «ещё один балансировщик». Ближе роутинг по форме контекста — оценить размер, затем выбрать модель; не round-robin, иначе трейсы выглядят умно, а счета честны.
Они не взаимоисключающие, но разделите роли: фолбэки подходят к семантике сбоев — модель недоступна, ошибки, лимиты; modelRouting — к семантике стоимости/задержки — насколько тяжёл этот ход. Смешайте — получите «маршрут выбрал большую модель, затем сбой уронил на маленькую» — платите дважды за драму.
| Измерение | primary + фолбэки (классика) | modelRouting (контекстные ярусы) |
|---|---|---|
| Триггер | Коды ошибок, таймауты, повторяемые сбои | Пороги оценочных токенов контекста (напр. стратегия размера контекста) |
| Главный выигрыш | Доступность: спасение от плохой модели | Эффективность: лёгкие чаты не платят цены флагмана |
| Типичный риск | Длинные цепочки раздувают хвост задержки и двойной биллинг | Плохие пороги ошибочно классифицируют тяжёлое и лёгкое |
| Наблюдаемость | Частота сбоев, ретраи, причина переключения | Смесь попаданий маршрута, ошибки у порогов, перцентили токенов |
| agents.defaults | Объявить primary и список фолбэков | Добавить блок роутинга под defaults и разделить до вызова |
Напишите «подмена при сбое» и «выбор до сбоя» на разных страницах — дежурный скажет спасибо.
Логируйте решения роутинга структурированно (попадание яруса, оценочная полоса токенов, финальный ID модели); иначе в проде виден только финал и пороги не проверить. Шесть шагов ниже — это релизный барьер.
Для инженеров, которые уже выкатывают изменения конфигурации — у каждого шага есть артефакт, чтобы modelRouting не стал разовым JSON-каракулем.
Зафиксируйте язык SLO: целевая задержка p95, потолок стоимости на сессию, доля «тяжёлых» сессий. Без SLO нет серьёзных порогов.
Сэмплируйте распределения токенов: реальные чаты и вывод инструментов — включая хвосты, не только среднюю длину.
Набросайте три яруса: ID лёгкой/средней/тяжёлой модели и задачи, которые никогда не должны попасть на лёгкий ярус (напр. многошаговые инструменты).
Подключите modelRouting и телеметрию: хиты, оценочные токены, финальная модель в структурированные логи и метрики.
Контролируемая канарейка: двойной прогон старого и нового на срезе, смотрите перцентили стоимости и задержки, затем промоут.
Переключатель отката: снимок, чтобы вернуться к «defaults + короткая цепочка фолбэков», если роутинг промахнулся.
{
"agents": {
"defaults": {
"model": { "primary": "anthropic/claude-sonnet-4-5" },
"modelRouting": {
"enabled": true,
"strategy": "context-size",
"thresholds": [
{ "maxTokens": 4000, "model": "anthropic/claude-haiku-4-5", "description": "light" },
{ "maxTokens": 100000, "model": "anthropic/claude-sonnet-4-5", "description": "medium" },
{ "maxTokens": null, "model": "anthropic/claude-opus-4-5", "description": "xlarge context" }
],
"fallbackOnOverflow": true
}
}
}
}
Заметка: Показаны форма и семантика; реальные ключи и значения по умолчанию должны совпадать с вашей версией OpenClaw. Делайте diff конфигов и гоняйте интеграционные фикстуры до обновления Gateway.
Полезная модель: defaults объявляет primary и общие фолбэки; modelRouting (по версии OpenClaw) выполняет разбиение по контексту вместе с defaults; фолбэки по-прежнему обрабатывают апстрим-сбои. В staging проверьте три вещи: на здоровых путях роутинг не должен метаться между моделями (иначе пороги слишком жёсткие); фолбэки после роутинга ведут себя ожидаемо; в логах разделены попадания маршрута и подмены по сбою.
При удалённых вычислениях частая топология: Gateway на Linux VPS или в контейнерах, тяжёлые тулчейны или только-macOS шаги — через очередь к исполнителям на выделенных удалённых Mac. modelRouting только раскладывает инференс внутри Gateway — не заменяет межмашинное планирование (по-прежнему очередь/раннер).
Для мультитенантных агентов на одном Gateway давайте арендаторам отдельные профили роутинга или ключи — иначе оценка контекста тяжёлого арендатора поднимает планку для всех.
Предупреждение: Считайте fallbackOnOverflow значением «контекст не влезает в модель», а не ручкой «экономить» — злоупотребление ведёт к тихому усечению или скрытым ретраям.
Используйте для быстрого дежурного роутинга; если оценочные токены и счета провайдера сильно расходятся, проверьте, не исключён ли вывод инструментов из оценки или не сэмплируются ли логи.
fallbackOnOverflow.Gateway на одноразовом ноутбуке или хосте без гарантий ёмкости убьёт p95 даже при идеальном роутинге; без эксклюзивной, постоянно доступной, контрактуемой плоскости исполнения macOS тулчейны и локальные сборки сопротивляются автоматизации. Командам, которым нужен OpenClaw рядом со сборками iOS/macOS, CI или агентами под одним долгоживущим продакшн-SLO, быстрее стабилизироваться, перенося тяжёлое исполнение на выделенные удалённые Mac-узлы, а не на вечные одноразовые среды. Балансируя политику роутинга и экономику исполнителей, облачная аренда Mac Mini NodeMini подходит как база: раскладывайте инференс через modelRouting в Gateway, сажайте тяжёлые тулчейны на выделенные узлы, фиксируйте ключи и ёмкость в ранбуках.
modelRouting строит ярусы до апстрим-вызова по оценке контекста для стоимости и задержки; фолбэки обычно реагируют на сбои. Могут сосуществовать — определите границы. Другие материалы OpenClaw — через фильтр категории.
Переиграйте реальные транскрипты с фикстурами в staging, проверьте попадания маршрута, затем канареечный выкат с перцентилями токенов и задержки. При параллельных вычислениях сверяйте ёмкость по странице цен для узлов удалённых Mac-исполнителей.
Те гайды про демоны и экспозицию; эта статья — про роутинг внутри Gateway. Сначала стабилизируйте деплой, затем ужесточайте openclaw.json. Подключение и права — в справочном центре.