Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

Feature Request: Multi API-Keys Load Balancing for LLM Providers

Đang mở
  • Có gì không ổn?
#445 2 bình luận 0 reaction 0 người được giao Xem trên GitHub

Chưa có ai nhận issue này.

Đánh giá

Độ khó
5/5
Thời gian dự kiến
Hơn một tuần
Mức phù hợp với người mới
20/100
Loại issue
Tính năng
Độ rõ ràng
Khá rõ ràng
Mức độ hoạt động
Đình trệ
Công nghệ
python
Lĩnh vực
api, backend-api-design

Hướng nghiên cứu

The issue does not identify files, tests, or entry points, so first locate the provider configuration and request-handling paths. Review how each provider currently loads and uses API keys, then check the existing tests and documentation. Done would mean supporting multiple keys, the stated balancing and configuration options, monitoring, backward compatibility, and comprehensive tests; the issue says implementation is already complete and a PR will follow.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

Multi API-Keys Load Balancing for LLM Providers

Is your feature request related to a problem?

Yes. For individual users on free or low-tier plans of OpenAI API/Azure/Google AI API, or enterprise users running self-hosted model service platforms, single API key usage is severely constrained by strict RPM (Requests Per Minute) and TPM (Tokens Per Minute) rate limits - typically in the single or double digits for RPM.

In our team's practical scenarios, running DeepWiki on large-scale repositories and handling subsequent RAG indexing/querying demands can easily consume over 100,000 tokens per minute. When DeepWiki is deployed as a service for development teams with 20+ concurrent users, at least 70 LLM requests per minute are required. Supporting only one API key per provider prevents cost-sensitive individual and enterprise users from deploying DeepWiki effectively.

Describe the solution you'd like

Implement a multi-API-key configuration system with intelligent load balancing algorithms to distribute model requests and token consumption across multiple API keys, thereby bypassing rate limit policies, while users don't have to rocket their spendings.

Key Features:

  1. Multiple Key Support: Allow users to configure multiple API keys per provider (e.g., OPENAI_API_KEYS=key1,key2,key3)
  2. Load Balancing Strategy:
    • Primary criterion: Least-used key (by request count)
    • Tiebreaker: Least recently used timestamp
    • Per-provider independent tracking
  3. Configuration Flexibility:
    • Environment variables with comma-separated values
    • JSON configuration file support
    • Dynamic key rotation without service restart
  4. Monitoring & Observability:
    • Real-time key usage statistics
    • Balance ratio metrics
    • Per-key performance tracking

Benefits:

  • ✅ Users can combine multiple free/low-tier keys to achieve higher effective rate limits
  • ✅ Cost remains controlled while bypassing single-key rate limit restrictions
  • ✅ Improved service reliability and availability
  • ✅ Horizontal scaling capability for enterprise deployments

Describe alternatives you've considered

Alternative 1: Request Queue with Delayed Retry

Instead of load balancing across multiple keys, implement a request queue that automatically retries failed requests after the rate limit window resets.

Implementation:

  • Maintain a FIFO queue for all LLM requests
  • When rate limit error occurs, calculate wait time based on rate limit window
  • Automatically retry requests after the wait period
  • Apply exponential backoff for subsequent failures

Why This Doesn't Work:

  • ❌ Poor User Experience: Users face significant delays (30-60 seconds per rate limit hit)
  • ❌ Unpredictable Latency: Response times become highly variable and unreliable
  • ❌ Queue Buildup: During high concurrency, queues grow exponentially, leading to request timeouts
  • ❌ Resource Waste: Server resources are tied up maintaining queue state and retry timers
  • ❌ No Scalability: Doesn't solve the fundamental throughput problem, just delays it
  • ❌ Cascade Failures: Long queues can cause cascading failures when requests timeout while waiting

Additional context

✅ Completed - This feature has been fully implemented and a PR will be submitted later:

  • Multi-key configuration via environment variables and JSON
  • Load balancing with least-used + LRU strategy
  • Real-time monitoring and statistics
  • Full backward compatibility with single-key setups
  • Comprehensive testing and documentation

Performance Metrics (from testing):

  • 10 concurrent requests distributed across 5 keys
  • Load balance ratio: 80%+ (1.0 = perfect balance)
  • Zero request failures due to rate limiting
  • Predictable, low-latency responses

Configuration Example:

# .env file
OPENAI_API_KEYS=sk-key1,sk-key2,sk-key3,sk-key4,sk-key5
GOOGLE_API_KEYS=AIza-key1,AIza-key2,AIza-key3

// api/config/api_keys.json
{
  "openai": {
    "keys": ["${OPENAI_API_KEYS}"]
  },
  "google": {
    "keys": ["${GOOGLE_API_KEYS}"]
  }
}
Ngôn ngữ chính
Python
Star
18.1k
Fork
2k
Không có pull request nào được merge trong 30 ngày

Chuẩn bị môi trường

Dự án này không cung cấp dev container, Dockerfile hay hướng dẫn đóng góp, nên bạn cần tự thiết lập môi trường: hãy bắt đầu từ README và xem hướng dẫn đóng góp lần đầu của chúng tôi để biết các bước chung.

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của AsyncFuncAI/deepwiki-open

Tất cả issue của AsyncFuncAI/deepwiki-open

Issue tương tự

Thêm issue về Python

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.