TokenLab Request Console: Gỡ lỗi các lệnh gọi API AI từ một bảng điều khiển duy nhất

Một lệnh gọi API AI thất bại hiếm khi tự thông báo một cách rõ ràng. Bạn nhận được mã trạng thái, có thể là một chuỗi lỗi và một kênh hỗ trợ nơi ai đó hỏi "ID yêu cầu là gì?". Nếu bạn không có sẵn thông tin đó, quá trình điều tra sẽ bị đình trệ ngay từ khi bắt đầu.

TokenLab Request Console ra đời để thu hẹp khoảng cách đó. Nó đưa các chi tiết ở cấp độ yêu cầu — model, key, trạng thái bộ nhớ đệm (cache), trạng thái thanh toán, thời gian và bản xem trước nội dung (payload) đã được ẩn danh — vào một chế độ xem bảng điều khiển duy nhất, để bạn có thể đi từ "lệnh gọi này đã thất bại" đến "đây là lý do tại sao" mà không cần phải chắp vá nhật ký từ ba nơi khác nhau.

Bài viết này sẽ hướng dẫn những gì bảng điều khiển hiển thị, những điều cần kiểm tra đầu tiên khi có sự cố và cách nó kết hợp với các báo cáo sử dụng (usage exports) dành cho các nhóm cần báo cáo chi phí.

Các điểm chính

• Request Console là giao diện gỡ lỗi ở cấp độ yêu cầu bên trong bảng điều khiển API của TokenLab, không phải là báo cáo thanh toán.
• Mỗi yêu cầu đều có một ID mà bạn có thể tìm kiếm trực tiếp và bạn có thể liên kết sâu (deep-link) đến một yêu cầu cụ thể bằng requestId trên URL.
• Bảng điều khiển hiển thị định tuyến, trạng thái thanh toán, trạng thái cache, ngữ cảnh model/key và bản xem trước nội dung đã ẩn danh cho các yêu cầu gần đây.
• Quyền truy cập được giới hạn trong tổ chức của bạn và được quản lý bởi quyền thành viên bảng điều khiển — các đồng nghiệp chỉ thấy những gì vai trò của họ cho phép.
• Để gỡ lỗi một sự cố đơn lẻ, hãy sử dụng bảng điều khiển. Để xem xét chi phí hàng loạt theo phạm vi thời gian, hãy sử dụng báo cáo sử dụng (usage exports).

Request Console là gì?

Bạn có thể truy cập nó tại https://tokenlab.sh/en/dashboard/api?tab=requestConsole, bên trong phần API của bảng điều khiển TokenLab. Nó được xây dựng dựa trên một tiền đề: khi một yêu cầu thất bại, cách khắc phục nhanh nhất đến từ việc có đầy đủ ngữ cảnh trước mắt, thay vì đoán mò dựa trên thông báo lỗi.

Mô tả trên bảng điều khiển cho biết console là một trình kiểm tra cho các yêu cầu gần đây, bao gồm định tuyến, thanh toán, nội dung yêu cầu/phản hồi và ngữ cảnh nhà cung cấp model. Trên thực tế, nó được chia thành một vài phần làm việc.

Chế độ xem danh sách. Một bảng có thể lọc các yêu cầu gần đây. Đây là nơi bạn bắt đầu khi chưa có ID yêu cầu cụ thể — bạn đang quét tìm lệnh gọi bị lỗi hoặc bất thường.

Bảng kiểm tra (Inspector panel). Khi bạn chọn một yêu cầu, trình kiểm tra sẽ mở ra với đầy đủ chi tiết: model nào đã phục vụ nó, API key nào được sử dụng, liệu nó có chạm vào cache hay không và trạng thái cuối cùng là gì.

Ngữ cảnh lỗi. Nếu yêu cầu thất bại, bảng điều khiển sẽ hiển thị thông tin lỗi gắn liền với lệnh gọi cụ thể đó, vì vậy bạn không cần phải đối chiếu với nhật ký lỗi riêng biệt.

Trạng thái định tuyến và thanh toán. Hiển thị cách yêu cầu được định tuyến và liệu nó đã được thanh toán, đang chờ xử lý, được hoàn tiền hay thất bại — bốn trạng thái quan trọng nhất khi khách hàng hỏi "tôi có bị tính phí cho lỗi đó không?".

Bản xem trước nội dung (Payload preview). Nội dung yêu cầu và phản hồi được hiển thị dưới dạng bản xem trước đã ẩn danh khi có sẵn, giúp bạn nắm bắt hình dạng và cấu trúc mà không làm lộ các thông tin bí mật thô trong nội dung.

Ngữ cảnh nhà cung cấp model và model key. Nhà cung cấp nào và model cụ thể nào đã xử lý lệnh gọi — hữu ích khi bạn đang chạy nhiều model đằng sau một tích hợp và cần xác nhận model đúng đã được gọi.

Không có phần nào trong số này yêu cầu bạn phải tự xây dựng quy trình ghi nhật ký trên API. Nó đã được hiển thị theo từng tổ chức, được lọc theo quyền thành viên bảng điều khiển, vì vậy các đồng nghiệp có quyền truy cập phù hợp sẽ thấy cùng dữ liệu yêu cầu như bạn.

Những điều cần kiểm tra đầu tiên

Khi một lệnh gọi API thất bại, có một thứ tự tự nhiên để kiểm tra. Việc nhảy ngay vào câu hỏi "model có bị sập không" trước khi xác nhận yêu cầu đã đến đúng điểm cuối hay chưa sẽ gây lãng phí thời gian.

Quy trình phân loại năm trường

Kiểm tra	Thông tin mang lại
Request ID	Xác nhận bạn đang xem đúng lệnh gọi đó, không phải lệnh gọi tương tự
Status	Đã thanh toán, đang chờ, hoàn tiền hoặc thất bại — cho biết đây là câu hỏi về chi phí hay kỹ thuật
Model	Model nào thực sự phục vụ yêu cầu (hữu ích nếu bạn định tuyến qua nhiều model)
Cache state	Liệu việc cache hit hay miss có làm thay đổi chi phí hoặc độ trễ hay không
Key source	API key nào đã được sử dụng, hữu ích khi nhiều key hoặc môi trường chia sẻ chung một tích hợp

Hãy bắt đầu với request ID. Nếu bạn có nó từ nhật ký phía client, phiếu hỗ trợ hoặc báo cáo lỗi, hãy sử dụng mẫu liên kết sâu:

https://tokenlab.sh/en/dashboard/api?tab=requestConsole&requestId=<request_id>

Điều đó sẽ mở trình kiểm tra trực tiếp trên yêu cầu đó, bỏ qua chế độ xem danh sách. Đây là con đường nhanh nhất khi ai đó đưa cho bạn một ID và hỏi "chuyện gì đã xảy ra ở đây".

Nếu bạn chưa có request ID, các bộ lọc của bảng điều khiển cho phép bạn thu hẹp theo model, phạm vi thời gian, trạng thái cache, nguồn key và trạng thái. Một mẫu phổ biến: lọc theo trạng thái "failed" trong vòng một giờ qua, sau đó quét danh sách để tìm lệnh gọi cụ thể mà người dùng đang hỏi.

Đọc đúng trường trạng thái

Bốn trạng thái — billed, pending, refunded, failed — trả lời các câu hỏi khác nhau:

• Billed (Đã thanh toán): nghĩa là lệnh gọi đã hoàn tất và tiêu tốn tín dụng. Nếu người dùng báo cáo lỗi nhưng yêu cầu hiển thị đã thanh toán, điều đó đáng để gắn cờ riêng, vì nó cho thấy lỗi xảy ra ở phía client sau khi nhận phản hồi thành công.
• Pending (Đang chờ): nghĩa là yêu cầu vẫn đang trong quá trình xử lý hoặc chờ quyết toán. Đừng vội coi đây là một thất bại.
• Refunded (Đã hoàn tiền): nghĩa là TokenLab đã đảo ngược khoản phí, thường gắn liền với lỗi từ phía nhà cung cấp hoặc phía định tuyến.
• Failed (Thất bại): nghĩa là lệnh gọi không hoàn tất thành công và không bị tính phí.

Biết được trạng thái nào áp dụng trước khi bạn leo thang vấn đề sẽ giúp tiết kiệm thời gian trao đổi với bộ phận hỗ trợ.

Xác nhận model và trạng thái cache

Nếu bạn đang chạy các yêu cầu với các model như Claude Sonnet 5, DeepSeek V4 Pro hoặc Gemini 3.5 Flash thông qua một tích hợp chia sẻ, hãy xác nhận bảng điều khiển hiển thị đúng model bạn mong đợi. Một client được cấu hình sai, biến môi trường cũ hoặc ghi đè định tuyến có thể gửi lưu lượng truy cập đến sai model mà không có lỗi rõ ràng ở phía client.

Trạng thái cache quan trọng vì hai lý do: chi phí và độ trễ. Một lần cache miss khi bạn mong đợi cache hit thường có nghĩa là tiền tố prompt đã thay đổi, dù chỉ là một chút — dấu thời gian, trường bị sắp xếp lại, một ký tự khoảng trắng thừa. Bộ lọc trạng thái cache của bảng điều khiển cho phép bạn so sánh các yêu cầu hit và miss cạnh nhau.

Cách nó hoạt động với Usage Exports

Request Console và usage exports giải quyết các vấn đề khác nhau, và cần phải làm rõ ranh giới để bạn không sử dụng sai công cụ.

Bảng điều khiển được xây dựng để điều tra từng yêu cầu đơn lẻ: một lệnh gọi, một lỗi, một câu hỏi thanh toán, được trả lời trong bảng kiểm tra. Đó là thứ bạn mở khi một yêu cầu cụ thể thất bại và bạn cần biết tại sao, ngay lập tức.

Usage exports được xây dựng để xem xét tổng hợp: chi tiêu trong một phạm vi thời gian, phân tích theo model hoặc key, và loại báo cáo mà bạn sẽ gửi cho các bên liên quan về tài chính hoặc sử dụng để đối soát hàng tháng. Nếu bạn đang cố gắng trả lời "chúng ta đã chi bao nhiêu cho DeepSeek V4 Pro tuần trước", đó là câu hỏi dành cho export, không phải console. Hãy xem hướng dẫn usage exports trên bảng điều khiển TokenLab cho quy trình đó.

Tóm lại: console cho các sự cố, exports cho tổng số. Một số nhóm sử dụng cả hai theo trình tự — một bản export làm nổi bật sự bất thường trong chi tiêu tổng thể, và console là nơi bạn đi sâu vào các yêu cầu cụ thể đã gây ra điều đó.

Quy trình gỡ lỗi thực tế

Gỡ lỗi tùy hứng sẽ biến thành đoán mò dưới áp lực. Một quy trình có thể lặp lại giúp các sự cố không kéo dài hơn mức cần thiết.

Danh sách kiểm tra: khi một yêu cầu thất bại

1. Lấy request ID. Từ nhật ký client, phản hồi lỗi hoặc báo cáo của người dùng. Nếu hiện tại bạn chưa ghi nhật ký request ID, hãy bắt đầu ngay bây giờ — đó là khóa tra cứu nhanh nhất bạn có.
2. Mở bảng điều khiển bằng liên kết sâu. Sử dụng tham số truy vấn requestId để nhảy thẳng đến trình kiểm tra.
3. Kiểm tra trường trạng thái trước tiên. Billed, pending, refunded hoặc failed — điều này định hình phần còn lại của cuộc điều tra.
4. Xác nhận model thực sự phục vụ yêu cầu. So sánh nó với những gì bạn mong đợi gửi đi.
5. Kiểm tra trạng thái cache. Một lần cache miss khi bạn mong đợi cache hit có thể giải thích độ trễ hoặc chi phí bất ngờ.
6. Kiểm tra nguồn key. Xác nhận đúng API key và môi trường đang được sử dụng, đặc biệt là trong các thiết lập staging-vs-production.
7. Đọc ngữ cảnh lỗi và thông tin định tuyến. Đây thường là nơi nguyên nhân gốc rễ thực sự trở nên rõ ràng.
8. Xem lại bản xem trước nội dung đã ẩn danh. Xác nhận hình dạng yêu cầu khớp với những gì client của bạn đã gửi — các tham số sai định dạng thường xuất hiện ở đây trước khi chúng xuất hiện ở bất kỳ nơi nào khác.
9. Đối chiếu với tài liệu tham khảo API nếu cần. Tài liệu tham khảo API chat completions của TokenLab ghi lại các hình dạng yêu cầu và phản hồi mong đợi, hữu ích để xác nhận liệu nội dung có bị sai định dạng ở phía client hay không.
10. Nếu đó là một mô hình lỗi, không phải sự cố đơn lẻ, hãy chuyển sang usage exports. Một yêu cầu thất bại đơn lẻ là vấn đề của console. Mười yêu cầu thất bại trong một giờ là một mô hình đáng để xuất và xem xét tổng thể.

Tuân theo thứ tự này — ID, trạng thái, model, cache, key, lỗi, nội dung — giúp bạn không bỏ qua trường thực sự giải thích cho sự thất bại.

Các bước tiếp theo

Nếu bạn hiện đang gỡ lỗi các lỗi API AI bằng cách grep qua nhật ký phía client của riêng mình và đối chiếu với bảng điều khiển thanh toán riêng biệt, Request Console sẽ loại bỏ một bước khỏi vòng lặp đó. Hãy bắt đầu bằng cách tìm một yêu cầu thất bại gần đây và mở nó trực tiếp.

• Mở bảng điều khiển và định vị yêu cầu theo ID: https://tokenlab.sh/en/dashboard/api?tab=requestConsole
• Tạo API key TokenLab tại tokenlab.sh/en/dashboard/api để bắt đầu thực hiện các yêu cầu từ bảng điều khiển hoặc tập lệnh của riêng bạn.
• Kiểm tra hình dạng yêu cầu/phản hồi chat completions nếu bạn nghi ngờ nội dung bị sai định dạng: https://docs.tokenlab.sh/api-reference/chat/create-completion
• Để xem xét chi tiêu tổng hợp, hãy sử dụng usage exports thay vì console: https://tokenlab.sh/en/blog/tokenlab-dashboard-usage-exports
• Nếu bạn đang so sánh các model về chi phí hoặc khả năng trước khi chuyển đổi, danh mục model có giá hiện tại và chi tiết cửa sổ ngữ cảnh: https://tokenlab.sh/en/models

Câu hỏi thường gặp

TokenLab Request Console là gì? Đây là chế độ xem gỡ lỗi ở cấp độ yêu cầu bên trong bảng điều khiển API của TokenLab. Nó hiển thị định tuyến, trạng thái thanh toán, trạng thái cache, ngữ cảnh model và key, cùng bản xem trước nội dung đã ẩn danh cho các yêu cầu gần đây, giới hạn trong tổ chức của bạn.

Tôi có thể kiểm tra một yêu cầu bằng request ID không? Có. Sử dụng định dạng liên kết sâu /dashboard/api?tab=requestConsole&requestId=<request_id> để mở trình kiểm tra trực tiếp trên một yêu cầu cụ thể hoặc tìm kiếm theo request ID từ chế độ xem danh sách.

Bảng điều khiển có thay thế usage exports không? Không. Bảng điều khiển dành cho việc điều tra các yêu cầu riêng lẻ — một lỗi, một câu hỏi thanh toán. Usage exports dành cho việc xem xét chi tiêu tổng hợp trong một phạm vi thời gian. Hãy sử dụng cả hai cùng nhau khi một bản export cho thấy một mô hình mà bạn cần đi sâu vào.

Tôi nên kiểm tra gì đầu tiên khi một yêu cầu API AI thất bại? Bắt đầu với request ID để xác nhận bạn đang xem đúng lệnh gọi, sau đó kiểm tra trường trạng thái (billed, pending, refunded, failed), model thực sự phục vụ nó và trạng thái cache. Từ đó, ngữ cảnh lỗi và bản xem trước nội dung thường làm cho nguyên nhân gốc rễ trở nên rõ ràng.

Nguồn và độ mới

• TokenLab Request Console — https://tokenlab.sh/en/dashboard/api?tab=requestConsole — quan sát ngày 2026-07-09
• Tài liệu tham khảo TokenLab Chat Completions API — https://docs.tokenlab.sh/api-reference/chat/create-completion — quan sát ngày 2026-07-09
• TokenLab Dashboard Usage Exports — https://tokenlab.sh/en/blog/tokenlab-dashboard-usage-exports — quan sát ngày 2026-07-09
• Danh mục model công khai của TokenLab — https://tokenlab.sh/en/models — quan sát ngày 2026-07-09

Các ví dụ về model được tham chiếu (Claude Sonnet 5, DeepSeek V4 Pro, Gemini 3.5 Flash) phản ánh SSOT model hiện tại tính đến ngày 2026-07-07. Để biết giá và tình trạng sẵn có chính xác hiện tại, hãy xác minh với liên kết danh mục model ở trên trước khi đưa ra quyết định định tuyến.