Microsoft a documentat pe 5 noiembrie o configurație prin care GitHub Copilot poate folosi Qwen3.8-27B cu inferență pe calculatorul dezvoltatorului. Modelul rulează prin Foundry Local pe un GPU NVIDIA, iar aplicația GitHub Copilot trimite cererile către serviciul local configurat drept furnizor. Pentru această variantă a modelului, Microsoft indică un fișier cuantizat la patru biți de aproximativ 18 GB și recomandă cel puțin 24 GB de memorie video în configurația descrisă.
Cum ajunge o cerere din Copilot la modelul local
Foundry Local este motorul care descarcă, încarcă și execută modelul. În exemplul Microsoft, acesta pornește un serviciu cu o adresă API pe calculatorul utilizatorului. Aplicația GitHub Copilot permite adăugarea unui furnizor de modele prin opțiunea Bring Your Own Key, abreviată BYOK. După ce este configurată adresa returnată de Foundry Local, Qwen3.8-27B poate fi ales din selectorul de modele al aplicației. Adresa depinde de instanța care rulează pe calculatorul respectiv.
Aplicația Copilot gestionează conversația și interacțiunile cu instrumentele de programare. Foundry Local preia cererea de inferență, iar GPU-ul generează răspunsul modelului. Într-un flux de lucru cu un depozit de cod, cererile pot include fișiere selectate, descrierea unei modificări și rezultatele testelor. Modelul primește contextul pe care îl transmite clientul. Permisiunile pentru fișiere, terminal și alte instrumente rămân la nivelul aplicației și al mediului în care lucrează echipa.
Ruta locală privește generarea făcută de model după instalare și încărcare. Prima descărcare a fișierelor este o operațiune separată. Autentificarea în aplicație, sincronizarea depozitului și folosirea extensiilor au propriile conexiuni și reguli. Pentru o echipă care lucrează cu un proiect privat, diferența este operațională. Destinația cererii către model poate fi identificată în configurarea furnizorului, iar traseul fișierelor folosite de celelalte instrumente se stabilește separat.
Ce poate încărca un GPU cu 24 GB sau 32 GB de VRAM
Qwen3.8-27B este un model dens din familia Qwen, cu 27 de miliarde de parametri. Fișa autorilor listează ponderile publice sub licența Apache 2.0. Microsoft a ales acest model pentru optimizarea fluxului de programare locală și descrie o variantă la patru biți. Cuantizarea reduce spațiul ocupat de ponderi. În timpul inferenței, memoria disponibilă este folosită și pentru context, date de lucru ale motorului și rezultatele generate în sesiune.
Conform Microsoft, pe un GPU NVIDIA cu 24 GB de VRAM configurația descrisă poate folosi un context de până la 64K de tokenuri. Cu 32 GB sau mai mult, compania indică posibilitatea de a ajunge la limita modelului, aproximativ 262.000 de tokenuri. Aici contextul măsoară unitățile de text disponibile pentru instrucțiuni, cod, istoricul conversației și continuarea ei. Contează și felul în care aplicația selectează fișierele pe care le introduce efectiv în cerere.
Foundry Local folosește ONNX Runtime pentru execuție. Pentru Qwen3.8-27B, Microsoft a lucrat la două etape distincte ale inferenței. Prima procesează intrarea, inclusiv fișierele și istoricul primit. A doua generează continuarea. Motorul poate păstra calcule pentru începutul comun al unor cereri succesive și poate grupa solicitări care sosesc în timp ce lucrează deja. Aceste tehnici sunt relevante când o sarcină revine la același cod după fiecare rezultat al unui test.
În etapa de generare, Microsoft descrie DFlash2, o metodă prin care o componentă mai mică propune mai multe tokenuri pentru verificare. Compania menționează și cuantizarea memoriei de context și posibilitatea de a muta o parte din date către memoria accesată de procesor. Aceste opțiuni reduc presiunea pe memoria video în configurațiile documentate. Efectul lor se raportează la setările motorului și la dimensiunea cererii prelucrate.
Exemplul folosește Foundry Local CLI 0.13.0 sau o versiune ulterioară. Microsoft precizează că bibliotecile CUDA și o versiune compatibilă cuDNN se instalează separat pentru execuția pe NVIDIA. Acestea fac parte din cerințele configurației pentru Qwen3.8-27B. Foundry Local este o platformă disponibilă pe mai multe sisteme, iar Microsoft tratează extinderea acestei optimizări pentru Qwen către Mac și GPU-uri AMD ca etapă viitoare.
Testele Microsoft și costul unei sesiuni locale
Microsoft a comparat Foundry Local și llama.cpp folosind Qwen3.8-27B cuantizat la patru biți, pe două sisteme. Primul avea un NVIDIA GeForce RTX 5090 cu 32 GB de VRAM. Al doilea era un NVIDIA DGX Spark cu 128 GB de memorie unificată. Evaluarea a folosit date din probleme raportate pe GitHub. Microsoft raportează o generare mai rapidă la lungimile de intrare testate și o diferență mai mare după aproximativ 131.000 de tokenuri în acel protocol.
Cele două sisteme folosesc tipuri diferite de memorie. RTX 5090 are memorie video proprie, în timp ce procesorul și grafica de pe DGX Spark împart memoria sistemului. Graficele Microsoft arată separat rezultatul fiecărei platforme. Cele 128 GB ale sistemului DGX Spark descriu memoria unificată totală din configurația de test, iar cei 32 GB ai RTX 5090 descriu memoria plăcii grafice.
Comparația are în vedere viteza de generare, în condițiile și cu configurațiile folosite de Microsoft. Timpul pentru un flux complet de lucru include și pregătirea contextului, apelurile instrumentelor, rularea testelor și revizuirea schimbărilor. Un model folosit pentru a explica un fișier de câteva sute de linii și același model folosit pentru a parcurge un depozit mare pot solicita memoria și procesorul grafic în mod diferit.
În această integrare, calculul pentru tokenurile generate de Qwen se face pe stația echipei. Resursele folosite țin de echipamentul disponibil, energia consumată și întreținerea configurației. Echipa poate folosi și alți furnizori în aplicație, conform funcțiilor disponibile în client. Pentru programarea pe cod intern, un aspect concret al noii documentații este posibilitatea de a păstra același client de lucru și de a alege explicit furnizorul care execută modelul.
