· · 2 minut czytania

Foundry Local zaczyna sprawiać, że tworzenie AI na brzegu staje się praktyczne

Najnowsze aktualizacje Foundry Local rozszerzają obsługę języków, wsparcie Linux ARM64, przepływy anulowania i przyspieszenie w Windows. Większa historia jest taka, że lokalne i brzegowe tworzenie AI staje się coraz łatwiejsze do wdrożenia operacyjnego.

Microsoft Foundry Local AI Edge AI AI Developer Tools
Ten post jest dostępny również w:English, Català, Español, Deutsch, Français, Português, Italiano, 日本語, 中文, 한국어, Русский, हिन्दी, Türkçe, العربية, Bahasa Indonesia, Nederlands

Ten wpis został przetłumaczony automatycznie. Aby zobaczyć oryginał, kliknij tutaj.

AI na brzegu brzmi ekscytująco, dopóki nie trzeba jej spakować, uruchomić, zoptymalizować i wspierać na prawdziwym sprzęcie.

Dlatego najnowsza aktualizacja Foundry Local się wyróżnia.

Wersja rozszerza wsparcie dokładnie tam, gdzie zamienia demo w coś naprawdę gotowego do wdrożenia:

  • transkrypcja wielojęzyczna
  • wsparcie Linux ARM64
  • obsługa anulowania
  • ulepszenia Windows ML
  • szersza przenośność sprzętowa

Artykuł źródłowy zaczyna od właściwego miejsca

Podoba mi się, że oryginalny artykuł zaczyna od uznania prawdy, którą developerzy już znają:

AI nie jest już zamknięta w eksperymentach chmurowych.

Brzmi to oczywiście, ale ma znaczenie, bo zmienia wymagania.

Gdy AI przenosi się do aplikacji, systemów edge, AI PC i środowisk regulowanych, platforma musi rozwiązać znacznie więcej niż sam dostęp do inferencji.

Musi rozwiązać:

  • pakowanie
  • różnice runtime
  • wsparcie sprzętowe
  • przepływy anulowania i kontroli
  • spójność wdrożeń
  • ograniczenia prywatności i lokalnego wykonywania

To tutaj lokalne AI staje się prawdziwą inżynierią, albo zostaje tylko dobrą ideą z keynote.

Dlaczego ta wersja wydaje się bardziej praktyczna niż aspiracyjna

To, co tu doceniam, to fakt, że ogłoszenie nie próbuje zaimponować jedną wielką abstrakcyjną obietnicą.

Poprawia dokładnie te elementy, które sprawiają, że lokalne AI jest trudne w praktyce:

  • więcej języków w transkrypcji na żywo
  • wsparcie Linux ARM64
  • obsługa anulowania w SDK
  • prostsze przyspieszenie Windows dzięki WinML 2.0
  • lepsza przenośność między urządzeniami

To nie jest efektowne.

To jest użyteczne.

A użyteczne rzeczy naprawdę prowadzą zespoły od eksperymentu do produktu.

Przykład głosowy GitHub Copilot CLI to sprytny dowód

Jedną z części, które szczególnie mi się podobały, było konkretne wyjaśnienie, że wejście głosowe GitHub Copilot CLI jest oparte na Foundry Local.

To znacznie lepsze niż ogólne demo w stylu “zobaczcie, co jest możliwe”.

Pokazuje:

  • prawdziwy workflow
  • prawdziwą powierzchnię produktu
  • prawdziwe pytania o wydajność
  • prawdziwą wartość lokalnego wykonywania

To sprawia, że historia platformy staje się dużo solidniejsza.

Prywatność i przenośność to prawdziwe tematy długoterminowe

Część, którą obserwowałbym najbliżej, to nie żadna pojedyncza zmiana API.

To kombinacja:

  • wykonywania z pierwszeństwem prywatności
  • przenośności sprzętowej
  • wsparcia wdrożeń hybrydowych/lokalnych
  • kontroli gotowej dla przedsiębiorstw

Ta kombinacja sprawia, że lokalne AI staje się użyteczne poza niszowymi eksperymentami.

Bo w wielu workloadach lokalna historia nie dotyczy tylko opóźnienia. Dotyczy kontroli.

Moja opinia

Ważna zmiana polega na tym, że lokalne AI zaczyna wyglądać mniej jak przypadek specjalny, a bardziej jak realny cel inżynieryjny.

To dobra wiadomość dla developerów, którym zależy na prywatności, responsywności, różnorodności sprzętu i AI działającym bliżej urządzenia.

I dlatego Foundry Local zasługuje na więcej uwagi niż większość ogłoszeń o “AI at the edge”.

Oryginalny artykuł: Accelerate Edge AI Development with Foundry Local

Udostępnij:
Zobacz kod źródłowy tego posta na GitHub ↗
← dotnet new WinUI: Tworzenie aplikacji Windows bez dotykania Visual Studio
Foundry Local 1.1: Transkrypcja w Czasie Rzeczywistym, Embeddings i Responses API →