Source: https://aiprimetech.io/vi/blog/reduce-llm-token-usage/

Tháng Sáu 20, 2026 · 7 phút · API 

# Giảm mức sử dụng token bằng kỹ thuật mà không ảnh hưởng chất lượng 

 A  Tác giả [AI Prime Tech](https://aiprimetech.io/vi/)  · Có AI hỗ trợ    

Tháng trước, tôi đã đánh giá một tác nhân hỗ trợ khách hàng tiêu tốn 18,000–42,000 token đầu vào cho mỗi phiếu hỗ trợ trước khi viết được dù chỉ một từ. Vấn đề thực tế của người dùng thường được trình bày trong chưa đến 300 token. Phần còn lại là ngữ cảnh “phòng khi cần”: toàn bộ lịch sử hội thoại, mọi trang chính sách nội bộ được truy xuất bằng tìm kiếm từ khóa, JSON kết quả công cụ được sao chép nguyên văn và một prompt hệ thống dài 900 token đã tích tụ thêm nội dung trong sáu tháng. 

Cách khắc phục không phải là “dùng mô hình nhỏ hơn” hay “giảm max_tokens rồi hy vọng.” Chúng tôi giảm mức sử dụng token trung vị khoảng 68% mà vẫn giữ chất lượng câu trả lời ổn định bằng những công việc kỹ thuật giản dị: cắt gọn ngữ cảnh, truy xuất bằng chứng có phạm vi hẹp hơn, tóm tắt trạng thái, áp dụng chặt chẽ lược đồ đầu ra và đo lường token một cách trung thực. 

Bài viết này nói về kiểu công việc đó. Không phải cuộc thi rút gọn prompt. Không phải những mẹo khiến mô hình hoạt động kém hơn. Chỉ là những cách thiết thực để tiêu tốn ít token hơn mà không làm hệ thống của bạn kém thông minh đi. 

## Mức sử dụng token là một vấn đề kiến trúc 

Hầu hết các nhóm xem chi phí token là vấn đề về giá mô hình. Trên thực tế, đó thường là vấn đề định tuyến thông tin. 

Một lời gọi LLM điển hình trong môi trường sản xuất có bốn nhóm token:  
- Token chỉ dẫn: prompt hệ thống, prompt của nhà phát triển, quy tắc định dạng, ràng buộc an toàn. 
- Token ngữ cảnh: lịch sử trò chuyện, tài liệu được truy xuất, đầu ra công cụ, bản ghi cơ sở dữ liệu. 
- Token suy luận/tác vụ: yêu cầu thực tế của người dùng và các chi tiết trung gian của tác vụ. 
- Token đầu ra: phản hồi được sinh, đối tượng JSON, truy vấn SQL, bản tóm tắt hoặc lời gọi công cụ.  

Khi mức sử dụng token vượt khỏi tầm kiểm soát, ngữ cảnh và đầu ra thường là nguyên nhân. Mô hình không tốn kém vì người dùng đặt câu hỏi khó. Nó tốn kém vì ứng dụng nhồi cả thế giới vào prompt rồi cho phép mô hình nói lan man. 

Một bước đầu hữu ích là ghi nhật ký mức sử dụng token theo từng phần, thay vì chỉ ghi tổng kích thước yêu cầu: 

```
{
  "request_id": "ticket_81291",
  "model": "sonnet-4.6",
  "tokens": {
    "system": 742,
    "history": 3890,
    "retrieval": 12640,
    "tool_results": 2110,
    "user": 184,
    "output": 931
  },
  "latency_ms": 4820
}
```

Khi thấy được cách phân chia này, hướng tối ưu hóa sẽ trở nên rõ ràng. Bạn không cần tranh luận một cách trừu tượng xem Claude Opus 4.8, Sonnet 4.6, GPT-5.5, Gemini 3, Fable 5 hay một mô hình mở như Qwen hoặc DeepSeek là “tốt nhất”. Trước tiên, bạn cần ngừng gửi 12,000 token truy xuất không liên quan. 

## Bắt đầu với ngân sách token cho từng luồng xử lý 

Tôi thích phân bổ ngân sách theo từng luồng xử lý của sản phẩm, thay vì áp dụng chung cho toàn hệ thống. Công việc rà soát hợp đồng pháp lý, tác nhân lập trình và bot trả lời câu hỏi thường gặp không nên dùng chung các giả định về token. 

Ví dụ về ngân sách cho một trợ lý hỗ trợ: 

 | Phương án | Ngân sách đầu vào | Ngân sách đầu ra | Nhóm mô hình | Ghi chú

 | Phân loại phiếu hỗ trợ | 600 | 50 | Mô hình rẻ/nhanh | Nhãn, mức độ khẩn cấp, ngôn ngữ

 | Truy xuất bằng chứng | 1,500 | 0 | Embedding/tìm kiếm | Không cần sinh nội dung

 | Soạn câu trả lời | 4,000 | 600 | Mô hình mạnh thuộc phân khúc trung/cao | Sử dụng bằng chứng đã chọn

 | Tóm tắt chuỗi hội thoại | 1,000 | 250 | Mô hình rẻ/nhanh | Cập nhật trạng thái bộ nhớ

 | Phân tích nhu cầu chuyển cấp xử lý | 6,000 | 900 | Mô hình mạnh | Chỉ dành cho trường hợp phức tạp 

Điểm chính không phải là những con số này đúng trong mọi trường hợp. Chúng được cố ý đặt làm các ràng buộc ban đầu ở mức khiêm tốn. Điều hữu ích là mỗi giai đoạn phải chứng minh lượng token mình sử dụng là cần thiết. 

Một điều dễ mắc phải: nếu bạn chỉ đặt max_tokens cho đầu ra, đầu vào vẫn có thể âm thầm phình to. Giới hạn đầu ra ngăn câu trả lời quá dài; chúng không ngăn việc nhồi nội dung truy xuất. 

## Cắt gọn ngữ cảnh trước khi truy xuất, không phải sau đó 

Nhiều hệ thống truy xuất tài liệu bằng tin nhắn mới nhất của người dùng nhưng vẫn đưa toàn bộ lịch sử hội thoại vào prompt cuối cùng. Điều đó có nghĩa là những chủ đề lạc hướng cũ, các lời gọi công cụ thất bại trước đó và những giả định lỗi thời vẫn nằm trong ngữ cảnh. 

Thay vào đó, hãy duy trì một trạng thái làm việc gọn: 

```
{
  "user_goal": "Get refund for duplicate annual subscription charge",
  "known_facts": [
    "User paid twice on 2025-01-08",
    "Invoice IDs: inv_1042 and inv_1077",
    "Account email: user@example.com"
  ],
  "constraints": [
    "Refund policy allows duplicate-charge refunds within 90 days",
    "User prefers email follow-up"
  ],
  "open_questions": [
    "Whether one charge has already been reversed"
  ],
  "last_updated_turn": 12
}
```

Khi đó, lời gọi cuối cùng của bạn sẽ bao gồm:  
- Trạng thái đã được cô đọng. 
- Tin nhắn mới nhất của người dùng. 
- Chỉ những đoạn chính sách được truy xuất có liên quan. 
- Có thể thêm một hoặc hai lượt hội thoại gần nhất nếu cần duy trì giọng điệu nhất quán.  

Đừng đưa mọi tin nhắn trước đó vào một cách máy móc. Lịch sử trò chuyện không phải là bộ nhớ; nó là bản ghi hội thoại. Bộ nhớ là trạng thái đã được chắt lọc, cần thiết để tiếp tục tác vụ. 

Trong thực tế, tôi sử dụng ba lớp:  
- Các lượt gần đây: 1–4 lượt gần nhất, tùy theo độ nhạy cảm của tác vụ. 
- Bản tóm tắt được cập nhật liên tục: các sự kiện và quyết định ổn định. 
- Truy xuất bên ngoài: tài liệu, bản ghi cơ sở dữ liệu, đầu ra công cụ.  

Cách này thường hiệu quả hơn việc nhồi nguyên bản ghi hội thoại vì mô hình nhận ít nhiễu hơn và ít chỉ dẫn mâu thuẫn hơn. 

## Truy xuất cần có chọn lọc, không phải để làm cảnh 

Sinh nội dung tăng cường truy xuất thường khởi đầu như một cách cải thiện chất lượng rồi trở thành nguồn lãng phí token. Dạng lỗi này rất dễ nhận ra: top-k được đặt thành 10 hoặc 20, mỗi đoạn có 1,000 token và prompt cuối cùng chứa cả đống tài liệu chỉ liên quan mơ hồ. 

Truy xuất tốt hơn thường cũng ít tốn kém hơn. 

Một quy trình truy xuất thiết thực: 

```
def build_context(query, user_state):
    search_query = rewrite_for_search(query, user_state)

    candidates = vector_search(
        query=search_query,
        top_k=30,
        filters={"product": user_state["product"]}
    )

    reranked = rerank_cross_encoder(
        query=search_query,
        docs=candidates,
        top_k=6
    )

    selected = []
    token_budget = 1800

    for doc in reranked:
        snippet = extract_relevant_span(doc.text, query=search_query, max_tokens=300)
        if token_count(selected) + token_count(snippet) <= token_budget:
            selected.append({
                "doc_id": doc.id,
                "title": doc.title,
                "text": snippet
            })

    return selected
```

Những chi tiết quan trọng:  
- Truy xuất nhiều ứng viên hơn số bạn dự định đưa vào. 
- Xếp hạng lại trước khi sinh nội dung. 
- Trích xuất các phần văn bản liên quan thay vì truyền toàn bộ các đoạn. 
- Áp dụng chặt chẽ ngân sách token cho truy xuất. 
- Giữ lại ID tài liệu để mô hình có thể trích dẫn hoặc tham chiếu bằng chứng trong nội bộ.  

Kích thước đoạn có vai trò quan trọng. Nếu các đoạn quá nhỏ, mô hình sẽ mất ngữ cảnh. Nếu chúng quá lớn, mỗi kết quả khớp sẽ kéo theo văn bản không liên quan. Với tài liệu sản phẩm và các trang chính sách, tôi thường bắt đầu với khoảng 300–600 token mỗi đoạn, giữ nguyên các tiêu đề, rồi điều chỉnh dựa trên những trường hợp thất bại. 

Điều gì thực sự xảy ra khi bạn nhồi quá nhiều ngữ cảnh truy xuất? Mô hình thường trở nên kém chính xác hơn. Nó cố dung hòa những chính sách gần nhau nhưng không liên quan, tiếp nhận các lưu ý đã lỗi thời hoặc trả lời sai phiên bản của câu hỏi. Giảm token có thể cải thiện chất lượng vì loại bỏ những yếu tố gây phân tâm. 

## Tóm tắt là nén thông tin có trách nhiệm 

Tóm tắt có thể tiết kiệm một lượng ngữ cảnh rất lớn, nhưng các bản tóm tắt cẩu thả rất nguy hiểm. Nếu bản tóm tắt bỏ sót một ràng buộc, tác nhân của bạn có thể tự tin làm sai. 

Tôi ưu tiên các bản tóm tắt có cấu trúc hơn văn xuôi: 

```
{
  "task": "Debug failing OAuth callback in staging",
  "environment": {
    "service": "auth-api",
    "branch": "release-2025-02-14",
    "runtime": "node 20"
  },
  "confirmed": [
    "Callback returns 302 to /login",
    "Provider sends code and state",
    "State validation passes"
  ],
  "suspected": [
    "Session cookie is not persisted after callback"
  ],
  "rejected": [
    "Provider credentials are invalid",
    "Redirect URI mismatch"
  ],
  "next_steps": [
    "Inspect Set-Cookie attributes in staging response",
    "Compare SameSite and Secure flags with production"
  ]
}
```

Cách này tiết kiệm token hơn và đáng tin cậy hơn so với:  

Người dùng đang gỡ lỗi OAuth và đã thử nhiều cách…  

Một bước tóm tắt tốt cần giữ lại:  
- Mục tiêu của người dùng. 
- Các dữ kiện chắc chắn. 
- Các quyết định đã được đưa ra. 
- Các ràng buộc và ưu tiên. 
- Các cách đã thử nhưng thất bại. 
- Các câu hỏi chưa được giải đáp. 
- ID, tên tệp, dấu thời gian và các định danh chính xác khác.  

Đừng loại bỏ các giá trị chính xác khi tóm tắt, trừ khi chúng thực sự không liên quan. “Người dùng gặp vấn đề về hóa đơn” tốn ít token nhưng vô ích. “Khoản thu trùng lặp: inv_1042 và inv_1077 vào 2025-01-08” là kiểu rút gọn bạn cần. 

Với các tác nhân hoạt động dài hạn, tôi cũng lưu các phiên bản bản tóm tắt. Nếu mô hình tạo một bản tóm tắt kém, bạn cần có khả năng kiểm tra thời điểm trạng thái bắt đầu sai lệch. 

## Ngăn đầu ra dài dòng bằng lược đồ 

Một lượng token bị lãng phí đáng ngạc nhiên nằm ở phía đầu ra. Prompt yêu cầu “hãy ngắn gọn”, nhưng mô hình lại viết lời mở đầu, các lưu ý, phần tóm lược và lời đề nghị hỗ trợ. 

Với đầu ra dành cho máy xử lý, hãy dùng lược đồ. Đừng chỉ yêu cầu chung chung “một phản hồi JSON”; hãy xác định cấu trúc và từ chối mọi đầu ra không tuân theo. 

Ví dụ về lệnh gọi phân loại: 

```
{
  "type": "object",
  "additionalProperties": false,
  "required": ["category", "priority", "needs_human", "reason"],
  "properties": {
    "category": {
      "type": "string",
      "enum": ["billing", "bug", "account", "how_to", "other"]
    },
    "priority": {
      "type": "string",
      "enum": ["low", "normal", "high", "urgent"]
    },
    "needs_human": {
      "type": "boolean"
    },
    "reason": {
      "type": "string",
      "maxLength": 160
    }
  }
}
```

Với phản hồi hiển thị cho người dùng, hãy đưa ra định dạng kèm giới hạn cứng: 

```
Write the answer in this structure:

- First sentence: direct answer, max 25 words.
- Then 2-4 bullets with concrete steps.
- Do not include a greeting.
- Do not include "let me know if you need anything else."
- Stop after the final bullet.
```

Cách này hiệu quả hơn yêu cầu “hãy viết ngắn” vì nó cung cấp cho mô hình một cấu trúc. 

Một vấn đề thường gặp: giá trị thấp của max_tokens có thể cắt ngang đầu ra hữu ích khi ý chưa được trình bày hết. Lược đồ hoặc định dạng có ràng buộc giúp giảm độ dài đầu ra mà vẫn giữ được tính đầy đủ. Cắt ngắn là biện pháp cuối cùng, không phải chiến lược định dạng. 

## Sử dụng chuỗi dừng một cách thận trọng 

Chuỗi dừng hữu ích khi phần văn bản được sinh ra có điểm kết thúc tự nhiên. Ví dụ, nếu mô hình đang tạo một phần trong tài liệu theo mẫu, bạn có thể cho dừng tại dấu đánh dấu phần tiếp theo. 

```
{
  "model": "gpt-5.5",
  "messages": [
    {
      "role": "user",
      "content": "Generate only the Risk Summary section for this review..."
    }
  ],
  "max_tokens": 500,
  "stop": ["\n## Mitigations", "\n## Appendix"]
}
```

Chuỗi dừng ít hữu ích hơn với các phản hồi mở của trợ lý vì chúng có thể cắt bỏ nội dung hợp lệ. Chúng cũng hoạt động khác nhau giữa các API và họ mô hình, đặc biệt khi có gọi công cụ hoặc đầu ra có cấu trúc. Hãy xem chúng là cơ chế bảo vệ ranh giới, không phải kỹ thuật rút gọn chính. 

Các cách dùng phù hợp:  
- Tạo một phần của mẫu đã biết. 
- Ngăn mô hình tiếp tục viết sang phần ví dụ. 
- Dừng tại ký tự phân cách khi xử lý hàng loạt. 
- Áp đặt ràng buộc cho các prompt kiểu hoàn thành văn bản truyền thống.  

Các cách dùng tiềm ẩn rủi ro:  
- Dừng tại dấu câu thông dụng. 
- Dừng tại những từ có thể xuất hiện trong câu trả lời thông thường. 
- Dùng chuỗi dừng thay cho một lược đồ đầu ra phù hợp. 
- Giả định rằng hành vi giống hệt nhau giữa Claude, GPT, Gemini và các cổng truy cập mô hình mở.  

## Phân chia tác vụ cho các mô hình rẻ hơn 

Không phải bước nào cũng cần mô hình mạnh nhất của bạn. Trong các hệ thống vận hành thực tế, tôi thường định tuyến các tác vụ con đến các mô hình nhỏ hơn hoặc rẻ hơn: 

 | Tác vụ con | Yêu cầu điển hình | Lựa chọn phù hợp

 | Nhận diện ngôn ngữ | Phân loại đơn giản | Mô hình nhỏ/rẻ

 | Phân loại yêu cầu hỗ trợ | Đầu ra nhãn có cấu trúc | Mô hình nhỏ hoặc trung bình

 | Viết lại truy vấn | Biến đổi văn bản ngắn | Mô hình nhỏ hoặc trung bình

 | Xếp hạng lại tài liệu | Bộ xếp hạng lại chuyên dụng hoặc mô hình nhỏ | Dùng phương pháp phi sinh khi có thể

 | Câu trả lời cuối cùng | Suy luận kết hợp giọng điệu | Mô hình mạnh hơn

 | Ngoại lệ chính sách | Sắc thái và rủi ro | Mô hình mạnh nhất 

Đây là lúc khả năng truy cập nhiều mô hình mang lại lợi ích trong vận hành. Bạn có thể muốn dùng Sonnet 4.6 cho phần lớn công việc viết do tác nhân thực hiện, GPT-5.5 cho một hướng suy luận khó, Gemini 3 cho một số quy trình đa phương thức hoặc ngữ cảnh dài, Fable 5 khi thực sự cần cửa sổ ngữ cảnh 1M, và các mô hình mở như Llama, Qwen, DeepSeek, MiniMax hoặc Kimi cho các tác vụ nội bộ có kiểm soát. Điểm cốt lõi về kỹ thuật là định tuyến, không phải trung thành với thương hiệu. 

Hạn chế: chi phí điều phối là có thật. Mỗi lệnh gọi mô hình bổ sung đều làm tăng độ trễ, các dạng lỗi có thể xảy ra, độ phức tạp của việc ghi nhật ký và phạm vi cần đánh giá. Nếu một bộ phân loại rẻ tiết kiệm được 300 token nhưng làm tăng thêm 600 ms và một luồng thử lại nữa, thì có thể không đáng. 

Một cách tổ chức tôi thích: 

```
if route == "simple_faq":
    model = "haiku-4.5"
elif route == "standard_support":
    model = "sonnet-4.6"
elif route == "legal_or_financial_exception":
    model = "opus-4.8"
else:
    model = "sonnet-4.6"
```

Các tên cụ thể sẽ thay đổi. Nguyên tắc cần giữ nguyên: dùng mô hình rẻ nhất có thể đáp ứng ổn định tiêu chuẩn chất lượng của tác vụ. 

## Đo lường token đầu vào và đầu ra một cách trung thực 

Việc tối ưu token thất bại khi các nhóm chỉ nhìn vào chi phí trung bình mỗi yêu cầu. Bạn cần xem các phân phối, phân tách theo tuyến xử lý và giai đoạn. 

Ít nhất hãy theo dõi:  
- Token đầu vào theo từng phần của prompt. 
- Token đầu ra. 
- Số tài liệu được truy xuất và số token truy xuất. 
- Tên và phiên bản mô hình. 
- Các phân vị độ trễ. 
- Tỷ lệ trúng bộ nhớ đệm, nếu dùng bộ nhớ đệm prompt hoặc ngữ cảnh. 
- Số lần thử lại. 
- Các tín hiệu chất lượng mà người dùng nhận thấy. 
- Tỷ lệ chuyển cho con người xử lý hoặc chỉnh sửa.  

Một bảng điều khiển hữu ích hiển thị p50, p90 và p99. Các lỗi liên quan đến token thường nằm ở phần đuôi của phân phối. 

Ví dụ về một dòng nhật ký: 

```
{
  "route": "support.draft_answer",
  "model": "sonnet-4.6",
  "input_tokens": 3820,
  "output_tokens": 514,
  "retrieved_docs": 4,
  "retrieval_tokens": 1320,
  "latency_ms": 3100,
  "cache_hit": false,
  "quality": {
    "user_thumb": "up",
    "human_edited": false
  }
}
```

Hãy thận trọng với tuyên bố “chúng tôi đã giảm số token 40%”. Số lần thử lại có tăng không? Số lần chuyển cấp xử lý có tăng không? Người dùng có đặt thêm câu hỏi tiếp nối vì câu trả lời trở nên quá ngắn không? Mô hình rẻ hơn có tạo ra nhiều JSON không hợp lệ hơn, buộc phải gọi thêm để sửa không? 

Chỉ số trung thực không phải là số token mỗi lần gọi. Đó là số token cho mỗi tác vụ thành công. 

## Ngữ cảnh dài không phải là lý do để làm việc qua loa 

Cửa sổ ngữ cảnh lớn thực sự hữu ích. Khả năng xử lý ngữ cảnh ở mức 1M của Fable 5, thế mạnh về ngữ cảnh dài của Gemini và các chế độ ngữ cảnh dài trên những mô hình tiên tiến nhất cho phép thực hiện các quy trình vốn còn khó khăn vài năm trước: phân tích mã trên toàn bộ kho mã, rà soát tài liệu lớn, xử lý bản chép lời kéo dài nhiều giờ và các bộ tài liệu nghiên cứu có mật độ thông tin cao. 

Nhưng ngữ cảnh dài là một khả năng, không phải kiến trúc mặc định. 

Các lệnh gọi với ngữ cảnh dài có thể phù hợp khi:  
- Câu trả lời phụ thuộc vào nhiều phần nằm cách xa nhau trong đầu vào. 
- Việc truy xuất sẽ bỏ sót các mối liên hệ giữa các tài liệu. 
- Tác vụ mang tính khám phá và bạn chưa biết điều gì là quan trọng. 
- Chi phí do mất một chi tiết cao hơn chi phí đọc thêm.  

Chúng thường gây lãng phí khi:  
- Người dùng hỏi một câu hỏi hẹp về dữ kiện. 
- Một vài đoạn trích nguồn là đủ. 
- Ngữ cảnh chứa thông tin trùng lặp hoặc lỗi thời. 
- Mô hình đang được dùng làm bộ lọc cơ sở dữ liệu.  

Một cách tổ chức phổ biến là dùng ngữ cảnh dài để phân tích ngoại tuyến rồi tạo các sản phẩm đầu ra gọn nhẹ để phục vụ trực tuyến. Ví dụ, phân tích toàn bộ kho tài liệu chính sách một lần, rồi tạo bản đồ chính sách có cấu trúc, các biểu diễn nhúng, bản tóm tắt và ca kiểm thử. Trợ lý khi chạy không nên đọc lại toàn bộ kho tài liệu cho mỗi yêu cầu hỗ trợ. 

## Quy trình tối ưu thực tế 

Khi tiếp quản một hệ thống LLM tiêu tốn nhiều token, tôi thường thực hiện theo thứ tự sau:  
-  

Thiết lập đo lường trước
 Bổ sung thống kê token theo từng phần. Đừng tối ưu khi chưa có dữ liệu.  
-  

Giới hạn ngữ cảnh truy xuất
 Đặt ngân sách token truy xuất cứng. Xếp hạng lại và trích xuất các đoạn văn bản.  
-  

Thay việc nhồi toàn bộ lịch sử hội thoại bằng trạng thái
 Giữ các lượt hội thoại gần đây cùng bộ nhớ có cấu trúc.  
-  

Áp đặt ràng buộc cho đầu ra
 Dùng lược đồ cho đầu ra dành cho máy xử lý và định dạng rõ ràng cho đầu ra hiển thị cho người dùng.  
-  

Định tuyến các tác vụ con
 Chuyển các tác vụ phân loại, viết lại và tóm tắt sang mô hình rẻ hơn khi có thể đảm bảo độ tin cậy.  
-  

Đánh giá chất lượng ở cấp tác vụ
 So sánh các lần xử lý thành công, không chỉ chi phí mỗi lần gọi.  
-  

Theo dõi phần đuôi phân phối
 Điều tra các đợt tăng đột biến số token ở p95 và p99. Chúng thường cho thấy truy xuất bị lỗi hoặc lịch sử hội thoại tăng mất kiểm soát.   

Đây là một biện pháp kiểm soát đơn giản tôi đã dùng trong các dịch vụ: 

```
TOKEN_LIMITS = {
    "support.classify": {"input": 800, "output": 80},
    "support.retrieve": {"input": 500, "output": 0},
    "support.draft": {"input": 4500, "output": 700},
    "support.summarize": {"input": 1800, "output": 300},
}

def assert_token_budget(route, prompt_sections, max_output_tokens):
    input_tokens = {
        name: count_tokens(text)
        for name, text in prompt_sections.items()
    }

    total_input = sum(input_tokens.values())
    limits = TOKEN_LIMITS[route]

    if total_input > limits["input"]:
        raise TokenBudgetError(route, total_input, input_tokens)

    if max_output_tokens > limits["output"]:
        raise TokenBudgetError(route, max_output_tokens, {"output": max_output_tokens})
```

Dừng sớm khi có lỗi tốt hơn là một tuần sau mới phát hiện một truy vấn truy xuất sai đã tiêu hết ngân sách của bạn vào các tệp PDF không liên quan. 

## Những điểm cần áp dụng trong thực tế  
- Việc giảm token nên bắt đầu bằng khả năng quan sát: ghi nhật ký token đầu vào và đầu ra theo từng phần của prompt, tuyến xử lý và mô hình. 
- Truy xuất hiệu quả hơn việc nhồi nội dung khi có tính chọn lọc: xếp hạng lại, trích xuất các đoạn văn bản và áp dụng giới hạn ngân sách ngữ cảnh. 
- Bản tóm tắt nên là trạng thái có cấu trúc, không phải văn xuôi mơ hồ. Giữ nguyên các dữ kiện chính xác, ID, ràng buộc và những lần thử thất bại. 
- Lược đồ đầu ra giúp giảm diễn đạt lan man an toàn hơn so với việc chỉ hạ max_tokens. 
- Chuỗi dừng hữu ích để kiểm soát ranh giới, nhưng không thay thế được đầu ra có cấu trúc. 
- Chỉ chuyển các tác vụ con đơn giản sang mô hình rẻ hơn khi độ trễ bổ sung và các dạng lỗi phát sinh là sự đánh đổi đáng chấp nhận. 
- Đánh giá mức tiết kiệm theo số token trên mỗi tác vụ thành công, không phải số token trên mỗi lần gọi riêng lẻ. 
- Các mô hình có ngữ cảnh dài rất mạnh, nhưng không loại bỏ nhu cầu thiết kế kiến trúc thông tin.  

[Suy luận](/vi/blog/tag/inference/)[Prompt](/vi/blog/tag/prompts/)[Mô hình](/vi/blog/tag/models/)[API](/vi/blog/tag/api/) 

A

[AI Prime Tech](https://aiprimetech.io/vi/)

AI Prime Tech xuất bản blog này. Các bài viết được soạn với sự hỗ trợ của AI; hãy đối chiếu những chi tiết phụ thuộc vào phiên bản như ID mô hình, giá và giới hạn với tài liệu chính thức trước khi dựa vào chúng. 

 Truy cập Claude API với chi phí thấp hơn 

Một khóa API cho Claude Opus 5.5, Sonnet 5, Haiku 4.5 và Fable 5.1, cùng GPT-6 mô hình. Thanh toán theo mức sử dụng, không cần đăng ký thuê bao. [Nhận khóa API của bạn →](/register)  

AI Prime Tech là cổng API bên thứ ba độc lập. Claude™ và Anthropic® là các nhãn hiệu của Anthropic, PBC. Không hàm ý có sự liên kết hay chứng thực.