Models | The .NET Blog

Claude Opus 4.8 in Foundry is nog een teken dat Modelkeuze een Platformfunctie wordt

Emiliano Montesdeoca — Mon, 15 Jun 2026 00:00:00 +0000

Dit bericht is automatisch vertaald. Klik hier voor de originele versie.

Op een gegeven moment worden mededelingen over beschikbaarheid van modellen niet meer interessant vanwege alleen het specifieke model.

Ze worden interessant omdat ze het platformverhaal versterken.

Zo lees ik Claude Opus 4.8 landing in Microsoft Foundry.

Het model is belangrijk, maar het grotere verhaal is belangrijker

Ja, Claude Opus 4.8 is op zichzelf een belangrijke modelupdate.

Maar ik denk dat het nuttigere signaal is dat Foundry zijn serieuze modelkeuze onder één beheerd operatief oppervlak blijft uitbreiden.

Dat is belangrijk omdat het teams meer ruimte geeft om:

modellen aan workloads koppelen
kosten en capaciteit in evenwicht brengen
flexibel te blijven wanneer modelkwaliteit of prijsstelling verandert
governance en implementatiediscipline op één plek houden

Dat is het deel waar ik meer om geef.

Waarom dit belangrijk is voor platformdenken

Als uw AI-platform alleen goed werkt wanneer één modelleverancier voor altijd dominant blijft, hebt u eigenlijk geen veerkrachtig platform.

U hebt een afhankelijkheid met goeie marketing.

Dus elke keer dat Foundry nog een serieuze modeloptie toevoegt, is de interessante vraag niet alleen “is dit model goed?”

Het is ook:

verhoogt dit mijn architectonische flexibiliteit?
vermindert het leverancierslocking-druk?
maakt het workload-specifieke routing realistischer?

Dat is het niveau waarop beschikbaarheid van modellen strategisch nuttig wordt.

Mijn conclusie

Dit gaat minder over één specifieke modelmilepaal en meer over dat Foundry zich blijft gedragen als een serieus multi-model platform.

Dat is het grotere verhaal.

En hoe meer Foundry dat verhaal versterkt, hoe geloofwaardiger het wordt als de plek waar teams modelkeuze kunnen bedrijven in plaats van er alleen op te reageren.

Origineel bericht: Claude Opus 4.8 is now available in Microsoft Foundry

Microsoft Foundry mei 2026: de updates die ik echt nauwlettend zou volgen

Emiliano Montesdeoca — Wed, 27 May 2026 00:00:00 +0000

Dit artikel is automatisch vertaald. Voor de originele versie, klik hier.

Maandelijkse platform-overzichten kunnen heel snel veranderen in een stortvloed aan functies.

Dus hier is de kortere versie van What’s New in Microsoft Foundry | May 2026: het platform wordt dieper op precies de gebieden die het belangrijkst zijn voor echte AI-systemen.

De lijnen die ik zou volgen zijn:

trace-based evaluatie
ruimere modelkeuze
sterkere agent-tools
betere beheerde isolatie en meer kostentransparantie
aanhoudende vaart rond lokale AI via Foundry Local

Dit is een dense roundup, dus het patroon is belangrijker dan het aantal

Er staan veel afzonderlijke punten in het originele artikel.

Dat is prima, maar ik denk niet dat de beste manier om zo’n post te lezen feature voor feature is.

De betere vraag is: welke richting versterkt het platform duidelijk?

En ik denk dat het antwoord dit is:

Foundry wordt sterker in de operationele lagen rond agents, niet alleen in de modelcatalogus.

Dat is een heel goed teken.

Het belangrijkste thema is trace-based evaluatie

Als ik één thema uit de hele roundup moest kiezen, dan was het waarschijnlijk trace-based evaluatie.

Waarom? Omdat het de evaluatieverhaal verandert van:

een statische dataset bouwen
een benchmark draaien
hopen dat die productie weerspiegelt

aan iets realistischers:

echt gedrag observeren
echte traces evalueren
leren van wat het systeem daadwerkelijk doet

Dat is een veel volwassener model voor AI in productie.

Modelbreedte is belangrijk, maar alleen als het operationeel blijft

De toevoegingen rond Grok, DeepSeek, Fireworks en reinforcement fine-tuning zijn allemaal op hun eigen manier nuttig.

Maar voor mij is het belangrijkere punt niet dat er simpelweg nog een model bij is gekomen.

Het is dat modelbreedte wordt gecombineerd met:

operationele zichtbaarheid
evaluatietools
governance-oppervlakken
consistente deployment

Dat is wat voorkomt dat een model-ecosysteem in chaos verandert.

Foundry Local wordt een terugkerend strategisch signaal

Nog iets dat ik niet zou negeren, is hoe vaak Foundry Local nu opduikt als serieus onderdeel van het Foundry-verhaal.

Dat vertelt me dat Microsoft lokale AI niet langer ziet als een side experiment.

Het wordt onderdeel van het bredere platformverhaal:

privacy
device-local inference
hardware portability
edge deployment
hybride operationele modellen

Dat is de moeite waard om in de gaten te houden.

Mijn mening

De details zijn belangrijk, maar het grotere patroon is belangrijker.

Foundry beweegt verder naar een platform waarin agents, evaluaties, modellen, lokale runtimes en governance natuurlijker met elkaar verbonden zijn.

Dat is de richting die mij het meest interesseert.

En deze roundup maakt die richting, meer dan veel kleinere afzonderlijke aankondigingen, op één plek makkelijker zichtbaar.

Origineel artikel: What’s new in Microsoft Foundry | May 2026

Het moeilijke aan AI-ontwikkeling is niet langer toegang. Het is het juiste model goed draaien

Emiliano Montesdeoca — Tue, 26 May 2026 00:00:00 +0000

Dit artikel is automatisch vertaald. Voor de originele versie, klik hier.

We zijn allang voorbij het punt waarop alleen toegang tot een krachtig model genoeg was.

Dat is precies wat deze nieuwe Foundry-gids voor model-, kosten- en kwaliteitsbeheer goed begrijpt.

De echte uitdaging is nu operationeel:

het juiste model per workload kiezen
het valideren tegen je eigen data
latency en uitgaven beheren
upgrades en regressierisico sturen

Daar moeten serieuze teams goed in worden.

Het bronartikel definieert het probleem goed

Eén zin uit het originele bericht vat deze verschuiving heel goed samen:

“Het moeilijkste deel van AI-systemen bouwen is vandaag niet langer toegang krijgen tot een capabel model. Het is weten hoe je het juiste model kiest, valideert, optimaliseert en opereert gedurende de volledige levenscyclus van een echte applicatie.”

Dat is precies de juiste diagnose.

Te veel teams denken nog steeds dat modelselectie de hoofdkeuze is.

Dat is het niet.

Modeloperatie is het grotere probleem:

welke workload krijgt welk model?
hoe wordt kwaliteit geverifieerd?
welke kostenstructuur is acceptabel?
wat gebeurt er als een nieuw model verschijnt of een oud model afdrijft?
hoe test je een verandering zonder echte workflows te breken?

Dat is nu het echte engineeringwerk.

Waarom dit Foundry-stuk nuttig is

Ik vind dit artikel prettig omdat het over AI-systemen spreekt zoals ervaren platformengineers er echt over moeten nadenken.

Niet als “kies het slimste model en ga verder”.

Maar als systemen die leven onder trade-offs:

capability
latency
cost
safety
governance
upgrade pressure

Dat is veel nuttiger dan benchmarkgedreven optimisme.

De belangrijkste verschuiving is criteria-first denken

Het originele artikel raadt aan om succescriteria te definiëren voordat je de modelcatalogus opent.

Ik denk dat dit een van de belangrijkste gewoonten is die teams kunnen aannemen.

Als je eerst de catalogus opent, anker je op reputatie.

Als je eerst criteria definieert, anker je op de werkelijkheid van de workload.

Dat is een gezonder proces.

Want het model dat een benchmark wint, is niet automatisch het model dat wint op:

je prompts
je latencybudget
je kostenrails
je governancevereisten

Dat onderscheid is waar volwassen AI-engineering begint.

Het multi-modelverhaal wordt een echt voordeel

Nog iets dat ik goed vind, is de expliciet model-agnostische framing.

Het artikel presenteert Foundry niet als een bestemming voor één model, maar als een operationele surface over:

Microsoft-modellen
partner-modellen
open-source modellen
post-getrainde varianten
routing- en optimalisatiestrategieën

Dat is belangrijk, omdat modelflexibiliteit geen luxe meer is. Het is onderdeel van risicobeheer.

Als kwaliteit verschuift, prijzen bewegen of quota krapper worden, hebben teams opties nodig.

Kostencontrole is geen bijzaak

Het artikel heeft ook gelijk als het kosten als een architectuurkwestie beschouwt.

Dit is geen “we optimaliseren het later”-probleem.

Als je standaard elke taak naar het zwaarste model stuurt, werkt dat misschien geweldig in een demo en stort het in onder de economie van productie.

Daarom denk ik dat de stukken over:

routing
batching
caching
provisioned throughput
quotabeheer

belangrijker zijn dan veel mensen zouden denken.

Teams die kostendiscipline behandelen als onderdeel van het systeemontwerp, zullen veel beter standhouden dan teams die het als latere opschoning zien.

Mijn mening

Dit is een nuttig Foundry-stuk omdat het over AI-systemen spreekt zoals ervaren engineers ze echt moeten draaien.

Niet als demo’s. Niet als eenmalige prototypes. En niet als leaderboard-toerisme.

Maar als operating systems voor workloads, constraints, trade-offs en voortdurende verandering.

We moeten dat gesprek blijven optrekken.

En als je production AI-systemen bouwt, is dit precies de mindset die teams vroeg zouden moeten internaliseren.

Originele post: A Developer’s Guide to Managing Models, Cost and Quality in Microsoft Foundry