FOTOhub kończy konsolidację na AWS i udostępnia klientom moc CPU oraz GPU w rozliczeniu godzinowym

Kategoria: Partnerstwo / Infrastruktura / Technologia

Data: 1 sierpnia 2026

Autor: FOTOhub Press Team, FOTOhub.app

Tagi: AWS, Amazon Web Services, infrastruktura chmurowa, GPU, multi region, storage obiektowy, trening AI dla marek, agenci, platforma dla developerów

Podsumowanie

FOTOhub zakończył strategiczną konsolidację całej platformy produkcyjnej na Amazon Web Services i należy do AWS Startup Portfolio Tier, z płatną umową AWS Business Support. Program, który zaczął się jako migracja infrastruktury, skończył się czymś znacznie ambitniejszym: to samo podłoże, na którym działa FOTOhub, jest dzisiaj osobnym produktem. Przez konsolę platformy firmy, profesjonaliści i indywidualni developerzy mogą wynajmować moc CPU i GPU w rozliczeniu godzinowym, zakładać własny storage obiektowy w wybranym regionie, orkiestrować trwałe wieloetapowe procesy agentowe, a w rozpoczynającym się właśnie wdrożeniu również trenować modele AI dedykowane własnej marce na własnym materiale. FOTOhub działa dziś w pięciu regionach AWS na trzech kontynentach, utrzymuje katalog ponad stu modeli AI produkcyjnie dostępnych z jednego salda kredytów i udostępnia cały ten obszar przez udokumentowane API REST, oficjalne SDK oraz warstwę narzędzi wywoływalnych maszynowo.

Dlaczego jedna chmura była jedyną sensowną odpowiedzią

Przez większość swojej historii FOTOhub działał na dwóch chmurach. To sytuacja typowa dla szybko rosnących firm AI i niemal zawsze wynika z historii, nie z projektu: moc bierze się tam, gdzie jest dostępna w momencie, w którym workload staje się pilny. Taki układ działa do skali, w której podwojenie wszystkiego staje się dominującym kosztem operacyjnym.

Dwie chmury oznaczały dwie umowy, dwa modele rozliczeń, których nie da się porównać pozycja do pozycji, dwa systemy tożsamości i uprawnień, dwa zestawy założeń sieciowych i dwie odpowiedzi na jedno pytanie, które zadaje każdy poważny klient korporacyjny przed podpisem: gdzie dokładnie leżą nasze dane. Żaden z tych punktów nie był katastrofą osobno. Razem stanowiły podatek nakładany na każdą decyzję inżynierską i hamulec w każdej rozmowie zakupowej.

Decyzja o konsolidacji na AWS nie była więc przede wszystkim decyzją o jakości technologii. Była decyzją o przejrzystości. Jedna chmura to jeden model kosztowy, który da się prognozować, jedna granica bezpieczeństwa, którą da się audytować, jeden zestaw gwarancji regionalnych, który da się wpisać do umowy, i jedna platforma, której usługi zarządzane zespół może przyjąć głęboko, zamiast używać ich na poziomie najmniejszego wspólnego mianownika dwóch dostawców.

Ten ostatni punkt okazał się najważniejszy. Kiedy platforma przestała się zabezpieczać na dwa fronty, budowanie wprost na warstwach zarządzanych AWS stało się racjonalne zamiast odtwarzania ich samemu. To właśnie różnica między hostowaniem w chmurze a integracją z nią i to ta różnica dała produkty opisane poniżej.

Etap pierwszy: konsolidacja i wyjście z drugiego środowiska

Migracja została celowo poprowadzona jako program etapowy, nie jako jednorazowe przełączenie, i nigdy nie była traktowana jak kopiowanie. Znacząca część usług została przepisana, nie przeniesiona, ponieważ przełożenie workloadu zaprojektowanego wokół prymitywów jednego dostawcy na prymitywy drugiego powtarza pierwotne kompromisy i nie przynosi żadnej z korzyści.

Prace szły usługa po usłudze, w kolejności zależności, a starsze środowisko pozostawało żywe za każdym przełączeniem, dopóki zamiennik nie obsłużył realnego ruchu produkcyjnego. Przetwarzanie mediów, kolejki generowania, rdzeń rozliczeń, uwierzytelnianie, storage i warstwa inferencji przechodziły każde w swoim tempie. Ostatni węzeł obliczeniowy opuścił poprzednie środowisko w drugiej połowie 2026 roku i wtedy druga chmura została wyłączona, a nie pozostawiona bezczynnie, co zamknęło zarówno koszt, jak i powierzchnię bezpieczeństwa równoległego środowiska.

Wniosek inżynierski z tego etapu jest nieefektowny i wart wypowiedzenia wprost, bo to część, którą większość komunikatów o migracji pomija: trudnością migracji chmurowej prawie nigdy nie jest moc obliczeniowa. Są nią model tożsamości, semantyka storage i nagromadzone założenia o opóźnieniach między komponentami, które pierwotnie stały obok siebie.

Etap drugi: obecność multi region i uczciwa rezydencja danych

Workloady produkcyjne FOTOhub działają dziś w pięciu regionach AWS na trzech kontynentach, z Unią Europejską jako domyślnym miejscem danych klientów i regionem podstawowym we Frankfurcie. Irlandia i Sztokholm niosą dodatkową moc europejską, natomiast regiony w Ameryce Północnej i Azji obsługują wrażliwą na opóźnienia inferencję oraz workloady brzegowe dla tych rynków bezpośrednio.

To część programu z najbardziej wyraźną konsekwencją handlową. Wybór regionu jest teraz jawną i umowną własnością workloadu klienta, nie szczegółem implementacyjnym. Europejskiemu sprzedawcy przetwarzającemu cały katalog produktowy można wskazać region, w którym leżą zdjęcia źródłowe, materiały pochodne i ślad audytowy. Studio obsługujące rynek japoński może mieć inferencję z regionu na tym samym kontynencie co jego odbiorcy, bez opłaty w postaci podróży przez Pacyfik przy każdym żądaniu.

Storage obiektowy idzie za tą samą zasadą. Buckety klientów powstają w nazwanym regionie, replikacja jest skonfigurowanym zachowaniem, a nie przypadkiem, a logowanie dostępów i ślady audytowe na poziomie konta zapisują się do dedykowanych miejsc od momentu, w którym bucket istnieje. Dystrybucja treści działa przez globalną sieć brzegową przed tym storage, więc bucket przypięty do regionu nie zamienia się w karę wydajnościową dla odbiorców na całym świecie.

FOTOhub otwarcie stawia jedno zastrzeżenie, bo alternatywą jest obietnica, której operacje nie utrzymają. Kiedy żądana klasa mocy jest faktycznie niedostępna w preferowanym regionie klienta, platforma pokaże ten stan, zamiast po cichu spełnić żądanie gdzie indziej, a workloady z twardymi wymogami rezydencji powinny być przypinane jawnie w momencie zakładania.

Etap trzeci: zarządzane serwowanie modeli jako warstwa pierwszej klasy

Po konsolidacji FOTOhub przyjął Amazon Bedrock jako podstawową warstwę zarządzanego serwowania obok własnej warstwy inferencji. Już w samym europejskim regionie podstawowym daje to dostęp do kilkudziesięciu modeli fundamentowych przez jeden nadzorowany interfejs, bez pracy wdrożeniowej na każdy model, bez osobnej umowy z każdym dostawcą i bez kolejnych sekretów do rozprowadzenia po usługach.

Praktyczny skutek dla katalogu produktowego jest taki, że szerokość oferty modeli nie jest już limitowana nakładem integracyjnym. FOTOhub utrzymuje dziś katalog stu sześćdziesięciu trzech modeli, z których ponad sto dziesięć jest włączonych produkcyjnie, obejmujących generowanie obrazu, wideo, tekst konwersacyjny, generowanie obiektów trójwymiarowych, transkrypcję i syntezę mowy. Każdy z nich rozlicza się z jednego salda kredytów niezależnie od tego, który dostawca lub która warstwa serwowania ostatecznie wykona żądanie, więc zmiana modelu przez klienta nie zmienia umowy, formatu faktury ani kodu integracji.

Obok warstwy zarządzanej FOTOhub prowadzi własną inferencję na dedykowanej mocy akcelerowanej dla własnej rodziny modeli IDA, gdzie kontrola nad stosem serwującym jest celem, a nie narzutem. Serwowanie zarządzane dla szerokości, serwowanie własne dla modeli, które są nasze: to konsolidacja sprawiła, że oba da się robić dobrze w rozsądnym budżecie.

Na tym samym koncie stoi też infrastruktura treningowa własnych modeli audio i głosu FOTOhub, z dedykowanymi zbiorami danych treningowych i zarządzanym oprzyrządowaniem uczenia maszynowego. Ta zdolność nie jest teoretyczna ani przyszła. Powstały na niej modele, które działają produkcyjnie dzisiaj, i jest ona bezpośrednim fundamentem technicznym wdrożenia treningu marek opisanego niżej.

Etap czwarty: otwarcie podłoża dla klientów

Najistotniejszym skutkiem migracji jest to, że FOTOhub nie traktuje już swojej warstwy obliczeniowej jako sprawy wewnętrznej. W konsoli platformy klienci mogą zakładać własną infrastrukturę i nią zarządzać bezpośrednio, w rozliczeniu godzinowym, w tej samej strukturze konta, na tej samej powierzchni rozliczeniowej i w tym samym modelu poświadczeń co reszta platformy.

Katalog do wynajęcia obejmuje dziś siedemnaście klas CPU i pięć klas GPU, od małych maszyn o zmiennej wydajności, odpowiednich dla skryptu uruchamianego z harmonogramu, po mocne maszyny wielordzeniowe i instancje akcelerowane w rozmiarze pod inferencję i dostrajanie modeli. Stawki są podawane za godzinę, bez opłaty za ruch wychodzący, moc można zamówić w cenie przerywalnej, o około sześćdziesiąt procent niżej niż na żądanie, dla workloadów znoszących odebranie zasobu, a instancja bezczynna jest zatrzymywana automatycznie, zamiast cicho generować koszt do momentu, w którym ktoś to zauważy.

Zakładanie, cykl życia, monitoring i likwidacja obsługiwane są z konsoli i z API, a rozmiar dysku, obraz systemu i konfiguracja startowa są zwykłymi parametrami. Storage obiektowy jest zarządzany z porównywalną głębokością: czternaście dedykowanych powierzchni administracyjnych obejmuje uprawnienia i polityki, klucze dostępu, przenoszenie między klasami storage w cyklu życia, replikację, punkty dostępu, powiadomienia o zdarzeniach, metryki, dystrybucję treści i serwowanie stron statycznych, a stoi za tym ponad osiemdziesiąt operacji API dotyczących samego storage. Storage wyceniany jest na podstawie cennika AWS, nie wymyślonej tabeli narzutów, i dostępne są zarówno klasy gorące, jak i rzadkiego dostępu.

To moment, w którym oferta FOTOhub zmienia kategorię. Klient nie musi już wybierać między korzystaniem z kreatywnej platformy AI a posiadaniem prawdziwej infrastruktury. Katalog generowania, silnik procesów, warstwa storage i wynajęta moc stoją za jednym logowaniem, jednym saldem i jednym API, a granica między nimi jest decyzją projektową, nie przeszkodą zakupową.

Trening modeli dla marek wchodzi we wdrożenie

System marek FOTOhub działa już dziś i jest mechanizmem, którym platforma produkuje materiały zgodne z marką w dużej skali. Marka w FOTOhub jest strukturą, nie notatką o stylu: dedykowane obszary danych trzymają zaakceptowane twarze, logotypy, typografię, produkty, materiały, presety stylu, pisane wytyczne i tablice nastrojów, z rolami współpracowników, kontrolą dostępu na poziomie wiersza i śladem audytowym na poziomie bazy przy każdej zmianie. Tę strukturę czytają wprost potoki generowania i wideo, dlatego spójność marki działa dziś bez żadnej personalizacji modelu.

Rozpoczynające się wdrożenie rozszerza to z generowania prowadzonego wytycznymi na prawdziwą adaptację modelu. Silnik treningowy oparty jest na uznanych technikach adaptacji efektywnej parametrowo w wielu modalnościach, z rozmiarem zbioru danych dobranym do realnych bibliotek marek, a nie benchmarków badawczych, z przerywalną mocą treningową i wznawianiem z punktów kontrolnych, tak aby długie zadanie przetrwało odebranie zasobu, z konfigurowalnymi okresami retencji i pełnym logowaniem audytowym każdego zadania. Wytrenowane adaptery mają być wybieralne w tych samych miejscach generowania, z których klienci już korzystają.

FOTOhub nazywa to wdrożeniem, nie ogólną premierą, i robi to celowo. Infrastruktura, schemat danych, kod treningowy i moc akcelerowana są na miejscu, a własne modele audio firmy powstały dokładnie na tym fundamencie. Trening marek dla klientów uruchamiany jest etapami, najpierw na kontach wczesnego dostępu, a ogólną dostępność FOTOhub ogłosi wtedy, gdy cała droga, łącznie z przyjmowaniem zbiorów danych i serwowaniem adapterów, zostanie potwierdzona na prawdziwych bibliotekach klientów, nie wewnętrznych. Ogłoszenie samej zdolności na etapie wdrożenia i daty dostępności osobno jest po prostu bardziej użyteczne dla zespołów, które planują wokół tego własne plany.

Trwała orkiestracja i warstwa agentowa

Czwartym filarem rozszerzonej oferty jest orkiestracja. FOTOhub prowadzi silnik procesów zbudowany na trwałym wykonaniu, a nie na skryptowaniu w trybie najlepszych starań, i to właśnie ta różnica decyduje o tym, czy automatyzacji można powierzyć produkcyjny katalog. Praca jest zapisywana w punktach kontrolnych, ponawiana według zdefiniowanych polityk, wznawialna po przerwaniu infrastruktury, wywoływalna z harmonogramu i zdolna zgłosić zakończenie uwierzytelnionym webhookiem.

Biblioteka węzłów dostępna temu silnikowi obejmuje dziś sto sześćdziesiąt typów węzłów w piętnastu kategoriach, z kilkudziesięcioma gotowymi szablonami typowych operacji kreatywnych i handlowych. Około dwie trzecie typów węzłów nie niesie dodatkowego kosztu generowania, ponieważ odpowiadają za przepływ sterowania, transformacje i obsługę danych, nie za inferencję. Reprezentatywny workload wygląda tak: obserwuj feed produktowy, wygeneruj zestaw packshotów i krótkie wideo na każdą nową pozycję, nałóż strukturę marki, zapisz wyniki do bucketu klienta w nazwanym regionie i zawołaj backend sklepu po zakończeniu partii, z każdym krokiem ponawialnym osobno.

FOTOhub przedstawia silnik i bibliotekę węzłów jako zdolność produkcyjną, a szerokość połączeń z kontami zewnętrznymi jako etapową. Dostępność konektorów włączana jest progresywnie, nie ogłaszana jako komplet, a firma woli wymienić konektor w dniu, w którym klient może się przez niego uwierzytelnić, niż w dniu, w którym węzeł pojawia się w bibliotece.

Co rozszerzona oferta znaczy dla każdej z grup

Dla firm propozycja brzmi tak: produkcja kreatywna w skali katalogu i infrastruktura, na której ona stoi, mogą teraz pochodzić od jednego dostawcy, na jednej umowie, ze wskazanym regionem dla każdego materiału i śladem audytowym, który istnieje domyślnie, a nie na życzenie. Zwykłym blokerem w projektach tej klasy jest złożoność zakupowa, nie jakość modeli, a konsolidacja jest tym, co ją usuwa.

Dla profesjonalistów i studiów wartością jest elastyczność bez narzutu operacyjnego. Kampania, która potrzebuje mocy akcelerowanej na cztery dni, nie wymaga zatrudnienia od infrastruktury, osobnego konta w chmurze ani zobowiązania miesięcznego. Wymaga instancji godzinowej, która zatrzymuje się razem z kampanią, stojącej obok katalogu modeli i systemu marki, z których studio korzysta codziennie.

Dla indywidualnych developerów FOTOhub świadomie ustawia się jako platforma do budowania, nie narzędzie do używania. Powierzchnia to dwieście sześćdziesiąt siedem udokumentowanych punktów końcowych REST w modułach platformy, oficjalne SDK dla Pythona i TypeScriptu opublikowane w publicznych repozytoriach paczek, klient wiersza poleceń oraz warstwa narzędzi wywoływalnych maszynowo, udostępniająca trzydzieści operacji platformy, tak aby asystent AI mógł sterować platformą bezpośrednio. Każda z tych dróg rozlicza się z tego samego salda i uwierzytelnia tym samym materiałem kluczowym co konsola, a plan darmowy ma prawo zakładać zasoby z tego samego katalogu infrastruktury co wszyscy pozostali.

Relacja z AWS

FOTOhub uczestniczy w AWS Startup Portfolio Tier i ma płatną umowę AWS Business Support. Umowa wsparcia to mniej efektowna połowa tego zdania i operacyjnie ważniejsza: oznacza zdefiniowane czasy odpowiedzi i dostęp do inżynierów AWS w czasie incydentu, na platformie, na której klienci przetwarzają całe katalogi produktowe i nie można im powiedzieć, żeby czekali na odpowiedź na forum. Firma na tym etapie wzrostu nie powinna mieć jednoosobowej funkcji wsparcia między terminem produkcyjnym klienta a dostawcą chmury.

Członkostwo w Portfolio Tier odzwierciedla relację techniczną, nie wyłącznie handlową, a konkretne warunki komercyjne tego układu nie są ujawniane. Ujawnialna i istotna dla klientów oceniających FOTOhub jest konsekwencja architektoniczna: platforma jest zbudowana na usługach zarządzanych dostawcy, a nie tylko hostowana na jego serwerach, a plan rozwoju układa się dziś względem krzywej możliwości jednego dostawcy, nie części wspólnej dwóch.

„Konsolidację na AWS ustawiliśmy wewnętrznie jako projekt kosztowy i porządkujący. Skończyła się jako strategia produktowa. Kiedy cała platforma stanęła na jednym podłożu, które rozumiemy od początku do końca, nie było już dobrego powodu, żeby to podłoże zatrzymywać dla siebie. Nasi klienci dostają tę samą moc, ten sam storage i te same gwarancje regionalne, na których działamy sami, rozliczane godzinowo, obok modeli i systemu marki, z których już korzystają." FOTOhub Press Team

Niezawodność, nadzór i to, czego FOTOhub nie twierdzi

Platforma prowadzi automatyczne śledzenie zdrowia modeli, które wyłącza model zewnętrzny zaczynający zawodzić, zamiast przekazywać błędy klientom, rozliczanie zużycia i kosztu na poziomie operacji, ślady audytowe na poziomie konta, kontrolę dostępu na poziomie wiersza dla danych klientów oraz publiczną powierzchnię statusu, której testy sprawdzają treść odpowiedzi, a nie samą osiągalność.

FOTOhub chce też być precyzyjny co do granic tego ogłoszenia, bo komunikaty o infrastrukturze to miejsce, w którym przesada kosztuje najwięcej. Firma nie ogłasza formalnej certyfikacji bezpieczeństwa i jej nie deklaruje. Nie twierdzi, że każdy zewnętrzny konektor w bibliotece procesów da się dziś podłączyć. Nie twierdzi, że trening modeli marek dla klientów jest ogólnie dostępny, bo wchodzi on w etapowe wdrożenie. I nie publikuje w komunikacie prasowym konkretnych nazw sprzętu ani zobowiązań co do mocy pojedynczych instancji, bo te zmieniają się w krótszym cyklu, niż żyje komunikat prasowy, a wiążącą odpowiedzią w danym momencie jest katalog w konsoli.

Co dalej

Z tego programu wynikają wprost trzy kierunki pracy. Pierwszy to głębokość warstwy wynajmowanej infrastruktury, rozszerzanie katalogu i automatyki wokół niego tak, aby uruchomienie workloadu dla potoku kreatywnego wymagało nie więcej wiedzy o infrastrukturze niż wybór modelu. Drugi to dokończenie drogi treningu marek do ogólnej dostępności, z przyjmowaniem zbiorów danych i serwowaniem wytrenowanych adapterów domkniętym od początku do końca. Trzeci to poszerzanie uwierzytelnionego pokrycia konektorów w warstwie orkiestracji, ogłaszane konektor po konektorze, w miarę jak każdy staje się używalny.

Wspólna nić jest ta sama, która stała za migracją. FOTOhub buduje platformę, w której generowanie kreatywne, wiedza o marce, która czyni je użytecznym handlowo, automatyzacja, która czyni je powtarzalnym, i infrastruktura, na której to wszystko stoi, są jednym systemem z jednym rachunkiem, w regionie wybranym przez klienta. Konsolidacja na AWS była warunkiem wstępnym. Otwarcie jej dla klientów jest celem.

O FOTOhub. FOTOhub to kreatywna platforma AI łącząca wielodostawcowy katalog modeli do generowania obrazu, wideo, audio, tekstu i obiektów trójwymiarowych z systemem marki, trwałym silnikiem procesów, storage obiektowym i infrastrukturą w rozliczeniu godzinowym, udostępnianymi przez udokumentowane API, oficjalne SDK i warstwę narzędzi wywoływalnych maszynowo.

Kontakt prasowy. FOTOhub Press Team, FOTOhub.app

Szczegóły techniczne: dokumentacja API · katalog modeli · konsola infrastruktury · marka i trening