Wnioskowanie AI na Windows Server

Wnioskowanie lokalne AI to proces uruchamiania wytrenowanego modelu AI na infrastrukturze, którą kontrolujesz ty lub twoja organizacja. Głównym scenariuszem Windows Server jest wnioskowanie rozproszone: serwer modelu kompatybilny z OpenAI działa na Windows Server, a zdalni klienci wysyłają żądania do jego punktu końcowego przez sieć. Na przykład Visual Studio Code na stacji roboczej z systemem Windows 11 może wysyłać monity do serwera i odbierać wygenerowane dane wyjściowe.

Organizacje stosują wnioskowanie rozproszone, aby dać wielu klientom dostęp do współdzielonego modelu obliczeniowego, jednocześnie kontrolując trasę żądań i wyników. Ta kontrola zależy od lokalizacji punktu końcowego, ścieżki sieciowej, konfiguracji klienta, pozyskiwania modelu, diagnostyki i innych usług w rozwiązaniu.

Ten artykuł pomaga administratorom i programistom Windows Server zdecydować, kiedy użyć wnioskowania lokalnego oraz zidentyfikować kwestie infrastrukturalne związane z tym wyborem.

Jak działa wnioskowanie AI na Windows Server

Korzystając z lokalnego wnioskowania AI na Windows Server, zdalne aplikacje i narzędzia łączą się z adresem sieciowym serwera modelu, wysyłają żądania i otrzymują odpowiedzi. Klienci nie ładują ani nie uruchamiają modelu lokalnie.

Ta topologia nadaje Windows Server odrębną rolę. Serwer centralizuje zasoby obliczeniowe i GPU, przechowywanie i hostowanie modeli, dostęp do sieci, obsługę usług oraz zarządzanie zasobami dla wielu klientów. Administratorzy obsługują współdzieloną usługę i jej infrastrukturę, podczas gdy deweloperzy konfigurują klientów pod kątem bazowego adresu URL punktu końcowego, identyfikatora modelu, obsługiwanego API oraz metody uwierzytelniania.

Rozwiązanie zawiera następujące elementy:

  • Zdalny klient: Aplikacja, narzędzie programistyczne lub narzędzie administracyjne, które wysyła prompty lub inne dane wejściowe do modelu przez sieć. Klienci mogą działać na Windows 11, Windows Server lub innej obsługiwanej platformie.
  • Interfejs: API SDK lub HTTP definiujące formaty żądań i odpowiedzi. Wiele współdzielonych runtime'ów udostępnia na przykład API kompatybilne z OpenAI.
  • Serwer modeli i model: Środowisko uruchomieniowe zorientowane na serwer, które ładuje wytrenowany model, planuje żądania inferencji i zwraca dane wyjściowe za pośrednictwem punktu końcowego.
  • Infrastruktura Windows Server: Fizyczny host lub maszyna wirtualna, procesor, pamięć, pamięć masowa, zasoby GPU, sieć i narzędzia zarządzające, które wspierają i udostępniają wspólne obciążenie.

Punkt końcowy implementuje jeden lub więcej formatów API, których używają klienci, ale kompatybilność nie oznacza, że każdy endpoint obsługuje każdą funkcjonalność. Klienci mogą wymagać konkretnych tras, identyfikatorów modeli, zachowania strumieniowego, wywoływania narzędzi lub funkcji, metod uwierzytelniania lub pól żądań. Potwierdź zarówno wymagania klienta, jak i możliwości punktu końcowego przed ich połączeniem.

Wnioskowanie wbudowane ma inną granicę. Aplikacja ładuje i uruchamia model na tym samym urządzeniu, często w procesie aplikacji, zamiast wywoływać serwer modelu. Windows ML zapewnia tę strukturę inferencyjną aplikacji dla modeli ONNX. Foundry Local jest również ukierunkowany na obsługę przepływów pracy na samym urządzeniu. Foundry Local SDK osadza środowisko uruchomieniowe w aplikacji, a jego interfejs wiersza poleceń zarządza modelami i usługą lokalną na jednym urządzeniu. Te opcje mogą działać na sprzęcie Windows Server, ale same w sobie nie zapewniają rozproszonej usługi wnioskowania, którą administratorzy obsługują centralnie dla wielu klientów.

Wybierz podejście do wnioskowania

Wybierz podejście na podstawie tego, gdzie prowadzone jest wnioskowanie, ilu klientów potrzebuje modelu oraz kto obsługuje czas działania. Używaj Windows Server jako współdzielonego endpointu do centralizacji modeli i obliczeń dla zdalnych klientów. Takie podejście dodaje wymagania dotyczące sieci, bezpieczeństwa, pojemności i dostępności. Alternatywnie w systemie Windows Server można użyć inferencji wbudowanej lub inferencji na urządzeniu, gdy jedna aplikacja lub jedno urządzenie powinny zarządzać środowiskiem uruchomieniowym i cyklem życia modelu.

Approach Najlepsze dopasowanie Model operacyjny Ważne granice
Punkt końcowy systemu Windows Server Wiele zdalnych aplikacji lub narzędzi, które zużywają modelową usługę, którą zarządza centralny zespół operacyjny Serwer modeli na Windows Server zarządza ładowaniem modeli, harmonogramowaniem żądań, współbieżnością oraz API. Zdalni klienci korzystają z bazowego adresu URL punktu końcowego, identyfikatora modelu oraz ustawień uwierzytelniania, które zatwierdza ich organizacja. Wybrany przez Ciebie produkt decyduje o instalacji w czasie uruchomienia, wdrożeniu endpointów, wsparciu API oraz cechach skalowania. Ten artykuł zakłada, że ten punkt końcowy istnieje i klienci mogą do niego dotrzeć.
Windows ML Aplikacje Windows, które uruchamiają modele ONNX na tym samym urządzeniu Aplikacja korzysta z ONNX Runtime, który obsługuje Windows, zarówno jako współdzielony komponent systemowy, jak i samodzielnie z aplikacją. Dostawcy wykonawczy opcjonalnie korzystają z dostępnych zasobów CPU, GPU lub NPU. Windows ML to platforma inferencyjna dla aplikacji, a nie zgodny z OpenAI punkt końcowy do udostępniania modeli. Wymagania dostawcy wykonawczego, sterownika, sprzętu i modelu są różne.
Znaleziono lokalnie Aplikacje i przepływy pracy programistycznej wymagające wnioskowania lokalnego na pojedynczym urządzeniu oraz wyselekcjonowanego katalogu modeli Aplikacja zazwyczaj uruchamia wnioskowanie w ramach procesu za pośrednictwem zestawu SDK. Foundry Local CLI może zarządzać modelami i lokalną usługą na urządzeniu. Foundry Local może działać na sprzęcie serwerowym, ale jego konstrukcja nie jest nastawiona na wnioskowanie serwerów wieloużytkownikowych. Nie zapewnia równoległego kolejkowania żądań, ciągłego grupowania ani efektywnego współdzielenia GPU dla wielu jednoczesnych klientów.

Te podejścia nie wykluczają się w całej organizacji. Jedna aplikacja może osadzać model ONNX w Windows ML, programista może używać Foundry Local na jednej stacji roboczej, a narzędzia zdalnego programowania i aplikacje biznesowe mogą korzystać z wspólnego endpointu na Windows Server. Traktuj każdą ścieżkę jako osobne obciążenie z własnym modelem, sprzętem, bezpieczeństwem i wymaganiami wsparcia.

Zaplanuj infrastrukturę Windows Server do wnioskowania AI

Architektura modelu, liczba parametrów, kwantyzacja, długość kontekstu, współbieżność żądań oraz cele opóźnień decydują o wymaganym obciążeniu obliczeniowym i pamięci. Niektóre modele działają na CPU, podczas gdy inne obciążenia korzystają z akceleracji GPU. GPU nie jest warunkiem koniecznym do każdego rozwiązania wnioskowania.

W przypadku obciążenia uruchomionego na fizycznym hoście z systemem Windows Server środowisko uruchomieniowe może korzystać ze sprzętu i interfejsów API obsługiwanych przez system Windows Server i producenta sprzętu. Dla obciążenia w Hyper-V maszynie wirtualnej wybierz odpowiednią opcję wirtualizacji GPU. Plan akceleracji GPU w Windows Server porównuje bezpośredni dostęp do hosta, przypisanie dyskretnego urządzenia (DDA), partycjonowanie GPU oraz scenariusze kontenerów Windows. Partycjonowanie GPU jest dostępne w Windows Server 2025 lub nowszym i stanowi opcjonalną opcję infrastruktury.

Zaplanuj także te zasoby:

  • Pamięć i pamięć GPU: uwzględnia załadowany model, wymagania dotyczące kontekstu i pamięci podręcznej, jednoczesne żądania oraz inne procesy na hostze.
  • Pamięć masowa: Zapewnienie kontroli pojemności i dostępu dla plików modeli, pakietów uruchomieniowych, logów i danych tymczasowych. Pozyskiwanie modelu może wymagać zewnętrznego połączenia sieciowego nawet gdy wnioskowanie odbywa się lokalnie.
  • Sieć: Dla wspólnego punktu końcowego oszacuj przepustowość i opóźnienia między klientami a punktem końcowym. Określ, które sieci i hosty mogą dotrzeć do usługi.
  • Dostępność i pojemność: Decyduj o zachowaniu klientów, gdy punkt końcowy jest niedostępny lub działa na pełnych obrotach. Zweryfikowaj współbieżność i przepustowość za pomocą reprezentatywnych modeli i żądań przed użyciem produkcyjnym.

Zabezpieczenie i działanie wnioskowania AI na Windows Server

Lokalna lokalizacja sama w sobie nie stanowi granicy bezpieczeństwa. Określ granicę, w której muszą pozostać prompty, pobrane dane, pliki modelu, wyjścia, logi i diagnostyka, a następnie weryfikuj każdy komponent względem tej granicy.

Chroń ruch sieciowy za pomocą zatwierdzonych ustawień TLS, uwierzytelniaj i autoryzuj klientów, ograniczaj dostęp do punktów końcowych za pomocą kontroli sieciowej oraz przechowuj dane uwierzytelniające w zatwierdzonym magazynie tajnych. Nie umieszczaj danych poświadczeniowych w plikach źródłowych ani konfiguracji narzędzi, które inni użytkownicy mogą przeczytać. Przejrzyj licencje modeli i źródła pozyskiwania przed wdrożeniem plików modeli.

Zweryfikowaj wyniki modelu, zanim na nich polegasz. Utrzymuj odpowiedni nadzór ludzki nad podejmowanymi działaniami lub decyzjami.

Zarządzaj infrastrukturą Windows Server za pomocą istniejących narzędzi administracyjnych, w tym Windows Admin Center, gdy obsługuje wymagane operacje. Postępuj zgodnie z dokumentacją środowiska uruchomieniowego dotyczącą cyklu życia modelu i operacji specyficznych dla punktów końcowych. Przynajmniej należy obserwować stan punktów końcowych, opóźnienia żądań, przepustowość, awarie, zużycie CPU i pamięci, wykorzystanie GPU i zużycie pamięci, jeśli to możliwe, oraz pojemność pamięci. Dostępne metryki i operacje zarządzania różnią się w zależności od czasu działania, dlatego ten artykuł nie przewiduje jednej implementacji obserwowalności.

Typowe scenariusze wnioskowania lokalnego AI

Wnioskowanie lokalne może wspierać obciążenia dla deweloperów, administratorów i aplikacji, jednocześnie utrzymując ścieżkę wnioskowania w wyznaczonych granicach organizacji.

  • Pomoc w programowaniu: Podłącz wspierane narzędzie programistyczne, takie jak Visual Studio Code na Windows 11, z istniejącym punktem końcowym na Windows Server w celu wyjaśnień, generowania, przeglądu lub rozwiązywania problemów. Kod źródłowy i prompty przechodzą przez sieć do tego punktu końcowego, więc w granicy danych uwzględniają ścieżkę sieciową, punkt końcowy oraz jej operatorów.
  • Pomoc administracyjna: Połącz narzędzie administracyjne z modelem, który może wyjaśnić lub zaproponować polecenia. Przejrzyj wygenerowane polecenia i zrozum ich efekty przed ich uruchomieniem, zwłaszcza gdy zmieniają stan systemu.
  • Przetwarzanie dokumentów: Użyj aplikacji do streszczania, klasyfikacji, wyodrębniania lub indeksowania dokumentów za pomocą lokalnego modelu. Aplikacja pozostaje odpowiedzialna za autoryzację dokumentów źródłowych oraz generowane wyniki.
  • Aplikacje konwersacyjne: Dodaj doświadczenia czatu lub odpowiadania na pytania do istniejącej aplikacji. Aplikacja może łączyć endpoint modelu z autoryzowanymi danymi przedsiębiorstwa, ale musi egzekwować kontrole dostępu niezależnie od modelu.

Kolejne kroki dotyczące wnioskowania lokalnego AI na Windows Server