Hoạch Định Ngân Sách Token Prompt

Về Bộ Hoạch Định Ngân Sách Token Prompt

Prompt dài âm thầm bị cắt cụt, pipeline RAG đứt giữa chừng, hoá đơn mô hình bùng nổ — gần như luôn do ngân sách prompt chưa bao giờ được tính trước. Bộ hoạch định này cho bạn ước lượng không cần API, chạy hoàn toàn trên trình duyệt, về số token mà văn bản sẽ tiêu thụ trên Claude Opus/Sonnet, Claude 1M, GPT-4o, GPT-5/o3, Gemini 2.x, Llama 3.1, Mistral Large hoặc bất kỳ giới hạn tùy chỉnh nào, rồi chia văn bản thành các đoạn an toàn với cửa sổ chồng lấp tuỳ chỉnh.

Dành sẵn token cho câu trả lời, system prompt và schema công cụ, sau đó chọn chia theo đoạn, theo câu hoặc theo ký tự. Mỗi đoạn có nút sao chép riêng để dùng cho pipeline truy xuất, tóm tắt hàng loạt hoặc hội thoại tuần tự.

Ước lượng này chính xác đến đâu so với tokenizer thật của Anthropic, OpenAI hay Google?

Ước lượng của chúng tôi là heuristic hoạch định, thường lệch 5-15% so với số thật cho văn bản tiếng Anh, 10-20% cho mã nguồn và 15-25% cho ngôn ngữ CJK. Chúng tôi cố ý không nạp thư viện tokenizer (tiktoken, anthropic-tokenizer, gemini tokenizer) vì chúng nặng 2-15 MB WASM và một số yêu cầu gọi server. Bộ ước lượng dùng quy tắc 1 token ≈ 4 ký tự tiếng Anh ≈ 0,75 từ, tinh chỉnh theo loại văn bản: ký tự CJK thường là 1 token mỗi ký tự (~1,5 ký tự/token), code nhiều dấu câu (~3,5 ký tự/token), nội dung hỗn hợp/markdown pha trộn cả hai. Để tính tiền chính xác hãy dùng tokenizer của nhà cung cấp; còn để xem tài liệu 240k token có vừa cửa sổ 200k không, công cụ này cho bạn câu trả lời đúng.

Tại sao phải chia có chồng lấp thay vì cắt sạch ở ranh giới đoạn?

Không có chồng lấp, một câu hỏi hoặc dữ kiện nhắc ở cuối đoạn 1 sẽ không có câu trả lời nhìn thấy được trong đoạn 2 dù đáp án nằm trong thân đoạn 2, vì mô hình ở đoạn 2 không biết bối cảnh câu hỏi. Chồng lấp 5-15% (mặc định 10%) lặp lại đuôi đoạn N làm đầu đoạn N+1, giữ lại tham chiếu, lập luận đang tiếp diễn, các mục danh sách và tiêu đề bảng. Với RAG thuần tuý, 10% thường đủ; với tóm tắt pháp lý hay khoa học cần suy luận nhiều đoạn, tăng lên 20-25%; với chat ngắn hoặc rút trích FAQ độc lập, có thể giảm về 0%.

Tôi nên đặt 'Dành cho đầu ra' bằng bao nhiêu và tại sao nó quan trọng?

Mọi API LLM hiện đại tính cả đầu vào + đầu ra trong cùng cửa sổ ngữ cảnh. Nếu mô hình có 200.000 token và bạn nhồi 199.000 vào prompt, mô hình chỉ còn 1.000 để sinh — thường cụt giữa câu. Hãy dành ít nhất max_tokens (giá trị truyền trong API call) cộng biên an toàn. Giá trị thực tế: 4.096 cho chat thường, 8.192 cho tóm tắt dài, 16.384-32.768 cho sinh code, 64.000+ cho mô hình suy luận như o3/o1 vì chúng tiêu thụ rất nhiều token suy nghĩ ẩn. Extended thinking của Claude và thinking mode của Gemini cũng âm thầm ăn ngân sách dự trữ — tăng dự trữ 30-50% nếu bật.

System prompt, schema tool/function và file tải lên có tính vào giới hạn ngữ cảnh không?

Có — mọi input mà API nhận đều tính trên cùng cửa sổ ngữ cảnh. Một agent điển hình đốt 2.000-8.000 token trước cả khi có input người dùng: system prompt 500-2.000 token, schema tool/function (mỗi schema JSON khoảng 50-300 token, agent thường có 5-20 tool = 1.000-6.000 token), cộng PDF/ảnh đã được chuyển thành văn bản. Hãy nhập trung thực 'System prompt tokens' và 'Tool tokens' — nếu bộ hoạch định báo còn 195k/200k khả dụng, đó mới là ngân sách thật sau chi phí agent.

Khi nào dùng Claude 1M, Gemini 2.x 1M hay chia nhỏ trên mô hình nhỏ hơn?

Mô hình 1M trông thần kỳ nhưng có ba chi phí thực: (1) độ trễ — token đầu tiên có thể mất 30-90 giây với 800k+ token đầu vào; (2) giá — token đầu vào vẫn bị tính dù mô hình chỉ chú ý một phần; (3) suy giảm recall — đa số mô hình 1M có sụt giảm độ chính xác sau ~400k token, nhất là tìm thông tin giữa tài liệu ('lost in the middle'). Quy tắc: tài liệu dưới 150k token — dùng mô hình 200k chuẩn (rẻ, nhanh, đáng tin hơn). 150k-500k cần lập luận dài — dùng 1M native. 500k+ hoặc tải production lặp lại — chia chunk và dùng mô hình nhỏ kèm truy xuất.

Làm sao dùng các đoạn cho RAG hay tóm tắt hàng loạt?

Ba mẫu phổ biến. (1) Map-reduce: gửi từng đoạn riêng với cùng prompt ('tóm tắt phần này'), thu kết quả, rồi gửi tất cả tóm tắt trong lượt 2 để hợp nhất. (2) RAG: embed mỗi đoạn bằng mô hình embedding (text-embedding-3-small, voyage-3, gemini-embedding), lưu vào vector DB (Qdrant, pgvector, Pinecone), truy xuất top-K khi truy vấn. Với embedding, để chunk 200-800 token — nhỏ hơn mặc định; đặt 'Cửa sổ ngữ cảnh' bằng giới hạn của mô hình embedding (8192 OpenAI, 32k Voyage). (3) Hội thoại tuần tự: nạp từng đoạn trong hội thoại nhiều lượt, yêu cầu mô hình nhớ các sự kiện then chốt.

Tại sao ước lượng CJK và code khác với tiếng Anh?

Tokenizer BPE và SentencePiece tách các chuỗi con phổ biến thành 1 token. Trong tiếng Anh, 'the', 'and', 'tion' là một token, từ hiếm tách thành 2-4 token, trung bình ~4 ký tự/token. Văn bản Trung/Nhật/Hàn chủ yếu là ký tự đơn — các tokenizer của Anthropic, OpenAI, Google đều ánh xạ phần lớn ký tự CJK thành 1 token, cho ~1,5 ký tự/token. Mã nguồn nhiều dấu câu một ký tự ({}, [], (), ;, :, .) và định danh ngắn, mỗi cái tốn một token, cộng thêm thụt lề — ~3,5 ký tự/token. Hãy dùng tùy chọn 'hỗn hợp' cho markdown, file JSON cấu hình hoặc văn viết kỹ thuật xen kẽ văn xuôi và code.

Công cụ này có chạy offline không và prompt của tôi có bị gửi đi đâu không?

Hoàn toàn offline sau khi trang đã tải. Mọi ước lượng, chia đoạn và tính chồng lấp đều chạy trong trình duyệt bằng JavaScript thuần — không gọi API, không telemetry, không upload server. Bạn có thể ngắt mạng và công cụ vẫn hoạt động. Chúng tôi chọn ước lượng heuristic chính vì không bao giờ phải gửi prompt đến tokenizer ở xa. Với nội dung nhạy cảm (hợp đồng pháp lý, hồ sơ y tế, mã nguồn, tài liệu nội bộ), công cụ này an toàn. Dữ liệu duy nhất rời khỏi trình duyệt là analytics lượt xem chuẩn nếu bạn chưa tắt trong cài đặt riêng tư.