Bước inference: chuyển prompt thành mã token

1Định nghĩa

Tách token khi suy luận là bước đổi văn bản của yêu cầu đã tiếp nhận thành mảng số nguyên (token ID), bằng đúng tokenizer của phiên bản mô hình đang phục vụ. Với mô hình chat, bước này còn xếp các tin nhắn theo mẫu hội thoại, chèn thẻ đánh dấu vai trò và thẻ mở đầu lượt trả lời của trợ lý ở cuối chuỗi, để mô hình biết rằng token tiếp theo là phần của nó.

Độ dài thật của mảng token ID là con số chính xác để bộ lập lịch kiểm tra ngân sách ngữ cảnh, tra xem phần đầu chuỗi có đã nằm sẵn trong KV cache hay không và đặt trước vùng nhớ cho pha prefill. Đây là phiên bản phục vụ của bước chuẩn bị dữ liệu trong huấn luyện: cùng bảng từ vựng, cùng quy tắc cắt.

Ví dụ đời thường: Tách token giống quầy lễ tân đóng khung phiếu gọi món theo mẫu chuẩn (dòng nào là lời dặn của khách, dòng nào để trống chờ bếp điền món) rồi bấm thành dãy mã món để màn hình trong bếp đọc ngay. Nếu quầy lễ tân dùng bảng mã món khác với bảng mã của bếp, phiếu vẫn in ra được nhưng bếp sẽ nấu nhầm món mà không ai báo lỗi.

2Luồng

Đây là nửa sau của ô 5A. Mũi tên vào mang văn bản, mũi tên ra mang một dãy số nguyên và độ dài của nó. Cột 1 của sơ đồ làm việc tương tự cho dữ liệu huấn luyện; điểm khác là ở đây không có bước đáp án và không thêm eos vào cuối prompt.

Sơ đồ kiến trúc huấn luyện · 22 ô (1A → 5C)

Kiến trúc huấn luyện LLM · Ánh xạ với Bài Lab tổng hợp

Thứ tự đọc: 1A → 1B ở cột 1, 2A → 2D ở cột 2, 3A → 3E ở cột 3; mũi tên next batch từ 3E quay về cột 1 và mũi tên load weights đi xuống băng 5 (5A → 5C). Cột 4 không phải bước kế tiếp: 4A, 4B tiết kiệm bộ nhớ, còn 4C–4G là các phương pháp huấn luyện thay thế nhau. Di chuột hoặc bấm vào từng ô để đọc pop-over.

Tất cả (22)1. Dữ liệu & nhãn2. Forward3. Học từ sai số4. Quy mô & phương pháp5. Suy luận

Ẩn khung overlay

1A1B1C2A2B2C2D3A3B3C3D3E4A4B4C4D4E4F4G5A5B5C

5A5 · Checkpoint → Inference

chat template · tokenizer · weights đóng băng

5A · Prompt → Token IDs

Điểm vào của suy luận: nhận prompt, kiểm tra rồi đổi thành token ID bằng đúng tokenizer của checkpoint.

Nhận gì

Yêu cầu của người dùng và checkpoint lưu từ ô 3E (mũi tên load weights): trọng số, cấu hình và tokenizer.

Làm gì, vì sao

Nhận prompt hoặc tin nhắn cùng cấu hình sinh, kiểm tra hợp lệ rồi đổi thành token ID bằng đúng mẫu hội thoại và tokenizer đã dùng khi huấn luyện, vì ID chỉ có nghĩa với đúng bảng từ vựng đó. Băng này không học gì: trọng số đóng băng và không có gradient.

Ra gì

Dãy token ID của prompt cùng độ dài thật, đi sang ô 5B (mũi tên sang phải).

Ví dụ, cách đọc ô

Nhãn ô: chat template · tokenizer. Ví dụ trong lab: câu hỏi "meo uong gi" thành 13 token ID sau khi gắn các token user và assistant.

Lưu ý

Nạp nhầm một checkpoint khác cùng cấu hình thường không báo lỗi mà cho đầu ra sai. Chỉ cần bản weights-only, không cần m, v.

Đọc bài 5A · Prompt → Token IDs↗Bài liên quan · Bước inference: chuyển prompt thành mã token↗Giai đoạn 13 trong Bài Lab: Từ checkpoint sang suy luận↗

flowchart TD
  step1["Yêu cầu đã hợp lệ"]
  step2["Áp mẫu hội thoại"]
  step3["Tách token và tra mã"]
  step4["Báo độ dài và chuyển đi"]
  step1 --> step2
  step2 --> step3
  step3 --> step4

3Giải pháp

Vị trí trên sơ đồ: nửa sau của ô 5A "Prompt → token IDs" trong băng "Checkpoint → Inference". Nó nối tiếp nhận yêu cầu với prefill (ô 5B). Nó phản chiếu ô 1A của cột 1, nhưng dùng lại tokenizer đã lưu thay vì xây mới.

Vấn đề cần giải. Mô hình chỉ đọc số, và những con số đó chỉ có nghĩa với đúng bảng từ vựng đã dùng khi học. Nếu ở lúc phục vụ ID 1 nghĩa là “chó” mà lúc huấn luyện ID 1 nghĩa là “mèo”, mô hình sẽ trả lời cho một câu khác hẳn mà không có thông báo lỗi nào.

Khái niệm tối thiểu. Tokenizer gồm bảng từ vựng và quy tắc cắt. Chat template là quy tắc xếp tin nhắn thành chuỗi. Token đặc biệt như eos có ID riêng. Độ dài N là số ID sau khi tách.

Ví dụ có số (minh họa, dùng bảng từ vựng nhỏ của bài chuẩn bị dữ liệu: 0 = pad, 1 = mèo, 2 = chó, 3 = ăn, 4 = cá, 5 = ngủ, 6 = eos). Prompt “mèo ăn” đổi thành [1, 3], N = 2. Khi huấn luyện, token “mèo” cũng có ID 1 và “ăn” cũng là 3, nên mô hình nhận ra chuỗi này. Với max_tokens = 8, bộ lập lịch cần đặt trước chỗ cho tối đa N + 8 = 10 vị trí.

Hai chi tiết dễ sai. (1) Không thêm eos vào cuối prompt: ở dữ liệu huấn luyện eos đánh dấu hết một tài liệu, nên prompt kết thúc bằng eos nói với mô hình rằng câu đã xong và token kế tiếp sẽ thuộc một tài liệu khác. (2) Từ chưa có trong bảng: tokenizer mức từ như ví dụ này phải báo lỗi chứ không được tự bịa ID; tokenizer BPE thật tách từ lạ thành các mảnh nhỏ đã có trong bảng nên không gặp tình huống này.

Chat template. Giả sử mô hình được fine-tune với mẫu: dòng “User:” theo sau là câu hỏi, rồi dòng “Assistant:” để mô hình viết câu trả lời. Khi phục vụ, chuỗi phải được dựng đúng mẫu đó và dừng sau thẻ “Assistant:” (để mô hình viết tiếp), vì mô hình chỉ học trả lời ở vị trí ấy. Dùng mẫu khác lúc fine-tune là một nguyên nhân phổ biến của câu trả lời kém dù trọng số không sai (xem phương pháp fine-tuning).

Cách đọc đầu ra. Kết quả là một hàng token ID cùng độ dài N (shape (1, N), 1 là số yêu cầu, N là số vị trí), không còn chữ nào. Điều có thể kết luận: nếu giải mã (decode) mảng này ra đúng văn bản đã gửi (cộng thẻ mẫu), tokenizer và mẫu nhất quán. Điều không thể kết luận: số từ không bằng số token; một từ tiếng Việt có thể thành nhiều token, nên không ước tính ngân sách ngữ cảnh bằng số từ.

Dùng lại checkpoint và cầu nối sang Inference Engineering. Tokenizer được phát hành cùng mô hình và phải ghim vào manifest triển khai cùng trọng số. Chuẩn bị đầu vào thường chạy trên CPU rồi chuyển tensor sang thiết bị; có thể gộp hoặc chạy song song khi nó thành điểm nghẽn. Phần chuyển văn bản thành đơn vị mà mô hình hiểu giải thích sâu hơn về BPE và chat template, còn bộ lập lịch cho thấy vì sao độ dài chính xác lại quan trọng với việc đặt bộ nhớ.

Để thấy một prompt được đổi thành ID bằng đúng bảng từ vựng của checkpoint (ký tự ngoài bảng báo lỗi), mở giai đoạn 13 · Từ checkpoint sang suy luận của Bài Lab tổng hợp. Hãy tự dự đoán N của một prompt ngắn trước khi chạy.

4Profiling

• Thời gian chuẩn bị đầu vào

  Kiểm tra tính đúng trước (mã hóa rồi giải mã ra lại văn bản, mẫu hội thoại giống lúc huấn luyện). Sau đó đo riêng thời gian dựng mẫu, tách token, đóng gói và chuyển dữ liệu sang thiết bị. Nếu phần này đáng kể so với prefill, mới đáng cân nhắc tối ưu.

• Độ dài sau khi tách token

  Ghi phân phối số token thật (p50, p95, lớn nhất) và kiểm tra giới hạn dựa trên token chứ không dựa trên số từ hay số ký tự. Độ dài này quyết định bộ nhớ và thời gian prefill nên phải khớp với số bộ lập lịch dùng.

• Khớp với lúc huấn luyện

  Lấy vài mẫu từ tập huấn luyện, dựng prompt bằng đường phục vụ và so từng ID với đường chuẩn bị dữ liệu. Chúng phải trùng nhau. Nếu khác ở thẻ vai trò hay khoảng trắng, mô hình đang nhận một đầu vào khác với đã học.

Mẹo đo lường: ghim số liệu trên workload thật, ghi cả p50/p95/p99 thay vì chỉ trung bình, và luôn ghi lại điều kiện chạy (batch, cache, đồng thời, phần cứng) trước và sau khi tối ưu. Số đo thiếu điều kiện chạy thì không so sánh được.

5Ví dụ

6Thuật ngữ

Tokenizer của checkpoint

Bảng từ vựng và quy tắc cắt token đã dùng khi huấn luyện, lưu cùng trọng số; đổi nó là đổi nghĩa của mọi token ID.

Chat template

Quy tắc xếp các lượt hội thoại thành một chuỗi có ký hiệu vai trò và thẻ mở lượt trả lời của trợ lý; phải giống lúc fine-tune.

Token ID

Số nguyên xác định token trong bảng từ vựng; cùng một chữ có thể ra ID khác nếu dùng tokenizer khác.

Độ dài prompt (N)

Số token thật sau khi tách. Bộ lập lịch dùng N cộng max_tokens để đặt trước bộ nhớ.

Token đặc biệt

Token như eos (hết chuỗi) hoặc thẻ vai trò; không phải chữ người dùng nhập và cần được chèn đúng chỗ.

7Bài liên quan

8Nguồn