Không phải cái gì không nằm trong RAM cũng biến mất

Giả sử nhà bạn có một cái bàn rộng đúng một mét.

Bây giờ có người chở tới một bộ Lego dài 100 mét và bảo:

Hãy ráp nó trên cái bàn này.

Phản ứng bình thường là:

Không thể.

Cái bàn một mét thì làm sao chứa bộ Lego dài 100 mét?

Nhưng một đứa trẻ sáu tuổi có thể nghĩ theo cách khác.

Nó không đem cả bộ Lego lên bàn.

Nó lấy hộp số 1 ra, ráp xong, cất xuống đất.

Lấy hộp số 2 lên.

Ráp.

Cất xuống.

Rồi hộp số 3.

Cứ thế cho tới hộp số 100.

Cái bàn chưa bao giờ chứa toàn bộ bộ Lego.

Nó chỉ chứa phần đang được xử lý ở thời điểm hiện tại.

AirLLM làm một chuyện khá giống như vậy với Large Language Model.

Thông thường, muốn chạy một mô hình lớn, chúng ta nghĩ:

1Model weights
2    ↓
3GPU VRAM
4    ↓
5Inference

Model 70B dùng BF16 thì riêng weights đã có kích thước xấp xỉ:

$$ 70 \times 10^9 \times 2 \approx 140GB $$

Nhìn vào GPU 24GB, 48GB hay 80GB, chúng ta bắt đầu cộng trừ nhân chia số card.

Nhưng AirLLM hỏi một câu hơi ngáo:

Ai bảo phải nhét toàn bộ model vào GPU cùng một lúc?

Thế là bài toán đổi thành:

 1SSD
 2 ↓
 3CPU RAM
 4 ↓
 5GPU
 6 ↓
 7tính một layer
 8 ↓
 9ném layer đó ra
10 ↓
11load layer tiếp theo

Đây là tư tưởng quan trọng nhất của AirLLM.

Nó không làm con voi nhỏ lại.

Nó bắt con voi đi qua cửa từng khúc một.

Nghe hơi bạo lực, nhưng về mặt kỹ thuật lại khá hợp lý.

AirLLM là gì?

AirLLM là một thư viện Python tập trung vào một mục tiêu rất cụ thể:

giảm lượng GPU VRAM cần thiết để inference các mô hình cực lớn.

Repository hiện tại quảng bá những con số khá kinh khủng:

Llama 70B có thể chạy với khoảng 4GB VRAM.
Llama 3.1 405B khoảng 8GB.
DeepSeek-V3 671B khoảng 12GB.
Qwen3-235B khoảng 3GB.
Kimi K3 2.8T đã được chạy thử với peak VRAM khoảng 3.72GB.

Nhìn bảng đó lần đầu rất dễ sinh ra một suy nghĩ nguy hiểm:

Vậy từ nay khỏi mua GPU lớn?

Không.

AirLLM giải quyết bài toán capacity, chứ không làm biến mất định luật vật lý.

Weights vẫn phải nằm ở đâu đó.

Nếu không nằm trong VRAM thì nó nằm trên RAM.

Nếu không nằm trên RAM thì nằm trên SSD.

Nếu model có checkpoint 1.5TB thì ổ đĩa của bạn vẫn phải chứa hơn 1.5TB dữ liệu.

Không có gì là hoàn toàn ảo.

Một parameter dù được gọi bằng những cái tên rất đẹp như neural network, tensor hay artificial intelligence, cuối cùng vẫn phải biến thành những bit thật nằm trên transistor thật, chạy qua controller thật, qua PCIe thật, rồi cuối cùng đập vào hàng tỷ transistor bên trong GPU.

AirLLM không xóa khối vật chất đó.

Nó chỉ thay đổi thời điểm khối vật chất ấy xuất hiện trong GPU.

Bình thường LLM ăn VRAM như thế nào?

Giả sử chúng ta có một Transformer đơn giản gồm 80 layer.

Có thể tưởng tượng nó như một dây chuyền:

 1Token
 2  ↓
 3Embedding
 4  ↓
 5Layer 0
 6  ↓
 7Layer 1
 8  ↓
 9Layer 2
10  ↓
11...
12  ↓
13Layer 79
14  ↓
15LM Head
16  ↓
17Token tiếp theo

Khi chạy kiểu truyền thống, weights của 80 layer thường được giữ sẵn trong GPU.

Khi token đi tới Layer 37, Layer 37 đã ngồi đó chờ.

GPU chỉ việc lấy dữ liệu và tính.

Đây là cách nhanh.

Nhưng rất tốn VRAM.

AirLLM nhìn vào chuỗi này và phát hiện một chuyện hiển nhiên đến mức đôi khi chúng ta không để ý:

Khi đang tính Layer 37 thì chúng ta đâu cần weights của Layer 62 ngay lúc đó.

Vậy tại sao phải bắt Layer 62 ngồi chiếm ghế trong VRAM?

Ý tưởng của AirLLM: layer-wise streaming

Phiên bản hiện tại của AirLLM dựng model bằng init_empty_weights() của Hugging Face Accelerate.

Các parameter ban đầu được tạo trên meta device.

Meta tensor là một thứ khá vui.

Nó biết:

1shape = [8192, 8192]
2dtype = bfloat16

nhưng không thực sự giữ 134MB dữ liệu tương ứng.

Nói đơn giản:

Nó giống bản vẽ của một cái tủ.

Biết cái tủ rộng bao nhiêu, cao bao nhiêu, có mấy ngăn.

Nhưng cái tủ chưa được đóng bằng gỗ.

Nhờ vậy AirLLM có thể tạo cấu trúc của một model cực lớn mà chưa phải nhét toàn bộ weights vào RAM hay VRAM.

Sau đó AirLLM gắn các forward hook vào:

1embedding
2decoder layer 0
3decoder layer 1
4...
5decoder layer N
6final norm
7lm_head

Trước khi một layer chạy:

1forward_pre_hook()

AirLLM làm:

1disk
2  ↓
3CPU
4  ↓
5GPU

Load weights của layer đó.

GPU tính toán.

Sau khi chạy xong:

1forward_hook()

weights lại bị chuyển về:

1meta

và bộ nhớ được dọn.

Luồng thực tế trở thành:

1SSD
2
3 ├─ Layer 0 ──→ GPU ──→ compute ──→ bỏ
4 ├─ Layer 1 ──→ GPU ──→ compute ──→ bỏ
5 ├─ Layer 2 ──→ GPU ──→ compute ──→ bỏ
6 │
7 └─ Layer N ──→ GPU ──→ compute ──→ bỏ

Do đó lượng VRAM dành cho weights gần với:

$$ VRAM \approx \max(Size(layer_i)) $$

thay vì:

$$ VRAM \approx \sum_i Size(layer_i) $$

Đây là lý do một model hàng trăm GB có thể chạy trên GPU vài GB.

Nhưng dữ liệu phải chạy một vòng rất xa

Ở đây bắt đầu có chuyện.

Trong inference truyền thống:

1VRAM
2  ↓
3GPU compute

Weights đã nằm sát GPU.

AirLLM biến nó thành:

 1SSD
 2 ↓
 3filesystem
 4 ↓
 5CPU memory
 6 ↓
 7PCIe
 8 ↓
 9VRAM
10 ↓
11GPU compute

Và chuyện này không chỉ xảy ra một lần.

Muốn sinh token tiếp theo, Transformer lại phải đi qua các layer.

Rồi token tiếp theo nữa.

Giả sử một Dense model có 140GB weights.

Nếu mỗi token thực tế phải đọc một lượng dữ liệu gần 140GB và SSD của chúng ta đạt 7GB/s, thì chỉ riêng giới hạn lý tưởng của storage đã là:

$$ 140 / 7 = 20\text{ giây} $$

cho mỗi lượt đọc toàn bộ weights.

Đây còn là thế giới thần tiên nơi:

SSD luôn đạt đúng 7GB/s.
Không có filesystem overhead.
Không có CPU overhead.
Không mất thời gian copy CPU → GPU.
GPU tính toán mất 0 giây.
Không có contention.
Không có tensor conversion.

Thế giới thật không dễ thương vậy.

Và đây là bản chất của AirLLM:

Nó biến vấn đề thiếu VRAM thành vấn đề I/O.

Chúng ta cứu được bộ nhớ.

Nhưng dòng sông dữ liệu bắt đầu chảy dữ dội từ SSD lên RAM, từ RAM qua PCIe, rồi vào GPU, token này nối token khác.

Không có bữa trưa miễn phí.

Prefetch: trong lúc GPU ăn món này, bếp chuẩn bị món tiếp theo

AirLLM có thêm một kỹ thuật khá hợp lý: prefetching.

Giả sử GPU đang tính Layer 20.

Thay vì chờ Layer 20 tính xong rồi mới bắt đầu đọc Layer 21 từ SSD, một thread khác có thể chuẩn bị Layer 21 trước.

1GPU:
2Layer 20 ───────── compute ─────────>
3
4CPU/SSD:
5          Layer 21 ─── load ───────>

Khi Layer 20 xong, Layer 21 có khả năng đã nằm sẵn trong CPU memory.

Hai công việc được overlap.

Repository từng ghi nhận prefetch giúp cải thiện tốc độ khoảng 10% trong một số trường hợp.

Code hiện tại còn cẩn thận với pinned memory.

Nếu layer không quá lớn, dữ liệu có thể được đặt trong page-locked memory để tăng tốc copy CPU → GPU.

Nhưng pinned memory cũng là đồ thật.

Nó bị khóa lại và hệ điều hành không thể tùy ý swap đi.

Với những layer MoE khổng lồ 17GB, prefetch hai layer có thể khóa hơn 30GB RAM.

Vì vậy AirLLM hiện giới hạn pinned layer ở khoảng 2GB.

Đây là một chi tiết rất nhỏ trong code nhưng cho thấy bài toán cuối cùng vẫn quay lại vật lý:

muốn nhanh hơn thì phải để dữ liệu ở gần nơi tính toán hơn.

Kimi K3 khiến AirLLM phải tiến thêm một bước

Layer streaming khá hợp với Dense Transformer.

Nhưng tới các mô hình Mixture of Experts (MoE), mọi thứ thú vị hơn.

Giả sử một MoE layer có 256 expert.

Nhưng với một token, router chỉ chọn 8 expert.

Ta có:

1256 experts
2      ↓ router
3
4 [3] [17] [61] [88] [102] [140] [201] [250]
5
6chỉ 8 expert được chạy

Nếu AirLLM load nguyên layer chứa cả 256 expert thì rất phí.

Và với Kimi K3, không chỉ phí.

Nó còn có thể không fit nổi.

Theo PR bổ sung Kimi K3 cho AirLLM, một layer của model này có khoảng:

~17GB dữ liệu ở dạng packed.
~56GB sau khi expand.

Trong khi thử nghiệm được thực hiện trên RTX 6000 Ada 48GB.

Load nguyên layer đã không được rồi.

Thế là AirLLM xuống thêm một tầng.

Không còn:

1load layer

mà thành:

1load expert

Per-expert streaming

Code hiện tại tìm các tensor thuộc từng expert trong file safetensors.

Sau đó mỗi expert lại được gắn forward hook.

Khi router quyết định:

1Token này cần Expert 27

AirLLM mới:

1SSD
2 ↓
3đọc tensor của Expert 27
4 ↓
5GPU
6 ↓
7compute
8 ↓
9thả Expert 27 ra

Expert 28 không được chọn?

Không load.

Expert 29 không được chọn?

Cũng không load.

Đây là điểm mà định dạng safetensors trở nên rất hữu ích.

AirLLM có thể seek và đọc một nhóm tensor cụ thể, không cần đọc cả file layer khổng lồ.

Về trực giác:

Một thư viện có 10.000 cuốn sách.

Bạn cần trang 73 của cuốn số 8.291.

Cách ngây thơ:

Chở cả thư viện tới nhà.

Cách đỡ ngáo hơn:

Lấy đúng cuốn sách đó.

AirLLM với per-expert streaming còn cực đoan hơn:

Xé đúng vài trang cần đọc đem sang.

Đọc xong đem trả.

Theo PR #316, AirLLM đã gắn streaming cho hơn 82.000 expert trải trên 92 layer của Kimi K3.

Đây là lý do model 2.8T có thể có peak VRAM rất nhỏ mặc dù tổng checkpoint khổng lồ.

2.8T parameter chạy trong 3.72GB VRAM có thật không?

Có một benchmark rất đáng chú ý trong PR #316.

Tác giả thử toàn bộ checkpoint Kimi K3 khoảng 1.56TB trên một RTX 6000 Ada 48GB.

Kết quả được báo cáo:

1Peak VRAM sau init:       0.83 GB
2Peak VRAM khi generate:   3.72 GB
3
44 token:
51168 giây
6
7≈ 292 giây/token

Đọc tới đây chúng ta sẽ hiểu hai câu sau đồng thời đều đúng:

Kimi K3 2.8T có thể chạy với chưa tới 4GB VRAM.

và:

Đây không phải cách hợp lý để dựng chatbot production cần trả lời ngay lập tức.

292 giây/token nghĩa là gần 5 phút để sinh một token trong benchmark đó.

Một câu trả lời 100 token, nếu tốc độ tương tự, có thể ngồi ngắm mây rất lâu.

Xong inference, quá dễ.

Chỉ là lúc đó khách hàng có thể đã đi ngủ.

Đây không phải lỗi trong ý tưởng AirLLM.

Đó chính là trade-off mà thiết kế này chấp nhận.

AirLLM tối ưu cho:

1"Model có chạy được không?"

nhiều hơn:

1"Model phục vụ 10.000 request đồng thời được không?"

Vậy 4GB ở đây thực sự có nghĩa là gì?

Đây là chỗ rất dễ hiểu nhầm khi đọc headline.

4GB VRAM không có nghĩa:

12.8T parameters
2      ↓
3nén bằng phép thuật
4      ↓
53.72GB dữ liệu

Checkpoint Kimi K3 trong thử nghiệm vẫn khoảng 1.56TB.

AirLLM đơn giản là không đưa 1.56TB đó vào GPU cùng một lúc.

Ta có thể viết:

$$ Total\ Model\ Size \gg Peak\ GPU\ Memory $$

bởi vì lifetime của từng weight trên GPU rất ngắn.

Nó xuất hiện.

Được sử dụng.

Rồi biến mất.

Giống một đoàn tàu dài 20km đi qua một nhà ga dài 200m.

Không có thời điểm nào cả đoàn tàu nằm trong nhà ga.

Nhưng toàn bộ đoàn tàu vẫn đi qua đó.

Đấy là khác biệt cực kỳ quan trọng.

AirLLM rất giống virtual memory

Nếu đã học hệ điều hành, cách suy nghĩ này khá quen.

RAM nhỏ hơn không gian địa chỉ của chương trình.

Hệ điều hành có thể:

1disk
2 ↓
3page in
4 ↓
5RAM
6 ↓
7CPU sử dụng
8 ↓
9page out

AirLLM có thể xem như một dạng application-level paging cho weights:

 1SSD
 2 ↓
 3weight shard
 4 ↓
 5CPU
 6 ↓
 7GPU
 8 ↓
 9compute
10 ↓
11evict

Một bên paging memory page.

Một bên paging neural-network weights.

Và cả hai đều chịu chung một định luật:

page fault quá nhiều thì hệ thống chậm khủng khiếp.

Trong hệ điều hành, chúng ta gọi hiện tượng dữ liệu cứ phải chạy qua chạy lại giữa RAM và disk là thrashing.

Trong inference kiểu AirLLM, nếu compute rất nhanh nhưng cứ phải chờ SSD đọc layer tiếp theo, GPU cũng ngồi chơi.

GPU trị giá hàng nghìn đô lúc đó trở thành một ông thợ cực khỏe nhưng cứ mỗi lần đóng một cái đinh lại phải chờ xe tải chở cái búa tiếp theo tới.

Tại sao AirLLM không giống vLLM?

Hai project giải quyết hai vấn đề rất khác.

vLLM thường hướng tới:

1weights nằm sẵn trên GPU
2          ↓
3continuous batching
4          ↓
5KV cache management
6          ↓
7nhiều request
8          ↓
9throughput cao

AirLLM hướng tới:

1model lớn hơn VRAM rất nhiều
2          ↓
3stream weights
4          ↓
5chấp nhận latency lớn
6          ↓
7vẫn chạy được

Có thể tóm gọn:

	AirLLM	vLLM
Mục tiêu chính	Giảm memory requirement	Serving hiệu năng cao
Weights	Stream vào GPU	Thường resident trên GPU
Disk I/O khi inference	Rất quan trọng	Không phải đường nóng chính
Latency	Có thể rất cao	Tối ưu mạnh
Concurrent requests	Không phải thế mạnh	Thế mạnh
Model lớn hơn VRAM nhiều lần	Có	Không phải mục tiêu chính

Vì vậy mình sẽ không dùng AirLLM để thay vLLM cho API production chỉ vì thấy dòng chữ 70B on 4GB.

Hai con dao khác nhau.

Một con dùng thái thịt.

Một con dùng chặt cây.

Cầm nhầm vẫn cắt được thứ gì đó, nhưng khá mệt.

Compression có cứu được tốc độ không?

AirLLM còn hỗ trợ lưu layer ở dạng 4-bit hoặc 8-bit.

Ý tưởng rất dễ hiểu.

Nếu bottleneck là:

1SSD → RAM

thì thay vì đọc 1GB:

1đọc 250MB
2→ giải nén
3→ tính toán

có thể nhanh hơn.

README của project từng quảng bá mức tăng tốc lên tới khoảng 3 lần nhờ block-wise compression.

Nhưng đây là phần nên đọc cẩn thận.

Một issue năm 2026 (#330) benchmark Qwen2.5-32B trên hệ thống có storage nhanh lại ghi nhận kết quả ngược:

1Không compression: 13.3 s/token
28-bit:             50.5 s/token
34-bit:            106.7 s/token

Lý do được người benchmark chỉ ra khá hợp lý:

Khi SSD đủ nhanh, bottleneck không còn đơn giản là số byte đọc từ disk.

Chi phí dequantization mỗi layer có thể lớn hơn phần thời gian tiết kiệm được từ I/O.

Điều này cho chúng ta một bài học quan trọng.

Không có optimization nào tồn tại trong chân không.

Năm 2023:

1storage chậm
2→ giảm byte đọc
3→ thắng

Một hệ thống khác:

1NVMe nhanh
2→ I/O rẻ hơn
3→ dequantization trở thành bottleneck
4→ compression có thể thua

Do đó nếu triển khai AirLLM thật, nên benchmark trên chính máy của mình thay vì lấy con số README làm định luật Newton thứ tư.

AirLLM phù hợp với bài toán nào?

Theo mình, AirLLM rất thú vị trong vài trường hợp.

1. Thử model mà phần cứng không đủ chứa

Đây là use case rõ ràng nhất.

Bạn có một GPU 24GB hoặc 48GB nhưng muốn:

kiểm tra tokenizer;
chạy một số prompt;
nghiên cứu output;
debug compatibility;
thử một checkpoint cực lớn;
chạy offline task không yêu cầu realtime.

Thay vì lập tức thuê 8 GPU, AirLLM có thể cho phép model chạy được trước.

Chậm vẫn hơn không chạy được.

2. Nghiên cứu model khổng lồ trên workstation

Có những lúc chúng ta không cần 100 token/s.

Chúng ta chỉ muốn biết:

Model này có trả lời đúng bài toán của mình không?

Nếu chỉ cần vài sample, việc mất vài phút cho một token có thể vẫn chấp nhận được hơn việc dựng cả cluster.

3. Batch job không nhạy latency

Ví dụ một job chạy ban đêm, xử lý rất ít request nhưng yêu cầu model lớn.

AirLLM có thể đáng xem xét.

Tuy nhiên vẫn phải benchmark throughput tổng thể.

Chậm 10 lần còn có thể chấp nhận.

Chậm vài trăm lần lại là câu chuyện khác.

Và khi nào không nên dùng?

API realtime

Nếu khách hàng đang ngồi trước màn hình chờ chatbot trả lời, vài chục giây/token đã là rất khó sử dụng.

292 giây/token thì thôi.

Serving nhiều concurrent user

Layer streaming vốn đã tạo traffic storage rất lớn.

Nếu hàng chục request cùng kéo weight lên xuống độc lập, bài toán lập tức trở nên phức tạp.

Lúc này giữ model resident trên GPU và batching request thường hợp lý hơn nhiều.

Khi model đã fit trong VRAM

Nếu model vừa GPU thì việc liên tục load/offload layer có thể chỉ làm mọi thứ chậm đi.

Cái bàn đã đủ rộng thì đừng cứ ráp một miếng Lego rồi cất xuống đất.

Một điểm rất hay trong AirLLM 3.x: không tự viết lại Transformer

Những phiên bản hệ thống kiểu này thường gặp một vấn đề.

Llama có forward kiểu Llama.

Qwen có chi tiết riêng.

DeepSeek có MoE riêng.

Model mới xuất hiện lại có Rotary Embedding, attention implementation, cache API hoặc remote code khác.

Nếu AirLLM tự implement:

1for layer in model.layers:
2    ...

rồi tự tái tạo toàn bộ logic attention, KV cache và generation, code sẽ rất nhanh trở thành một vườn thú.

Phiên bản hiện tại chọn cách khá đẹp.

Nó để transformers điều khiển forward pass bình thường.

AirLLM chỉ chen vào lifecycle của weights bằng hook:

 1Transformers:
 2"Chuẩn bị chạy layer 22"
 3
 4AirLLM:
 5"Khoan, để tôi đi lấy weights."
 6
 7Transformers:
 8"Chạy."
 9
10AirLLM:
11"Xong rồi hả? Trả VRAM đây."

Nhờ vậy architecture mới mà Hugging Face đã hỗ trợ có khả năng chạy với ít code đặc thù hơn.

Đây là một quyết định thiết kế mình đánh giá khá hay.

Không giành luôn công việc của framework.

Chỉ can thiệp đúng chỗ mình cần.

Bài học lớn hơn AirLLM

Điều thú vị nhất của AirLLM với mình không phải con số 4GB.

Nó là một lời nhắc về cách chúng ta nhìn hardware.

Chúng ta thường nghĩ:

1Model 140GB
2GPU 80GB
3
4→ không chạy được

Nhưng câu nói chính xác hơn phải là:

1Model cần 140GB storage.
2
3Tại một thời điểm,
4bao nhiêu byte thực sự cần nằm trên GPU?

Hai câu này hoàn toàn khác nhau.

Ý tưởng này xuất hiện ở rất nhiều nơi trong lịch sử máy tính.

RAM không đủ:

→ virtual memory.

Dataset không vừa RAM:

→ streaming, chunking, batch processing.

Database không vừa memory:

→ buffer pool.

File khổng lồ:

→ mmap.

Model không vừa GPU:

→ tensor parallel, pipeline parallel, CPU offload, NVMe offload, layer streaming.

Vấn đề không phải lúc nào cũng là:

Làm sao chứa tất cả?

Đôi khi câu hỏi đúng phải là:

Tại sao phải chứa tất cả cùng lúc?

Nhưng vật lý cuối cùng vẫn thu tiền

Một token hiện lên trên màn hình trông rất nhẹ.

Nó chỉ là vài chữ.

Nhưng phía sau AirLLM, để chữ đó xuất hiện, một quá trình rất vật lý đang diễn ra.

SSD controller tìm những block dữ liệu.

Hàng tỷ bit bị kéo khỏi NAND flash.

Dữ liệu chạy qua bus vào RAM.

CPU chuẩn bị tensor.

PCIe đẩy hàng GB dữ liệu về GPU.

Transistor trong GPU bật tắt hàng tỷ lần.

Layer hoàn thành.

Weights bị vứt khỏi VRAM.

Rồi layer kế tiếp tới.

Rồi layer kế tiếp.

Một vòng như thế kết thúc.

Transformer sinh được một token.

Sau đó cả đoàn tàu lại chạy từ đầu cho token tiếp theo.

Thứ chúng ta gọi là Artificial Intelligence nghe rất giống một khái niệm nằm trong mây.

Nhưng kéo nó xuống đủ sâu, cuối cùng chỉ còn:

1electron
2memory
3bandwidth
4heat
5time

AirLLM không chiến thắng vật lý.

Nó thương lượng lại hợp đồng với vật lý.

Thay vì trả bằng VRAM, nó trả bằng SSD capacity, bandwidth và latency.

Và đôi khi đó là một cuộc trao đổi rất đáng giá.

Tổng kết

AirLLM có một ý tưởng cốt lõi rất đơn giản:

không cần giữ toàn bộ model trong GPU nếu tại một thời điểm chỉ đang tính một phần của model.

Với Dense model:

1load layer
2→ compute
3→ unload

Với sparse MoE:

1router chọn expert
2→ load đúng expert
3→ compute
4→ unload

Nhờ đó peak VRAM có thể nhỏ hơn tổng kích thước model hàng chục, hàng trăm, thậm chí hàng nghìn lần.

Nhưng đừng đọc câu:

Kimi K3 2.8T chạy với 3.72GB VRAM.

rồi dừng ở đó.

Hãy đọc thêm dòng ngay bên dưới:

Benchmark đó mất khoảng 292 giây cho mỗi token và bị giới hạn bởi disk I/O.

Hai con số đó phải luôn đi cùng nhau.

AirLLM vì thế không phải phép thuật biến GPU 4GB thành H100.

Nó giống virtual memory dành cho neural network hơn.

Một cách lấy thứ rất lớn, chia thành những mảnh đủ nhỏ, rồi lần lượt đưa từng mảnh qua một cánh cửa hẹp.

Con voi vẫn nặng vài tấn.

Cánh cửa vẫn chỉ rộng một mét.

Chúng ta chỉ vừa tìm ra cách cho nó đi qua.

AirLLM: Nhét một mô hình 2.8 nghìn tỷ tham số qua khe cửa 4GB VRAM