Agent Bucket: Trilyong-Scale na Katutubong Bucket ng Agent

Sa panahon ngayon na tila kabute ang pagsulpot ng mga AI Agent, ang mga developer ay bumubuo ng mga matatalinong aplikasyon na puno ng imahinasyon sa bilis na hindi pa nararanasan. Mula sa mga programming assistant na kayang tumulong sa iyong magsulat ng code, hanggang sa mga tool sa paglikha na kayang bumuo ng isang pelikula sa isang pangungusap, hanggang sa mga personal na matatalinong assistant na laging handa, binabago ng Agent ang paraan ng ating pakikipag-ugnayan sa digital na mundo. Sa likod ng alon na ito, isang kasunduan ang lalong lumilinaw: sa tulong ng Serverless architecture (tulad ng Lambda), malalaking modelo ng wika (LLM), at cloud storage (tulad ng S3, TOS), kasama ang Vibe Coding, kahit sino ay kayang bumuo ng sarili nilang AI Agent sa loob ng 30 minuto.

Mula sa "nagagamit" hanggang sa "magandang gamitin", kailangan pa ring lampasan ng mga developer ng Agent ang mga problema mula sa "laruan" patungo sa "aplikasyon na pang-produksyon". Habang lumalaki ang negosyo sa napakaraming gumagamit, kailangang harapin ng mga developer ang isang napakakumplikadong hamon: paano bumuo ng isang kumpletong solusyon sa pag-iimbak para sa napakaraming end user sa object storage? Para sa karamihan ng mga developer, hindi lamang ito isang teknikal na hadlang, kundi isang hadlang din sa malawakang pamamahagi ng Agent. Nilalayon ng Agent Bucket na lubusang pasimplehin ang proseso ng pagbuo ng multi-tenant system sa pamamagitan ng AI-native na disenyo ng storage, na nagbibigay ng mas madaling gamiting kakayahan ng Agent.

Kapag dumagsa ang daan-daang milyong gumagamit, ang tradisyonal na object storage ay "hindi na sapat"

Gayahin na lamang na nakabuo ka ng isang sikat na AIGC application. Ang bawat gumagamit ay bubuo at mag-iimbak ng maraming larawan, video, at pansamantalang file. Bilang isang developer, natural na pipiliin mo ang mga mature at scalable na serbisyo ng object storage tulad ng S3 at TOS. Ngunit narito ang problema: paano pamahalaan ang data para sa napakaraming gumagamit?

Sa blog ng S3 noong 2022 na 《Partitioning and Isolating Multi-Tenant SaaS Data with Amazon S3》, ipinaliwanag ang dalawang paraan, "gumamit ng hiwalay na S3 bucket para sa bawat tenant" at "shared S3 bucket na nakahiwalay batay sa prefix":

• Lumikha ng isang hiwalay na "bucket" para sa bawat gumagamit: Ito ay posible kapag kakaunti ang mga gumagamit, ngunit kapag ang bilang ng mga gumagamit ay lumago sa sampu-sampung libo, daan-daang libo, ang bilang ng mga bucket ay mabilis na sasabog, at ang mga gastos sa pamamahala at mga limitasyon sa mapagkukunan ay magiging mahirap tiisin. Nagbibigay ang S3 ng kabuuang quota ng 10000 bucket sa buong rehiyon, ngunit para sa sikat na kakayahan ng AI, ang 10000 ay hindi pa rin sapat.

• Gumamit ng "prefix" upang paghiwalayin ang mga gumagamit sa parehong bucket: Ito ang naging pangunahing solusyon. Halimbawa, ang mga file ng gumagamit A ay nagsisimula sa user-a/, at ang mga file ng gumagamit B ay nagsisimula sa user-b/, tulad ng paggamit ng mga folder upang pamahalaan ang mga file sa isang computer. Ngunit walang katutubong folder sa object storage, ang solusyon na ito ay upang paghiwalayin ang multi-tenant sa pamamagitan ng "common prefix" sa sistema ng pag-iimbak ng "K-V".

Ang solusyon na nakabatay sa "bucket" o "prefix" na ito ay malawakang ginagamit sa nakalipas na sampung taon. Ngunit may mga sumusunod na problema:

• Paghihiwalay ng multi-tenant: Ang data ng lahat ng mga gumagamit ay magkahalo sa parehong bucket, at ang abnormal na madalas na pag-access ng isang gumagamit ay maaaring makaapekto sa lahat ng iba pang mga gumagamit, na nagdudulot ng "neighbor effect". Walang pag-uusap tungkol sa paghihiwalay ng pagganap at paghihiwalay ng pagkabigo.

• Pagkontrol sa pahintulot: Mahirap mapanatili ang mga kumplikadong patakaran sa pahintulot (IAM Policy), at madaling magkaroon ng mga pagkakamali sa pagsasaayos, na nagreresulta sa hindi sinasadyang pag-access sa data ng gumagamit, lalo na kapag kailangang makipag-ugnayan sa iba pang mga serbisyo sa cloud, mas malaki ang panganib.

• Malinaw na gastos: Mahirap mong malaman nang eksakto kung magkano ang espasyo sa pag-iimbak na ginamit ng bawat gumagamit at kung magkano ang gastos sa trapiko na nabuo. Kapag gusto mong maningil sa mga nagbabayad na gumagamit batay sa paggamit, ang pagsingil at pagsukat ay magiging isang magulong account.Bakit parang "mabigat" ang implementasyon ng mga developer ng Agent sa object storage para sa mga tila simpleng pangangailangan na ito? Ang malalim na dahilan ay dahil sa kasalukuyang cloud-native architecture, may malaking vacuum sa pagitan ng "object storage" tulad ng S3 at ng tradisyunal na "file system". Ang esensya ng object storage (S3/TOS) ay "flat", at ang orihinal na layunin ay simpleng pag-iimbak ng napakaraming data, tulad ng isang malaking bodega. Bagama't halos walang limitasyon ang kapasidad, napakasimple ng lohikal na istruktura. Kulang ito sa native na advanced na pamamahala ng direktoryo, fine-grained na kontrol ng metadata, at tunay na tenant awareness. Kapag sinusubukan ng mga developer na gayahin ang isang "three-dimensional" na multi-tenant file system sa "flat" na S3 sa pamamagitan ng hard-coding prefix, ginagamit natin ang isang uri ng "static na KV storage" upang suportahan ang isang "directory semantics, strongly isolated" na paraan ng pag-access sa file ng Agent application. Ibig sabihin, kailangan ng Agent na gumamit ng karagdagang token para pamahalaan ang mga file, at kontrolin at lutasin ang mga pahintulot at paghihiwalay ng multi-tenant. Ang mga karagdagang token na ito ay nagpapakita na ang simpleng serbisyo ng storage na tinukoy ng S3 ay hindi sapat na simple para sa Agent.

Sa blog ng S3 noong 2025, "Design patterns for multi-tenant access control on Amazon S3", ipinaliwanag pa ang S3 Access Point. Ibig sabihin, maaaring gumawa ng maraming virtual network access point, at mag-configure ng custom na access point policy para sa bawat access point, na nagbibigay ng ilang solusyon sa antas ng network scheduling para sa mga multi-tenant na sitwasyon.

Agent Wonderland

Ang isang ideal na developer ng Agent ay maaaring bumuo ng isang ganap na serverless na Agent batay sa "Agent SDK + storage + MaaS service" kapag nagde-develop ng AI Agent:

• Ang Agent ay maaaring tumakbo nang ganap na serverless

• Maaaring bumuo ng Agent sa pamamagitan ng pagsasama-sama ng mga kasalukuyang kakayahan ng produkto sa pamamagitan ng Vibe Coding

• Kailangan lamang na panatilihin ang python script ng "ADK"

• Gumagamit ng object storage para sa storage

• Gumagamit ng Doubao para sa AI capabilities

• Sa teorya, walang ECS o iba pang instance-type na produkto

Kasabay nito, kailangang magbigay ang storage ng mga sumusunod na kakayahan:

• Ang Agent ay maaaring magkaroon ng object semantics storage (pag-save ng mga file), na nagbibigay ng multi-tenant access capability, simula sa milyun-milyon, at maaaring palawakin sa daan-daang milyon

• Ang Agent ay maaaring magbigay ng hiwalay na espasyo para sa bawat user (sa pagitan ng maraming negosyo, maaaring magkapareho ang mga pangalan ng negosyo o uid)

• Maaaring direktang i-configure ng Agent ang bandwidth ng bawat user, at i-configure ang kabuuang limitasyon sa laki ng user object

• Maaaring mag-bill, mag-monitor, at mag-observe ang Agent batay sa user

• Maaaring i-configure ng Agent ang mga patakaran sa pag-access para sa mga file ng bawat user

Agent Bucket: Pag-inject ng "Native Multi-Tenant" Genes sa AI Agent

Upang ganap na malutas ang problemang ito, nagpanukala kami ng isang bagong object storage paradigm—Agent Bucket. Ang pangunahing inobasyon nito ay ang pagpapakilala ng isang bagong native resource level sa pagitan ng tradisyunal na "bucket" at "object": object collection.

Ang pangunahing ideya ng disenyo na ito ay napakasimple: tumugma sa isang eksklusibong ObjectSet para sa bawat end user mo. Maaari mong isipin ang ObjectSet bilang isang "data safe" o "cloud personal space" na ginawa para sa bawat user. Sa lohikal, ito ay kabilang sa iyong (developer) Bucket, ngunit sa pisikal at pamamahala, mayroon itong sariling independiyenteng "personality" at "lifecycle".Ang Agent Bucket ay sumusuporta sa 100 milyong ObjectSet bawat bucket, na nangangahulugang maaari mong pagsilbihan ang daan-daang milyong mga end-user nang madali, na parang ang bawat end-user ay 'naninirahan' sa kanilang sariling independiyenteng espasyo ng storage, nang hindi na kailangang mag-alala tungkol sa pamamahala ng multi-tenant storage.

Disenyo ng ObjectSet – Kakayahang Friendly sa Agent

Sa Agent Bucket, ang ObjectSet ay hindi lamang nagdaragdag ng isang antas, ngunit ginagawa rin nitong handa nang gamitin ang mga katutubong kakayahan ang mga pinakamahirap na pangangailangan sa mga multi-tenant na sitwasyon. Kapag ang pagmamay-ari ng data ay malinaw na naitakda sa antas ng ObjectSet, ang isang serye ng mga kakayahan na mahirap ipatupad sa nakaraan ay natural na lumilitaw.

• Katutubong Paghihiwalay: Sa antas ng ObjectSet, maaari kang magtakda ng mga independiyenteng QPS, limitasyon sa bandwidth, at quota ng kapasidad para sa bawat user. Ang karanasan ng mga nagbabayad na user ay maaaring garantisado, at ang abnormal na pag-uugali ng mga libreng user ay hindi makakaapekto sa iba. Ito ay tunay na paghihiwalay ng fault domain, na pumipigil sa 'mga kapitbahay' na makagambala sa isa't isa.

• Katutubong Pahintulot: Ang bawat ObjectSet ay maaaring magkaroon ng isang independiyenteng domain name. Nangangahulugan ito na maaari mong bigyan ang user A ng isang eksklusibong access address na user-a.yourapp.com, sa halip na ilantad ang domain name ng buong storage bucket. Ang mas matalinong disenyo ay ang 'dalawang kandado': Ang unang kandado ay ang pansamantalang access credential (STS) na inisyu ng cloud service provider, na kumokontrol sa mga pahintulot sa pag-access sa antas ng application; ang pangalawang kandado ay ang independiyenteng domain name ng ObjectSet, na nagla-lock ng mga kahilingan sa pag-access sa sariling data space ng user mula sa antas ng network. Lubos nitong pinapabuti ang seguridad ng data.

• Katutubong Pagsubaybay: Sa dashboard ng pagsubaybay, hindi mo na makikita ang pangkalahatang data ng buong bucket. Maaari mong i-decompose ang mga chart ng pagsubaybay sa pamamagitan ng ObjectSet, na malinaw na nakikita kung aling end-user ang gumagawa ng maraming pag-access, upang makagawa ng tumpak na mga desisyon sa pagpapatakbo at pag-optimize.

• Katutubong Pagbaba ng Kakayahan: Ang mga patakaran na maaari lamang itakda sa antas ng bucket sa nakaraan ay maaari na ngayong ibaba sa bawat user. Maaari kang magtakda ng iba't ibang lifecycle ng data para sa iba't ibang antas ng mga user, o gumamit ng iba't ibang mga encryption key para sa bawat ObjectSet, upang makamit ang mas pinong at mas ligtas na pamamahala ng data.

• Katutubong Pagsukat: Gusto mong malaman kung gaano karaming espasyo ng storage ang ginagamit ng bawat user? Gusto mong tumpak na hatiin ang mga gastos sa storage sa bawat user? Ngayon ay nagiging madali na. Awtomatikong istatistika ng Agent Bucket ang kapasidad at paggamit ng bawat ObjectSet para sa iyo, na ginagawang malinaw ang iyong pagsingil at pagbabahagi ng kita.

• Katutubong Pagsingil: Madaling maisasakatuparan ng mga developer ang pagbabahagi ng gastos, na tumpak na ibinabalik ang mga gastos na nabuo ng storage sa bawat end-user. Halimbawa, singilin ang iba't ibang bayad batay sa aktwal na proporsyon ng gastos na nabuo ng iba't ibang user na A, B, at C, na nagbibigay ng suporta sa data para sa komersyalisasyon ng Agent.

• Katutubong Limitasyon sa Kapasidad: Upang makontrol ang mga gastos sa pagpapatakbo ng Agent, maaari kang magtakda ng Quota (limitasyon sa kapasidad) para sa bawat ObjectSet. Kapag naabot na ang preset na halaga, lilimitahan ng system ang user na patuloy na gumawa ng mga bagong file, na pumipigil sa pang-aabuso sa mapagkukunan sa mga multi-tenant na sitwasyon mula sa pinagmulan.

• Katutubong Katalinuhan: Hinahayaan ng Agent Bucket ang Agent na lumabas sa tradisyonal na simpleng 'pag-access' ng file, na nagbibigay sa Object ng katutubong katalinuhan, na mas mahusay na sumusuporta sa one-stop na pag-develop ng Agent. Ang ObjectSet ay maaaring magbukas ng matalinong pag-index sa isang click, na nagbibigay sa Agent ng katutubong friendly na multi-modal na kakayahan sa pagtatanong, na pinapalitan ang mekanikal na operasyon ng tradisyonal na Object CRUD; sinusuportahan pa nito ang one-click na pagbubukas ng Agentself mode, na nag-uugnay sa mga vector, kaalaman, modelo, at prompt, na direktang naglalantad ng mga senaryo na sub-Agent function, na nagpapahintulot sa mga upper-layer na developer ng Agent na tumuon sa paglikha ng pangunahing workflow ng negosyo, na ganap na naglalabas ng kahusayan sa paggawa ng pera.

Mga Hamon sa Teknikal na Dulot ng Pagsabog ng Scale ng Aplikasyon

Sa pamamagitan ng pagpapakilala ng katutubong konsepto ng ObjectSet, nagbibigay ang Agent Bucket ng isang elegante at mahusay na paraan para sa mga developer ng application upang pamahalaan ang daan-daang milyong data ng end-user. Ang mga digital asset ng bawat user ay ligtas na nakaimbak sa kanilang eksklusibong ObjectSet, na natural na nagpapatupad ng paghihiwalay, pagsingil, at pamamahala ng quota.

Sa mabilis na paglawak ng scale ng application, ang pagiging kumplikado ng pamamahala, kahirapan sa paghihiwalay, at mga pisikal na bottleneck ng napakalaking Set ay lumilitaw nang sabay-sabay:

• Problema sa Pamamahala ng Graded ng Napakaraming User: Kapag ang application ay nangangailangan ng pagkakaiba-iba ng pamamahala ng malaking bilang ng iba't ibang antas ng mga mapagkukunan at katangian ng user, kailangang idisenyo at ipatupad ang sarili nitong graded metadata ng user, at iugnay ang mga switch ng tampok ng object storage. Ang pagtulong sa mga developer na eleganteng pamahalaan ang graded ng user sa katutubong konsepto ng Set ay mahalaga upang mapabilis ang pagpapatupad ng application.- Bottleneck ng kapasidad ng iisang cluster: Bagama't ang Agent Bucket ay maaaring walang limitasyong lumaki sa lohika, ang metadata nito ay naka-imbak bilang default sa isang solong pisikal na cluster. Kapag ang kabuuang bilang ng mga object sa loob ng bucket ay umabot sa daan-daang bilyon o kahit trilyon, ang pisikal na kapasidad ng isang solong cluster ay nagiging isang hindi malalampasang limitasyon.

• Isyu sa pagbabahagi ng access point: Ang pagkakaiba-iba ng negosyo ng Agent at ang napakaraming user ay nagdudulot ng mas malaking panganib sa seguridad at radius ng pagsabog sa mismong access point. Kung paano gumawa ng dynamic na pag-iiskedyul batay sa mga pagkakaiba sa pagitan ng maraming iba't ibang negosyo at user, at makamit ang pagkakaiba-iba sa seguridad, paghihiwalay, at kakayahan sa pagpapabilis ay nagiging isang hamon.

Set Tagging: Pamamahala ng User sa Pamamagitan ng Paglalagay ng Tag

Ang ObjectSet ay nagbibigay ng katutubong paraan ng pamamahala sa pamamagitan ng paglalagay ng tag, na nagpapahintulot sa mga developer ng Agent na madaling gamitin ang kakayahan ng set tagging upang kumpletuhin ang hierarchical na pamamahala ng mga user. Ang mga developer ay maaaring magtalaga ng isang tag sa bawat antas ng user na tinukoy, at paganahin ang iba't ibang quota at katangian para sa bawat tag. Lahat ng ObjectSet na may tag na ito ay maglalapat ng kaukulang quota at katangian. Gamitin ang V1, V2, at V3 bilang mga halimbawa upang ipaliwanag:

• V1: Default na antas, mga libreng user, ang default na tag para sa lahat ng ObjectSet, maaaring i-configure upang mag-imbak ng maximum na 1GiB ng data, ang pampublikong pamamahagi ng network ay hindi maaaring lumampas sa 100mbps bandwidth, at ang single-stream na bilis ng pag-download ay kinokontrol sa 1mbps;

• V2: Panimulang bayad na miyembro, i-configure upang mag-imbak ng maximum na 10GiB ng data, ang pampublikong pamamahagi ng network ay hindi maaaring lumampas sa 10gbps bandwidth, at ang single-stream na bilis ng pag-download ay kinokontrol sa 10mbps;

• V3: Advanced na bayad na miyembro, bukod sa pagbibigay ng mas malaking imbak at pampublikong quota ng pamamahagi ng network, sinusuportahan din nito ang pag-configure upang paganahin ang karagdagang pampublikong network na mahinang pagpapabilis ng network at mataas na pagganap na medium acceleration;

Ang mga developer ng Agent ay maaaring gamitin ang V1/V2/V3 tagging nang may kakayahang umangkop upang pamahalaan ang mga mapagkukunan at mga value-added na katangian na maaaring gamitin ng mga user na ito para sa iba't ibang yugto ng pag-unlad ng iba't ibang user.

Set Slice: Katutubong Paghihiwalay ng Napakaraming Data ng User

Kapag ang bilang ng Set sa loob ng isang Agent Bucket ay umabot sa daan-daang milyon, at ang bilang ng mga object ay umabot sa daan-daang bilyon o trilyon, ang katotohanan na "lahat ng metadata ng isang Bucket ay nakasentro sa isang KV cluster" mismo ay magdudulot ng dobleng panganib sa kapasidad at pagganap.

Ang Set Slice ay nagbibigay ng isang ideya ng "lohikal na hindi paghihiwalay, pisikal na paghihiwalay":

• Sa lohika, isa pa ring Agent Bucket ang pinamamahalaan mo.

• Sa pisikal, ayon sa saklaw ng Set at ang pangalan ng object sa loob ng Set, ang metadata ay nahahati sa maraming Slice (hiwa), at ang bawat Slice ay maaaring itago sa iba't ibang cluster. Ang maraming Set ay natural na nahihiwalay, at ang isang Set ay pahalang na pinalawak.

Ang Set Slice ay isang karagdagang extension at garantiya ng kakayahan ng ObjectSet. Sa ilalim, nalulutas nito ang problema ng walang limitasyong pagpapalawak ng pisikal na kapasidad, habang tinitiyak ang katatagan at pagkakapare-pareho ng modelo ng pamamahala ng ObjectSet sa itaas.

• Matatag na hangganan ng pamamahala: Kahit na ang data ng isang Agent Bucket ay sumasaklaw sa maraming pisikal na cluster, ang ObjectSet ay nananatiling ang tanging pangunahing yunit ng pahintulot, quota, pagsingil, at pagsubaybay. Ang mga patakaran na na-configure ng mga developer para sa ObjectSet (tulad ng kontrol sa pag-access, limitasyon sa kapasidad) ay awtomatikong magkakabisa sa lahat ng nauugnay na Slices, nang hindi kinakailangang mag-alala tungkol sa pamamahagi ng pinagbabatayan na data.

• Ang isang Set ay maaaring pahalang na palawakin: Kapag ang dami ng data ng isang ObjectSet ay mabilis na lumalaki, ang data nito ay natural na ipapamahagi sa maraming Slices. Sa pagpapalawak ng pangkalahatang cluster, ang kapasidad ng ObjectSet na ito ay lumalaki rin nang walang putol at pahalang. Hindi kailangang magsagawa ang mga developer ng anumang mapanirang operasyon tulad ng paghihiwalay o paglilipat sa ObjectSet mismo.

• Paghihiwalay ng mapagkukunan sa pagitan ng mga Set: Sa pamamagitan ng pamamahagi ng mga object ng iba't ibang saklaw sa iba't ibang pisikal na cluster, nakakamit ng SetSlice ang mas mataas na dimensyon ng paghihiwalay ng mapagkukunan. Kasama ng pamamahala ng quota ng ObjectSet, maaari nitong epektibong pigilan ang paglaki ng data ng isang "super-large" na ObjectSet mula sa pag-agaw ng lahat ng mapagkukunan ng isang solong cluster, na nakakaapekto sa katatagan ng iba pang ObjectSet, na ginagawang kontrolado ang pangkalahatang panganib sa kapasidad.- Lohikal na pagkakaisa at pagiging tugma: Para sa mga negosyo at developer, hindi mahalaga kung gaano karaming Slice ang nasa ilalim, ang kinakaharap nila ay isang lohikal na pinag-isang Agent Bucket. Ang lahat ng mga operasyon sa mga bucket, ObjectSet, at object ay nananatiling pareho, na nagpapatupad ng ganap na transparency ng pisikal na pagpapalawak sa mga upper-layer na application.\n\n## Set AccessPoint: Ihiwalay ang bawat pasukan ng gumagamit\n\Sinusuportahan ng Agent Bucket ang pagbubukas ng mga independiyenteng access point (independiyenteng mga domain name) para sa bawat ObjectSet, at nagpapalawak ng mga differentiated na seguridad, paghihiwalay, at mga kakayahan sa pagpapabilis sa mga access point. Kailangan ng system na suportahan ang mga independiyenteng pag-iskedyul ng access point sa antas ng bilyon at differentiated na mga kakayahan sa pagsasaayos.\n\nIndependiyenteng domain name ng pag-access {$apid}.tos-objectset-ap.volces.com: Dalawang antas ng proteksyon sa seguridad\n\n - Unang antas Obscurity (pagtatago): By User/ObjectSet independiyenteng subdomain, apid high-entropy hashing, napakababang posibilidad ng banggaan, imposibleng hulaan at isa-isahin ang mga partikular na pasukan ng user mula sa anggulo ng domain name ng pag-access;\n\n - Ikalawang antas Containment (paglalaman): Gumagamit ang mga developer ng Agent ng sts upang ipamahagi ang mga pahintulot sa pag-access sa antas ng ObjectSet. Kahit na ang sts ay tumagas, maaari nitong kontrolin ang saklaw ng pag-access nito sa loob ng limitadong panahon ng bisa ng isang partikular na ObjectSet;\n\nHeuristic scheduling system: Pagkalkula ng diskarte sa pag-iskedyul ng domain name sa antas ng bilyon\n\n - By user/ObjectSet: differentiated na diskarte sa pag-access ng tag\n\n - Awtomatikong ikinakalat ang maraming user/ObjectSet sa iba't ibang pampublikong pasukan sa network, at ang bilang ng mga user na apektado ng isang solong pagkabigo sa pasukan ay kontrolado\n\n - Buong rehiyon na nababaluktot na pag-iskedyul, awtomatikong nakumpleto ang pag-iimpake at paglilipat ng trapiko sa anumang solong pagkabigo/sobra ng pasukan\n\n - Pampublikong network na nagpapabilis sa mga user ng uri ng pamamahagi, nagmamarka ng pampublikong network na pagpapadala ng acceleration tag, awtomatikong nag-iiskedyul ng acceleration entrance\n\n - Pampublikong network na mga user na may panganib, nagmamarka ng panganib na tag, awtomatikong nag-iiskedyul ng pampublikong network na paghihiwalay ng pasukan, at binabawasan ang pampublikong network na bandwidth quota\n\n - Mga user ng uri ng cross-domain ng panloob na network, nagmamarka ng cross-domain tag, awtomatikong nag-iiskedyul ng panloob na network na espesyal na linya ng acceleration path\n\n - Lokal na accelerator user, nagmamarka ng accelerator tag, awtomatikong nag-mount ng lokal na accelerator\n\n\n\n## Mula sa mga katulong sa pagprograma hanggang sa AI cloud disk, ang walang limitasyong mga posibilidad ng Agent Bucket\n\nNagbibigay ang Agent Bucket ng kumpletong solusyon para sa Agent, at ang disenyo ng ObjectSet ay may higit pa sa mga application scenario. Madali itong mapapalawak sa lahat ng mga application na kailangang magbigay ng mga serbisyo sa napakaraming end user:\n\n - Repositoryo ng code: Sa nakaraan, kapag ang mga kumpanya o indibidwal ay nagho-host ng code sa cloud, madalas nilang kailanganing magtayo ng isang layer ng \ - Platform para sa pagho-host ng modelo: Sa mga sitwasyon ng pagho-host ng malalaking modelo, ang bawat modelo ay hindi lamang malaki ang sukat, ngunit maaari ring tumugma sa iba't ibang bersyon, timbang, at configuration ng inference. Ang paglikha ng ObjectSet para sa bawat modelo ay maaaring mag-package at mag-host ng mga timbang ng modelo, Tokenizer, mga configuration file, at mga kaugnay na data ng pagsusuri sa parehong espasyo. Maaaring magtakda ang panig ng operasyon at pagpapanatili ng mga differentiated na patakaran sa pag-encrypt, mga patakaran sa pag-backup, at kontrol sa bandwidth para sa iba't ibang modelo. Kasabay nito, sa pamamagitan ng katutubong kakayahan sa pagsukat, maaaring kalkulahin ang tunay na gastos sa paggamit ng bawat modelo, na nagbibigay ng batayan para sa pagsingil at pag-iskedyul ng mapagkukunan ayon sa dimensyon ng modelo.

  • Serbisyo ng Data SaaS: Ang mga platform ng pamamahagi ng data na nakaharap sa napakaraming end user ay madalas na kailangang kumonekta sa maraming provider ng data nang sabay. Kailangan nitong tiyakin na malinaw ang mga hangganan ng data ng bawat partido, at iwasan ang panganib sa pagganap ng "isang malaking bucket na humihila sa lahat pababa". Sa tulong ng Agent Bucket, maaaring magkaroon ang bawat provider ng data ng sarili nitong ObjectSet, na pinag-iisa ang pamamahala ng orihinal na data at mga resulta ng pagproseso. Pagkatapos, sa pamamagitan ng mga independiyenteng domain name at bandwidth, mga quota ng QPS, ang differentiated na serbisyo at limitasyon ng rate ay maaaring isagawa para sa iba't ibang provider, na nagpapatupad ng isang imprastraktura ng pamamahagi ng data na "isang platform, maraming provider, hiwalay sa isa't isa ngunit kontrolado ang pakikipagtulungan".

Reference:

• 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/