От повышения оценок до оплаты: иллюзия спроса Model Fusion

Автор：Yiping \& David，IOSG

I. Что такое Model Fusion?

В июне 2026 года рынок ИИ за менее чем три недели увидел два продукта под названием "Fusion".

12 июня OpenRouter выпустил Fusion Router с заголовком Превосходя границы Производительности с Fusion. В своем глубоком исследовании DRACO модельный набор, состоящий из Fable 5 и GPT-5.5, получил 69.0 баллов, превысив 65.3 балла Fable 5 в одиночном режиме. Основное преимущество, предложенное OpenRouter, было очень простым: когда одиночная модель недостаточно хороша, несколько моделей отвечают на один и тот же вопрос, а затем модель-эксперт сравнивает и обобщает результаты.

29 июня Cognition выпустила Devin Fusion, но заголовок был Производительность на границе с 35% меньшими затратами. Она не заставила несколько моделей повторять выполнение всей задачи, а вместо этого передала планирование и оценку передовым моделям, а тестирование и механические изменения — более дешевым помощникам, динамически переключая модели в процессе выполнения.

Одно и то же слово указывает на две противоположные экономические логики. OpenRouter использует больше вычислений для достижения более высокой границы; Cognition стремится сократить дорогие вычисления, сохраняя при этом прежнее качество. Этот контраст лучше всего иллюстрирует проблему, чем любая таблица моделей. Техническое утверждение о модели слияния действительно имеет смысл: многократные попытки имеют шанс превзойти одну попытку. Но рынок на самом деле не вознаграждает "большее количество вызовов моделей", а тех, кто может потратить меньше денег и быстрее выполнить работу после удовлетворения качественных порогов.

▲ Рисунок 1: В один и тот же месяц, два типа Fusion В этой статье Model Fusion определяется как более узкая архитектура: несколько моделей параллельно отвечают на одну и ту же задачу, модель-эксперт сравнивает результаты, а затем одна модель выдает ответ. Devin Fusion не подпадает под это определение, она ближе к динамической маршрутизации и делегированию задач. Причина, по которой она упоминается в начале, заключается в том, что рынок рассматривает "Fusion" как общее название для всех многомодельных композиций, в то время как действительно эффективные продукты часто удаляются от узкого понимания модели слияния.

Наши оценки скорее пессимистичны: Model Fusion — это дорогая страховка качества. Она может повысить абсолютные показатели для некоторых задач, но редко действительно выдвигает эффективность по затратам — качеству — задержке на передний план. Действительно, задачи, которые стоят того, чтобы купить эту страховку, очень редки. Она останется, но скорее станет функцией с низкой частотой срабатывания, а не стандартной архитектурой и будет труднее стать независимой категорией.

II. Какие варианты моделей существуют на данный момент?

Обсуждение Fusion легко уводит в рейтинги точности, но компании не покупают места в рейтингах. Компании покупают приемлемые результаты для задачи, одновременно учитывая цену, задержку, конфиденциальность и стабильность. Пока дешевые модели уже

пересекли линию приемки бизнеса, продолжать платить за "умнее" может не иметь экономического смысла. Эффективность затрат — это действительно главная линия на рынке моделей.

▲ Рисунок 2: Умные модели и стоимость одной задачи, ось X — логарифмическая шкала На графике наиболее примечательным является не самая высокая оценка в правом верхнем углу, а точки, отклоняющиеся от тренда цены — способности: они предлагают достаточную способность по более низкой цене и являются аномалиями по эффективности для конкретных рабочих нагрузок. Комплексный индекс не может напрямую ответить на вопрос, какая модель лучше всего подходит для проверки кода, исследования на китайском языке или развертывания под контролем, но он указывает на направление: предложение моделей становится товарным, "самая сильная модель" отделяется от "оптимального выбора".

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

Первый способ — это прямое обновление до более сильной одиночной модели. Это самый простой и самый легкий для аудита вариант; если предельная цена высококачественной модели ниже стоимости ошибок или переделок, это обычно остается первым выбором. Второй способ — это увеличение вычислений при тестировании на одной и той же модели, например, увеличение времени вывода, самосогласованности или многократного выборки. Третий способ — это маршрутизация, каскадирование и делегирование задач: сначала использовать дешевую модель для обработки проверяемых или механических частей, только при возникновении трудностей переходить на более дорогую. Четвертый способ — это узкое понимание Model Fusion: позволить нескольким моделям повторно отвечать на один и тот же вопрос, а затем модель-эксперт и обобщающая модель формируют окончательный ответ.

Все четыре способа могут "обменять больше вычислений на качество", различие заключается в том, где тратятся вычисления. Одиночная модель расширяет покупку более глубокого вывода, маршрутизация покупает более точное распределение ресурсов, Fusion же покупает больше кандидатных ответов. Первые три метода сосредотачивают бюджет на тех этапах, которые, вероятно, изменят результат; Fusion же сначала платит за повторяющиеся мнения, а затем ставит на то, что модель-эксперт сможет выявить эффективные различия. Кандидатные модели могут превзойти первые три варианта только в том случае, если они предоставляют достаточно независимой информации, и если эксперт может распознать эту информацию.

Маршрутизация уже доказала, что различия в способностях между моделями в первую очередь являются возможностью для планирования. RouteLLM в некоторых тестах снизил затраты более чем в два раза без потери качества; Switchcraft достиг 82.9% точности при снижении затрат на 84%, по расчетам статьи, экономя более 3,600 долларов на миллион запросов. Результаты все еще необходимо воспроизвести на собственном трафике компании, но экономическая логика очень проста: не обязательно собирать несколько моделей на совещание, просто передавайте каждую задачу самой дешевой квалифицированной модели.

Это означает, что рынок сначала будет использовать обновления, маршрутизацию и проверку для решения разницы в качестве; только когда эти методы все еще недостаточны, есть смысл платить за Fusion для получения большего количества кандидатных ответов.

III. Почему повышение баллов не равно ценности?

Потому что Fusion должен одновременно преодолеть три порога: прирост качества должен покрывать новые затраты и задержки, кандидатные модели должны предоставлять независимую информацию, а эксперт также должен стабильно распознавать лучшие ответы. Любое несоответствие делает повышение баллов невозможным для преобразования в производственную ценность. Стоимость вычислений: сколько нужно увеличить бюджет и задержку? Повышение баллов Fusion в первую очередь является определенной вычислительной затратой. OpenRouter параллельно вызывает несколько панельных моделей, а затем модель-эксперт и обобщающая модель генерируют ответ. Все три группы сравнения DRACO повысили баллы: Fable 5 + GPT-5.5 с 65.3 до 69.0; Opus 4.8 самообъединение с 58.8 до 65.5; группа из трех моделей с низкими затратами с 60.3 до 64.7.

Но повышение Opus самообъединения было более значительным, что указывает на то, что выгода может исходить от дополнительного поиска и выборки, а не от взаимодополняемости знаний между моделями. Справедливое сравнение должно учитывать самосогласованность, более длительное размышление и сильную одиночную модель при одинаковом бюджете токенов. Существующие исследования также показывают: многослойные агенты при примерно 20-кратном объеме вычислений могут повысить точность максимум на 7.1 процентных пункта; при одинаковом бюджете debate и Mixture-of-Agents лишь на 1.3 и 2.7 процентных пункта выше самосогласованности, другое исследование с равными токенами вывода показало, что одиночный агент может быть на уровне или даже лучше. Многочисленные "выгоды от сотрудничества" могут исчезнуть после выравнивания вычислительных затрат.

▲ Рисунок 3: Повышение стандартов OpenRouter и стоимость продукта По умолчанию стоимость панели из 3 моделей OpenRouter составляет примерно 4-5 раз больше обычного генерации, скорость медленнее в 2-3 раза, но не раскрывает полные токены, стоимость и задержки для каждой конфигурации DRACO, что делает невозможным оценить, стоит ли повышение на 3.7 балла. В тестах было только 100 чистых текстовых английских задач, и конфигурация Fable завершила только 93 задачи; замена модели-эксперта может переместить абсолютный балл на 10-25 процентных пунктов. Это доказало, что Fusion может повысить баллы, но не доказало, что Fusion улучшает производственный ROI.

Выборочный вызов может лишь размыть затраты. По диапазону, раскрытому OpenRouter, при уровне срабатывания 1% общая стоимость составляет около 1.03-1.04 раз; при 10% — 1.30-1.40 раз; при 25% уже достигает 1.75-2.00 раз.

▲ Рисунок 4: Общая экономичность выборочного вызова Fusion Самые сложные запросы с наибольшей вероятностью активируют Fusion, но система должна ждать самого медленного члена панели, а затем последовательно завершать оценку и генерацию, поэтому задержка концентрируется на самых ценных задачах. Многопоставочные вызовы также увеличивают вероятность сбоев, сложность аудита и раскрытие конфиденциальности. Затраты Fusion не только в цене API, но и в времени ожидания и новых системных рисках. Взаимодополняемость информации: действительно ли несколько моделей предоставляют различную информацию? Ценность Fusion зависит от того, приносят ли кандидатные модели независимую информацию, но разные модели часто разделяют обучающие корпуса, веб-источники и ошибочные предпосылки. В исследовательских задачах это может привести к "отмыванию ссылок": несколько моделей ссылаются на один и тот же источник, но упаковываются как несколько независимых доказательств. Если система не сохраняет происхождение на уровне утверждений и пути поиска, с увеличением числа моделей стоимость API почти линейно возрастает, но разнообразие доказательств не обязательно увеличивается.

Соучредитель и CEO KAIKAKU.AI Йозеф Чен в своей статье 2026 года Когда объединение языковых моделей помогает? исследовал 67 моделей от 21 поставщика. В открытых математических задачах вероятность того, что все модели одновременно ошибаются, составляет 2.3%, но фактически достигла 5.2% — примерно в 2.3 раза больше предсказанной вероятности; уровень совместных неудач при выполнении задач оценки кода и свободного ответа GPQA-Diamond еще больше возрос до 7.9% и 12.7%. Если заменить на 100 задач GPQA-Diamond, примерно 13 задач приведут к тому, что все кандидатные модели ответят неправильно, и голосование, оценка или обобщение не смогут предложить правильный ответ. Разногласия моделей по легким задачам могут увеличить комбинированную ценность, но в самых сложных вопросах, где нужна страховка, они могут ошибиться вместе. Оценка надежности: может ли система распознать и объединить лучшие ответы? Даже если кандидатные ответы взаимодополняемы, ценность все равно зависит от оценки. Когда кандидаты согласованы, эксперт может ошибочно принять связанные ошибки за высокую уверенность; когда кандидаты расходятся, он должен обладать достаточной профессиональной компетенцией, чтобы выбрать правильный. Обобщающая модель также может стереть мнения ключевых меньшинств или переписать реальные разногласия в определенные выводы.

В задачах кода компиляторы, тесты и статический анализ обычно более надежны, чем мнение другой модели; в творческих задачах оценка и обобщение могут легко усреднить различия. Наиболее сильная готовая модель оценки в LitBench согласуется с предпочтениями человеческого творческого письма всего лишь на 73%. Когда задача уже имеет дешевого внешнего проверяющего или "хорошее" само по себе зависит от субъективной оценки, повышение баллов Fusion трудно преобразовать в ценность, за которую можно заплатить.

IV. Кто будет платить за Fusion?

Спрос на Fusion зависит от двух порогов: может ли задача извлечь выгоду из многомодельного подхода и достаточно ли этой выгоды для формирования устойчивого платежа. Первый — это техническая проблема, второй — рыночная проблема. От технической применимости до экономической целесообразности Вероятность исправления ошибки × убытки от одной ошибки, которые можно избежать, должны быть больше новых затрат API, задержки, сложности обслуживания и рисков конфиденциальности.

Базовые баллы не могут ответить на этот вопрос о прибыли и убытках. Fusion может быть целесообразным только в том случае, если стоимость ошибок высока, кандидатные модели предоставляют взаимодополняющие пути поиска, отсутствуют более дешевые внешние проверяющие, а бизнес готов принять дополнительные задержки и риски поставщиков; окончательный результат все еще должен быть подтвержден человеком или внешними доказательствами.

▲ Рисунок 5: От технической применимости до устойчивого спроса Основными задачами, соответствующими этим условиям, являются исследования с высокой добавленной стоимостью и дью-дилидженс, архитектурные и безопасностные проверки, а также "второе мнение" перед необратимыми решениями. Их объединяет неполнота ограничений, высокие затраты на упущение, и другая независимая мысль сама по себе имеет ценность. Напротив, обычный код, приложения для реального времени, рабочие процессы с высоким объемом и низкой маржой, а также задачи, которые могут быть проверены непосредственно тестами или правилами, обычно не требуют Fusion. Регулирующие органы также могут отказаться от многопоставочных панелей из-за требований к границам данных и аудиту. От готовности платить до устойчивого спроса Техническая полезность может привести к высокой готовности платить, но не означает, что спрос можно масштабировать. Чтобы сформировать устойчивый спрос, убытки от ошибок должны быть количественно измеримыми, задачи должны повторяться, в организации должен быть четкий ответственный за бюджет, а Fusion должен постоянно превосходить человеческих экспертов, сильные одиночные модели и внешние проверки. Но бюджеты на дью-дилидженс часто направляются к аналитикам и надежным источникам, бюджеты на безопасность — к профессиональным аудитам, а необратимые решения происходят слишком редко.

Поэтому мы не оптимистично смотрим на компании, которые просто создают многомодельные обертки, по умолчанию запускают панели или рассматривают алгоритмы выбора статических моделей как защитный механизм. Подключение API легко копируется, фиксированные стратегии также быстро теряют эффективность с изменением способностей и цен моделей; если не известно, сколько стоит ошибка и сколько раз Fusion действительно исправил, невозможно установить цену на эту страховку. Скорее всего, ценность поймает сторона, обладающая реальными результатами: шлюзы и платформы агентов, вертикальные приложения, владельцы рабочих процессов, а также продукты для оценки и наблюдаемости. Они знают стоимость ошибок, могут наблюдать результаты и оптимизировать стратегии вызова. На самом деле трудно скопировать не список панелей, а способность определить, когда не вызывать Fusion. Рыночная проверка Открытый рынок еще не достаточно для оценки масштаба спроса на Fusion, но уже видно, как он используется. Perplexity Model Council доступен только для пользователей Max и Enterprise Max, которые платят 200 долларов в месяц, пользователи вручную выбирают три модели для инвестиционных исследований, сложных решений и проверки информации; открытые примеры использования включают интеграцию Model Council в процесс исследования акций через автоматизацию браузера. Hermes Mixture of Agents сделала Fusion виртуальной моделью, которую можно выбрать среди агентов: пользователи могут через /moa обновить только одну сложную задачу или продолжать использовать ее в сложной сессии, предоставляя анализ от нескольких референсных моделей, а затем агрегатор вызывает инструменты и завершает задачи. Позже Hermes снизила частоту по умолчанию, повторно используя мнения предыдущего раунда моделей для контроля затрат. Эти примеры показывают, что реальный спрос на Fusion сосредоточен на исследованиях, отладке, проверке и важных решениях, типичный способ использования — это активное обновление после того, как одиночная модель сталкивается с узким местом, а не автоматизированный процесс с высокой частотой по умолчанию. Существующие доказательства подтверждают наличие такого спроса, но открытая информация все еще недостаточна для оценки, сможет ли он сформировать независимый, масштабируемый рынок.

V. Будущее Fusion

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

Devin Fusion от Cognition демонстрирует направление этой конкуренции: оставить дорогие модели для этапа оценки, а проверяемую, механическую работу передать более дешевым моделям. В самопроверке производителей общий балл Fusion + Fable 5 увеличился с 57.0 до 57.6, средние затраты снизились с 5.12 долларов до 3.00 долларов; но в опубликованных 5 случаях затраты снизились на 25%-62%, а баллы задач колебались между +12 и -27. Четко определенные границы и достаточное тестирование ES6 рефакторинга повысили балл с 98 до 100; в то время как функции React/Redux, зависящие от интерактивного понимания и скрытых требований, упали с 54 до 27 баллов после неправильного делегирования.

▲ Рисунок 6: Баллы задач и затраты Devin Fusion Это примеры, выбранные производителями, и не представляют собой общую распределенность, но указывают на ясное направление: основная способность будущих многомодельных систем не в вызове большего количества моделей, а в определении правильных границ по снижению качества. Проверяемые, механические задачи могут быть переданы дешевым моделям, а задачи, требующие оценки, должны оставаться за передовыми моделями. OpenRouter продает "больше интеллекта", Cognition продает "такой же интеллект, но по более низкой цене"; вторая формулировка ближе к долгосрочному направлению. Чем ближе система к производственной экономике, тем меньше она похожа на узкое понимание Model Fusion и тем больше на маршрутизацию, делегирование и проверку.

В конце июля СМИ сообщили, что Stripe ведет переговоры о покупке OpenRouter за около 10 миллиардов долларов, сделка еще не подтверждена. Этот сигнал не следует интерпретировать как то, что Fusion уже получил рыночную проверку: основная ценность OpenRouter заключается не в какой-либо панели, а в нейтральном уровне вызова, соединяющем более 5 миллионов разработчиков и более 400 моделей. Stripe уже предоставляет OpenRouter услуги по выставлению счетов, налогам и управлению рисками, а также позволяет разработчикам напрямую создавать учетные записи, получать API-ключи и подключать платежи через Stripe Projects. На самом деле Stripe может купить вход в сделки по ИИ-вычислениям: OpenRouter контролирует выбор моделей, использование токенов и затраты, а Stripe обрабатывает ценообразование, счета и платежи. Это предоставляет рыночный сигнал для ранее упомянутой оценки ценности: ценность многомодельной эпохи скорее останется у тех, кто может наблюдать задачи, распределять вызовы и завершать расчеты, Fusion — это всего лишь одна из высокозатратных стратегий обновления.

Будущие многомодельные системы не будут по умолчанию собирать панели, а сначала оценят сложность задачи, затраты на проверку и убытки от ошибок; только когда более сильные одиночные модели, продление вывода и внешние инструменты все еще недостаточны, они перейдут к поиску разногласий между моделями. Частота срабатывания, прирост успешности и проверенные единичные затраты на результаты будут значимыми показателями продукта. Fusion останется как функция с низкой частотой, а не станет стандартной архитектурой или независимой категорией.

VI. Источники

• OpenRouter: Превосходя границы производительности с Fusion

• Документация OpenRouter Fusion Router

• Cognition: Devin Fusion — Производительность на границе с 35% меньшими затратами

• Microsoft Research: Switchcraft — AI Model Router для вызова инструментов

• Когда объединение языковых моделей помогает?

• Многослойное рассуждение улучшает эффективность вычислений

• Одиночные агенты LLM превосходят многослойные системы в многопроходном рассуждении при равных бюджетах токенов

• Mixture-of-Agents улучшает возможности больших языковых моделей

• RouteLLM: Обучение маршрутизации LLM с использованием данных предпочтений

• LitBench: Эталон для оценки творческого письма

• Сравнение моделей искусственного анализа

• Цена прогресса: ценовая производительность и будущее ИИ

• Perplexity: Что такое Model Council?

• Пример пользователя Perplexity: Model Council для финансовых исследований

• Hermes Agent: документация Mixture of Agents

• Stripe поддерживает глобальный доступ OpenRouter к моделям ИИ

• Axios: Что стоит за сообщением о сделке Stripe с OpenRouter