Google Linux w AI OS: COS i gLinux to różne systemy

„Google Linux” nie jest nazwą jednej dystrybucji, którą firma może po prostu zainstalować jako platformę AI. W tym kontekście trzeba odróżnić Container-Optimized OS (COS) dla kontenerów w Google Cloud od gLinux, wewnętrznego systemu stacji roboczych Google. Dają różne lekcje dla suwerennego AI OS.

COS: węzeł kontenerowy, nie pełna platforma AI

COS jest obrazem systemu dla maszyn Compute Engine i węzłów GKE, zoptymalizowanym pod kontenery. Google opisuje mały zakres pakietów, zabezpieczenia domyślne oraz gotowe runtime’y kontenerowe. Dokumentacja ma też instrukcję uruchamiania węzłów GPU, co czyni COS praktycznym hostem serwera inferencji w GCP. Nie jest natomiast typowym desktopem do notebooków ani systemem, w którym należy ręcznie instalować dowolne biblioteki na hoście.

W architekturze AI model, dane i API działają w kontenerach, a COS utrzymuje hosta. To ułatwia odtwarzanie węzłów i ogranicza przypadkowe zmiany na maszynie. Jeżeli jednak aplikacja wymaga niestandardowego sterownika, modułu jądra lub usługi hostowej, trzeba sprawdzić zgodność z konkretnym obrazem COS i wersją GKE.

gLinux: przykład zarządzania flotą, nie produkt do kupienia

Google opisało gLinux Rodete jako wewnętrzną dystrybucję desktopową opartą na Debian Testing. Zespół Google buduje pakiety, testuje je i wypuszcza falami na własną flotę. To cenna inspiracja dla zespołów AI: małe, częste aktualizacje, testy przyjęcia i etapowe wdrożenie. Nie traktuj gLinux jako publicznego obrazu, którego dostawca wspiera dla Twojego serwera GPU.

Co z suwerennością?

Publiczne pochodzenie części kodu COS nie zmienia faktu, że jego opisany przez Google przypadek użycia jest silnie związany z Compute Engine i GKE. Gdy wymaganiem jest lokalna instalacja oraz niezależność od dostawcy chmury, Debian, Ubuntu, Rocky lub RHEL mogą być prostszą bazą. Jeśli organizacja świadomie akceptuje GCP, COS może zmniejszyć pracę administracyjną. Ważny jest test przeniesienia kontenera, danych i uprawnień na inny klaster.

AI SDLC: czego uczyć się od Google?

Przy kodowaniu z agentami nie kopiuj automatycznie skryptu z desktopowego gLinux na host COS. Zamiast tego buduj obraz aplikacji, sprawdzaj go na wersji COS używanej w produkcji i wdrażaj etapami. W AI SDLC agent może przygotować testy i manifesty, a bramka człowieka powinna ocenić sterowniki GPU, prawa dostępu do modeli i możliwość cofnięcia zmiany. Podobny kompromis między otwartym kodem hosta a zależnością od chmury omawia Azure Linux.

Przykład: agent i model na węźle GKE

Zespół wdraża serwer modelu i agenta analizującego zgłoszenia. COS utrzymuje węzeł, a każdy składnik aplikacji jest kontenerem. Dobry podział oznacza, że agent dostaje osobne konto i tylko odczyt zgłoszeń, model nie ma dostępu do systemu biletowego, a wyniki przechodzą przez API z logowaniem decyzji. Jeśli kontener modelu wymaga ręcznej instalacji biblioteki na hoście, to sygnał, że obraz aplikacji lub wybór hosta trzeba poprawić.

Zrób próbę aktualizacji węzła. Czy żądania przechodzą na inne repliki? Czy po restarcie model ładuje się z kontrolowanego magazynu, a nie z przypadkowej wersji pobranej z internetu? Czy nowy węzeł ma zgodny sterownik GPU? Te pytania są ważniejsze niż sama nazwa obrazu systemowego.

Czego nie kopiować z gLinux?

Wewnętrzny model Google opiera się na dużej flocie, własnej infrastrukturze budowy pakietów, testach i etapowym wdrożeniu. Mała firma nie musi odtwarzać całej tej machiny. Może przyjąć zasadę: podpisany obraz, test na małej grupie, pomiar zdrowia usług i możliwość powrotu. Takie praktyki wzmacniają suwerenność niezależnie od tego, czy hostem jest COS, Debian czy Ubuntu. Nie zakładaj, że dostęp do technologii Google oznacza dostęp do jego wewnętrznego procesu operacyjnego.

Przy wyborze COS zapisz, które narzędzia są standardowymi kontenerami, a które wymagają API Google Cloud. Dla każdego zależnego elementu określ odpowiednik, format eksportu i szacowany czas migracji. Jeśli plan przeniesienia da się wykonać tylko po przepisaniu aplikacji, COS nie jest głównym źródłem uzależnienia; są nim integracje nad nim. Taki rozdział pomaga ocenić system uczciwie, bez przypisywania mu winy za decyzje aplikacyjne.