Skip to content

ADR 002: Dynamic Model Routing 2.0 (Capability-Aware Routing Matrix)

Дата: 2026-04-21
Статус: Принято
Автор: Black Swan Core Architecture Team

1. Контекст

До версии 0.6 распределение задач между узлами роя было полностью статическим. Core Node выполнял все сложные задачи (стратегия, Architectus), а Edge-узлы — только рутинные (Vagrant). Это приводило к трём фундаментальным проблемам:

  1. Ресурсный дисбаланс. Core Node часто простаивал в ожидании задач, в то время как арендованные Edge-узлы не могли справиться с нестандартными запросами из-за нехватки экспертов.
  2. Отсутствие учёта вида. Задачи Arbtiragius (трейдинг) и Sentinella (безопасность) отправлялись на те же узлы, что и Architectus, хотя их требования к латентности и экспертизе кардинально различаются.
  3. Неоптимальность затрат. Система не могла динамически выбирать между локальным инференсом, арендой GPU через EIF или вызовом API на основе текущей стоимости и задержки.

С переходом на DeepSeek‑V4 и видовые маски (ADR‑001) появилась возможность тонко настраивать процент активируемых экспертов под каждую задачу. Однако механизм, принимающий это решение, отсутствовал.

2. Решение

Реализовать Dynamic Model Routing 2.0 — Capability-Aware Routing Matrix. Это сервис (DynamicModelRouter, Rust), который для каждой входящей задачи в реальном времени выбирает оптимальную конфигурацию исполнения по четырём осям:

  • Целевой узел: Core Node, Regional Aggregator, или Edge Node.
  • Видовая маска: Architectus, Arbtiragius, Sentinella, Vagrant.
  • Процент активируемых экспертов: 20–60%.
  • Параметры инференса: квантизация (AWQ 4‑bit, INT4), число спекулятивных токенов (P-EAGLE).

Решение принимается на основе матрицы маршрутизации, хранящейся как CRDT-объект в GlobalState.infrastructure_state. Каждая запись матрицы связывает сигнатуру задачи (тип, сложность, срочность, длина контекста) с рекомендованной конфигурацией и историческими метриками.

Оптимизация производится по трёхцелевому Pareto-фронту (Quality, Latency, Cost/Energy), а в критических ситуациях — с добавлением четвёртой оси Strategic Risk (вероятность раскрытия).

Матрица самообучается: 10% задач направляются по экспериментальным маршрутам. L0 Meta-Analyzer анализирует результаты и обновляет веса Pareto и записи матрицы. Удачные экспериментальные маршруты промоутятся через Decision Pipeline.

3. Последствия

Положительные

  • Экономия GPU-часов на 15–25% за счёт точного подбора конфигурации.
  • Снижение задержки Fast Path. Для задач PPO-трейдинга роутер использует предварительно прогретый кэш, обеспечивая p95 < 5 мс на принятие решения о маршруте.
  • Автономная оптимизация. Система больше не требует ручной настройки балансировки нагрузки.
  • Учёт скрытности. Добавление оси Strategic Risk в Pareto-оптимизацию позволяет избегать узлов с высоким риском раскрытия.

Отрицательные

  • Увеличение сложности. Роутер — новый критический компонент. Его отказ (confidence < 0.75) вызывает fallback на статическую политику, которая может быть неоптимальной.
  • Зависимость от L0. Качество маршрутизации напрямую зависит от регулярного анализа L0 Meta-Analyzer. В первые дни после активации матрица неоптимальна.
  • Риск пере‑оптимизации. Без должной калибровки роутер может излишне агрессивно экономить ресурсы в ущерб качеству. Защита: L0-инвариант routing_coherence ≥ 0.88.

Нейтральные

  • Необходимость во внедрении RoutingDecisionArtifact в EventBus для аудита.

4. Связь с другими документами