Cách phân loại dễ nhớ: distillation làm model nhỏ hơn, quantization làm biểu diễn số học rẻ hơn, pruning cắt phần dư thừa, ONNX/ORT tối ưu graph/runtime inference.
Making Models Faster with Quantization: giảm số bit dùng để biểu diễn weight/activation, ví dụ từ FP32/FP16 xuống INT8 hoặc thấp hơn, để giảm model size, memory footprint và memory bandwidth.
Quantization có thể tăng tốc inference vì mỗi tham số tốn ít byte hơn và runtime/hardware có thể dùng low-precision kernels. Nhưng tốc độ tăng không tự động; phải đo trên backend thật.
Cần tách hai lợi ích: compression benefit gần như trực tiếp vì weight nhỏ hơn; compute/runtime benefit chỉ có nếu runtime/hardware tận dụng tốt INT8/low-bit kernels và không bị overhead dequantize lấn át.
Công thức trực giác: x_quant = round(x / scale) + zero_point, rồi dequantize xấp xỉ bằng x_approx = scale * (x_quant - zero_point).
Dynamic quantization thường dễ thử vì có thể quantize weight cho inference mà không cần train lại toàn bộ; quantization-aware training phức tạp hơn nhưng giúp model quen với lỗi xấp xỉ trong lúc train/fine-tune.
Có ba approach chính: dynamic quantization, static quantization và quantization-aware training. Dynamic dễ thử nhất; static cần calibration data; QAT tốn training hơn nhưng giúp model thích nghi với nhiễu quantization.
Static quantization dùng calibration data để ước lượng range của activation trước inference, từ đó chọn scale/zero-point phù hợp hơn.
Rủi ro chính là lỗi xấp xỉ làm giảm quality; vì vậy model quantized phải benchmark lại theo accuracy/F1, latency và memory.
Benchmarking Our Quantized Model: sau khi quantize, cần so với model gốc bằng cùng benchmark để biết trade-off thật: quality giảm bao nhiêu, latency có giảm thật không, model size/memory footprint giảm bao nhiêu.
Không nên kết luận “quantized model nhanh hơn” chỉ vì model nhỏ hơn. Tốc độ phụ thuộc runtime, CPU/GPU, batch size và việc backend có hỗ trợ kernel low-precision tốt hay không.
Optimizing Inference with ONNX and ONNX Runtime: export model từ framework training sang ONNX graph, kiểm tra output parity, rồi chạy bằng ORT để tận dụng graph optimization/runtime optimization.
ONNX Runtime tối ưu inference bằng các bước như hợp nhất operator, bỏ node dư thừa, tối ưu graph và dùng execution provider phù hợp với phần cứng.
Making Models Sparser with Weight Pruning: Pruning làm model sparse bằng cách đưa một số weight ít quan trọng về 0 hoặc loại bỏ cấu trúc như neuron/head/block.
Weight pruning thường dùng magnitude làm heuristic: weight có trị tuyệt đối nhỏ được xem là ít ảnh hưởng hơn và bị prune trước. Sau pruning thường cần fine-tune hoặc evaluate lại để phục hồi/kiểm tra quality.
Sparse model không tự động nhanh hơn. Nếu pruning là unstructured, model có nhiều số 0 hơn nhưng runtime/hardware không khai thác sparse matrix thì latency có thể không cải thiện đáng kể.
Viết lại bằng lời của tôi
Khi đưa Transformer vào production, accuracy không phải chỉ số duy nhất. Mình cần nhìn model như một hệ thống inference: chạy nhanh không, tốn bao nhiêu VRAM/RAM, throughput ra sao, và sau tối ưu có mất chất lượng nhiều không.
Quantization là cách làm model “dùng số gọn hơn”. Nó không dạy model mới như distillation, mà đổi cách lưu/tính weight hoặc activation để inference rẻ hơn. Cái bẫy là ít bit hơn có thể nhanh/gọn hơn nhưng cũng có thể làm mất quality, nên phải benchmark trước khi tin.
Ba approach quantization khác nhau ở mức độ chuẩn bị trước inference: dynamic làm ít nhất, static cần calibration trước, còn QAT đưa luôn lỗi quantization vào training để model học cách chịu nhiễu.
ONNX/ORT giống bước đóng gói và chạy lại model bằng một engine inference chuyên dụng. Việc quan trọng không chỉ là export được, mà phải kiểm tra output còn gần model gốc và benchmark xem runtime mới có thật sự nhanh hơn không.
Pruning giống dọn những trọng số ít đóng góp ra khỏi model. Nhưng với production, “nhiều số 0” chỉ có giá trị nếu nó chuyển thành size nhỏ hơn, memory thấp hơn hoặc latency tốt hơn trên backend thật.
Điều chưa rõ
Cần thực hành benchmark thật để cảm nhận rõ khi nào Quantization / ONNX Runtime / Pruning tạo speedup thật, thay vì chỉ giảm size trên lý thuyết.
Tổng kết sau khi đọc xong
Ngày 04-08 hoàn tất nửa sau Chapter 08: distillation, quantization, ONNX/ORT và pruning đều là các đòn bẩy production khác nhau, không thay thế cho benchmark.
Bài học chính: tối ưu model phải đọc theo trade-off quality - latency - memory - size. Một kỹ thuật chỉ đáng dùng khi cải thiện đúng ràng buộc deployment mà không làm quality giảm quá ngưỡng.
Với workflow thực tế, nên đi theo thứ tự: tạo baseline benchmark → thử kỹ thuật tối ưu → kiểm tra output/quality → đo latency/memory cùng điều kiện → quyết định deploy.