Tệp mô hình nặng bao nhiêu và vì sao bị chia mảnh
Tệp mô hình nặng bao nhiêu và vì sao bị chia mảnh
Bấm tải một mô hình về, bạn không nhận một tệp mà nhận bốn tệp đánh số. Không phải quy ước cho đẹp: có một trần kích thước, một phép chia làm tròn lên, và một luật cứng là không cắt được giữa một tensor.
Ở bài đọc tệp config.json bạn lấy được hình dáng của một mô hình từ chính tệp cấu hình nó công bố. Bài này trả lời câu hỏi kế tiếp, và là câu đầu tiên bất kỳ ai tải mô hình cũng gặp: bộ trọng số đó nặng bao nhiêu byte, và vì sao nó tới tay bạn dưới dạng nhiều tệp đánh số thay vì một tệp duy nhất.
Công thức chính thì ngắn tới mức dễ coi nhẹ: số byte trọng số bằng số tham số nhân số byte mỗi tham số. Phần thú vị nằm ở hai chỗ khác. Chỗ thứ nhất là phép chia mảnh, vì nó có một mốc biên mà một lỗi lệch một trốn được rất lâu. Chỗ thứ hai là chuyện một mảnh không cắt được giữa một tensor, nên số tệp thật thường không bằng số tệp mà phép chia nói.
1 · Mô hình này nặng bao nhiêu ✎ sửa được
8.030.261.248 tham số × 2 byte = 16.060.522.496 byte. Đó là toàn bộ công thức, và nó cũng nói luôn vì sao đổi định dạng lưu là việc rẻ nhất bạn làm được với một tệp mô hình: xem bài một bit dùng vào việc gì.
2 · Phép chia lý tưởng: cắt ở đâu cũng được ✎ sửa được
16.060.522.496 byte ÷ 5.000.000.000 byte mỗi mảnh = 3,212 nên phải làm tròn lên thành 4 mảnh. Mảnh cuối giữ phần còn lại: 16.060.522.496 - 3 × 5.000.000.000 = 1.060.522.496 byte.
3 · Đóng gói thật: một mảnh không cắt giữa một tensor
Mảnh được đóng theo từng tensor nguyên vẹn: thêm tensor tiếp theo vào mảnh đang mở nếu còn chỗ, không còn thì mở mảnh mới. Nên mảnh gần như luôn hụt so với trần, và số mảnh thật lớn hơn hoặc bằng phép chia lý tưởng, không bao giờ nhỏ hơn. Ở cấu hình này: lý tưởng 4 mảnh, thật 4 mảnh, tức vừa đúng bằng nhau lần này. Tổng chỗ trống bỏ lại ở các mảnh trước mảnh cuối là 107,6 MB, bằng 0,67% cả tệp.
| tệp | tensor | byte dữ liệu | còn trống | phần đầu | phần đầu / tệp |
|---|---|---|---|---|---|
| model-00001-of-00004.safetensors | 83 (số 0 tới 82) | 5,0 GB | 23,3 MB | 9.632 byte | 0,0002% |
| model-00002-of-00004.safetensors | 105 (số 83 tới 187) | 5,0 GB | 201,2 KB | 12.240 byte | 0,0002% |
| model-00003-of-00004.safetensors | 100 (số 188 tới 287) | 4,9 GB | 84,1 MB | 11.672 byte | 0,0002% |
| model-00004-of-00004.safetensors | 3 (số 288 tới 290) | 1,2 GB | 3,8 GB | 336 byte | 0,0000% |
4 · Phần đầu tệp safetensors, và vì sao nó không đáng kể
Mỗi mảnh mở đầu bằng 8 byte ghi độ dài phần đầu, rồi một khối JSON ghi tên, kiểu dữ liệu, hình dáng và khoảng byte của từng tensor trong mảnh đó. Nhờ khoảng byte ấy mà trình nạp đọc được đúng một tensor giữa tệp mà không phải đọc cả tệp.
{"__metadata__":{"format":"pt"},"model.embed_tokens.weight":{"dtype":"BF16","shape":[128256,4096],"data_offsets":[0,1050673152]},"model.layers.0.input_layernorm.weight":{"dtype":"BF16","shape":[4096],"data_offsets":[1050673152,1050681344]},"model.layers.0.self_attn.q_proj.weight":{"dtype":"BF16","sh …5 · Cùng mô hình, bốn định dạng lưu, ở trần 5,0 GB
| định dạng lưu | byte mỗi tham số | tổng (thước 1000) | tổng (thước 1024) | mảnh lý tưởng | mảnh thật | so với 4 byte |
|---|---|---|---|---|---|---|
| 4 byte (FP32) | 4 | 32,1 GB | 29,9 GiB | 7 | 7 | 100,0% |
| 2 byte (BF16 hoặc FP16) | 2 | 16,1 GB | 15,0 GiB | 4 | 4 | 50,0% |
| 1 byte (FP8 hoặc INT8) | 1 | 8,0 GB | 7,5 GiB | 2 | 2 | 25,0% |
| 4 bit (nửa byte) | 0.5 | 4,0 GB | 3,7 GiB | 1 | 1 | 12,5% |
- Nó đếm byte. Nó không đo tốc độ tải, không đo thời gian nạp vào GPU, và không biết mạng của bạn nhanh chậm ra sao.
- Hàng 4 bit là chặn dưới. Bản lượng tử hoá thật còn phải lưu hệ số tỉ lệ và điểm không theo từng nhóm, đóng gói giá trị vào từ rộng hơn, và sim này không đếm phần đó. Xem bài lượng tử hoá theo nhóm để biết phần thêm đó lớn cỡ nào.
- Bộ tensor ở đây là bộ xương kiểu Llama: có ma trận chiếu, ma trận nhúng và vector chuẩn hoá, không có vector bias mà một số họ mô hình vẫn dùng. Nên số tham số tính ra có thể thấp hơn số kho công bố, và ô so sánh ở trên nói rõ lệch bao nhiêu.
- Thứ tự ghi tensor quyết định biên mảnh rơi vào đâu. Sim ghi theo thứ tự nhúng, rồi từng lớp, rồi lớp ra. Một thư viện khác có thể ghi thứ tự khác và ra số mảnh lệch một.
- Trần mảnh ở đây áp cho phần dữ liệu, còn phần đầu cộng thêm bên trên, nên tệp thật nhích hơn trần một chút. Đó là quy ước, và nó khớp cách các thư viện phổ biến chia mảnh.
Cân cả mô hình bằng một phép nhân
Ở trạng thái mở bài, sim đang cân bộ xương hình dáng của Llama 3.1 8B Instruct. Nó có 291 tensor: 9 tensor mỗi lớp cho 32 lớp, cộng ma trận nhúng, vector chuẩn hoá cuối và ma trận chiếu ra. Cộng số phần tử của cả 291 tensor được 8.030.261.248 tham số, tức 8,03 tỉ. Con số này khớp từng chữ số với con số kho mô hình công bố, và đó là điều đáng nói: nó không phải phỏng đoán từ cái tên "8B" mà là tổng của các hình dáng.
Nhân với 2 byte mỗi tham số là ra 16.060.522.496 byte. Cùng một con số đó đọc theo hai thước khác nhau: 15,0 GiB theo thước 1024 của hệ điều hành, và 16,1 GB theo thước 1000 mà thẻ mô hình và Hugging Face dùng. Sim in cả hai cạnh nhau vì đây là chỗ người ta hay tưởng mình bị lừa: hai con số khác nhau mô tả đúng cùng một tệp.
Đổi định dạng lưu là đổi thẳng vào phép nhân đó, và bài một bit dùng vào việc gì mở cái thừa số "byte mỗi tham số" ra xem bên trong. Bốn lựa chọn ở đây là 4 byte, 2 byte, 1 byte và 4 bit tức nửa byte. Riêng phần hàng 4 bit thì phải nói thẳng: đó là chặn dưới, vì bản lượng tử hoá thật còn phải lưu hệ số tỉ lệ theo từng nhóm, và bài lượng tử hoá theo nhóm đếm phần thêm đó.
Con số 16,1 GB này là bộ trọng số nằm yên trên đĩa, không phải bộ nhớ lúc chạy. Chạy còn cộng bộ đệm KV, còn huấn luyện thì cộng bản sao độ chính xác cao, gradient và trạng thái bộ tối ưu, tức nhiều lần con số ở đây, và bài bộ nhớ khi huấn luyện tính phần đó. Muốn biết một tệp 16,1 GB có nạp nổi trên máy mình hay không thì sang bài chạy được trên máy nào.
Phép chia mảnh, và cái mốc chia hết
Không ai phát hành một tệp 16 GB liền khối. Người ta đặt một trần kích thước cho mỗi mảnh rồi cắt ra. Trần mặc định hiện nay của Hugging Face là 5 GB, và cần đọc đúng con số đó: nó nghĩa là 5 nhân 10 lũy thừa 9 byte, tức 5.000.000.000, chứ không phải 5 lần 2 lũy thừa 30.
Phép chia thì hai dòng:
- số mảnh bằng
ceil(tổng byte / trần mảnh) - kích thước mảnh cuối bằng
tổng byte - (số mảnh - 1) × trần mảnh
Ở trạng thái mở bài: 16.060.522.496 / 5.000.000.000 = 3,212 nên làm tròn lên thành 4 mảnh, và mảnh cuối giữ 16.060.522.496 - 3 × 5.000.000.000 = 1.060.522.496 byte, tức 21,2% của trần. Ba mảnh đầu đầy, mảnh cuối vơi, đúng như trực giác.
Bây giờ tới chỗ dễ sai nhất của cả bài, và nó là lý do preset thứ tư tồn tại. Khi tổng byte chia hết đúng cho trần mảnh thì ceil cho đúng số mảnh, và mảnh cuối bằng ĐÚNG một trần đầy, không phải bằng 0. Bấm preset minh hoạ: đúng mốc chia hết rồi nhìn: tổng 335.579.136 byte, trần đặt đúng bằng một phần ba tổng, tức 111.859.712 byte. Phép chia cho 3 mảnh và mảnh cuối bằng 111.859.712 byte, tức đúng 100% của trần.
Chỗ này đáng dừng lại vì cách sai rất thuyết phục. Một cài đặt viết công thức mảnh cuối thành tổng byte - số mảnh × trần mảnh sẽ cho ra 0 ở đúng cái mốc này và cho ra số âm ở mọi trần khác, nên nó lộ ngay. Nhưng một cài đặt dùng floor thay ceil thì tệ hơn nhiều: nó vẫn cho 3 ở đúng mốc chia hết, tức đúng, và chỉ sai ở mọi chỗ khác. Muốn bắt được nó thì phải kiểm cả ba điểm: đúng trên mốc, một byte dưới và một byte trên. Kéo trần lệch một byte theo mỗi chiều mà xem:
- trần 111.859.711 byte, tức thiếu một byte: 4 mảnh, và mảnh thứ tư chứa vỏn vẹn 3 byte
- trần 111.859.712 byte, đúng mốc: 3 mảnh, mảnh cuối 111.859.712 byte
- trần 111.859.713 byte, tức thừa một byte: vẫn 3 mảnh, mảnh cuối 111.859.710 byte
Một byte lệch làm số tệp nhảy từ 3 lên 4. Cổng kiểm số của bài này khoá đúng cả ba điểm đó, vì một khẳng định chỉ đứng ở giữa hai mốc thì không thấy gì.
Một mảnh không cắt được giữa một tensor
Phép chia trên coi byte như nước, cắt ở đâu cũng được. Thực tế thì không: mảnh được đóng theo từng tensor nguyên vẹn. Trình nạp phải đọc được trọn một tensor từ một tệp, nên không ai để nửa ma trận ở tệp này nửa kia ở tệp khác.
Cách đóng gói thì tham lam và đơn giản: thêm tensor tiếp theo vào mảnh đang mở nếu còn chỗ, không còn thì đóng mảnh lại và mở mảnh mới. Hệ quả là mảnh gần như luôn hụt so với trần, và vì mỗi mảnh chứa nhiều nhất một trần, số mảnh thật lớn hơn hoặc bằng ceil(tổng / trần), không bao giờ nhỏ hơn. Đó là một bất đẳng thức chứng minh được bằng một dòng, không phải một quan sát.
Ở trạng thái mở bài, hai con số bằng nhau: lý tưởng 4 mảnh, thật cũng 4 mảnh. Bảng mảnh cho thấy chỗ hụt:
| tệp | tensor | byte dữ liệu | còn trống |
|---|---|---|---|
model-00001-of-00004.safetensors | 83 | 4.976.697.344 | 23.302.656 |
model-00002-of-00004.safetensors | 105 | 4.999.798.784 | 201.216 |
model-00003-of-00004.safetensors | 100 | 4.915.904.512 | 84.095.488 |
model-00004-of-00004.safetensors | 3 | 1.168.121.856 | phần còn lại |
Mảnh đầu chứa ma trận nhúng cộng 9 lớp trọn cộng một vector chuẩn hoá của lớp thứ mười, rồi đứng lại vì ma trận truy vấn kế tiếp nặng hơn 23.302.656 byte còn trống. Cộng chỗ trống của ba mảnh đầu được 107.599.360 byte, tức 107,6 MB, bằng 0,67% cả bộ trọng số. Mảnh cuối không tính vào chỗ hao vì phần vơi của nó chỉ là chỗ mô hình hết, không phải chỗ bị bỏ.
Muốn thấy hai con số khác nhau thì bấm lại preset minh hoạ mốc chia hết: ở đó phép chia nói 3 mảnh mà đóng gói tham lam cần 4 tệp, với các mảnh 109.060.096, 109.064.192, 109.064.192 và 8.390.656 byte. Không mảnh nào chạm trần 111.859.712, và chính vì thế mới sinh ra tệp thứ tư.
Ca một tensor lớn hơn cả trần mảnh
Có một ca mà thuật toán tham lam không có đáp án nào cả: khi một tensor đơn lẻ đã nặng hơn trần mảnh. Không cắt được nó ra, mà nhét cả vào thì mảnh vượt trần. Đây chính là chỗ một cài đặt cẩu thả trả về một con số trông rất hợp lý rồi đi tiếp.
Sim làm khác: nó dừng lại và báo tên tensor, số byte của tensor đó, trần đang đặt và thiếu bao nhiêu byte. Có hai đường để tự tay chạm vào ca này:
- Kéo trần mảnh xuống dưới 1.050.673.152 byte, tức dưới kích thước của
model.embed_tokens.weight, tensor lớn nhất của mô hình mặc định với hình dáng128256 × 4096. Ma trận nhúng thường là tensor to nhất một mô hình có, nên nó cũng là thứ đặt sàn cho trần mảnh. - Hoặc ở preset minh hoạ mốc chia hết, nhìn hàng 4 byte của bảng bốn định dạng: ô "mảnh thật" ghi không xếp được, vì ở 4 byte ma trận nhúng của preset đó nặng 134.217.728 byte, vượt cái trần 111.859.712 mà preset đặt. Cột "mảnh lý tưởng" vẫn điền 6, và đó là câu trả lời đúng cho một câu hỏi khác: phép chia lý tưởng cắt ở đâu cũng được nên nó luôn có đáp án, còn đóng gói thật thì không.
Nói cho rõ: một trần mảnh không đủ chứa tensor lớn nhất không phải lỗi của mô hình, mà là cấu hình vô nghĩa. Cách chữa duy nhất là nâng trần lên ít nhất bằng tensor lớn nhất.
Phần đầu tệp safetensors, đo ra rồi mới kết luận
Mỗi mảnh mở đầu bằng 8 byte ghi độ dài phần đầu, rồi một khối JSON ghi tên, kiểu dữ liệu, hình dáng và khoảng byte của từng tensor trong mảnh đó. Nhờ khoảng byte ấy mà trình nạp nhảy thẳng tới một tensor giữa tệp mà không phải đọc cả tệp, và đó là toàn bộ lý do khuôn dạng này thắng các cách lưu cũ.
Câu hay gặp là "phần đầu không đáng kể". Câu đó đúng, nhưng nói suông thì không dạy được gì, nên sim tính tỉ lệ ra. Ở trạng thái mở bài:
- mảnh 1 giữ 83 tensor, khối JSON dài 9.618 ký tự, cộng 8 byte độ dài và phần đệm thành 9.632 byte
- mảnh 4 chỉ giữ 3 tensor, khối JSON dài 321 ký tự, thành 336 byte
- cả bốn mảnh cộng lại là 33.880 byte phần đầu, trên tổng 16.060.556.376 byte tệp, tức 0,00021%
Nói cách khác, phần đầu của cả bộ nhỏ hơn một phần bốn nghìn của một phần trăm. Nó nhỏ tới mức bạn có thể bỏ hẳn ra khỏi mọi tính toán dung lượng, và giờ thì bạn có con số để nói vậy thay vì đoán. Nhấp một hàng khác trong bảng mảnh để đọc phần đầu của mảnh đó, độ dài đổi theo số tensor trong mảnh.
Một điểm trung thực: phần đệm cho tròn 8 byte là quy ước sim này giả định, tối đa 7 byte mỗi mảnh. Nó không đổi kết luận nào ở thang phần trăm trên, và sim in cả độ dài chưa đệm để bạn tự kiểm.
Đổi định dạng lưu là đổi cả số mảnh phải tải
Bảng bốn định dạng ở cuối sim là chỗ quy về một câu người dùng cảm được. Cùng mô hình mặc định, cùng trần 5 GB:
| định dạng lưu | tổng | mảnh lý tưởng | mảnh thật |
|---|---|---|---|
| 4 byte | 32,1 GB | 7 | 7 |
| 2 byte | 16,1 GB | 4 | 4 |
| 1 byte | 8,0 GB | 2 | 2 |
| 4 bit | 4,0 GB | 1 | 1 |
Đọc bảng này cần cẩn thận đúng một chỗ. Số byte tỉ lệ chính xác: mỗi bước hẹp một nửa thì tổng giảm đúng một nửa, và bản 4 bit đúng bằng một phần tám bản 4 byte. Số mảnh thì không tỉ lệ, vì phép chia luôn làm tròn lên: 4 byte cần 7 tệp chứ không phải 8 lần 1 tệp. Nên câu nói cho đúng là: bản 4 bit tải nhanh hơn vì nó nhẹ hơn tám lần, chứ không phải vì nó ít tệp hơn. Số tệp chỉ là hệ quả, và nó là hệ quả có làm tròn.
Cũng đo được luôn chiều còn lại: nâng trần mảnh lên thì số tệp không bao giờ tăng. Cổng kiểm chạy thang chín trần từ 2 GB tới 40 GB và xác nhận điều đó theo cả hai cách đếm, đồng thời xác nhận nó có giảm thật ở đâu đó chứ không phải một cái núm trơ.
Khi số tính ra không khớp kho thật
Preset mang tên mô hình chỉ chép lại hình dáng đã công bố, kèm nguồn và ngày chép, và ngày đó hiện ngay dưới hàng preset. Ba preset thật ở đây cho ba kết cục khác nhau, và cả ba đều đáng đọc:
- Llama 3.1 8B Instruct. Số tham số khớp từng chữ số, và số mảnh cũng khớp: kho thật có 4 tệp, phép chia ở đây cho 4.
- Mistral 7B v0.1. Số tham số cũng khớp từng chữ số, 7.241.732.096. Nhưng ở trần 5 GB,
14.483.464.192byte cho 3 mảnh, còn kho thật chỉ có 2 tệp. Đây là chỗ lệch, và sim ghi thẳng chữ lệch chứ không bẻ số cho khớp. Lý do khả dĩ nằm ở chính cái trần: bản này lưu vào thời trần mặc định còn là 10 GB, và đặt trần 10 GB thì phép chia cho đúng 2. Bấm nút trần 10 GB để tự kiểm. Nói khả dĩ vì đó là một cách giải thích khớp số, không phải một bằng chứng về việc kho đó được lưu ra sao. - Qwen2.5 7B Instruct. Bộ hình dáng cho 7.615.487.488 tham số, còn thẻ mô hình ghi 7,62 tỉ, nên ô so sánh báo lệch -4.512.512 tham số, tức -0,06%. Phần lớn chỗ lệch đó chỉ là làm tròn: 7.615.487.488 làm tròn hai chữ số thập phân cũng ra 7,62 tỉ. Phần còn lại thì sim thiếu thật: họ mô hình này có vector bias ở các phép chiếu truy vấn, khoá và giá trị, mà bộ xương ở đây không đếm. Đổi lại, bỏ hai ma trận nhúng ra thì phần còn lại tính được 6.525.492.736 tham số, tức 6,53 tỉ, khớp đúng con số "không thuộc phần nhúng" mà thẻ mô hình ghi.
Preset thứ tư ghi rõ là số minh hoạ, không phải cấu hình của mô hình nào cả, và nó cũng không công bố số tham số nào để khỏi bị đọc thành sự thật. Nó tồn tại chỉ để đưa bạn đứng đúng trên mốc chia hết, vì mốc đó gần như không bao giờ gặp ở một mô hình thật.
Số byte trọng số bằng số tham số nhân số byte mỗi tham số, và đó là toàn bộ phần dễ. Phần khó là chia mảnh. Số mảnh bằng ceil(tổng byte / trần mảnh), mảnh cuối bằng phần còn lại, và tại đúng cái mốc tổng chia hết cho trần thì mảnh cuối bằng đúng một trần đầy chứ không phải bằng 0: đây là chỗ một lỗi lệch một sống được rất lâu nếu không kiểm cả ba điểm đúng mốc, dưới một byte và trên một byte. Nhưng mảnh thật không đóng theo byte mà theo từng tensor nguyên vẹn, nên nó gần như luôn hụt so với trần và số tệp thật lớn hơn hoặc bằng phép chia lý tưởng. Và nếu một tensor đơn lẻ vượt trần thì đóng gói tham lam không có đáp án nào, phải báo ra chứ không được cho số. Phần đầu tệp thì đo được là 0,00021% ở cấu hình mở bài, tức bỏ qua được, và đó là con số chứ không phải cảm giác.
- 1Bộ trọng số nặng đúng 12.000.000.000 byte, trần mỗi mảnh là 4.000.000.000 byte. Có bao nhiêu mảnh, và mảnh cuối nặng bao nhiêu?
- 2Vì sao số tệp thật của một kho mô hình thường nhiều hơn con số mà phép chia ceil(tổng byte / trần mảnh) cho ra?
- 3Mô hình mặc định ở 4 byte mỗi tham số cần 7 tệp với trần 5 GB, còn ở 4 bit thì chỉ 1 tệp. Kết luận nào đúng?