7210 produktów, brak API i 72 mln znaków do przetłumaczenia - jak to zrobiłem nie podnosząc kosztów projektu?

Podczas realizacji projektu dla klientki stanęliśmy przed wyzwaniem importu 7210 produktów z dwóch hurtowni, które nie udostępniały żadnego API ani plików eksportowych.

Dopiero na etapie tworzenia sklepu internetowego okazało się, że zamiast standardowego wdrożenia e-commerce będziemy musieli zbudować własnego bota z własnym system tłumaczeń dla 72 milionów znaków oraz zoptymalizować całą infrastrukturę pod kątem kosztów i wydajności. 🚀

 

1️⃣ Punkt wyjścia – problem

Tworzyliśmy sklep internetowy dla klientki, która chciała sprzedawać produkty z dwóch hurtowni – bez ręcznego dodawania ich do systemu. Problem polegał na tym, że żadna z hurtowni nie udostępniała API, plików CSV ani feedów XML, co oznaczało konieczność zbudowania własnego mechanizmu pobierania danych.

W praktyce oznaczało to obsługę 7210 produktów, z rozbudowanymi opisami przekraczającymi średnio 2000 znaków każdy, oraz konieczność przetłumaczenia ich na 5 dodatkowych języków. Szybkie przeliczenie pokazało skalę wyzwania — ponad 72 miliony znaków do przetworzenia.

 

 

2️⃣ Etap 1 – Bot scrapingowy

Ponieważ hurtownie nie udostępniały żadnego API ani gotowych plików eksportowych, jedynym rozwiązaniem było stworzenie własnego mechanizmu pobierania danych bezpośrednio ze stron internetowych. Od początku wiedzieliśmy, że bez automatyzacji projekt ugrzęźnie na etapie ręcznego kopiowania treści.

Powstał więc dedykowany bot scrapingowy, który:

• skanował strukturę kategorii w obu hurtowniach

• automatycznie przechodził przez podkategorie i paginację

• pobierał pełne opisy produktów

• zapisywał wszystkie zdjęcia w odpowiednich rozdzielczościach

• normalizował dane (usuwanie zbędnego HTML, ujednolicanie formatów)

• przygotowywał strukturę pod bezpośredni import do sklepu

• automatycznie narzucał marżę dla rynków zagranicznych

Dzięki temu udało się w pełni zautomatyzować przetworzenie 7210 rekordów bez ręcznej ingerencji, tworząc pipeline, który można było ponownie uruchomić w przypadku aktualizacji oferty. 🤖🚀

 

3️⃣ Problem kosztowy – DeepL API

Na początku naturalnym wyborem wydawało się wykorzystanie gotowego API tłumaczeniowego, takiego jak DeepL. Model rozliczeń był prosty: 25 € za 1 000 000 znaków. Przy skali projektu wynoszącej 72,1 miliona znaków oznaczało to koszt około 1802,5 €, czyli w przybliżeniu 7570 zł.

I to wyłącznie za samo tłumaczenie treści produkcyjnych — bez uwzględnienia testów, ponownych przeliczeń, korekt opisów czy dodatkowych iteracji. Każda poprawka generowałaby kolejne koszty, a przy tej skali nawet drobne zmiany mogły znacząco zwiększyć budżet.

To był moment, w którym stało się jasne, że przy takiej liczbie produktów trzeba zmienić strategię i poszukać rozwiązania, które będzie skalowalne kosztowo, a nie uzależnione od opłat za każdy przetworzony znak. 🚀

 

4️⃣ LibreTranslate – self-hosted

W poszukiwaniu alternatywy trafiłem na LibreTranslate — rozwiązanie open-source, które udostępnia własne API i pozwala uruchomić cały mechanizm tłumaczeń lokalnie, bez opłat za każdy przetworzony znak. To oznaczało pełną kontrolę nad infrastrukturą, brak limitów oraz niezależność od zewnętrznych dostawców.

Pierwsza instalacja została wykonana na środowisku:

• Windows

• Docker

• Intel Core i7 4930K

• przetwarzanie wyłącznie na CPU

System działał stabilnie i spełniał swoje zadanie — wszystkie 7210 produktów zostały przetłumaczone bez ponoszenia kosztów API. Cel został osiągnięty: uniknęliśmy wydatku rzędu kilku tysięcy złotych i zyskaliśmy pełną kontrolę nad procesem.

Ale pojawił się nowy czynnik — czas. ⏳

Tłumaczenie jednego produktu zajmowało średnio 3–5 minut, co przy tej skali przełożyło się na około trzy tygodnie ciągłego przetwarzania. Rozwiązanie było ekonomicznie trafione, jednak infrastrukturalnie nadal dalekie od optymalnego.

 

5️⃣ Wydajność – Windows + CPU

Na etapie pierwszej konfiguracji LibreTranslate działał w pełni poprawnie, jednak wydajność była ściśle uzależniona od możliwości procesora. Tłumaczenie jednego produktu zajmowało średnio od 3 do 5 minut, dlatego do dalszych obliczeń przyjęliśmy uśrednione 4 minuty.

Przy 7210 produktach oznaczało to:

• 7210 × 4 min = 28 840 minut

• około 480 godzin pracy

• czyli blisko 20 dni ciągłego tłumaczenia bez przerw

W praktyce infrastruktura działała stabilnie i osiągnęliśmy założony cel biznesowy — wszystkie produkty zostały przetłumaczone bez kosztów API. Jednak architektura była liniowa: każde tłumaczenie wykonywane było sekwencyjnie, a CPU stało się naturalnym wąskim gardłem całego procesu. ⏳

 

 

6️⃣ Ubuntu + GPU – zmiana architektury

Doświadczenia z pierwszego projektu pokazały jedno: ekonomicznie rozwiązanie było trafione, ale infrastrukturalnie wymagało przemyślenia. Dlatego w kolejnych wdrożeniach architektura została przeprojektowana pod kątem wydajności i skalowalności.

Nowa konfiguracja opiera się na:

• Ubuntu

• LibreTranslate

• AMD Radeon RX 7900 XTX

• 24 GB VRAM

• batch processing

• przetwarzaniu równoległym

CPU zostało zamienione na GPU dzięki pakietowi sterowników AMD ROCm który umożliwia wykorzystanie kart graficznych Radeon i procesorów Ryzen AI do zadań AI, uczenia maszynowego i HPC.

 

Dlaczego różnica jest tak duża?

Windows + Docker

• większy narzut systemowy

• dodatkowa warstwa abstrakcji

• ograniczona optymalizacja pod ML

• brak wykorzystania akceleracji GPU

Ubuntu

• mniejszy overhead systemowy

• lepsze wsparcie dla środowisk ML

• bezpośredni dostęp do zasobów GPU

• stabilniejsze środowisko kontenerowe

• możliwość równoległego przetwarzania dużych batchy tekstu

W praktyce oznacza to przejście z modelu liniowego (produkt po produkcie) do modelu równoległego, gdzie wiele fragmentów tekstu przetwarzanych jest jednocześnie.

📊 Porównanie czasu

Konserwatywnie przyjmując około 2 dni intensywnej pracy GPU przy podobnej skali danych, różnica wygląda następująco:

 

 

7️⃣ Zużycie energii

Optymalizacja nie dotyczyła wyłącznie czasu przetwarzania. Równie istotnym czynnikiem była efektywność energetyczna całego procesu.

Windows + CPU

Średni pobór mocy zestawu podczas intensywnego tłumaczenia wynosił około 200W.
Przy czasie pracy rzędu 504 godzin (około 3 tygodnie ciągłego przetwarzania) daje to:

• ~100,8 kWh zużytej energii

• około 101 zł kosztu energii (przy założeniu ~1 zł/kWh)

Ubuntu + GPU

Nowa infrastruktura oparta o GPU pobierała więcej mocy chwilowo — około 450W — jednak czas pracy skrócił się do około 48 godzin intensywnego obciążenia.

• ~21,6 kWh zużytej energii

• około 22 zł kosztu energii

 

Choć GPU zużywa więcej mocy w danym momencie, kończy zadanie wielokrotnie szybciej. W efekcie całkowite zużycie energii spada niemal pięciokrotnie, co pokazuje, że wydajność infrastruktury przekłada się bezpośrednio nie tylko na czas, ale również na realne koszty operacyjne. ⚡🚀

 

8️⃣ A gdyby robić to ręcznie?

Dla pełnego obrazu warto zadać sobie jedno pytanie: co by było, gdyby wszystkie produkty zostały dodane ręcznie?

Załóżmy bardzo optymistyczny scenariusz — 10 minut na jeden produkt. W tym czasie należałoby:

• skopiować i sformatować opis

• pobrać oraz wgrać zdjęcia

• uzupełnić parametry

• przetłumaczyć treść

• przygotować wersje językowe

• ustawić SEO

Przy 7210 produktach oznacza to:

• 7210 × 10 minut = 1201 godzin pracy

• około 150 dni roboczych (przy 8h dziennie)

Przy stawce 50 zł za godzinę daje to koszt rzędu:

≈ 60 000 zł

 

W tym miejscu najlepiej widać realną skalę automatyzacji. To nie była optymalizacja kilku godzin pracy — to była redukcja miesięcy operacyjnego wysiłku i dziesiątek tysięcy złotych kosztów. 🚀

 

9️⃣ Finalny pipeline – architektura rozwiązania

Ostatecznie projekt nie zakończył się jedynie na przetłumaczeniu produktów. Powstał kompletny, zautomatyzowany pipeline przetwarzania danych, który można uruchamiać ponownie przy każdej aktualizacji oferty lub dodaniu nowej hurtowni.

Schemat działania wyglądał następująco:

Bot scrapingowy
→ czyszczenie i normalizacja danych
→ tłumaczenie batchowe
→ automatyczne narzucanie marży
→ import do sklepu

Każdy etap był częścią jednego spójnego procesu, a nie ręczną operacją wykonywaną oddzielnie. Dane były przetwarzane masowo, tłumaczone równolegle i przygotowywane bez potrzeby ingerencji człowieka.

W efekcie:

• brak kosztów zewnętrznego API

• brak pracy manualnej przy 7210 produktach

• pełna skalowalność przy kolejnych tysiącach rekordów

• infrastruktura gotowa na integrację z następnymi hurtowniami

Projekt przestał być „wdrożeniem sklepu”, a stał się systemem automatyzacji, który można rozwijać i skalować bez liniowego wzrostu kosztów. 🚀