GitHub Copilot внедряет локальный ИИ для программирования на новых ПК с Windows

При работе с агентами разработчикам необходимы как свобода выбора, так и контроль. Им нужны технологии, которые обеспечивают четкие границы для их агентов и позволяют легко выбирать модель с оптимальным балансом скорости, производительности и стоимости для каждой задачи. Именно поэтому GitHub предлагает пограничные модели от основных провайдеров, а также такие варианты, как Project HydraFusion — оркестратор, выбирающий одну или несколько моделей для каждой задачи с учетом производительности, стоимости и задержки. По этой же причине в Windows разработали Microsoft Execution Containers (MXC) для повышения безопасности интерактивных и неинтерактивных сеансов программирования с помощью агентов.

К концу месяца в GitHub Copilot появится функция определения того, когда задачу лучше решать с помощью локального интеллекта, а когда — задействовать облачные модели масштабного уровня. Вместо того чтобы заставлять разработчиков самостоятельно принимать инфраструктурные решения, GitHub Copilot автоматически координирует локальный и облачный вывод в фоновом режиме. Для ПК под управлением Windows с NVIDIA RTX Spark, таких как Surface Laptop Ultra, это означает запуск локального программирования в GitHub Copilot с использованием мощных локальных моделей вывода и аппаратного обеспечения, способного обеспечить превосходный уровень взаимодействия на периферии (edge).

В результате этот шаг станет следующим этапом в реализации концепции HydraFusion: интеллектуальной оркестрации, охватывающей не только несколько моделей, но и различные вычислительные среды, включая периферийные устройства. GitHub Copilot может выполнять команды в этих средах с контролируемым доступом к файлам, сети, системным возможностям и учетным данным. Разработчики могут автоматизировать процессы с уверенностью в безопасности.

Почему память важна для локального агента программирования

Локальный вывод начинается с ограничения по памяти. Surface Laptop Ultra создан на базе NVIDIA RTX Spark с объемом унифицированной памяти до 128 ГБ и производительностью ИИ до 1 петафлоп.

При использовании дискретного GPU выделенная видеопамять становится важным ограничением: перемещение данных модели между системной памятью и GPU может создавать дополнительные накладные расходы. Унифицированная память предоставляет процессору и видеокарте доступ к общему физическому пулу. Это делает больший объем доступным для рабочей нагрузки, но не означает, что весь он доступен для весов модели.

Операционной системе, вашим приложениям и среде выполнения выводов тоже нужна память. Это же относится к кэшу ключей-значений (key-value cache), который хранит состояние внимания для токенов, уже обработанных моделью. По мере того как агент читает файлы и получает результаты работы инструментов, его контекст может увеличиваться, что ведет к росту потребления памяти и объема работы, необходимой для обработки следующего запроса.

Удержание модели загруженной между запросами позволяет избежать повторных затрат на ее загрузку. Тем не менее, это не гарантирует постоянного времени отклика: длина контекста, нагрузка на память и остальная часть рабочей нагрузки по-прежнему имеют значение. Именно поэтому полезно задаваться вопросом не только о том, помещается ли модель в память, но и о том, как она ведет себя при выполнении полной задачи программирования.

Представляем MAI Code 1.1 Flash для локального программирования

Чтобы воплотить в жизнь этот опыт локальной разработки, в Microsoft AI создали локальную версию MAI Code 1.1 Flash — оптимизированной для написания кода модели типа «мои эксперты» (mixture-of-experts) с общим количеством параметров 137 миллиардов и 6,8 миллиарда активных параметров. Локальная обработка использует квантование и спекулятивное дешифрование (спекулятивный вывод) для уменьшения размера модели и повышения общей оперативности отклика при сохранении качества выполнения задач и использования инструментов, столь важных в цикле работы агента.

Квантование снижает точность представления весов и активаций модели, уменьшая требования к памяти. Поскольку код не прощает ошибок, оценка при релизе должна измерять как успешность выполнения задач программирования, так и занимаемый объем: один некорректный токен может привести к синтаксической ошибке, неверному идентификатору, неправильному вызову инструмента или испорченному диффу (diff).

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

Для агента программирования важнейшим компромиссом является способность меньшей модели выполнять те же задачи. Меньший размер имеет смысл только тогда, когда изменения в качестве кода и использования инструментов предсказуемы и понятны.

В нашей первой поставляемой версии MAI Code 1.1 Flash на Surface Laptop Ultra мы достигаем следующей производительности при разной длине контекста, причем пиковое использование памяти составляет 75,5 ГБ при контексте 256 тыс. токенов. При контексте 64 тыс. и 128 тыс. токенов пропускная способность обработки промптов достигает 923,5 и 769,8 токенов в секунду соответственно.

Используемая нами на устройстве квантованная версия MAI Code 1.1 Flash демонстрирует впечатляющее сохранение возможностей по сравнению с облачным вариантом Bfloat16, занимая 53 ГБ, что на 80% меньше исходного размера.

Протестировано 5 октября 2026 года с использованием MAI Code 1.1 Flash (квантование со смешанной точностью, примерно 3,3 бита на вес) со спекулятивным декодированием на основе скользящего окна DFlash2 и средой выполнения llama.cpp CUDA для Windows ARM64. Результаты отражают пропускную способность декодирования для синтетической рабочей нагрузки по генерации кода; фактические результаты могут отличаться в зависимости от устройства, конфигурации и других факторов.

Два способа использования локальных моделей в GitHub Copilot

В GitHub Copilot добавляются два способа использования локальных моделей в интерфейсе командной строки (CLI) GitHub Copilot, приложении Copilot и VS Code. Разработчики могут позволить интеллектуальной оркестрации Auto в Copilot самостоятельно решать, когда использовать локальный или облачный вывод, либо явно выбрать локальную модель для рабочих процессов, требующих прямого контроля.

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

Этот оркестрированный подход дополняет прямой выбор модели, предоставляя разработчикам выбор: позволить Copilot оптимизировать размещение моделей или самостоятельно выбрать конкретную локальную модель.

Явный выбор локальной модели поддерживает рабочие процессы, требующие определенного провайдера, модели или конечной точки. Разработчики могут выбрать MAI Code 1.1 Flash через провайдер Windows ML или подключить GitHub Copilot к локальным конечным точкам, совместимым с OpenAI, и выбирать из моделей, предоставляемых этими конечными точками.

Как песочницы помогают защитить выполнение инструментов

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

GitHub Copilot использует Microsoft Execution Containers (или MXC) — библиотеку с открытым исходным кодом от команды Windows, которая преобразует политику в нативные элементы управления операционной системы. В Windows GitHub Copilot использует уровень BaseContainer бэкенда ProcessContainer. В macOS используется Seatbelt. В Linux используется bubblewrap. Эти локальные бэкенды не требуют отдельной виртуальной или контейнерной машины, но в будущем мы планируем сделать их доступными в качестве опций через MXC.

Когда изолированная среда (песочница) включена, команды оболочки и, по умолчанию, локальные серверы Model Context Protocol и языковые серверы выполняются внутри границ процесса. Встроенные файловые инструменты работают внутри самого GitHub Copilot: среда агента проверяет их запросы на соответствие действующей политике, но эти проверки не являются изоляцией дочернего процесса на уровне ОС. Удаленные серверы MCP также находятся за пределами локальной песочницы процесса; когда применяются элементы управления песочницей MCP, GitHub Copilot проверяет политику их подключения в рамках процесса.

Открытие интерфейса командной строки GitHub Copilot и выполнение слэш-команды `/sandbox` позволяет в любой момент настроить параметры.

Пример из реального мира: Ежедневная панель управления репозиториями

Чтобы показать, как эти технологии работают вместе, давайте рассмотрим реальный пример.

Представьте себе задачу, которая каждое утро считывает локальные репозитории, запускает их тесты в рабочих копиях и создает один HTML-отчет. Исходные репозитории должны оставаться доступными только для чтения, а тестовые процессы не должны иметь доступа к сети. Выбор модели не зависит от этого: для той же задачи можно использовать настроенную локальную или облачную модель.

Включение песочницы для вашего проекта

Откройте диалоговое окно настроек, щелкнув значок шестеренки в приложении GitHub Copilot и выбрав свой проект в левом меню. В этом примере мы будем использовать репозиторий `copilot-sdk`, в котором размещается наш проект с открытым исходным кодом GitHub Copilot Runtime/SDK.

Включение переключателя `Sandbox new sessions` автоматически активирует песочницу всякий раз, когда вы работаете в рамках этого проекта. По умолчанию его текущая рабочая директория доступна для чтения и записи, в то время как остальная часть системы остается преимущественно доступной только для чтения или недоступной для агента.

Создание новой автоматизации

Выберите раздел `Automations` в левой навигационной панели и нажмите кнопку `Start automation`, чтобы открыть диалоговое окно, позволяющее настроить новую автоматизацию.

Установив понятное название и время срабатывания ежедневно в 9:00 утра, вставьте базовые инструкции, которые помогут агенту создать ежедневную панель управления для сортировки задач.

Создайте сегодняшнюю общедоступную панель мониторинга сортировки для github/copilot-sdk, используя только метаданные проблем и запросов на включение (PR) GitHub (без локальных репозиториев, кода, тестов или внешних ссылок), обобщая открытые/закрытые/объединенные элементы, недавно обновленную работу, устаревшие элементы, метки, авторов, исполнителей и возраст; сгенерируйте .\dashboard\index.html со встроенными CSS и SVG, добавьте сегодняшние результаты в .\history.json максимум для семи дат и завершите работу ровно тремя строками: путь к отчету, сбои, а также пропущенная или недоступная работа.

Выбор новой локальной модели MAI Code 1.1 Flash и репозитория `copilot-sdk`, для которого мы активировали песочницу, позволяет агенту работать автономно со средствами защиты, которые помогают снизить риск непреднамеренных изменений на вашем локальном компьютере, и в то же время позволяет вашему агенту генерировать и запускать скрипты в своем текущем рабочем каталоге для сортировки и создания интерактивной панели мониторинга.

После сохранения нажатие кнопки `Run it now` сразу же запускает выполнение новой автоматизации для проверки.

Проверка результата

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

Заключение

Это только начало нашего пути. Локальные модели и инструменты в песочнице внедряются прямо сейчас, чтобы предоставить разработчикам больше выбора в отношении того, где запускается интеллект, и более четкий контроль над тем, что могут делать агенты. Начните работу с локальной разработкой с помощью GitHub Copilot.

Благодарности

PM: Ryan Hecht, Tucker Burns, Lei Xu, Pierce Boggan, Nhu Do, Greg Woo, Ramya Krishna Akula, Demetrius Nelon, Harald Kirschner

Engineering: Andrew Feller, Devraj Mehta, Mackinnon Buck, Roman Bulanenko, Chris Dern, Daniel Pagan, Keith Mahoney, Vicente Rivera, Austin Hodges, Anis Mohammed Khaja Mohideen, Stuart Schaefer, Sha Viswanathan, Carlos Alexandro Becker, Logan Ramos

Science: Ani Balasubramaniam, Shengyu Fu, Aashna Garg, Aakash Goel, Karthik Vijayan, Jennifer Zhu, Vivek Pradeep

Marketing: Katie Liu, Alyanna Castillo

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