theo dõi việc sử dụng AI theo từng key là thực hành vận hành gán cho mỗi API key AI một chủ sở hữu, môi trường, quy trình làm việc và loại lưu lượng rõ ràng, sau đó rà soát việc sử dụng, chi phí, lỗi và các sự kiện hạn mức theo key đó. Nó là sự khác biệt giữa việc biết rằng “tài khoản AI đã chi nhiều hơn trong tuần này” và biết rằng các bài kiểm tra ở môi trường staging, một tính năng production, hoặc một tích hợp hướng đến khách hàng cụ thể đã gây ra mức tăng đó.
Hướng dẫn này đã được kiểm tra vào ngày 17 tháng 6 năm 2026 theo múi giờ Asia/Shanghai đối chiếu với hướng dẫn chính thức về API sử dụng và chi phí của OpenAI, tài liệu ghi log và metadata của Cloudflare AI Gateway, tài liệu quan sát của Vercel AI Gateway, và ảnh chụp mới nhất của trang cùng giá công khai của Flatkey. Hãy xem tất cả nhãn trên dashboard, các hàng model, họ endpoint và đơn vị giá như bằng chứng tại một thời điểm; hãy xác minh đúng hàng trong bảng giá Flatkey trước khi có lưu lượng production.
Câu trả lời nhanh: Theo dõi sử dụng AI theo từng khóa nên chứng minh điều gì
Theo dõi sử dụng AI theo từng khóa hữu ích nên trả lời năm câu hỏi mà không cần một dự án “khai quật” bảng tính:
- Ai sở hữu khóa? Kỹ thuật, hỗ trợ, tăng trưởng, dữ liệu, một workspace khách hàng, hoặc một tài khoản dịch vụ.
- Khóa được phép chạy ở đâu? Phát triển, staging, sản xuất, xử lý theo lô, đánh giá, hoặc lưu lượng hướng tới khách hàng.
- Nó được phép gọi gì? Các mô hình đã phê duyệt, họ endpoint, nhà cung cấp, tuyến dự phòng, và các loại hình thức.
- Nó đã chi tiêu gì? Yêu cầu, token, token được lưu vào bộ nhớ đệm, hình ảnh, job video, lần thử lại, lần chuyển sang dự phòng, và chi phí.
- Điều gì xảy ra khi nó lệch chuẩn? Cảnh báo, giới hạn cứng, hạ cấp tuyến, xoay vòng khóa, xem xét khách hàng, hoặc phê duyệt của tài chính.
Mục tiêu thực tế không phải là tạo thêm nhiều khóa chỉ vì bản thân nó. Mục tiêu là làm cho mỗi khóa đủ nhỏ để việc quy kết chi phí, xem xét sự cố, chính sách hạn ngạch, và tách lưu lượng khách hàng đều có thể kiểm tra được.
Tại sao một khóa API AI dùng chung làm hỏng việc phân bổ chi phí
Một khóa production dùng chung trông có vẻ đơn giản cho đến khi xảy ra đợt tăng lưu lượng đầu tiên. Khi các bài kiểm thử staging, cron job, đánh giá mô hình, bản demo và lưu lượng khách hàng đều dùng chung một thông tin xác thực, biểu đồ sử dụng có thể cho bạn biết rằng đã có điều gì đó xảy ra, nhưng không cho biết ai là người gây ra hay cần làm gì tiếp theo.
Theo dõi mức sử dụng AI theo từng khóa khắc phục điều đó bằng cách làm cho ranh giới của thông tin xác thực khớp với ranh giới vận hành. Nếu một script staging chạy quá thường xuyên, staging nên hiển thị đợt tăng đó. Nếu một phân khúc khách hàng nào đó tiêu hết ngân sách của một mô hình cao cấp, khóa hướng tới khách hàng đó nên thể hiện điều đó. Nếu một batch job thử lại qua một phương án dự phòng tốn kém, khóa của batch đó nên chịu trách nhiệm cho chi phí và việc rà soát sự cố.
| Vấn đề của khóa dùng chung | Giải pháp theo dõi theo từng khóa | Kết quả rà soát |
|---|---|---|
| Các bài kiểm thử staging xuất hiện như chi tiêu production | Các khóa riêng cho non-production với hạn mức nhỏ | Tài chính có thể bỏ qua nhiễu từ kiểm thử khi rà soát chi phí production |
| Lưu lượng khách hàng bị trộn với tự động hóa nội bộ | Các khóa hướng tới khách hàng hoặc siêu dữ liệu theo workspace/tier | Hỗ trợ có thể gắn việc sử dụng với hành vi và gói sản phẩm của khách hàng |
| Một khóa bị rò rỉ đòi hỏi phản ứng ngừng dịch vụ trên diện rộng | Phạm vi khóa nhỏ và nhãn chủ sở hữu | Bảo mật có thể vô hiệu hóa một khóa mà không làm hỏng mọi tuyến đường |
| Chi phí fallback và retry là vô hình | Ghi log khóa gốc, route, số lần retry, mô hình fallback và trạng thái cuối cùng | Kỹ thuật có thể tinh chỉnh hành vi khôi phục mà không cần đoán |
| Chủ ngân sách tranh cãi về chi tiêu hàng tháng | Quyền sở hữu khóa ánh xạ mức sử dụng tới team, tính năng, khách hàng hoặc môi trường | Tài chính có thể đối soát mức sử dụng trước khi rà soát hóa đơn |
Ma trận phân loại khóa chính cho môi trường Staging, Production và lưu lượng khách hàng
Hãy dùng ma trận này như tài sản giá trị cho một đợt triển khai theo dõi sử dụng AI theo từng khóa. Tên khóa chính xác nên phù hợp với hệ thống của bạn, nhưng mỗi khóa nên có một chủ sở hữu, một mục đích, một cửa sổ đặt lại và một đường leo thang.
| Phạm vi khóa | Lưu lượng được phép | Các trường sử dụng cần xem xét | Chính sách hạn ngạch | Câu hỏi khi có sự cố |
|---|---|---|---|---|
| Khóa phát triển | Thử nghiệm cục bộ, công việc tính năng khối lượng thấp, kiểm tra smoke model | Chủ sở hữu, model, endpoint, số lượng request, trạng thái, số token, chi phí | Giới hạn cứng rất nhỏ; không dùng model cao cấp nếu chưa được phê duyệt | Chỉ chạy một script cục bộ hoặc notebook lâu hơn dự kiến phải không? |
| Khóa staging | QA trước sản xuất, kiểm thử tải với giới hạn đã phê duyệt, xác thực phát hành | Môi trường, bản phát hành, luồng công việc, model, độ trễ, token, lỗi, lần thử lại | Hạn mức riêng biệt với production; cảnh báo trong các cửa sổ kiểm thử tải | Lưu lượng sử dụng ở staging có vô tình giống lưu lượng production không? |
| Khóa ứng dụng production | Tính năng trực tiếp cho khách hàng và các đường dự phòng đã được phê duyệt | Tính năng, phân khúc khách hàng, kết quả được chấp nhận, tuyến, đơn vị sử dụng, chi phí cuối cùng | Hạn ngạch cao hơn với cảnh báo mềm và cần chủ sở hữu phê duyệt khi tăng | Tính năng hoặc phân khúc nào đã gây ra đột biến chi tiêu hoặc lỗi? |
| Khóa batch | Backfill, công việc bổ sung dữ liệu, đánh giá, tự động hóa theo lịch | ID công việc, kích thước đầu vào, kích thước đầu ra, số lần thử lại, bản ghi được chấp nhận, chi phí trên mỗi bản ghi | Phê duyệt ở cấp công việc, giới hạn đồng thời và điều kiện dừng | Các lần thử lại hoặc đầu ra bị từ chối có làm tăng chi phí hiệu dụng không? |
| Khóa workspace khách hàng | Workspace doanh nghiệp chuyên dụng, khách hàng khối lượng lớn, hoặc tuyến reseller | Workspace, cấp gói, model, trạng thái hạn ngạch, vượt hạn mức, lỗi, đơn vị sử dụng | Hạn mức theo từng cấp với khả năng hỗ trợ và tài chính cùng theo dõi | Khách hàng đang chạm ngưỡng tăng trưởng bình thường, lạm dụng, hay lệch gói? |
| Khóa đánh giá | Benchmark model, kiểm thử prompt, so sánh nhà cung cấp, tuyến xem trước | ID thử nghiệm, model, bộ dữ liệu, token, trạng thái cache, chấp nhận đầu ra, chi phí | Cửa sổ đặt lại ngắn; cần phê duyệt trước khi thử nghiệm preview hoặc model cao cấp | Benchmark nào đã tạo ra chi phí không nên tính cho production? |
Ghi gì cho từng API key
Theo dõi mức sử dụng AI theo từng key chỉ hoạt động khi key xuất hiện trong bản ghi log có đủ các trường về chi phí và ngữ cảnh. Bản ghi tối thiểu nên đọc được bởi kỹ thuật, tài chính và hỗ trợ.
| Nhóm trường | Các trường được khuyến nghị | Vì sao quan trọng |
|---|---|---|
| Danh tính | ID API key, chủ sở hữu, nhóm, môi trường, quy trình, thẻ khách hàng hoặc workspace | Gán cho mỗi yêu cầu một ngân sách và chủ sở hữu hỗ trợ |
| Tuyến | Nhà cung cấp, dòng model, họ endpoint, nhóm tuyến, tuyến dự phòng, hạng dịch vụ | Cho thấy lưu lượng có chuyển sang đường đi đắt hơn hoặc rủi ro hơn không |
| Sử dụng | Số lượng yêu cầu, token đầu vào, token đầu ra, token đã cache, hình ảnh, tác vụ video, thời lượng tác vụ | Ngăn việc chỉ theo dõi request làm che khuất chi phí của ngữ cảnh dài hoặc đa phương thức |
| Chi phí | Chi phí ước tính, chi phí cuối cùng, đơn vị giá, tiền tệ, cửa sổ đặt lại, chủ sở hữu ngân sách | Kết nối việc sử dụng model với rà soát tài chính và gói sản phẩm cho khách hàng |
| Độ tin cậy | Trạng thái, lớp lỗi, độ trễ, thời gian đến token đầu tiên, số lần thử lại, số lần chuyển sang dự phòng, đầu ra được chấp nhận | Tách tăng trưởng lành mạnh khỏi các vòng lặp thất bại và các lần khôi phục tốn kém |
| Quản trị | Trạng thái hạn mức, ngưỡng cảnh báo, ticket phê duyệt, ngày xoay vòng, chính sách lưu giữ | Giúp các thay đổi chính sách có thể kiểm toán sau một sự cố chi tiêu hoặc bảo mật |
Tài liệu chính thức của nhà cung cấp và gateway cũng đi theo cùng một hướng. API sử dụng của OpenAI hỗ trợ lọc theo API key và nhóm sử dụng theo các trường như project, user, API key, model, batch và service tier, trong khi API chi phí hỗ trợ lọc theo API key và nhóm chi phí theo project, line item và API key. Tài liệu Cloudflare AI Gateway mô tả log yêu cầu với provider, timestamp, status, token usage, cost, duration, user agent và custom metadata. Tài liệu quan sát của Vercel AI Gateway mô tả tóm tắt yêu cầu theo project và API key, cùng log yêu cầu chi tiết với các loại token và chi phí. Hãy dùng các tài liệu này như mẫu thiết kế có dẫn nguồn, sau đó xác minh chính xác các trường và hành vi lưu giữ trong nền tảng bạn vận hành.
Theo dõi mức sử dụng AI theo từng khóa bắt đầu với các phạm vi khóa riêng biệt
Một hạn mức gắn với một khóa dùng chung vẫn chỉ là một hạn mức dùng chung. Nếu production và staging dùng cùng một khóa, một bài kiểm tra tải ở staging có thể tiêu tốn phần dự phòng mà production cần. Nếu lưu lượng khách hàng và các job xử lý batch nội bộ chia sẻ một khóa, bộ phận hỗ trợ có thể đổ lỗi cho khách hàng về khoản chi phí do một tự động hóa nội bộ tạo ra.
Đối với theo dõi mức sử dụng AI theo từng khóa, hãy tạo hệ phân loại khóa trước khi tinh chỉnh hạn mức:
- Bắt đầu với các môi trường: development, staging, production và evaluation không nên dùng chung một khóa production.
- Chia theo rủi ro của luồng công việc: các job batch, agent, tạo ảnh/video và các tuyến dự phòng nặng nên có khóa riêng hoặc thẻ metadata riêng.
- Chia theo chủ sở hữu: một nhóm, khách hàng, tài khoản dịch vụ hoặc trung tâm chi phí nên sở hữu mỗi khóa có lưu lượng cao.
- Gắn hạn mức sau khi đã rõ chủ sở hữu: đặt ngưỡng cứng cho môi trường không phải production và các tuyến rủi ro; dùng cảnh báo mềm cho tăng trưởng production bình thường.
- Tài liệu hóa đường xử lý khi vượt giới hạn: quyết định xem ứng dụng sẽ chặn, giảm chất lượng, đổi tuyến, yêu cầu phê duyệt hay cảnh báo chủ sở hữu.
Cách chia cụ thể phụ thuộc vào lưu lượng. Một nhóm nhỏ có thể bắt đầu với các khóa development, staging, production và batch. Một nhóm lớn hơn có thể bổ sung các khóa theo workspace của khách hàng, khóa đánh giá mô hình, khóa tự động hóa hỗ trợ, và các khóa riêng cho những tuyến tạo ảnh hoặc video có chi phí cao. Bài kiểm tra cho theo dõi mức sử dụng AI theo từng khóa rất đơn giản: nếu hai nhóm lưu lượng cần chủ sở hữu, hạn mức hoặc hành động xử lý sự cố khác nhau, thì chúng có lẽ không nên bị ẩn sau cùng một khóa.
Cách sử dụng theo từng key giúp rà soát sự cố
Khi xảy ra đột biến mức sử dụng, câu hỏi đầu tiên không nên là "ai đang giữ API key?" Mà phải là "key theo phạm vi nào đã thay đổi?" Đó là lý do vì sao theo dõi mức sử dụng AI theo từng key nên nằm trong quy trình rà soát sự cố, chứ không chỉ trong báo cáo tài chính.
| Tín hiệu sự cố | Rà soát theo từng key nên cho thấy gì | Hành động có khả năng thực hiện |
|---|---|---|
| Đột biến chi phí | Key, chủ sở hữu, model, đơn vị, route, khách hàng/quy trình công việc và cửa sổ reset | Thiết lập cảnh báo, hạ hạn mức, chuyển route, hoặc phê duyệt mức sử dụng theo kế hoạch |
| Đột biến token | Phân tách input/output, kích thước prompt, hành vi cache, tỷ lệ kết quả được chấp nhận | Giới hạn kích thước input, rút ngắn output, cải thiện chiến lược cache, hoặc thay đổi prompt |
| Vòng lặp retry | Lỗi gốc, số lần retry, route dự phòng, trạng thái cuối cùng, chi phí cho mỗi output được chấp nhận | Thêm điều kiện dừng, backoff, loại lỗi không được retry, hoặc giới hạn fallback |
| Khiếu nại của khách hàng | Key workspace, trạng thái hạn mức, mức sử dụng gần đây, mẫu yêu cầu thất bại, route model | Điều chỉnh hạn mức khách hàng, debug route, giải thích giới hạn gói, hoặc chuyển lên bộ phận hỗ trợ cấp cao hơn |
| Khả năng key bị lộ | Chủ sở hữu key, môi trường nguồn, nguồn gốc request, model hoặc endpoint bất thường | Vô hiệu hóa hoặc xoay vòng một key theo phạm vi và bảo toàn lưu lượng không bị ảnh hưởng |
Cách Kiểm Tra Theo Dõi Sử Dụng AI Theo Từng Khóa Trong Flatkey
Trang web công khai của Flatkey định vị nền tảng này là một cổng API duy nhất cho các đội AI sản xuất, với quyền truy cập mô hình, định tuyến, thanh toán, phân tích mức sử dụng và các điều khiển vận hành. Trang giá công khai được kiểm tra cho bài viết này hiển thị 638 mô hình AI trên 23 nhà cung cấp, với các họ endpoint bao gồm /v1/chat/completions, /v1/responses, /v1/images/generations, /v1/video/generations, Anthropic Messages và Gemini generateContent. Hãy xem đây là ảnh chụp tại thời điểm ngày 17 tháng 6 năm 2026, không phải là cam kết دائم về tính khả dụng. Đối với theo dõi sử dụng AI theo từng khóa, bằng chứng hữu ích không chỉ là quy mô danh mục; mà là việc khóa hiện tại, dòng mô hình, họ endpoint và nhật ký sử dụng của bạn có thể được xem cùng nhau sau một yêu cầu hay không.
Một kế hoạch xác thực Flatkey thực tế cho theo dõi sử dụng AI theo từng khóa nên trông như sau:
- Mở bảng giá Flatkey và xác nhận đúng dòng mô hình, nhà cung cấp, họ endpoint, trạng thái khả dụng và đơn vị giá bạn dự định sử dụng.
- Tạo hoặc chọn các khóa riêng biệt cho môi trường staging, production, batch và lưu lượng hướng tới khách hàng. Nếu nhãn trên bảng điều khiển của bạn khác, hãy ghi lại các nhãn hiện tại trong ghi chú triển khai.
- Chạy một bài kiểm tra khói ít rủi ro cho mỗi khóa thông qua endpoint và tuyến mô hình dự kiến.
- Xem lại khả năng hiển thị sử dụng và thanh toán trên bảng điều khiển Flatkey sau mỗi yêu cầu. Xác nhận các trường khóa, mô hình, trạng thái, đơn vị sử dụng và chi phí mà nhóm của bạn sẽ dùng để xem xét.
- Đặt hạn mức staging cố ý thấp và kiểm tra hành vi vượt giới hạn trước khi mở một tuyến cho người dùng.
- Tài liệu hóa đường xử lý leo thang cho từng khóa: chủ sở hữu, ngưỡng cảnh báo, người phê duyệt hạn mức, chủ sở hữu xoay vòng và tuyến khôi phục.
- Lặp lại bài kiểm tra cho bất kỳ tuyến văn bản, hình ảnh, video, batch hoặc dự phòng nào vì chỉ đếm số lượng yêu cầu là chưa đủ cho việc xem xét chi phí đa phương thức.
Kế hoạch kiểm tra này tránh giả định các ngữ nghĩa thực thi chính xác. Hãy xác minh các nhãn bảng điều khiển hiện tại, dòng mô hình hiện tại, đơn vị giá hiện tại, trường nhật ký, hành vi hạn mức và phản hồi API trước khi phụ thuộc vào một tuyến cho các điều khiển sản xuất.
Mẫu: Hồ sơ sử dụng theo từng khóa
Giữ một hồ sơ ngắn gọn cho mỗi khóa dùng cho sản xuất hoặc hướng tới khách hàng. Hồ sơ này biến theo dõi mức sử dụng AI theo từng khóa thành một thói quen vận hành thay vì một lần kiểm tra bảng điều khiển.
Hồ sơ theo dõi mức sử dụng AI theo từng khóa
ID hoặc nhãn khóa: chỉ là định danh không bí mật
Chủ sở hữu: nhóm, tài khoản dịch vụ, workspace của khách hàng, hoặc chủ ngân sách
Môi trường: phát triển, staging, sản xuất, xử lý lô, đánh giá, hoặc hướng tới khách hàng
Các tuyến được phép: nhà cung cấp, hàng mô hình, họ endpoint, tuyến dự phòng, và phương thức
Trường sử dụng: số yêu cầu, token đầu vào, token đầu ra, token đã lưu vào bộ nhớ đệm, hình ảnh, tác vụ video, thời lượng
Trường chi phí: chi phí ước tính, chi phí cuối cùng, đơn vị tính giá, tiền tệ, chu kỳ đặt lại
Chính sách hạn mức: giới hạn cứng, cảnh báo mềm, người phê duyệt, và hành vi sản phẩm khi vượt hạn mức
Trường sự cố: trạng thái, loại lỗi, số lần thử lại, số lần thử dự phòng, tỷ lệ đầu ra được chấp nhận
Tần suất rà soát: ngày ra mắt, vận hành hằng tuần, tài chính hằng tháng, hoặc rà soát của bộ phận thành công khách hàng
Kế hoạch xoay vòng: chủ sở hữu, ngày, kích hoạt, và đường quay lui
Không lưu các bí mật API thực trong hồ sơ này. Hãy dùng nhãn khóa không bí mật hoặc ID trên bảng điều khiển để hồ sơ có thể được chia sẻ với tài chính, hỗ trợ, và người ứng phó sự cố.
Các lỗi thường gặp
- Dùng một khóa production ở mọi nơi: môi trường staging, bản demo, các job cron và lưu lượng khách hàng cần được phân bổ riêng.
- Theo dõi request nhưng không theo dõi đơn vị: prompt dài, token được cache, tạo ảnh và job video có cấu trúc chi phí khác nhau.
- Bỏ qua nhãn chủ sở hữu: một khóa không có đội, khách hàng hoặc chủ sở hữu dịch vụ sẽ không thể đánh giá khi có sự cố.
- Đặt hạn ngạch trước phân loại: hạn ngạch khó tinh chỉnh hơn khi phạm vi của khóa không rõ ràng.
- Bỏ qua chi phí retry và fallback: đầu ra được chấp nhận có thể đắt hơn nhiều so với yêu cầu đầu tiên đã thử.
- Cho rằng nhãn trên dashboard là vĩnh viễn: hãy xác minh các trường hiện tại, dữ liệu xuất, thời gian lưu giữ và đơn vị tính giá trước khi viết runbook.
- Nhúng bí mật vào runbook: hãy ghi lại các nhãn không phải bí mật và thông tin sở hữu của khóa, không phải các API key thô.
Câu hỏi thường gặp
Theo dõi mức sử dụng AI theo từng key là gì?
Theo dõi mức sử dụng AI theo từng key là thực hành xem xét mức sử dụng API AI, chi phí, trạng thái hạn mức, lỗi và quyền sở hữu theo từng API key. Điều này giúp các đội ngũ tách biệt lưu lượng staging, production, batch, evaluation và hướng tới khách hàng thay vì coi toàn bộ chi tiêu AI là một tổng cấp tài khoản duy nhất.
Tại sao staging và production nên dùng các API key AI riêng biệt?
Staging và production nên dùng các API key AI riêng biệt vì chúng có chủ sở hữu, mức độ rủi ro, hạn mức và cách ứng phó sự cố khác nhau. Một bài kiểm tra tải ở staging không nên tiêu hao dung lượng dự phòng của production hoặc khiến bộ phận tài chính nghĩ rằng lưu lượng khách hàng thực tế đã trở nên đắt hơn.
Tôi nên theo dõi những gì cho mức sử dụng LLM theo API key?
Đối với mức sử dụng LLM theo API key, hãy theo dõi chủ sở hữu, môi trường, quy trình, mô hình, nhà cung cấp, endpoint, số lượng request, input tokens, output tokens, cached tokens, trạng thái, độ trễ, số lần thử lại, tuyến dự phòng, trạng thái hạn mức và chi phí cuối cùng. Với các tuyến đa phương thức, hãy thêm đơn vị hình ảnh, video, âm thanh hoặc thời lượng job.
Theo dõi mức sử dụng API key có thể giúp phân bổ chi phí cho khách hàng không?
Có, theo dõi mức sử dụng API key có thể giúp phân bổ chi phí cho khách hàng khi key hoặc metadata xác định được workspace, gói dịch vụ hoặc chủ sở hữu của tuyến. Điều này đặc biệt hữu ích cho khách hàng doanh nghiệp, các tuyến reseller, workspace có lưu lượng lớn và các điều tra hỗ trợ.
Theo dõi mức sử dụng AI theo từng key liên quan thế nào đến quản lý hạn mức?
Theo dõi mức sử dụng AI theo từng key cho biết ai đã dùng ngân sách và tuyến nào đã gây ra chi phí. Quản lý hạn mức API AI quyết định giới hạn, cảnh báo, phê duyệt hoặc chặn nào nên áp dụng cho key đó. Hãy dùng theo dõi trước để hiểu phạm vi, rồi thiết lập hạn mức cho phạm vi đó.
Bước Rà Soát Cuối Cùng
Trước khi mở rộng một tính năng AI, hãy rà soát mọi key có thể truy cập route. Mỗi key nên có owner, môi trường, các model được phép, chính sách quota, bản ghi sử dụng, đường xử lý sự cố, và kế hoạch xoay vòng. Đó là cốt lõi của theo dõi mức sử dụng AI theo từng key: staging, production, batch, và traffic khách hàng được tách biệt đủ để chi phí, thanh toán, và sự cố có thể do đúng owner xử lý.
Đối với stack vận hành tổng thể, hãy kết hợp hướng dẫn này với hướng dẫn quản lý quota AI API, so sánh giá model AI, và checklist cổng AI API cho doanh nghiệp.
Xem giá: dùng bảng giá Flatkey để xác minh các dòng model hiện tại, nhóm endpoint, và đơn vị tính giá trước khi gán các key production, staging, hoặc hướng tới khách hàng.
