Tiết kiệm token: đừng chỉ nén, hãy đặt ranh

Tiết kiệm token: đừng chỉ nén, hãy đặt ranh

Token Saver gợi ra một quyết định quan trọng hơn hype: tài liệu nào cần qua model, tài liệu nào nên ở lại máy bạn.

Có một kiểu đau ví rất âm thầm: bạn kéo một file PDF 200 trang vào Claude, hỏi câu đầu thấy ổn, hỏi tiếp câu thứ hai cũng ổn, tới câu thứ năm thì mới nhận ra mình không chỉ trả tiền cho câu hỏi — mình đang trả tiền lại cho cả cái PDF khổng lồ trong lịch sử hội thoại.

Và rồi team bắt đầu tranh luận: “Hay đổi sang model context window 1M token?”, “Hay bật prompt caching?”, “Hay dùng tool nén gì đó?”.

Mình muốn rẽ câu chuyện sang hướng khác: vấn đề không phải là nhét được nhiều context hơn, mà là đặt ranh giới đúng giữa thứ model cần đọc và thứ hệ thống nên tự giữ. Token Saver, một MCP extension dùng Local Hybrid RAG cho Claude Desktop, đáng chú ý không phải vì con số tiết kiệm token nghe đã tai, mà vì nó nhắc builder một câu khá khó chịu: nhiều pipeline AI đang trả tiền cho phần đáng lẽ không nên gửi lên model ngay từ đầu.

Sơ đồ minh họa cho bài Tiết kiệm token: đừng chỉ nén, hãy đặt ranh

Sơ đồ tóm tắt ý chính của bài viết.

Tín hiệu mới: “context rẻ hơn” không đồng nghĩa “thiết kế tốt hơn”

Token Saver được giới thiệu như một MCP server local — chương trình chạy nền trên máy bạn để Claude gọi như một tool. MCP, hay Model Context Protocol, là giao thức giúp model tương tác với công cụ bên ngoài theo cách có cấu trúc. Ở đây, công cụ đó đọc PDF cục bộ, tạo chỉ mục tìm kiếm, rồi chỉ trả về đoạn liên quan cho model.

Điểm mấu chốt: PDF không cần rời khỏi ổ cứng.

Nguồn chính nói Token Saver có thể giảm token consumption khoảng 92% đến 99% trong bài toán hỏi đáp PDF. Con số này nên đọc như tín hiệu kỹ thuật, không phải lời hứa áp dụng y nguyên cho mọi team. Nếu tài liệu của bạn toàn bảng scan mờ, layout rối, hoặc câu hỏi cần tổng hợp toàn bộ hồ sơ, mức tiết kiệm sẽ khác.

Nhưng hướng đi thì rất rõ: đừng đưa cả tấm ván thô cho model rồi bắt nó tự bào phẳng. Hãy cắt, đo, đánh dấu phần cần dùng trước đã.

Lớp ẩn bên dưới: chi phí context là chi phí lặp

Nhiều team tính token theo kiểu “một lần upload tài liệu”. Sai nhẹ nhưng đau lâu.

Trong chat LLM, phần lịch sử hội thoại thường được gửi lại qua các lượt tương tác để model giữ ngữ cảnh. Nếu bạn nhét một PDF lớn vào đầu phiên, mỗi câu hỏi tiếp theo có thể kéo theo phần context khổng lồ đó. Với PDF, chi phí còn khó đo hơn vì hệ thống có thể xử lý cả text lẫn hình ảnh trang để giữ layout, chart, bảng biểu.

Nói thẳng ra thì: context window — vùng ngữ cảnh model còn giữ trong một lượt xử lý — không phải cái kho miễn phí. Nó giống mặt bàn thợ mộc: rộng hơn thì làm được đồ lớn hơn, nhưng cứ để cả đống gỗ vụn trên bàn thì thao tác nào cũng vướng.

Token Saver chọn hướng Local Hybrid RAG. RAG, tức Retrieval-Augmented Generation, là cách cho hệ thống tìm đoạn liên quan trước rồi mới đưa vào model để trả lời. “Hybrid” thường ám chỉ kết hợp nhiều kiểu tìm kiếm, ví dụ keyword search và vector search. Vector search là tìm theo độ gần nghĩa, không chỉ khớp chữ.

Ở cấp hệ thống, nó tách pipeline thành 4 lớp:

  1. Ingestion: đọc PDF và trích nội dung.
  2. Indexing: tạo chỉ mục để tìm lại nhanh.
  3. Retrieval: chọn đoạn có liên quan với câu hỏi.
  4. Generation: model chỉ nhận phần đã lọc để trả lời.

Framework để bạn nhớ: đừng tối ưu token ở lớp cuối nếu lỗi nằm ở lớp đầu.

Mổ xẻ ba hướng tiết kiệm: RAG, ảnh hóa, model dài

Tuần này có vài tín hiệu thú vị quanh cùng một nỗi đau: context đắt.

pxpipe chọn một mẹo khác: biến text dài thành PNG để giảm chi phí trong một số workflow với Claude Code và Fable 5. Lý do là cách định giá image token khác text token. Công cụ này render phần tĩnh như system prompt, tool docs, hoặc lịch sử cũ thành ảnh dày đặc. Theo bài của The Decoder, mức tiết kiệm trung bình được nêu khoảng 59% đến 70%.

Nhưng hướng này có tradeoff rất rõ: ảnh hóa text là lossy — có thể mất độ chính xác khi model đọc lại ký tự, hash, mã định danh, hoặc JSON dài. Nếu bạn đang debug production incident mà model đọc nhầm một ký tự trong config, tiền tiết kiệm token có thể đổi thành một buổi tối rất dài.

Trong khi đó, các model có context lớn như Laguna S 2.1 được công bố với context window tới 1M token cho bài toán agentic coding. Đây là tín hiệu quan trọng cho builder: model dài hơn mở ra workflow mới, nhất là codebase lớn, multi-file reasoning, hoặc tác vụ kéo dài.

Nhưng context dài không thay thế thiết kế retrieval. Nó chỉ cho bạn một tấm gỗ lớn hơn; còn mộng gỗ có khít hay không vẫn là chuyện bạn đo và đục thế nào.

So nhanh ba hướng:

| Hướng | Khi đáng dùng | Rủi ro chính |
|---|---|---|
| Local RAG như Token Saver | Hỏi đáp tài liệu lớn, cần privacy, câu hỏi thường chỉ cần vài đoạn | Retrieval sai thì model trả lời thiếu nền |
| Nén bằng ảnh như pxpipe | Context tĩnh, dài, ít cần exact string | Model đọc sai ký tự, chậm hơn do vision encoder |
| Model context dài | Tác vụ cần nhìn nhiều file hoặc chuỗi dài thật sự | Dễ lười thiết kế, chi phí lặp vẫn còn |

Điều đáng giữ: đặt “ranh giới dữ liệu” trước khi chọn model

Câu hỏi builder nên hỏi không phải “tool nào tiết kiệm nhiều nhất?”, mà là:

Dữ liệu này có cần đi qua boundary của provider không?

Boundary ở đây là ranh giới giữa máy/hạ tầng của bạn và server của nhà cung cấp model. Với tài liệu nhạy cảm — hợp đồng, hồ sơ khách hàng, nghiên cứu nội bộ — Local RAG có thêm lợi ích ngoài tiền: giảm bề mặt rò rỉ dữ liệu.

Hình dung thế này: team bạn có 5 người làm pháp chế nội bộ, mỗi ngày hỏi chatbot về hợp đồng mẫu, phụ lục, điều khoản cũ. Nếu cứ upload nguyên bộ tài liệu vào chat, bạn đang biến mỗi lượt hỏi thành một lần “chuyển đồ nghề ra ngoài xưởng”. Nếu dựng local index, model chỉ thấy mẩu gỗ đã được cắt đúng kích thước: đoạn điều khoản, tên file, số trang, metadata cần thiết.

Một buổi chiều, bạn có thể kiểm tra hướng này bằng checklist gọn:

Nếu không đo được cost chính xác, vẫn đo được hai thứ rất thực dụng: số ký tự gửi vào model và số lần câu trả lời phải sửa tay.

Điều dễ bị thổi quá: open-source không tự biến thành production

Token Saver là open-source và nhắm tới Claude Desktop, cài đặt được quảng bá là không cần Python environment hay terminal config. Điều đó tốt cho adoption, nhưng builder không nên dừng ở trải nghiệm desktop.

Nếu đưa vào workflow team, bạn còn phải hỏi:

Đây là chỗ nhiều demo RAG gãy: câu trả lời nhìn ổn, nhưng không audit được đường đi. Trong production, “model nói vậy” không đủ. Bạn cần biết nó dựa vào đoạn nào, phiên bản tài liệu nào, và vì sao đoạn đó được chọn.

AngelSpec của Tencent, dù nói về speculative decoding — kỹ thuật cho model nhỏ đề xuất token trước để model chính xác minh nhằm tăng tốc — cũng gợi cùng một bài học hệ thống: workload khác nhau cần chiến lược khác nhau. Conversation, code, math không nên dùng một cơ chế tối ưu duy nhất. Tương tự, PDF hợp đồng, textbook, log kỹ thuật, slide scan cũng không nên bị ném vào cùng một pipeline retrieval.

Sau bài này, nên đổi cách nghĩ gì?

Đừng xem token saving là trò vặt để né hóa đơn. Với builder, nó là bài toán kiến trúc: đặt dữ liệu ở đúng lớp, gửi context đúng lúc, và chỉ để model xử lý phần nó thật sự giỏi.

Nếu là mình, mình sẽ không bắt đầu bằng tool. Mình sẽ vẽ lại luồng dữ liệu: tài liệu nào ở local, đoạn nào được retrieve, metadata nào bắt buộc đi kèm, và câu hỏi nào mới xứng đáng dùng context dài.

Chọn model mới giống chọn gỗ tốt. Nhưng hệ thống chạy bền hay không nằm ở đường ghép — lệch nửa ly, cuối tháng lệch cả hóa đơn.

---
Bụi Wire — nghiện đọc release notes lúc 2 giờ sáng

Nguồn tham khảo