شرکتها به دنبال این هستند که به سرعت پتانسیل هوش مصنوعی مولد را با ارائه دسترسی به مدلهای پایه (FM) به خطوط مختلف کسبوکار (LOB) باز کنند. تیم های فناوری اطلاعات مسئول کمک به LOB در نوآوری با سرعت و چابکی هستند و در عین حال نظارت و نظارت متمرکز را ارائه می دهند. برای مثال، آنها ممکن است نیاز داشته باشند که استفاده از FMها را در بین تیمها، هزینههای استرداد وجه و قابلیت مشاهده برای مرکز هزینه مربوطه در LOB را ردیابی کنند. علاوه بر این، آنها ممکن است نیاز به تنظیم دسترسی به مدل های مختلف در هر تیم داشته باشند. به عنوان مثال، اگر فقط FM های خاصی ممکن است برای استفاده تایید شوند.
بستر آمازون یک سرویس کاملاً مدیریت شده است که انتخابی از مدلهای پایه با کارایی بالا را از شرکتهای پیشرو هوش مصنوعی مانند AI21 Labs، Anthropic، Cohere، Meta، Stability AI، و Amazon از طریق یک API، همراه با مجموعه وسیعی از قابلیتها برای ساخت هوش مصنوعی مولد ارائه میکند. برنامه های کاربردی با امنیت، حریم خصوصی و هوش مصنوعی مسئول. از آنجایی که Amazon Bedrock بدون سرور است، نیازی به مدیریت هیچ زیرساختی ندارید و میتوانید با استفاده از سرویسهای AWS که قبلاً با آنها آشنا هستید، قابلیتهای هوش مصنوعی مولد را به طور ایمن ادغام و در برنامههای خود مستقر کنید.
یک لایه نرمافزار به عنوان سرویس (SaaS) برای مدلهای پایه میتواند یک رابط ساده و سازگار برای کاربران نهایی فراهم کند، در حالی که مدیریت متمرکز دسترسی و مصرف را حفظ میکند. دروازههای API میتوانند اتصال آزاد بین مصرفکنندگان مدل و سرویس نقطه پایانی مدل و انعطافپذیری برای انطباق با مدلها، معماریها و روشهای فراخوانی در حال تغییر را فراهم کنند.
در این پست، ما به شما نشان می دهیم که چگونه یک لایه SaaS داخلی برای دسترسی به مدل های پایه با Amazon Bedrock در یک معماری چند مستاجر (تیم) بسازید. ما به طور خاص بر روی استفاده و ردیابی هزینه به ازای هر مستاجر و همچنین کنترل هایی مانند کاهش مصرف به ازای هر مستاجر تمرکز می کنیم. ما توضیح می دهیم که چگونه راه حل و برنامه های مصرف بستر آمازون به چارچوب کلی سفر SaaS نگاشت می شوند. کد راه حل و an کیت توسعه ابری AWS (AWS CDK) قالب در دسترس است مخزن GitHub.
چالش ها
یک مدیر پلت فرم هوش مصنوعی باید دسترسی استاندارد و آسان به FMها را برای چندین تیم توسعه فراهم کند.
در زیر برخی از چالشهای ایجاد دسترسی کنترل شده به مدلهای پایه آورده شده است:
- ردیابی هزینه و استفاده - هزینههای مستاجر و استفاده از مدلهای پایه را پیگیری و حسابرسی کنید و هزینههای بازپرداخت را به مراکز هزینه خاص ارائه دهید.
- کنترل بودجه و استفاده – مدیریت سهمیه API، بودجه و محدودیتهای استفاده برای استفاده مجاز از مدلهای پایه در یک فرکانس تعریف شده برای هر مستأجر
- کنترل دسترسی و حاکمیت مدل – تعریف کنترل های دسترسی برای مدل های مجاز لیست شده خاص به ازای هر مستاجر
- API استاندارد چند مستاجر - دسترسی مداوم به مدل های فونداسیون را با OpenAPI استانداردهای
- مدیریت متمرکز API – ارائه یک لایه واحد برای مدیریت کلیدهای API برای دسترسی به مدل ها
- نسخه های مدل و به روز رسانی - ارائه نسخه مدل جدید و به روز شده را مدیریت کنید
بررسی اجمالی راه حل
در این راه حل به الف اشاره می کنیم چند مستاجر رویکرد. آ مستاجر در اینجا می تواند از یک کاربر فردی، یک پروژه خاص، تیم یا حتی یک بخش کامل باشد. همانطور که در مورد رویکرد بحث می کنیم، از این اصطلاح استفاده می کنیم تیم، زیرا رایج ترین است. ما از کلیدهای API برای محدود کردن و نظارت بر دسترسی به API برای تیم ها استفاده می کنیم. به هر تیم یک کلید API برای دسترسی به FM ها اختصاص داده شده است. ممکن است مکانیسم های مختلف احراز هویت و مجوز کاربر در یک سازمان مستقر شود. برای سادگی، ما این موارد را در این راه حل نمی گنجانیم. همچنین می توانید ارائه دهندگان هویت موجود را با این راه حل ادغام کنید.
نمودار زیر معماری راه حل و اجزای کلیدی را خلاصه می کند. تیمهایی (مستاجر) که به مراکز هزینه جداگانه اختصاص داده شدهاند، FMهای آمازون Bedrock را از طریق یک سرویس API مصرف میکنند. برای ردیابی مصرف و هزینه هر تیم، راه حل دادهها را برای هر فراخوانی جداگانه، از جمله مدل فراخوانی شده، تعداد نشانهها برای مدلهای تولید متن، و ابعاد تصویر برای مدلهای چندوجهی ثبت میکند. علاوه بر این، فراخوانها را در هر مدل و هزینههای هر تیم جمعآوری میکند.
میتوانید با استفاده از AWS CDK راهحل را در حساب شخصی خود مستقر کنید. AWS CDK یک چارچوب توسعه نرم افزار منبع باز برای مدل سازی و ارائه منابع برنامه ابری شما با استفاده از زبان های برنامه نویسی آشنا است. کد AWS CDK در دسترس است مخزن GitHub.
در بخش های بعدی، اجزای کلیدی راه حل را با جزئیات بیشتری مورد بحث قرار می دهیم.
ثبت استفاده از مدل پایه در هر تیم
گردش کار برای گرفتن استفاده از FM برای هر تیم شامل مراحل زیر است (همانطور که در نمودار قبل شماره گذاری شده است):
- برنامه یک تیم یک درخواست POST را به دروازه API آمازون با مدلی که باید در آن فراخوانی شود
model_id
پارامتر query و درخواست کاربر در بدنه درخواست. - API Gateway درخواست را به یک مسیر می دهد AWS لامبدا تابع (
bedrock_invoke_model
) که مسئول ثبت اطلاعات استفاده از تیم است CloudWatch آمازون و با استناد به مدل آمازون بستر. - Amazon Bedrock یک نقطه پایانی VPC ارائه می دهد که توسط AWS PrivateLink. در این راه حل، تابع Lambda با استفاده از PrivateLink درخواست را به Amazon Bedrock ارسال می کند تا یک ارتباط خصوصی بین VPC در حساب شما و حساب سرویس Amazon Bedrock برقرار کند. برای کسب اطلاعات بیشتر در مورد PrivateLink، مراجعه کنید از AWS PrivateLink برای تنظیم دسترسی خصوصی به Amazon Bedrock استفاده کنید.
- پس از فراخوان Amazon Bedrock، Amazon CloudTrail تولید می کند رویداد CloudTrail.
- اگر فراخوانی Amazon Bedrock موفقیت آمیز باشد، تابع Lambda اطلاعات زیر را بسته به نوع مدل فراخوانی شده ثبت می کند و پاسخ تولید شده را به برنامه برمی گرداند:
- team_id - شناسه منحصر به فرد برای تیم صادر کننده درخواست.
- درخواست شناسه - شناسه منحصر به فرد درخواست.
- مدل_id – شناسه مدلی که باید فراخوانی شود.
- توکن های ورودی – تعداد توکن های ارسال شده به مدل به عنوان بخشی از اعلان (برای مدل های تولید متن و جاسازی).
- خروجی توکن ها – حداکثر تعداد نشانه هایی که باید توسط مدل تولید شود (برای مدل های تولید متن).
- ارتفاع – ارتفاع تصویر درخواستی (برای مدل های چند وجهی و مدل های تعبیه چند وجهی).
- عرض – عرض تصویر درخواستی (فقط برای مدل های چند وجهی).
- مراحل – مراحل درخواست شده (برای مدل های هوش مصنوعی پایداری).
هزینه های پیگیری برای هر تیم
یک جریان متفاوت اطلاعات استفاده را جمع آوری می کند، سپس هزینه های درخواستی هر تیم را به صورت روزانه محاسبه و ذخیره می کند. با داشتن یک جریان جداگانه، اطمینان حاصل می کنیم که ردیابی هزینه بر تأخیر و توان عملیاتی جریان فراخوانی مدل تأثیر نمی گذارد. مراحل گردش کار به شرح زیر است:
- An پل رویداد آمازون قانون یک تابع لامبدا را راه اندازی می کند (
bedrock_cost_tracking
) روزانه. - تابع Lambda اطلاعات استفاده از CloudWatch را برای روز قبل دریافت می کند، هزینه های مربوطه را محاسبه می کند و داده های جمع آوری شده توسط
team_id
وmodel_id
in سرویس ذخیره سازی ساده آمازون (Amazon S3) با فرمت CSV.
برای پرس و جو و تجسم داده های ذخیره شده در آمازون S3، گزینه های مختلفی از جمله S3 را انتخاب کنیدو Amazon Athena و Amazon QuickSight.
کنترل استفاده در هر تیم
یک برنامه استفاده مشخص می کند که چه کسی می تواند به یک یا چند API مستقر شده دسترسی داشته باشد و به صورت اختیاری نرخ درخواست هدف را برای شروع کاهش درخواست ها تنظیم می کند. این طرح از کلیدهای API برای شناسایی مشتریان API استفاده می کند که می توانند به API مرتبط برای هر کلید دسترسی داشته باشند. می توانید از API Gateway استفاده کنید برنامه های استفاده برای دریچه گاز درخواست هایی که از آستانه های از پیش تعریف شده فراتر می روند. همچنین می توانید استفاده کنید کلیدهای API و محدودیتهای سهمیه، که به شما امکان میدهد حداکثر تعداد درخواستها را برای هر کلید API تنظیم کنید که هر تیم مجاز است در یک بازه زمانی مشخص صادر کند. این علاوه بر سهمیه خدمات بستر آمازون که فقط در سطح حساب اختصاص داده می شوند.
پیش نیازها
قبل از استقرار راه حل، مطمئن شوید که موارد زیر را دارید:
پشته AWS CDK را مستقر کنید
دستورالعمل های موجود در README فایل مخزن GitHub برای پیکربندی و استقرار پشته AWS CDK.
پشته منابع زیر را مستقر می کند:
- محیط شبکه خصوصی (VPC، زیرشبکه های خصوصی، گروه امنیتی)
- نقش IAM برای کنترل دسترسی مدل
- لایه های لامبدا برای ماژول های ضروری پایتون
- تابع لامبدا
invoke_model
- تابع لامبدا
list_foundation_models
- تابع لامبدا
cost_tracking
- Rest API (Gateway API)
- برنامه استفاده از دروازه API
- کلید API مرتبط با طرح استفاده
سوار یک تیم جدید
برای دسترسی به تیمهای جدید، میتوانید کلید API یکسانی را بین تیمهای مختلف به اشتراک بگذارید و مصرف مدل را با ارائه یک کلید متفاوت دنبال کنید. team_id
برای فراخوانی API، یا ایجاد کلیدهای اختصاصی API مورد استفاده برای دسترسی به منابع Amazon Bedrock با پیروی از دستورالعمل های ارائه شده در README.
پشته منابع زیر را مستقر می کند:
- طرح استفاده از دروازه API مرتبط با REST API ایجاد شده قبلی
- کلید API مرتبط با برنامه استفاده برای تیم جدید، با پیکربندیهای throttling و burst رزرو شده برای API
برای اطلاعات بیشتر در مورد تنظیمات throttling و Burst Gateway API، مراجعه کنید درخواست API دریچه گاز برای خروجی بهتر.
پس از استقرار پشته، می توانید ببینید که کلید API جدید برای team-2
نیز ایجاد می شود.
کنترل دسترسی مدل را پیکربندی کنید
مدیر پلت فرم میتواند با ویرایش خطمشی IAM مرتبط با تابع Lambda، دسترسی به مدلهای پایه خاص را مجاز کند. invoke_model
.
مجوزهای IAM در فایل تعریف شده است setup/stack_constructs/iam.py. کد زیر را ببینید:
سرویس را فراخوانی کنید
پس از استقرار راه حل، می توانید سرویس را مستقیماً از کد خود فراخوانی کنید. به شرح زیر
نمونه ای در پایتون برای مصرف است invoke_model
API برای تولید متن از طریق درخواست POST:
خروجی: Amazon Bedrock یک پلتفرم فناوری داخلی است که توسط آمازون توسعه یافته است تا بسیاری از خدمات و محصولات خود را اجرا و اجرا کند. چند نکته کلیدی درباره بستر…
در زیر مثال دیگری در پایتون برای مصرف است invoke_model
API برای ایجاد جاسازی از طریق درخواست POST:
model_id = "amazon.titan-embed-text-v1" #the model id for the Amazon Titan Embeddings Text model prompt = "What is Amazon Bedrock?" response = requests.post( f"{api_url}/invoke_model?model_id={model_id}", json={"inputs": prompt, "parameters": model_kwargs}, headers={ "x-api-key": api_key, #key for querying the API "team_id": team_id #unique tenant identifier, "embeddings": "true" #boolean value for the embeddings model }
) text = response.json()[0]["embedding"]
خروجی: 0.91796875، 0.45117188، 0.52734375، -0.18652344، 0.06982422، 0.65234375، -0.13085938، 0.056884766، 0.092285156. , 0.06982422، 1.03125، 0.8515625، 0.16308594، -0.079589844، 0.033935547، -0.796875، -0.15429688، 0.29882812، 0.25585938، -0.45703125، 0.044921875، -0.34570312. XNUMX، XNUMX …
دسترسی به مدل های پایه ممنوع است
در زیر یک مثال در پایتون برای مصرف است invoke_model
API برای تولید متن از طریق درخواست POST با پاسخ رد شده از دسترسی:
«ردیابی (آخرین تماس اخیر): n فایل «/var/task/index.py»، خط 213، در پاسخ lambda_handlern = _invoke_text(bedrock_client, model_id, body, model_kwargs)n File ”/var/task/index.py "، خط 146، در _invoke_textn raise en File "/var/task/index.py"، خط 131، در _invoke_textn answer = bedrock_client.invoke_model(n File "/opt/python/botocore/client.py"، خط 535، در _api_calln بازگشت self._make_api_call(operation_name, kwargs)n فایل ”/opt/python/botocore/client.py”، خط 980، در _make_api_calln افزایش error_class(parsed_response, operation_name)nbotocore.xAceptiony:enied هنگام فراخوانی عملیات InvokeModel خطایی روی داد (AccessDeniedException): حساب شما مجاز به فراخوانی این عملیات API نیست.n"
مثال برآورد هزینه
هنگام فراخوانی مدلهای بستر آمازون با قیمتگذاری بر اساس تقاضا، هزینه کل به عنوان مجموع هزینههای ورودی و خروجی محاسبه میشود. هزینه های ورودی بر اساس تعداد توکن های ورودی ارسال شده به مدل و هزینه های خروجی بر اساس توکن های تولید شده است. قیمت ها به ازای هر 1,000 توکن ورودی و هر 1,000 توکن خروجی است. برای جزئیات بیشتر و قیمت مدل های خاص به ادامه مطلب مراجعه کنید قیمت گذاری سنگ بستر آمازون.
بیایید به مثالی نگاه کنیم که در آن دو تیم، team1 و team2، از طریق راه حل در این پست به Amazon Bedrock دسترسی دارند. داده های استفاده و هزینه ذخیره شده در آمازون S3 در یک روز در جدول زیر نشان داده شده است.
ستون ها input_tokens
و output_tokens
کل توکن های ورودی و خروجی را در فراخوانی های مدل در هر مدل و هر تیم به ترتیب برای یک روز معین ذخیره کنید.
ستون ها input_cost
و output_cost
هزینه های مربوطه را برای هر مدل و هر تیم ذخیره کنید. با استفاده از فرمول های زیر محاسبه می شود:
input_cost = input_token_count * model_pricing["input_cost"] / 1000
output_cost = output_token_count * model_pricing["output_cost"] / 1000
team_id | مدل_id | input_tokens | output_tokens | استناد | ورودی_هزینه | خروجی_هزینه |
Team1 | amazon.titan-tg1-large | 24000 | 2473 | 1000 | 0.0072 | 0.00099 |
Team1 | anthropic.claude-v2 | 2448 | 4800 | 24 | 0.02698 | 0.15686 |
Team2 | amazon.titan-tg1-large | 35000 | 52500 | 350 | 0.0105 | 0.021 |
Team2 | ai21.j2-grande-instruct | 4590 | 9000 | 45 | 0.05738 | 0.1125 |
Team2 | anthropic.claude-v2 | 1080 | 4400 | 20 | 0.0119 | 0.14379 |
نمای سرتاسر یک محیط SaaS بدون سرور چند مستاجر کاربردی
بیایید درک کنیم که یک محیط SaaS بدون سرور چند مستاجر عملکردی سرتاسر ممکن است چگونه باشد. در زیر نمودار معماری مرجع است.
این نمودار معماری یک نسخه کوچک شده از نمودار معماری قبلی است که قبلا در پست توضیح داده شد، جایی که نمودار معماری قبلی جزئیات یکی از ریزسرویس های ذکر شده (سرویس مدل پایه) را توضیح می دهد. این نمودار توضیح می دهد که به غیر از خدمات مدل پایه، شما باید اجزای دیگری را نیز در پلتفرم SaaS چند مستاجر خود داشته باشید تا یک پلت فرم کاربردی و مقیاس پذیر را پیاده سازی کنید.
بیایید جزئیات معماری را مرور کنیم.
درخواست های مستاجر
برنامه های مستاجر، برنامه های کاربردی جلویی هستند که با محیط تعامل دارند. در اینجا، چندین مستأجر را نشان میدهیم که از محیطهای مختلف محلی یا AWS دسترسی دارند. برنامه های کاربردی جلویی را می توان گسترش داد تا شامل یک صفحه ثبت نام برای مستاجران جدید برای ثبت نام خود و یک کنسول مدیریت برای مدیران لایه سرویس SaaS باشد. اگر برنامههای مستاجر نیاز به یک منطق سفارشی برای پیادهسازی داشته باشند که نیاز به تعامل با محیط SaaS دارد، میتوانند مشخصات میکروسرویس آداپتور برنامه را پیادهسازی کنند. سناریوهای مثال می تواند اضافه کردن منطق مجوز سفارشی در عین رعایت مشخصات مجوز محیط SaaS باشد.
خدمات به اشتراک گذاشته شده
خدمات مشترک زیر هستند:
- خدمات مدیریت مستاجر و کاربر – این خدمات وظیفه ثبت و مدیریت مستاجرین را بر عهده دارند. آنها عملکرد مقطعی را ارائه می دهند که جدا از خدمات برنامه است و در بین تمام مستاجرین به اشتراک گذاشته شده است.
- سرویس مدل فونداسیون – نمودار معماری راه حل توضیح داده شده در ابتدای این پست نشان دهنده این میکروسرویس است، جایی که تعامل از دروازه API به توابع لامبدا در محدوده این میکروسرویس انجام می شود. همه مستاجران از این میکروسرویس برای فراخوانی مدل های پایه از Anthropic، AI21، Cohere، Stability، Meta، و Amazon و همچنین مدل های دقیق استفاده می کنند. همچنین اطلاعات مورد نیاز برای ردیابی استفاده را در گزارشهای CloudWatch میگیرد.
- خدمات ردیابی هزینه - این سرویس هزینه و استفاده را برای هر مستاجر پیگیری می کند. این میکروسرویس بر اساس برنامهای اجرا میشود تا گزارشهای CloudWatch را پرس و جو کند و ردیابی مصرف جمعآوری شده و هزینه استنباطشده برای ذخیرهسازی داده را خروجی دهد. خدمات ردیابی هزینه را می توان برای ایجاد گزارش ها و تجسم بیشتر گسترش داد.
خدمات آداپتور برنامه
این سرویس مجموعهای از مشخصات و APIهایی را ارائه میکند که مستاجر ممکن است برای ادغام منطق سفارشی خود با محیط SaaS پیادهسازی کند. بر اساس میزان ادغام سفارشی مورد نیاز، این جزء می تواند برای مستاجران اختیاری باشد.
فروشگاه داده چند مستاجر
سرویسهای مشترک دادههای خود را در یک فروشگاه داده ذخیره میکنند که میتواند یک اشتراکگذاری شده باشد آمازون DynamoDB جدول با یک کلید پارتیشن بندی مستاجر که آیتم های DynamoDB را با مستاجران فردی مرتبط می کند. سرویس مشترک ردیابی هزینه، دادههای استفاده و ردیابی هزینه جمعآوری شده را به Amazon S3 خروجی میدهد. بر اساس موارد استفاده، میتواند یک ذخیرهسازی داده خاص برنامه نیز وجود داشته باشد.
یک محیط SaaS چند مستاجر می تواند اجزای بسیار بیشتری داشته باشد. برای اطلاعات بیشتر مراجعه کنید ساخت راه حل SaaS چند مستاجر با استفاده از خدمات بدون سرور AWS.
پشتیبانی از چندین مدل استقرار
چارچوبهای SaaS معمولاً دو مدل استقرار را ترسیم میکنند: استخر و سیلو. برای مدل استخر، همه مستاجران از یک محیط مشترک با زیرساخت های ذخیره سازی و محاسباتی مشترک به FM ها دسترسی دارند. در مدل سیلو، هر مستاجر مجموعه ای از منابع اختصاصی خود را دارد. میتوانید در مورد مدلهای جداسازی مطالعه کنید مقاله راهبردهای جداسازی مستاجر SaaS.
راه حل پیشنهادی می تواند برای هر دو مدل استقرار SaaS مورد استفاده قرار گیرد. در رویکرد استخر، یک محیط AWS متمرکز میزبان API، ذخیره سازی و منابع محاسباتی است. در حالت سیلو، هر تیم به APIها، ذخیره سازی و منابع محاسباتی در یک محیط اختصاصی AWS دسترسی دارد.
این راه حل همچنین با برنامه های مصرف موجود ارائه شده توسط Amazon Bedrock مطابقت دارد. AWS انتخابی از دو طرح مصرف را برای استنتاج ارائه می دهد:
- بر روی تقاضا - این حالت به شما امکان می دهد از مدل های پایه به صورت پرداختی و بدون نیاز به تعهدات مدت زمان بر استفاده کنید.
- توان عملیاتی تامین شده - این حالت به شما امکان می دهد تا در ازای تعهد مدت زمان، توان عملیاتی کافی برای برآورده کردن الزامات عملکرد برنامه خود را فراهم کنید.
برای اطلاعات بیشتر در مورد این گزینه ها به ادامه مطلب مراجعه کنید قیمت گذاری سنگ بستر آمازون.
راهحل مرجع بدون سرور SaaS که در این پست توضیح داده شده است، میتواند برنامههای مصرف Amazon Bedrock را برای ارائه گزینههای درجه بندی اولیه و ممتاز به کاربران نهایی اعمال کند. Basic می تواند شامل مصرف On-Demand یا Provisioned Throughput Amazon Bedrock باشد و می تواند شامل محدودیت های استفاده و بودجه خاص باشد. محدودیتهای مستاجر را میتوان با محدود کردن درخواستها بر اساس درخواستها، اندازه توکن یا تخصیص بودجه فعال کرد. مستاجران درجه ممتاز می توانند منابع اختصاصی خود را با مصرف توان عملیاتی تدارکاتی Amazon Bedrock داشته باشند. این مستاجران معمولاً با بارهای کاری تولیدی مرتبط هستند که به توان عملیاتی بالا و دسترسی با تأخیر کم به FM های آمازون بستر نیاز دارند.
نتیجه
در این پست، نحوه ساخت یک پلتفرم SaaS داخلی برای دسترسی به مدلهای پایه با Amazon Bedrock در یک راهاندازی چند مستاجر با تمرکز بر ردیابی هزینهها و استفاده و محدودیتهای کاهش فشار برای هر مستأجر بحث کردیم. موضوعات اضافی برای بررسی عبارتند از ادغام راه حل های احراز هویت و مجوز موجود در سازمان، تقویت لایه API برای گنجاندن سوکت های وب برای تعاملات دو طرفه سرور مشتری، افزودن فیلتر محتوا و سایر حفاظ های حاکمیتی، طراحی لایه های چندگانه استقرار، ادغام سایر میکروسرویس ها در SaaS. معماری، و بسیاری دیگر.
کل کد این راه حل در موجود است مخزن GitHub.
برای اطلاعات بیشتر در مورد چارچوب های مبتنی بر SaaS، مراجعه کنید SaaS Journey Framework: ایجاد یک راه حل جدید SaaS در AWS.
درباره نویسنده
حسن پوناوالا یک معمار ارشد راه حل های تخصصی AI/ML در AWS است که با مشتریان Healthcare و Life Sciences کار می کند. حسن به طراحی، استقرار و مقیاسبندی برنامههای کاربردی هوش مصنوعی و یادگیری ماشینی در AWS کمک میکند. او بیش از 15 سال تجربه کاری ترکیبی در یادگیری ماشین، توسعه نرم افزار و علم داده در فضای ابری دارد. حسن در اوقات فراغت خود عاشق گشت و گذار در طبیعت و گذراندن وقت با دوستان و خانواده است.
آناستازیا تزولکا یک معمار ارشد راه حل های تخصصی AI/ML در AWS است. به عنوان بخشی از کار خود، او به مشتریان در سراسر EMEA کمک می کند تا مدل های پایه بسازند و راه حل های مقیاس پذیر هوش مصنوعی و یادگیری ماشینی را با استفاده از خدمات AWS ایجاد کنند.
برو کشتینه پیستون یک معمار راه حل های تخصصی هوش مصنوعی و ML برای AWS مستقر در میلان است. او با مشتریان بزرگ کار می کند و به آنها کمک می کند تا نیازهای فنی خود را عمیقاً درک کنند و راه حل های هوش مصنوعی و یادگیری ماشینی را طراحی کنند که بهترین استفاده را از AWS Cloud و پشته یادگیری ماشینی آمازون می کند. تخصص او عبارتند از: یادگیری ماشینی، صنعتی سازی یادگیری ماشین، و هوش مصنوعی مولد. او از گذراندن وقت با دوستانش و کشف مکان های جدید و همچنین سفر به مقاصد جدید لذت می برد.
ویکش پاندی معمار راه حل های AI/ML مولد است و در خدمات مالی متخصص است که در آن به مشتریان مالی کمک می کند تا پلتفرم ها و راه حل های AI/ML مولد را بسازند و مقیاس کنند که به صدها تا حتی هزاران کاربر می رسد. ویکش در اوقات فراغت خود دوست دارد در انجمن های مختلف وبلاگ بنویسد و با بچه اش لگو بسازد.
- محتوای مبتنی بر SEO و توزیع روابط عمومی. امروز تقویت شوید.
- PlatoData.Network Vertical Generative Ai. به خودت قدرت بده دسترسی به اینجا.
- PlatoAiStream. هوش وب 3 دانش تقویت شده دسترسی به اینجا.
- PlatoESG. کربن ، CleanTech، انرژی، محیط، خورشیدی، مدیریت پسماند دسترسی به اینجا.
- PlatoHealth. هوش بیوتکنولوژی و آزمایشات بالینی. دسترسی به اینجا.
- منبع: https://aws.amazon.com/blogs/machine-learning/build-an-internal-saas-service-with-cost-and-usage-tracking-for-foundation-models-on-amazon-bedrock/