Microsoft Mage-VL: En codec-nativ 4B-videomodell, lanserad utan tillkännagivande

Det finns inget Microsoft-blogginlägg om Mage-VL. Inget inlägg i Azures nyhetsrum, ingen listning i Foundry-katalogen, ingen lanseringstråd, ingenting på de produktkanaler där Microsoft normalt introducerar en modell. Det som finns i stället är en Hugging Face-repo – microsoft/Mage-VL, sex commits, 10,8 GB vikter, Apache-2.0 – en GitHub-mapp med inferensskript, en projektsida som underhålls av något som kallar sig Microsoft Mage Team, och en arXiv-rapport med 23 författare. Lästa tillsammans beskriver dessa artefakter en modell för syn och språk i 4B-skala vars centrala idé är genuint ovanlig: i stället för att avkoda video till jämnt fördelade bildrutor och skicka ett tätt rutnät av patches genom en webbtränad kodare, läser Mage-VL den komprimerade bitströmmen själv, med hjälp av en från grunden byggd kodare som kallas Mage-ViT för att bara behålla de patches som codec:en använt bitar på. Microsoft rapporterar att detta minskar visuella token med mer än 75 % och ger upp till 3,5 gånger snabbare väggklockstid samtidigt som det matchar Qwen3-VL-4B på stillbilder och slår Microsofts egen 15B Phi-4-Reasoning-Vision på video.

Den sista meningen är den del man bör ta med en nypa salt. Varje prestandasiffra i den här artikeln härrör från Microsofts egen rapport, modellkort eller projektsida. Tio dagar efter att vikterna dök upp har ingen oberoende part reproducerat något av det, ingen tredjepartsledartavla listar modellen, och – som Hugging Face-sidan uttryckligen säger – är den "inte driftsatt av någon Inference Provider", så det finns inte ens en värdbaserad slutpunkt som någon kunde ha benchmarkat i förbigående. Det som följer skiljer det som repositoryt bevisar från det som Microsoft bara påstår, för i en release utan tillkännagivande är det mycket olika kategorier.

Vad som faktiskt existerar, tio dagar in.

Den verifierbara ytan av denna utgåva är liten och värd att räkna upp exakt.

• Vikter, daterade den 26 juli 2026. Två safetensors-delar på 4.97 GB och 4.52 GB, plus en separat fil på 1.07 GB med namnet streammind_gate.safetensors. Hugging Faces egen läsare rapporterar 5B parametrar vid BF16 — 4B i språkavkodaren, resten fördelad mellan den visuella kodaren och den gaten.

• En teknisk rapport, inlämnad den 27 juli 2026 (arXiv 2607.24904), en version, 23 författare, med titeln "Mage-VL: En effektiv codec-nativ strömmande multimodal grundmodell".

• Körbar kod, inte bara vikter.Repot innehåller modeling_mage_vl.py, processing_mage_vl.py, två videoprocessorer inklusive en dedikerad codec_video_processing_mage_vl.py, och streammind_gate.py — cirka 175 KB anpassad Python. auto_map i config.json dirigerar sex Transformers-klasser till dessa filer, vilket är anledningen till att repot bär taggen custom_code.

• Två licenser, inte en. Mage-VL är Apache-2.0; den fristående Mage-ViT-kodaren publiceras separat under MIT.

• En fungerande demo som du inte behöver installera. Microsoft kör microsoft/mage-vl-demo som en Hugging Face Space på ZeroGPU, och två community Spaces använder redan modellen.

• Tidig community-medvind, som växte fram snabbare än leverantörens egna kommunikationer. 268 gillningar, 435 784 nedladdningar under den senaste månaden, nio community-kvantiseringar och två finjusteringar i modellträdet. Nedladdningsräknarna inkluderar automatiska hämtningar och spegelhämtningar, så betrakta den råa siffran som en signal om uppmärksamhet snarare än om driftsättning.

• Ett syskon. Mage-Flow, en text-till-bild- och instruktionsredigeringsmodell byggd med samma fasta 4B-budget, lanserades fyra dagar tidigare, den 22 juli. GitHub-repot presenterar Mage som "en familj av lätta, forskningsvänliga multimodala modeller", vilket är det närmaste ett positioneringsuttalande som någon har publicerat.

Mot det är listan över saker som inte finns minst lika informativ. Det finns inget Microsoft-blogginlägg och inget pressmeddelande. Det finns ingen notering i Azure AI Foundry, vilket innebär ingen supportväg för företag, inget SLA, ingen hanterad slutpunkt. Ingen inferensleverantör erbjuder den. Det finns inget stöd för vLLM eller SGLang: en community-förfrågan om att lägga till Mage-VL i SGLang lämnades in den 28 juli som issue #32646 och är, när detta skrivs, fortfarande öppen utan kopplad pull request och utan svar från underhållarna. Och det finns ingen oberoende utvärdering av något slag – modellen saknas på de neutrala leaderboarderna där ett påstående som ”slår en 15B-modell på video” normalt skulle testas.

Den enda idén: läs codecen, inte bildrutorna.

Nästan varje videokapabel VLM i produktion gör samma sak. Den avkodar videon till RGB-bilder, samplar dem jämnt — en per sekund, eller 32 över klippet, eller vad budgeten tillåter — och skickar varje samplad bild genom en vision transformer som ett tätt rutnät av patch:ar. Varje patch i varje samplad bild blir tokens. En statisk bakgrundsvägg kostar exakt lika många tokens som personen som går framför den, och den kostar dem igen i nästa bildruta, och nästa.

Det är en enorm mängd redundant beräkning, och moderna videocodecs löste redan det underliggande problemet för decennier sedan. H.264 och HEVC lagrar inte varje bildruta; de lagrar enstaka ankarbilder (I-bilder) i fullformat och beskriver sedan bildrutorna mellan dem som rörelsevektorer plus residualer — "det här blocket flyttade hit, och här är vad som ändrades." De intressanta delarna av en video är, nästan per konstruktion, de delar som kodaren lade bitar på.

Mage-ViT utnyttjar detta direkt. Genom att arbeta med 16x16-patchgranularitet behåller den varje patch i ankarbilderna och, för predikterade bilder, behåller den endast patchar som markerats som relevanta av codecens egna rörelsevektorer och residualenergi — de regioner som bär verklig information, rörelse eller scenbyte — medan den kasserar de lågredundanta och helt redundanta. Microsoft uppger att reduktionen uppgår till över 75 % av de visuella tokens, med spatiotemporalt sammanhang bevarat eftersom ankarbilderna fortfarande bär hela scenen. Designen är codec-agnostisk: den traditionella sökvägen accepterar H.264 eller HEVC, och en neural sökväg accepterar DCVC-RT.

Det eleganta är att rörelseuppskattningen redan var gjord. Varje komprimerad video på internet kommer med en karta över var aktiviteten finns, beräknad av kodaren och betald av den som laddade upp den. En konventionell pipeline kastar bort den kartan i samma ögonblick som den avkodas till RGB och lägger sedan GPU-tid på att återupptäcka samma information. Mage-VL väljer helt enkelt att inte kasta bort den. Oavsett om benchmark-siffrorna håller eller inte, är den iakttagelsen det bestående bidraget här — och det är anledningen till att den här releasen är värd att läsa även om du aldrig laddar ner vikterna.

Det renaste med experimentet

Dold i uppställningen finns ett designbeslut som gör resultaten långt mer tolkningsbara än en typisk modell-lansering, och nästan ingen som bevakat den här releasen har påpekat det: språkmodellen hålls fixerad.

Mage-VL:s avkodare är Qwen3-4B-Instruct-2507, omodifierad. Jämförelsebaslinjen, Qwen3-VL-4B, använder samma 4B Qwen3-stomme med en konventionell webbförtränad visuell enkodare. Så när Mage-VL förbättrar jämfört med Qwen3-VL-4B, kan skillnaden tillskrivas enkodaren och den codec-nativa tokeniseringen, inte en större eller bättre tränad språkmodell. Det är en kontrollerad ablation utklädd till en produktjämförelse, och det är den starkaste metodologiska egenskapen i releasen.

Det skär också åt andra hållet, och ärlighet kräver att man säger det. En jämförelse med samma backbone är det rättvisaste testet av encoder-idén och samtidigt den inramning som mest sannolikt smickrar den — Microsoft valde den baslinje som isolerar dess eget bidrag. Phi-4-jämförelserna har inte den egenskapen: Phi-4-Reasoning-Vision-15B och Phi-4-MM-5.6B är olika backbones, olika träningsrecept, olika post-träning. "Slår vår 15B-modell på video" är ett verkligt resultat men ett mycket lösare sådant, och det är också en jämförelse mot Microsofts eget äldre arbete, vilket är den enklaste typen att vinna.

Träningsskalan är den andra punkten där uppsatsen gör ett genuint överraskande påstående. Mage-ViT förtränades från grunden på cirka 560 miljoner omärkta bilder och 100 miljoner omärkta videoramar – en stor korpus i absoluta tal, men långt ifrån de miljarder kurerade bild-text-par som ligger bakom de encoder-modeller den konkurrerar med. Uppsatsens första angivna resultat är att en stark VLM-encoder inte kräver övervakad data i webbskala. Om detta håller vid oberoende granskning spelar det betydligt större roll än någon enskild benchmark-rad.

Siffrorna, och vems siffror de är.

Det som följer är genomgående rapporterat av Microsoft, på Microsofts egen utvärderingsplattform, mot baslinjer som Microsoft valt. Inget här har reproducerats av tredje part. Läs det som en hypotes med ovanligt specifika felstaplar, inte som en resultattavla.

• Video-MME — Mage-VL-4B 64.0 mot Qwen3-VL-4B 59.7 mot Phi-4-Reasoning-Vision-15B 55.3

• NExT-QA — 83.1 vs 79.8 vs 69.0

• LongVideoBench — 61.3 mot 57.7 mot 51.2

• VideoEval-Pro — 45.2 mot 20.7 för Phi-4

• Timelens-QVHighlight (temporal grounding) — 57,4 mot 34,9 mot 11,6

• Ref-DAVIS17 (hänvisningsspårning) — 25.83 vs 7.48 vs 2.15

• DocVQA-val — 95.14 vs 94.69 vs 92.79 (Phi-4-MM-5.6B)

• OCRBench — 81,80 vs 81,60 vs 81,70

• ChartQA — 84.88 mot 83.96 mot 83.40

• MMStar — 67.32 vs 62.04 vs 59.63

• RealWorldQA — 70.46 vs 70.85 vs 70.72, en av raderna där Mage-VL förlorar

• MMBench-EN-dev — 84.02 mot 83.25, där Phi-4-Reasoning-Vision-15B ligger före båda med 84.19

• CV-Bench-3D / CV-Bench-2D — 94.75 vs 92.30, och 82.13 vs 81.00

• EmbSpatial — 82.67 mot 77.50

• OVO-Bench (streaming) — 64,00 totalt, beskrivs som state of the art bland streamingarkitekturer; delmängden för realtidsvisuell perception ligger i genomsnitt på 79,84 % jämfört med 72,8 % för Qwen3-VL-4B, vid 1 fps

• Mage-ViT som fristående encoder — över 86.3% på ImageNet vid en tokenbudget på 676, över 96.1% på Food-101

Tre avläsningar av den tabellen är värda mer än själva tabellen.

När det gäller bilder är "paritet" det ärliga ordet. DocVQA med 0.45, OCRBench med 0.20, ChartQA med 0.92, MMBench med 0.77 — dessa ligger inom det intervall där en annan promptmall eller avkodningsseed skulle kunna kasta om ordningen, och RealWorldQA går faktiskt till Qwen3-VL-4B. Microsoft säger detsamma och beskriver bildprestandan som paritet snarare än en seger, och den beskrivningen är korrekt. Om din arbetsuppgift är att besvara frågor om dokument och bilder, ger den här versionen dig ingen anledning att byta.

Inom video och temporal grounding är gapen stora och konsekventa. Timelens-QVHighlight nästan fördubblar baslinjen; Video-MME, NExT-QA och LongVideoBench rör sig alla med 3,6 till 4,3 poäng i samma riktning med backbone fixerad. Konsekvensen över benchmarks som stressar olika saker är det mönster du skulle förvänta dig om encoderändringen är verklig snarare än en tuning-artefakt.

Två rader ska inte citeras utan sammanhang. Ref-DAVIS17 på 25.83 mot 7.48 ser ut som en 3.5x-utklassning, och artikelns huvudsakliga rumsliga deltavärden inkluderar +11.0 på VSI-Bench och +53.1 på CrossPoint. När en baslinje hamnar nära golvet på en uppgift, mäter deltat mestadels vilken modell som tränats för att förstå uppgiftsformatet — inte vilken modell som är mer kapabel. Samma försiktighet gäller för streamingresultaten i absoluta tal: på SoccerNet är Mage-VL:s rapporterade siffror 55.54 TimVal, 83.14 ROC-AUC och ett F1 på 16.35. Ett F1 på 16.35 är ett toppmodernt värde i en ung utvärdering, inte ett löst problem. Proaktiv streamingperception är i ett tidigt skede, och ledarens absoluta poäng säger detsamma.

Grinden: en modell som avgör när den ska tala.

Den andra arkitekturidén är den med tydligast produktmässiga implikationer, och den förklarar den där mystiska 1,07 GB-filen.

Mage-VL delar upp strömning i två processer, som i artikeln beskrivs som System 1 och System 2. System 1 är en lättviktig "kognitionsgrind" som övervakar varje rullande fönster av codec-funktioner och uppskattar sannolikheten att något värt att tala om precis har avslutats. Under en tröskel förblir den tyst och den dyra delen av modellen körs aldrig. Över tröskeln anropas den fullständiga avkodaren för att producera ett svar. Demokonfigurationen använder 30-sekunders kausala fönster vid 1 fps, CLI:n exponerar tröskeln direkt som --gate_threshold, och strömningsingångspunkten bearbetar videosegment för segment (inference_streaming.py --video_backend codec --segment_sec 8). Endast grinden tränas i slutskedet, på 3,35M strömningsprover.

Två saker med det är värda att notera. För det första är gaten inte ett litet klassificeringshuvud som sitter ovanpå: 1.07 GB BF16-vikter är ungefär en halv miljard parametrar, en riktig modell i sin egen rätt, levererad som en separat checkpoint. För det andra är filnamnet streammind_gate.safetensors — namngivningen tyder på att denna komponent härstammar från tidigare streaming-perception-arbete snarare än att den uppfanns för denna uppsats, även om repot inte uttryckligen anger den härstamningen.

Varför det är kommersiellt viktigt: för video som alltid är på är den dominerande kostnaden inte latenstid per anrop, utan anropsfrekvensen. En kameraström som körs 24/7 genom en konventionell VLM med 1 fps innebär 86 400 framåtpassager per dag oavsett om något hände eller inte. En grind som förblir tyst under de 99 % av materialet där ingenting händer förändrar formen på den räkningen, inte bara storleken. Huruvida Microsofts grind är tillräckligt träffsäker för att anförtros det beslutet är precis det som ingen utanför labbet har testat.

Kan du faktiskt köra det idag?

Ja, om du har en GPU och tålamod. Friktionen är påtaglig och ligger mest i videopipelinen snarare än i modellen.

Minne. Microsoft publicerar inget VRAM-krav. Från viktindexet: 9,49 GB shards plus 1,07 GB gate är cirka 10,6 GB BF16-parametrar, så ett 16 GB-kort är en realistisk golvnivå för bildarbete och 24 GB eller mer är det vettiga målet när du lägger till KV-cache för lång video eller ett streamingfönster. Det är aritmetik från filstorlekar, inte en leverantörsspecifikation — mät innan du provisionerar.

Anpassad kod är obligatorisk. auto_map pekar varje Transformers-ingångspunkt mot repots egna moduler, så trust_remote_code krävs. Du kör Microsofts Python, inte bara läser in tensorer. Det finns ännu ingen vLLM- eller SGLang-väg, vilket innebär ingen paged attention, ingen kontinuerlig batchning, ingen produktionsservingstack – ett betydande gap om du hoppades kunna lägga detta bakom en slutpunkt.

Kodekvägen kräver systemverktyg. FFmpeg och ffprobe måste finnas i din PATH. Den traditionella kodek-backendern är beroende av ett codec-video-prep-paket som tillhandahåller ett cv-preinfer-steg; den neurala vägen behöver DCVC-RT; den vanliga frames-backendern behöver Decord. Kraven drar också in flash-attn och mamba-ssm, som kompilerar CUDA-tillägg — installera ett PyTorch-bygge som matchar din verktygssats först eller avsätt en eftermiddag för bygget.

Vad konfigurationen berättar för dig som kortet inte gör. De maximala positionsinbäddningarna är 262 144, så avkodaren ärver Qwen3-4B:s långa kontext. Visionssidan körs med inmatning på 448 pixlar och 16x16-patchar, en encoder med 24 lager och dold dimension 1024, rumslig 2x2-sammanslagning, en token per videosekund och ett fönster på fyra bildrutor. Träningen nådde en temporal längd på 384 bildrutor i fas tre. Ett tak på 262K är inte detsamma som 262K validerat beteende, och 384 bildrutor är den längd som modellen faktiskt tränades att hantera.

Kända brister. En öppen diskussion i repot, öppnad den 4 augusti och fortfarande obesvarad, rapporterar om tokenförskjutning när bilder och videor skickas i samma begäran. Tio dagar gammal mjukvara beter sig som tio dagar gammal mjukvara. Om du vill ta en titt utan allt detta är Microsoft-drivna Space på ZeroGPU zero-install-alternativet.

Licensraden är mindre enkel än "Apache-2.0"

Modellkortet anger Apache-2.0. Mage-ViT-kodaren anger MIT. Båda är ungefär så tillåtande som öppna vikter kan bli. Men familjens repository anger att ”dessa modeller släpps endast för forskningsändamål”, med betoning på ansvarsfull AI-granskning och mänsklig tillsyn – och den meningen passar illa ihop med en Apache-2.0-licens, som inte begränsar kommersiell användning. Lägg till beroendena: DCVC-RT och verktygen för codec-förberedelse har sina egna villkor, oberoende av modellens.

För ett hobbyprojekt är detta brus. För allt som levereras till kunder är det den typen av tvetydighet som bör gå till juridisk rådgivning innan det går till produktion, och den typen av fråga som är värd att ställa på själva repot — där det, anmärkningsvärt nog, för närvarande inte finns någon Microsoft-representant som svarar.

Bör du bygga vidare på detta?

Beslutet delar sig tydligt längs en linje: om ditt problem är en ström eller en förfrågan.

{{1}}Om du arbetar med ständig perception – en kameraström, en direktsändning, en robots synfält, ett möte som pågår i en timme – är Mage-VL riktat precis mot dig, och ekonomin i att själv hosta talar till din fördel.{{/1}} {{2}}API-prissättning per token skalar med antalet bildrutor, vilket är en brutal modell för kontinuerlig video;{{/2}} {{3}}en 4B-modell på egen hårdvara med en gate som förblir tyst genom händelsefattigt material är en fundamentalt annorlunda kostnadskurva.{{/3}} {{4}}Haken är att du också anmäler dig till att bli den första personen utanför Microsoft som får reda på om gatens omdöme håller måttet.{{/4}}

Om ditt problem är formulerat som en förfrågan — en användare laddar upp ett dokument, en PDF, en skärmdump, ett kort klipp och förväntar sig ett svar — är fallet mycket svagare. På just dessa uppgifter ligger Mage-VL i paritet med en modell som du ändå skulle behöva driva själv, och värdbaserade multimodala slutpunkter är ett API-anrop bort utan GPU, utan ffmpeg-bygge och utan trust_remote_code. På OrcaRouter, Gemini 3.6 Flash kostar $1,50 per miljon indatatokens och $7,50 per miljon utdatatokens, vilket är leverantörens listpris som förs vidare rakt av — vi tar 0% påslag, så när en leverantör sänker priserna är sänkningen live på vår sida samma dag snarare än efter en prisöversyn. En enda nyckel når över 200 modeller med automatisk failover om en leverantör försämras, vilket är den praktiska anledningen att behålla en värdbaserad slutpunkt som standard och reservera egen drift för arbetsbelastningar som verkligen behöver det.

För att vara tydlig, eftersom skillnaden är viktig: vi hostar inte Mage-VL, och det gör ingen annan heller. Hugging Faces egen modellsida säger att ingen inferensleverantör har distribuerat den. Idag innebär det att köra den att du får köra den själv.

Vad skulle ändra den här avläsningen?

Fyra saker, i ungefärlig ordning efter hur mycket de skulle betyda.

En oberoende utvärdering är den stora. Varje siffra ovan är ett påstående, och det påstående som mest behöver testas är inte ett benchmarkresultat utan 3,5x hastighetsökningen, som mättes mot enhetlig framesampling på NExT-QA utan publicerade uppgifter om hårdvara, upplösning eller antal frames. Codec-förbehandling flyttar verkligt arbete till processorn och in i ffmpeg; en väggklocka-vinst mätt från början till slut på någon annans maskin är den enda versionen av den siffran som är värd att planera utifrån.

För det andra, stöd för serving. En sammanslagen vLLM- eller SGLang-implementering skulle förvandla detta från en forskningskontrollpunkt till något du kan placera bakom en lastbalanserare. SGLang-frågan är öppen och inte tagen; det är tråden att följa.

För det tredje, en listning i Azure AI Foundry, vilket skulle signalera att Microsoft avser detta som en produkt snarare än en artikel. Ingenting i den aktuella releasen tyder på att det är nära förestående.

För det fjärde, och mest märkligt: huruvida Microsoft någonsin säger något. En teknisk rapport med 23 författare, en underhållen projektsida, en hostad demo-Space och en syskonmodell för generativ AI fyra dagar tidigare beskriver inte en läcka eller en olycka — de beskriver en avsiktlig forskningspublicering som helt hoppade över produktmegaforen. Gemenskapen fyllde tystnaden ändå, med nio kvantiseringar och två finjusteringar inom tio dagar.

För de flesta team är rätt drag att läsa rapporten, inte att ladda ner vikterna. Den codec-nativa idén är huvudpoängen, och den är portabel: om återanvändning av rörelsevektorer som kodaren redan beräknat verkligen ger 75 % tokenreducering med bibehållen noggrannhet, så kommer den tekniken att dyka upp i modeller med lanseringsinlägg, leverantörsstöd och reproducerade benchmarks. Om du kör kontinuerlig video idag är kalkylen annorlunda — klona repot, kör dina egna klipp genom båda backends och mät hastighetsförbättringen själv, för just nu skulle du vara den första.

Frågor som faktiskt är värda att ställa

Är Mage-VL bara Qwen3-VL med en Microsoft-etikett på?

Nej, även om förvirringen är förståelig. Språkavkodaren är Qwen3-4B-Instruct-2507, använd som den är — Microsoft tränade ingen ny LLM. Allt annat är nytt: Mage-ViT förtränades från grunden, den codec-nativa tokeniseringen har ingen motsvarighet i Qwen3-VL, och strömningsgrinden är en ytterligare modell med en halv miljard parametrar. Att återanvända en öppen ryggrad och byta ut den visuella fronten är en legitim och allt vanligare forskningsstrategi, och här är det också det som gör den direkta jämförelsen tolkningsbar. Om du har efterlevnadskrav kring modellens ursprung, notera att härstamningen går genom Alibabas Qwen3-vikter och kontrollera båda licenserna.

Betyder "3.5x snabbare" att det är 3.5x billigare att servera?

Inte tillförlitligt. Siffran är en speedup i väggklockstid på NExT-QA jämfört med uniform bildrutesampling, och Microsoft framställer det som "upp till". Två saker späder ut det i praktiken. Codec-nativ inferens kräver ett förberedelsesteg — ffmpeg, ffprobe och cv-preinfer-steget, eller en DCVC-RT-omkodning för den neurala banan — som förbrukar CPU-tid som en naiv bildrutepipeline inte gör, och som inte syns i en GPU-sidig mätning. Och vinsten kommer från tokenreducering, så den skalar med hur redundant ditt videomaterial är: en mestadels statisk säkerhetskamera borde prestera bättre än den citerade siffran, medan snabbt klippt redigerad video där nästan varje patch förändras borde prestera sämre. Mät det på dina egna klipp.

Behöver jag särskilda videofiler för att använda codec-sökvägen?

Mestadels nej, och det är den trevliga överraskningen. Vanliga MP4-filer är redan H.264 eller HEVC, vilket är exakt vad den traditionella codec-backendens förbrukar — de rörelsevektorer den behöver finns redan i filen du har. Det du behöver lägga till är verktygen: FFmpeg och ffprobe i din PATH, plus paketet för codec-förberedelse. Den neurala backendens är undantaget; DCVC-RT förväntar sig video kodad med den codec:en, så då skulle du behöva omkoda. Och backend för vanliga bildrutor finns fortfarande kvar som en reserv som fungerar som vilken annan VLM som helst, vilket också är det ärliga sättet att själv A/B-testa codec-påståendet.

Kan jag använda det kommersiellt?

Licensen anger Apache-2.0, vilket tillåter kommersiell användning, modifiering och vidaredistribution. Repositoryt säger också att modellerna är ”släppta enbart för forskningsändamål.” Dessa två uttalanden pekar i olika riktningar, och klyftan har inte klargjorts av någon på Microsoft – vilket, vid en release utan tillkännagivande, utan produktlistning och utan leverantörsnärvaro i repositoryts diskussioner, inte är förvånande. Om pengar beror på svaret, låt en advokat läsa båda dokumenten och beroendelicenserna snarare än att lita på enbart licensmärket.