6. Suy luận hoàn toàn bằng số nguyên — Quantization trong Deep Learning: từ nguyên lý đến thực hành

Chương 64 phút đọcSuy luận số nguyên

6Suy luận hoàn toàn bằng số nguyên#

Chương này trả lời câu hỏi: vì sao INT8 không chỉ nhẹ hơn mà còn nhanh hơn? Nội dung dựa theo Jacob và cộng sự (2018), nền tảng của cơ chế lượng tử trong TFLite.

6.1Nhân ma trận với các đại lượng đã lượng tử#

Xét $y = \sum_{k=1}^{K} w_k x_k$ (một phần tử của phép nhân ma trận hay tích chập). Thay mọi đại lượng bằng biểu diễn lượng tử $r = S(q - Z)$ :

S_y(q_y - Z_y) = \sum_{k} S_w(q_{w,k} - Z_w)\; S_x(q_{x,k} - Z_x).

Giải ra $q_y$ :

q_y = Z_y + \underbrace{\frac{S_w S_x}{S_y}}_{M} \sum_{k}(q_{w,k} - Z_w)(q_{x,k} - Z_x).

6.2Khai triển và những gì tính trước được#

Khai triển tích trong tổng:

\sum_k q_{w,k}\,q_{x,k} \;-\; Z_x \sum_k q_{w,k} \;-\; Z_w \sum_k q_{x,k} \;+\; K Z_w Z_x.

Phân tích từng số hạng:

$\sum_k q_{w,k} q_{x,k}$ là phần việc chính, gồm $K$ phép nhân int8×int8, cộng dồn vào thanh ghi int32.
$Z_x \sum_k q_{w,k}$ chỉ phụ thuộc trọng số và hằng $Z_x$ , nên tính trước được lúc chuyển đổi mô hình.
$Z_w \sum_k q_{x,k}$ phụ thuộc đầu vào, phải tính lúc chạy, tốn thêm $K$ phép cộng.
$K Z_w Z_x$ là hằng số.

Nếu trọng số lượng tử đối xứng ( $Z_w = 0$ ), hai số hạng 3 và 4 biến mất. Đây là lý do kỹ thuật khiến trọng số gần như luôn được lượng tử đối xứng.

6.3Bias#

Bias được lưu dạng int32 với scale $S_w S_x$ và zero-point 0: $q_b = \lfloor b / (S_w S_x) \rceil$ . Nhờ cùng scale với bộ cộng dồn, nó được cộng thẳng vào kết quả int32 mà không cần đổi đơn vị. Bias dùng 32 bit vì nó ít tham số nhưng ảnh hưởng trực tiếp lên mọi đầu ra, và vì bước $S_w S_x$ rất nhỏ.

6.4Requantization: nhân với số thực mà không dùng số thực#

Hệ số $M = S_w S_x / S_y$ là số thực. Thực nghiệm cho thấy $M$ gần như luôn nằm trong $(0, 1)$ . Ta viết

M = 2^{-n} M_0, \qquad M_0 \in [0{,}5;\ 1),

rồi lưu $M_0$ dưới dạng số nguyên 32 bit dấu chấm tĩnh: $M_0^{\text{int}} = \lfloor M_0 \cdot 2^{31} \rceil$ . Phép nhân với $M$ trở thành một phép nhân số nguyên 64 bit và một phép dịch phải có làm tròn:

\text{acc} \cdot M \approx \left(\text{acc} \cdot M_0^{\text{int}}\right) \gg (31 + n).

Cuối cùng cộng $Z_y$ và cắt về $[0, 255]$ . Toàn bộ quy trình được tóm tắt trong Hình 9.

Hàm kích hoạt ReLU được "gộp miễn phí": nếu dải đầu ra được calibrate sau ReLU thì $\alpha_y = 0$ , suy ra $Z_y = q_{min}$ , và phép cắt ở bước cuối tự động thực hiện ReLU. ReLU6 tương tự với cận trên. Các hàm phi tuyến phức tạp hơn (sigmoid, softmax, GELU) thường dùng bảng tra hoặc được tính ở độ chính xác cao hơn.

Ghi chú biên tập · Mục 6.4

Phạm vi áp dụng của `quantize_multiplier` và quy ước làm tròn số âm

Hai chi tiết cần nói rõ trước khi ai đó chép đoạn mã này vào việc thật.

a) Đoạn mã chỉ đúng với $0 < M < 1$ , đúng như chuỗi docstring của nó ghi. Vòng lặp while M < 0.5 chỉ chuẩn hoá lên, nên:

$M$	Kết quả	Nhận xét
$0{,}75$	`M0 = 1610612736`, `shift = 0`	đúng
$1{,}0$	`M0 = 1073741824`, `shift = -1`	tình cờ vẫn đúng, nhờ nhánh `if M0 == (1 << 31)`
$2{,}5$	`M0 = 5368709120`	tràn int32, sai âm thầm

Cài đặt thật (QuantizeMultiplier của gemmlowp/TFLite) cho phép shift âm, tức một phép dịch trái, nên mọi $M > 0$ đều xử lý được. Thêm đúng một vòng lặp là đủ:

Python

while M >= 1.0:
    M /= 2; shift -= 1

$M \ge 1$ xảy ra khi $S_w S_x \ge S_y$ , tức dải đầu ra hẹp hơn dải tự nhiên của bộ cộng dồn — hiếm, nhưng gặp thật ở lớp có đầu ra bị cắt mạnh hoặc khi activation để ở 16 bit.

b) rounding_right_shift làm tròn nửa về phía $+\infty$ , vì >> của Python là dịch số học (tương đương lấy sàn). Trong khi đó RoundingDivideByPOT của gemmlowp làm tròn nửa ra xa số 0. Hai quy ước chỉ khác nhau ở đúng điểm giữa của giá trị âm:

`acc`	`acc / 4`	Mã trong bài	gemmlowp
$-6$	$-1{,}5$	$-1$	$-2$
$-2$	$-0{,}5$	$0$	$-1$
$+6$	$+1{,}5$	$+2$	$+2$

Chênh lệch tối đa 1 LSB và không ảnh hưởng tới lập luận của chương. Nhưng nếu bạn muốn khớp từng bit với một backend cụ thể thì phải dùng đúng quy ước của backend đó — đây là loại chi tiết khiến hai cài đặt “cùng công thức” vẫn lệch nhau vài LSB.

6.5Kiểm chứng bằng mã#

Đoạn mã sau cài đặt đúng quy trình Hình 9 bằng NumPy cho một lớp Linear $256 \to 64$ và so sánh với cách mô phỏng bằng số thực (trích từ code/numpy_experiments.py):

Python

def quantize_multiplier(M):
    """Viết M (0 < M < 1) dưới dạng M0 * 2^-(31 + shift), với M0 là int32 trong [2^30, 2^31)."""
    shift = 0
    while M < 0.5:
        M *= 2; shift += 1
    M0 = int(round(M * (1 << 31)))
    if M0 == (1 << 31):
        M0 //= 2; shift -= 1
    return M0, shift

def rounding_right_shift(x, n):          # chia cho 2^n, làm tròn gần nhất
    return (x + (1 << (n - 1))) >> n

# X: activation (uint8 bất đối xứng), W: trọng số (int8 đối xứng), b: bias
q_x = np.clip(np.round(X / S_x) + Z_x, 0, 255).astype(np.int32)
q_w = np.clip(np.round(W / S_w), -127, 127).astype(np.int32)
q_b = np.round(b / (S_w * S_x)).astype(np.int32)

acc = q_x @ q_w.T - Z_x * q_w.sum(axis=1) + q_b          # int32; q_w.sum tính trước được
M0, shift = quantize_multiplier(S_w * S_x / S_y)
q_y = np.clip(Z_y + rounding_right_shift(acc.astype(np.int64) * M0, 31 + shift), 0, 255)

Kết quả (code/numpy_experiments_output.txt):

Kết quả chạy

S_x=0.038963 Z_x=106 | S_w=0.001661 | S_y=0.031995 Z_y=120
M = 0.0020223740 = 1111811840 * 2^-(31+8) -> 0.0020223740
max |q_y(integer) - q_y(float sim)| = 0 LSB; tỉ lệ khác nhau: 0.0000%
sai số tương đối so với FP32: 1.6085%
max |acc| = 66876 ; giới hạn int16 = 32767 ; cận trên lý thuyết 255*127*K = 8290560

Ba điều rút ra:

Đường tính toán thuần số nguyên cho kết quả trùng khớp từng bit với cách mô phỏng bằng số thực. Đây là lý do mô phỏng fake quantization (Chương 7) dự đoán đúng độ chính xác của mô hình khi triển khai.
Sai số so với FP32 khoảng 1,6%, hoàn toàn do lượng tử chứ không do phép tính số nguyên.
Giá trị cộng dồn lên tới 66 876, vượt giới hạn int16. Đó là lý do bộ cộng dồn phải là int32. Cận trên lý thuyết $8{,}3 \times 10^6$ vẫn nằm rất xa giới hạn int32 ( $\approx 2{,}1 \times 10^9$ ).

Khi dùng per-channel cho trọng số, mỗi kênh đầu ra $j$ có hệ số $M_j = S_{w,j} S_x / S_y$ riêng, còn lại mọi thứ giữ nguyên.

Ghi chú biên tập · Mục 6.5

“Trùng khớp từng bit” chứng minh điều gì và không chứng minh điều gì

Kết quả max |q_y(integer) - q_y(float sim)| = 0 LSB rất đáng giá, nhưng cần đọc đúng phạm vi.

Nó chứng minh: phép suy ra ở Mục 6.1–6.4 là đúng, và cách mô phỏng bằng số thực trong tài liệu này tái hiện chính xác đường tính toán số nguyên trong tài liệu này — với cấu hình đã nêu (một lớp Linear $256 \to 64$ , trọng số đối xứng, activation uint8, requantization 32 bit).

Nó không chứng minh: rằng mô phỏng fake quantization luôn khớp từng bit với một backend thật. Đây là phép tự đối chiếu giữa hai cài đặt của cùng một tác giả, không phải phép đối chiếu với TFLite, ONNX Runtime hay QNNPACK. Mức khớp với backend thật còn phụ thuộc:

quy ước làm tròn ở mỗi bước (xem ghi chú Mục 6.4);
độ chính xác của bước requantization — có backend dùng 32 bit thay vì 64;
cách gộp lớp, vì gộp hay không gộp sẽ đổi số lần lượng tử trung gian;
op không có kernel INT8 sẽ rơi về FP32 và sinh thêm cặp quantize/dequantize.

Phát biểu an toàn: fake quantization là công cụ dự đoán độ chính xác rất tốt, không phải bảo đảm về đầu ra từng bit. Chính vì vậy mà mục 8 trong danh sách kiểm tra ở Mục 12.3 vẫn bắt buộc đo lại trên thiết bị đích.

Tự kiểm tra

7 câu. Chọn đáp án để xem ngay lời giải thích.

1Vì sao bộ cộng dồn trong phép nhân ma trận INT8 phải là int32?
2Trọng số lượng tử đối xứng ( $Z_w = 0$ ) mang lại lợi ích tính toán gì?
3Bias được lưu như thế nào trong đường tính toán số nguyên?
4Requantization nhân với hệ số thực $M$ bằng cách nào mà không dùng số thực?
5Đoạn mã quantize_multiplier ở Mục 6.4 dùng được cho hệ số $M$ nào?
6Hàm dịch phải có làm tròn trong Mục 6.4 xử lý giá trị âm theo quy ước nào?
7Kết quả "trùng khớp từng bit" ở Mục 6.5 chứng minh điều gì?

Đã trả lời 0/7