Rachunek za energię ukryty w projektowaniu modeli
Licznik w rogu
Pierwsza wartościowa rozmowa o energii zużywanej przez AI rzadko zaczyna się od karty modelu. Zaczyna się od licznika. Gdzieś w budynku, często w pomieszczeniu, którego nigdy nie oskarżano o wystrój wnętrz, energia elektryczna zamienia się w ciepło, opóźnienia, faktury i od czasu do czasu pożyteczną pracę. Pulpit nawigacyjny na górze może to nazywać inteligencją. Zespół techniczny nazywa to obciążeniem. Obie strony mają rację, ale tylko jedna z nich dostaje rachunek z liczbami, które trzeba zapłacić.
Energia zużywana przez AI jest często omawiana jako problem centrów danych. Lepsze chłodzenie, lepsze układy, czystsza energia, mądrzejsze planowanie, wydajniejsze szafy rack. To wszystko ma znaczenie. Osoby zajmujące się infrastrukturą od dawna wyciskają użyteczną pracę z watów, zwykle bez oklasków, jakie otrzymuje model, który aktualnie nosi koronę. Jednak zaskakująca część rachunku za energię jest zapisywana, zanim obciążenie dotrze do centrum danych. Jest zapisywana w projekcie modelu.
Architektura modelu zobowiązuje do przyszłego zużycia energii. Tak samo długość kontekstu. Tak samo wybór, by odpowiadać na każde pytanie dużym ogólnym modelem, gdy wystarczyłaby mniejsza, wyspecjalizowana ścieżka. Tak samo projekt wyszukiwania, który przenosi zbyt dużo tekstu, styl promptów, który upycha dokumenty w oknie kontekstowym, bo nikt nie chciał porządnie zbudować indeksowania, strategia dekodowania generująca niepotrzebne tokeny, ścieżka serwowania, która nie potrafi grupować żądań, wybór precyzji dokonany dla wygody oraz kultura ewaluacji, która nagradza błyskotliwe wyniki benchmarków, ignorując koszty operacyjne.
Rachunek za energię ukrywa się tam, ponieważ wybory projektowe wyglądają na abstrakcyjne. Większe okno kontekstowe brzmi jak możliwość. Większy model brzmi jak zapas mocy. Więcej narzędzi brzmi jak elastyczność. Więcej próbkowania brzmi jak kreatywność. Więcej wyszukiwania brzmi jak ugruntowanie. Każde z tych rozwiązań może być użyteczne. Każde z nich wymaga też pracy od infrastruktury. Czasem ta praca jest warta zachodu. Czasem maszyna spala energię, aby zrekompensować projekt, który nie chciał zdecydować, gdzie powinny mieszkać wiedza, pamięć, routing i odpowiedzialność.
Inferencja to moment, w którym projekt staje się rachunkiem za media
Trenowanie przyciąga większość uwagi, ponieważ liczby są duże, a klastry brzmią filmowo. Inferencja jest mniej dramatyczna i często bardziej uporczywa. To codzienna praca obsługi pytań, streszczeń, klasyfikacji, rekomendacji, wyszukiwań, agentów i narzędzi wewnętrznych. Każde żądanie może być małe. Razem stają się rachunkiem za media, który podąża za produktem jak bardzo punktualny księgowy.
Na koszt wnioskowania składa się ilość obliczeń, przesyłania danych w pamięci i sieci, niewykorzystane zasoby oraz liczba ponownych prób potrzebnych do uzyskania jednej wartościowej odpowiedzi. To sformułowanie „wartościowa odpowiedź" ma znaczenie. Jeśli system generuje trzy akapity tam, gdzie wystarczyłoby jedno pole, to nie tylko problem z doświadczeniem użytkownika. To energia zmarnowana na rozwlekłość. Jeśli proces wywołuje duży model pięć razy, bo nie został odpowiednio rozłożony na etapy, rachunek jest informacją zwrotną na temat projektu. Jeśli agent krąży w kółko po narzędziach, bo stan jest niejasny, ciepło wydzielane z szafy serwerowej to częściowo problem zarządzania w przebraniu problemu technicznego.
Duże okna kontekstowe są dobrym przykładem. Są cenne, gdy zadanie naprawdę wymaga długiego materiału dowodowego. Są marnotrawstwem, gdy służą jako substytut selekcji źródeł. Wrzucenie całego podręcznika polityki do kontekstu, bo wyszukiwanie jest słabe, to odpowiednik przynoszenia całej szafy na dokumenty na spotkanie na wypadek, gdyby jeden akapit okazał się istotny. Działa, dopóki ktoś nie musi tej szafy nieść. W informatyce niesienie szafy oznacza zużycie pasma pamięci, koszt uwagi, opóźnienia i energię.
Lepszy projekt modelu wymaga pytania, jakie informacje powinny znajdować się w wagach, co w wyszukiwaniu, co w narzędziach, co powinno być buforowane, co obliczane lokalnie, a czemu należy odmówić. To pytania o energię w równym stopniu, co o architekturę. Odmowa może oszczędzić energię, gdy zadanie wykracza poza zakres. Mały klasyfikator może skierować pracę, zanim obudzi się duży model. Dobry indeks może zmniejszyć kontekst. Typowane narzędzie może zwrócić wartość bez proszenia modelu językowego o opowiadanie, jak wykonuje arytmetykę, co jest łaskawe zarówno dla watów, jak i dla czytelników.
Rozmiar to nie to samo co siła
Wyobraźnia publiczna wciąż traktuje rozmiar modelu jako prosty wskaźnik mocy. Większy musi być lepszy, albo przynajmniej poważniejszy. Inżynierowie wiedzą, że historia jest mniej uporządkowana. Duży gęsty model może być doskonały, ale nie jest automatycznie właściwą jednostką operacyjną do każdego zadania. Wiele zadań produkcyjnych ma wąską strukturę: sklasyfikuj ten typ dokumentu, wyodrębnij te pola, odpowiedz na podstawie tego źródła, przetłumacz ten formularz, przekieruj ten bilet, sprawdź ten warunek polityki. Używanie maksymalnej ogólności do minimalnej niejednoznaczności jest czasem jak podgrzewanie zupy silnikiem odrzutowym. Technicznie możliwe. Reakcje sąsiedztwa bywają różne.
Mniejsze modele, wyspecjalizowane głowice, architektury z wyszukiwaniem, ograniczone dekodery, kontrolki symboliczne i klasyczne algorytmy mogą zmniejszyć zużycie energii, jeśli są używane we właściwym miejscu. Nie chodzi o małość samą w sobie. Chodzi o dopasowanie do zadania. Kompaktowy model, który niezawodnie obsługuje jedno zadanie o dużej skali, może być znacznie wydajniejszy niż uniwersalny model proszony o udawanie, że każde zadanie jest nowością. Silnik reguł może być lepszy do deterministycznej oceny kwalifikowalności. Zapytanie do bazy danych może być lepsze dla znanych faktów. Indeks wyszukiwania może być lepszy do wyboru kandydatów. Model językowy może wtedy robić to, w czym modele językowe są dobre: syntezę, obsługę niejednoznaczności, wyjaśnianie i tworzenie szkiców w określonych granicach.
Architektury mieszane i rzadkie komplikują obraz. Aktywowanie tylko części modelu może zmniejszyć obliczenia, ale routing, układ pamięci, grupowanie i wsparcie sprzętowe decydują, czy teoretyczna oszczędność stanie się realna. Elegancka architektura na papierze może stać się korkiem w produkcji, jeśli żądania rozpraszają się między ekspertami, a pamięć nie nadąża. Wydajność to nie slogan dołączany do artykułu. To właściwość całej ścieżki serwowania.
Dlatego projektowanie świadome zużycia energii wymaga pomiarów w środowisku, w którym system będzie działał. Sama dokładność benchmarku nie wystarczy. Liczą się tokeny na dżul, obciążenie pamięci, rozkład opóźnień, możliwość grupowania, współczynnik trafień w pamięci podręcznej, ruch sieciowy, zimne starty i ponowne próby po błędach. Najlepsza architektura to nie ta, która wygrywa na jednym wykresie. To ta, która zapewnia wymaganą jakość przy najmniejszej możliwej do uniknięcia pracy przy rzeczywistym obciążeniu.
Przenoszenie pamięci to cicha praca
Ludzie lubią liczyć operacje. Sprzęt często narzeka na przenoszenie. Przenoszenie wag, aktywacji, kluczy, wartości, fragmentów źródła, osadzeń i logów przez pamięć i sieci pochłania czas i energię. Model może mieć imponujące możliwości arytmetyczne, a mimo to być ograniczony przez ilość danych, które trzeba przenieść, aby go zasilić. Użytkownik widzi spinner. Infrastruktura widzi usługę dostarczania liczb.
Projekt modelu wpływa na to przenoszenie. Wybór precyzji określa, ile bajtów podróżuje dla każdej wartości. Kwantyzacja może zmniejszyć zapotrzebowanie na przepustowość pamięci i pojemność, ale trzeba ją przetestować pod kątem zadania, bo tania błędna odpowiedź to nie efektywność. Długość kontekstu określa, ile stanu jest przenoszone przez uwagę. Projekt wyszukiwania określa, ile fragmentów trafia do promptu. Buforowanie określa, czy powtarzająca się praca jest unikana. Lokalność określa, czy dane podróżują między regionami, usługami czy urządzeniami, zanim pojawi się token.
Niektóre z najlepszych oszczędności energii są nieefektowne. Przypnij właściwą wersję modelu. Unikaj zbędnego szablonu w promptach. Usuń powtarzane instrukcje, które nic nie robią. Tam, gdzie przepływ pracy potrzebuje pól, używaj ustrukturyzowanych wyników zamiast rozwlekłej prozy. Buforuj stabilne wyniki narzędzi. Deduplikuj dokumenty przed indeksowaniem. Wygaś nieaktualne osadzenia. Trzymaj gorące indeksy blisko ścieżki serwowania. Grupuj zgodne żądania. Kompiluj typowe ścieżki. Mierz wyjściowe tokeny, nie tylko wejściowe. To nie są wielkie gesty. To sprzątanie z watomierzem.
Trudna strona jest taka, że wiele zespołów nie postrzega przenoszenia pamięci jako problemu produktowego. Widzą to jako instalację infrastrukturalną. Ale użytkownicy płacą za to opóźnieniem, organizacje płacą rachunkami za energię i chmurę, a społeczeństwo płaci zapotrzebowaniem na sieć. Jeśli projekt produktu zachęca do długich promptów, powtarzanych wywołań, niepotrzebnych ponowień i zawsze włączonych modeli ogólnych, to produkt jest częścią systemu energetycznego. Licznik energii elektrycznej nie dba o to, który dział podjął decyzję. Ma godną podziwu pogardę dla schematów organizacyjnych.
Energia wycieka przez cały stos
Rachunek za energię nie znajduje się w jednej warstwie. Wycieka przez cały stos. Wybory dotyczące danych treningowych wpływają na rozmiar i specjalizację modelu. Wybory architektoniczne wpływają na aktywacje i pamięć. Wybory dotyczące tokenizera i kontekstu wpływają na długość sekwencji. Wybory dotyczące wyszukiwania wpływają na przenoszenie i ugruntowanie. Wybory dotyczące promptów wpływają na tokeny. Wybory dotyczące dekodowania wpływają na długość wyjścia. Wybory dotyczące serwowania wpływają na grupowanie i moc jałową. Wybory sprzętowe wpływają na efektywność. Wybory dotyczące monitorowania wpływają na to, jak szybko wykrywane są straty. Jeśli nikt nie zarządza całą ścieżką, strata staje się drobnym problemem wszystkich innych, a licznik kontynuuje swoją cichą pracę.
Widok warstw pomaga, bo pokazuje, gdzie interwencje są potrzebne. Jeśli problemem jest zbyt duży kontekst, zakup lepszego sprzętu może tylko odroczyć rachunek. Jeśli problemem jest słabe routowanie, kwantyzacja może pomóc mniej niż tani klasyfikator z przodu. Jeśli problemem jest niskie wykorzystanie zasobów, architektura może mieć mniejsze znaczenie niż grupowanie i planowanie zadań. Jeśli problemem jest nieaktualne wyszukiwanie, energia jest marnowana na generowanie dopracowanych odpowiedzi z niewłaściwego materiału, co jest tragicznym wykorzystaniem elektronów.
Są oczywiście kompromisy. Redukcja zużycia energii nie może odbywać się kosztem bezpieczeństwa, dostępności ani sprawiedliwości. Mniejszy model, który zawodzi w przypadkach brzegowych, może po prostu przenieść koszt na ludzi. Agresywne buforowanie może serwować nieaktualne odpowiedzi. Kwantyzacja może szkodzić rzadkim zachowaniom językowym. Trasa lokalna może zmniejszyć ruch sieciowy, ale zwiększyć duplikację. Te kompromisy są realne. Odpowiedzią jest pomiar, nie hasła. Mierz jakość, energię, opóźnienia, naprawę błędów i obciążenie ludzi razem. Wat zaoszczędzony kosztem personelu naprawiającego złe wyniki nie jest oszczędnością. To po prostu przeniesienie ciepła na ludzi.
Dlatego zużycie energii przez model powinno być częścią przeglądu projektu. Nie jako moralny dodatek, ale jako właściwość inżynieryjna. Jakie jest oczekiwane zużycie energii na użyteczną odpowiedź. Które komponenty dominują. Które żądania są odstające. Jaka jest ścieżka awaryjna. Co się dzieje podczas szczytowego obciążenia. Co można buforować. Które zadania powinny unikać dużego modelu. Jakie dowody pokażą, że projekt się poprawia. Te pytania należą obok dokładności i bezpieczeństwa, nie na slajdzie o zrównoważonym rozwoju dodanym przez kogoś ze stockowym zdjęciem liścia.
Okno kontekstu nie jest przyciskiem pomijania
Długi kontekst stał się kuszącym przyciskiem pomijania dla architektury. Po co budować staranne wyszukiwanie, ranking źródeł, streszczenia, filtrowanie dostępu i strukturę dokumentów, skoro model może przeczytać wszystko. Odpowiedź brzmi: czytanie wszystkiego to praca. Co ważniejsze, czytanie wszystkiego to często gorsze zarządzanie. Model otrzymuje nieistotny materiał, wrażliwy materiał, nieaktualny materiał i sprzeczny materiał, a następnie musi zdecydować, co jest ważne, w bardzo kosztownym wzorcu uwagi.
Dobry projekt kontekstu jest selektywny. Traktuje okno kontekstu jako ograniczoną pamięć roboczą, a nie jednostkę pamięci z problemami zaufania. Wybór źródeł powinien następować przed generowaniem. Dokumenty powinny być dzielone na fragmenty ze zrozumieniem, a nie cięte na arbitralne kawałki, bo domyślna opcja biblioteki wyglądała oficjalnie. Metadane powinny zawierać daty, autorytet, wrażliwość i zakres. Filtry dostępu powinny działać przed wyszukiwaniem. Streszczenia powinny być buforowane, gdy są stabilne. Model powinien otrzymywać dowody potrzebne do zadania, a nie miejskie archiwum w przebraniu podpowiedzi.
To jest problem energetyczny, ponieważ koszt uwagi rośnie wraz z długością sekwencji oraz dlatego, że długie prompty zwiększają przepływ pamięci, opóźnienia i pokusę generowania długich odpowiedzi. Model mający duży kontekst może też udzielać dłuższych odpowiedzi, bo widział więcej materiału. Wynik również zużywa energię. Systemy projektowane ze świadomością energetyczną szukają krótkich ścieżek do użytecznych odpowiedzi. Nie nagradzają maszyny za pisanie przewodnika po materiale dowodowym, gdy przepływ pracy wymaga jednego pola decyzji i kodu powodu.
Jest też pułapka ewaluacyjna. Systemy z długim kontekstem mogą robić wrażenie w demonstracjach, bo odpowiadają na pytania dotyczące dużych dokumentów. W produkcji dominować mogą jednak małe, powtarzalne, ustrukturyzowane pytania. Jeśli ścieżka serwowania traktuje każde żądanie jak rzadką zagadkę badawczą, rachunek za energię grzecznie wyjaśni różnicę między demonstracją a usługą. Posłuży się liczbami, bo faktury są godne podziwu pod względem zwięzłości.
Routing jako kontrola energii
Routing to jedna z najbardziej niedocenianych kontroli energii w systemach AI. Zanim żądanie dotrze do dużego modelu, system może zdecydować, czy żądanie mieści się w zakresie, czy istnieje odpowiedź z pamięci podręcznej, czy może odpowiedzieć narzędzie deterministyczne, czy wystarczy mały model, czy potrzebne jest wyszukiwanie, czy sprawą powinien zająć się człowiek, czy system powinien odmówić. Każda z tych gałęzi może oszczędzić pracę i poprawić jakość, jeśli jest zaprojektowana uczciwie.
Zły routing działa odwrotnie. Wysyła każde pytanie tą samą kosztowną ścieżką. Wywołuje narzędzia po generacji zamiast przed nią. Każe modelowi klasyfikować coś, co już zna pole formularza. Prosi o prozę tam, gdzie wystarczyłaby wartość logiczna. Powtarza wywołania, bo stan nie jest przenoszony dalej. Pozwala agentowi eksplorować, bo nikt nie określił granic zadania. Wynikające z tego zużycie energii nie jest winą układu. Układ robi to, o co go poproszono, ze zmęczonym profesjonalizmem całej infrastruktury.
Routing świadomy energetycznie wymaga progów pewności, reguł zakresu, kontroli świeżości źródeł, unieważniania pamięci podręcznej i przekazywania spraw człowiekowi. Powinien być na tyle przejrzysty, aby operatorzy mogli zobaczyć, którą trasę wybrano i dlaczego. Powinien być oceniany nie tylko pod kątem średniego kosztu, ale także przypadków skrajnych. Reguła routingu, która oszczędza energię w typowych żądaniach, ale wysyła trudne przypadki w powtarzające się błędy, może zwiększyć całkowity koszt po uwzględnieniu wsparcia, ponowień i ręcznych napraw. Trasę należy oceniać po użytecznym ukończeniu zadania.
Jest też wymiar ludzki. Dobry routing zmniejsza obciążenie poznawcze. Proste przypadki kieruje do prostych mechanizmów, ustrukturyzowane do systemów ustrukturyzowanych, niejednoznaczne do modeli, a wrażliwe do ludzi mających dowody. To wydajność w szerszym sensie. Efektywność energetyczna i jasność instytucjonalna często wskazują ten sam kierunek: nie obciążaj najbardziej ogólnego komponentu każdą odpowiedzialnością tylko dlatego, że potrafi wyprodukować zdanie.
Lokalność i kształt popytu
Na energię wpływa też to, gdzie popyt spotyka się z podażą. Jeśli dane są w jednym miejscu, modele w drugim, logi w trzecim, a użytkownicy w czwartym, każda odpowiedź może wiązać się z ruchem sieciowym i zdublowanym przechowywaniem. Czasem taki rozkład jest konieczny. Czasem to przypadkowy skutek kupowania usług w kolejności, w jakiej stawały się modne. Wybory dotyczące lokalności wpływają jednocześnie na opóźnienia, odporność, zarządzanie i energię.
Przetwarzanie brzegowe i lokalna inferencja mogą zmniejszyć ruch w przypadku powtarzalnych lub wrażliwych zadań, ale mogą też dublować zasoby i obniżać wykorzystanie, jeśli stosuje się je bezrefleksyjnie. Centralne serwowanie może poprawić wykorzystanie i wydajność sprzętu, ale może zwiększyć ruch sieciowy i koncentrację zależności. Rozwiązania regionalne mogą równoważyć oba podejścia. Właściwa odpowiedź zależy od kształtu popytu: wolumenu, powtarzalności, wrażliwości, tolerancji na opóźnienia, lokalizacji źródeł, wzorców szczytowych i trybów awarii.
Dlatego średnie nie wystarczają. Średni koszt pojedynczego żądania może być niski, podczas gdy górne pięć procent żądań dominuje w zużyciu energii. Niewielka grupa zadań z długim kontekstem może zużywać więcej mocy niż tysiące krótkich klasyfikacji. Nocne zadania wsadowe mogą ukrywać możliwą do uniknięcia ponowną kalkulację. Ponowne próby agentów mogą nasilać się podczas awarii źródła. Projektowanie świadome energetycznie patrzy na rozkład, a nie tylko na średnią. Średnia to miejsce, gdzie problemy wyglądają na szanowane.
Popyt powinien zmieniać projekt. Jeśli użytkownicy wielokrotnie zadają to samo pytanie faktyczne, zapisz odpowiedź w pamięci podręcznej lub opublikuj ją. Jeśli wielokrotnie potrzebują jednego pola z dokumentu, zbuduj ekstrakcję. Jeśli zadają szerokie pytania, bo interfejs ukrywa strukturę, napraw interfejs. Jeśli agenci wielokrotnie wywołują narzędzia, bo stan jest niejasny, przeprojektuj stan. Każdy powtarzający się wat to wskazówka projektowa. Niektóre wskazówki są subtelne. Miesięczny rachunek do nich nie należy.
Pętla modelu świadoma energetycznie
Praktyczna odpowiedź nie polega na uczynieniu energii jedynym celem. To byłoby głupie i czasem szkodliwe. Ciemny serwer jest bardzo wydajny, ale nie jest wielką usługą. Zadanie polega na włączeniu energii do pętli projektowania obok jakości, bezpieczeństwa, opóźnień, prywatności, odporności i łatwości utrzymania. Mierz użyteczną pracę. Ogranicz zadanie. Wybierz najmniejszy adekwatny solver. Wdrażaj z obserwowalnością. Obserwuj rzeczywisty popyt. Zmieniaj projekt, gdy pojawiają się marnotrawstwa.
Pętla potrzebuje wspólnego języka. Zespoły produktowe powinny znać koszt energetyczny wzorców projektowych: długich promptów, powtarzanych wywołań, rozwlekłych wyników, zawsze włączonych agentów, nieograniczonych narzędzi. Inżynierowie powinni znać wartość użytkownika z dodatkowych obliczeń: mniej błędów, lepsza dostępność, bezpieczniejsze decyzje, krótszy wysiłek ludzki. Zespoły operacyjne powinny wiedzieć, które obciążenia dominują w rachunku. Zespoły zarządzania powinny wiedzieć, kiedy redukcje energii zmieniają ryzyko. Zespoły ds. zrównoważonego rozwoju powinny być w pomieszczeniu, zanim system nauczy się drogich nawyków.
Nie chodzi o poczucie winy. Poczucie winy to słaby profiler. Chodzi o znajomość projektowania. Gdy zespoły zobaczą, że energia jest zobowiązana przez architekturę, mogą wybierać lepiej. Mogą zachować duże modele dla zadań, które ich potrzebują, mniejsze modele dla zadań ograniczonych, wyszukiwanie dla wiedzy, narzędzia dla pracy deterministycznej, pamięci podręczne dla powtórzeń, ludzi dla oceny, a odmowę dla nonsensu. Wynik jest często tańszy, szybszy i jaśniejszy, co jest przyzwoitym rezultatem dla tematu, który zaczął się od licznika energii elektrycznej w smutnym pokoju.
Lekcja
Rachunek za energię AI nie jest ukryty tylko w centrum danych. Jest ukryty w projektowaniu modelu: rozmiar, architektura, kontekst, wyszukiwanie, precyzja, routing, lokalność, buforowanie, forma wyniku, ocena i odmowa. Wydajność sprzętu ma znaczenie, ale sprzęt realizuje czeki, które projekt już wypisał.
Dobra infrastruktura AI zaczyna się więc wcześniej niż zakup akceleratorów. Zaczyna się od pytania o użyteczną pracę. Jaka odpowiedź jest potrzebna. Ile języka jest konieczne. Który solver pasuje. Która wiedza powinna żyć w wagach, wyszukiwaniu, narzędziach czy regułach. Które żądania należy odrzucać. Które dowody pokażą marnotrawstwo. Które wybory projektowe tworzą zbędny ruch. Które wywołania dużych modeli faktycznie wykonują pracę dużych modeli.
Projektowanie modeli z myślą o energii to nie oszczędność. To precyzja. Utrzymuje możliwości tam, gdzie się opłacają, i usuwa pracę tam, gdzie jest tylko nawykiem. Efekt to nie tylko mniejszy rachunek. To często lepszy system: szybszy, łatwiejszy do zarządzania, łatwiejszy do skalowania, łatwiejszy do wyjaśnienia i mniej zależny od heroicznej infrastruktury, która rekompensuje leniwe projektowanie. Licznik w rogu mówił prawdę przez cały czas. Wystarczyło odczytać go jako architekturę.