· · 3 minuti di lettura

Foundry Local sta iniziando a rendere pratico lo sviluppo di AI all'edge

Gli ultimi aggiornamenti di Foundry Local ampliano il supporto alle lingue, il supporto Linux ARM64, i flussi di annullamento e l'accelerazione Windows. La storia più grande è che lo sviluppo di AI locale e all'edge sta diventando più facile da mettere in produzione.

Microsoft Foundry Local AI Edge AI AI Developer Tools
Questo articolo è disponibile anche in:English, Català, Español, Deutsch, Français, Português, 日本語, 中文, 한국어, Русский, हिन्दी, Polski, Türkçe, العربية, Bahasa Indonesia, Nederlands

Questo articolo è stato tradotto automaticamente. Per la versione originale, fai clic qui.

L’AI all’edge sembra entusiasmante finché non devi impacchettarla, eseguirla, ottimizzarla e supportarla su hardware reale.

Ecco perché l’ultimo aggiornamento di Foundry Local si distingue.

La release amplia il supporto esattamente nei punti che trasformano una demo in qualcosa di realmente distribuibile:

  • trascrizione multilingue
  • supporto Linux ARM64
  • supporto all’annullamento
  • miglioramenti a Windows ML
  • portabilità hardware più ampia

L’articolo sorgente parte dal punto giusto

Mi piace che l’articolo originale inizi riconoscendo una verità che gli sviluppatori già conoscono:

L’AI non è più confinata agli esperimenti cloud.

Sembra ovvio, ma è importante perché cambia i requisiti.

Una volta che l’AI si sposta nelle app, nei sistemi edge, negli AI PC e negli ambienti regolati, la piattaforma deve risolvere molto più dell’accesso all’inferenza.

Deve risolvere:

  • impacchettamento
  • differenze di runtime
  • supporto hardware
  • flussi di annullamento e controllo
  • coerenza del deployment
  • vincoli di privacy ed esecuzione locale

Qui l’AI locale diventa vera ingegneria, oppure resta una bella idea da keynote.

Perché questa release sembra più pratica che aspirazionale

Quello che apprezzo qui è che l’annuncio non cerca di impressionarmi con una grande promessa astratta.

Migliora esattamente i pezzi che rendono l’AI locale difficile nella pratica:

  • più lingue nella trascrizione live
  • supporto Linux ARM64
  • supporto all’annullamento tra gli SDK
  • accelerazione Windows più semplice con WinML 2.0
  • portabilità dei dispositivi più forte

Non è glamour.

È utile.

E l’utile è ciò che porta davvero i team dall’esperimento al prodotto.

L’esempio vocale di GitHub Copilot CLI è una prova intelligente

Una parte che mi è piaciuta molto è la spiegazione concreta che l’input vocale di GitHub Copilot CLI è basato su Foundry Local.

È molto meglio di una demo vaga del tipo “guardate cosa è possibile”.

Mostra:

  • un workflow reale
  • una superficie prodotto reale
  • domande reali di performance
  • valore reale dell’esecuzione locale

Questo rende la storia della piattaforma molto più solida.

Privacy e portabilità sono i veri temi di lungo periodo

La parte che osserverei più da vicino non è una singola aggiunta API.

È la combinazione di:

  • esecuzione privacy-first
  • portabilità hardware
  • supporto al deployment ibrido/llocale
  • controllo pronto per l’azienda

Questa combinazione è ciò che rende l’AI locale valida oltre gli esperimenti di nicchia.

Perché, per molti workload, la storia locale non riguarda solo la latenza. Riguarda il controllo.

La mia opinione

Il cambiamento importante qui è che l’AI locale inizia a sembrare meno un caso speciale e più un vero obiettivo di ingegneria.

Sono buone notizie per gli sviluppatori che tengono a privacy, reattività, varietà hardware e AI che gira più vicino al dispositivo.

Ed è per questo che Foundry Local merita più attenzione di quanta ne ricevano di solito la maggior parte degli annunci “AI at the edge”.

Articolo originale: Accelerate Edge AI Development with Foundry Local

Condividi:
Vedi il codice sorgente di questo articolo su GitHub ↗
← dotnet new WinUI: Crea app Windows senza toccare Visual Studio
Foundry Local 1.1: Trascrizione in Tempo Reale, Embeddings e l'API di Risposta →