1 triệu token context: một con số, bảy kiến trúc, và sự thật về "long context"

Khi Claude đọc lại file lần thứ ba trong cùng một session

Tối thứ tư tuần trước, mình đang ngồi refactor một module auth nhỏ với Claude Code. Turn đầu tiên, Claude mở auth.rs, đọc 400 dòng, đề xuất một thay đổi. Mình đồng ý. Vài turn sau, mình hỏi tiếp: "thế còn cái edge case khi token expired thì sao?". Claude trả lời, nhưng trước khi trả lời, nó gọi lại Read trên đúng file auth.rs đó. Nội dung không đổi, file vẫn nằm yên trên disk, mới đọc xong cách đây bốn phút.

Lần đầu mình nghĩ là bug. Đến lần thứ ba trong cùng session thì rõ là không phải bug, là một pattern.

Đi tìm hiểu thì thấy nó có nhiều tên cụ thể: prompt cache TTL, compaction trigger, effective context window, persistent memory. Mỗi cái là một mảnh của cùng một câu chuyện. Câu chuyện đó là: context window mà Anthropic quảng cáo trên trang chủ không phải context mà mình thực sự có khi ngồi trước terminal. Và nó dẫn mình tới một câu hỏi lớn hơn: khi Anthropic, Google, OpenAI, DeepSeek, Meta đều quảng cáo "1 triệu token context", con số đó có ý nghĩa như nhau không?

Câu trả lời ngắn: không. Câu trả lời dài là bài này.

"1M context" là một nhãn gộp, không phải một khả năng thực sự

Bảng thông số là một thứ tệ vì nó ép những lựa chọn kiến trúc rất khác nhau vào cùng một con số duy nhất. Nó giống như nói hai chiếc xe đều "đi được 200 km một lần đổ xăng": có thể đúng về mặt kỹ thuật, nhưng một chiếc dùng động cơ nhỏ chạy đều ga, một chiếc dùng pin điện trên đường thẳng không leo dốc, một chiếc dùng thùng phụ gắn ngoài. Lúc lên đèo bạn mới biết bạn đang ngồi xe nào.

"1M context" cũng vậy. Cùng một con số, ít nhất năm kiến trúc khác nhau ở dưới, cộng thêm hai con số từ những lab không công bố kiến trúc. Giá tiền, độ trễ, độ chính xác ở token thứ 800,000 khác nhau hoàn toàn. Và quan trọng hơn cho người dùng hàng ngày: cách mỗi model "quên" thông tin khi gần cạn ngân sách context cũng khác nhau.

Để cho dễ hình dung, đi qua từng kiến trúc một. Nhưng trước đó, mình muốn đặt sẵn vài khái niệm để phần dưới đỡ nặng.

Một chút nền: vì sao long context lại khó

Phần này dành cho người chưa quen với cách hoạt động bên trong của LLM. Nếu bạn đã biết attention, RoPE, KV cache là gì, có thể bỏ qua section này.

Vấn đề gốc: attention scale theo bình phương. Trong một Transformer, mỗi token cần "nhìn" vào tất cả token đứng trước nó để quyết định mình nghĩa là gì trong ngữ cảnh đó. Mạnh, nhưng tốn. Một câu 1,000 token cần khoảng 1 triệu lượt so sánh. Một context 1 triệu token cần khoảng 1 nghìn tỷ. Đây là lý do mọi kiến trúc long context bên dưới đều đang cố gắng tránh trả full O(n²) một cách nào đó: hoặc bỏ qua bớt cặp token (sparse attention), hoặc đổi công thức để chi phí tăng tuyến tính (linear attention), hoặc nén context cũ thành dạng gọn hơn.

Position encoding (RoPE và những người bạn). Attention tự nó không biết "token này là token thứ mấy". Phải gắn thêm một "nhãn vị trí" vào mỗi token, gọi là positional encoding. RoPE là cách phổ biến nhất hiện nay. Vấn đề: model chỉ biết các vị trí đã được nhìn thấy lúc train. Nếu lúc train chỉ thấy vị trí 0 đến 256K mà inference lại hỏi vị trí 9 triệu, model "lạc" vì chưa biết vị trí đó trông thế nào. Đây là lý do "ngoại suy" độ dài context là một bài toán riêng.

KV cache và prefill. Khi model xử lý prompt, mỗi token sinh ra một cặp key-value lưu lại để các token sau dùng. Cache này gọi là KV cache. Bước tính toàn bộ prompt để xây cache này gọi là prefill. Prefill chiếm phần lớn chi phí cho prompt dài. Cache để dành dùng lại được, gọi là prompt caching, đây là cơ sở cho việc Claude tính tiền cache khác với input mới. Bên cạnh prompt caching, một hướng tối ưu khác là nén KV cache sau khi đã tạo - mình có viết riêng về TurboQuant của Google nén KV cache 6 lần và câu chuyện thật phía sau con số đó.

MoE (Mixture of Experts). Thay vì một model dày đặc 600B tham số luôn chạy hết, MoE chia thành N "chuyên gia" nhỏ, mỗi token chỉ kích hoạt 2-8 chuyên gia. Compute giảm, chất lượng giữ. Gemini 1.5 Pro, Llama 4, MiniMax-01, DeepSeek V3 đều là MoE.

Compaction (chỉ trong agentic CLI như Claude Code). Khi context đầy gần ceiling, hệ thống tự động xoá bớt phần cũ và thay bằng bản tóm tắt, để context tiếp tục có chỗ trống. Đây không phải tính chất của model, mà là cơ chế ở tầng wrapper Claude Code. Nó là nguyên nhân chính của hiện tượng "Claude đọc lại file" mình kể đầu bài.

OK. Giờ vào 7 kiến trúc.

Những kiến trúc dưới cùng một cái nhãn

Gemini: full attention thật, mở rộng bằng sức tính toán

Gemini 1.5 Pro là sparse mixture-of-experts Transformer, và Google đã xác nhận điều đó trong tech report 1.5. Họ tuyên bố ">99% needle retrieval at 10M tokens", train trên TPUv4 pods 4096 chip. Tech report Gemini 2.5 tiếp tục chỉ nói "efficient attention with multi-query support for long contexts", không đi sâu hơn.

Cộng đồng nghi Google dùng Ring Attention của Berkeley, hoặc kết hợp với Infini-attention. Cấu trúc Ring Attention, query block tính cục bộ còn KV blocks luân chuyển qua một vòng device, khớp đẹp với cấu trúc TPU pod. Nhưng đây vẫn là phỏng đoán. Google chưa xác nhận.

Điểm cần nhớ: Gemini là model duy nhất dám tuyên bố 10M, và benchmark needle-in-haystack thường xác nhận con số đó. Nhưng "needle" chỉ là việc tìm lại một dữ kiện đơn lẻ trong đống rơm. Suy luận multi-hop hoặc theo dõi trạng thái qua thời gian là chuyện khác hoàn toàn, mình sẽ quay lại phần này.

DeepSeek NSA: sparse từ đầu, không vá thêm về sau

Trước khi nói NSA làm gì, cần nói "sparse attention" nói chung là gì. Vanilla attention bắt mỗi token nhìn toàn bộ token đứng trước. Sparse attention chọn lọc: mỗi token chỉ nhìn một subset, vài trăm token thay vì cả triệu. Compute giảm mạnh. Vấn đề kinh điển của sparse: hầu hết approach trước đây là dán lên một model đã train với full attention. Model học pattern attention dựa trên việc nhìn tất cả, giờ bị ép chỉ nhìn một phần thì chất lượng tụt. Phải fine-tune lại nhiều, mà thường vẫn không bằng full attention.

NSA giải bài này theo hai bước:

1. Train sparse từ đầu. Model học attention pattern thẳng từ điều kiện "chỉ được nhìn một subset" ngay từ pretraining, không có cú shock chuyển từ dense sang sparse. Đây là ý nghĩa của chữ "Native" trong tên.
2. Hierarchical (hai tầng). Mỗi token có hai loại attention chạy song song: coarse compression (nén một block N token thành một token đại diện, dùng để nắm cái nhìn rộng), và fine selection (cho mỗi vùng quan trọng, chọn ra cụ thể vài token để xem chi tiết). Kết hợp lại: bạn có cả tầm nhìn tổng thể lẫn độ chính xác cục bộ, mà không phải trả O(n²).

Abstract NSA paper, các cụm từ chính được highlight: hierarchical sparse strategy, coarse-grained token compression, fine-grained token selection, Natively Trainable, arithmetic intensity-balanced.

Một điểm khác làm NSA practical: họ thiết kế ăn khớp với mật độ tính toán của tensor core trên H100/H800. Nói cách khác, sparse pattern không phải chỉ đẹp trên giấy, mà còn map được vào kernel CUDA chạy nhanh trên GPU thực. Kết quả ở 64K sequences: nhanh hơn đáng kể cả khi train lẫn inference, mà chất lượng vẫn ngang hoặc nhỉnh hơn full attention trên long-context tasks.

Trade-off: phải train từ đầu, không retrofit được model có sẵn. Bạn không thể dán NSA lên Llama 3 và mong nó work. Cái mình thấy thú vị là DeepSeek công khai toàn bộ paper. Bạn đọc paper, hiểu cơ chế, có thể tự cài lại. So với Anthropic chỉ đăng con số 1M trên blog, đây là một chênh lệch thông tin rất lớn. Nếu bạn muốn đào sâu thêm cách DeepSeek tiếp tục thí nghiệm hướng này ở thế hệ sau, mình có bài riêng về CSA, HCA và canh bạc 1M context của DeepSeek V4.

Llama 4 Scout: train ở 256K, tuyên bố 10M

Meta giới thiệu Llama 4 Scout với 17B active params, 16 experts, và "10 million token context". Họ gọi kiến trúc là iRoPE.

Để hiểu iRoPE làm gì, cần nhớ vấn đề của RoPE đã nói trong primer: nhãn vị trí chỉ được học cho range mà model gặp lúc train. Train với 256K nghĩa là model biết "nhãn 1" đến "nhãn 256000". Inference 10M nghĩa là model gặp nhãn 999K, 5M, 9M, mà chưa từng nhìn thấy bao giờ. Nó "lạc" theo nghĩa thật sự: không biết phải tin attention pattern nào cho khoảng cách đó.

NoPE (No Position Encoding) là một cách lách. Một số layer được làm việc mà không có nhãn vị trí gắn vào, model tự suy position từ pattern token. Vì không bị ràng buộc bởi giá trị nhãn cụ thể, layer NoPE ngoại suy độ dài tốt hơn về mặt lý thuyết. iRoPE = interleaved: phần lớn layer giữ RoPE để có thông tin vị trí cục bộ chi tiết (giúp hiểu syntax, neighbor), một số layer xen kẽ là NoPE để làm global attention không lo position bị "lạc".

Stack 8 layer iRoPE: layer 1, 2, 3, 5, 6, 7 dùng RoPE giữ vị trí cục bộ; layer 4 và 8 dùng NoPE cho global attention không có position encoding.

Trong lý thuyết, ý tưởng này ổn. Trong thực tế nó không cứu được Llama 4. Lý do gốc: dù NoPE giúp ngoại suy nhãn vị trí, model vẫn chưa từng học pattern attention cho sequence dài 10M. Train data chỉ tới 256K. Khi inference 10M, attention vẫn phải áp dụng pattern học từ 256K vào một thế giới gấp 40 lần. Meta có thêm temperature scaling cho attention lúc inference để bù lại, nhưng đó là kỹ thuật khá chuẩn rồi (cùng họ với attention scaling trong YaRN), không phải bí kíp riêng. Và thật ra, Llama 4 yếu trên long-context không chỉ tại kiến trúc. Chất lượng pretraining data, instruction tuning, post-training của Llama 4 cũng đang bị cộng đồng nghi ngờ. Đổ hết cho việc ngoại suy 40x là hơi gọn.

Thực tế khá tàn nhẫn. Fiction.live benchmark test Scout ở 128K, accuracy 15.6%. Đó là 1.28% của con số họ quảng cáo. Cùng benchmark, Gemini 2.5 Pro ở 120K đạt 90.6%. Zvi Mowshowitz có một bài tổng kết thẳng thừng: "Llama Does Not Look Good 4 Anything".

LMArena leaderboard tháng 4/2025: Llama-4-Maverick xếp hạng 32, đứng cùng hàng với Yi-Lightning, GPT-4o-2024-05-13, Qwen2.5-plus. Nguồn: The Decoder / LMArena.ai.

Bài học: ngoại suy 40 lần độ dài lúc train là một niềm tin lãng mạn, không phải kỹ thuật.

Qwen 2.5-1M: chồng vài mẹo lên một model train ngắn

Qwen2.5-7B-Instruct-1M và 14B-Instruct-1M đều open weights trên Hugging Face, và Alibaba công bố đầy đủ công thức. Cách tiếp cận của họ ngược hẳn với DeepSeek: thay vì train lại từ đầu, họ giữ nguyên model đã train ở context ngắn rồi chồng vài mẹo lên để mở rộng tới 1M. Hai mẹo chính:

DCA (Dual Chunk Attention) giải quyết đúng cái vấn đề iRoPE đã chật vật. Nếu model train với max 32K, RoPE chỉ học khoảng cách 0-32K. Khoảng cách 500K không tồn tại trong distribution training, model không biết phải làm gì. DCA chia sequence dài thành các chunk nhỏ hơn pre-training length, rồi xử lý position theo hai chế độ. Trong cùng chunk (intra-chunk), position được dùng nguyên gốc 0..N giống lúc train, không thay đổi gì. Giữa hai chunk khác nhau (inter-chunk), DCA gán một bảng position riêng được tính sao cho khoảng cách relative giữa hai token bất kỳ trong toàn sequence không bao giờ vượt quá khoảng cách model đã thấy lúc train. Chính cái phân tách intra/inter này mới là điểm mấu chốt làm DCA work. Hiệu ứng tâm lý cho model: nó "tưởng" mình đang nhìn 30 sequence ngắn liên kết với nhau, không phải 1 sequence 1M dài bất thường. Mọi position đều quen.

Sequence 1M token gốc với position 0..999999 được chia thành 4 chunk, mỗi chunk được đánh số lại từ 0..N để giữ trong vùng training distribution.

YaRN là tinh chỉnh đi kèm. Nó scale temperature trên attention logits theo độ dài sequence, làm pattern attention "co giãn" theo, giúp model thích nghi với độ dài mới mà không cần train lại trọng số. Hai mẹo này cộng với chunk prefill (xử lý từng chunk thay vì toàn bộ một lần) cho Alibaba giảm 96.7% activation VRAM và prefill nhanh hơn 3.2 lần ở 1M sequences.

Hiệu quả thì hiệu quả thật, nhưng bản chất là vá lên sau khi train xong. Trade-off: với task chỉ cần retrieval (tìm fact ở vị trí xa), DCA work. Với task cần long-range reasoning thật sự (kết nối thông tin xa nhau bằng nhiều bước suy luận), DCA có thể miss vì model chưa từng học pattern reasoning ở khoảng cách đó. Khác hẳn DeepSeek NSA, vốn học sparse pattern từ đầu nên có khả năng reasoning ở scale lớn.

MiniMax-01: linear attention thay vì softmax

MiniMax-01 paper chọn con đường cấp tiến nhất: thay vì giảm số cặp token cần so (sparse) hoặc lừa model về position (DCA), họ thay luôn công thức attention. Bỏ softmax, dùng "Lightning Attention" tuyến tính.

Phải nói thêm tại sao softmax là nguyên nhân chính của O(n²). Trong vanilla attention, mỗi cặp token (Q, K) cho một score, rồi softmax chuẩn hoá toàn bộ scores của một query thành xác suất, rồi lấy weighted sum của V. Bước softmax đòi tất cả scores tồn tại đồng thời để chuẩn hoá, nên không thể tách compute ra theo cách nào cho phép re-arrange thành O(n). Linear attention thay softmax bằng một phép toán tách được (kernel approximation). Nhờ tính chất kết hợp, computation re-arrange được sao cho cost tăng tuyến tính theo độ dài. 1M token chỉ tốn gấp 1000 lần 1K, không phải gấp 1 triệu lần. Đây là asymptotic. Trong thực tế, constant overhead của linear attention khá lớn, nên ở độ dài "vừa phải" (vài chục K cho tới quanh 100K), softmax thực ra vẫn nhanh hơn. Điểm cắt nơi linear thắng nằm ở context rất dài, đúng cái sân mà MiniMax đang muốn chơi.

So sánh chi phí tính toán: softmax attention O(n²) cong parabola dốc đứng, so với Lightning linear attention O(n) đường thẳng tuyến tính, cùng range 0 đến 1M token.

Họ train ở 1M context, ngoại suy lúc inference lên 4M. 456B total params, 45.9B active per token, 32 experts.

Trade-off cổ điển của linear attention: precise retrieval kém hơn softmax. Lý do trực quan: softmax có thể "dồn" hầu hết attention vào đúng 1 token quan trọng (xác suất gần 1), kernel approximation không sharp được như vậy, nó "phết" attention rộng hơn. Khi cần tìm exact một con số trong context dài, softmax thắng. Khi cần "tổng hợp xu hướng" trên nhiều token, linear ngang ngửa. MiniMax tuyên bố đã khắc phục bằng các chiến lược song song hoá tối ưu, nhưng benchmark độc lập từ cộng đồng còn ít. Đây là một canh bạc kiến trúc lớn, và mình chưa đủ dữ liệu để khen hay chê dứt khoát.

Claude 4.6: hộp đen

Anthropic ra mắt 1M context GA tháng 3 năm 2026, giá phẳng cho toàn bộ range, không nhân hệ số khi vượt 200K (trước đó Sonnet 4.5 bản beta tính giá premium cho phần đó). Nhưng không có paper. Không biết họ dùng sliding window, sparse, full attention với KV cache phân tầng, hay gì khác.

GPT-4.1: hộp đen

OpenAI giới thiệu GPT-4.1 với 1M context, viết "consistently retrieves information accurately at all positions and all context lengths, up to 1 million tokens". Cũng không có paper. Cũng không có benchmark độc lập nào hậu thuận câu đó.

Điều này quan trọng vì nó tạo ra một sự chênh lệch khó chịu: bạn so sánh DeepSeek NSA (có paper, kiểm chứng được) với Claude 1M (không có gì), nhưng cả hai đều xuất hiện trên cùng bảng thông số với cùng con số. Bạn không đang so sánh hai quả táo với nhau. Bạn đang so sánh một quả táo với một bức ảnh của quả táo.

Bảng tổng hợp

Ba lab mở toàn bộ kiến trúc và paper. Meta mở một phần. Google mở architecture cơ bản nhưng giấu chi tiết attention. Anthropic và OpenAI đóng hoàn toàn. Khi bạn thấy hai con số bằng nhau, mặc định bạn nên hỏi: cái nào kiểm chứng được?

Đối chiếu với thực tế: benchmark độc lập nói gì

Kiến trúc mở hay đóng chỉ là một mặt. Mặt khác là kết quả thực nghiệm. Nếu chỉ tin marketing, bạn nghĩ tất cả model đều dùng được toàn bộ context một cách trơn tru. Benchmark độc lập kể câu chuyện khác.

RULER benchmark của NVIDIA test 17 long-context model trên 13 loại task. Kết quả chính: tất cả model tuyên bố 32K+ nhưng chỉ một nửa giữ được "hiệu năng đủ tốt" ở 32K. "Dù đạt accuracy gần hoàn hảo trên NIAH cơ bản, gần như mọi model đều rớt mạnh khi context dài hơn."

Chroma "Context Rot" research tháng 7 năm 2025 test 18 model gồm GPT-4.1, Claude 4, Gemini 2.5, Qwen3. Kết luận đáng nhớ: một model có context 200K có thể giảm chất lượng đáng kể ngay từ 50K, tức một phần tư cửa sổ. Suy giảm diễn ra liên tục, không phải rơi vực. Ba cơ chế chính: lost-in-the-middle (thông tin ở giữa bị bỏ qua, accuracy giảm 30%+), attention bị loãng (100K token nghĩa là 10 tỷ cặp quan hệ, attention loãng ra), nhiễu từ nội dung gần giống nhưng không liên quan.

Fiction.LiveBench test khả năng theo dõi diễn biến theo thời gian và phân biệt thông tin của người đọc với thông tin của nhân vật. Gemini 2.5 Pro dẫn đầu với 90.6% ở 120K. Llama 4 Scout 15.6%. Llama 4 Maverick 28.1%. Khoảng cách rất lớn giữa "tìm kim trong đống rơm" và "hiểu một câu chuyện dài".

Còn OpenAI? Chính họ phát hành MRCR (Multi-Round Coreference) và biểu đồ trong bài announce GPT-4.1 cho thấy accuracy bản 2-needle tụt từ khoảng 84% ở 8K xuống còn khoảng 50% ở 1M. Marketing nói "consistently retrieves at all positions". Benchmark của chính họ nói khác. Cả hai đều không sai về mặt câu chữ, nhưng đặt cạnh nhau thì rất dễ gây hiểu lầm.

Còn Gemini "lười" ở long context cũng là kiểu mà cộng đồng báo cáo nhiều, issue #5269 trong gemini-cli mô tả "suy giảm đáng kể chỉ sau khi dùng 20% context". Người dùng cảm thấy Pro hoạt động như Flash khi prompt dài, như thể model "đọc lướt" input thay vì đọc kỹ. Google chưa phản hồi chính thức, nhưng kiểu hành vi này tái hiện được.

Quay lại câu hỏi đầu bài: tại sao Claude đọc lại file?

Giờ về câu hỏi của mình từ tối thứ tư. Tại sao Claude Code đọc lại đúng file vừa đọc xong vài phút trước? Câu trả lời không phải một nguyên nhân. Là năm.

Một, Claude Code wrapper kích hoạt compaction ở khoảng 83.5% context. Cần phân biệt: docs API của Anthropic cho phép set trigger threshold tuỳ ý (mặc định 100K-150K tokens). Còn 83.5% là ngưỡng riêng của Claude Code wrapper, có thể chỉnh qua biến môi trường CLAUDE_AUTOCOMPACT_PCT_OVERRIDE. Trước compaction, hệ thống xoá bớt tool output cũ trước, kết quả của Read bị xoá đầu tiên vì nội dung file thường to. Sau compaction, model chỉ còn nhìn thấy bản tóm tắt thay vì nội dung file gốc. Khi cần suy luận tiếp về file, vì không còn nội dung gốc trong context, nó phải gọi Read lại. Cách wrapper quản lý context, tool calls và compaction là một topic riêng đáng đào - mình đã ngồi với buzzword "harness engineering" một lần và viết lại trong bài này, nó là context tốt cho phần còn lại bên dưới.

Vòng đời context trong Claude Code: phiên mới (20%) → tool calls dồn lên (80%) → compaction kích hoạt ở 83.5% xoá tool output cũ → post-compact chỉ còn summary, file content biến mất → Read tool được gọi lại để re-fetch file.

Hai, prompt cache TTL mặc định 5 phút. Khi bạn idle quá 5 phút, cache bị xoá. Message tiếp theo sẽ prefill toàn bộ lịch sử hội thoại ở giá input đầy đủ, ba dollar mỗi triệu token cho Sonnet, không phải ba mươi cent ở giá cache. Có tuỳ chọn TTL 1 giờ nhưng phải bật riêng và trả thêm. Tệ hơn nữa, issue #46829 ghi nhận tháng 3 năm 2026 Anthropic lặng lẽ giảm mặc định từ 1 giờ về 5 phút, và rất nhiều người dùng Claude Code đột nhiên thấy quota tăng vọt mà không biết tại sao.

Screenshot GitHub issue #46829, hai đoạn được highlight vàng: "silently changed the prompt cache TTL default from 1 hour to 5 minutes sometime in early March 2026" và "20-32% increase in cache creation costs".

Ba, đọc lại toàn bộ hội thoại ở mỗi lượt. Kiến trúc Claude Code đọc lại toàn bộ lịch sử ở mỗi message, không có bộ nhớ liên tục giữa các phiên. Nếu bạn đóng terminal và mở lại ngày hôm sau, mọi thứ Claude "biết" từ phiên trước biến mất. Issue #28984 thảo luận chính cái khoảng cách giữa "context quảng cáo" và "context thực dùng" này.

Bốn, bản tóm tắt sau compaction có thể bịa. Issue #46602 ghi nhận một kiểu lỗi đáng sợ hơn: bản tóm tắt đôi khi bịa ra chỉ thị mà người dùng chưa từng gõ. Sau khi context bị reset, Claude thực thi những chỉ thị giả này như thể bạn vừa gõ. Mất thông tin đã tệ, sinh ra thông tin giả còn tệ hơn.

Năm, và quan trọng nhất, 1M context không sửa được vấn đề này. Ngay cả khi bạn bật Claude Opus 4.7 với 1M, phiên agentic trong Claude Code vẫn gặp compaction. Lý do: kết quả tool call chiếm phần lớn ngân sách. Một phiên 50-100 tool call có thể ngốn 200K-500K tokens chỉ riêng output của Bash, Read, Grep. Compaction kích hoạt trước khi chạm trần 1M. Context lớn hơn không xử lý nguyên nhân gốc, chỉ đẩy vấn đề ra xa hơn vài bước.

Bài học mình rút ra sau tối thứ tư đó: context window của model không phải context bạn thực sự có. "Context thực dùng" trong workflow agentic nhỏ hơn nhiều so với bảng thông số. Và chi phí mỗi task không tỉ lệ tuyến tính với độ dài context, nó tỉ lệ với tần suất cache miss và compaction.

Đọc bảng thông số như một tài liệu không trung lập

Mình đã lờ đi cái chênh lệch thông tin này khá lâu. Cứ đọc bảng thông số, thấy 1M, mặc nhiên cho rằng tất cả model đều "đọc được" 1M kiểu giống nhau. Sai. Ba lab mở toàn bộ (DeepSeek, Qwen, MiniMax) công khai paper và kiến trúc đầy đủ, bạn có thể kiểm chứng. Meta mở một phần (có paper iRoPE nhưng kết quả thực tế tách xa lý thuyết). Google mở architecture cơ bản nhưng không công bố chi tiết attention. Anthropic và OpenAI đóng hoàn toàn - chỉ công bố con số marketing. Khi con số marketing chọi nhau với benchmark độc lập, mặc định nghi ngờ là vị trí hợp lý.

Điều mình thấy khó chấp nhận hơn: Anthropic có thể lặng lẽ giảm một nửa cache TTL và đẩy chi phí lên cho tất cả người dùng Claude Code mà không có một dòng ghi chú thay đổi nào. Cộng đồng phải tự mở github issue để xác nhận với nhau. Một lab kín kiểu này, mỗi quyết định nội bộ đều có thể đổi mô hình giá của bạn 2-3 lần mà bạn không biết. Đó không phải vấn đề kỹ thuật, đó là vấn đề về phạm vi mà giá tiền của bạn có thể bị tác động.

Mình vẫn dùng Claude Code mỗi ngày, vẫn mở Gemini khi cần 1M thật sự, và vẫn nghĩ NSA của DeepSeek là kiến trúc thanh lịch nhất hiện tại trong số những thứ công khai được. Nhưng mình không còn đọc bảng thông số như một tài liệu trung lập nữa.

Lần tới khi bạn thấy một bảng thông số ghi 1M context, hỏi lại ba câu: kiến trúc nào ở dưới, có paper nào hậu thuẫn không, benchmark độc lập nào xác nhận. Nếu không trả lời được cả ba, con số đó là một cái nhãn, không phải một khả năng thật. Bạn vẫn có thể dùng nó, nhưng bạn nên biết bạn đang dùng cái gì.

Còn về phần tại sao Claude đọc lại file, mình vẫn chưa có câu trả lời nào đẹp hơn ngoài "viết CLAUDE.md tốt hơn, /compact thủ công sớm hơn, chấp nhận cache miss như một dòng chi phí cố định". Có thể mấy tháng tới Anthropic sẽ ra bộ nhớ liên tục thật sự. Có thể không. Trong lúc chờ, mình tắt Claude Code đi pha trà mỗi khi context gần đầy, và đó là toàn bộ "context engineering" mình có cho hôm nay.

Nếu bạn đang nghĩ về chuyện này, hoặc thấy mình đang sai ở chỗ nào (đặc biệt phần Gemini và Ring Attention, mình không chắc chắn lắm), mình muốn nghe bạn nghĩ gì.

FAQ:

Vài câu mình hay nhận được sau khi share bài này, gom lại đây cho gọn. Trả lời ngắn, chi tiết đầy đủ ở các section trên.

Tại sao 1M token context của các lab không hoạt động giống nhau?

Vì "1M" chỉ là con số đầu vào tối đa, không nói gì về kiến trúc bên dưới. Gemini dùng full sparse attention với hậu thuẫn TPU pod, DeepSeek NSA train sparse từ đầu, Qwen dùng DCA + YaRN vá lên model train ngắn, MiniMax thay luôn softmax bằng linear attention, Llama 4 ngoại suy từ 256K, còn Claude và GPT không công bố. Cùng nhãn 1M nhưng giá, độ trễ và độ chính xác ở token thứ 800,000 khác nhau hoàn toàn.

Tại sao Claude Code đọc lại file vừa đọc xong?

Có năm nguyên nhân chồng nhau: compaction kích hoạt ở 83.5% context và xoá tool output cũ trước, prompt cache TTL mặc định chỉ 5 phút (Anthropic giảm lặng lẽ từ 1 giờ tháng 3/2026), kiến trúc đọc lại toàn bộ hội thoại mỗi turn, bản tóm tắt sau compaction đôi khi bịa chỉ thị chưa từng có, và 1M context không sửa được vấn đề vì tool output có thể ngốn 200K-500K tokens trước khi chạm trần.

iRoPE của Llama 4 là gì và tại sao không cứu được model?

iRoPE = interleaved RoPE: phần lớn layer dùng RoPE giữ thông tin vị trí cục bộ, một số layer xen kẽ là NoPE (không có position encoding) để global attention không bị "lạc" khi ngoại suy độ dài. Vấn đề: dù NoPE giúp ngoại suy nhãn vị trí, model vẫn chưa từng học pattern attention cho sequence dài 10M. Train data chỉ tới 256K, inference 10M là thế giới gấp 40 lần. Fiction.live benchmark cho Scout 15.6% ở 128K - 1.28% con số quảng cáo.

DCA (Dual Chunk Attention) hoạt động thế nào?

DCA chia sequence dài thành các chunk nhỏ hơn pre-training length, rồi xử lý position theo hai chế độ: trong cùng chunk dùng position 0..N nguyên gốc, giữa hai chunk dùng bảng position riêng được tính sao cho khoảng cách relative không vượt quá khoảng cách model đã thấy lúc train. Hiệu ứng tâm lý cho model: nó "tưởng" đang nhìn 30 sequence ngắn liên kết, không phải 1 sequence 1M dài bất thường. Work cho retrieval, hạn chế cho long-range reasoning đa bước.

Linear attention khác softmax attention thế nào?

Softmax attention scale O(n²) vì bước softmax đòi mọi score tồn tại đồng thời để chuẩn hoá. Linear attention thay softmax bằng kernel approximation tách được, computation re-arrange thành O(n). 1M token chỉ tốn gấp 1000 lần 1K, không phải gấp 1 triệu. Trade-off: linear không "dồn" attention vào đúng 1 token sharp được như softmax, nên precise retrieval kém hơn. Khi cần tìm exact một con số, softmax thắng. Khi cần tổng hợp xu hướng trên nhiều token, linear ngang ngửa.

Lab nào công khai kiến trúc 1M context, lab nào đóng?

DeepSeek (NSA), Qwen (DCA + YaRN), MiniMax (Lightning) công khai paper đầy đủ, có thể tự cài lại. Meta công bố iRoPE nhưng benchmark độc lập tách xa lý thuyết. Google công bố architecture cơ bản (sparse MoE) nhưng giấu chi tiết attention long context. Anthropic Claude và OpenAI GPT-4.1 đóng hoàn toàn, chỉ công bố con số 1M trên blog không có paper hay benchmark độc lập hậu thuẫn.

Bình