AlphaFold: Protein Structure Prediction

Cześć, tu Alex z DEV STORIES DOT EU. AlphaFold: Przewidywanie struktury białek, odcinek 1 z 21. Przez pięćdziesiąt lat naukowcy potrafili odczytać surowy tekst naszego DNA, ale nie potrafili przewidzieć, co ten tekst tak naprawdę zbuduje. Mieli kod źródłowy życia, ale nie mieli pojęcia, jak kompiluje się on w fizyczne maszyny napędzające nasze komórki. To wielkie wyzwanie jest znane jako problem fałdowania białek. Białka to molekularne maszyny, które utrzymują cię przy życiu. Zajmują się niemal wszystkim, co dzieje się w twoim ciele, od transportu tlenu we krwi po zwalczanie infekcji. Każde białko zaczyna swoje życie jako jednowymiarowy string. Ten string jest zbudowany ze słownika dwudziestu różnych chemicznych bloków budulcowych zwanych aminokwasami. Pomyśl o sekwencji aminokwasów jak o surowym kodzie źródłowym biologii. To liniowy string znaków, czytany sekwencyjnie. Ale prosta linia aminokwasów nie może wykonać żadnej rzeczywistej pracy. Tak jak zwykły plik tekstowy musi zostać skompilowany do wykonywalnej binarki, żeby można było go uruchomić, tak jednowymiarowa sekwencja aminokwasów musi zwinąć się w bardzo specyficzny, trójwymiarowy kształt. W świecie biologii kształt całkowicie dyktuje funkcję. Fizyczne kontury białka determinują to, z czym może ono wchodzić w interakcje. Białko zwinięte w kształt kieszeni może złapać i rozłożyć konkretną cząsteczkę cukru. Białko zwinięte w sztywną rurkę może pełnić funkcję wsparcia strukturalnego dla komórki. Jeśli proces fałdowania pójdzie nie tak, biologiczny program crashuje. U ludzi nieprawidłowo sfałdowane białka są główną przyczyną wielu poważnych chorób. Sekwencja aminokwasów zawiera wszystkie instrukcje potrzebne do utworzenia tej konkretnej, trójwymiarowej struktury. Różne aminokwasy mają różne właściwości chemiczne. Niektóre noszą ładunki dodatnie lub ujemne i działają jak magnesy. Niektóre odpychają wodę i próbują ukryć się w środku struktury, podczas gdy inne są przyciągane przez wodę i pchają się na zewnątrz. Te konkurujące ze sobą siły fizyczne sprawiają, że string plącze się, skręca i wskakuje w jedną, stabilną konfigurację. Oto kluczowe spostrzeżenie. Matematyka stojąca za tym procesem fałdowania jest oszałamiająca. Typowy chain białkowy składa się z setek aminokwasów. Liczba możliwych sposobów, na jakie tak długi chain może się zgiąć, wynosi około dziesięć do potęgi trzysta. Naukowiec Cyrus Levinthal zauważył, że gdyby białko sekwencyjnie sprawdzało każdy możliwy kształt, żeby znaleźć ten właściwy, proces ten trwałby dłużej niż wiek wszechświata. A jednak w twoich komórkach nowy string białkowy wskakuje w swój prawidłowy kształt w ciągu kilku milisekund. Problem fałdowania białek to próba wypełnienia tej luki. To wyzwanie polegające na wzięciu jednowymiarowej sekwencji aminokwasów jako jedynego inputu i obliczeniowym przewidzeniu jej ostatecznej, trójwymiarowej struktury. Historycznie naukowcy musieli polegać na powolnych, fizycznych technikach laboratoryjnych, żeby mapować te struktury. Metody takie jak krystalografia rentgenowska polegały na zamrażaniu białek w kryształy i strzelaniu w nie wiązkami, żeby zmierzyć kąty rozproszonego światła. Odkrycie struktury pojedynczego białka mogło zająć lata żmudnych prób i błędów. Ponieważ technologia sekwencjonowania genetycznego wyprzedziła fizyczne mapowanie, społeczność naukowa zgromadziła setki milionów znanych, jednowymiarowych sekwencji, ale zmapowała struktury 3D tylko dla ich ułamka. Mieliśmy nieskończone linijki kodu źródłowego, ale żadnego dekompilatora, który pokazałby nam wykonującą się logikę. Obliczeniowe rozwiązanie problemu fałdowania białek daje nam dokładne, mechaniczne schematy biologii, zmieniając odkrywanie leków z powolnego procesu laboratoryjnego zgadywania w precyzyjną, ukierunkowaną inżynierię. Jeśli podoba ci się podcast i chcesz wesprzeć program, możesz wyszukać DevStoriesEU na Patreonie. To wszystko w tym odcinku. Dzięki za słuchanie i buduj dalej!

Cześć, tu Alex z DEV STORIES DOT EU. AlphaFold: Przewidywanie struktury białek, odcinek 2 z 21. Chcesz przewidzieć fizyczny kształt pojedynczej sekwencji białkowej, ale samo patrzenie na tę sekwencję nie wystarczy. Aby dowiedzieć się, jak się zwija, musisz zbadać jej ewolucyjne drzewo genealogiczne, żeby wykryć zsynchronizowane wzorce mutacji na przestrzeni milionów lat. Zrozumienie, jak algorytm przetwarza te ewolucyjne wzorce, to dokładnie to, co omawiamy w Inside AlphaFold 2: Architecture Overview. Architektura działa jak ciągły przepływ danych, przekształcając string liter aminokwasów w kształt 3D. Zaczyna się od sekwencji docelowej. Zanim nastąpi jakiekolwiek przetwarzanie przez sieć neuronową, AlphaFold przeszukuje ogromne biologiczne bazy danych, aby zebrać dwa konkretne inputy na podstawie tej sekwencji. Pierwszy input to Multiple Sequence Alignment, czyli MSA. Jest to zbiór podobnych sekwencji białkowych pochodzących od innych organizmów. Jeśli dwa aminokwasy w sekwencji stale mutują razem u różnych gatunków, prawdopodobnie fizycznie się stykają w ostatecznej, zwiniętej strukturze. Drugi input składa się z szablonów strukturalnych. Są to znane trójwymiarowe struktury białek, które są bardzo podobne do twojej sekwencji docelowej. Te surowe MSA i szablony trafiają bezpośrednio do Embedding layer. Embedding layer tłumaczy te biologiczne dane na dwa odrębne matematyczne formaty, które sieć neuronowa może przetworzyć. Są to MSA representation oraz Pair representation. MSA representation to macierz przechowująca historię ewolucyjnych mutacji. Pair representation to abstrakcyjna, dwuwymiarowa siatka śledząca potencjalną odległość i fizyczną relację między każdą możliwą parą aminokwasów w sekwencji. Po utworzeniu, obie reprezentacje trafiają do stacku Evoformer. Evoformer to silnik AlphaFold 2, składający się z 48 odrębnych bloków przetwarzania. I tu jest kluczowa sprawa. Wewnątrz każdego bloku, MSA representation i Pair representation komunikują się ze sobą. Wymieniają się informacjami, aby udoskonalić swoje dane. Jeśli dane ewolucyjne w MSA representation silnie sugerują interakcję dwóch aminokwasów, aktualizuje ona Pair representation, aby zbliżyć je do siebie na abstrakcyjnej siatce odległości. I odwrotnie, jeśli Pair representation zda sobie sprawę, że umieszczenie dwóch aminokwasów razem narusza fizyczne ograniczenia przestrzenne, aktualizuje MSA representation, aby ponownie ocenić ten ewolucyjny link. Ta wzajemna komunikacja odbywa się w sposób ciągły, gdy dane przepływają przez wszystkie 48 bloków, tworząc bardzo dokładną mapę wewnętrznych relacji. Ludzie często zakładają, że Evoformer generuje ostateczny fizyczny kształt, ale tak nie jest. Evoformer buduje jedynie abstrakcyjne matematyczne reprezentacje odległości i ewolucyjnych linków. Jego outputem są wysoce udoskonalone macierze danych, a nie fizyczny obiekt. Aby uzyskać rzeczywisty zwinięty kształt, dane opuszczają 48. blok Evoformera i trafiają do Structure Module. Structure Module pobiera udoskonaloną Pair representation oraz oryginalne dane sekwencji, a następnie przekształca tę abstrakcyjną siatkę na rzeczywiste współrzędne atomowe 3D. Przypisuje dokładne położenie X, Y i Z w przestrzeni każdemu atomowi w szkielecie białka i jego łańcuchach bocznych. Sukces AlphaFold 2 opiera się na tym, że Evoformer nieustannie wymusza spójność między ewolucyjną historią a ograniczeniami przestrzennymi, zanim zostanie wyznaczona choćby jedna współrzędna 3D. To wszystko w tym odcinku. Dzięki za wysłuchanie i buduj dalej!

Cześć, tu Alex z DEV STORIES DOT EU. AlphaFold: Predykcja struktury białka, odcinek 3 z 21. Najpotężniejszą cechą modelu AI nie zawsze jest jego output, ale to, że potrafi ci dokładnie powiedzieć, kiedy zgaduje. Jeśli spojrzysz na wygenerowany model białka i założysz, że każda pętla i domena są w rzeczywistości idealnie na swoim miejscu, twoje dalsze eksperymenty najpewniej się nie udadzą. Żeby bezpiecznie korzystać z tych modeli, musisz zrozumieć ocenę predykcji: pLDDT i PAE. AlphaFold zwraca dwie różne metryki, żeby określić poziom swojej niepewności. Pierwsza to pLDDT, czyli predicted Local Distance Difference Test. Ocenia ona lokalną pewność modelu. Dla każdej pojedynczej reszty aminokwasowej w białku, AlphaFold przypisuje wynik od 0 do 100. Ten wynik mówi ci, jak bardzo sieć jest pewna lokalnej struktury szkieletu. Kiedy wynik dla danej reszty przekracza 90, masz do czynienia z bardzo wysoką pewnością. Na tym poziomie nawet orientacje łańcuchów bocznych są zazwyczaj wiarygodne. Wynik między 70 a 90 to wciąż dobra, godna zaufania predykcja szkieletu. Gdy wynik spada poniżej 70, pewność staje się wątpliwa. I tu jest kluczowa sprawa. Kiedy widzisz wynik pLDDT poniżej 50, twoim pierwszym instynktem może być myśl, że model nie znalazł właściwego sfałdowania. Zazwyczaj to nieprawda. Bardzo niski wynik pLDDT często wskazuje na wewnętrznie nieuporządkowany region. Białko fizycznie nie ma stałej struktury w izolacji. Może to być elastyczny linker lub ogon, który zwija się tylko wtedy, gdy wiąże się z inną cząsteczką. AI wcale tu nie zawodzi; trafnie przewiduje, że ten kawałek białka jest po prostu naturalnie wiotki. Choć pLDDT świetnie sprawdza się przy lokalnych sfałdowaniach, ma jeden poważny martwy punkt. Ocenia regiony w izolacji. Wyobraź sobie białko z dwiema całkowicie oddzielnymi domenami strukturalnymi, połączonymi długim łańcuchem aminokwasów. Odpalasz predykcję, sprawdzasz pLDDT i widzisz, że obie domeny mają wynik powyżej 90. Ich wewnętrzne struktury są solidne. Jednak pLDDT nie powie ci, czy te dwie domeny są poprawnie ułożone względem siebie w przestrzeni trójwymiarowej. Aby to rozwiązać, AlphaFold dostarcza drugą metrykę o nazwie Predicted Aligned Error, czyli w skrócie PAE. Ta metryka ocenia względne położenie domen. PAE mierzy oczekiwany błąd odległości między dowolnymi dwiema konkretnymi resztami w białku. Logika opiera się na prostym pytaniu: jeśli idealnie dopasujemy predykcję do rzeczywistej struktury na reszcie X, o ile angstremów odchylona będzie reszta Y? To daje ci dwuwymiarową siatkę błędów dla każdej pary. Wracając do scenariusza z białkiem o dwóch domenach, jeśli sprawdzisz PAE między resztami wewnątrz pierwszej domeny, błąd będzie bardzo niski. To samo dotyczy wnętrza drugiej domeny. Ale jeśli sprawdzisz PAE między resztą w pierwszej domenie a resztą w drugiej domenie, błąd może być bardzo wysoki. Wysokie PAE między domenami oznacza, że ich względna orientacja jest całkowicie niepewna. Model dokładnie wie, jak wyglądają te dwa oddzielne kształty, ale nie ma pojęcia, pod jakim kątem są do siebie ułożone. Musisz oceniać obie metryki razem, żeby zrozumieć pełny obraz. Używasz pLDDT, żeby móc zaufać lokalnemu sfałdowaniu i zidentyfikować obszary naturalnego nieporządku. Polegasz na PAE, żeby zweryfikować, czy ogólne, globalne ułożenie tych odrębnych, sfałdowanych części jest rzeczywiście stałe, czy to tylko przestrzenne zgadywanie algorytmu. Nigdy nie traktuj przewidzianej struktury jako jedynej, sztywnej prawdy; traktuj ją jak mapę prawdopodobieństw, na której każda domena i linker ma swój własny dowód wiarygodności. Dzięki za spędzenie ze mną tych kilku minut. Do usłyszenia następnym razem, trzymaj się.

Cześć, tu Alex z DEV STORIES DOT EU. AlphaFold: Przewidywanie struktury białek, odcinek 4 z 21. Trenowanie przełomowego modelu machine learning jest imponujące, ale dla pracującego biologa surowa sieć neuronowa to po prostu kolejne ciężkie narzędzie do skonfigurowania. Żeby naprawdę zmienić tę dziedzinę, nie możesz po prostu opublikować modelu. Używasz go, żeby sfałdować niemal każde znane białko na Ziemi, a wyniki wrzucasz do sieci za darmo. Tym właśnie jest AlphaFold Protein Structure Database. Ta baza danych, stworzona we współpracy Google DeepMind i EMBL-EBI, zawiera ponad 200 milionów przewidzianych struktur. Ta ogromna liczba reprezentuje niemal całe znane uniwersum białek. Zamiast konfigurować hardware i samodzielnie odpalać algorytm AlphaFold, całkowicie pomijasz compute i robisz query do gotowych predykcji. Spójrzmy na workflow korzystania z web interface'u. Jeśli badasz receptor wolnych kwasów tłuszczowych 2, wchodzisz na alphafold dot ebi dot ac dot uk i wpisujesz tę nazwę w pasek wyszukiwania. Możesz szukać po nazwie genu albo sekwencji, ale najdokładniejszą metodą jest użycie numeru akcesyjnego UniProt. Ponieważ baza danych mapuje się bezpośrednio na UniProt, każda struktura jest ściśle powiązana z istniejącymi biologicznymi metadanymi. Kiedy wybierzesz swój target z wyników, lądujesz na konkretnym entry page dla tego białka. I to jest ta najważniejsza część. Centralnym elementem tego entry page jest interaktywny 3D viewer, ale nie pokazuje on tylko fizycznej geometrii. Wizualnie reprezentuje on wewnętrzne confidence modelu co do tej geometrii. AlphaFold ocenia swoją własną dokładność dla każdego pojedynczego aminokwasu za pomocą metryki o nazwie pLDDT. 3D viewer koloruje fizyczny model dokładnie na podstawie tych wyników. Ciemnoniebieski oznacza bardzo wysokie confidence co do struktury. Jasnoniebieski oznacza confidence. Żółty oznacza niskie confidence, a pomarańczowy bardzo niskie confidence. Kiedy obracasz receptor wolnych kwasów tłuszczowych 2 w przeglądarce, zobaczysz ostre, ciemnoniebieskie struktury helikalne tam, gdzie białko przecina błonę komórkową. Ale luźne ogony zwisające na końcach mogą być jaskrawopomarańczowe. Te pomarańczowe regiony to rzadko kiedy błędy algorytmu. Zazwyczaj są to regiony wewnętrznie nieuporządkowane, czyli części białka, które nie mają stałego kształtu w biologicznej rzeczywistości. Oglądanie struktury w przeglądarce jest dobre na szybki sanity check, ale prawdziwa praca obliczeniowa wymaga surowych danych. Pod viewerem znajdziesz sekcję downloadu. Możesz pobrać współrzędne 3D w standardowym formacie PDB albo nowoczesnym formacie mmCIF. Wrzucasz te pliki prosto do swojego lokalnego softu do modelowania, żeby mierzyć odległości albo symulować interakcje molekularne. Razem z plikami współrzędnych musisz też pobrać dane Predicted Aligned Error. Są one dostarczane jako prosty plik JSON. O ile kolory w 3D viewerze mówią ci, czy lokalny kawałek białka jest dokładny, plik JSON PAE mówi ci, czy względne pozycje dwóch różnych kawałków są dokładne. Zawiera on macierz marginesów błędu dla odległości między każdą parą reszt. Jeśli twoje białko ma dwie solidne, niebieskie domeny oddzielone elastycznym zawiasem, dane JSON powiedzą ci, czy faktycznie możesz zaufać kątowi między nimi. AlphaFold Protein Structure Database całkowicie zmienia twój workflow. Nie spędzasz już dni na próbach przewidzenia struktury; poświęcasz minuty na jej wyszukanie, a twoja właściwa praca staje się interpretowaniem metryk confidence dołączonych do downloadu. To wszystko w tym odcinku. Dzięki za słuchanie i keep building!

Cześć, tu Alex z DEV STORIES DOT EU. AlphaFold: Przewidywanie struktury białek, odcinek 5 z 21. Prawdziwa bioinformatyka nie polega na ręcznym klikaniu przycisków pobierania w przeglądarce internetowej. Kiedy musisz przeanalizować setki białek, budujesz zautomatyzowane, skalowalne pipeline'y. I tak dochodzimy do tematu Automatyzacja Odkrywania: API bazy danych AlphaFold. Wiesz już, że baza danych zawiera miliony predykcji strukturalnych, ale przeglądanie jednego białka po drugim na stronie internetowej jest niewykonalne przy dużych projektach. Jeśli robisz analizę porównawczą całej rodziny enzymów albo filtrujesz cele w pipeline'ie do odkrywania leków, musisz zaciągać te struktury bezpośrednio do swojego środowiska obliczeniowego. Baza danych AlphaFold udostępnia REST API, żeby rozwiązać dokładnie to wąskie gardło. Pozwala to twojemu kodowi odpytywać bazę danych i programistycznie pobierać dane strukturalne bez ingerencji człowieka. Głównym kluczem do tej automatyzacji jest UniProt ID. Możesz myśleć o UniProt ID jak o uniwersalnym kodzie kreskowym dla każdego białka. Twój pipeline zazwyczaj zaczyna się od listy takich ID. Używając standardowej biblioteki HTTP w Pythonie, wysyłasz request do API z prośbą o dane predykcyjne powiązane z konkretnym kodem kreskowym. I to jest najważniejsza część. Kiedy robisz ten request, API nie zwraca ogromnego pliku pełnego trójwymiarowych współrzędnych atomowych. Serwowanie ciężkich plików przez synchroniczny API call jest wolne i podatne na błędy. Zamiast tego, API zwraca manifest. Ten manifest to lekki response, który dokładnie opisuje, jakie zasoby są dostępne dla białka, o które pytasz. Koncepcyjnie, ten manifest daje ci biologiczne metadane i katalog bezpośrednich linków do pobrania. Wskazuje na właściwe pliki struktur 3D w standardowych formatach branżowych. Co kluczowe, dostarcza też linki do metryk pewności, takich jak macierz Predicted Aligned Error, czyli PAE. Potrzebujesz obu tych rzeczy. W zautomatyzowanym pipeline'ie pobranie struktury to tylko połowa roboty. Musisz też pobrać dane PAE, żeby twoje algorytmy downstreamowe wiedziały, które części białka są wysoce pewne, a które elastyczne. Przejdźmy przez to, jak ta logika wygląda w typowym skrypcie w Pythonie. Ustawiasz pętlę, żeby iterować po swojej liście UniProt ID. Wewnątrz pętli robisz network request dla pierwszego ID. Zanim zrobisz cokolwiek innego, sprawdzasz HTTP status code. Nie każda istniejąca sekwencja białka ma wcześniej policzoną strukturę AlphaFold. Jeśli zrobisz request o niezmapowane białko, baza danych zwróci standardowy błąd 404 Not Found. Twój skrypt musi zgrabnie złapać ten błąd, zalogować brakujące ID i przejść do następnej iteracji. Jeśli zignorujesz status cody i spróbujesz sparsować brakujący response, twój cały batch job wywali się na pierwszym nieobsługiwanym białku. Kiedy request zakończy się sukcesem, twój skrypt czyta zwrócony manifest. Piszesz logikę, żeby wyciągnąć konkretne linki do pobrania, na których ci zależy, czyli zazwyczaj główny plik współrzędnych i odpowiadający mu plik macierzy błędów. Następnie twój skrypt robi kolejne HTTP requesty do tych konkretnych linków, streamując ciężkie dane bezpośrednio do twojego lokalnego storage'u albo cloud bucketa. Oddzielając query od pobierania, API sprawia, że początkowa faza odkrywania jest niesamowicie szybka. Możesz szybko sprawdzić dostępność tysięcy białek, zbudować zwalidowaną listę linków, a potem obsłużyć ciężkie pobieranie hurtowo. Prawdziwą wartością AlphaFold API jest to, że usuwa ludzkie wąskie gardło, zamieniając ogromną, statyczną bazę danych w pełni programowalny komponent twojej architektury badawczej. To wszystko w tym odcinku. Dzięki za wysłuchanie i koduj dalej!

Cześć, tu Alex z DEV STORIES DOT EU. AlphaFold: Przewidywanie struktury białka, odcinek 6 z 21. Kiedy odpalasz przewidywanie struktury białka, sieć neuronowa rzadko jest bottleneckiem. Prawdziwe czekanie zaczyna się jeszcze zanim model w ogóle wystartuje, zabierając ci z dnia całe godziny tylko na przeszukiwanie genetycznych baz danych. Przewidywanie struktur za pomocą ColabFold całkowicie zmienia tę matematykę. Standardowy pipeline dla AlphaFold opiera się na narzędziu o nazwie Jackhmmer. Jackhmmer skanuje ogromne, terabajtowe lokalne bazy danych, żeby znaleźć ewolucyjnych krewnych twojego docelowego białka. To wyszukiwanie buduje Multiple Sequence Alignment, czyli MSA. MSA to kluczowy input, który mówi AlphaFoldowi, które części białka prawdopodobnie będą ze sobą wchodzić w interakcje na podstawie historii ewolucji. Jednak wygenerowanie tego alignmentu w tradycyjny sposób pożera godziny compute'u i zmusza cię do zarządzania ogromnymi datasetami na twojej własnej infrastrukturze. ColabFold modyfikuje ten pipeline, uderzając w ten konkretny bottleneck. Zastępuje Jackhmmera innym algorytmem wyszukiwania o nazwie MMseqs2. MMseqs2 jest mocno zoptymalizowany pod kątem bardzo szybkiego wyszukiwania sekwencji. Ale ColabFold idzie o krok dalej niż tylko podmiana algorytmów. Zamiast zmuszać cię do odpalania MMseqs2 i powiązanych z nim baz danych na twojej lokalnej maszynie, ColabFold całkowicie offloaduje ten krok. Bierze twoją sekwencję inputową i wysyła ją do dedykowanego, publicznego serwera MMseqs2 przez API. Ten serwer odwala całą czarną robotę. Przeszukuje swoje własne, centralnie zarządzane bazy danych i zwraca gotowy MSA bezpośrednio do twojego środowiska. Ta zmiana architektury oznacza, że w ogóle nie potrzebujesz lokalnego storage'u na bazy danych. Właśnie dlatego możesz efektywnie odpalić ColabFold w Jupyter Notebooku hostowanym w usługach cloudowych, takich jak Google Colab czy UCloud. Taki setup nie wymaga praktycznie żadnej infrastruktury. Otwierasz notebooka i wklejasz swoją sekwencję aminokwasów. Może to być białko typu dzikiego albo customowa, zmutowana sekwencja, z którą właśnie eksperymentujesz. Kiedy uruchamiasz notebooka, proces ten przebiega w dwóch odrębnych fazach. Najpierw twoje środowisko cloudowe robi szybki API call do zdalnego serwera MMseqs2. Serwer oblicza alignment i odsyła MSA z powrotem do twojego notebooka. To skraca proces, który normalnie zajmuje godziny, do zaledwie kilku minut, a nawet sekund. Teraz wkracza drugi element tego workflow. Twój notebook przekazuje pobrany MSA do sieci neuronowej AlphaFold. To tutaj odbywa się właściwe przewidywanie fałdowania. W przeciwieństwie do przeszukiwania bazy danych, ten krok inference'u odpala się lokalnie w twojej instancji cloudowej. Wykorzystuje GPU podpięte do twojej sesji Google Colab lub UCloud, żeby obliczyć współrzędne przestrzenne struktury białka. Ponieważ powolne przeszukiwanie bazy danych jest outsourcowane i przyspieszone, twój całkowity czas iteracji drastycznie spada. Dostajesz wysoce dokładną predykcję sieci neuronowej, jakiej oczekujesz od AlphaFolda, ale dostajesz ją szybko. Jeśli musisz przetestować, jak konkretna mutacja punktowa zmienia fizyczny kształt białka, po prostu edytujesz jedną literę w swojej zmiennej z sekwencją, odpalasz komórkę jeszcze raz i oceniasz nowy output. Oto kluczowy wniosek. ColabFold udowadnia, że dzięki całkowitemu oddzieleniu wymagającego dużej ilości danych wyszukiwania alignmentu od inference'u sieci neuronowej, możesz umieścić światowej klasy narzędzia biologii strukturalnej w standardowej przeglądarce internetowej. To wszystko w tym odcinku. Dzięki za wysłuchanie i twórz dalej!

Cześć, tu Alex z DEV STORIES DOT EU. AlphaFold: Przewidywanie struktury białka, odcinek siódmy z dwudziestu jeden. Przewidywanie struktury pojedynczego białka jest jak zgadywanie kształtu pojedynczego puzzla. Ale w biologii białka rzadko działają same. Jeśli wrzucisz dwie losowe sekwencje do standardowego modelu predykcyjnego, często po prostu zlepi je ze sobą w przestrzeni trójwymiarowej, niezależnie od tego, czy w naturze faktycznie się ze sobą wiążą. Aby ustalić, jak kilka elastycznych elementów faktycznie do siebie pasuje, potrzebujesz innego narzędzia. Jest nim AlphaFold-Multimer. Standardowy AlphaFold jest zoptymalizowany pod kątem pojedynczych łańcuchów polipeptydowych. AlphaFold-Multimer to przetrenowana wersja systemu, zaprojektowana specjalnie do przewidywania kompleksów białkowych. Wytrenowano go tak, aby rozpoznawał i modelował zarówno interfejsy homomeryczne, gdzie wiąże się ze sobą kilka kopii tego samego białka, jak i interfejsy heteromeryczne, gdzie oddziałują ze sobą zupełnie różne białka. Kiedy podasz kilka sekwencji do AlphaFold-Multimer, zawsze zwróci przewidywany kompleks. Kluczowym wyzwaniem jest ustalenie, czy ten przewidywany interfejs to rzeczywista interakcja biologiczna, czy sztucznie wymuszona kolizja. Model robi to, o co go prosisz, więc po prostu umieści łańcuchy obok siebie. Aby rozwiązać problem fałszywych interakcji, AlphaFold-Multimer wprowadza specjalistyczną metrykę confidence, zwaną interface predicted Template Modeling score, w skrócie ipTM. Standardowe wyniki confidence oceniają, jak dobrze zwija się dany fragment łańcucha. Wynik ipTM całkowicie ignoruje wewnętrzną strukturę poszczególnych białek. Zamiast tego mierzy dokładność względnego ułożenia łańcuchów. W szczególności ocenia confidence interfejsu, w którym spotykają się białka. Wyobraź sobie scenariusz, w którym przewidujesz dwułańcuchowy kompleks przeciwciało-antygen. Przekazujesz do modelu sekwencję aminokwasów przeciwciała i sekwencję docelowego antygenu. System zwraca output w postaci struktury zawierającej obie cząsteczki. Najpierw sprawdzasz standardowe, lokalne wyniki confidence dla każdego łańcucha. Mogą być bardzo wysokie, co wskazuje, że model dokładnie wie, jak fałduje się wyizolowane przeciwciało i wyizolowany antygen. Zwróć na to uwagę. Możesz mieć idealnie sfałdowane pojedyncze łańcuchy z wynikiem ipTM bliskim zeru. Jeśli ipTM jest niski, model mówi ci, że chociaż kształty są poprawne, to nie ma pojęcia, jak się ze sobą łączą. Po prostu zaparkował dwie sfałdowane struktury obok siebie, ponieważ podałeś mu dwie sekwencje. Ich interfejs nie ma żadnego znaczenia. Jeśli jednak wynik ipTM jest wysoki, zazwyczaj powyżej zero przecinek osiem, model jest pewny tej interakcji. Wysoki wynik ipTM oznacza, że system znalazł strukturalne i ewolucyjne dowody na to, że te konkretne powierzchnie do siebie pasują. Model nie tylko wymusza ich połączenie; on przewiduje rzeczywiste wiązanie. Aby zrankować ostateczne outputy, AlphaFold-Multimer oblicza połączony wynik confidence. Ta połączona metryka kładzie duży nacisk na interfejs, zazwyczaj biorąc osiemdziesiąt procent wyniku ipTM i dodając dwadzieścia procent ogólnego wyniku strukturalnego. Model z najwyższym połączonym wynikiem jest zwracany jako twoja najlepsza predykcja. Dokładność strukturalna pojedynczych łańcuchów nie gwarantuje prawidłowej interakcji. Interface predicted Template Modeling score to kluczowa metryka, która dowodzi, że model odkrył autentyczny kompleks biologiczny, a nie tylko spełnił prośbę o zgrupowanie dwóch sekwencji. To wszystko w tym odcinku. Dzięki za słuchanie i buduj dalej!

Cześć, tu Alex z DEV STORIES DOT EU. AlphaFold: Protein Structure Prediction, odcinek 8 z 21. Pojedyncza literówka w sekwencji tysięcy aminokwasów może zadecydować o zdrowiu lub poważnej chorobie genetycznej. Ale kiedy sekwencjonujesz genom pacjenta i znajdujesz nową mutację, skąd wiesz, czy to ona jest główną przyczyną, czy to tylko nieszkodliwy szum biologiczny? AlphaMissense daje matematyczną odpowiedź na dokładnie ten problem. Wariant missense to mutacja genetyczna, w której zmiana pojedynczej litery DNA skutkuje zastąpieniem jednego aminokwasu innym w docelowym białku. Przeciętny ludzki genom zawiera tysiące takich wariantów. Wiele z nich jest całkowicie niegroźnych. Zmieniają peryferyjną część białka, nie wpływając na jego ogólną funkcję. Inne całkowicie zaburzają działanie białka, prowadząc do poważnych chorób genetycznych. Oddzielenie niebezpiecznych wariantów od tych nieszkodliwych to ogromny bottleneck w genetyce klinicznej. AlphaMissense to model zbudowany specjalnie do klasyfikacji tych efektów. Od razu musimy wyjaśnić pewne powszechne nieporozumienie. AlphaMissense nie przewiduje zmian w strukturze 3D spowodowanych mutacją. Nie zwraca nowego pliku pokazującego zdeformowany kształt białka. Zamiast tego wykorzystuje kontekst strukturalny i ewolucyjny, którego sieć AlphaFold już się nauczyła, żeby obliczyć prawdopodobieństwo. Zwraca ciągły score patogenności w przedziale od zera do jedynki. Ten score reprezentuje prawdopodobieństwo, że konkretna mutacja wywołuje chorobę. Weźmy konkretny scenariusz. Analizujesz genom pacjenta i izolujesz nową substytucję pojedynczego aminokwasu w kluczowym genie. Walina zastąpiła alaninę na pozycji 142. Pacjent jest chory, ale dokładnie ta mutacja nigdy nie była udokumentowana w literaturze medycznej. Musisz wiedzieć, czy ta substytucja jest patogenna. Robisz query do bazy danych AlphaMissense o ten konkretny wariant. Pod spodem model ocenia ewolucyjną konserwację dokładnie tej pozycji, patrząc na multiple sequence alignments. Sprawdza, czy natura tolerowała zmiany na tej pozycji przez miliony lat ewolucji. Ocenia też kontekst strukturalny. Aminokwas ciasno upakowany w hydrofobowym rdzeniu białka jest znacznie bardziej wrażliwy na zmiany niż ten luźno pływający po zewnętrznej powierzchni. AlphaMissense przetwarza te ewolucyjne i strukturalne sygnały, żeby zwrócić twój score. Score bliski zeru oznacza, że wariant jest prawdopodobnie niegroźny. Białko prawdopodobnie zwija się i funkcjonuje normalnie. Score bliski jedynki flaguje go jako prawdopodobnie patogenny. Substytucja prawie na pewno psuje stabilność lub funkcję białka. Żeby te dane były actionable, model stosuje predefiniowane progi. Scory powyżej górnego progu są kategoryzowane jako prawdopodobnie patogenne. Scory poniżej dolnego progu są prawdopodobnie niegroźne. Wszystko, co wpada w środkowe pasmo, jest klasyfikowane jako niejednoznaczne. Ta klasyfikacja pozwala ci błyskawicznie odfiltrować genomowy szum. Zamiast projektować drogie, czasochłonne eksperymenty laboratoryjne, żeby przetestować każdy nieznany wariant w genomie pacjenta, od razu skupiasz swoje zasoby kliniczne na tych kilku mutacjach, które AlphaMissense oflaguje wysokim scorem. Oto kluczowy wniosek. Prawdziwy wpływ tego narzędzia to jego skala. AlphaMissense nie czeka na queries. Obliczył już score patogenności dla wszystkich 71 milionów możliwych substytucji pojedynczego aminokwasu w całym ludzkim proteomie, katalogując wyniki, zanim pacjent w ogóle wejdzie do kliniki. Jeśli podoba ci się podcast i chcesz pomóc nam tworzyć go dalej, możesz nas wesprzeć, wyszukując DevStoriesEU na Patreonie. To wszystko w tym odcinku. Dzięki za słuchanie i keep building!

Cześć, tu Alex z DEV STORIES DOT EU. AlphaFold: Przewidywanie struktur białek, odcinek 9 z 21. Pewnie myślisz, że największą przeszkodą w przewidywaniu struktur białek jest znalezienie wystarczająco mocnego GPU. Ale prawdziwym wąskim gardłem jest storage. Zanim zwiniesz pojedynczy aminokwas, musisz odpytać ogromne, wieloterabajtowe ewolucyjne bazy danych. Ten odcinek omawia lokalny deploy AlphaFold 2. Uruchomienie AlphaFold na własnym sprzęcie daje ci pełną prywatność dla twoich własnych sekwencji i zdejmuje limity czasu wykonania, które znajdziesz na publicznych serwerach. DeepMind udostępnia kod open-source bezpośrednio na GitHubie. Aby z niego skorzystać, musisz najpierw odtworzyć dokładne genetyczne środowisko referencyjne, którego model używa do szukania podobnych sekwencji. Wymaga to pobrania lokalnych kopii publicznych baz danych, takich jak BFD, MGnify, UniRef90 i PDB70. Razem te nieskompresowane bazy danych zajmują około trzech terabajtów na dysku. Wyobraź sobie inżyniera DevOps, który provisionuje nowy node High Performance Computing dla zespołu badawczego. Pierwszym wymaganiem jest trzyterabajtowy dysk. Nie możesz tu użyć tanich, wolnych dysków talerzowych. Potrzebujesz szybkiego storage'u NVMe. Przeszukiwanie milionów sekwencji genetycznych generuje agresywne operacje odczytu z dysku. Jeśli twój storage jest wolny, cały pipeline dławi się, zanim dane w ogóle dotrą do sieci neuronowej. Oto kluczowa kwestia. Lokalny pipeline AlphaFold składa się z dwóch odrębnych faz obliczeniowych, które wymagają zupełnie innych profili sprzętowych. Faza pierwsza generuje Multiple Sequence Alignment, czyli MSA. System przeszukuje twoje terabajty lokalnych baz danych za pomocą zewnętrznych narzędzi bioinformatycznych. Ta faza zużywa dokładnie zero cykli GPU. Jej wąskim gardłem są wyłącznie rdzenie CPU, pamięć systemowa i prędkość dysku. Faza druga to właściwy inference strukturalny. To tutaj sieć neuronowa przejmuje stery, by wygenerować współrzędne 3D, a ta faza bezwzględnie wymaga GPU z dużą ilością VRAM-u. Jeśli sprovisionujesz node z potężnym GPU, ale słabym CPU, twój job predykcyjny utknie na wiele godzin w fazie alignmentu. Zarządzanie zależnościami oprogramowania dla obu tych faz jest strasznie trudne. Musisz zgrać ze sobą konkretne wersje CUDA, Jax i narzędzi do alignmentu sekwencji. Aby to rozwiązać, oficjalne repozytorium mocno opiera się na Dockerze. Konteneryzacja zapewnia, że to złożone środowisko uruchomieniowe pozostaje odizolowane i spójne na różnych systemach operacyjnych. Konfiguracja deployu opiera się na dwóch głównych skryptach. Najpierw odpalasz dostarczony skrypt bash, żeby pobrać dane. Kierujesz go na swój dysk NVMe i pozwalasz mu działać. W zależności od twojego łącza, pobieranie i rozpakowywanie tych plików może zająć kilka dni. Kiedy dane wylądują już na twoim szybkim storage'u, jesteś gotowy do odpalenia. Kontrolujesz pipeline za pomocą dostarczonego pythonowego wrappera o nazwie run docker dot py. Odpalasz ten skrypt z terminala, przekazując mu kilka obowiązkowych argumentów. Podajesz ścieżkę do wejściowego pliku FASTA, który zawiera twoją docelową sekwencję aminokwasów. Podajesz ścieżkę do katalogu z twoją wieloterabajtową bazą danych. Wskazujesz katalog wyjściowy. Na koniec ustawiasz maksymalną datę wydania szablonu, co zabrania modelowi korzystania ze znanych szablonów strukturalnych opublikowanych po określonym czasie. Pythonowy wrapper przyjmuje te argumenty i buduje kontener Dockera. Montuje twoje lokalne katalogi hosta w kontenerze jako wolumeny, pozwalając odizolowanemu oprogramowaniu czytać twoje bazy danych i zapisywać pliki wyjściowe z powrotem na twój dysk. Następnie kontener przejmuje stery, automatycznie orkiestrując mocno obciążające CPU wyszukiwanie alignmentu oraz mocno obciążający GPU proces inference'u. Lokalny deploy AlphaFold to w gruncie rzeczy wyzwanie infrastrukturalne, które wymaga od ciebie zbalansowania dużej prędkości dysku dla obciążającej CPU fazy alignmentu z odpowiednią ilością VRAM-u dla obciążającej GPU fazy zwijania. Dzięki za spędzenie ze mną tych kilku minut. Do usłyszenia następnym razem, trzymaj się.

Cześć, tu Alex z DEV STORIES DOT EU. AlphaFold: Przewidywanie struktury białka, odcinek 10 z 21. Przez lata, jeśli chciałeś zobaczyć, jak potencjalny lek oddziałuje z białkiem docelowym, musiałeś uruchomić swoją sekwencję, wygenerować strukturę białka, a następnie użyć zupełnie oddzielnego oprogramowania do obliczeniowego dokowania leku. Wciskałeś sztywny związek chemiczny w sztywny model. AlphaFold 3 całkowicie to zmienia, składając wszystko razem w tym samym czasie. Dzisiaj przedstawiamy AlphaFold 3: Poza białkami. Poprzednie wersje AlphaFold koncentrowały się wyłącznie na przewidywaniu struktury białek na podstawie ich sekwencji aminokwasowych. Były w tym wyjątkowo dobre, ale prawdziwe systemy biologiczne nie działają jak nagie białka unoszące się w próżni. Białka oddziałują z DNA, aby włączać i wyłączać geny. Polegają na jonach metali, aby katalizować reakcje. Są blokowane lub aktywowane przez małe cząsteczki leków. Przed tą aktualizacją modelowanie tych złożonych interakcji wymagało pofragmentowanego pipeline'u. Najpierw przewidywałeś strukturę białka, potem ewentualnie oddzielnie modelowałeś DNA, a na końcu próbowałeś obliczyć, jak fizycznie do siebie pasują. To sekwencyjne podejście ma poważną wadę. Zakłada, że struktura białka jest statyczna. W rzeczywistości białka dynamicznie zmieniają kształt, gdy wiążą się z innymi cząsteczkami. Oto kluczowy wniosek. AlphaFold 3 przestaje być tylko narzędziem do fałdowania białek, a staje się uogólnionym predyktorem kompleksów biomolekularnych. Rozszerza swój natywny słownik poza aminokwasy, obejmując trzy zupełnie nowe kategorie cząsteczek. Po pierwsze, obsługuje teraz kwasy nukleinowe, co oznacza, że możesz podać jako input zarówno sekwencje DNA, jak i RNA. Po drugie, natywnie rozumie ligandy małocząsteczkowe, co obejmuje zdecydowaną większość leków farmaceutycznych. Po trzecie, pozwala na uwzględnienie niezbędnych jonów, które często stanowią rdzeń funkcjonalnych białek. Zamiast przewidywać te składniki w izolacji, AlphaFold 3 przewiduje wspólną strukturę wszystkich tych odrębnych jednostek molekularnych jednocześnie. Oblicza interakcje między każdym atomem w całym kompleksie w jednym przebiegu. Pomyśl, jak to zmienia standardowy scenariusz modelowania. Nie patrzysz już na izolowany cel. Możesz teraz zdefiniować input zawierający sekwencję białka, określoną nić DNA oraz chemiczną definicję małego inhibitora. System analizuje je razem. Wygenerowany output pokazuje białko aktywnie chwytające nić DNA, podczas gdy mała cząsteczka leku jest idealnie wciśnięta w kieszeń wiążącą. Ponieważ wszystko zostało złożone w tej samej przestrzeni obliczeniowej, model białka automatycznie odzwierciedla zmiany strukturalne spowodowane zarówno przez DNA, jak i lek. To nie jest po prostu stary engine AlphaFold z doklejonym na końcu algorytmem dokowania. To zupełnie odrębna architektura modelu wytrenowana bezpośrednio na tym, jak różne klasy cząsteczek biologicznych oddziałują ze sobą w przestrzeni fizycznej. Najważniejszą zmianą w AlphaFold 3 jest to, że nie generujesz już izolowanych części biologicznych, ale przewidujesz kompletne, oddziałujące ze sobą maszyny molekularne dokładnie tak, jak istnieją w świecie fizycznym. To wszystko w tym odcinku. Dzięki za wysłuchanie i buduj dalej!

Cześć, tu Alex z DEV STORIES DOT EU. AlphaFold: Przewidywanie struktury białek, odcinek 11 z 21. Nie potrzebujesz już dyplomu inżyniera ani superkomputera, aby uruchomić najbardziej zaawansowane na świecie biomolekularne AI. Bariera wejścia obniżyła się do zwykłej przeglądarki internetowej. To właśnie AlphaFold Server, twoja bezpośrednia brama do AlphaFold 3. Kiedyś uruchamianie złożonych predykcji struktur wiązało się z zarządzaniem zależnościami, pobieraniem terabajtów genetycznych baz danych i utrzymywaniem potężnych GPU. AlphaFold Server omija to wszystko. To w pełni graficzny interfejs webowy, który pozwala biologom i chemikom uruchamiać joby AlphaFold 3 bez pisania ani jednej linijki kodu. Wszystkie multiple sequence alignments, template searching i zwijanie oparte na dyfuzji odbywają się zdalnie, na współdzielonej infrastrukturze compute. Zanim przejdziemy do predykcji, musimy wyjaśnić dwa ważne ograniczenia. Po pierwsze, AlphaFold Server jest przeznaczony wyłącznie do użytku niekomercyjnego. Po drugie, ponieważ opiera się na udostępnionych zasobach compute, twoje konto podlega dziennym limitom jobów. Nie możesz go użyć do brute-force'owania ogromnego pipeline'u screeningowego. Jest on zaprojektowany do ukierunkowanego projektowania eksperymentów w ramach pojedynczych jobów. Oto jak w interfejsie budujesz złożony, wielołańcuchowy job predykcyjny. Cały workflow opiera się na dodawaniu oddzielnych encji do współdzielonego workspace'u. Zaczynasz od głównego białka. Klikasz przycisk, aby dodać encję białkową. Pojawia się pole tekstowe. Po prostu wklejasz swoją jednoliterową sekwencję aminokwasów bezpośrednio do tego pola. Jeśli spodziewasz się, że to białko utworzy homodimer, nie musisz wklejać sekwencji dwa razy. Po prostu zmieniasz ustawienie copy number na dwa, a system zajmie się stechiometrią. Teraz drugim elementem jest dodanie interagujących cząsteczek. Załóżmy, że chcesz zobaczyć, jak to białko wiąże się z określonym segmentem DNA. Klikasz, aby dodać encję DNA i wklejasz sekwencję dla forward strand. Aby zbudować rzeczywistą podwójną helisę, dodajesz kolejną encję DNA i wklejasz sekwencję reverse complementary. AlphaFold 3 wymodeluje je razem w tej samej przestrzeni trójwymiarowej, przewidując zarówno parowanie zasad DNA, jak i jego interfejs strukturalny z twoim białkiem. To właśnie tutaj robi się ciekawie w przypadku komponentów niepolimerowych. Serwer natywnie obsługuje ligandy, jony i kofaktory. Jeśli twoje białko wymaga określonego jonu metalu do stabilizacji swojej struktury, klikasz, aby dodać encję jonu. Nie musisz wyszukiwać skomplikowanych identyfikatorów chemicznych ani pisać stringów SMILES dla standardowych komponentów. Serwer oferuje wbudowany dropdown. Po prostu wyszukujesz popularny jon, wybierasz magnez lub cynk, definiujesz ile kopii potrzebujesz, a interfejs to zatwierdza. Gdy twój workspace zawiera już sekwencję białka, dwie nici DNA i wybrany jon, klikasz przycisk submit. To cały setup. W tle kontrolę przejmuje serwer. Zarządza on pipeline'ami alignmentu, przekazuje dane do sieci neuronowej AlphaFold 3 i uruchamia proces structural diffusion. Po zakończeniu joba, wyniki ładują się bezpośrednio w twojej przeglądarce. Otrzymujesz wbudowany viewer 3D, aby natychmiast obejrzeć przewidziany kompleks. Co ważniejsze, dostajesz czysty pakiet do pobrania, zawierający przewidziane pliki współrzędnych atomowych i wszystkie powiązane confidence metrics do twojej lokalnej analizy. Prawdziwa moc serwera to nie tylko natychmiastowy dostęp do modelu, ale niesamowita szybkość iteracji, jaką zapewnia podczas testowania hipotez strukturalnych. To wszystko w tym odcinku. Dzięki za wysłuchanie i keep building!

Cześć, tu Alex z DEV STORIES DOT EU. AlphaFold: Przewidywanie struktury białka, odcinek 12 z 21. Przewidzenie dokładnie, jak nowy lek wiąże się z białkiem docelowym, wydaje się przełomem, dopóki nie uświadomisz sobie, że AI właśnie umieściło dwa atomy węgla w dokładnie tym samym miejscu w przestrzeni. Pięknie wyrenderowana struktura jest bezużyteczna, jeśli łamie prawa fizyki. Dzisiaj omówimy interpretację wyników AlphaFold 3, żeby pomóc ci oddzielić biologiczny sens od obliczeniowych halucynacji. AlphaFold 3 generuje trójwymiarowy plik ze współrzędnymi oraz zestaw konkretnych metryk. Ocena wyniku wymaga analizowania tych metryk razem, ponieważ wysoki wynik w jednym obszarze może maskować katastrofalny błąd w innym. Najpierw patrzysz na lokalną pewność modelu, używając metryki o nazwie pLDDT. Ocenia ona każdy pojedynczy atom lub resztę aminokwasową w skali od zera do stu. Wysoki wynik oznacza, że model jest bardzo pewny konkretnej, lokalnej geometrii tego łańcucha. Ale sama lokalna pewność to za mało. Możesz mieć idealnie przewidziane białko i idealnie przewidziany mały ligand, które po prostu niezależnie unoszą się w przestrzeni. Żeby wiedzieć, czy faktycznie ze sobą oddziałują, musisz sprawdzić Predicted Aligned Error, czyli PAE. PAE mierzy oczekiwany błąd pozycji w angstremach. Im niższy wynik, tym lepiej. Kiedy przewidujesz kompleksy, na przykład białko wiążące się z nicią DNA albo cząsteczką leku, skupiasz się na cross-PAE. Pomyśl o wyniku PAE jak o macierzy w formie heatmapy. Przekątna pokazuje, jak pewny jest model co do wewnętrznej struktury pojedynczego łańcucha. Obszary poza przekątną pokazują pewność relacji między różnymi encjami. Jeśli PAE między twoim białkiem a ligandem jest niskie, AlphaFold jest bardzo pewny ich wzajemnego położenia. Mocno wierzy, że ligand siedzi dokładnie w tej konkretnej kieszeni. I tu pojawia się kluczowy wniosek. Wysoka pewność nie oznacza automatycznie fizycznej rzeczywistości. AlphaFold 3 to model deep learningowy, a nie symulator dynamiki molekularnej. Priorytetyzuje rozpoznane wzorce przestrzenne nad ścisłymi prawami fizyki. To prowadzi nas do clash score. Ponieważ AlphaFold 3 modeluje ligandy, kwasy nukleinowe i zmodyfikowane reszty bezpośrednio, bez rygorystycznego kroku relaksacji opartego na fizyce, wyniki mogą zawierać poważne kolizje steryczne. Kolizja ma miejsce, gdy dwóm atomom przypisane zostaną współrzędne, które umieszczają je niemożliwie blisko siebie, przez co w praktyce na siebie nachodzą. Serwer oblicza i podaje clash score dla twojego wyniku. Wysoki clash score to ogromna czerwona flaga. Wyobraź sobie scenariusz, w którym analizujesz wynik, a główny łańcuch białka ma pLDDT powyżej 90. Cross-PAE między białkiem a twoim docelowym ligandem jest bardzo niskie. Metryki interfejsu sugerują silne, pewne wiązanie. Na papierze wygląda to jak idealna predykcja dokowania. Potem sprawdzasz clash score i okazuje się, że jest mocno podwyższony. Jeśli załadujesz fizyczne współrzędne do viewera, zobaczysz ligand przechodzący prosto przez szkielet białka. Sieć neuronowa rozpoznała, że ligand pasuje do tej ogólnej kieszeni wiążącej, ale nie poradziła sobie z poprowadzeniem atomów wokół istniejących łańcuchów bocznych. Wyhalucynowała cząsteczkę-widmo, która ignoruje materię stałą. Kiedy oceniasz wynik z AlphaFold 3, musisz jednocześnie sprawdzać pewność strukturalną i fizyczny realizm. Używaj pLDDT, żeby weryfikować kształt poszczególnych cząsteczek. Używaj PAE, żeby potwierdzić, że wchodzą w interakcje tam, gdzie się tego spodziewasz. Następnie sprawdź clash score, żeby upewnić się, że model nie złamał podstawowych zasad chemii, by wymusić tę interakcję. Pamiętaj, że model deep learningowy zwraca hipotezę przestrzenną opartą na rozpoznawaniu wzorców, więc wysoce pewna predykcja jest ważna tylko wtedy, gdy atomy faktycznie przestrzegają praw fizyki. To wszystko w tym odcinku. Dzięki za odsłuch i buduj dalej!

Cześć, tu Alex z DEV STORIES DOT EU. AlphaFold: Przewidywanie struktury białek, odcinek 13 z 21. DeepMind udostępnił swój najnowszy model biologii strukturalnej jako open-source, ale jeśli sklonujesz repository i spróbujesz je uruchomić, od razu wyrzuci błąd. Kod jest w całości publiczny, ale sama sieć neuronowa, która generuje predykcje, jest ściśle kontrolowana. Dzisiaj przyjrzymy się inference pipeline dla AlphaFold 3 i temu, jak właściwie zabrać się za jego deploy. Aby uruchomić AlphaFold 3 lokalnie, musisz połączyć dwa oddzielne elementy: kod uruchomieniowy i parametry modelu. Repository daje ci logikę pipeline'u. Jeśli chodzi o parametry, a konkretnie weights w wersji trzy kropka zero kropka jeden, musisz osobno poprosić o dostęp. Google wymaga przesłania formularza ze szczegółowym opisem twojego niekomercyjnego, badawczego use case'u. Po zatwierdzeniu wniosku otrzymasz link do pobrania tych ogromnych weights modelu. Takie rozdzielone podejście pozwala DeepMind ograniczyć komercyjne wykorzystanie, jednocześnie pozwalając badaczom na analizę i uruchamianie open-source'owego pipeline'u na własnym sprzęcie. Po pobraniu weights, twoim kolejnym krokiem jest zdefiniowanie tego, co model ma przewidzieć. Wcześniejsze wersje AlphaFold radziły sobie głównie z pojedynczymi łańcuchami białkowymi, więc mogłeś po prostu przekazać zwykły string z aminokwasami. AlphaFold 3 modeluje złożone interakcje między różnymi typami cząsteczek, więc zwykły string już nie wystarczy. Zamiast tego tworzysz plik konfiguracyjny. Ten plik działa jak kompletny manifest dla twojego biologicznego celu. Określasz w nim dokładne cząsteczki biorące udział w twoim eksperymencie. Może to być standardowe białko, nić DNA lub RNA, albo konkretny ligand małej cząsteczki. W tym samym pliku konfiguracyjnym definiujesz również seeds dla losowości. Ponieważ nowa architektura modelu opiera się na procesie diffusion, aby wygenerować ostateczną trójwymiarową strukturę, wprowadzenie drobnych zmian w random seed daje różne możliwe stany strukturalne. Definiując wiele seeds w konfiguracji, instruujesz pipeline, aby wygenerował różne predykcje dla dokładnie tego samego inputu. W tym pliku deklarujesz również wersję dialektu, co po prostu mówi parsing engine, aby zastosował reguły walidacji AlphaFold 3 do twojego manifestu. Mając pobrane weights i gotowy plik konfiguracyjny, przechodzisz do uruchomienia. Ponieważ ten pipeline zależy od bardzo konkretnych wersji bibliotek machine learningowych i sterowników GPU, uruchamianie go bezpośrednio na twoim systemie operacyjnym hosta jest ryzykowne. Oficjalny workflow opiera się na Dockerze. Budujesz container image bezpośrednio z dostarczonego repository, gwarantując sobie idealne środowisko. Aby faktycznie uruchomić inference, odpalasz ten kontener i łączysz go z maszyną hosta, montując trzy kluczowe ścieżki. Po pierwsze, montujesz folder zawierający twój wejściowy plik konfiguracyjny. Po drugie, montujesz katalog zawierający te ogromne, zatwierdzone weights modelu, które pobrałeś wcześniej. I wreszcie, montujesz pusty katalog, w którym kontener może zapisać swoje wyniki. Kiedy kontener wystartuje, wywołujesz główny run script. Pipeline waliduje twój wejściowy manifest, ładuje weights z zamontowanego katalogu do pamięci GPU i rozpoczyna predykcję strukturalną. Kiedy proces się zakończy, twój zamontowany folder wyjściowy będzie zawierał końcowe współrzędne żądanych cząsteczek, sformatowane i gotowe do wizualizacji. Głównym wyzwaniem tego pipeline'u nie jest sam kod, ale zarządzanie logistyką zdobycia weights modelu i skrupulatne ustrukturyzowanie pliku konfiguracyjnego, aby odwzorować złożone interakcje biologiczne. Jeśli chcesz wesprzeć podcast, możesz wyszukać DevStoriesEU na Patreonie. To wszystko w tym odcinku. Dzięki za wysłuchanie i buduj dalej!

Cześć, tu Alex z DEV STORIES DOT EU. AlphaFold: Przewidywanie struktury białek, odcinek 14 z 21. Największym błędem, jaki popełniają inżynierowie podczas deployu AlphaFold, jest pozwalanie, by drogie GPU stały bezczynnie, czekając na zakończenie prostych zapytań do bazy danych. Stawiasz A100, odpalasz joba i patrzysz, jak utylizacja leży na zerze przez wiele godzin. Rozwiązaniem jest separacja środowisk uruchomieniowych, i to jest dokładnie to, co dzisiaj omówimy w temacie Data Pipelines i wymagań sprzętowych. AlphaFold 3 wykonuje dwa fundamentalnie różne typy zadań. Po pierwsze, przeszukuje ogromne genetyczne bazy danych, żeby zbudować Multiple Sequence Alignments i znaleźć szablony strukturalne. Po drugie, przekazuje te przetworzone dane do sieci neuronowej, żeby wygenerować predykcję ostatecznej struktury trójwymiarowej. Przeszukiwanie bazy danych jest całkowicie CPU-bound i zależy od prędkości odczytu ze storage'u. Predykcja sieci neuronowej wymaga GPU. Jeśli odpalisz domyślny setup, AlphaFold wykonuje oba kroki sekwencyjnie na tej samej maszynie. To oznacza, że twoje drogie GPU nie robi absolutnie nic, podczas gdy CPU spędza godziny na mieleniu terabajtów referencyjnych baz danych. I tu jest kluczowa sprawa. Repozytorium udostępnia dwie konkretne flagi, żeby rozdzielić te workloady. Pierwsza flaga to run data pipeline. Kiedy odpalasz skrypt run z włączoną tą flagą i wyłączonym run inference, AlphaFold wykonuje tylko wyszukiwania genetyczne i szablonów. Czyta twój input konfiguracyjny, odpytuje lokalne bazy danych i generuje wszystkie niezbędne features sekwencji. Następnie zapisuje ten pośredni stan danych na dysku. Co kluczowe, ten krok wymaga zero zasobów GPU. Opiera się wyłącznie na maszynie z wieloma rdzeniami CPU i szybkimi dyskami NVMe SSD, żeby obsłużyć ciężkie operacje I/O. Kiedy data pipeline skończy budować features, używasz drugiej flagi. Odpalasz skrypt ponownie, ale ustawiasz run data pipeline na false, a run inference na true. AlphaFold całkowicie pominie przeszukiwanie bazy danych. Bezpośrednio ładuje scache'owane dane features, które właśnie wygenerowałeś, inicjalizuje wagi modelu i wykonuje forward pass sieci neuronowej. Ten krok jest całkowicie GPU-bound. Opiera się wyłącznie na twoim akceleratorze sprzętowym i jego pamięci o wysokiej przepustowości. Taka jawna separacja to sposób, w jaki projektuje się porządną infrastrukturę enterprise. Zamiast podłączać ogromne dyski z bazami danych do wielu drogich maszyn z GPU, stawiasz flotę opłacalnych node'ów CPU. Rozdzielasz przychodzące requesty o predykcję pomiędzy te node'y CPU, używając ich do agresywnego odpytywania baz danych i równoległego generowania alignmentów. Za każdym razem, gdy node CPU kończy joba w data pipeline, wrzuca wynikowe pliki features na współdzielony storage. W międzyczasie utrzymujesz jeden, mocno utylizowany node z potężnym GPU. Ta maszyna służy wyłącznie do inference'u. Stale monitoruje współdzielony storage. Kiedy pojawia się nowy plik features, podnosi go, odpala predykcję sieci neuronowej w kilka minut, zapisuje ostateczną strukturę molekularną i natychmiast pobiera kolejny plik. Twoje GPU już nigdy nie czeka na bottleneck na storage'u ani na przeszukiwanie bazy danych. Oddzielenie CPU-bound data pipeline od GPU-bound inference'u to najskuteczniejszy sposób na skalowanie predykcji struktury białek przy jednoczesnym trzymaniu kosztów sprzętu pod kontrolą. Dzięki za spędzenie ze mną tych kilku minut. Do usłyszenia następnym razem, trzymaj się.

Cześć, tu Alex z DEV STORIES DOT EU. AlphaFold: Przewidywanie struktury białek, odcinek 15 z 21. Twój model białka jest zaskakująco mały, ma poniżej stu milionów parametrów. Udaje ci się przewidzieć strukturę sekwencji o długości 500 reszt na standardowym GPU z 16 gigabajtami pamięci, ale kiedy podajesz jako input sekwencję o długości 1500 reszt, proces natychmiast wywala się z błędem out of memory, nagle żądając ponad 80 gigabajtów VRAM-u. To katastrofalne skalowanie wynika ze specyficznej cechy architektury zwanej memory bottleneck: O(n³) Attention. Według publikacji FastFold autorstwa Chenga i innych, to gwałtowne zużycie pamięci nie ma nic wspólnego z wagami modelu. Cały model AlphaFold ma tylko 93 miliony parametrów. Bottleneck leży całkowicie w pośrednich aktywacjach generowanych podczas forward pass. Wraz ze wzrostem długości sekwencji, pamięć wymagana do przechowywania tych pośrednich tensorów skaluje się sześciennie. Aby zrozumieć dlaczego, musimy zajrzeć do wnętrza Evoformera. Evoformer to główny trzon strukturalny AlphaFold, składający się z 48 zestackowanych bloków. Wewnątrz każdego bloku model opiera się na wyspecjalizowanym mechanizmie attention. Standardowe transformery, takie jak te używane w modelach językowych, zazwyczaj mają mechanizmy attention, w których pamięć skaluje się kwadratowo wraz z długością sekwencji. Porównują one jednowymiarową sekwencję tylko z nią samą. AlphaFold jest inny. Wykorzystuje dwuwymiarową reprezentację pośrednią do modelowania interakcji parami między aminokwasami. Oto kluczowy wniosek. Aby dokładnie przewidywać trójwymiarowe struktury białek, sieć nie może po prostu patrzeć na pary reszt w izolacji. Musi oceniać relacje trójkątne, aby upewnić się, że przewidywane odległości między trzema punktami są fizycznie możliwe w trójwymiarowej przestrzeni. Aby to obliczyć, moduł attention generuje pośrednie tensory aktywacji. Memory footprint tych tensorów wynika ze ścisłego wzoru. To długość sekwencji podniesiona do sześcianu, pomnożona przez liczbę attention heads i przez rozmiar w bajtach danego typu danych. AlphaFold używa precyzji BFloat16, która zajmuje dwa bajty na wartość. Prześledźmy matematykę dla developera, któremu wywaliło GPU. Kiedy podajesz do modelu sekwencję o długości 500 reszt, długość sekwencji wynosi 500. 500 do sześcianu to 125 milionów. Jeśli masz cztery attention heads, mnożysz 125 milionów przez cztery, a następnie przez dwa bajty dla tej precyzji. Pojedyncza warstwa attention tworzy około jednego gigabajta pośrednich aktywacji. Twoje 16-gigabajtowe GPU radzi sobie z tym z zapasem. Teraz zmieniasz input na sekwencję o długości 1500 reszt. Zaledwie potroiłeś długość inputu. Ale ponieważ skalowanie jest sześcienne, musisz podnieść 1500 do sześcianu, co daje ponad 3,3 miliarda. Pomnóż to przez cztery heads i dwa bajty, a ta sama pojedyncza warstwa attention wymaga teraz prawie 27 gigabajtów pamięci tylko do przechowania swoich aktywacji. Ponieważ sieć przepuszcza te dane przez 48 kolejnych bloków Evoformera, całkowite zapotrzebowanie na pamięć natychmiast przekracza 80 gigabajtów. Tensory puchną tak szybko, że sprzęt po prostu ubija proces. Właśnie dlatego AlphaFold wymaga mocnej optymalizacji dla dłuższych sekwencji. Sama liczba parametrów sieci neuronowej nie mówi ci prawie nic o jej wymaganiach sprzętowych, kiedy wewnętrzna geometria wymusza jednoczesny rozrost danych pośrednich w trzech wymiarach. Jeśli chcesz wesprzeć podcast, wyszukaj DevStoriesEU na Patreon. To wszystko w tym odcinku. Dzięki za słuchanie i koduj dalej!

Cześć, tu Alex z DEV STORIES DOT EU. AlphaFold: Przewidywanie struktury białek, odcinek 16 z 21. Jeśli intermediate tensor jest zbyt masywny dla pojedynczego GPU, standardowym odruchem jest podzielenie parametrów modelu na wiele kart. Ale kiedy twoja sieć neuronowa ma tylko 93 miliony parametrów, a activation tensors zajmują 20 gigabajtów, cięcie modelu niczego nie rozwiązuje. Musisz pociąć geometrię samych danych. I to jest dokładnie to, co rozwiązuje Dynamic Axial Parallelism. Żeby zrozumieć, dlaczego takie podejście w ogóle istnieje, musimy spojrzeć na wąskie gardła zidentyfikowane w publikacji FastFold. Głównym silnikiem AlphaFold jest blok Evoformer. Przetwarza on multiple sequence alignments i pair representations, które w zasadzie działają jak ogromne, dwuwymiarowe siatki danych. Standardowy Tensor Parallelism próbuje radzić sobie z dużym obciążeniem, dzieląc wagi warstw liniowych pomiędzy różne GPU. W przypadku AlphaFold tworzy to jednak poważne spadki wydajności. Tensor Parallelism wymaga częstej, ciężkiej synchronizacji, odpalając nawet do dwunastu kroków komunikacji na jeden blok. Ma to również zastosowanie tylko do modułów attention i feed-forward. Co gorsza, jego skalowanie jest twardo ograniczone przez liczbę attention heads. W pair stacku AlphaFold ogranicza cię to do maksymalnie zaledwie czterech GPU. Dynamic Axial Parallelism, czyli DAP, całkowicie porzuca podejście oparte na dzieleniu wag. Zamiast tego, DAP trzyma kompletne parametry modelu w nienaruszonym stanie na każdym pojedynczym urządzeniu. Sam model nigdy nie jest rozpraszany. Rozpraszane są za to intermediate activations. Evoformer przetwarza dane wzdłuż dwóch wymiarów sekwencji, ale operacje matematyczne zawsze odbywają się tylko wzdłuż jednego wymiaru naraz. Takie zachowanie pozwala algorytmowi DAP na czyste podzielenie danych wzdłuż nieaktywnego wymiaru. Możesz to sobie wyobrazić w setupie multi-GPU. Ogromna siatka danych sekwencyjnych wchodzi do warstwy. DAP tnie ten input poziomo. GPU zero bierze pierwszy chunk wierszy, GPU jeden bierze następny i tak dalej. Następnie każde GPU oblicza attention dla swojego konkretnego wycinka danych. Ponieważ każde GPU trzyma pełną kopię wag modelu i ponieważ obliczenia są odizolowane do osi poziomej, GPU nie muszą ze sobą gadać. Przeliczają swoje chunki niezależnie. I tu pojawia się kluczowy wniosek. Kiedy te poziome obliczenia się skończą, model musi przetworzyć dane wzdłuż pionowego wymiaru sekwencji. Żeby to się udało, GPU wykonują krok komunikacji all-to-all. Transponują geometrię danych w sieci. GPU zero rozrzuca swoje fragmenty kolumn do innych urządzeń i zbiera kawałki, których potrzebuje do następnej fazy. Orientacja podziału się odwraca. Teraz dane są pocięte pionowo w całym klastrze. GPU natychmiast odpalają kolejną warstwę obliczeń attention, znowu z zerową komunikacją między sobą podczas samej matematyki. Ta strategia transpozycji zmniejsza wolumen komunikacji o cały rząd wielkości w porównaniu do standardowego Tensor Parallelism. Umożliwia to również zrównoleglenie w każdym pojedynczym module obliczeniowym w Evoformerze. Ponieważ masywne activation tensors są równomiernie rozłożone w klastrze, ogólne zużycie pamięci mocno spada, zapobiegając crashom poszczególnych urządzeń pod ciężarem długich sekwencji. Kiedy twoje sprzętowe wąskie gardło wynika z samego fizycznego rozmiaru intermediate representations, a nie z głębokości sieci neuronowej, nie fragmentujesz architektury. Rozpraszasz osie danych. To wszystko w tym odcinku. Dzięki za wysłuchanie i buduj dalej!

Cześć, tu Alex z DEV STORIES DOT EU. AlphaFold: Przewidywanie struktury białek, odcinek 17 z 21. Co by było, gdyby twój compiler był na tyle inteligentny, żeby automatycznie slice'ować operacje macierzowe, tak aby idealnie pasowały do budżetu pamięci sprzętowej? Wyobraź sobie inżyniera, który spędza dni na ręcznym profilowaniu i slice'owaniu kodu, żeby zapobiec błędom Out of Memory. Za każdym razem, gdy zmienia się długość sekwencji, stałe slice'y zawodzą. Zestaw to z systemem, który dynamicznie szacuje memory footprint i generuje partycjonowany kod w locie. AutoChunk to algorytm, który to umożliwia. W publikacji FastFold badacze wzięli na warsztat ogromne memory bottlenecks pojawiające się przy przepuszczaniu długich sekwencji przez modele do predykcji białek. Standardowym podejściem do unikania błędów Out of Memory jest chunking. Partycjonujesz tensor wzdłuż wymiarów, które nie wchodzą ze sobą w interakcje podczas obliczeń, przetwarzasz te mniejsze bloki sekwencyjnie i zszywasz je z powrotem. Zazwyczaj jest to ręczny, pracochłonny proces. Profilujesz kod, zgadujesz najlepsze rozmiary slice'ów i hardcodujesz granice. Publikacja FastFold zwraca uwagę, że stałe schematy chunkingu są nieefektywne, bo nie potrafią dostosować się do zmiennych wymiarów sekwencji ani do specyficznych memory spikes podczas operacji. Oto kluczowy wniosek. Badacze z FastFold zaobserwowali, że 95 procent operacji w modelu zużywa mniej niż 20 procent peak memory. Chunking na poziomie modułu jest całkowicie zbędny. Musisz chunkować tylko te konkretne operacje, które powodują memory spikes. AutoChunk automatyzuje to, analizując twój kod jako computational graph. Jako inputy przyjmuje ten graf i twój konkretny budżet pamięci sprzętowej. Przekładając to na ludzki język, algorytm odpala ciągłą pętlę. Dopóki potrzebna jest strategia pamięciowa, szacuje on zużycie pamięci przez graf, żeby znaleźć pojedynczy node o największym zużyciu. Node to w tym przypadku podstawowa operacja, taka jak dodawanie czy linear projection. Kiedy oflaguje ten node z peak memory, AutoChunk określa maksymalny możliwy zakres chunka rozchodzący się od niego na zewnątrz. Oblicza to, sprawdzając wszystkie aktywne node'y, które aktualnie trzymają dane w pamięci. Następnie identyfikuje każdą możliwą strategię chunkingu w tym zakresie, śledząc wymiary tensorów w górę grafu. Wymiar może być chunkowany tylko wtedy, gdy jest to free dimension, co oznacza, że w tym konkretnym zakresie operacji nie są na nim wykonywane żadne obliczenia. Ponieważ śledzenie każdego outputu w górę jest kosztowne obliczeniowo, AutoChunk używa dwuetapowego wyszukiwania. Etap pierwszy sprawdza, czy początkowe i końcowe node'y zakresu spełniają zasady chunkingu. Jeśli tak, etap drugi przeprowadza głęboką weryfikację dla wszystkich node'ów pośrednich. Po zmapowaniu możliwości, AutoChunk wybiera strategię, która utrzymuje pamięć ściśle poniżej budżetu, jednocześnie minimalizując narzut na execution speed. Na koniec algorytm wychodzi z pętli i przekazuje wybrane strategie do generatora kodu, wstawiając optymalną logikę partycjonowania bezpośrednio do grafu. Już nie musisz hardcodować slice'ów macierzy i mieć nadziei, że wytrzymają na produkcji. System analizuje aktywny stan pamięci i pisze logikę partycjonowania za ciebie. Najbardziej przydatny wniosek jest taki, że chunking nigdy nie powinien być statycznym ustawieniem na poziomie całego modułu. Izolując i partycjonując tylko te konkretne, odstające operacje, które powodują peak memory spikes, możesz przetwarzać znacznie dłuższe sekwencje bez zabijania execution speed. To wszystko w tym odcinku. Dzięki za wysłuchanie i keep building!

Cześć, tu Alex z DEV STORIES DOT EU. AlphaFold: Przewidywanie struktury białek, odcinek 18 z 21. Odpalasz potężny, wielomilionowy klaster z tysiącem GPU do trenowania swojego modelu, ale jego utilization spada do zera. Cały twój distributed ring zatrzymuje się, ponieważ pojedyncza maszyna pobrała bardzo złożoną sekwencję ewolucyjną i potrzebuje 100 sekund na wygenerowanie alignmentu. Pokonanie tej nierównowagi w komunikacji to sposób na rozwiązanie tego konkretnego bottlenecku. Ten podstawowy problem jest znany jako straggler problem. W distributed training, każde GPU w twoim klastrze przetwarza lokalny batch danych. Na końcu każdego kroku treningowego, wszystkie GPU muszą osiągnąć punkt synchronizacji, aby wymienić się gradientami. Twój klaster działa tylko tak szybko, jak jego absolutnie najwolniejsza maszyna. Jak szczegółowo opisano w publikacji ScaleFold autorstwa Zhu i innych, przygotowywanie batchy treningowych do zwijania białek jest bardzo zmienne w czasie. Niektóre sekwencje aminokwasów są krótkie i proste. Inne wymagają potężnych multi-sequence alignments, co zajmuje nawet trzy rzędy wielkości więcej czasu na przygotowanie. Szybki batch zajmuje ułamek sekundy. Wolny batch zajmuje 100 sekund. Jeśli używasz domyślnego data loadera w PyTorch, generuje on batche w ścisłej, deterministycznej kolejności. Jeśli jeden z twoich workerów data loadera utknie podczas przygotowywania ogromnej sekwencji, proces treningowy czeka na zakończenie tego konkretnego batcha. Nawet jeśli inne workery skończyły już przygotowywać kolejne batche, pipeline jest zablokowany. Twój krok treningowy się kończy, twoje lokalne GPU przechodzi w stan idle, a ponieważ nie może osiągnąć punktu synchronizacji, pozostałe 999 GPU w klastrze siedzi całkowicie bezczynnie, czekając na nie. Autorzy ScaleFold rozwiązali ten problem, budując Non-Blocking Data Pipeline. Zamiast wymuszać sztywną sekwencję, pipeline zwraca batch w momencie, gdy jakikolwiek przetwarzany batch staje się gotowy. Oto kluczowy wniosek. System oddziela kolejność przygotowywania danych od kolejności ich konsumpcji za pomocą priority queue. Najpierw przypisujesz wiele workerów data loadera do asynchronicznego przygotowywania batchy. Gdy worker otrzymuje batch do przetworzenia, system taguje ten batch jego oryginalnym indeksem sekwencji. Ten indeks staje się jego priority score. Prześledźmy tę logikę. Worker pierwszy dostaje batch A, szybką sekwencję. Worker drugi dostaje batch B, stusekundową sekwencję. Worker trzeci dostaje batch C, kolejną szybką sekwencję. Worker pierwszy natychmiast kończy batch A i wrzuca go do priority queue. Proces treningowy go konsumuje i wykonuje krok. Worker drugi wciąż miele potężny batch B. W domyślnym systemie, GPU zatrzymałoby się i czekało. Ale w tym non-blocking pipeline, worker trzeci kończy batch C i wrzuca go do priority queue. Ponieważ batch B wciąż nie jest gotowy, kolejka po prostu przekazuje batch C do procesu treningowego. GPU kontynuują trenowanie bez żadnej przerwy. W końcu worker drugi kończy batch B i wrzuca go do kolejki. Ponieważ batch B ma wcześniejszy oryginalny indeks, priority queue natychmiast umieszcza go na samym początku kolejki. Proces treningowy konsumuje go w następnym kroku. Ten mechanizm priorytetów gwarantuje kolejność próbek w trybie best-effort. Dokładna globalna sekwencja danych zmienia się nieznacznie w różnych przebiegach treningowych, ale publikacja potwierdza, że nie wpływa to negatywnie na konwergencję treningu. Eliminujesz czas idle spowodowany skokami zużycia CPU w tle i złożonymi próbkami danych. Najwolniejszy batch danych nie dyktuje już prędkości działania twojej najszybszej maszyny. To wszystko w tym odcinku. Dzięki za wysłuchanie i twórz dalej!

Cześć, tu Alex z DEV STORIES DOT EU. AlphaFold: Przewidywanie struktury białek, odcinek 19 z 21. Czasami GPU wcale nie jest wolne w obliczeniach. Po prostu spędza cały czas czekając, aż CPU wyda mu kolejną instrukcję, przez co twój profiler jest pełen ogromnych, białych plam. Rozwiązaniem tego problemu jest Kernel Fusion i optymalizacja GPU. Według paperu ScaleFold, trenowanie modelu AlphaFold wymaga odpalenia ponad 150 000 pojedynczych operacji na jeden step. Większość z nich to memory-bound kernels, takie jak małe LayerNorms czy pofragmentowane operacje element-wise. Za każdym razem, gdy CPU każe GPU uruchomić operację w PyTorch, pojawia się launch overhead. Kiedy połączysz ze sobą 150 000 małych operacji, ten overhead całkowicie przyćmiewa same obliczenia. Spójrz na Multi-Head Attention w AlphaFold, które zajmuje około trzydzieści cztery procent całkowitego czasu stepu treningowego. To nie jest standardowe attention. AlphaFold dodaje specyficzny pair bias do macierzy logits tuż przed operacją softmax. W domyślnym PyTorch tworzy to chain oddzielnych zdarzeń. Najpierw odpalasz kernel do batched matrix multiplication. GPU odczytuje dane z global memory, wykonuje obliczenia i zapisuje wynik z powrotem. Następnie CPU odpala drugi kernel, aby dodać pair bias. GPU ponownie odczytuje macierz z pamięci, dodaje bias i znów ją zapisuje. Na koniec odpala się trzeci kernel dla softmax. Ten ciągły round-trip do global memory sprawia, że GPU po prostu głoduje. Autorzy paperu ScaleFold rozwiązują ten problem, pisząc customowe kernele za pomocą kompilatora OpenAI Triton. Zamiast oddzielnych stepów, robią fuse całej sekwencji w jeden pojedynczy kernel. Oto kluczowy wniosek. Dzięki wykonaniu fuse operacji, GPU ładuje dane wejściowe do swojej szybkiej, wbudowanej pamięci SRAM tylko raz. Wykonuje matrix multiplication, dodaje pair bias, aplikuje softmax i robi końcowe mnożenie bezpośrednio w pamięci SRAM. Zapisuje wynik do global memory dopiero po zakończeniu całego bloku Multi-Head Attention. Standardowe, zoptymalizowane biblioteki, takie jak FlashAttention, tutaj nie zadziałają z powodu tego unikalnego wstrzykiwania pair bias, co sprawia, że customowy kernel w Triton jest absolutnie niezbędny, aby ominąć bottleneck w postaci memory bandwidth. To podejście rozciąga się też na inne pofragmentowane części modelu. LayerNorm pochłania czternaście procent czasu stepu, ponieważ AlphaFold używa małych wymiarów, zazwyczaj 128 lub 256. Podczas korzystania z Dynamic Axial Parallelism, czyli DAP, rozmiary tych problemów są skalowane w dół jeszcze bardziej, przez co hardware nie jest w pełni wykorzystany. ScaleFold wprowadza fused LayerNorm kernel, w którym pojedynczy thread block w CUDA przetwarza wiele wierszy wejściowych jednocześnie. Oblicza statystyki normalizacji w jednym passie, zamiast korzystać z kosztownych metod iteracyjnych, i wykorzystuje dwuetapową redukcję w backward pass, aby uniknąć operacji atomowych. Nawet optimizer jest fused. Autorzy ScaleFold połączyli optimizer Adam i Stochastic Weight Averaging w jeden pojedynczy kernel. Wartości pośrednie między stepami optimizera pozostają w rejestrach GPU, całkowicie omijając odczyty z pamięci. W pozostałej części modelu polegają na narzędziach kompilatora PyTorch, aby automatycznie zrobić fuse pozostałych, pofragmentowanych operacji, szczególnie w komponentach szeregowych, takich jak Structure Module. Kiedy masz do czynienia z tysiącami małych, memory-bound operacji, twoim bottleneckiem nie są teraflopy, tylko memory bandwidth i CPU launch overhead. Zrobienie fuse tych operacji w pojedyncze, ciągłe bloki wykonania to jedyny sposób na faktyczne wysycenie hardware'u. Dzięki za wysłuchanie, happy coding wszystkim!

Cześć, tu Alex z DEV STORIES DOT EU. AlphaFold: Przewidywanie struktury białek, odcinek 20 z 21. Skalowanie modelu AI ze 128 do 2000 GPU to nie tylko zakup dodatkowego sprzętu; wymaga to całkowitego przeprojektowania tego, jak system oddycha. Kiedy dodajesz tak dużą moc obliczeniową, odkrywasz ogromne bottlenecki w tym, jak twoje hosty komunikują się z akceleratorami. Rozwiązanie tych bottlenecków wymaga zbudowania pipeline'u o wysokiej przepustowości. Właśnie w ten sposób badacze skrócili niedawno czas pretrainingu AlphaFold z siedmiu dni do dziesięciu godzin. Projekt tej architektury pochodzi z paperu ScaleFold. Autorzy zidentyfikowali brutalną rzeczywistość skalowania. Kiedy dystrybuujesz model na tysiące GPU, matematyczny workload na pojedynczym GPU maleje. GPU kończą swoje obliczenia tak szybko, że CPU nie jest w stanie wydawać nowych instrukcji dla kerneli wystarczająco szybko, żeby zapewnić im ciągłą pracę. Overhead CPU staje się głównym bottleneckiem. Żeby to naprawić, usuwasz CPU z execution loopa, używając CUDA Graphs. CUDA Graph przechwytuje sekwencję operacji GPU i ich alokacje pamięci w jeden statyczny graf. Po przechwyceniu, GPU wykonuje cały graf bezpośrednio, bez czekania, aż CPU zdispatchuje każdy pojedynczy kernel. I tu pojawia się kluczowy wniosek. Nie możesz po prostu zastosować standardowych CUDA Graphs w AlphaFold. Architektura AlphaFold używa mechanizmu recyklingu, dynamicznie przekazując predykcje z powrotem do modelu. To tworzy dynamiczny graf obliczeniowy. Jeśli operacje się zmienią, standardowy CUDA Graph się wysypuje i musi zostać przechwycony ponownie, co rujnuje cały zysk wydajności. Paper ScaleFold rozwiązuje ten problem, projektując cache dla CUDA Graphs. Zamiast jednego sztywnego grafu, system przechwytuje i przechowuje wiele grafów, które reprezentują różne scenariusze recyklingu. Kiedy dynamiczne wykonanie się zmienia, system po prostu wyciąga odpowiedni, prekompilowany graf z cache'u. CPU jest całkowicie pomijane. A teraz drugi element tej architektury o wysokiej przepustowości. Kiedy czas twojego kroku treningowego jest już mocno zoptymalizowany, pojawia się nowy bottleneck. W standardowym pipelinie node'y treningowe okresowo pauzują, żeby policzyć metryki walidacyjne. Według paperu ScaleFold, w miarę jak czasy kroków maleją, ta faza ewaluacji może pochłaniać nawet 43 procent całkowitego czasu pipeline'u. Twój ogromny, drogi klaster treningowy siedzi bezczynnie przez prawie połowę czasu, tylko po to, żeby sprawdzać swoją własną robotę. Rozwiązaniem jest Asynchronous Evaluation. Całkowicie oddzielasz walidację od training loopa. Node'y treningowe nigdy nie pauzują. Stale obliczają gradienty, aktualizują wagi i streamują checkpointy modelu do oddzielnej, dedykowanej puli node'ów ewaluacyjnych. W implementacji ScaleFold, na około 2000 GPU, tylko 32 były dedykowane do ewaluacji. Reszta nie robiła nic poza trenowaniem. Jednak przeniesienie ewaluacji na oddzielne node'y wprowadza race condition. Node'y ewaluacyjne muszą skończyć walidację checkpointu, zanim node'y treningowe wyprodukują kolejny. Jeśli ewaluacja nie nadąża, twój pipeline się zatrzymuje. Żeby zagwarantować, że node'y ewaluacyjne nadążają, system całkowicie omija storage dyskowy. Cały dataset ewaluacyjny jest cache'owany bezpośrednio w DRAM CPU na node'ach walidacyjnych. Dzięki wyeliminowaniu overheadu związanego z dispatchem CPU za pomocą cache'owanych CUDA Graphs i offloadowaniu walidacji na asynchroniczne node'y z cache'em w pamięci, pipeline nigdy się nie zatrzymuje. Sprzęt jest w końcu wysycony. Kiedy projektujesz architekturę w dużej skali, twoim głównym zadaniem nie jest już optymalizacja matematyki; twoim głównym zadaniem jest pilnowanie, żeby GPU nie musiały czekać. To wszystko na dziś. Dzięki za wysłuchanie — idź zbudować coś fajnego.

Cześć, tu Alex z DEV STORIES DOT EU. AlphaFold: Przewidywanie struktury białka, odcinek 21 z 21. Przez lata branża zakładała, że przewidywanie struktury białka wymaga niezwykle wyspecjalizowanych, customowych architektur sieci neuronowych. Potrzebowałeś multiple sequence alignments, explicit pair representations i wymagających obliczeniowo triangular updates, żeby w ogóle uzyskać sensowny wynik. Ale co, gdyby standardowy, generyczny transformer mógł wykonać dokładnie to samo zadanie? Odpowiedzią jest koncepcja flow-matching w modelu SimpleFold. Paper Apple'a o SimpleFold to radykalne odejście od sztywnych architektur, które widzieliśmy w tradycyjnych modelach do foldingu. Całkowicie pozbywa się domain-specific heuristics. Tradycyjne modele hardkodują biologiczną intuicję w sieci. Wykorzystują multiple sequence alignments, żeby znaleźć ewolucyjne wskazówki, oraz triangle updates, żeby wymusić reguły geometryczne. Wymaga to ogromnego compute'u i wysoce wyspecjalizowanej inżynierii. SimpleFold porzuca te mechanizmy, stawiając zamiast tego na generatywny model flow-matching, zbudowany wyłącznie na generycznych blokach transformera. SimpleFold traktuje folding jako warunkowe zadanie generatywne. Pomyśl o modelach text-to-image, gdzie prompt tekstowy steruje generowaniem obrazka. Tutaj sekwencja aminokwasów jest promptem, a outputem jest trójwymiarowa struktura współrzędnych wszystkich atomów. Osiąga to za pomocą flow-matching. Flow-matching generuje dane, definiując ciągłą ścieżkę od prostego rozkładu szumu do złożonego rozkładu danych. Podczas treningu model uczy się pola prędkości zależnego od czasu. Całkuje zwyczajne równanie różniczkowe w czasie, stopniowo przesuwając losowy szum w kierunku rzeczywistych współrzędnych atomowych. Proces zaczyna się, gdy zamrożony, pre-trenowany protein language model, a konkretnie ESM2, konwertuje wejściową sekwencję aminokwasów na sequence embedding. W tym samym czasie atom encoder pobiera zaszumione współrzędne atomów i przetwarza je na atom tokens. I tu pojawia się kluczowy insight. Zamiast utrzymywać złożone, pamięciożerne pairwise interaction maps, SimpleFold wykorzystuje operację grupowania. Po prostu uśrednia atom tokens należące do tej samej reszty w pojedynczy residue token. Te residue tokens są konkatenowane z sequence embeddings i przekazywane do residue trunk. Ten trunk zawiera większość parametrów modelu. Składa się w całości ze standardowych bloków transformera z warstwami adaptacyjnymi warunkowanymi przez flow timestep. Nie ma tu żadnych geometric equivariant modules ani triangular math. Tylko standardowe operacje attention i skalowania. Na koniec operacja ungrouping broadcastuje zaktualizowane residue tokens z powrotem do poszczególnych atomów. Następnie atom decoder przewiduje pole prędkości, aby zaktualizować końcowe pozycje atomów. Podczas treningu system nie sampluje czasu równomiernie. Mocno oversampluje timesteps bliższe clean data manifold. Ponieważ struktury białek mają ścisłą hierarchię coarse-to-fine, to skupienie się na późnym etapie zmusza model do uczenia się wysoce dopracowanych struktur, w tym delikatnych łańcuchów bocznych. Co więcej, ponieważ model wykorzystuje generative objective, a nie deterministyczny regression objective, w naturalny sposób wychwytuje niepewność. Jeśli przepuścisz tę samą sekwencję przez SimpleFold wiele razy, może on wygenerować ensemble różnych prawidłowych konformacji, dokładnie odzwierciedlając to, jak białka faktycznie poruszają się i istnieją w naturze. SimpleFold udowadnia, że jeśli poprawnie zmapujesz problem, generyczny transformer może nauczyć się podstaw fizyki foldingu białek bezpośrednio z danych. Zachęcam cię do przeczytania papera, przejrzenia oficjalnej dokumentacji i spróbowania odpalenia kodu na własnym sprzęcie. Możesz również odwiedzić stronę devstories.eu, aby zasugerować tematy do naszej kolejnej serii. To wszystko w tym odcinku. Dzięki za wysłuchanie i keep building!