Windows ML får llama.cpp og GGUF, men API-et kan foreløpig bare greedy decoding
torsdag 8. oktober · KI-generert · Kilde: Microsoft Foundry on Windows
Test Windows MLs nye llama.cpp-backend for GGUF-modeller, men regn med at Text Generation API-et foreløpig bare kan greedy decoding.
Microsoft har sammen med NVIDIA bidratt med spekulativ dekoding av typen Eagle-3, MTP og D-Flash2 til llama.cpp. Det nye Text Generation API-et i Windows ML bruker llama.cpp under panseret, men eksponerer ingen av dem. Det ser du når du legger Microsofts kunngjøring fra 7. oktober ved siden av API-dokumentasjonen på Microsoft Learn: sesjonen velger alltid tokenet med høyest sannsynlighet, uten temperature, top-p, top-k, chat-maler eller strukturert output.
Selve nyheten er Windows ML 2.7.2021 Experimental, som ligger ute som NuGet-pakke. Den gir to oppgavespesifikke API-er. Text Generation tar språkmodeller i både GGUF- og ONNX-format, mens Speech Recognition transkriberer lyd med en ONNX-versjon av Whisper, og de to kan kjedes. Windows ML velger kjøremotor selv, så en GGUF-fil går automatisk til llama.cpp. Tokenizeren ligger inne i GGUF-fila, så du slipper den separate tokenizer.json-fila som ONNX-varianten krever.
«Med denne nye, eksperimentelle llama.cpp-integrasjonen kan du hente en splitter ny GGUF-modell fra Hugging Face og kjøre den lokalt gjennom den samme Windows ML-stacken du allerede bruker, med bare noen få kodelinjer» — Microsoft, i utviklerbloggen Foundry on Windows
Den raskeste veien inn er et OpenAI-kompatibelt endepunkt. Du starter WinMLServer.exe model.gguf --model-id qwen2.5-0.5b --target gpu --port 8080 og peker OpenAI-SDK-en mot http://127.0.0.1:8080/v1 med tilgangsnøkkelen serveren skriver ut ved oppstart. Kode som allerede snakker med OpenAI, kan dermed prøves mot en lokal modell ved å bytte base_url.
Under de to oppgave-API-ene ligger Windows ML Runtime API, en ny eksperimentell inferensvei for deg som vil styre mer selv. Du kan sende bilder, videorammer og lydbuffere inn i modellen uten kopiering, kjede flere modeller i én deterministisk pipeline der hvert steg plasseres på CPU, GPU eller NPU, og kompilere modeller på forhånd for raskere oppstart. De kjente ONNX Runtime-API-ene er fortsatt fullt støttet ved siden av.
«API-et skjuler ikke maskinvareplasseringen; det fjerner bare behovet for å skrive din egen token-løkke» — Microsoft Learn, dokumentasjonen for Text Generation API
Begrensningene står tydelig i dokumentasjonen. API-ene finnes bare for C++ og Python, ikke C#. De er eksperimentelle og ikke støttet i produksjon, og apper som prøver dem, skal ikke publiseres i Microsoft Store. Eksemplene er validert mot modellfamilien Qwen2.5-0.5B-Instruct, mens andre decoder-only-modeller med samme kontrakt skal kunne fungere.
Hva bør du gjøre?
- Start WinMLServer.exe med en liten GGUF-modell og kjør den eksisterende OpenAI-SDK-koden din mot den, før du skriver C++ eller Python mot Runtime API-et.
- Behold llama-server eller Ollama for alt som trenger temperature, sampling eller strukturert output, siden Text Generation API-et ikke kan det ennå.
- Hold API-ene unna produksjonsbygg og Store-innsendinger til Microsoft fjerner eksperimentmerket.
Bakgrunn
Windows ML er Microsofts felles rammeverk for lokal inferens på Windows-PC-er med GPU, NPU og CPU fra AMD, Intel, NVIDIA og Qualcomm. I samme kunngjøring får PyTorch offisielle native CPU-bygg for Windows på Arm64, NVIDIA publiserer CUDA-pakker for samme plattform, og Triton for Windows gir torch.compile på støttede GPU-er. Microsoft retter pakken mot de nye PC-ene med NVIDIA RTX Spark, som Surface Laptop Ultra.