```html Autorzy: Mayank Mishra⋆, IBM Matt Stallone⋆, IBM Gaoyuan Zhang⋆, IBM Yikang Shen, IBM Aditya Prasad, IBM Adriana Meza Soria, IBM Michele Merler, IBM Parameswaran Selvam, IBM Saptha Surendran, IBM Shivdeep Singh, IBM Manish Sethi, IBM Xuan-Hong Dang, IBM Pengyuan Li, IBM Kun-Lung Wu, IBM Syed Zawad, IBM Andrew Coleman, IBM Matthew White, IBM Mark Lewis, IBM Raju Pavuluri, IBM Yan Koyfman, IBM Boris Lublinsky, IBM Maximilien de Bayser, IBM Ibrahim Abdelaziz, IBM Kinjal Basu, IBM Mayank Agarwal, IBM Yi Zhou, IBM Chris Johnson, IBM Aanchal Goyal, IBM Hima Patel, IBM Yousaf Shah, IBM Petros Zerfos, IBM Heiko Ludwig, IBM Asim Munawar, IBM Maxwell Crouse, IBM Pavan Kapanipathi, IBM Shweta Salaria, IBM Bob Calio, IBM Sophia Wen, IBM Seetharami Seelam, IBM Brian Belgodere, IBM Carlos Fonseca, IBM Amith Singhee, IBM Nirmit Desai, IBM David D. Cox, IBM Ruchir Puri†, IBM Rameswar Panda†, IBM Abstrakt Duże modele językowe (LLM) wytrenowane na kodzie rewolucjonizują proces tworzenia oprogramowania. Coraz częściej kody LLM są integrowane ze środowiskami tworzenia oprogramowania w celu zwiększenia produktywności ludzkich programistów, a agenci oparte na LLM zaczynają wykazywać obiecujące wyniki w samodzielnym radzeniu sobie ze złożonymi zadaniami. Pełne wykorzystanie potencjału kodów LLM wymaga szerokiego zakresu możliwości, w tym generowania kodu, naprawiania błędów, wyjaśniania i dokumentowania kodu, utrzymywania repozytoriów i nie tylko. W niniejszej pracy przedstawiamy serię modeli kodowych Granite typu decoder-only do zadań generowania kodu, wytrenowanych na kodzie napisanym w 116 językach programowania. Rodzina modeli Granite Code składa się z modeli o rozmiarach od 3 do 34 miliardów parametrów, odpowiednich do zastosowań od złożonych zadań modernizacji aplikacji po przypadki użycia z ograniczeniami pamięci na urządzeniu. Ocena na obszernym zestawie zadań pokazuje, że modele Granite Code konsekwentnie osiągają najnowocześniejsze wyniki wśród dostępnych otwartych kodów LLM. Rodzina modeli Granite Code została zoptymalizowana pod kątem przepływów pracy w przedsiębiorstwach zajmujących się tworzeniem oprogramowania i dobrze sprawdza się w wielu zadaniach związanych z kodowaniem (np. generowanie, naprawianie i wyjaśnianie kodu), co czyni ją wszechstronnym kodem LLM „wszystkomogącym”. Udostępniamy wszystkie nasze modele Granite Code na licencji Apache 2.0 zarówno do celów badawczych, jak i komercyjnych. https://github.com/ibm-granite/granite-code-models 1 Wprowadzenie Przez ostatnie kilka dekad oprogramowanie stało się integralną częścią każdego aspektu naszego społeczeństwa. Wraz ze wzrostem popytu na tworzenie oprogramowania, kluczowe jak nigdy dotąd jest zwiększenie produktywności tworzenia oprogramowania, a LLM stanowią obiecującą ścieżkę do wspomagania ludzkich programistów. Znaczące przypadki użycia LLM w przedsiębiorstwach w celu zwiększenia produktywności tworzenia oprogramowania obejmują generowanie kodu, wyjaśnianie kodu, naprawianie kodu, generowanie testów jednostkowych i dokumentacji, modernizację aplikacji, wykrywanie luk, tłumaczenie kodu i inne. W ostatnich latach nastąpił szybki postęp w zdolności LLM do generowania i manipulowania kodem, a dziś dostępna jest gama modeli o imponujących zdolnościach kodowania. Modele mają rozmiary od pojedynczych miliardów parametrów (np. Llama-7B (Touvron i in., 2023), Gemma-7B (Gemma-Team i in., 2024) itp.) do setek miliardów: DBRX (Databricks), Arctic (Snowflake), Grok, Mixtral 8x22B (MistralAI), Command R+ (Cohere) i różnią się przeznaczeniem, przy czym niektóre modele mają na celu objęcie szerokiego zakresu zastosowań poza kodem, podczas gdy inne skupiają się głównie na zadaniach związanych z kodowaniem (np. StarCoder (Li i in., 2023a; Lozhkov i in., 2024), CodeGen (Nijkamp i in., 2023), CodeLlama (Rozie`re i in., 2023), CodeGemma (CodeGemma Team i in., 2024)). Jednakże, w obecnym polu LLM dla kodu istnieją ważne luki, szczególnie w kontekście tworzenia oprogramowania w przedsiębiorstwach. Po pierwsze, chociaż bardzo duże, ogólne LLM mogą osiągać doskonałe wyniki w kodowaniu, ich rozmiar sprawia, że są drogie wdrożeniu. Mniejsze modele skupione na kodzie ( , ; , ; , ; , ; , ) mogą osiągać doskonałe wyniki w generowaniu kodu w mniejszym i bardziej elastycznym pakiecie, ale wydajność w zadaniach kodowania poza generowaniem (np. naprawa i wyjaśnianie) może być niższa niż wydajność generowania kodu. Li i in. 2023a Lozhkov i in. 2024 Nijkamp i in. 2023 Rozie`re i in. 2023 CodeGemma Team i in. 2024 W wielu kontekstach przedsiębiorstw adopcja kodów LLM może być dodatkowo skomplikowana przez czynniki wykraczające poza wydajność modeli. Na przykład, nawet otwarte modele czasami cierpią na brak przejrzystości co do źródeł danych i metod przetwarzania danych użytych do stworzenia modelu, co może podważyć zaufanie do modeli w krytycznych dla misji i regulowanych kontekstach. Ponadto, warunki licencyjne w dzisiejszych otwartych LLM mogą utrudniać i komplikować możliwość wykorzystania modelu przez przedsiębiorstwo. Prezentujemy modele Granite Code, serię wysoce zdolnych kodów LLM, zaprojektowanych do wspierania tworzenia oprogramowania w przedsiębiorstwach w szerokim zakresie zadań kodowania. Modele Granite Code mają dwa główne warianty, które udostępniamy w czterech różnych rozmiarach (3B, 8B, 20B i 34B): podstawowe modele bazowe do zadań związanych z kodowaniem; Granite Code Base: modele podążające za instrukcjami, dostrojone przy użyciu kombinacji commitów Git powiązanych z instrukcjami ludzkimi oraz otwartych, syntetycznie generowanych zbiorów danych instrukcji kodu. Granite Code Instruct: Podstawowe modele w serii zostały wytrenowane od podstaw przy użyciu dwuetapowej strategii treningowej. W fazie 1 nasz model jest trenowany na 3-4 bilionach tokenów pochodzących ze 116 języków programowania, zapewniając kompleksowe zrozumienie języków programowania i składni. W fazie 2 nasz model jest dalej trenowany na 500 miliardach tokenów z starannie zaprojektowaną mieszanką wysokiej jakości danych z domen kodu i języka naturalnego, aby poprawić zdolność modelu do rozumowania. Używamy nienadzorowanego celu modelowania językowego do trenowania podstawowych modeli w obu fazach treningu. Modele instruujące są pochodnymi dalszego dostrajania powyższych wytrenowanych modeli bazowych na kombinacji przefiltrowanej wersji CommitPack ( , ), zbiorów danych podążających za instrukcjami w języku naturalnym (OASST ( , ), HelpSteer ( , )) i otwartych zbiorów danych matematycznych (MathInstruct ( , ) i MetaMathQA ( , )), w tym syntetycznie generowanych zbiorów danych kodu w celu poprawy umiejętności podążania za instrukcjami i rozumowania. Muennighoff i in. 2023 Ko¨ pf i in. 2023 Wang i in. 2023 Yue i in. 2023 Yu i in. 2023 Przeprowadzamy obszerne oceny naszych kodów LLM na kompleksowym zestawie benchmarków, w tym HumanEvalPack ( , ), MBPP(+) ( , ; , ), RepoBench ( , ), ReCode ( , ) i inne. Ten zestaw benchmarków obejmuje wiele różnych rodzajów zadań kodowania poza samą syntezą kodu w Pythonie, np. naprawianie kodu, wyjaśnianie kodu, edycja kodu, tłumaczenie kodu itp., w większości głównych języków programowania (Python, JavaScript, Java, Go, C++, Rust itp.). Muennighoff i in. 2023 Austin i in. 2021 Liu i in. 2023a Liu i in. 2023b Wang i in. 2022 Nasze wyniki pokazują, że wśród otwartych modeli, modele Granite Code ogólnie wykazują bardzo silną wydajność we wszystkich rozmiarach modeli i benchmarkach (często przewyższając inne otwarte modele kodu, które są dwukrotnie większe od Granite). Dla ilustracji, rysunek 1 (na górze) pokazuje porównanie Granite-8B-Code-Base z innymi otwartymi podstawowymi kodami LLM, w tym z niedawno wydanymi, wysoko wydajnymi, ogólnymi podstawowymi LLM, takimi jak Mistral ( , ) i LLama-3 ( , ) na HumanEvalPack ( , ). Chociaż CodeGemma i StarCoder2 działają rozsądnie dobrze w generowaniu kodu, znacznie gorzej radzą sobie z wariantami HumanEvalPack dotyczącymi naprawy i wyjaśniania kodu. Średnio, Granite-8B-Code-Base przewyższa najbardziej konkurencyjny model CodeGemma-8B o prawie 12 punktów na HumanEvalPack (33,2% vs 21,3%), pomimo trenowania na znacznie mniejszej liczbie tokenów (4,5T vs 7,5T tokenów). Oprócz podstawowych modeli, instruowane warianty naszych modeli Granite Code również wykazują silną wydajność na HumanEvalPack, przewyższając inne otwarte (kodowe) modele instruujące, co demonstruje korzyści dla szerszego zestawu zadań kodowania z instrukcjami w języku naturalnym (patrz rysunek 1 (na dole)). Jiang i in. 2023b AI@Meta 2024 Muennighoff i in. 2023 Ponadto, ponieważ rozumowanie jest kluczowe dla rozwiązywania skomplikowanych pytań i zadań, testujemy również nasz model Granite-8B-Code-Base na sześciu benchmarkach matematycznych, w tym MATH ( , ), GSM8K ( , ) i rozwiązywanie problemów z dostępem do narzędzi obliczeniowych, gdzie nasz model Granite 8B osiąga lepsze wyniki w porównaniu do większości najnowocześniejszych LLM o wielkości 7B lub 8B. Na przykład, Granite-8B-Code-Base przewyższa Llama-3-8B-Base o około 12 punktów na GSM8K i około 6 punktów na MATH (patrz tabela 15). Cobbe i in. 2021 Cobbe i in. 2021 Główne zalety modeli Granite Code obejmują: : Modele Granite Code osiągają konkurencyjną lub najnowocześniejszą wydajność w różnych rodzajach zadań związanych z kodowaniem, w tym w generowaniu, wyjaśnianiu, naprawianiu, edycji, tłumaczeniu kodu itp., demonstrując ich zdolność do rozwiązywania różnorodnych zadań kodowania; Wszechstronny kod LLM : Wszystkie nasze modele są trenowane na danych dopuszczonych do licencjonowania, zebranych zgodnie z zasadami etyki AI firmy IBM , i kierowanych przez zespół prawny firmy IBM w celu zapewnienia niezawodnego użytkowania w przedsiębiorstwach. Wszystkie modele Granite Code są udostępniane na licencji Apache 2.0. Niezawodny kod LLM klasy korporacyjnej 1 Opisujemy nasz cały potok zbierania, filtrowania i przetwarzania danych w sekcji 2. Sekcja 3 opisuje szczegóły architektury modelu, a następnie szczegóły treningu w Sekcji 4. Sekcja 5 zawiera szczegóły dotyczące dostrajania instrukcji, a Sekcja 6 opisuje eksperymenty i wyniki porównujące modele Granite Code z innymi kodami LLM. 2 Zbieranie danych W tej sekcji opisujemy proces przeszukiwania i filtrowania (Sekcja 2.1), deduplikacji (Sekcja 2.2), filtrowania HAP/PII (Sekcja 2.3) używany do przygotowania danych kodowych do treningu modelu. Przedstawiamy również przegląd wysokiej jakości danych w języku naturalnym użytych do poprawy zrozumienia języka i umiejętności rozumowania matematycznego modelu. 2.1 Przeszukiwanie i filtrowanie danych Dane kodu do wstępnego trenowania pochodziły z kombinacji publicznie dostępnych zbiorów danych, takich jak Github Code Clean , StarCoderdata , a także dodatkowych publicznych repozytoriów kodu i zgłoszeń z GitHub. Filtrujemy surowe dane, aby zachować listę 116 języków programowania spośród ponad 300 języków, wymienionych w załączniku A. Przypisywanie danych do języków programowania odbywa się wyłącznie na podstawie rozszerzenia pliku, podobnie jak w StarCoder ( , ). Po przefiltrowaniu języków stosujemy cztery kluczowe zasady filtrowania, aby odrzucić kod niższej jakości ( , ): (1) usuń pliki z mniejszą niż 25% liczbą znaków alfabetycznych, (2) z wyjątkiem języka XSLT, odrzuć pliki, w których ciąg znaków „<?xml version=” pojawia się w pierwszych 100 znakach, (3) dla plików HTML zachowaj tylko te, w których widoczny tekst stanowi co najmniej 20% kodu HTML i ma minimalną długość 100 znaków, (4) dla plików JSON i YAML zachowaj tylko te pliki, które mają liczbę znaków w zakresie od 50 do 5000 znaków. Filtrujemy również zgłoszenia GitHub za pomocą zestawu metryk jakości, które obejmują usuwanie automatycznie generowanego tekstu, filtrowanie zgłoszeń nieanglojęzycznych, wykluczanie komentarzy od botów i wykorzystanie liczby użytkowników zaangażowanych w konwersację jako wskaźnika jakości. Każdy plik kodu opatrujemy również informacjami o licencji powiązanymi z odpowiednim repozytorium, znalezionymi za pomocą interfejsów API GitHub i zachowujemy tylko pliki z permistywnymi licencjami do treningu modelu. 2 3 Li i in. 2023a Li i in. 2023a 2.2 Dokładna i przybliżona deduplikacja Przyjmujemy agresywną strategię deduplikacji, obejmującą zarówno dokładną, jak i przybliżoną deduplikację, w celu usunięcia dokumentów o (prawie) identycznej zawartości kodu z naszego zestawu treningowego. W przypadku dokładnej deduplikacji najpierw obliczamy skrót SHA256 na zawartości dokumentu i usuwamy rekordy o identycznych skrótach. Po dokładnej deduplikacji stosujemy przybliżoną deduplikację w celu usunięcia plików kodu, które mogą mieć drobne wariacje, a tym samym dalszego odchylenia danych. Stosujemy w tym celu dwuetapową metodę: (1) obliczamy MinHashes wszystkich dokumentów, a następnie wykorzystujemy Locally Sensitive Hashing (LSH) do grupowania dokumentów na podstawie ich odcisków palców MinHash, (2) mierzymy podobieństwo Jaccarda między każdą parą dokumentów w tym samym wiadrze i oznaczamy dokumenty, z wyjątkiem jednego, jako duplikaty na podstawie progu podobieństwa 0,7. Stosujemy ten proces niemal-deduplikacji do wszystkich języków programowania, w tym zgłoszeń GitHub, aby zwiększyć bogactwo i różnorodność zestawu danych treningowych. 2.3 Filtrowanie HAP, PII, złośliwego oprogramowania Aby zmniejszyć prawdopodobieństwo generowania przez modele nienawistnego, obraźliwego lub wulgarnego języka (HAP), dokładamy wszelkich starań, aby filtrować treści HAP z zestawu treningowego. Najpierw tworzymy słownik słów kluczowych HAP, a następnie przypisujemy każdemu dokumentowi kodu liczbę wystąpień takich słów kluczowych w zawartości, w tym w komentarzach. Filtrujemy dokumenty, które przekraczają próg HAP, obliczony na podstawie analizy dystrybucyjnej oraz manualnej inspekcji plików kodu. Ponadto, aby chronić prywatność, postępujemy zgodnie ze StarCoder ( , ) i dokładamy wszelkich starań, aby zredagować informacje umożliwiające identyfikację osób (PII) z zestawu treningowego. Konkretnie, wykorzystujemy model StarPII do wykrywania adresów IP, kluczy, adresów e-mail, nazwisk, nazw użytkowników i haseł znalezionych w zawartości. Krok redagowania PII zastępuje tekst PII odpowiednimi tokenami NAME , EMAIL , KEY , PASSWORD i zmienia adres IP na syntetycznie wygenerowany adres IP, jak u Li et al. (2023a). Skanujemy również nasze zbiory danych za pomocą narzędzia, aby zidentyfikować i usunąć przykłady złośliwego oprogramowania w kodzie źródłowym. Li i in. 2023a 4 2.4 Zbiory danych w języku naturalnym Oprócz zbierania danych kodowych do treningu modeli, tworzymy kilka publicznie dostępnych, wysokiej jakości zbiorów danych w języku naturalnym w celu poprawy biegłości modelu w rozumieniu języka i rozumowaniu matematycznym. Reprezentatywne zbiory danych w tej kategorii obejmują dokumenty internetowe (Stackexchange, CommonCrawl), teksty matematyczne z sieci (OpenWeb-Math; (2023), StackMathQA; (2024)), teksty akademickie (Arxiv, Wikipedia) i zbiory danych do dostrajania instrukcji (FLAN; (2023), HelpSteer ( , 2023)). Nie deduplikujemy tych już wstępnie przetworzonych zbiorów danych w języku naturalnym. Paster i in. Zhang Longpre i in. Wang i in. 3 Architektura modelu Trenujemy serię modeli kodowych o różnej wielkości w oparciu o architekturę dekodera transformera ( , 2017). Hiperparametry modelu dla tych modeli podano w Tabeli 1. Dla wszystkich architektur modeli używamy pre-normalizacji ( , 2020): normalizacja stosowana do wejścia bloków uwagi i MLP. Vaswani i in. Xiong i in. : Najmniejszy model w rodzinie modeli Granite-code jest trenowany z osadzeniem RoPE ( , 2023) i Multi-Head Attention ( , 2017). Ten model wykorzystuje funkcję aktywacji swish ( , 2017) z GLU ( , 2020) dla MLP, powszechnie określanej również jako swiglu. Do normalizacji używamy RMSNorm ( , 2019), ponieważ jest ona bardziej wydajna obliczeniowo niż LayerNorm ( , 2016). Model 3B jest trenowany z długością kontekstu 2048 tokenów. 3B Su i in. Vaswani i in. Ramachandran i in. Shazeer Zhang & Sennrich Ba i in. : Model 8B ma podobną architekturę jak model 3B, z wyjątkiem użycia Grouped-Query Attention (GQA) ( , 2023). Użycie GQA zapewnia lepszy kompromis między wydajnością modelu a efektywnością wnioskowania w tej skali. Trenujemy model 8B z długością kontekstu 4096 tokenów. 8B Ainslie i in. : Model kodu 20B jest trenowany z nauczonymi bezwzględnymi osadzeniami pozycji. Używamy Multi-Query Attention ( , 2019) podczas treningu w celu efektywnego wnioskowania w dalszych etapach. Dla bloku MLP używamy funkcji aktywacji GELU ( , 2023). Do normalizacji aktywacji używamy LayerNorm ( , 2016). Ten model jest trenowany z długością kontekstu 8192 tokenów. 20B Shazeer Hendrycks & Gimpel Ba i in. : Aby wytrenować model 34B, podążamy za podejściem w zakresie zwiększania głębokości modelu 20B. Konkretnie, najpierw duplikujemy model kodu 20B z 52 warstwami, a następnie usuwamy 8 ostatnich warstw z oryginalnego modelu i 8 pierwszych warstw z jego duplikatu, tworząc dwa modele. 34B Kim i in. Na koniec łączymy oba modele, tworząc model Granite-34B-Code z 88 warstwami (patrz rysunek 2 dla ilustracji). Po zwiększeniu głębokości obserwujemy, że spadek wydajności w porównaniu do modelu 20B jest niewielki, w przeciwieństwie do tego, co zaobserwowali . Wydajność ta jest szybko odzyskiwana po kontynuacji przedtreningu powiększonego modelu 34B. Podobnie jak w przypadku modelu 20B, używamy kontekstu 8192 tokenów podczas przedtreningu. Kim i in. 4 Przedtrenowanie W tej sekcji przedstawiamy szczegóły dotyczące dwuetapowego treningu (Sekcja 4.1), celów treningowych (Sekcja 4.2), optymalizacji (Sekcja 4.3) i infrastruktury (Sekcja 4.4) użytych do przedtrenowania modeli. 4.1 Dwuetapowy trening Modele Granite Code są trenowane na 3,5T do 4,5T tokenów danych kodu i zbiorów danych języka naturalnego związanych z kodem. Dane są tokenizowane za pomocą byte pair encoding (BPE, ( , 2015)), używając tego samego tokenizera co StarCoder ( , 2023a). Zgodnie z ( , 2024; , 2024), wykorzystujemy wysokiej jakości dane w dwóch fazach treningu, w następujący sposób. Sennrich i in. Li i in. Shen i in. Hu i in. • : Podczas fazy 1, zarówno modele 3B, jak i 8B są trenowane na 4 bilionach tokenów danych kodu obejmujących 116 języków. Model 20B parametrów jest trenowany na 3 bilionach tokenów kodu. Model 34B jest trenowany na 1,4T tokenów po zwiększeniu głębokości, które jest przeprowadzane na punkcie kontrolnym 1,6T modelu 20B. Faza 1 (trening tylko kodu) • : W fazie 2 dodajemy wysokiej jakości, publicznie dostępne dane z różnych domen, w tym dokumenty techniczne, matematyczne i internetowe, aby jeszcze bardziej poprawić wydajność modelu w zakresie rozumowania i rozwiązywania problemów, które są niezbędne do generowania kodu. Trenujemy wszystkie nasze modele na 500B tokenów (80% kodu i 20% danych językowych) w fazie 2 treningu. Faza 2 (trening kodu + języka) 4.2 Cel treningowy Do trenowania wszystkich naszych modeli używamy celu kauzalnego modelowania językowego oraz celu Fill-In-the-Middle (FIM) ( , 2022). Cel FIM polega na przewidywaniu wstawionych tokenów przy danym kontekście i tekście następującym. Trenujemy nasze modele do pracy zarówno w trybach PSM (Prefiks-Sufiks-Środek), jak i SPM (Sufiks-Prefiks-Środek), z odpowiednimi tokenami kontroli formatowania, tak jak w StarCoder ( , 2023a). Bavarian i in. Li i in. Ogólna strata jest obliczana jako ważona kombinacja 2 celów: Empirycznie ustawiamy = 0,5 podczas treningu i stwierdzamy, że działa to dobrze w praktyce, prowadząc do SOTA wydajności zarówno w zadaniach uzupełniania kodu, jak i wypełniania kodu. Należy zauważyć, że cel FIM jest używany tylko podczas przedtrenowania, jednak usuwamy go podczas dostrajania instrukcji, tj. ustawiamy = 1. α α 4.3 Optymalizacja Używamy optymalizatora AdamW ([Kingma & Ba](#_bookmark80), [2017](#_bookmark80)) z β1 = 0,9, β2 = 0,95 i wagą rozpadu 0,1 do trenowania wszystkich naszych modeli kodowych Granite. Do przedtrenowania fazy 1, współczynnik uczenia podąża za harmonogramem kosinusowym, zaczynając od 3 10 , który spada do 3 10 z początkowym krokiem rozgrzewki liniowej wynoszącym 2 tys. iteracji. Do przedtrenowania fazy 2, zaczynamy od 3 10 (1,5 10 dla modeli 20B i 34B) i stosujemy harmonogram wykładniczego rozpadu, aby obniżyć go do 10% początkowego współczynnika uczenia. Używamy rozmiaru wsadu 4M-5M tokenów, w zależności od rozmiaru modelu, podczas obu faz przedtrenowania. −4 −5 −4 −4 Aby przyspieszyć trening, używamy FlashAttention 2 ( , 2022; , 2023), persistent layernorm kernel, Fused RMSNorm kernel (w zależności od modelu) i Fused Adam kernel dostępnych w . Używamy niestandardowego forka NVIDIA Megatron-LM ( , 2019; , 2021) do rozproszonego treningu wszystkich naszych modeli. Trenujemy z mieszanką 3D paralelizmu: tensorowego, potokowego i danych. Używamy również sekwencyjnego paralelizmu ( Dao i in. Dao bibliotece NVIDIA Apex Shoeybi i in. Narayanan i in.
