Agent Bucket: Skalowalny do bilionów obiektów natywny zasobnik dla Agentów

W dzisiejszych czasach, gdy Agenci AI wyrastają jak grzyby po deszczu, programiści budują inteligentne aplikacje z wyobraźnią z niespotykaną dotąd prędkością. Od asystentów programowania, którzy pomagają pisać kod, po narzędzia do tworzenia, które generują film z jednego zdania, po osobistych inteligentnych asystentów, którzy są zawsze w pogotowiu, Agenci zmieniają sposób, w jaki wchodzimy w interakcje ze światem cyfrowym. Za tą falą coraz wyraźniejszy staje się konsensus: dzięki architekturze Serverless (takiej jak Lambda), dużym modelom językowym (LLM) i chmurze (takiej jak S3, TOS) w połączeniu z Vibe Coding, każdy może szybko zbudować własnego Agenta AI w 30 minut.

Od "działa" do "działa dobrze", twórcy Agentów nadal muszą pokonać trudności, przechodząc od "zabawek" do "aplikacji klasy produkcyjnej". Wraz z rozwojem biznesu do ogromnej liczby użytkowników, programiści muszą zmierzyć się z niezwykle złożonym wyzwaniem: jak zbudować kompletne rozwiązanie do przechowywania danych dla ogromnej liczby użytkowników końcowych w pamięci obiektowej? Dla większości programistów jest to nie tylko bariera techniczna, ale także przepaść, która utrudnia skalowalną dystrybucję Agentów. Agent Bucket ma na celu radykalne uproszczenie procesu budowania systemów wielodostępnych dzięki natywnej dla AI konstrukcji pamięci masowej, zapewniając bardziej przyjazne możliwości Agentów.

Gdy napływają setki milionów użytkowników, tradycyjna pamięć obiektowa "nie wystarcza"

Wyobraź sobie, że opracowałeś popularną aplikację AIGC. Każdy użytkownik będzie generował i przechowywał ogromne ilości zdjęć, filmów i plików tymczasowych. Jako programista naturalnie wybierzesz dojrzałe i skalowalne usługi przechowywania obiektów, takie jak S3 i TOS. Ale pojawia się pytanie: jak zarządzać danymi dla ogromnej liczby użytkowników?

Blog S3 z 2022 roku, zatytułowany "Partitioning and Isolating Multi-Tenant SaaS Data with Amazon S3", opisuje dwa sposoby: "Używanie oddzielnych zasobników S3 dla każdego najemcy" i "Współdzielone zasobniki S3 izolowane na podstawie prefiksów":

• Utwórz oddzielny "zasobnik" (Bucket) dla każdego użytkownika: jest to wykonalne, gdy liczba użytkowników jest niewielka, ale gdy liczba użytkowników wzrośnie do dziesiątek tysięcy lub milionów, liczba zasobników szybko eksploduje, a koszty zarządzania i ograniczenia zasobów stają się nie do zniesienia. S3 oferuje łączną kwotę 10 000 zasobników dla całego regionu, ale w przypadku popularnych możliwości AI 10 000 to zdecydowanie za mało.

• Użyj "prefiksów" do rozróżniania użytkowników w tym samym zasobniku: stało się to głównym rozwiązaniem. Na przykład pliki użytkownika A zaczynają się od user-a/, a pliki użytkownika B zaczynają się od user-b/, tak jak zarządzanie plikami w folderach na komputerze. Jednak w pamięci obiektowej nie ma natywnych folderów, to rozwiązanie rozróżnia wielu najemców za pomocą "wspólnego prefiksu" w systemie przechowywania "K-V".

To rozwiązanie oparte na "zasobnikach" lub "prefiksach" było szeroko stosowane w ciągu ostatnich dziesięciu lat. Ale istnieją następujące problemy:

• Izolacja wielu najemców: dane wszystkich użytkowników są pomieszane w tym samym zasobniku, a nietypowy dostęp o wysokiej częstotliwości jednego użytkownika może wpłynąć na wszystkich innych użytkowników, powodując "efekt sąsiedztwa". Izolacja wydajności i izolacja awarii są niemożliwe.

• Kontrola uprawnień: złożone zasady uprawnień (IAM Policy) są trudne w utrzymaniu i łatwo o błędy konfiguracyjne, które mogą prowadzić do przypadkowego dostępu do danych użytkownika, zwłaszcza gdy konieczna jest interakcja z innymi usługami w chmurze, ryzyko jest większe.

• Jasność kosztów: trudno jest dokładnie wiedzieć, ile miejsca w pamięci masowej zużył każdy użytkownik i ile kosztów transferu wygenerował. Kiedy chcesz pobierać opłaty od płacących użytkowników na podstawie zużycia, rozliczenia i pomiary stają się niejasne.Dlaczego te pozornie podstawowe potrzeby są dla twórców Agentów tak "ciężkie" w implementacji na pamięci obiektowej? Dogłębna analiza przyczyn, dlaczego w obecnej architekturze chmurowej istnieje ogromna luka między "pamięcią obiektową" S3/TOS a tradycyjnym "systemem plików". Istotą pamięci obiektowej (S3/TOS) jest "spłaszczenie", a jej pierwotnym celem jest proste przechowywanie ogromnych ilości danych, niczym ogromny magazyn. Chociaż pojemność jest niemal nieograniczona, to struktura logiczna jest niezwykle prosta. Brakuje jej natywnego, zaawansowanego zarządzania katalogami, szczegółowej kontroli metadanych i prawdziwej świadomości najemców (ang. tenant). Kiedy deweloperzy próbują na "płaskim" S3, poprzez twardo zakodowane prefiksy, symulować "trójwymiarowy" system plików dla wielu najemców, w rzeczywistości używamy "statycznej pamięci KV", aby obsługiwać sposób dostępu do plików aplikacji Agent, który ma "semantykę katalogów i silną izolację". Oznacza to, że Agent musi dodatkowo zużywać tokeny do zarządzania plikami i kontrolować uprawnienia i izolację wielu najemców. To dodatkowe zużycie tokenów pokazuje, że prosta usługa przechowywania zdefiniowana przez S3 nie jest wystarczająco prosta dla Agenta.

Artykuł z bloga S3 z 2025 roku, zatytułowany "Design patterns for multi-tenant access control on Amazon S3", dodatkowo omawia S3 Access Point. Oznacza to, że można utworzyć wiele wirtualnych punktów dostępu do sieci i skonfigurować dla każdego z nich niestandardową politykę dostępu, co na poziomie planowania sieci daje pewne rozwiązania dla scenariuszy z wieloma najemcami.

Agent Wonderland

Idealny twórca Agenta, podczas tworzenia AI Agenta, może zbudować w pełni serwerlessowego Agenta w oparciu o "Agent SDK + przechowywanie + usługi MaaS":

• Agent może działać w pełni serwerlessowo

• Można łączyć istniejące możliwości produktu, aby zbudować Agenta za pomocą Vibe Coding

• Wystarczy utrzymywać skrypt Pythona "ADK"

• Przechowywanie wykorzystuje pamięć obiektową

• Zdolności AI wykorzystują Doubao (nazwa własna)

• Teoretycznie nie ma ECS ani innych produktów instancyjnych

Jednocześnie przechowywanie musi zapewniać następujące możliwości:

• Agent może mieć przechowywanie z semantyką obiektów (zapisywanie plików), zapewniające możliwość dostępu dla wielu najemców, zaczynając od miliona, z możliwością rozszerzenia do miliarda

• Agent może zapewnić każdemu użytkownikowi niezależną przestrzeń (między wieloma usługami, nazwy usług lub UID mogą się powtarzać)

• Agent może bezpośrednio konfigurować przepustowość dla każdego użytkownika, konfigurować limit całkowitego rozmiaru obiektu użytkownika

• Agent może rozliczać, monitorować i obserwować użytkowników

• Agent może konfigurować polityki dostępu do plików dla każdego użytkownika

Agent Bucket: Wstrzykiwanie "natywnego dla wielu najemców" genu do AI Agenta

Aby zasadniczo rozwiązać ten problem, zaproponowaliśmy zupełnie nową paradygmat pamięci obiektowej - Agent Bucket. Jego podstawową innowacją jest wprowadzenie nowej, natywnej warstwy zasobów między tradycyjnym "bucketem" a "obiektem": zbiór obiektów (ObjectSet).

Podstawowa idea tego projektu jest niezwykle prosta: dopasuj dedykowany ObjectSet do każdego użytkownika końcowego. Możesz myśleć o ObjectSet jako o "sejfie danych" lub "osobistej przestrzeni w chmurze" stworzonej specjalnie dla każdego użytkownika. Logicznie należy on do Twojego (dewelopera) Bucketa, ale fizycznie i zarządczo ma swoją własną, niezależną "osobowość" i "cykl życia".Agent Bucket obsługuje 100 milionów ObjectSetów w każdym kubełku, co oznacza, że możesz bez problemu obsługiwać setki milionów użytkowników końcowych, tak jakby każdy użytkownik "żył" w oddzielnej przestrzeni dyskowej, bez konieczności martwienia się o zarządzanie pamięcią masową dla wielu najemców.

Projekt ObjectSet – możliwości przyjazne dla Agenta

W Agent Bucket ObjectSet to nie tylko dodanie kolejnej warstwy, ale także przekształcenie najbardziej kłopotliwych potrzeb w scenariuszach wielodostępności w gotowe do użycia, natywne możliwości. Gdy własność danych zostanie jasno określona na poziomie ObjectSet, szereg możliwości, które wcześniej były trudne do zrealizowania, staje się naturalny.

• Natywna izolacja: Na poziomie ObjectSet możesz ustawić niezależne limity QPS, przepustowości i pojemności dla każdego użytkownika. Doświadczenie płacących użytkowników może być zagwarantowane, a nietypowe zachowania bezpłatnych użytkowników nie będą miały wpływu na innych. Jest to prawdziwa izolacja domeny awarii, dzięki której "sąsiedzi" nie przeszkadzają sobie nawzajem.

• Natywne uprawnienia: Każdy ObjectSet może mieć niezależną domenę. Oznacza to, że możesz dać użytkownikowi A dedykowany adres dostępu user-a.yourapp.com, zamiast ujawniać domenę całego kubełka. Jeszcze sprytniejszy jest projekt "dwóch zamków": pierwszy zamek to tymczasowe poświadczenia dostępu (STS) wydane przez dostawcę usług w chmurze, kontrolujące uprawnienia dostępu na poziomie aplikacji; drugi zamek to niezależna domena ObjectSet, która blokuje żądania dostępu do przestrzeni danych użytkownika z poziomu sieci. To znacznie poprawia bezpieczeństwo danych.

• Natywny monitoring: Na panelu monitoringu nie widzisz już tylko danych przeglądowych dla całego kubełka. Możesz rozłożyć wykresy monitoringu by-ObjectSet, aby wyraźnie zobaczyć, który użytkownik końcowy generuje duży ruch, a tym samym podejmować precyzyjne decyzje operacyjne i optymalizacyjne.

• Natywne możliwości schodzą w dół: Zasady, które wcześniej można było ustawić tylko na poziomie kubełka, można teraz przenieść do każdego użytkownika. Możesz ustawić różne cykle życia danych dla różnych poziomów użytkowników lub użyć różnych kluczy szyfrowania dla każdego ObjectSet, aby uzyskać bardziej szczegółowe i bezpieczne zarządzanie danymi.

• Natywne pomiary: Chcesz wiedzieć, ile miejsca zajmuje każdy użytkownik? Chcesz dokładnie rozłożyć koszty przechowywania na każdego użytkownika? Teraz staje się to łatwe. Agent Bucket automatycznie oblicza pojemność i wykorzystanie każdego ObjectSet, dzięki czemu rozliczenia i podział kosztów są jasne i przejrzyste.

• Natywne rozliczenia: Deweloperzy mogą łatwo realizować podział kosztów, precyzyjnie przekazując koszty generowane przez pamięć masową każdemu użytkownikowi końcowemu. Na przykład, różnicować opłaty w oparciu o rzeczywiste proporcje kosztów generowanych przez różnych użytkowników A, B i C, zapewniając wsparcie danych dla komercjalizacji Agenta.

• Natywny limit pojemności: Aby kontrolować koszty operacyjne Agenta, możesz ustawić Quota (limit pojemności) dla każdego ObjectSet. Po osiągnięciu ustawionej wartości system ograniczy generowanie nowych plików przez tego użytkownika, zapobiegając w ten sposób nadużyciom zasobów w scenariuszach wielodostępności.

• Natywna inteligencja: Agent Bucket pozwala Agentowi wyjść poza proste "przechowywanie i pobieranie" plików, nadając Objectowi natywną inteligencję, aby wydajniej wspierać kompleksowe tworzenie Agenta. ObjectSet może włączyć inteligentne indeksowanie jednym kliknięciem, zapewniając Agentowi natywnie przyjazne możliwości pytań i odpowiedzi multimodalnych, zastępując mechaniczne operacje Object CRUD; obsługuje nawet tryb Agentself jednym kliknięciem, łącząc wektory, wiedzę, modele i prompt, bezpośrednio ujawniając funkcje sub-Agentów specyficzne dla scenariusza, umożliwiając programistom Agentów wyższego poziomu skupienie się na tworzeniu głównych przepływów pracy biznesowej, w pełni uwalniając wydajność monetyzacji inteligencji.

Wyzwania techniczne związane z gwałtownym wzrostem skali aplikacji

Agent Bucket, wprowadzając natywną koncepcję ObjectSet, zapewnia programistom aplikacji elegancki i wydajny sposób zarządzania danymi setek milionów użytkowników końcowych. Zasoby cyfrowe każdego użytkownika są bezpiecznie przechowywane w jego dedykowanym ObjectSet, naturalnie realizując izolację, rozliczenia i zarządzanie przydziałami.

Wraz z gwałtownym wzrostem skali aplikacji, złożoność zarządzania ogromną liczbą Setów, trudności z izolacją i fizyczne wąskie gardła stają się widoczne:

• Problem z hierarchicznym zarządzaniem ogromną liczbą użytkowników: Gdy aplikacja różnicuje zarządzanie zasobami i funkcjami dużej liczby użytkowników o różnych poziomach, musi samodzielnie zaprojektować i wdrożyć metadane hierarchii użytkowników oraz powiązać przełączniki funkcji przechowywania obiektów. Pomoc programistom w eleganckim zarządzaniu hierarchią użytkowników w oparciu o natywną koncepcję Set jest ważna dla przyspieszenia wdrażania aplikacji.- Wąskie gardło pojemności pojedynczego klastra: Chociaż Agent Bucket może być logicznie rozszerzany w nieskończoność, jego metadane są domyślnie przechowywane w jednym klastrze fizycznym. Gdy łączna liczba obiektów w buckecie osiągnie setki miliardów, a nawet biliony, fizyczna pojemność pojedynczego klastra staje się nieprzekraczalną granicą.

• Problem współdzielenia punktu dostępu: Różnorodność biznesowa agenta i ogromna liczba użytkowników stwarzają większe ryzyko bezpieczeństwa i promień rażenia dla samego punktu dostępu. Trudnością staje się, jak dynamicznie planować w oparciu o różnice między dużą liczbą różnych biznesów i użytkowników, aby osiągnąć zróżnicowane możliwości bezpieczeństwa, izolacji i przyspieszenia.

Set Tagging: Tagowanie do zarządzania warstwami użytkowników

ObjectSet zapewnia natywne metody zarządzania tagami, umożliwiając programistom agentów proste korzystanie z możliwości tagowania zestawów w celu ukończenia zarządzania warstwami użytkowników. Programiści mogą przypisać tag do każdego zdefiniowanego poziomu użytkownika i włączyć różne limity i funkcje dla każdego tagu. Wszystkie ObjectSety oznaczone tym tagiem będą miały zastosowane odpowiednie limity i funkcje. Przykład z trzema poziomami: V1, V2 i V3:

• V1: Domyślny poziom, darmowi użytkownicy, domyślny tag dla wszystkich ObjectSetów, można skonfigurować maksymalnie 1 GiB danych, dystrybucja w sieci publicznej nie może przekraczać przepustowości 100 mbps, a prędkość pobierania pojedynczego strumienia jest kontrolowana do 1 mbps;

• V2: Płatni członkowie poziomu podstawowego, konfiguracja do przechowywania 10 GiB danych, dystrybucja w sieci publicznej nie może przekraczać przepustowości 10 gbps, a prędkość pobierania pojedynczego strumienia jest kontrolowana do 10 mbps;

• V3: Płatni członkowie premium, oprócz zapewnienia większej ilości miejsca i limitów dystrybucji w sieci publicznej, obsługują również konfigurację dodatkowego przyspieszenia słabej sieci publicznej i możliwości przyspieszenia nośników o wysokiej wydajności;

Programiści agentów mogą elastycznie używać tagowania V1/V2/V3 do zarządzania zasobami i funkcjami o wartości dodanej, z których mogą korzystać ci użytkownicy, w różnych cyklach rozwoju różnych użytkowników.

Set Slice: Natywna izolacja danych dla ogromnej liczby użytkowników

Gdy liczba Setów w Agent Bucket osiągnie setki milionów, a liczba obiektów osiągnie setki miliardów lub biliony, sam fakt, że "wszystkie metadane pojedynczego Bucketa są scentralizowane w jednym klastrze KV", stwarza podwójne ryzyko pojemności i wydajności.

Set Slice oferuje podejście "logicznie nie dziel, fizycznie dziel":

• Z logicznego punktu widzenia nadal zarządzasz tylko jednym Agent Bucketem.

• Fizycznie, w oparciu o zakres Setu i nazw obiektów w Setcie, metadane są dzielone na wiele Slice'ów (plastrów), a każdy Slice może być przechowywany w różnych klastrach. Wiele Setów jest naturalnie izolowanych, a pojedynczy Set jest skalowany w poziomie.

Set Slice jest dalszym rozszerzeniem i gwarancją możliwości ObjectSet. Rozwiązuje problem nieograniczonej rozbudowy pojemności fizycznej na poziomie podstawowym, zapewniając jednocześnie stabilność i spójność modelu zarządzania ObjectSet na wyższym poziomie.

• Stabilna granica zarządzania: Nawet jeśli dane Agent Bucket obejmują wiele klastrów fizycznych, ObjectSet nadal jest jedyną podstawową jednostką uprawnień, limitów, rozliczeń i monitorowania. Strategie konfigurowane przez programistów dla ObjectSet (takie jak kontrola dostępu, limity pojemności) automatycznie wchodzą w życie na wszystkich powiązanych Slice'ach, bez konieczności martwienia się o dystrybucję danych na poziomie podstawowym.

• Pojedynczy Set może być skalowany liniowo: Gdy ilość danych w ObjectSet rośnie szybko, jego dane są naturalnie dystrybuowane do wielu Slice'ów. Wraz z rozszerzeniem całego klastra, pojemność ObjectSet również rośnie płynnie i liniowo. Programiści nie muszą wykonywać żadnych destrukcyjnych operacji, takich jak dzielenie lub migracja samego ObjectSet.

• Izolacja zasobów między Setami: Dystrybuując obiekty o różnych zakresach w różnych klastrach fizycznych, SetSlice realizuje izolację zasobów o wyższym wymiarze. W połączeniu z zarządzaniem limitami ObjectSet, może skutecznie zapobiegać wzrostowi danych "super dużego" ObjectSet, który wypiera wszystkie zasoby pojedynczego klastra, wpływając w ten sposób na stabilność innych ObjectSetów, dzięki czemu ogólne ryzyko pojemności staje się kontrolowane. - Logiczna jednolitość i kompatybilność: Zarówno dla biznesu, jak i dla programistów, niezależnie od tego, ile Slice'ów znajduje się pod spodem, zawsze mają do czynienia z logicznie jednolitym Agent Bucket. Wszystkie operacje na bucketach, ObjectSetach i obiektach pozostają niezmienione, co zapewnia całkowitą transparentność rozszerzenia fizycznego dla aplikacji wyższego poziomu.

Set AccessPoint: Izolacja punktów dostępu dla każdego użytkownika

Agent Bucket obsługuje włączanie niezależnych punktów dostępu (niezależnych domen) dla każdego ObjectSetu i rozszerzanie zróżnicowanych możliwości w zakresie bezpieczeństwa, izolacji i przyspieszenia w punktach dostępu. System musi w tym celu obsługiwać planowanie niezależnych punktów dostępu na poziomie miliardów i zróżnicowane możliwości konfiguracji.

Niezależna domena dostępu {$apid}.tos-objectset-ap.volces.com: Dwupoziomowa ochrona bezpieczeństwa

• Pierwszy poziom Obscurity (ukrycie): Niezależna subdomena By User/ObjectSet, wysoka entropia haszowania apid, bardzo niskie prawdopodobieństwo kolizji, niemożność odgadnięcia i wyliczenia konkretnego punktu wejścia użytkownika z perspektywy domeny dostępu;

• Drugi poziom Containment (ograniczenie): Programiści Agent używają sts do dystrybucji uprawnień dostępu na poziomie ObjectSet, nawet jeśli sts wycieknie, można kontrolować zakres dostępu ograniczony do ograniczonego okresu ważności określonego ObjectSetu;

Heurystyczny system planowania: Obliczanie strategii planowania dla miliardów domen

• Zróżnicowana strategia dostępu By user/ObjectSet:tag

• Automatyczne rozpraszanie wielu user/ObjectSet na różnych publicznych punktach wejścia, kontrolowana liczba użytkowników dotkniętych awarią pojedynczego punktu wejścia

• Elastyczne planowanie w całym regionie, automatyczne pakowanie i przenoszenie ruchu w przypadku awarii/przeciążenia dowolnego pojedynczego punktu wejścia

• Użytkownicy klasy dystrybucji przyspieszenia publicznego, oznaczani tagiem przyspieszenia transmisji publicznej, automatyczne planowanie punktu wejścia przyspieszenia

• Użytkownicy klasy ryzyka publicznego, oznaczani tagiem ryzyka, automatyczne planowanie publicznego punktu wejścia izolacji i obniżanie limitu przepustowości publicznej

• Użytkownicy klasy międzydomenowej sieci wewnętrznej, oznaczani tagiem międzydomenowym, automatyczne planowanie przyspieszonej ścieżki dedykowanej sieci wewnętrznej

• Użytkownicy lokalnego akceleratora, oznaczani tagiem akceleratora, automatyczne montowanie lokalnego akceleratora

Od asystenta programowania po dysk AI w chmurze, nieograniczone możliwości Agent Bucket

Agent Bucket zapewnia kompletne rozwiązanie dla Agenta, a scenariusze zastosowania projektu ObjectSet wykraczają daleko poza to. Można go łatwo rozszerzyć na wszystkie aplikacje, które wymagają świadczenia usług dla ogromnej liczby użytkowników końcowych:

• Repozytorium kodu: W przeszłości, gdy przedsiębiorstwa lub osoby fizyczne hostowały kod w chmurze, często musiały budować warstwę "systemu najemcy" na pamięci masowej obiektów, aby osiągnąć izolację kont i kontrolę uprawnień. Teraz można przypisać dedykowany ObjectSet każdemu programiście, aby ujednolicić repozytorium kodu, artefakty kompilacji i zależności. Agent Skills są również naturalnie dostosowane do ObjectSet. Przesyłanie, pobieranie i dystrybucja Skills odbywa się za pośrednictwem ObjectSet, zapewniając silną izolację, aby uniknąć zakłóceń sąsiednich Agentów podczas działania.

• Firmowy album zdjęć/dysk sieciowy: Tradycyjne usługi albumów zdjęć lub dysków sieciowych często mieszają zdjęcia wszystkich użytkowników w tym samym buckecie, rozróżniając użytkowników za pomocą prefiksów, co jest nie tylko trudne w zarządzaniu, ale także podatne na "efekt sąsiedztwa". W oparciu o ObjectSet zdjęcia i filmy każdego użytkownika znajdują się w ich własnym Set, szczyty dostępu nie zakłócają się wzajemnie, a także można ustawić limity pojemności, strategie tworzenia kopii zapasowych i metody szyfrowania dla każdego użytkownika, aby naprawdę osiągnąć "każdy ma bezpieczny i kontrolowany album w chmurze".

• Hurtownia danych Hadoop: W hurtowni danych przedsiębiorstwa różne linie biznesowe i różne bazy danych często współdzielą zasoby na tej samej warstwie bazowej pamięci masowej. Mapując każdą bazę danych na ObjectSet, przedsiębiorstwo może zaimplementować izolację i kontrolę przydziałów na poziomie bazy danych na ujednoliconej pamięci masowej. W szczególności ObjectSet zapewnia dodatkową warstwę uprawnień w TOS, zapewniając izolację i kontrolę uprawnień dla baz danych i tabel przechowywanych w TOS bez zmiany istniejącego Proton on TOS. - Platforma hostingu modeli: W scenariuszach hostingu dużych modeli, każdy model jest nie tylko ogromny, ale może również odpowiadać różnym wersjom, wagom i konfiguracjom wnioskowania. Utworzenie ObjectSet dla każdego modelu pozwala na spakowanie i hostowanie wag modelu, Tokenizera, plików konfiguracyjnych i powiązanych danych ewaluacyjnych w tej samej przestrzeni. Strona operacyjna może ustawić zróżnicowane strategie szyfrowania, strategie tworzenia kopii zapasowych i kontrolę przepustowości dla różnych modeli. Jednocześnie, dzięki natywnym możliwościom pomiarowym, można statystycznie określić rzeczywisty koszt użytkowania każdego modelu, co stanowi podstawę do rozliczeń i planowania zasobów w wymiarze modelu.

• Usługi Data SaaS: Platformy dystrybucji danych skierowane do ogromnej liczby użytkowników końcowych często muszą łączyć się z wieloma dostawcami danych, zapewniając jednocześnie jasne granice danych każdej ze stron i unikając ryzyka wydajności "jeden duży kubeł spowalnia wszystkich". Dzięki Agent Bucket każdy dostawca danych może mieć swój własny ObjectSet, który ujednolica zarządzanie danymi pierwotnymi i wynikami przetwarzania. Następnie, poprzez niezależne domeny i przepustowość, kwoty QPS, można zapewnić zróżnicowane usługi i ograniczenia przepływu dla różnych dostawców, realizując infrastrukturę dystrybucji danych "jedna platforma, wielu dostawców, izolacja i kontrolowana współpraca".

Odnośniki:

• https://aws.amazon.com/cn/blogs/apn/partitioning-and-isolating-multi-tenant-saas-data-with-amazon-s3/

• https://aws.amazon.com/cn/blogs/storage/design-patterns-for-multi-tenant-access-control-on-amazon-s3/