AWS Media внедрява Bedrock AI за фен ангажираност

Разходи за Bedrock и работни потоци на агенти

Резюме

Две референтни архитектури на AWS Media илюстрират различни оперативни приоритети: оптимизирана за разходи стрийминг инфраструктура и агентен AI спътник за спортни фенове. Едната се фокусира върху FinOps контроли в compute, storage, мрежи, observability и оркестрация на работни потоци. Другата описва многоагентна система text-to-SQL, изградена върху Amazon Bedrock и Amazon Athena върху таблици Apache Iceberg, с real-time ingest и контроли за безопасност чрез Amazon Bedrock Guardrails.

Ключови индустриални развития

• FinOps модели за стрийминг натоварвания в AWS
• Bedrock Streaming прилага многоосна стратегия за разходи, която включва Amazon EC2 Spot Instances за Kubernetes worker nodes, процесори AWS Graviton, рационализиране на API повикванията и внимание към жизнения цикъл на storage.
• Production Kubernetes worker nodes работят на EC2 Spot Instances с автоматичен failover към on-demand инстанции, когато Spot капацитетът е ограничен.
• Платформата използва instance reservations за managed services, включително Amazon RDS, Amazon ElastiCache и Amazon OpenSearch Service, и използва capacity reservations за Amazon DynamoDB.
• Контроли на разходите за storage, registry и задържане на данни
• Amazon S3 се използва като основа за хостване на видео библиотека, със S3 storage classes, политики за автоматичен преход, Intelligent-Tiering и lifecycle management.
• Ръстът на разходите в Amazon ECR от натрупани Docker images се адресира чрез включване на автоматично изчистване на стари images.
• DynamoDB time to live (TTL) се използва за автоматично изтичане на остарели данни, намалявайки разходите за storage и backup.
• Техники за оптимизация на мрежа, пренос на данни и разходи за API
• VPC endpoints за Amazon S3 и Amazon DynamoDB се използват за елиминиране на транзитните разходи през AWS Network Address Translation (NAT) Gateway.
• Обработката на video-on-demand е преработена така, че всяка заявка да остава в своята входна Availability Zone, елиминирайки разходите за трансфер между Availability Zone.
• Разходите за S3 API се намаляват чрез добавяне на cache и оптимизиране на API повикванията, включително премахване на излишни проверки за съществуване и внедряване на обработка на 404.
• Инженеринг на разходите за observability и работни потоци
• CloudWatch metrics се експортират към Prometheus, а събираните metrics се рационализират, за да се намалят разходите за CloudWatch API повиквания 2.5 пъти.
• Amazon CloudWatch Logs Infrequent Access се използва за логове, изискващи удължено задържане, за да се намалят разходите за ingest и storage.
• AWS Step Functions express mode е избран вместо standard mode, за да се намалят разходите за проект за работни потоци.
• Обработката на съобщения в Amazon SQS е оптимизирана чрез batch processing, включително batch deletion, което намалява разходите за операции по изтриване с 66%.
• Архитектурни модели за агентен AI за приложения, насочени към фенове
• Captain на Bundesliga е агентен AI спътник, вграден в официалното приложение на Bundesliga.
• Услугата, базирана на чат, използва работен поток text-to-SQL: LLM преобразува въпросите в заявки, изпълнявани от Amazon Athena срещу статистически данни, съхранявани в Amazon S3 Tables.
• Въпросите се класифицират по тип и сложност с Amazon Nova 2 Lite, след което се маршрутизират към Amazon Nova Pro или Claude Sonnet 4 в Amazon Bedrock.
• Research услугата е реализирана като автономен агентен цикъл с Strands Agents SDK с Amazon Bedrock и е проектирана да работи върху Amazon Bedrock AgentCore.

Реални случаи на употреба

• Автоматично мащабиране на стрийминг инфраструктура със Spot капацитет и по-бърз старт на инстанции
• Bedrock Streaming изпълнява Kubernetes worker nodes 100% на EC2 Spot Instances и използва автоматичен failover към on-demand инстанции при ограничен Spot капацитет.
• Използват се custom Amazon Machine Images (AMIs) за намаляване на времето за стартиране на нови инстанции, а внедряването използва повече от 10 типа инстанции в три Availability Zones.
• End-to-end контроли на разходите за storage, опашки и бази данни
• Съхранението на видео библиотеката в Amazon S3 използва storage classes, Intelligent-Tiering и lifecycle management за управление на дългоживеещо съдържание.
• DynamoDB TTL автоматично изтича остарели записи, намалявайки разходите за storage и backup, а режимът на капацитет се оценява за всяка таблица, включително миграции от on-demand към provisioned режим след наблюдение.
• Amazon SQS batch processing намалява оперативния overhead, включително 66% намаление на разходите за операции по изтриване чрез batch deletion.
• Намаляване на мрежовия и API overhead по пътища с голям обем заявки
• VPC endpoints за S3 и DynamoDB премахват NAT Gateway транзитните такси за трафик, който иначе би преминал през NAT.
• Обработката на video-on-demand задържа заявките в входната Availability Zone, за да се избегнат такси за трансфер между Availability Zone.
• API за изтегляне на изображения намалява разходите за S3 API чрез добавяне на caching и оптимизиране на шаблоните на заявките (включително премахване на излишни проверки за съществуване и внедряване на обработка на 404).
• Многоагентен асистент за фенове с управляван text-to-SQL и real-time ingest
• Captain използва многоагентна архитектура, която включва Router Agent, Stats Agent и Video Agent за обработка на различни типове въпроси, включително заявки, свързани с видео.
• Основата за данните използва Amazon S3 Tables във формат Apache Iceberg, с Amazon Athena като serverless query engine.
• Real-time ingest използва Amazon Managed Streaming for Apache Kafka (Amazon MSK), AWS Lambda и Amazon Data Firehose, като metadata се регистрира в AWS Glue Data Catalog.
• Amazon Bedrock Guardrails се използват за филтриране на входа (включително блокиране на опити за prompt injection, неподходящо съдържание и заявки извън темата) и за проверки за grounding на изхода.

Защо е важно

• Резултатите по разходите зависят от инженерни избори на множество слоеве
• Примерът с Bedrock Streaming свързва контрола на разходите с конкретни механизми: Spot капацитет с failover, reservations за managed services, планиране на капацитета на DynamoDB и управление на storage на база lifecycle.
• Изборите в мрежовата архитектура (VPC endpoints, обработка, локализирана по Availability Zone) се третират като директни лостове за намаляване на разходите за NAT и трансфер между Availability Zone.
• Оперативната телеметрия може да бъде измерим двигател на разходи
• Експортирането на CloudWatch metrics към Prometheus и съгласуването на събираните metrics с използваните в Grafana намалява разходите за CloudWatch API повиквания 2.5 пъти, показвайки, че изборът на metrics и работните потоци за събиране влияят върху разходите.
• Стратегията за задържане на логове (CloudWatch Logs Infrequent Access) се използва като конкретен контрол за изисквания за удължено задържане.
• Агентните AI системи печелят от изрично маршрутизиране, структурирано заявяване и guardrails
• Работният поток на Captain комбинира класификация (Amazon Nova 2 Lite), маршрутизиране на модели (Amazon Nova Pro или Claude Sonnet 4) и изпълнение text-to-SQL (Athena върху S3 Tables), за да произвежда отговори, базирани на данни.
• Guardrails се прилагат както преди генериране (филтриране на входа), така и след генериране (проверки за grounding на изхода), осигурявайки дефиниран работен поток за безопасност и контрол на качеството за чат-базиран асистент.

Източници

• https://aws.amazon.com/blogs/media/how-bedrock-streaming-optimizes-its-aws-costs/
• https://aws.amazon.com/blogs/media/how-bundesliga-built-captain-an-ai-agent-for-fans-using-amazon-bedrock/