LiteLLM ਬਨਾਮ Bifrost: ਮੈਂ ਦੋਵਾਂ ਨੂੰ ਪ੍ਰੋਡਕਸ਼ਨ ਵਿੱਚ ਟੈਸਟ ਕੀਤਾ

ਮੈਂ ਦੋ ਹਫ਼ਤਿਆਂ ਲਈ LiteLLM ਅਤੇ Bifrost ਨੂੰ ਨਾਲ-ਨਾਲ ਚਲਾਇਆ।

ਮੈਂ ਇੱਕੋ ਜਿਹਾ ਟ੍ਰੈਫਿਕ, ਇੱਕੋ ਜਿਹੇ ਮਾਡਲ ਅਤੇ ਇੱਕੋ ਜਿਹੀ ਇਨਫਰਾ (infra) ਦੀ ਵਰਤੋਂ ਕੀਤੀ। ਮੈਨੂੰ ਆਪਣੀ ਟੀਮ ਲਈ ਇੱਕ ਗੇਟਵੇ ਚੁਣਨਾ ਸੀ। ਮੈਂ ਮਾਰਕੀਟਿੰਗ ਦਾਅਵਿਆਂ ਦੀ ਬਜਾਏ ਅਸਲ ਡੇਟਾ ਚਾਹੁੰਦਾ ਸੀ।

ਇੱਥੇ ਮੇਰੇ ਨਤੀਜੇ ਹਨ।

ਟੈਸਟ ਸੈੱਟਅੱਪ

ਮੈਂ 4 vCPUs ਅਤੇ 8GB RAM ਵਾਲੇ c5.xlarge instances ਦੀ ਵਰਤੋਂ ਕੀਤੀ। ਮੈਂ ਛੋਟੇ ਟੈਸਟ instances ਦੀ ਵਰਤੋਂ ਨਹੀਂ ਕੀਤੀ। ਮੈਂ ਸਾਡੇ ਏਜੰਟ ਪਲੇਟਫਾਰਮ ਤੋਂ ਪ੍ਰਤੀ ਸੈਕਿੰਡ 200 ਤੋਂ 400 ਰਿਕੁਐਸਟਾਂ ਦੀ ਦਰ ਨਾਲ ਅਸਲ ਯੂਜ਼ਰ ਰਿਕੁਐਸਟਾਂ ਦੀ ਵਰਤੋਂ ਕੀਤੀ।

ਪ੍ਰੋਵਾਈਡਰ ਕਵਰੇਜ

  • LiteLLM 100 ਤੋਂ ਵੱਧ ਪ੍ਰੋਵਾਈਡਰਾਂ ਦਾ ਸਮਰਥਨ ਕਰਦਾ ਹੈ।
  • Bifrost ਲਗਭਗ 23 ਪ੍ਰੋਵਾਈਡਰਾਂ ਦਾ ਸਮਰਥਨ ਕਰਦਾ ਹੈ।

LiteLLM ਇੱਕ ਸਧਾਰਨ config ਦੀ ਵਰਤੋਂ ਕਰਕੇ OpenAI, Anthropic, Bedrock, Vertex, Groq, ਅਤੇ Deepseek ਨੂੰ ਸੰਭਾਲਦਾ ਹੈ। Bifrost ਵਿੱਚ ਸਾਡੇ ਲੋੜੀਂਦੇ ਕੁਝ ਪ੍ਰੋਵਾਈਡਰਾਂ ਦੀ ਕਮੀ ਸੀ। ਇਸ ਕਾਰਨ ਇਹ ਸਾਡੇ ਲਈ ਇੱਕ ਵੱਡੀ ਰੁਕਾਵਟ (dealbreaker) ਬਣ ਗਿਆ।

ਪਰਫਾਰਮੈਂਸ

Bifrost ਰੌਅ ਗੇਟਵੇ ਓਵਰਹੈੱਡ (raw gateway overhead) 'ਤੇ ਤੇਜ਼ ਹੈ ਕਿਉਂਕਿ ਇਹ Go ਦੀ ਵਰਤੋਂ ਕਰਦਾ ਹੈ। ਮੈਂ ਲਗਭਗ 0.08ms ਓਵਰਹੈੱਡ ਮਾਪਿਆ। LiteLLM ਦੇ Python proxy ਨੇ ਪ੍ਰਤੀ ਰਿਕੁਐਸਟ ਲਗਭਗ 7ms ਤੋਂ 8ms ਜੋੜ ਦਿੱਤੇ।

ਹਾਲਾਂਕਿ, ਇੱਕ LLM ਕਾਲ ਵਿੱਚ 500ms ਤੋਂ 30 ਸੈਕਿੰਡ ਲੱਗਦੇ ਹਨ। ਮਾਡਲ ਰਿਸਪਾਂਸ ਸਮੇਂ ਦੇ ਮੁਕਾਬਲੇ 7ms ਦੀ ਦੇਰੀ ਲਗਭਗ ਅਣਡਿੱਠੀ ਹੁੰਦੀ ਹੈ।

ਇਸ ਤੋਂ ਇਲਾਵਾ, LiteLLM ਨੇ ਹੁਣੇ ਹੀ ਇੱਕ Rust-ਅਧਾਰਤ ਗੇਟਵੇ ਰਿਲੀਜ਼ ਕੀਤਾ ਹੈ। ਇਹ ਓਵਰਹੈੱਡ ਨੂੰ ਘਟਾ ਕੇ 0.05ms ਕਰ ਦਿੰਦਾ ਹੈ। ਇਹ ਪਰਫਾਰਮੈਂਸ ਦੇ ਪਾੜੇ ਨੂੰ ਖਤਮ ਕਰਦਾ ਹੈ।

ਖਰਚੇ ਦੀ ਟ੍ਰੈਕਿੰਗ

ਇੱਥੇ LiteLLM ਜਿੱਤਦਾ ਹੈ। ਇਹ ਹਰ ਕੀ (key) ਅਤੇ ਹਰ ਟੀਮ ਵਿੱਚ ਖਰਚੇ ਨੂੰ ਆਪਣੇ ਆਪ ਟ੍ਰੈਕ ਕਰਦਾ ਹੈ।

  • ਤੁਹਾਨੂੰ ਪ੍ਰਤੀ-ਕੀ (per-key) ਬਜਟ ਮਿਲਦਾ ਹੈ।
  • ਤੁਹਾਨੂੰ ਪ੍ਰਤੀ-ਟੀਮ (per-team) ਬਜਟ ਮਿਲਦਾ ਹੈ।
  • ਤੁਹਾਨੂੰ ਰੋਜ਼ਾਨਾ ਖਰਚੇ ਦੀਆਂ ਰਿਪੋਰਟਾਂ ਮਿਲਦੀਆਂ ਹਨ।

Bifrost ਵਿੱਚ ਬਜਟ ਦੀਆਂ ਸੀਮਾਵਾਂ ਹਨ, ਪਰ LiteLLM ਡੂੰਘੀ ਲਾਗਤ ਐਟਰੀਬਿਊਸ਼ਨ (cost attribution) ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ। ਜਦੋਂ ਤੁਸੀਂ ਮਹੀਨੇ ਵਿੱਚ 10 ਮਿਲੀਅਨ ਕਾਲਾਂ ਚਲਾਉਂਦੇ ਹੋ, ਤਾਂ ਤੁਹਾਡਾ CTO ਬਿਲਕੁਲ ਇਹੀ ਪੁੱਛੇਗਾ ਕਿ ਹਰੇਕ ਟੀਮ ਨੇ ਹਰੇਕ ਮਾਡਲ 'ਤੇ ਕਿੰਨਾ ਖਰਚ ਕੀਤਾ। LiteLLM ਤੁਹਾਨੂੰ ਉਹ ਜਵਾਬ ਤੁਰੰਤ ਦੇ ਦਿੰਦਾ ਹੈ।

ਰੂਟਿੰਗ ਰਣਨੀਤੀਆਂ

LiteLLM ਪੰਜ ਰੂਟਿੰਗ ਰਣਨੀਤੀਆਂ ਪੇਸ਼ ਕਰਦਾ ਹੈ:

  • Simple shuffle
  • Least busy
  • Latency-based
  • Cost-based
  • Usage-based

Bifrost ਵਿੱਚ weighted ਅਤੇ adaptive ਰੂਟਿੰਗ ਹੈ, ਪਰ ਇਸ ਵਿੱਚ cost-based ਰੂਟਿੰਗ ਦੀ ਕਮੀ ਹੈ। LiteLLM ਕਿਸੇ ਰਿਕੁਐਸਟ ਲਈ ਆਪਣੇ ਆਪ ਸਭ ਤੋਂ ਸਸਤਾ ਮਾਡਲ ਚੁਣ ਸਕਦਾ ਹੈ।

ਫੈਸਲਾ

ਮੈਂ LiteLL