A Microsoft entra na corrida pela IA local

Autoria: Sam Witteveen · Assistir no YouTube

Vídeo de autoria do canal indicado, não da IANIA; todos os direitos pertencem ao criador. Transcrição, resumo e tradução gerados automaticamente; o conteúdo no idioma original é preservado na versão em idioma original.

Idioma original: inglês

Vídeo original: Microsoft Joins the Local AI Push · Canal: Sam Witteveen · 13:25 · Assistir no YouTube

Tópicos: Agentes de IA, Infraestrutura e hardware de IA, Modelos locais e open source

Resumo

No evento de Windows e Surface, a Microsoft apresentou uma estratégia de inteligência híbrida que encaminha tarefas entre modelos locais e modelos na nuvem. Uma demonstração do GitHub Copilot usou agentes locais para processar a maior parte de 1,6 milhão de tokens, enquanto um modelo na nuvem planejava a tarefa. O vídeo examina os modelos altamente quantizados anunciados, os possíveis limites de qualidade e o suporte a llama.cpp no Windows ML. Também aborda os contêineres de execução da Microsoft e o hardware RTX Spark, concluindo que o apoio da Microsoft pode ajudar a tornar a IA local mais comum.

Pontos-chave

O modo automático do GitHub Copilot pode escolher entre modelos na nuvem e um modelo local, sem que o desenvolvedor precise definir essa escolha.
Em uma demonstração, um modelo na nuvem planejou a tarefa e três subagents locais examinaram issues do repositório Windows Terminal; quase todos os 1,6 milhão de tokens foram processados localmente.
A Microsoft anunciou modelos locais com quantização de três, dois e 1,6 bits, mas o apresentador questiona quanto da qualidade, do desempenho em contextos longos e da confiabilidade de tool calling será preservado.
O Windows ML passará a incluir llama.cpp, o que pode facilitar a execução de modelos abertos e variantes personalizadas no Windows.
Os Microsoft Execution Containers (MXC) permitem definir políticas de acesso para agentes e atribuir as ações à identidade do agente, em vez de ao usuário conectado.
O RTX Spark foi apresentado como hardware Windows com até 128 GB de memória unificada e suporte a CUDA; o vídeo menciona um preço inicial estimado em cerca de US$ 2.600.
O apresentador considera o apoio da Microsoft à execução local um passo importante para que a IA local deixe de ser exceção.

Capítulos

Início	Capítulo	Resumo
00:00	Demonstração de modelos locais e inteligência híbrida	A Microsoft mostra uma sessão do agente que processa 1,6 milhão de tokens localmente e apresenta o encaminhamento entre modelos locais e na nuvem.
04:16	Modelos quantizados e dúvidas sobre qualidade	O vídeo analisa os modelos anunciados com quantização agressiva e questiona seu desempenho em programação, contextos longos e tool calling.
08:05	llama.cpp no Windows ML e segurança de agentes	A integração de llama.cpp pode ampliar a compatibilidade com modelos, enquanto os MXC oferecem sandbox e políticas de acesso para agentes.
11:12	Hardware RTX Spark e o futuro da IA local	O apresentador comenta as especificações e o preço do hardware e avalia o apoio da Microsoft à adoção mais ampla da IA local.

Citações

A conta disso foi zero — não porque a Microsoft estivesse pagando, mas porque o modelo estava rodando no próprio laptop. — 00:00

O modelo caro faz o planejamento; os modelos locais mais baratos fazem a maior parte da leitura. — 02:07

Todo router vive ou morre pelo que acontece quando erra. — 03:44

A Microsoft deixou claro que será preciso conseguir executar modelos localmente, e não apenas usar a nuvem. — 12:17

Conceitos e entidades

hybrid intelligence (conceito): Estratégia da Microsoft que combina modelos, runtime e hardware para encaminhar tarefas entre execução local e na nuvem.
GitHub Copilot (ferramenta): Ferramenta de programação mostrada encaminhando tarefas para modelos locais ou na nuvem.
Microsoft AI code 1.1 flash (modelo): Modelo de programação da Microsoft apresentado em uma versão quantizada para execução local.
Nemotron (modelo): Família de modelos mencionada como opção futura para execução local com quantização de dois bits.
DeepSeek V4 (modelo): Modelo que a Microsoft demonstrou executando localmente com quantização de 1,6 bits.
llama.cpp (repo): Projeto de execução de modelos que será integrado ao Windows ML para ampliar a compatibilidade com modelos locais.
Windows ML (ferramenta): Runtime da Microsoft para implantar modelos em GPUs, NPUs e CPUs.
Microsoft Execution Containers (MXC) (ferramenta): Sandbox de execução que permite às organizações definir políticas de acesso para agentes no Windows.
RTX Spark (ferramenta): Hardware apresentado pela Microsoft para executar modelos localmente em um sistema Windows.
Microsoft (empresa): Empresa que anunciou a estratégia de inteligência híbrida, o suporte a llama.cpp no Windows ML e novos recursos de execução local.

Tradução completa (pt-BR)

00:00 Certo, ontem a Microsoft realizou seu evento de Windows e Surface em San Francisco. Neste vídeo, quero falar sobre algumas das coisas interessantes que eles mostraram lá. Houve uma parte interessante em que mostraram 1,6 milhão de tokens. Essa foi a quantidade que uma sessão de agent de programação enviou para um modelo durante uma das demonstrações. E deixaram claro que o custo disso foi zero. Não porque a Microsoft estivesse pagando a conta nem nada assim, mas porque o modelo estava rodando no próprio laptop. E devo dizer que também não parecia uma demonstração de brinquedo. O agent estava investigando algumas issues do GitHub

00:32 na base de código do terminal do Windows. E talvez a parte mais interessante tenha sido a afirmação de que nem foi o desenvolvedor quem decidiu que ele deveria rodar localmente. Foi a ferramenta. Embora a maior parte da cobertura que vi desse evento tenha se concentrado no Surface Laptop Ultra e no chip Nvidia RTX Spark — ambos pareciam muito legais, embora tivessem um preço bem salgado —, muita coisa já havia sido anunciada em junho. Na verdade, acho que o mais importante aqui são as datas de lançamento, os preços e coisas desse tipo. Mas, para mim, o interessante aqui

01:03 era: o que o Windows vai fazer com esse processador potente? E parece que uma das principais coisas que ele vai fazer é decidir quais dos seus tokens rodam na sua máquina e quais vão para a nuvem. A Microsoft está chamando isso de inteligência híbrida. A pessoa que lidera a equipe do Windows descreveu isso como roteamento inteligente. Basicamente, os modelos, o runtime e o chipset trabalhando juntos. Então, vamos começar pelo roteador, que foi o componente que fez a demonstração funcionar. Na

01:34 demonstração do GitHub Copilot, a apresentadora deixou o seletor de modelo na opção automática. E a nova versão da opção automática não escolhe mais apenas entre modelos na nuvem. Ela também pode escolher um modelo local. Então, quando ela passou uma tarefa bastante básica de limpeza na base de código do terminal do Windows, a tarefa foi enviada ao modelo Microsoft AI code flash, que estava rodando no laptop. E dava para ver a GPU acelerando na tela. Ela até observou que era possível colocar a máquina inteira no modo avião e ela continuaria funcionando. Depois disso

02:07 ela passou uma tarefa mais difícil: analisar todas as issues marcadas como needs repo. Quando fez isso, aconteceu algo totalmente diferente. Basicamente, um modelo na nuvem — era um dos modelos da OpenAI, GPT-6 ou algo assim — fez o planejamento, e depois três subagents rodaram localmente usando aquele modelo Microsoft AI code. Então, esse é um padrão bem comum que já vimos, certo? O modelo caro faz o raciocínio; os modelos locais e baratos fazem a maior parte da leitura. E é aí que chegamos aos 1,6 milhão de tokens que entraram

02:37 aqui, certo? A maioria desses tokens — na verdade, acho que todos, menos uns 10 mil — foi processada localmente. E é daí que vêm os 1,6 milhão de tokens: 1,6 milhão de entrada e pouco mais de 10 mil de saída. Isso dá aproximadamente 150 para 1. E esse é cada vez mais o tipo de padrão que vemos quando se constroem coisas com vários agents: o context window continua aumentando e você continua enviando conteúdo para gerar uma saída pequena. E achei muito interessante ver basicamente como eles lidaram com esse

03:11 roteamento entre o modelo local e o modelo na nuvem. Porque acho que isso é algo que veremos acontecer cada vez mais daqui para a frente. Embora não seja do interesse de empresas como OpenAI ou Anthropic falar muito sobre isso, é do interesse de qualquer fabricante de hardware e até de empresas como a Microsoft, que produzem parte do software e do hardware, e não apenas os próprios modelos. Isso será lançado no app do GitHub Copilot em 15 de outubro. E parece que, nos próximos meses, esse app receberá contexto local, ações locais e modelos locais. E

03:44 vai ser algo muito interessante de acompanhar. Porque sabemos que qualquer roteador depende do que acontece quando erra. Se o modelo local não consegue lidar com a tarefa que recebeu, ele percebe isso e a envia de volta para a nuvem, ou você simplesmente recebe uma resposta pior e nunca descobre o que falhou nem o que não saiu como queria? Infelizmente, não foi algo que mostraram aqui, mas certamente vai ser interessante acompanhar, considerando que já vimos ideias como a de roteador de modelos, com coisas como PAIR, da NVIDIA, além de outros projetos

04:16 e ideias que as pessoas apresentaram sobre como isso vai funcionar na prática. Certo, então o que disseram que roda localmente? Para começar, era o modelo Microsoft AI code 1.1 flash. Esse é o modelo de programação que a Microsoft apresentou na conferência Build. E o que me surpreende é que reduziram para três bits, diminuindo o tamanho em quase 80%. E fizeram o modelo rodar nesses dispositivos com um context window de 256K, totalmente local. Agora, devo dizer

04:49 que ainda estou em dúvida sobre versões de modelos quantizadas para três bits, especialmente quando se tenta usá-las para algo como programação. O tempo dirá: ou encontraram uma solução muito boa para o que estão fazendo, ou isso vai acabar recorrendo à nuvem para qualquer tarefa de programação minimamente difícil. E a mesma ideia se aplica ao segundo modelo, certo? Eles falaram de um novo modelo Nemotron que roda com dois bits e usa cerca de 20 GB de memória. E, curiosamente, estão apresentando-o como uma boa opção para o RTX Spark. Então, não se esqueça de que o RTX Spark

05:24 agora não vai vir apenas numa versão de 128 GB. Já vimos os DGX Sparks com uma versão de 64 GB, e parece que o RTX Spark pode até ter variantes com apenas 24 GB. Agora, o terceiro que mostraram — e devo dizer que estou um pouco desconfiado desse —, espero muito estar enganado, mas foi o DeepSeek 4 rodando localmente com 1,6 bit e cerca de 60 GB de memória. A frase que usaram no palco foi algo mais ou menos assim: há um ano, essa capacidade só estava disponível nos modelos de fronteira na nuvem.

05:58 E, para a maioria das pessoas, isso é mais ou menos verdade. Agora dá para rodar o DeepSeek 4.1 em vários DGXs. Eu faço isso. É um dos meus modelos favoritos, de que gosto muito. Mas vai ser muito interessante ver como é, de fato, uma versão de 1,6 bit desse modelo. Para ser justo, eles estão dizendo que 1,6 bit não é a média. Na prática, isso significa que algumas camadas serão mantidas em maior precisão e muitas serão reduzidas a uma precisão bem baixa. Assim, tenta-se manter as camadas mais importantes em níveis de precisão mais altos e, para as camadas que não são ativadas com tanta frequência,

06:28 usa-se uma precisão menor. Mas a verdadeira questão é: quanto dessa qualidade realmente se mantém? A afirmação no palco foi que ele supera outros modelos em benchmarks de programação e raciocínio. Mas não esclareceram muito bem o que isso significava. E eu diria que há três pontos principais aqui. Primeiro: a taxa de aprovação em programação se mantém em comparação com uma versão do mesmo modelo de maior precisão? Tenho muitas dúvidas de que isso aconteça. Segundo: ele desmorona com contextos longos? E

07:01 terceiro: se você usa ferramentas de forma complexa, ele ainda produz chamadas de ferramenta limpas? A saída estruturada costuma ser a primeira coisa a falhar quando se exagera na quantização. E, em qualquer tipo de tarefa com agent, uma chamada de ferramenta com erro geralmente significa que a tarefa falhou. Outra coisa que você precisa lembrar é que, se estiver buscando um contexto longo, como 256K, isso não sai de graça, certo? Com esse comprimento, o KV cache ocupa muita memória, além daquela usada pelos pesos do modelo.

07:34 Há vários truques interessantes para quantizar o cache KV, reduzindo-o para 8 bits, 4 bits, talvez até menos agora. Mas meu palpite é que você provavelmente vai precisar de uma das versões maiores desta máquina, com bastante memória, para conseguir fazer isso. Agora, outro ponto interessante que quero mencionar aqui, sobre o qual ainda não falei muito no canal, é o debate bastante interessante: você escolhe um modelo maior com uma taxa de quantização menor ou uma taxa de quantização maior com um

08:05 modelo menor? Pessoalmente, tenho visto que, desde que suas quantizações não fiquem abaixo de 4 bits, escolher o modelo maior geralmente traz resultados melhores. Mas isso é principalmente uma impressão anedótica minha. Não consigo me lembrar de nenhum artigo ou algo do tipo que tenha falado sobre isso. Certo. Para conseguir executar esses modelos na máquina, você vai precisar de um ambiente de execução. E um dos anúncios que fizeram — acho que foi uma vitória clara — foi a ideia de incluir o llama.cpp no Windows ML. O Windows ML é o ambiente de execução da Microsoft para

08:37 fazer deploy de modelos em GPUs, NPUs e CPUs. E o legal aqui é que eles estão trazendo o llama.cpp para isso. Por que isso importa? Basicamente, vai permitir muita compatibilidade. Isso significa modelos open source desde o primeiro dia. Então, quando um modelo novo é lançado e surge uma quantização GGUF algumas horas depois, você não precisa esperar a Microsoft empacotá-lo. E isso vale especialmente se você não estiver usando apenas as versões normais — talvez esteja usando uma versão sem censura, uma versão especificamente submetida a fine-tuning, que a

09:08 Microsoft nunca vai converter para o seu sistema. Então, incluir o llama.cpp agora dá a você a possibilidade de simplesmente escolher os modelos que quer executar e de fato executá-los. Outra coisa legal aqui é que, se você estiver desenvolvendo um aplicativo para Windows que vem com um modelo local, agora terá esse único ambiente de execução, que lida com qualquer hardware que o usuário tenha. Imagino que isso funcione desde que o hardware seja relativamente recente. O que ainda não sei, e vou investigar, é como conectar seu próprio

09:38 modelo local ao roteador do Copilot aqui, ou se só é possível usar os modelos escolhidos pela Microsoft. Tenho que dizer que, se fosse possível conectar qualquer modelo, isso poderia ser uma grande vitória para a Microsoft: você poderia simplesmente decidir: “Ah, quero conectar ao meu sistema operacional um modelo Qwen 4 35B de mistura de especialistas, e ele seria usado automaticamente por vários aplicativos diferentes ou algo assim.” Certo, a próxima questão, depois de ter modelos locais capazes, é obviamente como impedir que eles

10:09 façam coisas que você não quer que façam. Em muitos aspectos, o que a Microsoft anunciou aqui foi a versão deles do OpenShell da Nvidia ou dos ambientes isolados do Docker, etc. Isso se chama Microsoft Execution Containers, ou MXC. É basicamente um ambiente isolado de execução para o qual as organizações podem definir políticas sobre o que um agent pode acessar; então, o próprio Windows as aplica enquanto o agent está em execução. O que acho realmente interessante aqui é toda a questão da identidade do agent. Cada ação que o agent realiza

10:41 é atribuída ao agent, não a você. Então, dá para imaginar que isso ajuda tanto a rastrear as coisas quanto, quando você está trabalhando em algo, a bloquear o agent caso ele tente fazer alguma coisa. Nesse caso, ele perde o acesso para realizar aquela ação, mas você, como usuário conectado, ainda pode ter acesso. Certo, por fim, temos o próprio hardware, e vou dizer que a Microsoft fez um ótimo trabalho de design aqui. Eles parecem muito impressionantes. E não se esqueça: estes são apenas os primeiros RTX Sparks que estamos vendo chegar ao mercado. Essas máquinas têm até 128 GB de memória unificada, suporte completo a CUDA e tudo isso funciona em um laptop com Windows. Você não precisa usar Linux para fazer isso. Então, lendo algumas das análises, acho que a Engadget estima que essa GPU está mais ou menos no nível de uma RTX 5070, com 20 núcleos de CPU, e que o consumo não passa de 80 watts. Os preços começaram, acho, em torno de US$ 2.600, mas, obviamente, quanto mais memória você colocar nela, mais o preço

11:12 aumenta. E acho que não há muito que a Microsoft ou a Nvidia possam fazer para evitar isso. Os problemas com memória e RAM que estão acontecendo no momento só estão tornando todo esse hardware cada vez mais caro. Além de uma versão para laptop, eles também têm uma versão para desktop. E, curiosamente, até deram uma prévia de uma versão do Windows da DGX Station, que chega mais para o fim deste ano. Vai ser interessante ver. Acho que isso vai ajudar mais a liberar a possibilidade de outras pessoas conseguirem usar esses equipamentos. Então, espero que em algum momento eu consiga pôr as mãos em uma RTX Spark, fazer alguns testes por conta própria, ver como essas máquinas se comportam e descobrir para que grupo de pessoas elas serão uma alternativa viável à DGX Spark, etc.

11:44 Enfim, para juntar tudo, achei que este foi um evento da Microsoft mais interessante do que o habitual, porque realmente deixou clara a posição da empresa: será necessário conseguir executar modelos localmente, e não apenas usar a nuvem. E acho que o apoio deles é um passo importante na direção que a IA local está tomando. Então, agora não são mais apenas entusiastas, pessoas de ML ou até startups que estão defendendo a IA local.

12:17 E, embora a Nvidia tenha claramente defendido a IA local neste ano, ter a Microsoft se juntando a essa tendência é definitivamente um passo à frente para tornar tudo isso a norma, em vez da exceção. Então, enfim, me contem nos comentários o que vocês acham. Qual é a opinião de vocês sobre a RTX Spark? O que acham de o Windows adotar o llama.cpp, em vez de simplesmente criar o próprio protocolo ou a própria maneira de fazer isso? Estou realmente interessado em ouvir a opinião de vocês sobre esse assunto. Acho que a Microsoft seguiu um rumo interessante aqui. Enfim, como sempre, se gostaram do vídeo, cliquem em gostei

12:53 e se inscrevam. A gente se fala no próximo vídeo. Até mais.

13:25 e se inscreva, e conversarei com você no próximo vídeo. Até mais.

Transcrição original

[00:00] Okay, so yesterday Microsoft held their Windows and Surface event in San Francisco. In this video I want to talk about some of the interesting things that they showed there. So they had an interesting section where they showed 1.6 million tokens. That was how much one coding agent session sent into a model during one of the demos. And they made it clear that the bill for that was zero. Not because Microsoft was picking up the tab or anything like that, but because the model was running on the laptop itself. And I got to say that it didn’t look like a toy demo either. The agent was investigating some GitHub

[00:32] issues on the Windows terminal code base. And maybe even the most interesting part here was that they claimed that it wasn’t actually even the developer who decided it should run locally. It was the tool. And while most of the coverage that I’ve seen about this event really focused on the Surface Laptop Ultra and the Nvidia RTX Spark chip here, both of those looked really cool. Although definitely a steep price tag there. A lot of that was actually announced back in June. Really the big thing here I guess is the shipping dates, the pricing, that kind of thing. But for me the interesting thing here

[01:03] was what is Windows actually going to do with this powerful processor? And it seems one of the key things that it’s going to do is decide which of your tokens run on your machine and which of them go to the cloud. So Microsoft is calling this hybrid intelligence. They had the person who leads the Windows team actually described it as intelligent routing. Basically the models, the runtime, and the chip set all working together. So let’s start with the router that’s the piece that actually made the demo work. So in the

[01:34] GitHub Copilot demo, the presenter had the model picker set to auto. And the new version of auto doesn’t just choose between cloud models anymore. It can also choose a local model. So when she gave it a pretty basic sort of clean up task on the Windows terminal code base, it actually sent that to the Microsoft AI code flash model that was running on the laptop. And you could actually see the GPU ramping up on the screen. She even pointed out that you could put the whole machine into airplane mode and it would still keep going. After that

[02:07] though, she then gave it something harder to go through all the issues that were tagged needs repo. When she did that, what happened there was a whole different thing. So basically a cloud model, it was one of the open AI models GPT-6 or something, did the planning, then three sub agents ran locally on that Microsoft AI code model. So this is a very standard pattern we’ve seen, right? The expensive model does the thinking, the local cheap models do the bulk reading. And that’s where we get to the actual 1.6 million tokens coming in

[02:37] here, right? The majority of those tokens, in fact, I think all but maybe like 10,000 or so, were running locally. And that’s where the 1.6 million tokens come from. 1.6 million in and a bit over 10,000 out. That’s roughly 150 to 1. And more and more this is the kind of pattern that you see if you’re sort of building things with multiple agents, where the context window keeps getting longer and you keep sending it through to generate something small out. And I thought this this was really interesting to see basically how they handled this

[03:11] routing between the local model and the cloud model. Because I do think that this is something we’re going to see happen more and more going forward. While it’s not in the interest of companies like OpenAI or Anthropic to really talk about that, it is in the interest of any of the hardware makers and even companies like Microsoft who are making some of the software and the hardware, not just the actual models. So this is going to ship in the GitHub Copilot app on October 15th. And it seems that that app is getting both local context, local actions, local models over the next few months. And

[03:44] it’s really going to be something that’s very interesting to sort of look out for. Because we know that every router lives or dies by what happens when it gets it wrong. If the locomotive can’t handle the task it was sent, does it then know that and send it back to the cloud, or do you just get a worse answer and never actually know what failed and what didn’t work out the way you wanted it. Unfortunately, that wasn’t something that they showed here, but it’s certainly going to be interesting to see when we’ve seen things like the whole model router idea with things like PAIR from NVIDIA through to other projects

[04:16] and ideas that people have put out there of how this is actually going to work. All right, so what did they actually say runs locally? So, first off, this was the Microsoft AI code 1.1 flash model. This is the coding model that Microsoft introduced at the Build conference. And the thing that kind of amazes me here is that they’ve taken it down to three bits, which has cut the size by close to 80%. And they’ve got it running on these devices with a 256K context window fully local in there. Now, I’ve got to say

[04:49] that I’m on the fence a lot about a three-bit quantized version of a model, especially when you’re trying to use it for something like coding. I think time’s going to tell either they’ve worked out something really good that they’re actually doing there, or this is going to be calling the cloud for any sort of coding task that’s remotely difficult. And that same idea carries into the second model, right? So, they talked about a new coming Nemotron model that runs at two bits in about 20 gigs of memory. And interestingly, they’re pitching that as a good fit for the RTX Spark. So, don’t forget the RTX Spark

[05:24] now is not just going to come in a 128 gig version. We’ve already seen the DGX Sparks include a 64 gig version, and it seems that the RTX Spark might even have variations that go down to a 24 gig version. Now, the third one that they showed, and I got to say I’m a bit suspicious about this one. I really hope I’m proven wrong, but this was them running DeepSeek 4 locally at 1.6 bits in about 60 gigs of memory. The line that they used on stage was something along the lines of that a year ago this capability was only available from the

[05:58] Frontier cloud models. And for most people that is kind of true. Now you can run DeepSeek 4.1 on multiple DGXs. I actually do that. It’s one of my favorite models that I really like. But it’s going to be really interesting to see what a 1.6 bit version of that model actually is like. Now to be fair, they’re actually saying that the 1.6 bits isn’t average. So in practice that means some layers are going to be kept at higher precision and a lot of them are going to be pushed very low. So you try and keep the layers that are the

[06:28] most important at higher precision levels and then layers that don’t get activated as much, you then go for lower precision on those. The real question is though, how much of that quality actually survives? So the claim on stage was that it outperforms on coding and reasoning benchmarks. But they didn’t really clarify what that meant. And I would say that there really sort of three key things here. One, does the coding pass rate hold up against a higher precision version of the same model? I’m very suspicious of whether that actually does. Secondly, does it fall apart at long context? And then

[07:01] thirdly, if you’ve got sort of complicated use of tools, does it actually still produce clean tool calls? Because structured output is often the first thing to break when you push quantization too far. And for any sort of agentic task, a broken tool call is generally going to be a failed task. The other thing you got to remember too is that if you’re really going for a sort of long context like 256K, that’s not going to be free, right? At that length your KV cache takes up a lot of memory on top of the actual weight.

[07:34] So there’s a lot of nice tricks of where people quantize that KV cache where that’s down to 8 bit, 4 bit, perhaps even lower than that now. But my guess is you’re probably going to need one of the bigger versions of this machine with a large amount of memory to be able to do that. Now, another interesting point just to raise here that I haven’t really talked about on the channel before is that it’s a very interesting debate of do you go for a bigger model with a lower quantization rate, or do you go for a higher quantization rate with a

[08:05] smaller model? And I personally I’ve been seeing as long as your quantizations don’t go below 4-bit, actually going for the bigger model usually gives you a better win. But, that’s mostly me saying that anecdotally. I can’t recall off the top of my head any sort of papers or anything that have been talking about that. All right. So, to be able to run these models on the machine, you’re going to need a runtime. And one of the announcements that they had, I think, is just a clear win here was the whole idea of llama.cpp inside of Windows ML. So, Windows ML is Microsoft’s runtime for

[08:37] deploying models across GPUs, NPUs, CPUs. And the cool thing here is that they’re bringing llama.cpp into it. So, why does that matter? Basically, it’s going to allow for a lot of compatibility. It means open models on day one. So, when a new model drops and there’s a GGUF quant that shows up a few hours later, you’re not having to wait for Microsoft to package it. And that’s especially true if you’re not just using the normal versions, perhaps you’re using an uncensored version, a specifically fine-tuned version, which

[09:08] Microsoft is never going to convert for their sort of system. So, having llama.cpp in there now gives you that ability to just pick the models that you want to run and actually run them. The other cool thing here is that if you are building a Windows app that ships with a local model, you’ve now got this one runtime that handles whatever the hardware your user happens to have. I’m guessing as long as that hardware probably is reasonably recent. The thing I I know yet, and I’ll be looking into, is how you can actually plug your own

[09:38] local model into the Copilot router here or whether it’s only the Microsoft picks. I got to say, if you could plug in any model there, this could be a huge win for Microsoft in that you could just basically decide, “Oh, I want Qwen 4 35B mixture of expert model plugged into my OS and it just gets automatically used by a whole bunch of different apps or something.” All right, the next thing up was once you’ve got capable local models here is obviously how do you stop them

[10:09] from doing things that you don’t want them to do. And in many ways what Microsoft announced here was their version of Nvidia’s open shell or their version of Docker sandboxes, etc. And this is called the Microsoft execution containers, MXC. It’s basically a runtime sandbox that organizations can set policies for what an agent can access, and then Windows itself enforces them while the agent runs. The bit that I think here is really quite interesting is the whole thing around agent identity. Every action the agent takes

[10:41] is attributed to the agent, not to you. And so you can imagine that this helps both in sort of tracing things, but also when you’re actually working on something, if the agent actually goes to do something, you can actually block it and then it loses access to take that action, but you as the logged-in user still can have access. All right, lastly up I guess was the hardware itself and I’m going to say Microsoft’s done a really nice job at design here. These look really impressive. And don’t forget, these are just the first of the

[11:12] RTX sparks that we’re seeing coming out. These machines are up to 128 gigs of unified memory, they have full CUDA support, and it’s all running on a Windows laptop. You don’t have to go into Linux to actually do this. So reading some of the coverage, I think Engadget puts this GPU at around about an RTX 5070 level with 20 CPU cores and it won’t draw more than 80 watts. Now, the prices for this started I think around about $2,600, but obviously the more memory that you put into this, the more that price goes

[11:44] up. And I guess there’s really nothing that Microsoft or Nvidia can really do to prevent that. The whole memory and RAM issues that are going on at the moment is just making all of this hardware get more and more expensive. Along with a laptop version, they’ve also got a desktop hearing there. And interestingly, they even teased a Windows version of the DGX Station coming later on this year. So, that’s going to be interesting to see. I think more for unlocking the ability for other people to be able to actually use these. So, hopefully at some point I will get my hands on an RTX Spark and be able to

[12:17] run some tests on it myself and see just how these things perform and work out for which group of people is this going to be a viable alternative to a DGX Spark, etc. Anyway, so to pull it all together, I thought this was actually interesting than usual event from Microsoft because it really planted a flag of them saying that you’re going to need to be able to run models locally and not just use the cloud. And I think by them getting behind it really is an important step in the direction that local AI is going. So, no longer do we just have sort of enthusiasts or ML people or even just startups sort of

[12:53] pushing for local AI now. And while we’ve had Nvidia clearly pushing for local AI this year, having Microsoft join that bandwagon is definitely a step forward in making all of this the norm rather than the exception. So, anyway, let me know in the comments what you think. What’s your take on the RTX Spark? How do you feel about Windows adopting Llama.cpp rather than just making their own protocol or their own way to do it? I’m really interested to hear from people about this one. I do think Microsoft’s gone in an interesting direction here. Anyway, as always, if you enjoyed the video, please click like

[13:25] and subscribe and I will talk to you in the next video. Bye for now.