Trening na GPU w chmurze: jak dobrać instancję i nie przepalić budżetu

Po co w ogóle GPU w chmurze i kiedy ma to sens

Kiedy GPU faktycznie przyspiesza trening modeli

GPU w chmurze najbardziej opłaca się wszędzie tam, gdzie trening modeli jest intensywnie równoległy i da się go podzielić na tysiące małych operacji wykonywanych jednocześnie. Typowo chodzi o deep learning i modele z dużą liczbą parametrów. W praktyce największy zysk z trenowania modeli na GPU w chmurze pojawia się przy:

• Transformersach – NLP, generowanie tekstu, tłumaczenia, klasyfikacja sekwencji.
• Modelach wizji komputerowej – CNN do klasyfikacji obrazów, detekcja obiektów, segmentacja.
• Modelach sekwencyjnych – LSTM/GRU w zastosowaniach time-series czy przetwarzania języka, jeśli są odpowiednio duże.
• Dużych batch size’ach – im większa paczka danych na raz, tym bardziej GPU wykorzystuje swoją równoległość.

Jeśli jedna epoka treningu na CPU trwa kilka godzin, na GPU może zejść do kilkunastu minut. Różnica przy 50–100 epokach jest dramatyczna – to nie jest przyspieszenie o 10–20%, tylko często rzędu kilkunastu–kilkudziesięciu razy. Przy projekcie biznesowym oznacza to, że eksperymenty mieszczą się w czasie sprintu, a nie rozciągają na miesiąc.

GPU w chmurze ma sens także wtedy, gdy model musi być trenowany cyklicznie, ale nie non-stop. Na przykład rekomendacje odświeżane raz na dobę, system scoringowy trenowany raz na tydzień czy rekalkulacja embeddingów raz na kilka godzin. W takich scenariuszach zapłacenie za kilka godzin mocnej instancji GPU jest znacznie tańsze niż utrzymywanie zbliżonej mocy lokalnie przez cały czas.

Sytuacje, w których wystarczy CPU lub lokalna maszyna

GPU nie jest magicznym młotkiem, który przyspiesza wszystko. W wielu projektach bardziej opłaca się zostać przy CPU niż płacić za trening na GPU w chmurze. Szczególnie przy:

• Prostych modelach klasycznych – regresja liniowa, drzewka, lasy losowe, gradient boosting (XGBoost/LightGBM) na średnich zbiorach danych często lepiej skaluje się na CPU.
• Małych zbiorach danych – gdy dane spokojnie mieszczą się w pamięci RAM, a trening trwa kilkanaście minut na laptopie, chmura z GPU jest przerostem formy nad treścią.
• Prototypowaniu architektury – jeśli dopiero szkicujesz model na małym podzborze danych, CPU (albo jedna, nawet starsza karta lokalna) bywa wystarczająca.
• Eksperymentach z feature engineeringiem – większość obróbki tabelarycznej dobrze działa na CPU (Pandas, Spark), GPU niewiele tu zmieni.

Jeżeli całe zadanie treningowe trwa krócej niż godzina na lokalnym sprzęcie i nie powtarzasz go kilkadziesiąt razy dziennie, inwestowanie w chmurową instancję GPU często nie ma sensu ekonomicznego. Zamiast tego warto dopracować kod, zmniejszyć zbiór do sanity-checków i zostawić moc GPU na etap „pełnego treningu”.

Własna karta GPU vs chmura – koszt posiadania i elastyczność

Zakup własnej karty GPU (np. klasy konsumenckiej) na pierwszy rzut oka wydaje się tańszy. Płacisz raz, masz sprzęt na lata. Problem w tym, że całkowity koszt posiadania to nie tylko cena karty:

• komputer z odpowiednim zasilaczem i chłodzeniem,
• prąd i potencjalne ograniczenia termiczne,
• utrzymanie środowiska (sterowniki, biblioteki CUDA, awarie),
• ryzyko, że karta szybko się zestarzeje i będzie zbyt słaba do kolejnych modeli.

Chmura pozwala „wynajmować” różne karty GPU wtedy, kiedy są potrzebne. Daje to elastyczność:

• Skalujesz moc do etapu projektu – słaby T4 na początek, mocniejsza A100 na intensywny tydzień treningu.
• Nie płacisz, gdy nie trenujesz – instancja wyłączona nie generuje kosztów GPU (płacisz ewentualnie za storage).
• Możesz testować nowe generacje GPU bez wymiany sprzętu w biurze.

W praktyce lokalna karta opłaca się, gdy codziennie intensywnie trenujesz modele i masz wystarczająco przewidywalne potrzeby. Przy nieregularnych projektach, PoC, hackathonach czy okresowych retrainingach, chmura zdejmuje ryzyko „kup i żałuj” oraz daje dostęp do klas GPU, których kupno byłoby poza zasięgiem budżetowym.

Typowe scenariusze, w których chmurowe GPU dobrze się bilansuje

W praktyce trening modeli na GPU w chmurze sprawdza się szczególnie w kilku profilach projektów:

• Okresowe treningi modeli produkcyjnych – np. retraining modelu raz dziennie / tydzień, po kilkadziesiąt minut–parę godzin.
• Eksperymenty i R&D – kilkudniowe/miesięczne serie eksperymentów, gdzie trzeba szybko przewinąć dziesiątki konfiguracji.
• Hackathony i PoC dla klienta – potrzeba dużej mocy na krótko, bez inwestycji w infrastrukturę.
• Indywidualne projekty hobbystyczne – trenowanie własnego modelu Stable Diffusion, małego LLM czy klasyfikatorów obrazów/fotografii.

W takich scenariuszach koszt godzinowy GPU jest zazwyczaj mniejszy niż koszt zakupu i utrzymania sprzętu o podobnej mocy. Szczególnie, gdy dba się o to, by instancje nie działały bez sensu, a storage i transfer danych są rozsądnie zoptymalizowane.

Jak oszacować potrzeby sprzętowe zanim wybierzesz instancję

Kluczowe pytania przed wyborem GPU

Zanim zaczniesz wybierać konkretną instancję GPU, dobrze jest doprecyzować kilka parametrów projektu. Prosta checklista pomaga uniknąć szukania „na czuja”:

• Typ modelu: CNN, LSTM, transformer, model tablicowy (MLP) czy mieszany?
• Rozmiar danych: liczba próbek, rozmiar pojedynczego przykładu (obraz 224×224 vs 1024×1024, długość sekwencji, liczba cech).
• Docelowy czas treningu: ile realnie możesz czekać na pełny eksperyment – godziny, dni, tygodnie?
• Budżet miesięczny: maksymalna kwota do wydania na trening oraz eksperymenty.
• Poziom niepewności: czy architektura jest już dość ustalona, czy dopiero szukasz kierunku?

Im większy budżet i krótszy deadline, tym bardziej agresywnie możesz iść w mocniejsze GPU. Jeżeli budżet jest sztywny, a deadline ruchomy, opłaci się trenować na tańszych jednostkach, nawet kosztem dłuższego czasu na każdą epokę.

Reguły kciuka: gdzie wąskie gardło – GPU, CPU, RAM czy I/O

Żeby trening na GPU w chmurze miał sens, GPU musi być faktycznie wykorzystywane. Jeśli GPU się nudzi, przepalasz budżet. Proste sygnały, gdzie bywa wąskie gardło:

• GPU ~100% użycia, CPU umiarkowanie (30–70%) – optymalny scenariusz, GPU jest głównym pracusiem.
• GPU poniżej 30–40%, CPU wysoko (80–100%) – preprocessing danych i augmentacja dławią CPU, GPU czeka na batch.
• GPU nisko, dysk lub sieć wysoko – I/O jest problemem (powolny storage, odczyt z sieci, małe pliki).
• Wycieki pamięci i OOM – brakuje RAM albo VRAM, batch size jest za duży, model nie mieści się w GPU.

Przy modelach wizji zwykle GPU i dysk są istotne (dużo plików, duża przepustowość), przy NLP (transformery) krytyczna jest ilość VRAM. Przy klasycznych modelach (XGBoost na dużych tabelach) kluczowy jest RAM i CPU, a GPU często można pominąć.

Jak liczyć wymaganą pamięć GPU – prosty schemat

Pamięć GPU (VRAM) to jeden z najczęstszych ograniczników. Za mało VRAM oznacza:

• konieczność zmniejszania batch size,
• rezygnację z większych modeli,
• częstsze przełączanie danych między CPU a GPU (spowolnienie).

Przybliżony wzór na zapotrzebowanie VRAM można rozbić na składniki:

• Parametry modelu – każdy parametr to zwykle 4 bajty (float32) lub 2 bajty (float16/bfloat16).
• Gradienty i optymalizator – zazwyczaj wielokrotność parametrów (2–3× ich rozmiaru).
• Aktywacje i batch – zależne od batch size i głębokości sieci, potrafią być większe niż same parametry.
• Overhead frameworka – cache, buforowanie, wewnętrzne struktury (kilkaset MB–kilka GB).

Przykładowo prosty ResNet z kilkunastoma milionami parametrów przy obrazach 224×224 i rozsądnym batch size (np. 32) może zmieścić się w 8–12 GB VRAM. Mały transformer (np. 100–200M parametrów) przy sekwencjach 128–256 tokenów też zazwyczaj wejdzie w 8–16 GB VRAM, szczególnie przy mixed precision. Przy większych modelach (kilkaset milionów parametrów i więcej) bezpieczniej jest mieć 16–24 GB VRAM albo stosować techniki typu gradient checkpointing.

Dłużej na słabszym GPU, czy krótko na mocniejszym – profil projektu

Wybór między słabszym a mocniejszym GPU to najczęściej kompromis między czasem a kosztem jednostkowym. Scenariusze:

• Masz sztywny deadline (np. demo dla klienta) – opłaca się wziąć mocniejszą instancję, skrócić eksperymenty i zdążyć. Nawet jeśli koszt za godzinę jest dużo wyższy, całkowity czas (i koszt) może wyjść podobny lub niższy.
• Masz sztywny budżet, ale elastyczny czas – sens ma tańsze GPU, mniejszy batch, więcej cierpliwości. Można też ograniczać się do mniejszej liczby pełnych eksperymentów.
• Eksperymenty są mocno iteracyjne – krótkie przebiegi, dużo wersji modelu – liczy się szybkość feedbacku, więc często lepiej zapłacić więcej za godzinę, aby dostać wynik w kilkanaście minut.

Przy małym projekcie hobbystycznym bywa rozsądniej trenować model na tańszym T4 czy odpowiedniku i zostawić go na noc niż kupować na chwilę topowego A100. Przy projekcie komercyjnym, gdzie każda doba opóźnienia ma swoją cenę, inwestycja w mocniejsze GPU często zwraca się z nawiązką.

Mini-szablon do opisania wymagań sprzętowych

Zwięzły opis wymagań ułatwia wybór instancji oraz porównanie ofert różnych dostawców. Można używać prostego szablonu:

• Model: typ architektury (np. ResNet50, mały transformer 200M parametrów, LSTM 3 warstwy).
• Dane: liczba próbek, rozmiar przykładu (np. 100k obrazów 224×224, 1M sekwencji do 128 tokenów).
• Deadline: ile czasu można poświęcić na jeden pełny eksperyment i na całą serię eksperymentów.
• Maksymalny koszt: budżet na trening w danym okresie (np. 500 zł na miesiąc, 1000 zł na serię PoC).
• Tryb pracy: pojedyncze długie treningi vs wiele krótkich iteracji.

Taki opis można potem zderzyć z ofertą GPU w AWS, GCP, Azure czy mniejszych dostawców, dobierając instancje, które mieszczą się w budżecie i czasie, zamiast startować „na oko” od najmocniejszego sprzętu.

Przegląd typów instancji GPU w popularnych chmurach (AWS, GCP, Azure)

Rodziny GPU: „konsumenckie” vs „data center”

W dużym uproszczeniu chmury oferują dwie klasy GPU:

• GPU „ekonomiczne” / uniwersalne – np. NVIDIA T4, L4, A10. Dobre do typowych zadań treningowych, inference, mniejszych transformerów. Często mają mniej VRAM i niższą przepustowość, ale są wyraźnie tańsze.
• GPU „enterprise” / data center – V100, A100, H100 i podobne. Bardzo wysoka wydajność, dużo pamięci (40–80 GB), ogromna przepustowość. Świetne do bardzo dużych modeli, multi-GPU, distributed training – i odpowiednio drogie.

Do większości praktycznych zastosowań – zwłaszcza na początku – instancje oparte na T4, L4, A10 w zupełności wystarczają. Wchodzenie od razu w A100 ma sens głównie przy dużych projektach i bardzo ciężkich modelach, gdzie w grę wchodzą setki milionów–miliardy parametrów, długie sekwencje i rozbudowany trening wielowęzłowy.

Przykładowe rodziny instancji w AWS

AWS ma kilka generacji instancji GPU. Różnią się nie tylko mocą, ale też opłacalnością do konkretnych zadań.

• g4/g5 (T4, A10G) – uniwersalne i względnie tanie. Dobre do klasycznych modeli wizji, NLP średniej wielkości, serwowania modeli. g4dn (T4) to rozsądny punkt startowy dla wielu PoC.
• p3 (V100) – starsza generacja „enterprise”, ciągle mocna. Sprawdza się przy cięższych treningach, ale często przegrywa opłacalnością z nowszymi seriami lub tańszymi GPU dla średnich modeli.
• p4/p5 (A100/H100) – topowe instancje pod duże LLM, multi-GPU, training na naprawdę poważną skalę. Stawka godzinowa potrafi zjeść mały budżet badawczy w kilka dni, więc sens przy ograniczonych środkach tylko wtedy, gdy inaczej model się nie zmieści lub czas jest krytyczny.

Przy AWS kluczowy jest dobór nie tylko samego GPU, ale też ilości vCPU i RAM. Zbyt mało CPU potrafi wysycić się na data loaderach, a wtedy drogi A10 czy V100 czeka bezczynnie.

Przykładowe rodziny instancji w GCP

Google Cloud tradycyjnie mocno promuje własne TPU, ale klasyczne GPU też są łatwo dostępne:

• T4 (np. n1-standard-XX + T4) – dobre rozwiązanie na „pierwszy GPU w chmurze”. Wystarczające do większości projektów akademickich i hobbystycznych, często dostępne w wersjach preemptible w bardzo niskiej cenie.
• L4 – nowsza generacja, w wielu zastosowaniach korzystniejsza wydajnościowo niż T4 przy ciągle rozsądnym koszcie. Dobry kompromis dla mniejszych LLM-ów i modeli wizji 4K.
• A100 – dostępne głównie w konfiguracjach z dużą ilością RAM i CPU. Sens przy większych modelach lub kiedy istotna jest przepustowość NVLink i duży VRAM.

Ogromną przewagą GCP bywa elastyczność w doborze custom machine type – można przyciąć liczbę vCPU lub RAM tak, żeby nie płacić za „powietrze”. Do mniejszych modeli często wystarczy jeden T4 z 4–8 vCPU i 16–32 GB RAM.

Przykładowe rodziny instancji w Azure

Azure ma dość szerokie portfolio serii N, ale pod trening opłacają się zwykle wybrane warianty:

• NCas_T4_v3 – odpowiednik instancji z T4, sensowny do startu, PoC, średnich treningów.
• NC A100 v4 – instancje z A100, podobnie jak w AWS/GCP – dopiero wtedy, gdy VRAM i przepustowość stają się barierą.
• NV-serie – częściej używane do renderingu i desktopów w chmurze, do treningu modelu zwykle mniej opłacalne niż T4/L4/A10.

W Azure często pojawiają się regionalne różnice w dostępności i cenach. Zdarza się, że przeskok do innego regionu o kilkanaście milisekund większego opóźnienia sieci daje zauważalnie niższe stawki GPU.

Dodatkowe koszty wokół instancji GPU

Samą ceną za godzinę instancji łatwo się zasugerować, ale w rozliczeniu miesięcznym potrafią przeważyć koszty poboczne:

• Storage – dyski SSD (EBS/Persistent Disk/Managed Disk) i bucket’y (S3/GCS/Blob). Trzymanie terabajtów danych przez kilka miesięcy bywa droższe niż sam weekendowy trening.
• Transfer danych – wyciąganie modeli i danych poza chmurę (egress) potrafi kosztować więcej niż same godziny GPU przy dużych wolumenach.
• Usługi pomocnicze – managed Kubernetes, load balancery, logowanie. Przy czysto treningowych zadaniach często można je zastąpić prostszą orkiestracją i oszczędzić stałe koszty.

Dla budżetu liczy się więc nie tylko jaką instancję wybierasz, ale też jak długo trzymasz dane, jak często je kopiujesz oraz czy uruchamiasz do tego ciężkie usługi pomocnicze.

Jak dobrać instancję GPU do etapu projektu (R&D, eksperymenty, produkcja)

Faza eksploracji i prototypowania

Na starcie projektu najważniejsze jest szybkie sprawdzenie, czy pomysł w ogóle działa. W tym etapie nie ma sensu inwestować w najdroższe GPU:

• Modele zwykle są mniejsze lub działają na przyciętym zbiorze danych.
• Częściej restartujesz trening niż go kończysz.
• Zmieniasz kod, więc sporo czasu pochłania debugowanie, a nie pełne epoki.

Tu wystarcza pojedyncze T4/L4/A10 z niedużym CPU i RAM. Celem jest krótki czas iteracji przy niskim koszcie: lepiej mieć kilka tanich instancji na różne eksperymenty niż jedną drogą, która i tak się nudzi.

R&D na poważnie – tuning i większe zbiory

Gdy architektura jest już mniej więcej ustalona, wchodzą dłuższe treningi i grid/random search hiperparametrów. W tym momencie zmieniają się priorytety:

• liczy się przepustowość eksperymentów – ile konfiguracji uda się odpalić w jednostce czasu,
• pojawia się potrzeba automatyzacji (scheduler, kolejki, repozytorium wyników),
• zaczynasz pilnować kosztu całej kampanii, a nie pojedynczego runu.

Dobrym podejściem jest zestaw kilku tańszych instancji (np. kilka T4/L4), zamiast jednej potężnej. Można wtedy 🙂 równoleglić eksperymenty, co często daje lepszy „efekt za złotówkę”. A100 czy H100 mają sens wtedy, gdy:

• model fizycznie nie mieści się na słabszym GPU,
• potrzebujesz długich sekwencji (NLP) lub obrazów bardzo wysokiej rozdzielczości,
• deadline wymusza skrócenie pojedynczego treningu do minimum.

Środowisko produkcyjne – inference vs trening ciągły

W produkcji GPU może służyć do dwóch odmiennych zadań:

• Inference on-line – obsługa requestów w czasie rzeczywistym,
• Trening okresowy – np. retraining co tydzień z nowymi danymi.

Do inference w 8 na 10 przypadków wystarczy mniejsze GPU (T4/L4) lub nawet CPU, jeśli model jest mały i dobrze zoptymalizowany. Dobrą praktyką jest:

• ustawienie autoscalingu na podstawie latency/QPS,
• korzystanie z mniejszych, ale liczniejszych instancji – lepsza odporność na awarie i łatwiejsze skalowanie,
• trzymanie „gorących” modeli w pamięci, aby uniknąć wolnych ładowań.

Trening produkcyjny (np. cotygodniowe batch jobs) można wykonywać na innych, bardziej „mięsistych” instancjach, często w trybie spot/preemptible, bo przerwanie joba zwykle nie jest tragedią – da się go wznowić.

Różne instancje na kolejne fazy – przykład prostego workflow

Praktyczny, tani schemat dla zespołu z ograniczonym budżetem może wyglądać tak:

1. Eksploracja architektury – pojedynczy T4 w tanim regionie, mały dataset, krótkie epoki.
2. R&D i tuning – 2–4 instancje T4/L4 na spot/preemptible, równoległe eksperymenty, logi w jednym miejscu (MLflow, Weights&Biases, prosty S3).
3. Trening końcowy – jedna mocniejsza instancja (A10/A100) na pełnych danych, najlepiej z checkpointami i monitoringiem.
4. Inference – małe GPU (T4) lub zoptymalizowany model na CPU w autoscalingu.

Dzięki takiemu podziałowi najmocniejsze i najdroższe GPU są używane krótko i tylko tam, gdzie naprawdę robią różnicę.

Liczenie realnego kosztu treningu – od ceny za godzinę do pełnego eksperymentu

Rozbicie kosztu pojedynczego treningu

Żeby porównać różne instancje, trzeba umieć policzyć koszt całego treningu, a nie tylko cenę za godzinę. W najprostszym ujęciu:

koszt_treningu ≈ (czas_treningu_w_godzinach × stawka_GPU)
               + koszt_storage
               + koszt_transferu
               + narzut_na_nadgodziny / idle

Przy małych projektach storage i transfer często są pomijalne, a największym „ukrytym” kosztem bywa po prostu GPU, które nie zostało wyłączone po treningu i doczłapało się przez weekend na idle.

Jak oszacować czas treningu przed startem

Szacowanie czasu pełnego runu da się zrobić empirycznie:

1. Uruchom trening na kilku procentach danych (np. 1–5%) z docelowym batch size.
2. Zobacz, ile trwa jedna epoka i czy GPU jest dobrze wykorzystane (monitoring nvidia-smi / profiler frameworka).
3. Przeskaluj liniowo do pełnego datasetu (to przybliżenie, ale na start wystarcza).

Przykład: 1 epoka na 5% danych trwa 3 minuty na T4. Pełne dane → 60 minut na epokę. Jeśli planujesz 20 epok, liczysz 20 godzin. Do tego warto dodać bufor (np. 20–30%) na restarty, logowanie, ewentualne zmiany hiperparametrów.

Porównywanie instancji – kiedy droższe wychodzi taniej

Zestawienie dwóch instancji pokazuje, że sama cena za godzinę nie mówi nic:

• Instancja A: 2 zł/h, epoka trwa 60 minut → koszt 2 zł za epokę.
• Instancja B: 5 zł/h, epoka trwa 15 minut → koszt 1,25 zł za epokę.

Druga opcja jest droższa „na godzinę”, ale tańsza na wynik. Przy treningach, które trwają wiele godzin, oszczędność czasu potrafi też obniżyć koszty pracy zespołu: mniej czekania, mniej frustracji, więcej iteracji w tym samym budżecie.

Wliczanie kosztów eksperymentów i dead-endów

Rzeczywisty koszt projektu to nie tylko finalny model, ale też wszystkie ślepe uliczki:

• nieudane konfiguracje hiperparametrów,
• bugi w kodzie, po których trzeba restartować run,
• eksperymenty, które trwają zbyt długo, choć już po paru epokach widać, że wynik jest słaby.

Rozsądna praktyka to wczesne zatrzymywanie („early stopping manualny”): jeśli po kilku epokach krzywa loss wygląda znacznie gorzej niż poprzednie próby, nie ma sensu dociągać 50 epok tylko „dla porządku”. To prosta oszczędność godzin GPU.

Planowanie budżetu na całą kampanię treningową

Zanim uruchomisz dziesiątki eksperymentów, warto policzyć sobie zgrubny budżet:

1. Oszacuj koszt jednego treningu (metoda z próbną epoką).
2. Określ, ile konfiguracji chcesz realnie przetestować (np. 20–30, nie „setki na ślepo”).
3. Dodaj 20–50% marginesu na nieprzewidziane zmiany (bugi, dodatkowe eksperymenty).

Jeśli wychodzi więcej niż dostępny budżet – trzeba ciąć:

• zmniejszyć liczbę epok,
• zmniejszyć dataset (np. subset danych na wstępny tuning),
• zejść na tańszą instancję i zaakceptować dłuższy czas,
• agresywniej korzystać z early stopping.

Tanie strategie: spot/preemptible, wynajmowanie GPU poza „wielką trójką”, współdzielenie

Instancje spot/preemptible – duża zniżka za ryzyko przerwania

Spot (AWS/Azure) i preemptible (GCP) to najprostszy sposób, żeby ciąć rachunki nawet o kilkadziesiąt procent. Mechanika jest prosta:

• płacisz znacznie mniej za godzinę,
• instancja może zostać przerwana z krótkim wyprzedzeniem (30–120 sekund),
• masz górny limit czasu działania (np. 24 h dla niektórych preemptible).

Do treningu nadają się świetnie, pod warunkiem że:

• robisz regularne checkpointy (co X minut/epokę),
• umiesz wznowić trening od checkpointu,
• nie robisz krytycznego demo na żywo w momencie, gdy instancja może zniknąć.

Przy długich treningach różnica w rachunku bywa dramatyczna. Jeśli eksperyment trwa 30 godzin, a płacisz o połowę mniej, realnie otrzymujesz dwa takie treningi w cenie jednego on-demand.

Małe chmury i wynajem bare-metal z GPU

Poza AWS/GCP/Azure działa sporo dostawców oferujących tanie GPU, często na kartach zbliżonych do „konsumenckich” (np. RTX 3090/4090). To dobre wyjście, jeśli: