GitHub направи Copilot Fusion общодостъпен, премествайки многомоделното маршрутизиране от проблем на инфраструктурата в ежедневния работен процес на кодиране. Вместо да изисква разработчик да избере един фиксиран модел, Fusion може да избере и организира един или повече модели за заявка.
Изданието има значение извън GitHub Copilot. Той демонстрира как потребителят може да изпрати една задача, докато услугата взема няколко основни моделни решения, потенциално генерирайки няколко отделно таксувани обаждания. Това променя това, което разработчиците, администраторите и системите за таксуване трябва да знаят за дадена заявка: моделът, показан в интерфейса, вече не е непременно пълно описание на това как е извършена работата.
Fusion може да избира, каскада или критика
GitHub документира три модела на изпълнение за Fusion. Една заявка може да отиде до един избран модел, да премине през каскада от модели или да използва един модел, за да критикува изхода на друг модел. Потребителите могат също така да избират стандартни, високи или максимални нива на усилие, което им дава известен контрол върху това колко оркестрация се прилага.
Това е значителна продуктова промяна, тъй като маршрутизирането става част от изживяването на крайния потребител, а не невидима оптимизация зад доставчик API. мултимоделен API шлюз за екипи може да извърши подобен избор на приложния слой, но Fusion поставя решението в основна среда за разработка и излага контрол на усилията директно на разработчика.
Подходът може да намали необходимостта потребителите да разбират силните страни на всеки наличен модел. Освен това създава нов диагностичен проблем. Когато даден отговор е бавен, скъп или неправилен, екипите трябва да знаят дали резултатът идва от един модел, каскада или критично преминаване, включващо няколко модела.
Една заявка може да доведе до няколко такси
GitHub казва, че всеки модел, използван от Fusion, се таксува по стандартната тарифа на този модел. Той също така обяви временна отстъпка от 30% върху разходите за модел Fusion за платени планове, въпреки че прегледаното съобщение не уточнява кога тази отстъпка ще приключи.
Този дизайн на фактуриране прави проследяването на изпълнението важно от търговска гледна точка. Едно действие на разработчика може да изразходва повече ресурси, отколкото директно извикване на един модел, дори когато оркестрацията води до по-добър резултат. Следователно екипите, които оценяват Fusion, ще трябва да сравнят разходите за изпълнена задача за кодиране, а не само посочената цена на токена на първия участващ модел.
Същият проблем се отнася за унифицирано AI API таксуване. Записите за използване трябва да идентифицират всяко основно повикване на модела, като същевременно запазват връзката с оригиналната потребителска заявка. Без тази връзка администраторите може да виждат моделни такси, но се затрудняват да обяснят коя задача ги е генерирала или дали настройката за усилие е увеличила разходите.
Правилата на предприятието все още оформят маршрута
Администраторите на предприятия и организации могат да ограничат кои модели Fusion може да използва чрез GitHub съществуващите политики за модели. Това дава на компаниите начин да изключат модели, които не отговарят на вътрешни изисквания, но също така означава, че една и съща заявка на Fusion може да бъде маршрутизирана по различен начин в различните организации.
За инженерните лидери политиката за модела и бюджетната политика вече трябва да се разглеждат заедно. Разрешаването на скъп модел в каталога може да позволи на Fusion да го извика като част от последователност от множество модели, не само когато разработчикът го избере изрично. Практическите AI API контроли на разходите за екипи следователно трябва да отчитат дълбочината на оркестрация, нивото на усилията и общата цена на всички обаждания, свързани с дадена задача.
Операторите на шлюз са изправени пред свързано изискване за докладване. Регистрационните файлове трябва да разграничават модела или режима, поискани от потребителя, от всеки модел, който действително е обслужил заявката. Това разграничение поддържа приписване на разходите, разследване на инциденти и възпроизводими оценки, когато поведението на маршрутизиране се променя с течение на времето.
Локалното маршрутизиране не елиминира облачните въпроси
GitHub също така въведе експериментален предварителен преглед, който може да маршрутизира между отговарящи на условията локални и облачни модели. Локалният извод може да предостави друга опция за цена, латентност или обработка на данни, но думата „локален“ сама по себе си не описва пълния път на обработка. Екипите все още се нуждаят от яснота относно това кои решения за маршрутизиране, подкани, метаданни или извиквания на последващ модел остават в облачните услуги на GitHub.
Няколко подробности остават неуредени. GitHub не е посочил продължителността на отстъпката от 30% и публикуваните сравнения на разходите и производителността с Claude кода зависят от конкретна конфигурация за сравнение. Тези резултати не трябва да се третират като универсални оценки за всяко хранилище или работно натоварване.
Трайната промяна е архитектурна: оркестрацията на модела се превръща в стандартна характеристика на инструментите за разработчици. Когато това се случи, прозрачните записи за маршрутизиране, изборът на модел, съобразен с политиката, и отчитането на разходите на ниво задача стават необходими части от продукта, а не незадължителни функции за наблюдение.