TokenLab Request Console: Gỡ lỗi các lệnh gọi AI API 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ột 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. Chúng tôi đã xây dựng TokenLab Request Console để thu hẹp khoảng cách đó bằng cách đưa các chi tiết ở cấp độ yêu cầu vào một chế độ xem bảng điều khiển duy nhất. Nó hiển thị model, key, trạng thái bộ nhớ đệm, trạng thái thanh toán, thời gian và bản xem trước payload đã được ẩn danh. Trong pipeline của chúng tôi, chúng tôi coi ID yêu cầu là khóa tra cứu đầu tiên.

Những điểm chính

• TokenLab Request Console là bề mặt gỡ lỗi ở cấp độ yêu cầu bên trong bảng điều khiển API 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. Bạn có thể liên kết sâu (deep-link) đến một yêu cầu cụ thể bằng requestId trong URL.
• Bảng điều khiển hiển thị định tuyến, trạng thái thanh toán, trạng thái bộ nhớ đệm, ngữ cảnh model/key và bản xem trước payload đã ẩ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 các quyền thành viên trong bảng điều khiển — các thành viên trong nhóm chỉ thấy những gì vai trò của họ cho phép.
• Để gỡ lỗi 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 tính năng xuất dữ liệu sử dụng (usage exports).

TokenLab Request Console là gì

Bạn có thể truy cập nó tại /dashboard/api?tab=requestConsole, bên trong phần API của bảng điều khiển TokenLab. Bản thân bảng điều khiển API nằm tại /dashboard/api. Bảng điều khiển này đượ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ó toàn bộ ngữ cảnh trước mắt, thay vì đoán mò dựa trên thông báo lỗi.

Phần mô tả trong bảng điều khiển gọi đây là 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. Chúng tôi chia nó 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ó truy cập bộ nhớ đệm 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ể đó. Bạn không cần phải đối chiếu với một 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 Payload. 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, cung cấp cho bạn hình dạng và cấu trúc mà không làm lộ các thông tin bí mật trong nội dung.

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

Không có bước nào trong số này yêu cầu bạn phải tự xây dựng pipeline ghi nhật ký trên API. Nó đã được hiển thị cho mỗi tổ chức, được lọc theo quyền thành viên bảng điều khiển, vì vậy các thành viên trong nhóm 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 gì 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 endpoint hay chưa sẽ gây lãng phí thời gian.

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 chính xác lệnh gọi đang được đề cập, không phải lệnh gọi tương tự
Trạng thái	Đã thanh toán, đang chờ xử lý, được hoàn tiền hoặc thất bại — cho biết đây là vấn đề chi phí hay vấn đề 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)
Trạng thái bộ nhớ đệm	Liệu việc truy cập bộ nhớ đệm (cache hit/miss) có làm thay đổi chi phí hoặc độ trễ hay không
Nguồn Key	API key nào đã được sử dụng, hữu ích khi nhiều key hoặc môi trường chia sẻ một tích hợp

Hãy bắt đầu với ID yêu cầu. 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:

/dashboard/api?tab=requestConsole&requestId=%3Crequest_id>

Điều đó mở trình kiểm tra trực tiếp trên yêu cầu đang được đề cập, bỏ qua hoàn toàn 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ó ID yêu cầu, 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 bộ nhớ đệm prompt, nguồn key và trạng thái. Ví dụ: khi một yêu cầu thất bại, hãy lọc theo trạng thái 'failed' trong 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 (đã thanh toán), pending (đang chờ xử lý), refunded (đã hoàn tiền), failed (thất bại) — trả lời các câu hỏi khác nhau:

• Billed 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 được gắn cờ riêng. Nó cho thấy lỗi xảy ra ở phía client sau khi nhận được phản hồi thành công.
• Pending nghĩa là yêu cầu vẫn đang được thực hiện hoặc đang chờ quyết toán. Đừng vội coi đây là một thất bại.
• Refunded nghĩa là TokenLab đã hoàn lại khoản phí, thường liên quan đến lỗi từ phía nhà cung cấp hoặc phía định tuyến.
• Failed 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 qua lại với bộ phận hỗ trợ.

Xác nhận model và trạng thái bộ nhớ đệm

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ị model bạn mong đợi. Một client được cấu hình sai, một biến môi trường cũ hoặc một 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 bộ nhớ đệm quan trọng vì hai lý do: chi phí và độ trễ. Việc cache miss (không tìm thấy trong bộ nhớ đệm) trong khi bạn mong đợi cache hit (tìm thấy) thường có nghĩa là tiền tố prompt đã thay đổi, dù chỉ là một chút. Hãy tìm dấu thời gian, một trường bị sắp xếp lại hoặc một ký tự khoảng trắng thừa. Bộ lọc trạng thái bộ nhớ đệm 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 TokenLab Request Console hoạt động với Usage Exports

Request Console và usage exports giải quyết các vấn đề khác nhau, vì vậy cần làm rõ ranh giới giữa chúng. 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 muốn trả lời 'chúng ta đã chi bao nhiêu cho DeepSeek V4 Pro vào tuần trước', đó là câu hỏi dành cho export, không phải bảng điều khiển. Hãy xem hướng dẫn xuất dữ liệu sử dụng của bảng điều khiển TokenLab cho quy trình đó.

Tóm lại: bảng điều khiển cho các sự cố, export 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 hợp, và bảng điều khiển 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 ad hoc 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 ID yêu cầu. 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 bạn chưa ghi nhật ký ID yêu cầu ở phía mình, 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. 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 bộ nhớ đệm. Một cache miss trong 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 payload đã ẩ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 tại https://docs.tokenlab.sh/api-reference/chat/create-completion ghi lại các hình dạng yêu cầu và phản hồi dự kiến. Sử dụng nó để xác nhận liệu payload có bị sai định dạng ở phía client hay không.
10. Nếu đó là một mô hình, không phải trường hợp đơ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 bảng điều khiển. 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 hợp.

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

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

Làm thế nào để tìm một yêu cầu thất bại mà không có ID yêu cầu?

Sử dụng các bộ lọc chế độ xem danh sách trong TokenLab Request Console. Thu hẹp theo model, phạm vi thời gian, trạng thái bộ nhớ đệm prompt, nguồn key và trạng thái. Ví dụ: lọc theo trạng thái 'failed' trong giờ qua, sau đó quét tìm lệnh gọi mà người dùng đang hỏi. Khi tìm thấy, hãy mở trình kiểm tra và sao chép ID yêu cầu cho các nhật ký trong tương lai.

Tại sao một yêu cầu hiển thị đã thanh toán khi client báo cáo lỗi?

Billed 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, lỗi có khả năng xảy ra ở phía client sau khi nhận được phản hồi thành công. Hãy gắn cờ trường hợp đó riêng vì nó chỉ ra con đường khắc phục khác với yêu cầu thất bại hoặc được hoàn tiền.

Cache miss cho tôi biết điều gì trong trình kiểm tra?

Cache miss nghĩa là yêu cầu không tìm thấy trong bộ nhớ đệm prompt. Điều đó quan trọng đối với chi phí và độ trễ. Một lần miss trong khi bạn mong đợi hit thường có nghĩa là tiền tố prompt đã thay đổi, dù chỉ là một chút. Hãy kiểm tra dấu thời gian, một trường bị sắp xếp lại hoặc một ký tự khoảng trắng thừa.

Tôi có thể chia sẻ liên kết yêu cầu với thành viên trong nhóm không?

Có, nếu quyền thành viên bảng điều khiển của họ cho phép. Dữ liệu yêu cầu được giới hạn trong tổ chức của bạn. 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. Các thành viên trong nhóm thấy những gì vai trò của họ cho phép.

Khi nào tôi nên chuyển từ bảng điều khiển sang usage exports?

Chuyển đổi khi vấn đề là một mô hình, không phải trường hợp đơn lẻ. Một yêu cầu thất bại đơn lẻ là vấn đề của bảng điều khiển. 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 hợp. Sử dụng export cho chi tiêu trong một phạm vi thời gian, phân tích theo model hoặc key và đối soát hàng tháng.

Nguồn và độ mới

• TokenLab Request Console — /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 — /blog/tokenlab-dashboard-usage-exports — quan sát ngày 2026-07-09
• Danh mục model công khai của TokenLab — /models — quan sát ngày 2026-07-09
• Bảng điều khiển API key của TokenLab — /dashboard/api — 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-09-19. Ảnh chụp nhanh nguồn cho ghi chú bảng điều khiển này được quan sát vào ngày 2026-07-09; ngày SSOT model gốc trong nguồn là 2026-07-07.

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 và đối chiếu với một 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 đó. Bảng điều khiển nằm tại /dashboard/api?tab=requestConsole. Bảng điều khiển API key nằm tại tokenlab.sh/dashboard/api. Hình dạng yêu cầu/phản hồi chat completions được ghi lại tại 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. Để biết chi tiết về giá model và cửa sổ ngữ cảnh, hãy xem danh mục model. Hãy mở bảng điều khiển và định vị một yêu cầu thất bại gần đây theo ID.