Chuyển đến nội dung chính

Hướng dẫn Requesty: Cổng LLM hợp nhất với chuyển đổi dự phòng tự động

Tìm hiểu cách sử dụng cổng LLM hợp nhất của Requesty, chuyển đổi dự phòng, bộ nhớ đệm và phân tích để xây dựng ứng dụng AI tin cậy, tiết kiệm chi phí trên nhiều nhà cung cấp.
· 13 phút đọc

Khám phá cùng AI

Ứng dụng AI của bạn chạy rất ổn với OpenAI cho đến khi hóa đơn chạm mốc 2.000 đô trong tháng. Bạn thêm Anthropic để lập luận tốt hơn và Google để tiết kiệm chi phí, và giờ bạn đang phải xoay xở với ba API khác nhau, mỗi cái có hệ thống thanh toán và giám sát riêng. Khi OpenAI gặp sự cố, ứng dụng của bạn hỏng. Khi chạm giới hạn tốc độ, người dùng thấy lỗi. Bạn cần một cách tiếp cận đáng tin cậy hơn.

Requesty giải quyết điều này bằng cách cung cấp một cổng hợp nhất với chuyển đổi dự phòng tự động và công cụ tối ưu chi phí. Cấu hình chuỗi dự phòng và tùy chọn bộ nhớ đệm một lần trong bảng điều khiển, rồi mọi yêu cầu API sẽ tự động áp dụng các chính sách đó. 

Khi một nhà cung cấp gặp sự cố, Requesty sẽ chuyển sang mô hình dự phòng của bạn. Khi bạn bật bộ nhớ đệm trên các nhà cung cấp được hỗ trợ như Anthropic, chi phí cho các truy vấn lặp lại sẽ giảm xuống.

Trong hướng dẫn này, tôi sẽ giới thiệu các khả năng cốt lõi của Requesty. Tôi bắt đầu với các lệnh gọi API cơ bản qua cổng hợp nhất và truyền phát phản hồi. Sau đó, chúng ta cấu hình chuyển đổi dự phòng tự động để đảm bảo thời gian hoạt động, bật bộ nhớ đệm nhà cung cấp để giảm chi phí khi truy vấn lặp lại, và dùng bảng điều khiển phân tích để theo dõi chi tiêu và tối ưu hóa việc sử dụng. Những tính năng này hoạt động giống nhau dù bạn đang xây dựng nguyên mẫu AI đầu tiên hay triển khai hệ thống sản xuất ở quy mô lớn.

Requesty là gì?

Ảnh chụp màn hình trang chủ Requesty cho một hướng dẫn

Requesty là cổng LLM hợp nhất kết nối bạn với hơn 300 mô hình từ các nhà cung cấp như OpenAI, Anthropic, Google, Meta và AWS thông qua một API duy nhất. Đây là dịch vụ quản lý, nên bạn không cần tự lưu trữ bất cứ thứ gì.

Tổng quan và các tính năng chính

Requesty cấu hình chính sách định tuyến qua bảng điều khiển thay vì code hay file cấu hình. Bạn thiết lập chuỗi dự phòng, trọng số cân bằng tải và tùy chọn bộ nhớ đệm qua giao diện web, và các chính sách này tự động áp dụng cho mọi yêu cầu API.

Cấu hình dựa trên bảng điều khiển cho phép:

  • Bộ nhớ đệm gốc của nhà cung cấp: Bật bộ nhớ đệm trên các nhà cung cấp được hỗ trợ như Anthropic và Gemini để tái sử dụng phần nhắc lặp lại và giảm chi phí cho các yêu cầu định kỳ.
  • Chuyển đổi dự phòng tự động nhanh: Nền tảng tự động chuyển sang mô hình dự phòng khi nhà cung cấp gặp sự cố, với cam kết SLA 99,99%.
  • Phân tích thời gian thực: Theo dõi token, chi phí, các phân vị độ trễ, tỷ lệ cache hit và tần suất chuyển đổi dự phòng cho tất cả yêu cầu qua một bảng điều khiển hợp nhất.

Những khả năng này kết hợp với các chính sách định tuyến linh hoạt (chuỗi dự phòng, cân bằng tải, tối ưu độ trễ), rào chắn bảo mật tích hợp cho PII và tiêm mồi nhắc, cùng theo dõi chi phí chi tiết.

OpenRouter cung cấp quyền truy cập hợp nhất tương tự tới nhiều LLM nhưng với định tuyến cơ bản và không có bảng điều khiển phân tích. LiteLLM có tính năng tương đương nhưng yêu cầu tự lưu trữ và cấu hình YAML thủ công cho chính sách định tuyến. Requesty nằm giữa hai lựa chọn này như một dịch vụ quản lý với cấu hình qua bảng điều khiển.

Khi nào tôi nên dùng Requesty?

Nếu bạn vận hành hệ thống doanh nghiệp với yêu cầu thời gian hoạt động nghiêm ngặt, SLA 99,99% là quan trọng. Khi ứng dụng ngừng hoạt động, bạn mất tiền. Các tính năng bảo mật tích hợp như che giấu PII và phát hiện tiêm mồi nhắc xử lý yêu cầu tuân thủ mà không cần tự xây dựng. Các đội ngũ hoạt động theo GDPR có thể bật lưu trữ tại EU để giữ dữ liệu đúng khu vực tài phán.

Nhóm phát triển xây dựng ứng dụng AI sản xuất tránh bị khóa nhà cung cấp bằng cách chuyển đổi qua cấu hình thay vì viết lại mã. Chuyển đổi dự phòng tự động giúp bạn không phải xây dựng hạ tầng độ tin cậy tùy chỉnh.

Các dự án tiết kiệm ngân sách được hưởng lợi từ bộ nhớ đệm của nhà cung cấp và cân bằng tải có chiến lược. Thay vì tự viết logic tối ưu, bạn cấu hình chính sách một lần và để Requesty xử lý việc giảm chi phí.

Yêu cầu tiên quyết

Thiết lập môi trường phát triển của bạn. Mất khoảng 5 phút và bao gồm các gói Python, khóa API, và cấu hình cơ bản.

Bạn cần cài Python 3.7 hoặc mới hơn trên hệ thống. Kiểm tra phiên bản của bạn:

import sys
print(f"Python {sys.version_info.major}.{sys.version_info.minor}")

Cài đặt các gói cần thiết bằng pip hoặc uv:

pip install openai python-dotenv
# or with uv: uv add openai python-dotenv

Bạn cần gói openai để tương tác với API của Requesty. Gói python-dotenv xử lý biến môi trường an toàn.

Tạo tài khoản Requesty tại app.requesty.ai. Sau khi đăng nhập, vào phần API Keys và tạo khóa mới. Sao chép khóa này để xác thực. Đừng quên nạp một ít tiền vào tài khoản của bạn.

Lưu khóa API vào file .env trong thư mục dự án:

REQUESTY_API_KEY=your_api_key_here

Cách này giúp tách thông tin xác thực khỏi mã và an toàn hơn khi chia sẻ dự án mà không lộ bí mật.

Xác minh mọi thứ hoạt động bằng cách tải biến môi trường và kiểm tra khóa API có thể truy cập hay không:

import os
from dotenv import load_dotenv
from openai import OpenAI

load_dotenv()
api_key = os.getenv("REQUESTY_API_KEY")

# Check your setup
if api_key:
   print("✓ API key loaded")
   client = OpenAI(
       api_key=api_key,
       base_url="https://router.requesty.ai/v1"
   )
   print("✓ Client configured")
else:
   print("✗ API key not found")

Nếu bạn thấy cả hai dấu kiểm, bạn đã sẵn sàng gửi yêu cầu đầu tiên.

Bắt đầu với Requesty: Thực hiện lệnh gọi API đầu tiên

Khi đã cấu hình môi trường và có khóa API, bạn có thể thực hiện lệnh gọi API đầu tiên. Requesty hoạt động như sự thay thế thả-vào của SDK OpenAI. Nếu bạn từng dùng OpenAI, thao tác này sẽ quen thuộc. Khác biệt duy nhất là trỏ client tới bộ định tuyến của Requesty.

Cách thiết lập client:

import os
from openai import OpenAI
from dotenv import load_dotenv

load_dotenv()

client = OpenAI(
   api_key=os.getenv("REQUESTY_API_KEY"),
   base_url="https://router.requesty.ai/v1"
)

Tham số base_url sẽ định tuyến yêu cầu của bạn qua Requesty thay vì gửi trực tiếp tới OpenAI. Bạn có thể thử với một lệnh gọi tới GPT-5:

response = client.chat.completions.create(
   model="openai/gpt-5",
   messages=[
       {"role": "user", "content": "Explain recursion in one sentence"}
   ]
)

print(response.choices[0].message.content)

Kết quả:

Recursion is a technique where a function solves a problem by calling itself on smaller inputs until it reaches a base case.

Tham số model dùng định dạng provider/model-name. Ở đây là openai/gpt-5, truy cập model mới nhất của OpenAI với khả năng lập luận gốc và hiệu năng cải thiện trong các tác vụ mã hóa và toán học. Ngoài định dạng model và base URL, SDK hoạt động y hệt OpenAI.

Lưu ý: Mỗi lệnh gọi API đều tốn tiền. Requesty cộng thêm 5% phụ phí so với giá gốc của nhà cung cấp, nên GPT-5 sẽ đắt hơn một chút qua Requesty so với gọi trực tiếp OpenAI. Bạn đang trả cho độ tin cậy, khả năng dự phòng và bảng điều khiển hợp nhất. Hãy theo dõi mức sử dụng qua bảng điều khiển Requesty để quản lý chi tiêu.

Đối tượng phản hồi chứa siêu dữ liệu hữu ích ngoài nội dung tin nhắn:

print(f"Model used: {response.model}")
print(f"Total tokens: {response.usage.total_tokens}")
print(f"Response: {response.choices[0].message.content}")

Kết quả:

Model used: gpt-5-2025-08-07
Total tokens: 108
Response: Recursion is a technique where a function solves a problem by calling itself on smaller inputs until it reaches a base case.

Số lượng token giúp bạn theo dõi chi phí vì giá thường tính theo token.

Chuyển sang nhà cung cấp khác bằng cách đổi tên model:

response = client.chat.completions.create(
   model="anthropic/claude-sonnet-4",
   messages=[
       {"role": "user", "content": "Explain recursion in one sentence"}
   ]
)

print(f"Claude says: {response.choices[0].message.content}")

Kết quả:

Claude says: Recursion is a programming technique where a function calls itself to solve a problem by breaking it down into smaller, similar subproblems until it reaches a base case that stops the repetition.

Claude 4 cung cấp cửa sổ ngữ cảnh mở rộng và khả năng lập luận cải thiện, đặc biệt mạnh cho phân tích mã phức tạp. Tất cả các model khả dụng đều theo mẫu nhà-cung-cấp/tên-model:

# OpenAI GPT-4o
model = "openai/gpt-4o"

# Anthropic Claude
model = "anthropic/claude-sonnet-4"
Wrap your API calls in error handling before moving to production:
try:
   response = client.chat.completions.create(
       model="openai/gpt-5",
       messages=[{"role": "user", "content": "Hello!"}]
   )
   print(response.choices[0].message.content)
except Exception as e:
   print(f"Error: {e}")

Điều này bắt các lỗi như hết thời gian mạng, khóa API không hợp lệ, hoặc model không khả dụng mà không làm ứng dụng sập.

Truyền phát (Streaming) để có phản hồi theo thời gian thực trong Requesty

Khi bạn yêu cầu một phản hồi dài, màn hình đóng băng vài giây trong lúc model tạo ra hàng nghìn token. Rồi mọi thứ đổ về cùng lúc. 

Người dùng nhìn vào màn hình trống và tự hỏi có gì đang diễn ra không.

Streaming giải quyết điều này bằng cách gửi từng phần phản hồi khi model đang tạo, giúp người dùng thấy chữ hiện dần, giống như ChatGPT. Điều này khiến ứng dụng phản hồi nhanh, đặc biệt với phản hồi dài như giải thích, sinh mã, hoặc sáng tác.

Để bật streaming trong Requesty, đặt tham số stream thành True:

response = client.chat.completions.create(
   model="openai/gpt-4o",
   messages=[
       {"role": "user", "content": "Explain recursion like I'm five years old"}
   ],
   stream=True
)

for chunk in response:
   if chunk.choices[0].delta.content is not None:
       print(chunk.choices[0].delta.content, end="", flush=True)

Phản hồi sẽ truyền từng chữ:

Okay! Imagine you have a big basket of toys, and you're trying to find your favorite teddy bear. 
But instead of looking through the whole basket all at once, you call your little sibling and say, 
"Can you look in here and find my teddy bear? If you see more baskets inside, ask someone else to help in the same way!" …

Tham số stream=True thay đổi phản hồi từ một đối tượng đơn thành một iterator trả về từng phần. Mỗi phần chứa một đoạn văn bản trong delta.content. Tham số end="" ngăn xuống dòng giữa các phần, và flush=True buộc hiển thị ngay thay vì đệm.

Ứng dụng sản xuất thường cần vừa trải nghiệm streaming vừa văn bản đầy đủ để ghi log hay phân tích. Một hàm hỗ trợ sẽ xử lý cả hai:

def stream_and_capture(model, messages):
   """Stream response to user while capturing complete text."""
   response = client.chat.completions.create(
       model=model,
       messages=messages,
       stream=True
   )
  
   complete_text = ""
  
   for chunk in response:
       if chunk.choices[0].delta.content is not None:
           text = chunk.choices[0].delta.content
           complete_text += text
           print(text, end="", flush=True)
  
   print()  # Final newline
   return complete_text

# Use it
full_response = stream_and_capture(
   "anthropic/claude-sonnet-4",
   [{"role": "user", "content": "Write a haiku about debugging code at 3 AM"}]
)

print(f"\nCaptured {len(full_response)} characters")

Kết quả:

Blinking cursor waits
Coffee cold, eyes burning red,
One missing bracket.

Captured 74 characters

Không phải lúc nào streaming cũng là lựa chọn đúng. Với phản hồi ngắn hoặc đầu ra có cấu trúc như dữ liệu JSON, yêu cầu thông thường đơn giản và nhanh hơn vì chi phí xử lý từng phần vượt quá lợi ích trải nghiệm người dùng.

Luồng có thể lỗi giữa chừng do sự cố mạng, giới hạn tốc độ, hoặc gián đoạn nhà cung cấp. Hãy bao bọc mã streaming trong xử lý lỗi cơ bản:

try:
   response = client.chat.completions.create(
       model="openai/gpt-4o",
       messages=[{"role": "user", "content": "Explain quantum entanglement in one sentence"}],
       stream=True
   )
  
   for chunk in response:
       if chunk.choices[0].delta.content is not None:
           print(chunk.choices[0].delta.content, end="", flush=True)
except Exception as e:
   print(f"\nError: {e}")

Nếu luồng lỗi, bạn bắt được lỗi và có thể thử lại thủ công hoặc chuyển sang model khác.

Chuyển đổi dự phòng tự động để tăng độ tin cậy

Ứng dụng sản xuất không thể chấp nhận thời gian chết. Khi OpenAI chạm giới hạn tốc độ vào giờ cao điểm, người dùng của bạn thấy lỗi. Khi Anthropic gặp gián đoạn, chatbot của bạn ngừng hoạt động. Những lỗi này là không thể tránh khỏi khi bạn phụ thuộc vào nhà cung cấp bên ngoài.

Requesty xử lý việc này bằng chuyển đổi dự phòng tự động. Khi model chính thất bại, Requesty chuyển sang model dự phòng trong vòng dưới 50 mili-giây.

Chuyển đổi dự phòng là gì và vì sao quan trọng

Hệ thống dự phòng phát hiện khi model chính không khả dụng và chuyển hướng yêu cầu của bạn sang model dự phòng mà không cần thay đổi mã. Việc phát hiện diễn ra tự động khi nhà cung cấp trả về lỗi, chạm giới hạn tốc độ hoặc hết thời gian chờ. Requesty sau đó định tuyến yêu cầu sang model tiếp theo trong chuỗi bạn đã cấu hình.

Requesty đảm bảo thời gian hoạt động 99,99% nhờ hệ thống này. Tức tối đa khoảng 4 phút ngừng hoạt động mỗi tháng, so với có thể hàng giờ nếu bạn chỉ dùng một nhà cung cấp không có dự phòng.

Ba loại chính sách điều khiển cách chuyển đổi dự phòng hoạt động:

  • Chuỗi dự phòng (Fallback Chain): Thử các model theo thứ tự. Nếu cái đầu thất bại, thử cái thứ hai. Nếu tiếp tục thất bại, thử cái thứ ba. Phù hợp khi bạn có model ưu tiên nhưng vẫn muốn có phương án dự phòng.
  • Cân bằng tải: Chia lưu lượng qua nhiều model theo tỷ lệ phần trăm. Bạn có thể gửi 70% đến GPT-5 và 30% đến Claude Sonnet 4 để giảm tải trên một nhà cung cấp. Khi một model không khả dụng, Requesty tự động định tuyến toàn bộ lưu lượng tới các model còn hoạt động.
  • Độ trễ: Định tuyến yêu cầu đến model phản hồi nhanh nhất. Requesty đo thời gian phản hồi và gửi lưu lượng tới lựa chọn có độ trễ thấp nhất. Tối ưu cho tốc độ hơn là chi phí.

Đa số đội ngũ bắt đầu với Chuỗi dự phòng vì tính dự đoán. Bạn nhận được model ưa thích khi khả dụng và tự động chuyển sang dự phòng khi không có.

Cấu hình chuỗi dự phòng

Thiết lập dự phòng diễn ra trong bảng điều khiển Requesty. Vào phần API Keys, rồi nhấn Policies. Tạo một chính sách Fallback Chain mới. Bạn sẽ thấy biểu mẫu để thêm model theo thứ tự ưu tiên.

Ảnh chụp màn hình giao diện bảng điều khiển Requesty hiển thị biểu mẫu cấu hình chính sách dự phòng

Đây là một chuỗi ví dụ cân bằng giữa chất lượng, chi phí và tính sẵn sàng:

1. openai/gpt-5

2. anthropic/claude-sonnet-4

3. deepseek/deepseek-r1:free

Chuỗi này thử GPT-5 trước vì nhanh và mạnh. Nếu thất bại, thử Claude Sonnet 4 với chất lượng tương tự. Nếu cả hai model cao cấp đều ngừng, nó sẽ chuyển sang DeepSeek R1, miễn phí và hầu như luôn khả dụng.

Sau khi lưu chính sách này và gắn nó vào khóa API, việc dự phòng diễn ra mà không cần thay đổi mã:

response = client.chat.completions.create(
   model="openai/gpt-5",
   messages=[{"role": "user", "content": "Explain how DNS works"}]
)

print(f"Model used: {response.model}")
print(response.choices[0].message.content)

Trường response.model cho biết model nào thực sự xử lý yêu cầu của bạn. Bảng điều khiển theo dõi tần suất dự phòng để bạn thấy khi nào model dự phòng được dùng.

Kết quả:

Model used: gpt-5-2025-08-07
DNS (Domain Name System) translates human-readable website addresses like "google.com" into IP addresses (like 142.250.80.46) that computers use to locate and connect to servers. This translation happens through a hierarchical system of DNS servers that cache and distribute this information globally for fast lookups.

Nếu tất cả model trong chuỗi đều thất bại, Requesty trả về lỗi sau khi thử từng cái. Bạn sẽ nhận phản hồi lỗi API chuẩn cho biết không có model nào khả dụng. Trường hợp này hiếm nhưng có thể xảy ra khi gián đoạn diện rộng.

Một vài hướng dẫn hữu ích khi xây dựng chuỗi dự phòng:

  • Dùng nhà cung cấp khác nhau: Nếu bạn đặt openai/gpt-5 và openai/gpt-4o trong chuỗi, cả hai có thể cùng ngừng khi OpenAI bị sự cố. Trộn nhiều nhà cung cấp để tăng độ tin cậy.
  • Sắp xếp theo chất lượng trước, rồi đến chi phí: Đặt model tốt nhất lên đầu. Nếu không khả dụng, thử model tốt kế tiếp. Phương án cuối cùng nên là lựa chọn đáng tin cậy nhất, dù chất lượng thấp hơn hoặc miễn phí.
  • Bao gồm ít nhất ba model: Một dự phòng nghĩa là có hai điểm lỗi. Ba model trở lên cho phạm vi bao phủ tốt hơn.
  • Kiểm thử chuỗi của bạn: Gửi vài yêu cầu và kiểm tra bảng điều khiển phân tích để xem model nào đang xử lý lưu lượng. Điều này xác nhận chính sách hoạt động đúng.

Trong khi LiteLLM yêu cầu cấu hình YAML thủ công cho dự phòng, Requesty xử lý tất cả qua chính sách trên bảng điều khiển.

Bộ nhớ đệm để giảm chi phí

Chạy đi chạy lại cùng một truy vấn sẽ tốn tiền. Nếu bạn có chatbot tài liệu trả lời lặp lại cùng câu hỏi, hoặc trợ lý mã hóa với system prompt giống nhau cho mọi yêu cầu, bạn đang trả đủ giá mỗi lần. Bộ nhớ đệm khắc phục bằng cách tái sử dụng phần nhắc không thay đổi.

Một số nhà cung cấp hỗ trợ bộ nhớ đệm prompt gốc. Anthropic và Gemini cho phép bạn lưu phần prompt không đổi và tái sử dụng giữa các yêu cầu. Điều này cắt giảm chi phí khi có mẫu lặp lại vì bạn chỉ trả đủ giá cho phần mới.

Khi bạn gửi yêu cầu với system prompt dài, nhà cung cấp sẽ lưu prompt đó vào bộ nhớ đệm của họ. Ở lần yêu cầu tiếp theo với cùng system prompt, họ lấy lại từ bộ nhớ đệm thay vì xử lý lại. Bạn trả phí đọc cache giảm thay vì chi phí xử lý đầy đủ.

Truyền auto_cache trong trường extra_body với một đối tượng requesty lồng nhau:

response = client.chat.completions.create(
   model="anthropic/claude-sonnet-4",
   messages=[
       {"role": "system", "content": "You are a helpful documentation assistant. You answer questions about Python's asyncio library based on the official docs. Be concise and include code examples."},
       {"role": "user", "content": "How do I create a basic event loop?"}
   ],
   extra_body={
       "requesty": {
           "auto_cache": True
       }
   }
)

print(response.choices[0].message.content)

System prompt giữ nguyên giữa các yêu cầu. Với auto_cache: True, Anthropic sẽ lưu nó vào bộ nhớ đệm sau yêu cầu đầu tiên. Các yêu cầu sau tái sử dụng prompt đã lưu và chỉ xử lý câu hỏi của người dùng.

Tham số bộ nhớ đệm chấp nhận ba giá trị:

  • True: Bật bộ nhớ đệm cho yêu cầu này
  • False: Cố tình bỏ qua bộ nhớ đệm ngay cả khi nhà cung cấp hỗ trợ (hữu ích cho dữ liệu nhạy cảm hoặc nội dung nhạy thời gian khi bạn muốn đảm bảo xử lý mới)
  • Bỏ qua: Dùng hành vi mặc định (không đệm trừ khi cấu hình toàn cục)

Chỉ Anthropic và Gemini hiện hỗ trợ lưu đệm prompt. Dùng auto_cache với nhà cung cấp khác sẽ âm thầm quay về xử lý bình thường mà không báo lỗi.

Khi nào nên dùng bộ nhớ đệm

Bộ nhớ đệm hiệu quả nhất khi bạn có system prompt dài và giữ nguyên giữa các yêu cầu. Chatbot tài liệu và trợ lý mã hóa là ví dụ điển hình. Bot FAQ và hệ thống hỗ trợ khách hàng cũng hưởng lợi khi người dùng hỏi các câu tương tự. Cơ sở tri thức với tài liệu tham chiếu lớn không đổi cũng là trường hợp mạnh.

Hãy bỏ qua bộ nhớ đệm khi mỗi yêu cầu cần dữ liệu mới. Ứng dụng thời tiết và giá cổ phiếu thuộc nhóm này. Gợi ý cá nhân hóa với prompt riêng cho từng người dùng sẽ không có lợi. Giám sát thời gian thực và luồng dữ liệu trực tiếp thay đổi quá thường xuyên để tận dụng bộ nhớ đệm.

Ví dụ này cho thấy một chatbot tài liệu cho thư viện Python. System prompt bao gồm toàn bộ tham chiếu API. Người dùng hỏi các câu khác nhau, nhưng system prompt giữ nguyên:

# Simulate a long API documentation string
long_api_documentation = """
Python AsyncIO Library Reference:
- asyncio.run(): Execute async functions
- asyncio.create_task(): Schedule coroutines
- asyncio.gather(): Run multiple tasks
... (this continues for 5,000+ tokens)
"""

# First request - cache miss, pays full price
response = client.chat.completions.create(
   model="anthropic/claude-sonnet-4",
   messages=[
       {"role": "system", "content": long_api_documentation},
       {"role": "user", "content": "How do I authenticate?"}
   ],
   extra_body={"requesty": {"auto_cache": True}}
)

print(f"Tokens: {response.usage.total_tokens}")
# Output: Tokens: 5,247 (full processing)

Yêu cầu thứ hai với cùng system prompt sẽ trúng bộ nhớ đệm:

# Second request - cache hit, reduced cost
response = client.chat.completions.create(
   model="anthropic/claude-sonnet-4",
   messages=[
       {"role": "system", "content": long_api_documentation},
       {"role": "user", "content": "What are rate limits?"}
   ],
   extra_body={"requesty": {"auto_cache": True}}
)

print(f"Tokens: {response.usage.total_tokens}")
# Output: Tokens: 312 (only new content processed, 5,000 tokens served from cache)

Phí đọc cache có thể giảm chi phí 50 đến 90% cho phần đã lưu.

Kiểm tra tỷ lệ cache hit trong bảng điều khiển Requesty, mục Analytics. Nếu dưới 40%, prompt của bạn thay đổi quá thường để có lợi từ bộ nhớ đệm. 

Hãy tìm các mẫu nơi bạn có thể chuẩn hóa system prompt hoặc tách nội dung biến đổi sang tin nhắn người dùng. Bảng điều khiển cũng hiển thị tổng mức tiết kiệm từ bộ nhớ đệm, phân tách theo nhà cung cấp và model, để bạn thấy chính xác nơi nỗ lực tối ưu phát huy hiệu quả.

Theo dõi chi phí và phân tích trong Requesty

Bảng điều khiển của bạn hiện khá trống. Bạn đã gửi vài yêu cầu thử, tiêu tốn khoảng 0,10 đô. Chưa có nhiều thứ để phân tích. Phần này chỉ ra những gì cần thiết lập ngay và những gì hữu ích về sau khi bạn chuyển sang sản xuất.

Đặt giới hạn chi tiêu là thói quen tốt ngay cả khi thử nghiệm. Vào phần API Keys trong bảng điều khiển, nhấp vào khóa của bạn và tìm “API Limits.” Đặt ngưỡng ngân sách hàng tháng 5 đô. Requesty sẽ cảnh báo ở mức 50%, 75% và 90% của giới hạn đó. Để bảo vệ nghiêm ngặt hơn, đặt mức trần sử dụng để dừng mọi yêu cầu khi chạm giới hạn. Điều này ngăn sự cố trong thử nghiệm và bảo vệ bạn khi vận hành.

Khi mức sử dụng tăng, Requesty theo dõi năm chỉ số chính:

  • Mức dùng token: Mỗi yêu cầu tiêu thụ bao nhiêu token
  • Theo dõi chi phí: Chi tiêu chính xác theo model và nhà cung cấp
  • Chỉ số độ trễ: Thời gian phản hồi P50, P95, P99
  • Hiệu suất bộ nhớ đệm: Tỷ lệ hit thể hiện mức tiết kiệm
  • Tần suất dự phòng: Tần suất dùng model dự phòng

Sau vài tuần lưu lượng sản xuất, các chỉ số này cho thấy mẫu hình giúp bạn tối ưu. Dùng bảng điều khiển để tìm quy trình đắt đỏ và chuyển sang model rẻ hơn, phát hiện truy vấn lặp lại và bật bộ nhớ đệm với auto_cache: true, và theo dõi mẫu dự phòng để điều chỉnh chuỗi fallback. Một chatbot tài liệu đã giảm chi phí từ 500 đô xuống 200 đô mỗi tháng bằng cách bật bộ nhớ đệm sau khi bảng điều khiển cho thấy 70% truy vấn giống hệt nhau.

Giám sát, mở rộng và thực tiễn vận hành trở nên thiết yếu khi bạn chuyển từ nguyên mẫu sang sản xuất. LLMOps bao quát toàn bộ vòng đời quản lý mô hình ngôn ngữ lớn trong môi trường sản xuất, bao gồm chiến lược tối ưu chi phí bổ trợ cho phân tích tích hợp của Requesty.

Kết luận

Bạn đã học cách Requesty hoạt động như cổng hợp nhất tới 300+ model AI qua một API duy nhất. Thiết lập rất đơn giản: cài SDK OpenAI, trỏ tới base URL của Requesty, và bạn đã kết nối. Từ đó, streaming cung cấp phản hồi tiến dần, chuỗi dự phòng đảm bảo thời gian hoạt động ngay cả khi nhà cung cấp gặp sự cố, và bộ nhớ đệm có thể cắt giảm một nửa chi phí khi bạn xử lý prompt lặp lại.

Lựa chọn giữa Requesty, LiteLLM và OpenRouter phụ thuộc vào ưu tiên của bạn. Nếu bạn cần hạ tầng quản lý với dự phòng tự động và phân tích tích hợp, Requesty xử lý sự phức tạp cho bạn. Các đội ngũ thoải mái với tự lưu trữ và muốn kiểm soát chi tiết có thể dùng cách tiếp cận mã nguồn mở của LiteLLM. OpenRouter cung cấp quyền truy cập hợp nhất cơ bản khi bạn thấy thoải mái với việc chọn model thủ công và không cần chính sách định tuyến nâng cao.

Bắt đầu bằng cách cấu hình chuỗi dự phòng với ba model từ các nhà cung cấp khác nhau, sau đó bật bộ nhớ đệm cho các yêu cầu có system prompt lặp lại. Cho các trường hợp phức tạp hơn, hãy khám phá khả năng lập luận của Claude Sonnet 4 hoặc áp dụng thực tiễn LLMOps cho triển khai sản xuất.

Bexruz (Bex) Tuychiev

Tác giả

Bexruz (Bex) Tuychiev

Tôi là người sáng tạo nội dung về khoa học dữ liệu với hơn 2 năm kinh nghiệm và là một trong những tài khoản có lượng người theo dõi lớn nhất trên Medium. Tôi thích viết các bài chuyên sâu về AI và ML với chút giọng điệu mỉa mai, vì bạn cũng phải làm gì đó để chúng bớt khô khan. Tôi đã xuất bản hơn 130 bài viết và một khóa học trên DataCamp, cùng với một khóa nữa đang được thực hiện. Nội dung của tôi đã được hơn 5 triệu lượt xem, trong đó 20 nghìn người đã trở thành người theo dõi trên cả Medium và LinkedIn. 

Chủ đề

Liên quan