Krok 1: aplikacja produkcyjna instrumentuje każde wywołanie LLM stabilnym identyfikatorem zadania (workload_id) i loguje pełen request/response do scentralizowanego store'u (np. Elasticsearch). Krok 2: orchestrator (np. Celery) okresowo zbiera logi, deduplikuje i dzieli na zbiory ewaluacyjny i treningowy z balansem klas (stratified split). Krok 3: dla każdego workload_id równolegle uruchamiane są trzy typy eksperymentów na puli kandydatów modelowych (base, in-context learning, LoRA fine-tune). Krok 4: ewaluator porównuje wyniki kandydatów z produkcyjnym modelem przez LLM-as-judge w skali [0,1]. Krok 5: kandydaci z wynikiem powyżej progu trafiają do human review; po akceptacji są wdrażani jako nowy NIM, co zamyka pętlę. Cykl powtarza się dziennie, tygodniowo lub na żądanie.
Modele frontierowe są drogie i wolne na inferencji, ale produkcyjne aplikacje generują wystarczająco wąsko-tematyczne dane (np. pojedyncza ścieżka agenta), żeby model 70-krotnie mniejszy mógł je obsłużyć po fine-tuningu. Brakowało zautomatyzowanego procesu, który ciągle wykrywa takie okazje i utrzymuje produkcję na najtańszym, wystarczająco dokładnym modelu, bez konieczności ręcznego projektowania eksperymentów przez inżynierów ML.
Scentralizowany magazyn surowych logów produkcyjnych w schemacie {timestamp, workload_id, client_id, request, response}. NVIDIA Blueprint używa Elasticsearch 8.12.
Oficjalna
Komponent który pobiera logi z log store, deduplikuje je per workload_id i dzieli na zbiory eval/train z class-aware stratified splitting (scikit-learn), zapewniając zbalansowaną reprezentację typów wywołań.
Oficjalna
Workflow runner planujący eksperymenty per workload_id × kandydat (base / ICL / LoRA fine-tune) i wykonujący je równolegle z respektem dla puli GPU. NVIDIA Blueprint używa Celery z parent_queue (concurrency=1) dla głównego DAG i osobnego workera dla evals.
Oficjalna
Komponent dostrajający kandydujące modele bazowe na datasecie treningowym workload_id. NVIDIA Blueprint używa NeMo Customizer z SFT + LoRA (adapter dim 32, dropout 0.1, 2 epochs, batch 16, lr 1e-4).
Oficjalna
Komponent porównujący odpowiedzi kandydatów z odpowiedziami modelu produkcyjnego przez LLM-as-judge, zwracający wynik podobieństwa w skali [0, 1]. NVIDIA Blueprint używa NeMo Evaluator z opcją self-hosted (6 GPU) lub remote (2 GPU) judge.
Oficjalna
Świadomie ręczny krok: inżynier ML lub badacz przegląda kandydatów wskazanych przez ewaluator i decyduje o wdrożeniu. NVIDIA Blueprint definiuje flywheel jako „latarkę, nie autopilota" — promocja do produkcji pozostaje decyzją człowieka.
Domyślnie NVIDIA Blueprint kieruje surowy ruch produkcyjny do trenowania, bez maskowania danych osobowych. Dla wielu branż (zdrowie, finanse, sektor publiczny) jest to nieakceptowalne i wymaga własnego pipeline'u redakcji PII przed log store.
Wzorzec buduje zbiory ewaluacyjne z odpowiedzi modelu produkcyjnego, traktowanych jako wzorzec. Jeśli produkcja systematycznie się myli w wąskim wycinku, kandydaci dostroją się do tych samych błędów.
NVIDIA Blueprint v1 ogranicza concurrency parent_queue do 1, więc tylko jeden run flywheela jednocześnie. W dużych deploymentach tworzy to wąskie gardło niezależne od ilości GPU.
Pętla optymalizuje koszt i latencję; nawet z human-in-the-loop ryzyko jest takie, że kolejne iteracje obniżają jakość modelu o niezauważalny ułamek, który po wielu wymianach kumuluje się w wyraźną regresję.
Biznesowa metafora ciężkiego koła rozpędzanego konsekwentnymi pchnięciami — koncepcja zaczerpnięta później do AI/ML.
Termin „data flywheel" zaczyna być stosowany w VC i edukacji AI dla pętli produkt → dane → model → produkt.
Pierwsza publiczna referencyjna implementacja flywheela jako produkcyjnego serwisu, oparta o NeMo Microservices (Datastore, Customizer, Evaluator, Deployment Manager). Wynik 98,6% redukcji kosztów w HR chatbocie NVIDIA.
NVIDIA wycofuje publiczny blueprint jako reference-only i przenosi rozwój do nowszych wzorców na NeMo Microservices. Wzorzec Data Flywheel jako koncept pozostaje aktywny i nadal stosowany przez społeczność i inne stosy (LangSmith, Arize, Weights & Biases).
Złożoność czasowa: O(W · K · E + W · F). Złożoność przestrzenna: O(L + K · M_adapter + D).
Bottleneck przeniósł się z ręcznej pracy inżyniera ML na zasoby GPU. NVIDIA Blueprint v1 serializuje całe runy DAG (concurrency=1 dla parent_queue), bo nie ma jeszcze automatycznego discovery wolnych GPU.
Jak drobno dzielimy ruch produkcyjny na zadania. Zbyt grubo = niewykrywalne wzorce; zbyt drobno = brak masy krytycznej do fine-tuningu (min. 50 rekordów).
Lista mniejszych modeli rozważanych jako zastępcy produkcyjnego. NVIDIA Blueprint v1 testuje Meta Llama 3.2 1B Instruct; roadmapa: Qwen, Llama-Nemotron, Mistral.
Jak często orchestrator uruchamia pełen DAG flywheela.
Liczba przykładów odkładanych do ewaluacji per workload_id. NVIDIA Blueprint default = 20 ewaluacja + 0.1 walidacji.
Hiperparametry fine-tuningu LoRA: adapter_dim, dropout, epochs, batch_size, learning_rate.
Pętla flywheela aktywuje się na różnych etapach życia modelu: codziennie (incremental), tygodniowo (deep sweep), ad-hoc (po zmianie aplikacji).
Każde wywołanie produkcyjne dostaje workload_id (np. agent.tool_router). Orchestrator routuje logi tego workload_id do osobnego potoku ewaluacji i osobnego kandydata fine-tune. To routing nie inferencyjny — routing pętli treningowo-ewaluacyjnej.
Architektura jest naturalnie equivalent do hyperparameter sweep — każde workload_id × kandydat × strategia (base/ICL/LoRA) jest niezależnym jobem.
Fine-tuning LoRA i równoległa inferencja LLM-as-judge wymagają mocnych Tensor Cores. NVIDIA Blueprint minimum: 6× H100/A100 (self-hosted judge) lub 2× (remote judge).
Komponenty orchestracji (Celery), log store (Elasticsearch), API (FastAPI), MongoDB, Redis działają w pełni na CPU.
Sam koncept Data Flywheel jest abstrakcyjnym wzorcem systemowym — można go zrealizować na dowolnym stosie ML (TPU, AWS Inferentia, AMD MI300).
