TokenLab Console không còn mang lại cảm giác chỉ là một bảng điều khiển đối với chúng tôi khi chế độ hỗ trợ lập trình và chế độ ứng dụng AI được hợp nhất thành một giao diện làm việc duy nhất. Trong quy trình của chúng tôi, yêu cầu, phản hồi và trạng thái tài khoản liên quan giờ đây nằm cùng một chỗ. Điều đó loại bỏ việc phải chuyển đổi ngữ cảnh trong mỗi phiên làm việc và thay đổi cách chúng ta đọc một phản hồi chậm.
Những điểm chính cần lưu ý
- Chế độ hỗ trợ lập trình và chế độ ứng dụng AI hiện cùng nằm trong TokenLab Console; hai điểm truy cập cũ đã được hợp nhất vào đây.
- Các liên kết hiện có vẫn hoạt động và các cuộc trò chuyện trước đó vẫn còn đó. Không có gì cần phải di chuyển thủ công.
- Phản hồi được truyền phát (stream) khi mô hình tạo ra chúng thay vì chỉ xuất hiện ở cuối. Giao diện hiển thị thời gian nhận token đầu tiên.
- Độ trễ token đầu tiên là một tín hiệu yêu cầu được ghi lại (
ttft_mstrong nhật ký yêu cầu), không chỉ là một trang trí trên giao diện. - Khi số dư thấp giữa chừng cuộc trò chuyện, mục nạp tiền sẽ xuất hiện ngay cạnh cuộc trò chuyện thay vì nằm trong trang thanh toán riêng biệt.
- Việc lựa chọn mô hình của Console tuân theo danh mục công khai; hãy kiểm tra danh mục mô hình để biết các tùy chọn hiện tại. Các ví dụ trong danh mục hiện tại bao gồm Claude Sonnet 5 và DeepSeek V4 Pro.
Những gì đã thay đổi trong TokenLab Console và những gì không
Thay đổi này được phát hành dưới dạng hai mục trong nhật ký thay đổi. Sự hội tụ của Console (2026-08-04) đã di chuyển hai điểm truy cập cũ vào một Console duy nhất. Tính năng truyền phát trò chuyện trên Console (2026-08-18) đã thêm tính năng truyền phát vào trò chuyện. Hai thay đổi này cách nhau một tháng, vì vậy các nhóm bỏ lỡ mục đầu tiên vẫn nhận được mục thứ hai miễn phí.
Đây là thay đổi về giao diện, không phải thay đổi về hành vi. Các lệnh gọi mô hình, khóa (key) và thanh toán vẫn không thay đổi. Các liên kết cũ vẫn hoạt động và các cuộc trò chuyện hiện có được bảo toàn sau khi hợp nhất. Không có bước di chuyển thủ công nào cả.
Bước hội tụ tập trung vào các điểm truy cập, không phải quyền truy cập mô hình. Bước truyền phát tập trung vào cách phản hồi xuất hiện, không phải cách tính phí token. Điều đó quan trọng vì một thay đổi về giao diện sản phẩm có thể che giấu một thay đổi về hành vi, và lần này thì không. Chế độ hỗ trợ lập trình và chế độ ứng dụng AI hiện chia sẻ một nơi, vì vậy quyết định đầu tiên trong một phiên làm việc không còn là chọn điểm truy cập nào để mở nữa.
Nếu nhóm của bạn có các runbook trỏ đến các điểm truy cập cũ, hãy cập nhật nhãn khi có thể. Các liên kết cũ vẫn hoạt động nên runbook sẽ không bị hỏng. Console là nơi để đánh dấu cho công việc mới. Khi bạn chọn một mô hình ở bất kỳ chế độ nào, lựa chọn đó tuân theo danh mục công khai, vì vậy hãy kiểm tra danh mục mô hình. Các ví dụ trong danh mục hiện tại bao gồm Claude Sonnet 5 và DeepSeek V4 Pro.
Truyền phát trong TokenLab Console thay đổi cách bạn đọc một phiên làm việc
Truyền phát thay đổi khoảnh khắc bạn biết điều gì đó đang xảy ra. Trong quy trình của chúng tôi, máy khách cổng Console xây dựng các yêu cầu trò chuyện truyền phát và phản hồi hiển thị dần dần. Giao diện hiển thị thời gian nhận token đầu tiên, vì vậy bạn có thể thấy khi nào mô hình bắt đầu trả lời. Console cũng ghi lại tín hiệu đó dưới dạng ttft_ms, một cột tùy chọn trong nhật ký yêu cầu.
Thời gian nhận token đầu tiên cho bạn biết khi nào token đầu tiên đến, trong khi tổng độ trễ cho bạn biết khi nào toàn bộ phản hồi hoàn tất. Đó là những câu hỏi khác nhau, vì vậy khi một phản hồi có vẻ chậm, hãy kiểm tra ttft_ms trước. Nếu token đầu tiên đến muộn, thời gian chờ nằm ở trước quá trình tạo. Nếu token đầu tiên đến sớm và phản hồi kéo dài, thời gian chờ nằm ở phần còn lại của luồng.
Khi chúng tôi theo dõi một phiên làm việc chậm, chúng tôi so sánh ttft_ms với các bằng chứng yêu cầu còn lại thay vì đoán từ vòng quay tải. Bằng chứng cấp yêu cầu được giới hạn trong tổ chức và bao gồm định tuyến, trạng thái thanh toán, trạng thái bộ nhớ đệm, cũng như ngữ cảnh mô hình và khóa đằng sau một yêu cầu. Console hiển thị cùng một bản ghi yêu cầu mà bạn thường phải tìm trong nhật ký.
Một ví dụ thực tế về việc đọc tín hiệu token đầu tiên:
# Nhật ký yêu cầu của Console hiển thị `ttft_ms` dưới dạng một cột tùy chọn.
# 1. Lọc nhật ký yêu cầu đến yêu cầu bạn đang kiểm tra.
# 2. Đọc `ttft_ms`.
# 3. So sánh `ttft_ms` với tổng độ trễ của yêu cầu trong cùng một hàng.
Để biết cấu trúc yêu cầu truyền phát chính xác, hãy sử dụng tài liệu API TokenLab hiện tại. Một ví dụ yêu cầu được sao chép với các trường tự chế sẽ ít hữu ích hơn so với trang tài liệu sở hữu các tên đó.
Truyền phát không thay đổi những gì bạn bị tính phí, vì cùng một lượng token được tạo ra nhưng chúng hiển thị ngay khi đến. Vì phản hồi hiện được truyền phát, một phiên bị gián đoạn vẫn hiển thị phản hồi một phần thay vì không có gì. Điều đó thay đổi cách bạn chẩn đoán lỗi giữa phiên. Đối với các công việc chạy lâu mà luồng trò chuyện không bao quát được, hãy xem hướng dẫn về các tác vụ tạo hình ảnh bất đồng bộ.
Cách xác minh một phiên làm việc chậm mà không cần đoán
Hãy bắt đầu với nhật ký yêu cầu, không phải vòng quay tải, vì cột ttft_ms cho bạn biết khi nào token đầu tiên đến. Nếu con số đó cao, mô hình chưa bắt đầu trả lời. Nếu con số đó thấp, mô hình đã bắt đầu sớm và luồng còn lại mới tốn thời gian. Sự phân tách đó giúp bạn không đổ lỗi cho sai phần của đường truyền.
Bản ghi yêu cầu được giới hạn trong tổ chức của bạn. Nó bao gồm tuyến đường đã phục vụ yêu cầu, trạng thái thanh toán, trạng thái bộ nhớ đệm, cũng như ngữ cảnh mô hình và khóa. Các trường đó nằm cùng nhau, vì vậy bạn có thể đọc phiên làm việc như một sự kiện duy nhất thay vì ghép nối các trang riêng biệt. Cùng một bản ghi yêu cầu có sẵn trong bảng điều khiển, giúp ích khi so sánh chế độ xem Console với dữ liệu cấp tài khoản. Hướng dẫn Request Console giải thích nơi lưu trữ bằng chứng đó.
Ví dụ, nếu token đầu tiên đến sớm và phản hồi kéo dài, ttft_ms không phải là tín hiệu chính, vì phần còn lại của luồng mới là vấn đề. Bạn có thể xem tuyến đường và trạng thái bộ nhớ đệm trong cùng một bản ghi yêu cầu. Bạn có thể kiểm tra xem yêu cầu có truy cập bộ nhớ đệm hay đi đến mô hình. Bạn có thể thấy khóa và ngữ cảnh mô hình nào đã được đính kèm.
Không có điều nào trong số đó tự nó kể toàn bộ câu chuyện, nhưng cùng nhau chúng cung cấp cho bạn nơi để tìm kiếm. Khi chúng tôi theo dõi một phiên làm việc chậm, nhật ký yêu cầu có các chi tiết chúng tôi cần. Chúng tôi so sánh ttft_ms với các bằng chứng cấp yêu cầu khác trước khi đưa ra kết luận.
Quy trình tương tự cũng hữu ích khi một yêu cầu thất bại hoặc tạm dừng do số dư. Bản ghi yêu cầu bao gồm trạng thái thanh toán, vì vậy lỗi không còn là điều bí ẩn. Mục nạp tiền nằm cạnh cuộc trò chuyện, vì vậy cách khắc phục vẫn nằm trong cùng một cửa sổ. Bạn không cần rời khỏi phiên làm việc để tìm bước tiếp theo, vì vậy bạn có thể nạp tiền và sau đó tiếp tục.
Nếu số dư ổn, bạn có thể chuyển sang định tuyến, trạng thái bộ nhớ đệm hoặc lựa chọn mô hình. Vấn đề là đọc bằng chứng cấp yêu cầu theo thứ tự. Đầu tiên hãy hỏi khi nào token đầu tiên đến, sau đó hỏi tuyến đường nào đã phục vụ nó, và sau đó hỏi bản ghi nói gì về thanh toán, bộ nhớ đệm, mô hình và ngữ cảnh khóa. Thứ tự đó rất đơn giản và nó khớp với cách Console trình bày dữ liệu.
Hạn chế
Truyền phát hiển thị tiến trình, không phải thông lượng, vì một luồng có thể bắt đầu nhanh nhưng vẫn mất nhiều thời gian để hoàn thành. Một token đầu tiên nhanh không chứng minh toàn bộ yêu cầu là nhanh. Thời gian nhận token đầu tiên cũng phụ thuộc vào mô hình và tuyến đường. Hãy so sánh trong cùng một mô hình thay vì giữa các mô hình khác nhau.
Sự thay đổi trong ttft_ms có thể phản ánh định tuyến, trạng thái bộ nhớ đệm hoặc lựa chọn mô hình, không chỉ là prompt. Hãy coi ttft_ms là một tín hiệu trong nhật ký yêu cầu. Hãy ghép nó với các bằng chứng cấp yêu cầu khác trước khi đưa ra kết luận. Đây là giao diện để đọc một phiên làm việc, không phải là điểm chuẩn để xếp hạng các mô hình.
Console không biến luồng trò chuyện thành trình chạy tác vụ. Nếu bạn có một tác vụ hình ảnh chạy lâu, hãy sử dụng hướng dẫn về các tác vụ tạo hình ảnh bất đồng bộ thay vì giữ luồng trò chuyện mở. Giao diện truyền phát dành cho các phản hồi đến từng token một. Hướng dẫn bất đồng bộ dành cho công việc chạy bên ngoài phản hồi trò chuyện.
Cũng cần nhớ rằng bằng chứng cấp yêu cầu được giới hạn trong tổ chức, điều này gắn một yêu cầu với ngữ cảnh tài khoản xung quanh nó. Điều đó cũng có nghĩa là bạn không nên coi một yêu cầu là điểm chuẩn toàn cầu. Bản ghi bao gồm định tuyến, trạng thái thanh toán, trạng thái bộ nhớ đệm, cũng như ngữ cảnh mô hình và khóa cho yêu cầu đó. Đó là một nơi tuyệt vời để bắt đầu chẩn đoán. Nó không phải là bảng xếp hạng các nhà cung cấp hoặc mô hình. Khi chúng tôi so sánh các phiên làm việc, chúng tôi so sánh trong cùng một mô hình và cùng một nhóm tuyến đường, điều này giúp việc so sánh trở nên công bằng.
Câu hỏi thường gặp
Các liên kết Console cũ của tôi có còn hoạt động không?
Có. Các liên kết cũ vẫn hoạt động và các cuộc trò chuyện hiện có được bảo toàn sau khi hợp nhất. Không có gì cần phải di chuyển thủ công. Nếu bạn đã đánh dấu một trang Console, nó vẫn hoạt động.
Thời gian nhận token đầu tiên thực sự đo lường điều gì?
Nó đo lường thời điểm token đầu tiên đến trong một phản hồi truyền phát, và Console hiển thị nó trong giao diện cũng như ghi lại dưới dạng ttft_ms, một cột tùy chọn trong nhật ký yêu cầu. Nó không đo lường tổng độ trễ hoặc thông lượng.
Tôi nạp tiền ở đâu khi cuộc trò chuyện hết số dư?
Sử dụng mục nạp tiền bên cạnh cuộc trò chuyện, xuất hiện khi số dư thấp giữa chừng cuộc trò chuyện, vì vậy bạn có thể xử lý số dư mà không cần rời khỏi phiên làm việc. Trang thanh toán trong bảng điều khiển vẫn là nơi dành cho các công việc tài khoản rộng hơn.
Tôi có thể so sánh thời gian nhận token đầu tiên giữa các mô hình khác nhau không?
Không, đó không phải là một sự so sánh rõ ràng. Thời gian nhận token đầu tiên phụ thuộc vào mô hình và tuyến đường, vì vậy hãy so sánh trong cùng một mô hình thay vì giữa các mô hình khác nhau. Sử dụng ttft_ms như một tín hiệu cấp yêu cầu, không phải là xếp hạng mô hình.
Tạo khóa API và chạy một phiên làm việc trong Console mới tại bảng điều khiển.
Nguồn
- TokenLab changelog: Console convergence and streamingQuan sát ngày 2026-09-19
- TokenLab dashboardQuan sát ngày 2026-09-19
