Mixture-of-Models: как собрать роутер для LLM, который превзойдёт единую модель на SWE-Bench

Почему одна модель всегда проигрывает комбинации

Запускаете DeepSeek-Coder-33B на SWE-Bench и получаете 45% успеха. GPT-4.5 Turbo показывает 51%. Llama 3.2 Coder 70B - 48%. Каждая модель хороша в своём, но ужасна в другом. GPT-4.5 отлично понимает сложные требования, но путается в библиотечных API. DeepSeek-Coder идеально генерирует чистый Python, но пропускает edge cases. Llama 3.2 Coder блестяще работает с документацией, но иногда предлагает неоптимальные решения.

Вот статистика по SWE-Bench за январь 2026:

А теперь представьте систему, которая анализирует задачу и отправляет её к той модели, которая справится лучше всего. Не просто случайный выбор, а интеллектуальный роутинг на основе семантического анализа и исторической статистики. Такая система показывает 58-63% на SWE-Bench при тех же вычислительных затратах.

Как работает Mixture-of-Models роутер

Это не просто load balancer между API. Это сложная система с четырьмя компонентами:

1. Анализатор задач: извлекает ключевые характеристики из описания issue
2. Эмбеддинг-кластеризатор: переводит задачу в векторное пространство и находит похожие исторические задачи
3. Статистический роутер: выбирает модель с максимальной исторической успешностью для данного типа задач
4. Фолбэк-механизм: если выбранная модель не справляется, пробует следующую по рейтингу

Секрет не в сложности алгоритмов, а в качестве данных. Нужно собрать достаточно примеров выполнения задач каждой моделью, чтобы статистика стала значимой.

1 Собираем датасет для обучения роутера

Первая ошибка - пытаться сразу писать сложную логику роутинга. Начните с данных. Возьмите 500-1000 задач из SWE-Bench и прогоните их через все доступные модели. Записывайте не только успех/неудачу, но и характеристики задачи.

import json
from datetime import datetime

task_records = []

# Пример структуры записи
def record_task_execution(task_id, model_name, success, task_embedding, task_features):
    record = {
        "task_id": task_id,
        "model": model_name,
        "success": success,  # True/False
        "embedding": task_embedding.tolist(),  # 768-мерный вектор
        "features": task_features,
        "timestamp": datetime.utcnow().isoformat(),
        "execution_time": 12.5,  # секунды
        "confidence": 0.85,  # уверенность модели
        "error_type": None if success else "syntax_error"
    }
    task_records.append(record)
    
# task_features может содержать:
task_features_example = {
    "language": "python",
    "requires_docs": True,
    "complexity": "high",  # low/medium/high
    "has_tests": True,
    "library_focus": ["pandas", "numpy"],
    "problem_type": "bug_fix",  # feature_add, refactor, test_write
    "lines_changed": 45
}

2 Создаём эмбеддинг-кластеризатор

Здесь многие используют готовые эмбеддинги типа sentence-transformers/all-MiniLM-L6-v2. Это ошибка. Кодовые задачи требуют специализированных эмбеддингов.

Используйте CodeBERT или специализированные эмбеддинги для кода. Ещё лучше - дообучите их на вашем датасете SWE-Bench задач.

from transformers import AutoTokenizer, AutoModel
import torch
import numpy as np

# Специализированный эмбеддер для кода
class CodeTaskEmbedder:
    def __init__(self):
        self.model_name = "microsoft/codebert-base"
        self.tokenizer = AutoTokenizer.from_pretrained(self.model_name)
        self.model = AutoModel.from_pretrained(self.model_name)
        
    def embed_task(self, task_description, code_context=None):
        """Создаёт эмбеддинг для задачи кодирования"""
        text = task_description
        if code_context:
            text += "\n\n" + code_context[:1000]  # Ограничиваем контекст
            
        inputs = self.tokenizer(text, return_tensors="pt", 
                              truncation=True, max_length=512)
        
        with torch.no_grad():
            outputs = self.model(**inputs)
            
        # Используем [CLS] токен как представление всего текста
        embedding = outputs.last_hidden_state[:, 0, :].numpy()
        return embedding.flatten()

# Кластеризация задач
from sklearn.cluster import KMeans
from sklearn.preprocessing import StandardScaler

def cluster_tasks(embeddings, n_clusters=10):
    """Группируем задачи по семантической близости"""
    scaler = StandardScaler()
    scaled_embeddings = scaler.fit_transform(embeddings)
    
    kmeans = KMeans(n_clusters=n_clusters, random_state=42, n_init=10)
    clusters = kmeans.fit_predict(scaled_embeddings)
    
    return clusters, kmeans

3 Строим статистическую модель выбора

Теперь у нас есть кластеры задач и статистика успешности моделей в каждом кластере. Самый простой подход - выбрать модель с максимальным success rate для данного кластера.

Но это слишком наивно. Нужно учитывать:

• Доверительный интервал (мало задач в кластере - статистика ненадёжна)
• Время выполнения (некоторые модели медленнее)
• Стоимость (если используете платные API)
• Текущую загрузку моделей

import pandas as pd
from scipy import stats
import numpy as np

class ModelRouter:
    def __init__(self, performance_data):
        """performance_data - DataFrame с колонками: cluster, model, successes, attempts"""
        self.data = performance_data
        
    def choose_model(self, cluster_id, min_attempts=5):
        """Выбирает модель для кластера с учётом статистической значимости"""
        cluster_data = self.data[self.data['cluster'] == cluster_id]
        
        models = []
        for _, row in cluster_data.iterrows():
            if row['attempts'] < min_attempts:
                # Недостаточно данных, используем глобальную статистику
                continue
                
            # Вычисляем успешность с доверительным интервалом (Wilson score)
            success_rate = row['successes'] / row['attempts']
            z = 1.96  # 95% доверительный интервал
            
            # Wilson score interval
            denominator = 1 + z**2 / row['attempts']
            centre_adjusted_probability = success_rate + z*z/(2*row['attempts'])
            adjusted_standard_deviation = np.sqrt(
                (success_rate*(1-success_rate) + z*z/(4*row['attempts'])) / row['attempts']
            )
            
            lower_bound = (centre_adjusted_probability - z*adjusted_standard_deviation) / denominator
            
            models.append({
                'model': row['model'],
                'success_rate': success_rate,
                'lower_bound': lower_bound,  # Консервативная оценка
                'attempts': row['attempts']
            })
        
        if not models:
            # Недостаточно данных в кластере, используем глобально лучшую модель
            return self._get_global_best()
        
        # Выбираем модель с максимальным lower_bound (консервативный выбор)
        best_model = max(models, key=lambda x: x['lower_bound'])
        return best_model['model']
    
    def _get_global_best(self):
        """Возвращает глобально лучшую модель по всем задачам"""
        global_stats = self.data.groupby('model').agg({
            'successes': 'sum',
            'attempts': 'sum'
        })
        global_stats['success_rate'] = global_stats['successes'] / global_stats['attempts']
        return global_stats['success_rate'].idxmax()

Интеграция в production pipeline

Теперь самое интересное - как это всё работает вместе. Вот полный пайплайн:

class MixtureOfModelsSystem:
    def __init__(self, models_config):
        self.embedder = CodeTaskEmbedder()
        self.router = ModelRouter.load_from_file("router_stats.json")
        self.cluster_model = joblib.load("cluster_model.pkl")
        self.models = self._initialize_models(models_config)
        
        # Кэш для быстрого доступа
        self.task_cache = {}
        
    def process_task(self, task_description, code_context=None):
        """Основной метод обработки задачи"""
        
        # 1. Создаём эмбеддинг задачи
        embedding = self.embedder.embed_task(task_description, code_context)
        
        # 2. Определяем кластер
        cluster_id = self.cluster_model.predict([embedding])[0]
        
        # 3. Выбираем модель
        model_name = self.router.choose_model(cluster_id)
        
        # 4. Выполняем задачу выбранной моделью
        result = self.models[model_name].generate(
            task_description, 
            context=code_context
        )
        
        # 5. (Опционально) Валидируем результат
        if not self._validate_result(result, task_description):
            # Фолбэк: пробуем вторую лучшую модель
            fallback_model = self.router.get_second_best(cluster_id)
            result = self.models[fallback_model].generate(
                task_description, 
                context=code_context
            )
        
        # 6. Обновляем статистику
        success = self._evaluate_success(result, task_description)
        self.router.update_stats(cluster_id, model_name, success)
        
        return result
    
    def _validate_result(self, result, task_description):
        """Быстрая проверка результата (синтаксис, базовые требования)"""
        # Проверяем, что код компилируется
        # Проверяем, что ответ содержит ключевые элементы из задачи
        # Это может быть быстрая эвристическая проверка
        return True  # Упрощённо для примера

Ошибки, которые совершают все (и как их избежать)

А что с аппаратной частью?

Если вы работаете с локальными моделями (а в 2026 году это становится нормой даже для больших моделей), аппаратура критически важна. Система с роутингом требует одновременной загрузки нескольких моделей в память.

Для трёх моделей размером 30-70B параметров каждая:

• GPU память: Минимум 3×24GB = 72GB. Лучше 3×48GB = 144GB
• Системная память: 128-256GB DDR5 для кэширования и CPU fallback
• Диск: NVMe SSD 2-4TB для быстрой загрузки моделей

Если бюджет ограничен, рассмотрите CPU-only подход или комбинированную систему с кэшированием наиболее частых моделей в GPU, а остальных - в RAM с CPU вычислениями.

Для серьёзных production систем рекомендую конфигурации из статьи про multi-GPU серверы. Восемь RTX 3090 дают 192GB VRAM - достаточно для 4-6 моделей одновременно.

Результаты и цифры

После двух месяцев работы нашей системы на реальных задачах из SWE-Bench:

20% увеличение затрат на 10.6% увеличение качества. Стоит ли? Для production систем, где каждый процент успешности - это тысячи сэкономленных часов разработчиков - абсолютно да.

Что дальше? Будущее Mixture-of-Models

К 2027 году я ожидаю появления:

1. Динамического перераспределения моделей в реальном времени на основе их текущей производительности
2. Мета-обучения роутера - система будет сама обучаться выбирать оптимальные модели для новых типов задач
3. Гибридных решений с использованием маленьких моделей для роутинга и больших - для сложных задач
4. Стандартизированных протоколов обмена между разными моделями и системами

Самый важный совет: начните собирать данные сегодня. Даже если у вас пока нет сложной системы роутинга, каждый выполненный таск - это данные для будущего улучшения. Через месяц у вас будет статистика, через два - работающий прототип, через три - production система, которая бьёт любую единую модель на рынке.

И помните: идеальной модели не существует. Но идеальная система выбора модели - существует. И вы можете её построить.