Quản lý chi phí cho Generative AI là trách nhiệm chung giữa các nhóm xây dựng ứng dụng và các nhóm chịu trách nhiệm chi tiêu cho đám mây. Nhiều nhóm bắt đầu bằng cách so sánh tỷ lệ mã thông báo trên mỗi mô hình và yêu cầu nhóm ứng dụng rút ngắn lời nhắc. Những bước đó có ích nhưng không trả lời các câu hỏi mà các nhà lãnh đạo tài chính và kỹ thuật đặt ra như quy mô sử dụng: nhóm nào đã chi tiêu khoản này, cho khối lượng công việc nào và khoản chi tiêu đó có nằm trong ngân sách được phê duyệt không? Khối lượng công việc đại lý làm cho những câu hỏi đó trở nên cấp bách hơn. Trợ lý đàm thoại thường đưa ra một lệnh gọi mô hình cho mỗi lượt người dùng. Một quy trình làm việc tác nhân, chẳng hạn như trợ lý mã hóa AI lên kế hoạch thay đổi, đọc tệp, gọi công cụ và lặp lại, đưa ra nhiều lệnh gọi cho mỗi tác vụ và mang bối cảnh lớn hơn cho mỗi tác vụ. Do đó, mức tiêu thụ mã thông báo sẽ tăng theo mức độ tự chủ mà bạn cấp cho quy trình làm việc và quy mô của bối cảnh mà nó mang theo, thay vì theo số lượng tương tác của người dùng. Bởi vì mức tiêu thụ là một chức năng của cách khối lượng công việc được thiết kế và vận hành nên việc quản lý chi phí cho AI tạo ra là một nguyên tắc kiến ​​trúc và vận hành. Số liệu trung bình đã công bố không thể thay thế tốt cho số liệu của chính bạn: sử dụng Công cụ tính giá AWS và trang định giá Amazon Bedrock để lập mô hình giá và sử dụng Bước 2 của bài đăng này để đo lường khối lượng công việc của bạn thực sự tiêu thụ. Cách khắc phục không phải là mẫu rẻ hơn hoặc lời nhắc nhỏ hơn. Đó là một mô hình hoạt động: một vòng lặp có thể lặp lại, phân bổ từng đô la cho chủ sở hữu, khiến mọi yêu cầu đều có thể được quan sát, cảnh báo và thực thi ngân sách trước khi chi tiêu quá mức, tối ưu hóa các giá trị mặc định của nền tảng gây lãng phí nhiều nhất và xem xét toàn bộ hệ thống theo nhịp độ. Trong bài đăng này, bạn tìm hiểu cách quản lý chi phí Amazon Bedrock theo năm bước. Bạn quy mỗi đô la cho chủ sở hữu, thực hiện mọi yêu cầu có thể quan sát được, kiểm soát chi tiêu bằng ngân sách và việc thực thi, tối ưu hóa các giá trị mặc định của nền tảng nhằm thúc đẩy mức chi tiêu có thể tránh được nhất và vận hành nhịp đánh giá để biến dữ liệu thành quyết định. Cách tiếp cận này được xây dựng từ AWS các khối xây dựng và bạn có thể tùy chỉnh nó và áp dụng nó vào môi trường của riêng bạn. Bài đăng này được viết cho hai đối tượng: những người thực hành FinOps sở hữu phân bổ, yêu cầu bồi hoàn, ngân sách và đánh giá bất thường, cũng như các nhóm kỹ thuật nền tảng sở hữu ghi nhật ký, yêu cầu siêu dữ liệu, thực thi và mặc định định tuyến. Mô hình hoạt động trong một chế độ xem Năm giai đoạn, chạy như một vòng lặp. Thuộc tính: mỗi đô la của Amazon Bedrock đều thuộc về một danh tính, nhóm và ứng dụng trong quy trình thanh toán. Lưu ý: mọi yêu cầu đều được ghi lại với đủ siêu dữ liệu để giải thích điều gì đã tạo ra khoản chi tiêu. Thực thi: ngân sách có răng, với các cảnh báo ở mức tối thiểu và các khối cứng khi rủi ro yêu cầu. Tối ưu hóa: các giá trị mặc định của nền tảng (định tuyến mô hình, bộ nhớ đệm, giới hạn mã thông báo) loại bỏ lãng phí một cách tập trung thay vì yêu cầu mọi nhóm phải cẩn thận. Vận hành: một thẻ điểm nhỏ và nhịp đánh giá biến dữ liệu thành quyết định. FinOps dẫn đầu giai đoạn một và năm. Kỹ thuật nền tảng dẫn từ hai đến bốn. Việc xem xét là chung. Các giai đoạn được sắp xếp có chủ ý. Mỗi cái đều phụ thuộc vào những cái trước nó và các nhóm chuyển thẳng sang tối ưu hóa mà không cần phân bổ và khả năng quan sát đều đang đoán mò.

Hình 1: Mô hình vận hành 5 giai đoạn, chạy vòng lặp liên tục

Giai đoạn 1: Thuộc tính mỗi đô la Bạn không thể quản lý những gì bạn không thể phân bổ và mọi thứ ở phía dưới (hoàn tiền, ngân sách, thực thi, phát hiện bất thường) đều phụ thuộc vào giai đoạn này. Nền tảng là phân bổ chi phí chi tiết của Amazon Bedrock (xem Giới thiệu phân bổ chi phí chi tiết cho Amazon Bedrock): Amazon Bedrock tự động phân bổ chi phí suy luận cho nguyên tắc AWS Identity and Access Management (IAM) đã thực hiện lệnh gọi trên tất cả các mô hình mà không cần quản lý tài nguyên. ARN của người gọi sẽ nằm trong cột line_item_iam_principal của Báo cáo chi phí và sử dụng AWS (CUR) 2.0, đồng thời phạm vi áp dụng bao gồm người dùng IAM, vai trò, danh tính liên kết và khóa API. Thiết lập là bốn bước:

Bật dữ liệu chính IAM trong quá trình xuất dữ liệu CUR 2.0 của bạn. Gắn thẻ các nguyên tắc IAM của bạn với các khía cạnh kinh doanh như nhóm, ứng dụng và trung tâm chi phí. Để có quyền truy cập liên kết, hãy định cấu hình nhà cung cấp danh tính của bạn để chuyển tên và thẻ phiên thông qua xác nhận quyền sở hữu OIDC hoặc SAML. Kích hoạt các thẻ đó dưới dạng thẻ phân bổ chi phí trong AWS Billing (bảng điều khiển hoặc API UpdateCostAllocationTagsStatus). Phân tích thẻ: chúng xuất hiện trong CUR 2.0 với tiền tố iamPrincipal/ (ví dụ: iamPrincipal/team) và xuất hiện trong AWS Cost Explorer trong danh mục IAM trong vòng 24–48 giờ kể từ khi kích hoạt, sẵn sàng lọc và nhóm theo nhóm, ứng dụng hoặc trung tâm chi phí.

Đây là phân bổ theo danh tính, cấp hóa đơn, không có cơ sở hạ tầng tùy chỉnh. Vấn đề chia sẻ vai trò Mô hình đáng được chú ý nhất là vấn đề chia sẻ vai trò, bởi vì đó là nơi hầu hết các nền tảng âm thầm mất quyền phân bổ. Cổng mô hình ngôn ngữ lớn (LLM) gọi Amazon Bedrock thông qua một vai trò IAM duy nhất quy mỗi đô la cho một vai trò đó, loại bỏ hoàn toàn khả năng hiển thị của mỗi người dùng. Cách khắc phục là quản lý phiên của mỗi người dùng. Cổng này đảm nhận vai trò gọi Amazon Bedrock một lần cho mỗi người dùng, chuyển danh tính của người dùng làm tên phiên vai trò và các thuộc tính của họ dưới dạng thẻ phiên, sau đó lưu các thông tin xác thực đó vào bộ nhớ đệm trong tối đa một giờ (một lệnh gọi Dịch vụ mã thông báo bảo mật AWS (AWS STS) cho mỗi người dùng mỗi giờ, không phải mỗi yêu cầu). Điều này cần có hai vai trò: vai trò thực thi cổng giữ các quyền sts:AssumeRole và sts:TagSession và vai trò gọi Amazon Bedrock mà nó đảm nhận. Kết quả là các mục nhập line_item_iam_principal như pseudo-role/BedrockRuntimeRole/gw-alex, mỗi mục mang theo thẻ của người dùng: thuộc tính của mỗi người dùng và mỗi đối tượng thuê được khôi phục sau một cổng chung.

nhập boto3

sts = boto3.client("sts")

Một cuộc gọi cho mỗi người dùng; lưu trữ thông tin đăng nhập được trả về tối đa 1 giờ

phản hồi = sts.assume_role( RoleArn="arn:aws:iam::123456789012:role/BedrockRuntimeRole", RoleSessionName="gw-alex", # người dùng, không phải cổng Thẻ=[ {"Khóa": "đội", "Giá trị": "bán hàng-ai"}, {"Khóa": "ứng dụng", "Giá trị": "tác nhân gia hạn"}, {"Khóa": "costCenter", "Giá trị": "CC-2041"} ] )

Lưu ý về hồ sơ suy luận ứng dụng và Dự án Amazon Bedrock cung cấp thêm hai cơ chế phân bổ, mỗi cơ chế phù hợp với một mẫu khác nhau. Hồ sơ suy luận ứng dụng là các tài nguyên được tạo trước cho mỗi ứng dụng trên điểm cuối thời gian chạy nền tảng mang thẻ phân bổ chi phí. Bạn tạo một hồ sơ cho mỗi ứng dụng cho mỗi mô hình cho mỗi Khu vực AWS và người gọi sẽ tham chiếu ARN hồ sơ, phù hợp với các nhóm có bộ ứng dụng và mô hình nhỏ và ổn định. Các dự án và không gian làm việc phục vụ điểm cuối nền tảng (API phản hồi, API hoàn thành trò chuyện). Một dự án không bị ràng buộc với một mô hình cụ thể, do đó, một ID dự án duy nhất trải rộng trên nhiều mô hình, phù hợp với các nhóm có cách sử dụng mô hình thay đổi thường xuyên. Bạn chuyển ID dự án khi khởi tạo ứng dụng khách và các thẻ của nó sẽ chuyển sang CUR 2.0 và Cost Explorer (xem Quản lý chi phí AI với Dự án Amazon Bedrock). Dự án là đường dẫn phân bổ cho khối lượng công việc tương thích với OpenAI trên Amazon Bedrock. Đối với khối lượng công việc trong thời gian chạy nền tảng, chúng tôi khuyên bạn nên phân bổ chính IAM thông qua thẻ phiên làm cơ chế chính. Nó mở rộng quy mô theo hệ thống nhận dạng của bạn, không yêu cầu tài nguyên được tạo trước và bao gồm mọi hoạt động mô hình và API. Hồ sơ suy luận ứng dụng hoạt động tốt khi một nhóm đơn vị kinh doanh nhỏ, ổn định cần phân tách hóa đơn theo cấp hóa đơn mà không cần thay đổi thiết kế nhận dạng. Sử dụng các dự án cho khối lượng công việc cơ bản sử dụng API phản hồi hoặc API hoàn thành trò chuyện. Giai đoạn 2: Làm cho mọi yêu cầu có thể quan sát được CUR cho bạn biết ai đã chi tiêu. Nhật ký lệnh gọi cho bạn biết điều gì đã xảy ra. Amazon Bedrock hỗ trợ ghi nhật ký lệnh gọi mô hình của dữ liệu yêu cầu, dữ liệu phản hồi và siêu dữ liệu vào Nhật ký Amazon CloudWatch, Amazon Simple Storage Service (Amazon S3) hoặc cả hai. Sử dụng Amazon CloudWatch để truy vấn hoạt động nhanh và S3 cộng với Amazon Athena để truy cập thông tin kinh doanh (BI) dài hạn. Coi việc ghi nhật ký là cơ sở hạ tầng chứ không phải chuyển đổi thủ công: cung cấp nhóm nhật ký hoặc bộ chứa thông qua mã, xác định chính sách lưu giữ và mã hóa cũng như xác thực việc phân phối trong môi trường thiết lập onment. Nếu việc ghi nhật ký chỉ tồn tại trong quá trình phát triển hoặc chỉ ở một Khu vực, chương trình chi phí của bạn sẽ trở nên rời rạc khi mức sử dụng tăng lên. Việc ghi nhật ký cũng thu hẹp khoảng cách về độ trễ: phân bổ CUR trễ khoảng 24 giờ, nhưng CloudWatch cộng với OpenTelemetry có thể cung cấp năng lượng cho các trang tổng quan gần như thời gian thực hiển thị mức chi tiêu của mỗi nhà phát triển trong vòng vài phút (Phân tích việc sử dụng Mã Claude với CloudWatch và OpenTelemetry chứng minh điều này từ đầu đến cuối). Yêu cầu siêu dữ liệu để phân bổ ở cấp độ khối lượng công việc Nhật ký thô trả lời các câu hỏi ở cấp độ nhận dạng. Để trả lời các câu hỏi ở cấp độ khối lượng công việc (tính năng, quy trình làm việc hoặc đối tượng thuê nào đã tạo mã thông báo), hãy đóng dấu siêu dữ liệu yêu cầu trên mỗi cuộc gọi. Amazon Bedrock ghi lại siêu dữ liệu này trong nhật ký lệnh gọi để phân tích sau: Ví dụ sau sử dụng Anthropic Claude Sonnet 5.5 trên Amazon Bedrock thông qua hồ sơ suy luận giữa các khu vực của Hoa Kỳ. Để biết danh sách đầy đủ các mô hình, hãy xem Các mô hình nền tảng được hỗ trợ trong Amazon Bedrock. Để biết tính khả dụng theo Khu vực, hãy xem Hỗ trợ mô hình theo Khu vực AWS trong Amazon Bedrock.

phản hồi = client.converse( modelId="us.anthropic.claude-sonnet-5-5", tin nhắn=[...], requestMetadata={ "ứng dụng": "đổi mới-phi công phụ", "workflow": "gia hạn-rủi ro-tóm tắt", "người thuê nhà": "doanh nghiệp bán hàng", "agent": "đại lý gia hạn" } )

Amazon Bedrock không thực thi siêu dữ liệu yêu cầu và các nhóm nhanh chóng chuyển sang các lược đồ không nhất quán khi mỗi ứng dụng thực hiện công việc riêng của mình. Nhóm nền tảng nên đưa siêu dữ liệu bắt buộc vào trung tâm trong trình bao bọc hoặc cổng SDK dùng chung, chuẩn hóa bộ khóa và coi mức độ bao phủ siêu dữ liệu như một chỉ số về tình trạng nền tảng. Truy vấn chẩn đoán Với nhật ký và siêu dữ liệu sẵn có, CloudWatch Logs Insights sẽ trả lời các câu hỏi thường gặp. Ai tiêu thụ nhiều token nhất:

các trường @timestamp, Identity.arn là người gọi, modelId, input.inputTokenCount dưới dạng inTokens, out.outputTokenCount dưới dạng outTokens | tổng số liệu thống kê (inTokens + outTokens) dưới dạng tổngTokens, đếm(*) dưới dạng cuộc gọi bởi người gọi, modelId | sắp xếp tổngTokens mô tả | giới hạn 25

Truy vấn tương tự được nhóm theo requestMetadata.application và requestMetadata.workflow thay vì người gọi sẽ tạo ra bảng xếp hạng cấp khối lượng công việc: nhóm kỹ thuật và sản phẩm xem sẽ yêu cầu FinOps tại thời điểm cuộc trò chuyện yêu cầu bồi hoàn bắt đầu. Lưu ý: Đường dẫn trường hiển thị trong truy vấn trước chỉ mang tính minh họa. Xác minh dựa trên lược đồ nhật ký lệnh gọi của bạn, lược đồ này có thể khác nhau tùy theo mô hình, hoạt động API và cấu hình ghi nhật ký. Giai đoạn 3: Thực thi ngân sách Với sự phân bổ và khả năng quan sát được áp dụng, việc thực thi trở thành một lựa chọn kiến trúc hơn là một mong muốn. Có ba tầng khả thi. Điều kiện phù hợp phụ thuộc vào tốc độ chi tiêu của bạn, mức độ chấp nhận rủi ro đối với việc chi tiêu quá mức và cách các công cụ của bạn kết nối với Amazon Bedrock. Cấp 1: Giám sát và cảnh báo (không chặn) Amazon Bedrock tự động ghi danh tính chính vào quy trình thanh toán. Bạn đặt Ngân sách AWS lên hàng đầu để cảnh báo ngưỡng, với bảng thông tin OpenTelemetry từ Giai đoạn 2 sẽ thu hẹp khoảng cách CUR trong 24 giờ để có được khả năng hiển thị hàng ngày. Không có gì để triển khai, thanh toán AWS gốc và không có độ trễ bổ sung cho lệnh gọi suy luận. Nó hoạt động với các công cụ gọi trực tiếp đến Amazon Bedrock. Không gì có thể ngăn chặn được việc chi tiêu, vì vậy bạn sẽ thấy vấn đề sau khi nó xảy ra. Quyền được áp dụng sớm, trong đó cảnh báo cộng với sự can thiệp của con người là đủ. Hai hướng dẫn dành cho người xây dựng sẽ hướng dẫn chi tiết: Hạn chế sử dụng Bedrock và kiểm soát chi phí cũng như Tìm hiểu sâu về quản lý Bedrock trong Mã Claude với Ngân sách và Thẻ AWS. Cấp 2: Thực thi thẻ IAM (từ chối khi vi phạm) Hàm AWS Lambda tổng hợp tính toán mã thông báo theo mỗi người dùng và bộ đếm đô la trong Amazon DynamoDB từ dữ liệu nhật ký lệnh gọi. Khi người dùng vi phạm ngưỡng của họ, chức năng này sẽ thêm danh tính của họ vào chính sách từ chối IAM chung (từ chối nền tảng:*) cho đến khi đặt lại hàng tháng hoặc ghi đè của quản trị viên. Việc thực thi này chạy hoàn toàn trên ghi nhật ký IAM và Amazon Bedrock, không có thành phần của bên thứ ba trong đường dẫn suy luận và nó hoạt động với các công cụ gọi trực tiếp đến Amazon Bedrock. Hướng dẫn về mã Claude với Amazon Bedrock trong AWS Sol Thư viện utions cung cấp một biến thể có thể triển khai. Nó kiểm tra mức sử dụng của từng người dùng theo giới hạn của mỗi người dùng và mỗi nhóm khi cấp thông tin xác thực và giữ lại thông tin xác thực khi người dùng vượt quá giới hạn của họ. Vì hoạt động kiểm tra đó sử dụng phép đo từ xa mức sử dụng do máy khách phát ra nên số liệu của nó có thể khác với CUR. Trong cả hai hình thức, việc thực thi đều không đồng bộ. Việc chặn sẽ có hiệu lực từ vài giây đến vài phút sau lệnh gọi vi phạm yêu cầu cập nhật chính sách IAM hoặc ở lần làm mới thông tin xác thực tiếp theo để kiểm tra thông tin xác thực. Nhóm nền tảng của bạn sở hữu đường dẫn. Cấp độ này phù hợp với các nhóm cần thực thi thực sự, có thể chịu đựng được độ trễ đó và muốn loại bỏ phần mềm của bên thứ ba khỏi đường dẫn dữ liệu. Cấp 3: Thực thi cổng (khối đồng bộ) Một cổng nằm trong đường dẫn dữ liệu suy luận và thực thi ngân sách một cách đồng bộ, trả về HTTP 429 ngay khi người dùng hoặc nhóm vượt quá giới hạn của họ. Bạn nhận được tính năng chặn dưới giây, danh sách cho phép mô hình cho mỗi người dùng, giới hạn tốc độ mã thông báo và các quy tắc định tuyến được thực thi tập trung. Sự đánh đổi: một thành phần trong đường dẫn dữ liệu phải được triển khai, mở rộng quy mô và xem xét bảo mật. Khách hàng phải được cấu hình để gửi yêu cầu của họ thông qua cổng. Đối với nhóm Claude Code và Claude Desktop, cổng ứng dụng Claude dành cho AWS là đề xuất chính thức. Nó vận chuyển bên trong hệ nhị phân CLI và chạy dưới dạng một vùng chứa không trạng thái duy nhất được hỗ trợ bởi PostgreSQL. Nó cung cấp nhận dạng OIDC, chính sách được quản lý tập trung, đo từ xa OpenTelemetry, định tuyến Amazon Bedrock đa khu vực và giới hạn chi tiêu cho mỗi người dùng/nhóm/tổ chức. Đối với khối lượng công việc mô hình hỗn hợp trải rộng trên nhiều nhà cung cấp, các cổng đa năng vẫn là lựa chọn phù hợp: LiteLLM thông qua Amazon Elastic Container Service (Amazon ECS) trên kiến trúc tham chiếu AWS Fargate hoặc một giải pháp thay thế không có máy chủ được mô tả trong Xây dựng hệ thống quản lý chi phí AI chủ động cho Amazon Bedrock, Phần 2. Chọn một cấp độ Hai yếu tố chiếm ưu thế. Khả năng kết nối: Nếu các nhà phát triển gọi trực tiếp đến Amazon Bedrock mà không cần proxy thì chỉ có Cấp 1 và 2 là khả thi. Vận tốc chi tiêu: Nếu sp cuối cùng đã lên tới hàng triệu mỗi tháng, hãy xây dựng biện pháp thực thi ngay bây giờ. Nếu cảnh báo có thể duy trì trong một quý khác, trước tiên hãy đầu tư vào Giai đoạn 1 và 2 và thêm biện pháp thực thi khi dữ liệu yêu cầu. Hầu hết các tổ chức nên thực hiện theo từng giai đoạn: quan sát ở Cấp 1, sau đó tăng dần. Hãy coi cả ba là cầu nối chứ không phải điểm đến: Ống kính AI tác nhân được kiến ​​trúc tốt đã hệ thống hóa việc quản lý chi phí đại lý như mối quan tâm về kiến ​​trúc hạng nhất và nền tảng phân bổ từ Giai đoạn 1 là điều mà bất kỳ hoạt động thực thi được quản lý nào cũng sẽ áp dụng. Giai đoạn 4: Tối ưu hóa mặc định Hầu hết rác thải của Amazon Bedrock không phải là sự bất cẩn của cá nhân. Đó là mặc định của nền tảng không ai đặt. Hai đòn bẩy có tác động cao nhất đều được điều khiển bằng nền tảng. Định tuyến mô hình Không phải mọi nhiệm vụ đều cần một mô hình biên giới. Quá trình hoàn thành định kỳ (bản soạn sẵn, đề xuất tìm lỗi mã nguồn, công cụ tái cấu trúc nhỏ) có thể chạy trên các mô hình nhỏ hơn, rẻ hơn với chất lượng dành riêng cho lý luận phức tạp, thông qua định tuyến lời nhắc thông minh trong dòng mô hình hoặc quy tắc định tuyến tại cổng (xem Giảm chi phí và độ trễ với Định tuyến lời nhắc thông minh của Amazon Bedrock và bộ nhớ đệm lời nhắc để biết toàn bộ hướng dẫn). Quy trình công việc nào có thể giảm tốc độ là một câu hỏi thực nghiệm: lấy bảng xếp hạng khối lượng công việc từ Giai đoạn 2, chạy đánh giá chất lượng trên mô hình rẻ hơn cho các mục hàng đầu và định tuyến những gì vượt qua. Đối với nhóm mã hóa đại lý, nơi bản soạn sẵn thống trị số lượng cuộc gọi, hơn một nửa số cuộc gọi đến các mô hình rẻ hơn là mục tiêu có thể đạt được. Bộ nhớ đệm nhắc nhở Bộ nhớ đệm nhắc thưởng các tiền tố lặp lại ổn định. Kể từ tháng 10 năm 2026, giá Amazon Bedrock công bố cho các mẫu Anthropic Claude ở Miền Đông Hoa Kỳ (Bắc Virginia) tính phí ghi vào bộ nhớ đệm ở mức gấp 1,25 lần tốc độ đầu vào cơ bản với thời gian tồn tại là 5 phút (TTL) (gấp đôi với TTL 1 giờ). Tốc độ đọc bộ nhớ đệm được tính phí ở mức 0,1 lần tốc độ đầu vào cơ sở trên Claude Sonnet 4.6 và Claude Haiku 4.5 và ở mức 0,05 lần trên Claude Sonnet 5.5 và Claude Opus 5.5. Kiểm tra trang giá cho kiểu máy và Khu vực của bạn vì các hệ số này khác nhau tùy theo kiểu máy và có thể thay đổi. anh trai Toán chẵn-eak thân thiện hơn những gì các đội nghĩ. Với TTL dài 5 phút, một lần sử dụng lại đã trả phí cho việc ghi và mười lệnh gọi đối với tiền tố ổn định có giá khoảng 1/5 giá không được lưu vào bộ nhớ đệm (khoảng 22% với tốc độ đọc 0,1 lần, 17% ở tốc độ 0,05 lần). Trường hợp thua duy nhất là các bản ghi không bao giờ được đọc lại, khiến chi phí tăng thêm 25% với TTL 5 phút và gấp đôi với TTL 1 giờ. Vì vậy, bảng điều khiển nền tảng sẽ theo dõi khối lượng đọc bộ nhớ đệm so với khối lượng ghi bộ nhớ đệm trên mỗi quy trình công việc. Tỷ lệ đọc thấp có nghĩa là tiền tố không thực sự ổn định (thường là dấu thời gian hoặc ID phiên được nhúng trước điểm bộ đệm). Ứng viên xuất hiện trực tiếp từ nhật ký yêu cầu:

các trường requestMetadata.workflow dưới dạng quy trình làm việc, modelId, input.inputTokenCount dưới dạng inTokens | số liệu thống kê(*) dưới dạng cuộc gọi, avg(inTokens) dưới dạng avgInputTokens, sum(inTokens) dưới dạng TotalInputTokens theo quy trình làm việc, modelId | lọc cuộc gọi > 50 và avgInputTokens > 2000 | sắp xếp tổngInputTokens mô tả | giới hạn 25

Lưu ý: Đường dẫn trường hiển thị trong truy vấn trước chỉ mang tính minh họa. Xác minh dựa trên lược đồ nhật ký lệnh gọi của bạn, lược đồ này có thể khác nhau tùy theo mô hình, hoạt động API và cấu hình ghi nhật ký. Tối ưu hóa cấp ứng dụng Loại tiết kiệm thứ ba (truy xuất đúng lúc thay vì ngữ cảnh nhồi nhét, nén các cuộc hội thoại dài, chắt lọc quy trình công việc ổn định với khối lượng lớn vào các mô hình nhỏ hơn) thuộc về các nhóm ứng dụng thay vì nền tảng. Công việc của nền tảng là hiển thị những khoản tiết kiệm đó: xuất bản bảng xếp hạng mã thông báo trên mỗi quy trình công việc, đặt giới hạn mã thông báo cho mỗi mô hình và quy trình làm việc, đồng thời cho phép các nhóm sở hữu quy trình làm việc đắt tiền biết chính xác vị trí của họ. Giai đoạn 5: Vận hành vòng lặp Bốn giai đoạn đầu tiên tạo ra dữ liệu. Điều này biến nó thành quyết định. Nhóm nền tảng chạy một bảng thông tin tình trạng thường trực với bốn tín hiệu:

Kết hợp mô hình: Những mô hình nào được gọi và tần suất gọi là thước đo trực tiếp về kỷ luật định tuyến. Tỷ lệ yêu cầu không thành công: Lỗi, điều chỉnh và hết thời gian chờ. Mỗi lần thử lại sẽ tăng thêm độ trễ và thời gian chờ phía máy khách đối với một yêu cầu vẫn hoàn thành ở phía dịch vụ có thể bị tính phí hai lần, một lần cho cuộc gọi bị bỏ dở và một lần cho lần thử lại. Hiệu quả của bộ đệm: Tỷ lệ đọc so với ghi từ Giai đoạn 4. Phạm vi siêu dữ liệu: Tỷ lệ cuộc gọi sản xuất có siêu dữ liệu hoàn chỉnh. Mỗi cuộc gọi không được phát hiện đều là một điểm mù quy kết làm giảm giá trị của mọi số khác một cách lặng lẽ.

Khi tín hiệu bị sai lệch, biện pháp khắc phục là thay đổi chính sách (quy tắc định tuyến, giới hạn mã thông báo, thực thi siêu dữ liệu), chứ không phải là email yêu cầu các nhóm phải cẩn thận. Vòng lặp tiền FinOps chạy vòng lặp tiền trên cùng một dữ liệu. Khi phân bổ rõ ràng, hoạt động phát hiện bất thường sẽ trở thành một luồng điều tra thay vì chung tay hoảng loạn: sự gia tăng đột biến về nhóm hoặc ứng dụng được gắn thẻ sẽ kích hoạt tra cứu trong bảng xếp hạng Giai đoạn 2 chứ không phải phòng chiến tranh. Khoản bồi hoàn chạy từ các nhóm CUR theo nhóm và ứng dụng. Thẻ điểm Các ngưỡng sau đây là điểm khởi đầu, không phải quy định. Hiệu chỉnh chúng dựa trên dữ liệu nhóm và mức giá của riêng bạn trước khi áp dụng chúng làm chính sách.

Kích thước Số liệu màu xanh lá cây màu vàng màu đỏ

Đơn vị kinh tế Chi phí cho mỗi kết quả thành công ≤ ngân sách Ngân sách 1–1,5 lần

1,5 lần ngân sách

Chi phí mỗi nhà phát triển Chi tiêu hàng ngày cho mỗi nhà phát triển $300

Định tuyến mô hình % cuộc gọi đến các mô hình tiết kiệm chi phí

50% 30–50% 60% 30–60% <30%

Màu xanh lá cây có nghĩa là khối lượng công việc hoạt động bên trong phạm vi kinh tế của nó. Màu vàng có nghĩa là kỷ luật định tuyến hoặc bộ nhớ đệm đang bị tuột dốc. Màu đỏ có nghĩa là chi tiêu đang tập trung vào các mô hình cao cấp hoặc bối cảnh không được lưu vào bộ nhớ đệm và các điều khiển Giai đoạn 3 và 4 là lộ trình khắc phục. Xem lại thẻ điểm này theo nhịp độ đều đặn (hàng tuần đối với đội tàu tốc độ cao, nếu không thì hai tuần một lần) và coi nó như là bề mặt quyết định chung của nền tảng FinOps-plus. Kết luận Trong bài đăng này, bạn đã tìm hiểu cách xây dựng mô hình hoạt động gồm 5 giai đoạn giúp chi tiêu của Amazon Bedrock từ không được kiểm soát đến được quản lý hoàn toàn:

Phân bổ mỗi đô la cho chủ sở hữu bằng cách sử dụng thẻ chính IAM, thẻ phiên và CUR 2.0. Quan sát mọi yêu cầu thông qua ghi nhật ký lệnh gọi mô hình và siêu dữ liệu yêu cầu được đóng dấu. Thực thi ngân sách ở cấp phù hợp với rủi ro của bạn: chỉ giám sát, từ chối IAM khi vi phạm hoặc chặn cổng đồng bộ. Tối ưu hóa các giá trị mặc định của nền tảng với tính năng định tuyến nhanh chóng thông minh và bộ nhớ đệm nhanh chóng để loại bỏ lãng phí một cách tập trung. Vận hành thẻ điểm và nhịp độ xem xét để biến phép đo từ xa thành các quyết định chính sách.

Lưu ý hàng đầu tiên của thẻ điểm đó: chi phí cho mỗi kết quả thành công, không phải chi phí cho mỗi cuộc gọi. Sự khác biệt đó chính là điểm mà cuốn sách này phát huy tác dụng. Mọi thứ ở đây làm cho chi tiêu của Amazon Bedrock hiển thị rõ ràng, có thể phân bổ, có giới hạn và hiệu quả, nhưng một quy trình công việc có thể hoàn toàn hiệu quả nhưng vẫn không đáng để chạy. Việc quyết định điều đó đòi hỏi phải đo lường tác nhân dựa trên quy trình của con người mà nó đã thay thế, đây là một nguyên tắc về sản phẩm và phân tích chứ không phải là nguyên tắc FinOps. Những gì nền tảng chi phí đóng góp chính là nền tảng: phân bổ rõ ràng và dữ liệu chi phí trên mỗi quy trình làm việc chính xác là những yếu tố đầu vào mà việc đo lường kết quả kết hợp dựa trên. Hãy xây dựng năm giai đoạn và bạn có thể trả lời từ đầu đến cuối: ai đã tiêu số tiền đó, tại sao và liệu số tiền đó có được kiểm soát hay không. Đó chính là ý nghĩa của việc quản lý chi phí Amazon Bedrock và đó là sự khác biệt giữa việc xem xét hóa đơn hàng tháng và mô hình hoạt động. Để bắt đầu, hãy triển khai Hướng dẫn dành cho Mã Claude với kiến ​​trúc tham chiếu Amazon Bedrock cho Giai đoạn 1–3, sau đó sử dụng tài liệu về các phương pháp hay nhất về phân bổ chi phí để định cấu hình chiến lược gắn thẻ của bạn.

Về các tác giả