Bước inference: tiếp nhận prompt và yêu cầu sinh

1Định nghĩa

Tiếp nhận yêu cầu suy luận là điểm bắt đầu của đường phục vụ (serving path): người dùng gửi một prompt hoặc danh sách tin nhắn hội thoại, và hệ thống kiểm tra rồi quyết định có nhận hay không. Khác với huấn luyện cần cả dữ liệu lẫn đáp án, suy luận chỉ nhận ngữ cảnh đầu vào kèm các tham số điều khiển cách sinh chữ như max_tokens, temperature, top_p và stop; đáp án là thứ mô hình sẽ tự tạo ra.

Tại đây cổng tiếp nhận và router xác thực quyền, kiểm tra phiên bản checkpoint đang phục vụ và đối chiếu giới hạn độ dài ngữ cảnh, trước khi chuyển yêu cầu xuống bước tách token. Checkpoint mà bản sao mô hình nạp chính là thứ vòng lặp huấn luyện đã lưu.

Ví dụ đời thường: Tiếp nhận yêu cầu giống quầy lễ tân nhận phiếu đặt món của thực khách: nhân viên kiểm tra món có trong thực đơn hiện hành không, ghi lại yêu cầu riêng (ít đường, nhiều đá, tương ứng temperature và max_tokens) và nếu bếp đang quá tải thì nói rõ ‘xin chờ hoặc quay lại sau’ thay vì nhận bừa. Khác nhà hàng, thực đơn ở đây chính là phiên bản mô hình, và nhận nhầm phiên bản có thể cho ra câu trả lời hoàn toàn khác mà không báo lỗi.

2Luồng

Băng dưới của sơ đồ (Checkpoint → Inference) bắt đầu từ checkpoint ghi ở ô 3E. Bài này là nửa đầu của ô 5A: mũi tên mang một yêu cầu đã kiểm tra, chưa có token ID nào. Ô 5A xong khi tokenizer đã biến yêu cầu thành mảng số.

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["Nhận yêu cầu"]
  step2["Kiểm tra quyền và giới hạn"]
  step3["Quyết định tiếp nhận"]
  step4["Chọn bản sao mô hình"]
  step5["Chuyển sang tách token"]
  step1 --> step2
  step2 --> step3
  step3 --> step4
  step4 --> step5

3Giải pháp

Vị trí trên sơ đồ: băng dưới "Checkpoint → Inference", ô 5A "Prompt → token IDs". Ô này gồm hai nửa; bài này là nửa đầu (nhận và kiểm tra yêu cầu), bài tách token là nửa sau. Điều làm băng dưới khác cột 1 đến 4: nó không học gì. Nó dùng lại checkpoint mà ô 3E (vòng lặp, eval, checkpoint) đã lưu và chỉ chạy forward với trọng số đóng băng.

Vấn đề cần giải. Khi huấn luyện, ta kiểm soát toàn bộ dữ liệu. Khi phục vụ, yêu cầu đến từ ngoài, kích thước, tốc độ và ý định không biết trước, mà tài nguyên GPU có hạn. Cần một cổng nhận có kiểm tra để một yêu cầu xấu hoặc quá lớn không làm hỏng các yêu cầu khác.

Khái niệm tối thiểu. Yêu cầu gồm đầu vào (prompt hoặc tin nhắn) và cấu hình sinh. max_tokens là số token mới tối đa được sinh. Context window là tổng số token tối đa của prompt cộng phần sinh. Admission control là quyết định nhận hay từ chối. Mô hình đang phục vụ được xác định bởi checkpoint (trọng số, cấu hình, tokenizer).

Ví dụ có số (minh họa). Yêu cầu: tin nhắn “mèo ăn”, max_tokens = 8, temperature = 0 (luôn chọn token điểm cao nhất), stop = [“.”]. Giả sử context window của mô hình đang phục vụ là 4.096. Với prompt vài token thì 4.096 dư thừa. Nhưng với một yêu cầu có 3.900 token trong prompt và max_tokens = 300, tổng là 4.200, vượt 4.096 là 104 token; hệ thống phải từ chối với lý do rõ ràng, hoặc hạ max_tokens xuống 196 nếu chính sách cho phép.

Từng thao tác và lý do. (1) Xác thực và hạn mức: biết ai gửi, và giới hạn mỗi người để một người không chiếm hết GPU (xem bài về an toàn và cô lập dữ liệu). (2) Kiểm tra định dạng và phạm vi: max_tokens không âm, temperature trong khoảng hợp lệ, stop không quá dài; nhờ vậy lỗi bị bắt ở cổng thay vì làm hỏng engine. (3) Gắn với phiên bản checkpoint: yêu cầu phải chạy trên đúng mô hình, vì tokenizer và trọng số đi cùng nhau. (4) Admission control: hàng đợi có giới hạn; khi đầy thì trả ‘thử lại sau’ thay vì nhận vô hạn. (5) Chọn bản sao mô hình (router) và đặt thời hạn xử lý. Kiểm tra độ dài chính xác cần số token thật, nên được hoàn tất sau khi tách token.

Cách đọc đầu ra. Kết quả là một đối tượng yêu cầu đã hợp lệ có mã yêu cầu, cấu hình sinh, thời hạn và bản sao được chọn, hoặc một lời từ chối có nguyên nhân. ‘Đã nhận’ chỉ nghĩa là đã vào hàng đợi, chưa phải đã xong, và không bảo đảm thời gian trả lời. Thành phần này không chứa bất cứ kết luận nào về chất lượng câu trả lời.

Dùng lại checkpoint đã huấn luyện. Bản sao mô hình nạp từ checkpoint: trọng số, cấu hình (số lớp, chiều rộng, kích thước bảng từ vựng) và tokenizer. Nó không cần m, v của AdamW hay gradient, nên chiếm ít bộ nhớ hơn lúc huấn luyện. Phần kiểm tra phiên bản bảo đảm bản sao đang chạy đúng checkpoint mà tokenizer và cấu hình tương ứng; xem checkpoint và việc nạp mô hình.

Cầu nối sang khóa Inference Engineering. Khóa đó đi sâu vào từng phần của ô này: cổng tiếp nhận và kiểm soát yêu cầu, chọn bản sao, hàng đợi và vì sao nó tăng mạnh gần hết năng lực, cô lập người dùng và giữ dịch vụ ổn định. Một kiến trúc phổ biến tách cổng dịch vụ khỏi các máy chạy mô hình: cổng giữ quy tắc chung, máy chạy mô hình tập trung vào tính toán. Hàng đợi hữu hạn, kiểm tra thời hạn và truyền tín hiệu hủy tới engine là ba biện pháp quan trọng; nếu khách ngắt kết nối mà engine vẫn sinh token, tài nguyên tiếp tục bị lãng phí.

Để thấy checkpoint huấn luyện được nạp nguyên vẹn vào một yêu cầu suy luận mà không khởi tạo mô hình 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ếu nạp nhầm checkpoint của một lần huấn luyện khác thì kết quả có báo lỗi không?

4Profiling

• Thời gian chờ trước engine

  Kiểm tra trước rằng yêu cầu hợp lệ được nhận và yêu cầu vi phạm giới hạn bị từ chối đúng lý do. Sau đó ghi dấu thời gian lúc nhận và lúc engine bắt đầu chạy, xem cả đuôi phân phối (p95, p99) chứ không chỉ trung bình, vì người dùng nhớ những lần chờ lâu. Báo kèm tải đồng thời lúc đo.

• Tỷ lệ từ chối và hủy

  Đếm theo nguyên nhân: hạn mức, quá dài, hàng đợi đầy, người dùng hủy. Với yêu cầu bị hủy, kiểm tra bộ nhớ riêng của nó được trả lại chứ không chỉ kiểm tra mã lỗi trả về; đây là lỗi dễ gây rò rỉ tài nguyên mà biểu đồ lỗi không cho thấy.

• Khớp phiên bản checkpoint

  Ghi mã băm hoặc nhãn phiên bản của checkpoint trên mỗi bản sao và so với phiên bản mà cổng định phục vụ. Một bản sao nạp nhầm checkpoint có thể vẫn trả lời trôi chảy, nên lỗi này chỉ lộ ra qua đối chiếu phiên bản chứ không qua thông báo lỗi.

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ữ

Application Programming Interface (API)

Giao diện lập trình: cách một chương trình gửi yêu cầu tới chương trình khác theo định dạng đã quy định, ở đây là gửi prompt và nhận câu trả lời.

Cấu hình sinh

Các tham số điều khiển cách sinh chữ: max_tokens (tối đa bao nhiêu token mới), temperature và top_p (độ ngẫu nhiên khi chọn token), stop (chuỗi dừng).

Context window

Số token tối đa mà mô hình xử lý được trong một chuỗi; prompt cộng số token được phép sinh không được vượt quá nó.

Admission control

Quyết định nhận hay từ chối công việc dựa trên giới hạn tài nguyên và thời gian, để bảo vệ các yêu cầu đã nhận.

Phiên bản checkpoint

Dấu nhận biết bộ trọng số, cấu hình và tokenizer đang được phục vụ; yêu cầu chỉ có nghĩa với đúng phiên bản đó.

7Bài liên quan

8Nguồn