LLM ಗೇಟ್‌ವೇ ಹೇಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ? ಎಂಜಿನಿಯರಿಂಗ್ ತಂಡಗಳಿಗಾಗಿ ಒಂದು ಪ್ರಾಯೋಗಿಕ ಮಾರ್ಗದರ್ಶಿ

LLM ಗೇಟ್‌ವೇ ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್‌ಗಳು ಮತ್ತು ಅದರ ಮೂಲಕ ನೀವು ಸಂಪರ್ಕಿಸುವ ಮಾಡೆಲ್ ಪೂರೈಕೆದಾರರ ನಡುವೆ ಇರುತ್ತದೆ, ಕ್ರೆಡೆನ್ಶಿಯಲ್‌ಗಳನ್ನು ನಿರ್ವಹಿಸಲು ಮತ್ತು ಬಳಕೆಯನ್ನು ಟ್ರ್ಯಾಕ್ ಮಾಡಲು ನಿಮಗೆ ಒಂದೇ ಸ್ಥಳವನ್ನು ಒದಗಿಸುತ್ತದೆ.

“ಸದ್ಯಕ್ಕಂತೂ ಇದೊಂದು ಹೊಲಸು ಗೊಂದಲ,” ಎಂದು ಒಬ್ಬ ಎಂಜಿನಿಯರ್ ಸೆಪ್ಟೆಂಬರ್ 2026 ರಲ್ಲಿ Redditನ r/LLMDevsನಲ್ಲಿ ಬರೆದಿದ್ದಾರೆ.

“ಪ್ರತಿಯೊಬ್ಬರ ಬಳಿಯೂ Claude, OpenAI, AWS Bedrock ಮತ್ತು ನಾವು ಬಳಸುವ ಇತರ ಎಲ್ಲಾ ಇನ್ಫರೆನ್ಸ್ ಪೂರೈಕೆದಾರರಿಗಾಗಿ ತಮ್ಮದೇ ಆದ ಕೀಗಳ ಸೆಟ್ ಇದೆ.”

llm-proxy-tk ಕುರಿತ BigGoನ ವರದಿಯು ಈ ಹಗುರವಾದ FastAPI ಗೇಟ್‌ವೇಯ ವ್ಯವಸ್ಥೆಯನ್ನು LLMಗಳನ್ನು “ಕಾರ್ಪೊರೇಟ್ ನಲ್ಲಿಯ ನೀರು” ಆಗಿ ಪರಿವರ್ತಿಸುವುದಕ್ಕೆ ಹೋಲಿಸುತ್ತದೆ, ಇದರಲ್ಲಿ ಗೇಟ್‌ವೇ ಕಟ್ಟಡದ ಮುಖ್ಯ ಕವಾಟದಂತೆ ಕೆಲಸ ಮಾಡುತ್ತದೆ.

ಆದರೆ ಈ ಕೊಳಾಯಿ ವ್ಯವಸ್ಥೆಯ ಮೇಲೆ ಅಷ್ಟೊಂದು ನಂಬಿಕೆ ಇಡುವ ಮೊದಲು, ನೀವು ಏನನ್ನು ಅಳವಡಿಸುತ್ತಿದ್ದೀರಿ ಎಂಬುದನ್ನು ನೋಡೋಣ.

LLM ಗೇಟ್‌ವೇ ಎಂದರೇನು?

LLM ಗೇಟ್‌ವೇ ಎಂದರೆ ಮಾಡೆಲ್ ಕರೆಗಳಿಗಾಗಿ ಇರುವ ರಿವರ್ಸ್ ಪ್ರಾಕ್ಸಿ. ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್‌ಗಳು ವಿನಂತಿಗಳನ್ನು ನೇರವಾಗಿ OpenAI, Anthropic, Google ಅಥವಾ ನೀವು ಬಳಸುವ ಯಾವುದೇ LLM ಪೂರೈಕೆದಾರರಿಗೆ ಕಳುಹಿಸುವ ಬದಲು ಅದಕ್ಕೆ ಕಳುಹಿಸುತ್ತವೆ. ಗೇಟ್‌ವೇ ಆ ವಿನಂತಿಗಳನ್ನು ಮುಂದಕ್ಕೆ ರವಾನಿಸುತ್ತದೆ, ಹಾಗೆ ಹಾದುಹೋಗುವಾಗ ನಿಮ್ಮ ನಿಯಮಗಳನ್ನು ಅನ್ವಯಿಸುತ್ತದೆ.

ಪ್ರತಿಯೊಂದು LLM ಪೂರೈಕೆದಾರರಿಗೂ ಒಂದು API ಇದೆ: ಅದಕ್ಕೆ ತನ್ನದೇ ಆದ ವಿನಂತಿ ಸ್ವರೂಪ, ತನ್ನದೇ ಆದ ದೃಢೀಕರಣ ಮತ್ತು ದೋಷಗಳನ್ನು ಹಿಂದಿರುಗಿಸುವ ತನ್ನದೇ ಆದ ವಿಧಾನವಿದೆ. ಪ್ರತಿಯೊಂದಕ್ಕೂ ಪ್ರತ್ಯೇಕ ರೇಟ್ ಮಿತಿಗಳು ಮತ್ತು ವೈಫಲ್ಯದ ಸ್ವರೂಪಗಳಿವೆ. ಈಗ, ಅವುಗಳ ಮುಂದೆ ಹಂಚಿಕೆಯ ಪದರವೊಂದು ಇಲ್ಲದಿದ್ದರೆ, ಪೂರೈಕೆದಾರರನ್ನು ಕರೆಯುವ ಪ್ರತಿಯೊಂದು ಅಪ್ಲಿಕೇಶನ್ ಎಲ್ಲವನ್ನೂ ತಾನೇ ಮಾಡುತ್ತದೆ, ಮತ್ತು ಸ್ವಲ್ಪ ಬೇರೆ ರೀತಿಯಲ್ಲಿ ಮಾಡುತ್ತದೆ.

ನಲ್ಲಿ ನೀರಿನ ಹೋಲಿಕೆ ಒಂದು ಮಟ್ಟಿಗೆ ಮಾತ್ರ ಸರಿಹೊಂದುತ್ತದೆ, ಆದರೆ ಇಷ್ಟರಮಟ್ಟಿಗೆ ಅದು ಸರಿ—ಪೂರೈಕೆದಾರರನ್ನು ಒಮ್ಮೆ ಮಾತ್ರ, ಗೇಟ್‌ವೇಯಲ್ಲಿ, ಸಂಪರ್ಕಿಸಲಾಗುತ್ತದೆ. ಅಲ್ಲಿಂದ ಮುಂದೆ, ಪ್ರತಿಯೊಂದು ಅಪ್ಲಿಕೇಶನ್‌ಗೆ ತನ್ನದೇ ಆದ ಮೀಟರ್ ಮಾಡಲಾದ ಸಂಪರ್ಕ ಸಿಗುತ್ತದೆ, ಆದ್ದರಿಂದ ಯಾರು ಏನನ್ನು ಬಳಸುತ್ತಿದ್ದಾರೆ ಎಂಬುದನ್ನು ನೀವು ನೋಡಬಹುದು ಮತ್ತು ಇತರ ಸಂಪರ್ಕಗಳನ್ನು ಮುಟ್ಟದೆಯೇ ಯಾವುದೇ ಒಂದು ಲೈನ್ ಅನ್ನು ಸ್ಥಗಿತಗೊಳಿಸಬಹುದು.

LLM, AI, MCP ಮತ್ತು API ಗೇಟ್‌ವೇಗಳು: ವ್ಯತ್ಯಾಸವೇನು?

LLM ಗೇಟ್‌ವೇ ಹೇಗೆ ಕೆಲಸ ಮಾಡುತ್ತದೆ?

ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್‌ನಿಂದ ಮಾಡೆಲ್‌ಗೆ ಹೋಗಿ ಹಿಂತಿರುಗುವ ಒಂದು ವಿನಂತಿಯನ್ನು ಅನುಸರಿಸಿ ನೋಡಿ.

1. ವಿನಂತಿ ಗೇಟ್‌ವೇಯನ್ನು ತಲುಪುತ್ತದೆ: ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್ ಸಾಮಾನ್ಯವಾಗಿ ಕಾಣುವ ಚಾಟ್ ವಿನಂತಿಯನ್ನು, ಹೆಚ್ಚಾಗಿ OpenAI-ಹೊಂದಾಣಿಕೆಯ ಸ್ವರೂಪದಲ್ಲಿ, ಗೇಟ್‌ವೇಯ ಎಂಡ್‌ಪಾಯಿಂಟ್‌ಗೆ ಕಳುಹಿಸುತ್ತದೆ. ಅಪ್ಲಿಕೇಶನ್‌ನ ದೃಷ್ಟಿಯಿಂದ, ಮಾಡೆಲ್ ಅನ್ನು ತಲುಪಲು ಅದು ಕರೆಯುವ ವಿಳಾಸ ಇದೇ.
2. ಯಾರು ಕೇಳುತ್ತಿದ್ದಾರೆ ಮತ್ತು ಅವರಿಗೆ ಏನು ಮಾಡಲು ಅನುಮತಿ ಇದೆ ಎಂಬುದನ್ನು ಗೇಟ್‌ವೇ ಪರಿಶೀಲಿಸುತ್ತದೆ: ವಿನಂತಿಯನ್ನು ಮುಂದಕ್ಕೆ ಕಳುಹಿಸುವ ಮೊದಲು, ಅದು ಕ್ರೆಡೆನ್ಶಿಯಲ್‌ಗಳನ್ನು ಮೌಲ್ಯೀಕರಿಸುತ್ತದೆ. ಹೆಚ್ಚಾಗಿ, ಅದು ಒಂದು ತಂಡಕ್ಕೆ ಅಥವಾ ಉತ್ಪನ್ನಕ್ಕೆ ನೀಡಲಾದ ವರ್ಚುವಲ್ ಕೀ ಆಗಿರುತ್ತದೆ. ನೀವು ಇನ್‌ಪುಟ್ ಗಾರ್ಡ್‌ರೈಲ್‌ಗಳನ್ನು ಅಳವಡಿಸಿದ್ದರೆ, ಸೂಕ್ಷ್ಮ ಡೇಟಾ ಅಥವಾ ಮಾಡೆಲ್‌ನ ಸೂಚನೆಗಳನ್ನು ಅತಿಕ್ರಮಿಸುವ ಪ್ರಯತ್ನಗಳಿಗಾಗಿ ಪ್ರಾಂಪ್ಟ್‌ಗಳನ್ನು ಸ್ಕ್ಯಾನ್ ಮಾಡಲೂ ಸಾಧ್ಯ.
3. ತನ್ನ ಬಳಿ ಈಗಾಗಲೇ ಉತ್ತರವಿದೆಯೇ ಎಂದು ಗೇಟ್‌ವೇ ಪರಿಶೀಲಿಸುತ್ತದೆ: ಕ್ಯಾಶಿಂಗ್ ಸಕ್ರಿಯಗೊಂಡಿದ್ದರೆ, ಅರ್ಹವಾದ ಹೊಂದಾಣಿಕೆಯ ವಿನಂತಿಗೆ ಮತ್ತೊಂದು ಪೂರೈಕೆದಾರ ಕರೆ ಇಲ್ಲದೆಯೇ ಉಳಿಸಿದ ಪ್ರತಿಕ್ರಿಯೆಯಿಂದ ಉತ್ತರಿಸಬಹುದು. ಕೆಲವು ಗೇಟ್‌ವೇಗಳು ಸೆಮ್ಯಾಂಟಿಕ್ ಕ್ಯಾಶಿಂಗ್ ಅನ್ನು ಸಹ ನೀಡುತ್ತವೆ, ಇದು ಸಂಪೂರ್ಣವಾಗಿ ಒಂದೇ ಆಗಿರುವ ವಿನಂತಿಗಳ ಬದಲು ಸಾಕಷ್ಟು ಹೋಲುತ್ತವೆ ಎಂದು ಪರಿಗಣಿಸಲಾದ ವಿನಂತಿಗಳನ್ನು ಹುಡುಕುತ್ತದೆ. ಇದು FAQ ಮಾದರಿಯ ಟ್ರಾಫಿಕ್‌ಗೆ ಸೂಕ್ತವಾಗಬಹುದು.
4. ವಿನಂತಿ ಎಲ್ಲಿಗೆ ಹೋಗಬೇಕು ಎಂಬುದನ್ನು ಗೇಟ್‌ವೇ ಆಯ್ಕೆ ಮಾಡುತ್ತದೆ: ವಿನಂತಿಯು ನಿರ್ದಿಷ್ಟ ಮಾಡೆಲ್ ಅಥವಾ ಅಲಿಯಾಸ್ ಅನ್ನು ಹೆಸರಿಸಬಹುದು. ಗೇಟ್‌ವೇ ನಿಮ್ಮ ಕಾನ್ಫಿಗರೇಶನ್‌ನಲ್ಲಿ ಹೊಂದಾಣಿಕೆಯಾಗುವ ರೂಟ್ ಅನ್ನು ಹುಡುಕುತ್ತದೆ. ನೀವು ಬ್ಯಾಕಪ್ ರೂಟ್ ಅನ್ನು ಸಹ ಕಾನ್ಫಿಗರ್ ಮಾಡಬಹುದು. ಪೂರೈಕೆದಾರ A ಟೈಮ್ ಔಟ್ ಆದರೆ, ಗೇಟ್‌ವೇ ಪೂರೈಕೆದಾರ B ಅನ್ನು ಪ್ರಯತ್ನಿಸಬಹುದು.
5. ಗೇಟ್‌ವೇ ಕರೆಯನ್ನು ಸಿದ್ಧಪಡಿಸಿ ಪ್ರತಿಕ್ರಿಯೆಯನ್ನು ಹಿಂತಿರುಗಿಸುತ್ತದೆ: ಗೇಟ್‌ವೇ ನಿಮ್ಮ ವಿನಂತಿಯನ್ನು ಆಯ್ಕೆ ಮಾಡಿದ ಪೂರೈಕೆದಾರರ ಸ್ವರೂಪಕ್ಕೆ ಪರಿವರ್ತಿಸುತ್ತದೆ ಮತ್ತು ಹೊರಹೋಗುವ ಕರೆಯನ್ನು ದೃಢೀಕರಿಸುತ್ತದೆ. ಪ್ರತಿಕ್ರಿಯೆ ಬಂದ ತಕ್ಷಣ, ಅದನ್ನು ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್‌ಗೆ ಅಗತ್ಯವಿರುವ ಸ್ವರೂಪಕ್ಕೆ ಪರಿವರ್ತಿಸಲಾಗುತ್ತದೆ.
6. ಏನಾಯಿತು ಎಂಬುದನ್ನು ಗೇಟ್‌ವೇ ದಾಖಲಿಸುತ್ತದೆ: ಲಾಗಿಂಗ್ ಸಕ್ರಿಯಗೊಂಡಿದ್ದಾಗ, ಕರೆ ಮಾಡಿದವರು ಯಾರು, ಯಾವ ಮಾಡೆಲ್ ಅದನ್ನು ಪೂರೈಸಿತು, ಟೋಕನ್ ಎಣಿಕೆಗಳು, ಲೇಟೆನ್ಸಿ ಮತ್ತು ವೆಚ್ಚ ಸೇರಿದಂತೆ ವಿವರಗಳನ್ನು ಗೇಟ್‌ವೇ ದಾಖಲಿಸುತ್ತದೆ. ಪರಿಚಯದಲ್ಲಿ ಉಲ್ಲೇಖಿಸಿದ Reddit ಎಂಜಿನಿಯರ್ ಬಳಿ ಇಲ್ಲದಿದ್ದ ಲಾಗ್ ಇದೇ.

ಗೇಟ್‌ವೇಯನ್ನು ಪ್ರೊಡಕ್ಷನ್‌ಗೆ ತರುವ ಮೊದಲು ನೀವು ತಿಳಿದುಕೊಳ್ಳಬೇಕಾದ 4 ವಿಷಯಗಳು

ಮೇಲಿನ ವಿಭಾಗದಲ್ಲಿರುವ ಎಲ್ಲವೂ ಸಾಧ್ಯವಾಗುವುದು ಗೇಟ್‌ವೇ ತನ್ನ ಮೂಲಕ ರೂಟ್ ಆಗುವ ಪ್ರತಿಯೊಂದು ವಿನಂತಿಯನ್ನು ನೋಡುವುದರಿಂದ. ಇದರ ಮುಖ್ಯ ಆಕರ್ಷಣೆಯೇ ಅದು. ಆದರೆ ನೀವು ಯೋಜಿಸಬೇಕಾದ ದಾಳಿಯ ಮೇಲ್ಮೈ (attack surface) ಮತ್ತು ವೆಂಡರ್ ಅವಲಂಬನೆಯ ವಿವರಣೆಯೂ ಇದೇ ಆಗಿದೆ.

ಗೇಟ್‌ವೇ ಈಗ ನಿಮ್ಮ AI ಸ್ಟ್ಯಾಕ್‌ನಲ್ಲಿನ ಅತ್ಯಂತ ಮೌಲ್ಯಯುತ ಘಟಕ

ಗೇಟ್‌ವೇ ಪ್ರವೇಶವನ್ನು ಕೇಂದ್ರೀಕರಿಸುತ್ತದೆ. ಆದ್ದರಿಂದ, ಅದು ಸಾಕಷ್ಟು ಕ್ರೆಡೆನ್ಶಿಯಲ್‌ಗಳನ್ನು ಒಂದೇ ಸೇವೆಯ ಕೈಗೆಟುಕುವಂತೆಯೂ ಮಾಡುತ್ತದೆ. LiteLLM ನಿಯೋಜನೆಯು ಏನನ್ನು ಹೊಂದಿರಬಹುದು ಅಥವಾ ಹಿಂಪಡೆಯಬಹುದು ಎಂಬುದನ್ನು Microsoftನ ಭದ್ರತಾ ತಂಡ ಪಟ್ಟಿ ಮಾಡುತ್ತದೆ: ಪೂರೈಕೆದಾರ API ಕೀಗಳು, ಅದರದೇ ಮಾಸ್ಟರ್ ಕೀ, ವರ್ಚುವಲ್-ಕೀ ದಾಖಲೆಗಳು, ಡೇಟಾಬೇಸ್ ಕನೆಕ್ಷನ್ ಸ್ಟ್ರಿಂಗ್‌ಗಳು, ರೂಟಿಂಗ್ ಸೆಟ್ಟಿಂಗ್‌ಗಳು ಮತ್ತು ಟೆನೆಂಟ್ ನೀತಿಗಳು.

ಅಕ್ಟೋಬರ್ 2026 ರಲ್ಲಿ, LiteLLMನಲ್ಲಿನ ಎರಡು ಹೆಚ್ಚು ಅಪಾಯಕಾರಿ ದುರ್ಬಲತೆಗಳನ್ನು Check Point Research ಬಹಿರಂಗಪಡಿಸಿತು:

• CVE-2026-35029, ಓದಲು-ಮಾತ್ರ ಅನುಮತಿ ಹೊಂದಿರುವವರೂ ಸೇರಿದಂತೆ ದೃಢೀಕೃತ ಬಳಕೆದಾರರಿಗೆ ಆಡಳಿತಾತ್ಮಕ ಕಾರ್ಯಗಳನ್ನು ತಲುಪಲು ಮತ್ತು ಇನ್‌ಸ್ಟೆನ್ಸ್ ಅನ್ನು ತಮ್ಮ ನಿಯಂತ್ರಣಕ್ಕೆ ತೆಗೆದುಕೊಳ್ಳಲು ಅವಕಾಶ ನೀಡಿತು.
• CVE-2026-59823, ಬಳಕೆದಾರರಿಗೆ ತಾವು ನಿಯಂತ್ರಿಸುವ ಸರ್ವರ್‌ಗೆ ವಿನಂತಿಗಳನ್ನು ಮರುನಿರ್ದೇಶಿಸಲು ಮತ್ತು ಪೂರೈಕೆದಾರ ಕೀಗಳನ್ನು ಸೆರೆಹಿಡಿಯಲು ಅವಕಾಶ ನೀಡಿತು.

ಎರಡನ್ನೂ ಆವೃತ್ತಿ 1.83.9 ರಲ್ಲಿ ಸರಿಪಡಿಸಲಾಯಿತು. ಗೇಟ್‌ವೇಯನ್ನು ಬಳಸುವ ಅಪ್ಲಿಕೇಶನ್‌ಗೆ ಅದರ ಸೆಟ್ಟಿಂಗ್‌ಗಳನ್ನು ಬದಲಾಯಿಸಲು ಸಾಧ್ಯವಾಗಬಾರದು.

ನಿಮ್ಮ ಗಾರ್ಡ್‌ರೈಲ್‌ಗಳಿಗೆ ವೈಫಲ್ಯ ನೀತಿಯೊಂದು ಬೇಕು

Pillar Securityಯ ಅಕ್ಟೋಬರ್ 4, 2026 ರ ವಿಮರ್ಶೆಯು LiteLLM, Kong, TrueFoundry, Portkey, Azure API Management ಮತ್ತು Apigee ಸೇರಿದಂತೆ ಪ್ರಮುಖ ಗೇಟ್‌ವೇಗಳಲ್ಲಿನ ಮೂರನೇ ವ್ಯಕ್ತಿಯ ಗಾರ್ಡ್‌ರೈಲ್ ಇಂಟಿಗ್ರೇಶನ್‌ಗಳನ್ನು ದಾಖಲಿಸುತ್ತದೆ. (Pillar ಗಾರ್ಡ್‌ರೈಲ್‌ಗಳನ್ನು ಮಾರಾಟ ಮಾಡುತ್ತದೆ, ಆದ್ದರಿಂದ ಅದರ ಶಿಫಾರಸುಗಳನ್ನು ಓದುವಾಗ ಇದನ್ನು ಗಮನದಲ್ಲಿಡಿ.)

ಹುಕ್ ಎಂದರೆ ವಿನಂತಿಯ ಮಾರ್ಗದಲ್ಲಿನ ಒಂದು ಹಂತ—ಸಾಮಾನ್ಯವಾಗಿ ಪ್ರಾಂಪ್ಟ್ ಮಾಡೆಲ್‌ಗೆ ಹೋಗುವ ಮೊದಲು ಅಥವಾ ಪ್ರತಿಕ್ರಿಯೆ ಹಿಂತಿರುಗಿದ ನಂತರ—ಇಲ್ಲಿ ಗೇಟ್‌ವೇ ತೀರ್ಪಿಗಾಗಿ ವಿಷಯವನ್ನು ಬಾಹ್ಯ ಸ್ಕ್ಯಾನರ್‌ಗೆ ಹಸ್ತಾಂತರಿಸಬಹುದು. ಬ್ಲಾಕಿಂಗ್ ಪರಿಶೀಲನೆಯು ಟ್ರಾಫಿಕ್ ಮುಂದುವರಿಯಲು ಬಿಡುವ ಮೊದಲು ಆ ತೀರ್ಪಿಗಾಗಿ ಕಾಯುತ್ತದೆ. Portkeyಯ ಡಾಕ್ಯುಮೆಂಟೇಶನ್ ಇವುಗಳನ್ನು before_request_hooks ಮತ್ತು after_request_hooks ಎಂದು ಕರೆಯುತ್ತದೆ; TrueFoundry ನಾಲ್ಕು ಹುಕ್‌ಗಳನ್ನು ಚಲಾಯಿಸುತ್ತದೆ, MCP ಟೂಲ್ ಕರೆಗಳ ಮೊದಲು ಮತ್ತು ನಂತರದ ಪರಿಶೀಲನೆಗಳನ್ನು ಸೇರಿಸುತ್ತದೆ.

ಈಗ, ಪರಿಶೀಲಿಸಬೇಕಾದ ಎರಡು ವಿಷಯಗಳು:

• ಸ್ಕ್ಯಾನರ್ ತಾನೇ ವಿಫಲವಾದರೆ ಏನಾಗುತ್ತದೆ? ನೀವು ವಿನಂತಿಯನ್ನು ನಿರ್ಬಂಧಿಸಿದರೆ, ಪರಿಶೀಲಿಸದ ಟ್ರಾಫಿಕ್ ಅನ್ನು ತಡೆಯುತ್ತೀರಿ, ಆದರೆ ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್‌ಗೆ ಅಡ್ಡಿಯಾಗಬಹುದು. ಅದನ್ನು ಹಾದುಹೋಗಲು ಬಿಟ್ಟರೆ, ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್ ಆ ಪರಿಶೀಲನೆ ಇಲ್ಲದೆಯೇ ಮುಂದುವರಿಯಬಹುದು. ಪರಿಶೀಲನೆ ನಡೆದಿರಲಿಲ್ಲ ಎಂಬುದನ್ನು ವೈಫಲ್ಯದ ಲಾಗ್ ನಂತರ ನಿಮಗೆ ತೋರಿಸುತ್ತದೆ; ಇದು ಉಪಯುಕ್ತ, ಆದರೆ ಪರಿಶೀಲನೆಯನ್ನು ನಿಜವಾಗಿ ನಡೆಸಿದ್ದಕ್ಕೆ ಸಮನಲ್ಲ.
• ನೀವು ಸ್ಕ್ಯಾನರ್ ಅನ್ನು ಬದಲಾಯಿಸಬಹುದೇ? ಮತ್ತೊಂದು ಪೂರೈಕೆದಾರರಿಗೆ ಬೆಂಬಲವಿಲ್ಲದಿದ್ದರೆ, ಅದನ್ನು ಸಂಪರ್ಕಿಸಲು ನೀವು ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ಅಪ್‌ಡೇಟ್ ಮಾಡಬೇಕಾಗಬಹುದು ಅಥವಾ ಮತ್ತೊಂದು ಪ್ರಾಕ್ಸಿಯನ್ನು ಬಳಸಬೇಕಾಗಬಹುದು.

TrueFoundryಯ MCP ಹುಕ್‌ಗಳು ಗೇಟ್‌ವೇಯ ವ್ಯಾಪ್ತಿಯನ್ನು ಮಾಡೆಲ್ ವಿನಂತಿಗಳಿಂದ ಟೂಲ್ ಕರೆಗಳವರೆಗೆ ವಿಸ್ತರಿಸುತ್ತವೆ. ಆದರೆ ಅದು ತನ್ನ ಮೂಲಕ ಹಾದುಹೋಗುವ ಟ್ರಾಫಿಕ್ ಅನ್ನು ಮಾತ್ರ ಪರಿಶೀಲಿಸಬಲ್ಲದು. ಡೆವಲಪರ್‌ನ ಕಂಪ್ಯೂಟರ್‌ನಲ್ಲಿ ಕಮಾಂಡ್ ಚಲಾಯಿಸುವ ಕೋಡಿಂಗ್ ಏಜೆಂಟ್ ಆ ಗೋಚರತೆಯ ಹೊರಗೆ ಇರಬಹುದು.

Perplexityಯ ಓಪನ್-ಸೋರ್ಸ್ Numbat ಆ ಭಾಗದಲ್ಲಿ ಕೆಲಸ ಮಾಡುತ್ತದೆ. Numbat ಸ್ಥಳೀಯ ಹುಕ್‌ಗಳ ಮೂಲಕ ಬೆಂಬಲಿತ ಏಜೆಂಟ್‌ಗಳಿಗೆ ಸಂಪರ್ಕಿಸುತ್ತದೆ ಮತ್ತು ಶೆಲ್ ಕಮಾಂಡ್‌ಗಳನ್ನು ಚಲಾಯಿಸುವುದು ಅಥವಾ ಫೈಲ್‌ಗಳಿಗೆ ಬರೆಯುವುದು ಮುಂತಾದ ಯೋಜಿತ ಕ್ರಿಯೆಗಳನ್ನು ಅವು ಕಾರ್ಯಗತಗೊಳ್ಳುವ ಮೊದಲೇ ಪರಿಶೀಲಿಸಬಲ್ಲದು. ನಿರ್ಬಂಧಿಸುವ ವೈಶಿಷ್ಟ್ಯವು ಐಚ್ಛಿಕವಾಗಿದ್ದು, ಡೀಫಾಲ್ಟ್ ಆಗಿ ಆಫ್ ಆಗಿರುತ್ತದೆ. ಗೇಟ್‌ವೇ ತನ್ನ ಮೂಲಕ ರೂಟ್ ಆಗುವ ಮಾಡೆಲ್ ಟ್ರಾಫಿಕ್ ಅನ್ನು ನೋಡುತ್ತದೆ. ಏಜೆಂಟ್ ಉತ್ತರದೊಂದಿಗೆ ಏನು ಮಾಡುತ್ತದೆ ಎಂಬುದರ ಗೋಚರತೆಯನ್ನು Numbat ಸೇರಿಸುತ್ತದೆ.

ಗೇಟ್‌ವೇಯ ನಿಯಂತ್ರಣ ಎಲ್ಲಿ ಕೊನೆಗೊಳ್ಳುತ್ತದೆ ಎಂಬುದನ್ನು ನೀವು ತಿಳಿದಿರಬೇಕು

Forkast News, ವಿಭಿನ್ನ ದಿಕ್ಕುಗಳಿಂದ ಗೇಟ್‌ವೇಯತ್ತ ಸಾಗುತ್ತಿರುವ ಮೂರು ಪರಂಪರೆಗಳನ್ನು ಗುರುತಿಸುತ್ತದೆ:

• LLM-ಕೇಂದ್ರಿತ ಗೇಟ್‌ವೇಗಳು: LiteLLM ಮತ್ತು Portkey ಮಾಡೆಲ್ ಕರೆಗಳೊಂದಿಗೆ ಆರಂಭವಾದವು; ಪೂರೈಕೆದಾರರ ನಡುವೆ ಅನುವಾದಿಸುವುದು, ವಿನಂತಿಗಳನ್ನು ರೂಟ್ ಮಾಡುವುದು ಮತ್ತು ಟೋಕನ್‌ಗಳನ್ನು ಟ್ರ್ಯಾಕ್ ಮಾಡುವುದು. ಅವು ಈಗ ಟೂಲ್ ಕರೆಗಳಿಗೆ ನಿಯಂತ್ರಣಗಳನ್ನು ಸೇರಿಸುತ್ತಿವೆ.
• API ನಿರ್ವಹಣಾ ಪ್ಲಾಟ್‌ಫಾರ್ಮ್‌ಗಳು: Kong, Googleನ Apigee ಮತ್ತು Azure API Management ದೃಢೀಕರಣ, ಅನುಮತಿಗಳು ಮತ್ತು ಟ್ರಾಫಿಕ್ ನಿರ್ವಹಣೆಯೊಂದಿಗೆ ಆರಂಭವಾದವು, ನಂತರ ಮಾಡೆಲ್‌ಗಳಿಗೆ ಬೆಂಬಲ ಮತ್ತು AI-ನಿರ್ದಿಷ್ಟ ನಿಯಮಗಳನ್ನು ಸೇರಿಸಿದವು.
• ಏಜೆಂಟ್-ನೇಟಿವ್ ಮೂಲಸೌಕರ್ಯ: ಉದಾಹರಣೆಗೆ, agentgateway ಅನ್ನು MCP ಮತ್ತು A2A ಮೂಲಕವೂ ಸೇರಿದಂತೆ, ಏಜೆಂಟ್‌ಗಳು ಮಾಡೆಲ್‌ಗಳು, ಟೂಲ್‌ಗಳು ಮತ್ತು ಇತರ ಏಜೆಂಟ್‌ಗಳೊಂದಿಗೆ ಸಂವಹನ ನಡೆಸುವುದನ್ನು ಕೇಂದ್ರವಾಗಿಟ್ಟುಕೊಂಡು ನಿರ್ಮಿಸಲಾಗಿದೆ.

ಆಯ್ಕೆಯನ್ನು ನಿರ್ಧರಿಸುವ ಪ್ರಶ್ನೆಯೆಂದರೆ, ನೀವು ಏನನ್ನು ರೂಟ್ ಮಾಡುತ್ತಿದ್ದೀರಿ ಎಂಬುದು:

• ಕೇವಲ ಮಾಡೆಲ್ ಕರೆಗಳೇ? LLM-ಕೇಂದ್ರಿತ ಗೇಟ್‌ವೇ ಉತ್ತಮ ಆರಂಭಿಕ ಆಯ್ಕೆ.
• ಈಗಾಗಲೇ API ನಿಯಮಗಳಿಂದ ತುಂಬಿರುವ ಎಂಟರ್‌ಪ್ರೈಸ್‌ನೊಳಗೆ ಮಾಡೆಲ್ ಕರೆಗಳೇ? ನಿಮ್ಮ ಬಳಿ ಇರುವ ಪ್ಲಾಟ್‌ಫಾರ್ಮ್‌ನಿಂದಲೇ ಆರಂಭಿಸಿ.
• ಏಜೆಂಟ್‌ಗಳು ಟೂಲ್‌ಗಳನ್ನು ಕರೆದು, ಆ ಟೂಲ್‌ಗಳು ಮಾಡೆಲ್‌ಗಳನ್ನು ಕರೆಯುತ್ತವೆಯೇ? ಆ ಸಂಪರ್ಕಗಳೂ ವ್ಯಾಪ್ತಿಗೆ ಒಳಪಟ್ಟಿವೆಯೇ ಎಂಬುದನ್ನು ಪರಿಶೀಲಿಸಿ.

ನೀವು ಹಂಚಿಕೆಯ ವೈಫಲ್ಯದ ಬಿಂದುವೊಂದನ್ನು ಪರಿಚಯಿಸುತ್ತೀರಿ

ನಿಮ್ಮ ಸಪೋರ್ಟ್ ಚಾಟ್‌ಬಾಟ್ OpenAI ಅನ್ನು ಮತ್ತು ನಿಮ್ಮ ಸಂಶೋಧನಾ ಟೂಲ್ Anthropic ಅನ್ನು ಬಳಸುತ್ತವೆ ಎಂದುಕೊಳ್ಳಿ—ಎರಡೂ ಒಂದೇ ಗೇಟ್‌ವೇ ಮೂಲಕ ಸಂಪರ್ಕಿಸುತ್ತವೆ. ಆದರೆ ಆ ಗೇಟ್‌ವೇ ಕೆಲಸ ಮಾಡುವುದನ್ನು ನಿಲ್ಲಿಸಿದರೆ, OpenAI ಮತ್ತು Anthropic ಸಾಮಾನ್ಯವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತಿದ್ದರೂ ಸಹ, ಎರಡೂ ಟೂಲ್‌ಗಳು ತಮ್ಮ ಮಾಡೆಲ್‌ಗಳಿಗೆ ಪ್ರವೇಶವನ್ನು ಕಳೆದುಕೊಳ್ಳುತ್ತವೆ.

ಇದು ನಿಜವಾಗಿಯೂ ಸಂಭವಿಸಿದೆ. ಜೂನ್ 12, 2025 ರ ಸ್ಥಗಿತದ ಸಮಯದಲ್ಲಿ Cloudflareನ AI Gatewayಯ ದೋಷ ದರ ಗರಿಷ್ಠ 97% ತಲುಪಿತ್ತು. ಗೇಟ್‌ವೇ ಸೆಟ್ಟಿಂಗ್‌ಗಳಿಗಾಗಿ Cloudflareನ Workers KV ಸ್ಟೋರೇಜ್ ಸೇವೆಯನ್ನು ಅವಲಂಬಿಸಿತ್ತು, ಮತ್ತು ಆ ಸೇವೆ ವಿಫಲವಾಗುತ್ತಿತ್ತು.

ನೀವೇ ಗೇಟ್‌ವೇಯನ್ನು ಚಲಾಯಿಸುತ್ತಿದ್ದರೆ, ಒಂದು ವಿಫಲವಾದರೆ ಅದರ ಕೆಲಸವನ್ನು ವಹಿಸಿಕೊಳ್ಳಬಲ್ಲ ಇನ್ನೊಂದು ಪ್ರತಿಯನ್ನು ಚಾಲನೆಯಲ್ಲಿಡಿ. ಬೇರೆ ಯಾರಾದರೂ ನಿಮ್ಮ ಗೇಟ್‌ವೇಯನ್ನು ಹೋಸ್ಟ್ ಮಾಡುತ್ತಿದ್ದರೆ, ವೈಫಲ್ಯಗಳ ಸಮಯದಲ್ಲಿ ಅವರು ಅದನ್ನು ಹೇಗೆ ಚಾಲನೆಯಲ್ಲಿಡುತ್ತಾರೆ ಮತ್ತು ಚೇತರಿಕೆಯ ಸಮಯದಲ್ಲಿ ನಿಮ್ಮ ವಿನಂತಿಗಳಿಗೆ ಏನಾಗುತ್ತದೆ ಎಂದು ಕೇಳಿ.

LLM ಗೇಟ್‌ವೇಗಳಲ್ಲಿ ಗಮನಿಸಬೇಕಾದ ಪ್ರಮುಖ ವೈಶಿಷ್ಟ್ಯಗಳು

ನೀವು ಗೇಟ್‌ವೇಗೆ ಎಲ್ಲರ ಕ್ರೆಡೆನ್ಶಿಯಲ್‌ಗಳಿಗೆ ಪ್ರವೇಶ ನೀಡಲಿದ್ದೀರಿ, ಆದ್ದರಿಂದ ಪ್ರತಿಯಾಗಿ ಅದು ಏನು ಮಾಡುತ್ತದೆ ಎಂಬುದರ ಬಗ್ಗೆ ನೀವು ಕಟ್ಟುನಿಟ್ಟಾದ ನಿರೀಕ್ಷೆಗಳನ್ನು ಇಟ್ಟುಕೊಳ್ಳಬೇಕು.

• ಬಹು ಪೂರೈಕೆದಾರರ ಮುಂದೆ ಒಂದೇ API: ನಿಮ್ಮ ಕೋಡ್ ಒಂದೇ ಸ್ವರೂಪವನ್ನು ಬಳಸುತ್ತದೆ, ಹೆಚ್ಚಾಗಿ OpenAI-ಹೊಂದಾಣಿಕೆಯದು, ಮತ್ತು ಗೇಟ್‌ವೇ ಅದನ್ನು ಅನುವಾದಿಸುತ್ತದೆ. LLM ಪೂರೈಕೆದಾರರೂ ಇದಕ್ಕೆ ಹೊಂದಿಕೊಳ್ಳಲು ಮುಂದಾಗುತ್ತಿದ್ದಾರೆ. ಉದಾಹರಣೆಗೆ, Perplexityಯ Agent API OpenAIನ Responses API ಇಂಟರ್‌ಫೇಸ್ ಅನ್ನು ಬೆಂಬಲಿಸುತ್ತದೆ, ಆದ್ದರಿಂದ ತಂಡಗಳು ಈಗಿರುವ OpenAI ಕ್ಲೈಂಟ್ ಲೈಬ್ರರಿಗಳನ್ನು ಮರುಬಳಕೆ ಮಾಡಬಹುದು.
• ನಿಯಮಗಳನ್ನು ಲಗತ್ತಿಸಿದ ವರ್ಚುವಲ್ ಕೀಗಳು: ಪ್ರತಿಯೊಂದು ತಂಡ ಅಥವಾ ಉತ್ಪನ್ನಕ್ಕೆ ಅನುಮತಿಸಲಾದ ಮಾಡೆಲ್‌ಗಳು, ವಿನಂತಿ ಮಿತಿಗಳು ಮತ್ತು ಖರ್ಚನ್ನು ನಿಯಂತ್ರಿಸುವ ನಿಯಮಗಳೊಂದಿಗೆ ತನ್ನದೇ ಆದ ಕೀ ಸಿಗುತ್ತದೆ.
• ರೂಟಿಂಗ್ ಮತ್ತು ಫಾಲ್‌ಬ್ಯಾಕ್: ಗೇಟ್‌ವೇ ನಿಮ್ಮ ಸೆಟ್ಟಿಂಗ್‌ಗಳ ಆಧಾರದ ಮೇಲೆ ವಿನಂತಿಗಳನ್ನು ಮಾಡೆಲ್‌ಗಳಿಗೆ ಕಳುಹಿಸುತ್ತದೆ; ಈ ಸೆಟ್ಟಿಂಗ್‌ಗಳು ವೆಚ್ಚ, ವೇಗ ಅಥವಾ ನಿರ್ದಿಷ್ಟ ಪೂರೈಕೆದಾರರಿಗೆ ಆದ್ಯತೆ ನೀಡಬಹುದು. ಕರೆ ವಿಫಲವಾದರೆ, ಅದು ಇನ್ನೊಂದನ್ನು ಪ್ರಯತ್ನಿಸಬಹುದು. Perplexityಯ Agent API, ವಿಭಿನ್ನ ಪೂರೈಕೆದಾರರ ಮಾಡೆಲ್‌ಗಳೂ ಸೇರಿದಂತೆ, ಗರಿಷ್ಠ ಐದು ಮಾಡೆಲ್‌ಗಳನ್ನು ನಿಮ್ಮ ಆದ್ಯತೆಯ ಕ್ರಮದಲ್ಲಿ ಪಟ್ಟಿ ಮಾಡಲು ಅನುಮತಿಸುತ್ತದೆ.
• ಕ್ಯಾಶಿಂಗ್: ಉಳಿಸಿದ ಪ್ರತಿಕ್ರಿಯೆಯು ಮತ್ತೊಂದು ಪೂರೈಕೆದಾರ ಕರೆಯನ್ನು ತಪ್ಪಿಸಬಹುದು. ಕೆಲವು ಗೇಟ್‌ವೇಗಳು ಸಂಪೂರ್ಣವಾಗಿ ಒಂದೇ ಆಗಿರುವ ವಿನಂತಿಗಳನ್ನು ಹೊಂದಿಸುತ್ತವೆ; ಇತರವು ಹೋಲುವ ಅರ್ಥವಿರುವ ವಿನಂತಿಗಳನ್ನೂ ಹೊಂದಿಸಬಲ್ಲವು. ಕ್ಯಾಶ್ ಮಾಡಿದ ಪ್ರತಿಕ್ರಿಯೆಗಳನ್ನು ಬಳಕೆದಾರ ಅಥವಾ ತಂಡದ ಪ್ರಕಾರ ಪ್ರತ್ಯೇಕಿಸಬಹುದೇ, ಮತ್ತು ವೈಯಕ್ತೀಕರಿಸಿದ ಅಥವಾ ಸಮಯ-ಸೂಕ್ಷ್ಮ ಉತ್ತರಗಳಿಗೆ ಕ್ಯಾಶಿಂಗ್ ಅನ್ನು ಆಫ್ ಮಾಡಬಹುದೇ ಎಂಬುದನ್ನು ಪರಿಶೀಲಿಸಿ.
• ಸ್ಟ್ರೀಮಿಂಗ್ ಮತ್ತು ಸ್ಥಿರವಾದ ದೋಷಗಳು: ಪ್ರತಿಕ್ರಿಯೆಗಳು ರಚನೆಯಾಗುತ್ತಿದ್ದಂತೆಯೇ ಬರುತ್ತವೆ, ಮತ್ತು ಪೂರೈಕೆದಾರರ ದೋಷಗಳನ್ನು ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್ ನಿರ್ವಹಿಸಬಲ್ಲ ಸ್ವರೂಪಕ್ಕೆ ಅನುವಾದಿಸಲಾಗುತ್ತದೆ. ನೀವು AI ಗಾರ್ಡ್‌ರೈಲ್‌ಗಳನ್ನು ಸೇರಿಸಿದಾಗ ಏನಾಗುತ್ತದೆ ಎಂಬುದನ್ನು ಪರಿಶೀಲಿಸಿ.
• ಲಾಗಿಂಗ್ ಮತ್ತು ವೆಚ್ಚದ ಹಂಚಿಕೆ: ಕರೆ ಮಾಡಿದವರು ಯಾರು, ಯಾವ ಮಾಡೆಲ್ ಅದನ್ನು ಪೂರೈಸಿತು, ಅದು ಎಷ್ಟು ಟೋಕನ್‌ಗಳನ್ನು ಬಳಸಿತು, ಎಷ್ಟು ಸಮಯ ತೆಗೆದುಕೊಂಡಿತು ಮತ್ತು ಅದರ ಅಂದಾಜು ವೆಚ್ಚ ಎಷ್ಟು ಎಂಬುದನ್ನು ಗೇಟ್‌ವೇ ದಾಖಲಿಸುತ್ತದೆ. ಲಾಗ್‌ಗಳಲ್ಲಿ ಪ್ರಾಂಪ್ಟ್‌ಗಳು ಮತ್ತು ಪ್ರತಿಕ್ರಿಯೆಗಳು ಸೇರಿವೆಯೇ ಮತ್ತು ಅವುಗಳನ್ನು ಎಷ್ಟು ಕಾಲ ಇರಿಸಲಾಗುತ್ತದೆ ಎಂಬುದನ್ನು ಪರಿಶೀಲಿಸಿ.
• ಗಾರ್ಡ್‌ರೈಲ್ ಹುಕ್‌ಗಳು: ಇವು ವಿನಂತಿಯ ಮಾರ್ಗದಲ್ಲಿ ಗೇಟ್‌ವೇ ತೀರ್ಪಿಗಾಗಿ ವಿಷಯವನ್ನು ಬಾಹ್ಯ ಸ್ಕ್ಯಾನರ್‌ಗೆ ಕಳುಹಿಸಬಹುದಾದ ಹಂತಗಳು. ಅವು ಸಾಮಾನ್ಯವಾಗಿ ಮಾಡೆಲ್ ವಿನಂತಿಯ ಮೊದಲು ಅಥವಾ ಅದರ ಪ್ರತಿಕ್ರಿಯೆಯ ನಂತರ ಇರುತ್ತವೆ. ಸ್ಕ್ಯಾನರ್ ವಿಫಲವಾದಾಗ ವಿನಂತಿಗಳು ನಿಲ್ಲುತ್ತವೆಯೇ ಅಥವಾ ಮುಂದುವರಿಯುತ್ತವೆಯೇ, ಮತ್ತು ನೀವು ಬೇರೆ ಸ್ಕ್ಯಾನರ್ ಅನ್ನು ಸಂಪರ್ಕಿಸಬಹುದೇ ಎಂಬುದನ್ನು ಪರಿಶೀಲಿಸಿ.
• ನೀವು ಬಿಗಿಯಾಗಿ ಭದ್ರಪಡಿಸಬಹುದಾದ ಅಡ್ಮಿನ್ ಇಂಟರ್‌ಫೇಸ್: ಗೇಟ್‌ವೇ ಪೂರೈಕೆದಾರ ಕ್ರೆಡೆನ್ಶಿಯಲ್‌ಗಳಿಗೆ ಪ್ರವೇಶವನ್ನು ಮತ್ತು ಎಲ್ಲರೂ ಬಳಸುವ ನಿಯಮಗಳನ್ನು ನಿರ್ವಹಿಸುತ್ತದೆ. ಅಪ್ಲಿಕೇಶನ್ ಟ್ರಾಫಿಕ್‌ನಿಂದ ಪ್ರತ್ಯೇಕವಾಗಿ ಅಡ್ಮಿನ್ ಪ್ರವೇಶವನ್ನು ನಿರ್ಬಂಧಿಸಬಹುದೇ ಮತ್ತು ಓದಲು-ಮಾತ್ರ ಬಳಕೆದಾರರು ಸೆಟ್ಟಿಂಗ್‌ಗಳನ್ನು ಬದಲಾಯಿಸಲು ಸಾಧ್ಯವಿಲ್ಲವೇ ಎಂಬುದನ್ನು ಪರಿಶೀಲಿಸಿ. ಮುಖ್ಯ ಕವಾಟಕ್ಕೆ ಒಂದು ಬೀಗ ಬೇಕು.

ನಿಮ್ಮ LLM ಗೇಟ್‌ವೇಯನ್ನು ನಿರ್ಮಿಸಲು ನೀವು ಯಾವ ಟೂಲ್‌ಗಳನ್ನು ಬಳಸಬಹುದು?

ಮಾರುಕಟ್ಟೆಯಾದ್ಯಂತ ವೈಶಿಷ್ಟ್ಯಗಳ ಪಟ್ಟಿಗಳು ಒಂದಕ್ಕೊಂದು ಹೋಲುತ್ತವೆ. ಆಂತರಿಕ ಮಾಡೆಲ್ ಪ್ರವೇಶದ ಕುರಿತ ಒಂದು Reddit ಥ್ರೆಡ್‌ನಲ್ಲಿ, ಪೋಸ್ಟ್ ಮಾಡಿದವರು ಹೀಗೆ ಕೇಳಿದರು: ಯಾವ ಗೇಟ್‌ವೇಗೆ ಮೀಸಲಾದ ಎಂಜಿನಿಯರ್ ಅಗತ್ಯವಿರುವುದಿಲ್ಲ?

ನಮ್ಮ ಅಭಿಪ್ರಾಯದಲ್ಲಿ ಅದು ಸರಿಯಾದ ಪ್ರಶ್ನೆ, ಮತ್ತು ನೀವು ಎಷ್ಟು ಕೆಲಸದ ಜವಾಬ್ದಾರಿಯನ್ನು ವಹಿಸಿಕೊಳ್ಳಲು ಸಿದ್ಧರಿದ್ದೀರಿ ಎಂಬುದನ್ನು ಅವಲಂಬಿಸಿ ಅದಕ್ಕೆ ನಾಲ್ಕು ಉತ್ತರಗಳಿವೆ.

ಅದನ್ನು ನೀವೇ ಬರೆಯಿರಿ

ಕನಿಷ್ಠ ಗೇಟ್‌ವೇ ಕೆಲವೇ ಕೆಲಸಗಳನ್ನು ನಿರ್ವಹಿಸುತ್ತದೆ—ವಿನಂತಿಗಳನ್ನು ಸ್ವೀಕರಿಸುವುದು, ಕರೆ ಮಾಡುವವರ ಕೀಯನ್ನು ಪರಿಶೀಲಿಸುವುದು, ಪೂರೈಕೆದಾರ ಕ್ರೆಡೆನ್ಶಿಯಲ್ ಅನ್ನು ಸೇರಿಸುವುದು, ಕರೆಯನ್ನು ಮುಂದಕ್ಕೆ ಕಳುಹಿಸುವುದು ಮತ್ತು ಫಲಿತಾಂಶವನ್ನು ಲಾಗ್ ಮಾಡುವುದು. ಆದರೆ ವಿಭಿನ್ನ ಪೂರೈಕೆದಾರರ ಸ್ವರೂಪಗಳನ್ನು ಬೆಂಬಲಿಸುವುದು ಕೆಲಸವನ್ನು ಹೆಚ್ಚಿಸುತ್ತದೆ. ಇಡೀ ವ್ಯವಸ್ಥೆಯನ್ನು ಚಾಲನೆಯಲ್ಲಿಡುವುದೂ ಹಾಗೆಯೇ.

ನೀವು ಈಗಾಗಲೇ Envoy ಅನ್ನು ಚಲಾಯಿಸುತ್ತಿದ್ದರೆ, ಅದರ external-processing ಫಿಲ್ಟರ್ ವಿನಂತಿಗಳು ಮತ್ತು ಪ್ರತಿಕ್ರಿಯೆಗಳನ್ನು ಪರಿಶೀಲಿಸುವ ಮತ್ತು ಬದಲಾಯಿಸುವ ಸೇವೆಯನ್ನು ಸಂಪರ್ಕಿಸಲು ನಿಮಗೆ ಅವಕಾಶ ನೀಡುತ್ತದೆ. ಆದರೂ ಆ ಸೇವೆಯನ್ನು ನೀವೇ ನಿರ್ಮಿಸಿ ಚಲಾಯಿಸಬೇಕಾಗುತ್ತದೆ.

ಗೇಟ್‌ವೇ ವೆಚ್ಚವನ್ನು ಕಡಿಮೆ ಮಾಡುತ್ತದೆಯೇ ಎಂಬ ಕುರಿತ r/LLMDevs ಥ್ರೆಡ್‌ನಲ್ಲಿ, ಪ್ರತಿಯೊಂದು ಕರೆಯಲ್ಲೂ ಟೋಕನ್‌ಗಳನ್ನು ಮತ್ತು ಕ್ಯಾಶ್-ಹಿಟ್ ಫ್ಲ್ಯಾಗ್ ಅನ್ನು ಲಾಗ್ ಮಾಡಿದ್ದು, ಸಂಪೂರ್ಣವಾಗಿ ಒಂದೇ ಆಗಿರುವ ಪ್ರಾಂಪ್ಟ್‌ಗಳಿಗೆ ಪೂರ್ಣ ಬೆಲೆ ಪಾವತಿಸುತ್ತಿದ್ದ ಎರಡು ಜಾಬ್‌ಗಳನ್ನು ಪತ್ತೆಹಚ್ಚಲು ಸಹಾಯ ಮಾಡಿತು ಎಂದು u/QuanTradin ಹೇಳಿದರು.

“...ಅದನ್ನು ಸರಿಪಡಿಸಿದ್ದು ಯಾವುದೇ ರೂಟಿಂಗ್ ಲೇಯರ್‌ಗಿಂತ ಹೆಚ್ಚು ಮೌಲ್ಯಯುತವಾಗಿತ್ತು.”

ಅದು ವರದಿಯಾದ ಒಂದು ಅನುಭವ, ಮತ್ತು ಇಲ್ಲಿಂದಲೇ ಆರಂಭಿಸುವುದು ಒಳ್ಳೆಯದು. ಅದನ್ನು ರೂಟ್ ಮಾಡಲು ಸಂಕೀರ್ಣ ವಿಧಾನಗಳನ್ನು ನಿರ್ಮಿಸುವ ಮೊದಲು ನೀವು ಯಾವುದಕ್ಕೆ ಪಾವತಿಸುತ್ತಿದ್ದೀರಿ ಎಂಬುದನ್ನು ಕಂಡುಕೊಳ್ಳಿ.

ಓಪನ್-ಸೋರ್ಸ್ ಗೇಟ್‌ವೇಯನ್ನು ಸ್ವಯಂ-ಹೋಸ್ಟ್ ಮಾಡಿ

LiteLLM ಇಲ್ಲಿ ಸಾಮಾನ್ಯ ಆಯ್ಕೆ: OpenAI-ಹೊಂದಾಣಿಕೆಯದು, ವ್ಯಾಪಕ ಶ್ರೇಣಿಯ ಪೂರೈಕೆದಾರರನ್ನು ಬೆಂಬಲಿಸುತ್ತದೆ, ಮತ್ತು ದೊಡ್ಡ ಸಮುದಾಯವನ್ನು ಹೊಂದಿದೆ. Bifrost ಒಂದು ಪರ್ಯಾಯ, ಇದನ್ನು ಪ್ರತಿ-ವಿನಂತಿಯ ಕಡಿಮೆ ಓವರ್‌ಹೆಡ್‌ಗಾಗಿ ನಿರ್ಮಿಸಲಾಗಿದೆ. ನಿಮ್ಮ ವೈಶಿಷ್ಟ್ಯಗಳ ಪಟ್ಟಿಯಲ್ಲಿ ಅಬ್ಸರ್ವೆಬಿಲಿಟಿ ಅಗ್ರಸ್ಥಾನದಲ್ಲಿದ್ದರೆ Helicone ನೋಡಲು ಯೋಗ್ಯವಾಗಿದೆ.

ಯಾವುದೇ ಉತ್ಪನ್ನದಂತೆ LiteLLM ಕೂಡ ಕೆಲವು ತಂಡಗಳಿಗೆ ಮಿತಿಗಳನ್ನು ಹೊಂದಿದೆ. ಸ್ವಂತವಾಗಿ ನಿರ್ಮಿಸುವುದಕ್ಕೆ ಇರುವ ಪರ್ಯಾಯಗಳ ಕುರಿತ r/aiagents ಥ್ರೆಡ್‌ನಲ್ಲಿ, LiteLLM ರೂಟಿಂಗ್ ಅನ್ನು ಚೆನ್ನಾಗಿ ನಿರ್ವಹಿಸಿತು, ಆದರೆ ತಂಡಗಳಾದ್ಯಂತ ಪ್ರಾಂಪ್ಟ್ ಆವೃತ್ತೀಕರಣ ಮತ್ತು ಮಾಡೆಲ್‌ಗಳನ್ನು ಬದಲಾಯಿಸುವಾಗ ನಿರಂತರ ಮೌಲ್ಯಮಾಪನಗಳ (evals) ವಿಷಯದಲ್ಲಿ ತಮಗೆ ಸಾಕಾಗಲಿಲ್ಲ, ಇದು ತಮ್ಮನ್ನು ಪ್ರತ್ಯೇಕ ಟೂಲ್‌ನತ್ತ ತಳ್ಳಿತು ಎಂದು u/Own_Bar_920 ಹೇಳಿದರು.

ಅವು ಮೂಲಭೂತ ಗೇಟ್‌ವೇ ರೂಟಿಂಗ್‌ಗಿಂತ ಮೀರಿದ ಅಗತ್ಯಗಳು, ಮತ್ತು ಅದೇ ಮುಖ್ಯ ಅಂಶ—ರೂಟಿಂಗ್ ಮುಖ್ಯ ಅಗತ್ಯವಾಗಿದ್ದರೆ, LiteLLM ಅವರಿಗೆ ಚೆನ್ನಾಗಿ ಕೆಲಸ ಮಾಡಿತು.

ನಿಮಗೆ ಸಿದ್ಧವಾದ ವೈಶಿಷ್ಟ್ಯಗಳ ಪಟ್ಟಿ ಸಿಗುತ್ತದೆ, ಕೆಲವು ವೈಶಿಷ್ಟ್ಯಗಳು ಆವೃತ್ತಿಯನ್ನು (edition) ಅವಲಂಬಿಸಿರುತ್ತವೆ, ಮತ್ತು ಗೇಟ್‌ವೇ ನಿಮ್ಮ ನೆಟ್‌ವರ್ಕ್‌ನೊಳಗೇ ಉಳಿಯುತ್ತದೆ. ಪ್ಯಾಚಿಂಗ್‌ನ ಜವಾಬ್ದಾರಿಯೂ ನಿಮ್ಮದೇ—ಹಿಂದೆ ಉಲ್ಲೇಖಿಸಿದ Check Point ಬಹಿರಂಗಪಡಿಸುವಿಕೆಗಳು ಇದನ್ನು ಸ್ಪಷ್ಟಪಡಿಸಿದವು—ಮತ್ತು ಗೇಟ್‌ವೇಯ ಲಭ್ಯತೆಯ ಜವಾಬ್ದಾರಿಯೂ ನಿಮ್ಮದೇ, ಇದನ್ನು ಹಂಚಿಕೆಯ ವೈಫಲ್ಯದ ಬಿಂದುವಿನ ಕುರಿತ ವಿಭಾಗ ಸ್ಪಷ್ಟಪಡಿಸಿತು.

ಆದರೆ ಅದರ ಜವಾಬ್ದಾರಿ ಹೊರಲು ಒಬ್ಬರನ್ನು ನಿಮ್ಮ ಬಜೆಟ್‌ನಲ್ಲಿ ಪರಿಗಣಿಸಿ. ಆಂತರಿಕ ಪ್ರವೇಶಕ್ಕಾಗಿ ಗೇಟ್‌ವೇಗಳ ಕುರಿತ r/LLMDevs ಥ್ರೆಡ್‌ನಲ್ಲಿನ ಒಂದು ಕಳವಳ ನಿರ್ವಹಣೆಯಾಗಿತ್ತು. u/Informal-Writer9685 ಅವರು “ನಿರ್ವಹಿಸಲು ಮೀಸಲಾದ ಎಂಜಿನಿಯರ್ ಅಗತ್ಯವಿಲ್ಲದ” ಏನನ್ನಾದರೂ ಬಯಸಿದ್ದರು ಮತ್ತು LiteLLMನ ವರದಿಯಾದ ಅಪ್‌ಗ್ರೇಡ್ ಅಸ್ಥಿರತೆ ತಮ್ಮ ಪ್ರಮಾಣದಲ್ಲಿ ನಿಜವಾದ ಸಮಸ್ಯೆಯೇ ಅಥವಾ ಕೇವಲ ಪ್ರೊಡಕ್ಷನ್‌ಗೆ ಸಂಬಂಧಿಸಿದ ಕಾಳಜಿಯೇ ಎಂದು ಕೇಳಿದರು.

ನಿರ್ವಹಿತ ಗೇಟ್‌ವೇ ಬಳಸಿ

Cloudflare AI Gateway, Vercel AI Gateway, OpenRouter ಮತ್ತು Portkeyಯ ಹೋಸ್ಟ್ ಮಾಡಲಾದ ಗೇಟ್‌ವೇ ನಿಮಗಾಗಿ ಸೇವೆಯನ್ನು ಚಲಾಯಿಸುತ್ತವೆ. ಹೊಂದಾಣಿಕೆಯ ಅಪ್ಲಿಕೇಶನ್‌ಗೆ, ಮೊದಲ ವಿನಂತಿಯನ್ನು ಯಶಸ್ವಿಯಾಗಿ ಕಳುಹಿಸಲು URL ಬದಲಾವಣೆ ಮತ್ತು ಒಂದು API ಕೀಗಿಂತ ಹೆಚ್ಚೇನೂ ಬೇಕಾಗದಿರಬಹುದು.

ಇಲ್ಲಿನ ರಾಜಿ ಎಂದರೆ, ಪ್ರತಿಯೊಂದು ಪ್ರಾಂಪ್ಟ್ ಈಗ ಪೂರೈಕೆದಾರರನ್ನು ತಲುಪುವ ಮೊದಲು ಮೂರನೇ ವ್ಯಕ್ತಿಯ ಮೂಲಕ ಹಾದುಹೋಗುತ್ತದೆ. ಅಂದರೆ ನಿಮ್ಮ ಕಂಪ್ಲೈಯನ್ಸ್ ದಾಖಲೆಪತ್ರಗಳಿಗೆ ಇನ್ನೊಂದು ಡೇಟಾ ಪ್ರೊಸೆಸರ್ ಸೇರುತ್ತದೆ, ಮತ್ತು ಗೇಟ್‌ವೇಯ ಸ್ಥಗಿತ ವೆಂಡರ್‌ನ ಘಟನೆಯಾಗುತ್ತದೆ—ಅದನ್ನು ಸರಿಪಡಿಸುವುದು ನಿಮ್ಮ ಕೈಯಲ್ಲಿರುವುದಿಲ್ಲ.

ಉದಾಹರಣೆಗೆ, ಫೆಬ್ರವರಿ 17 ಮತ್ತು 19, 2026 ರಂದು, ಕ್ಯಾಶಿಂಗ್ ಅವಲಂಬನೆಯೊಂದು ವಿಫಲವಾದ ನಂತರ OpenRouter ಕ್ರಮವಾಗಿ 38 ಮತ್ತು 35 ನಿಮಿಷಗಳ ಸ್ಥಗಿತಗಳನ್ನು ಅನುಭವಿಸಿತು. ಕೆಲವು ಗ್ರಾಹಕರು “User not found” ದೋಷಗಳನ್ನು ಪಡೆದರು ಮತ್ತು ಸಂಪೂರ್ಣವಾಗಿ ಮಾನ್ಯವಾದ API ಕೀಗಳನ್ನು ಡೀಬಗ್ ಮಾಡುವುದರಲ್ಲಿ ಸಮಯ ಕಳೆದರು. ದೋಷ ಗೇಟ್‌ವೇಯ ಮೂಲಸೌಕರ್ಯದಲ್ಲಿತ್ತು.

ಆದರೆ OpenRouterಗೆ ಶ್ರೇಯಸ್ಸು ಸಲ್ಲಬೇಕು: ಅದು ವಿವರವಾದ ಪೋಸ್ಟ್‌ಮಾರ್ಟಮ್ ಅನ್ನು ಪ್ರಕಟಿಸಿತು ಮತ್ತು ಕ್ಯಾಶ್ ವೈಫಲ್ಯವು ತನ್ನ ಡೇಟಾಬೇಸ್ ಮೇಲೆ ಅತಿಯಾದ ಹೊರೆ ಹಾಕದಂತೆ ತಡೆಯಲು ರಕ್ಷಣಾ ಕ್ರಮಗಳನ್ನು ಸೇರಿಸಿತು. OpenRouterನಂತಹ ನಿರ್ವಹಿತ ಗೇಟ್‌ವೇ ಪ್ರವೇಶವನ್ನು ಸರಳಗೊಳಿಸಬಹುದು, ಆದರೆ r/LLMDevsನಲ್ಲಿ u/QuanTradin ಗಮನಸೆಳೆಯುವಂತೆ, ಬಿಲ್‌ಗಳನ್ನು ಒಗ್ಗೂಡಿಸುವುದರಿಂದ ಖರ್ಚು ತಾನಾಗಿಯೇ ಕಡಿಮೆಯಾಗುವುದಿಲ್ಲ.

ನಿಮ್ಮ ಬಳಿ ಈಗಾಗಲೇ ಇರುವ API ಗೇಟ್‌ವೇಯನ್ನು ವಿಸ್ತರಿಸಿ

Kong, Apigee ಅಥವಾ Azure API Management ಈಗಾಗಲೇ ನಿಮ್ಮ ಸೇವೆಗಳ ಮುಂಭಾಗದಲ್ಲಿದ್ದರೆ, ಪ್ರತಿಯೊಂದೂ AI-ನಿರ್ದಿಷ್ಟ ಸಾಮರ್ಥ್ಯಗಳನ್ನು ಹೊಂದಿದೆ: Kong AI Gateway, Apigeeಯ AI ಗೇಟ್‌ವೇ ನೀತಿಗಳು ಮತ್ತು Azure API Managementನ AI ಗೇಟ್‌ವೇ. ನಿಮ್ಮ ಬಳಿ ಈಗಾಗಲೇ ಇರುವ ದೃಢೀಕರಣ, ನೆಟ್‌ವರ್ಕ್ ನಿಯಮಗಳು ಮತ್ತು ಕಾರ್ಯಾಚರಣಾ ಕಾರ್ಯವಿಧಾನಗಳ ಮೇಲೆ ನೀವು ನಿರ್ಮಿಸಬಹುದು, ಪ್ಲಗಿನ್‌ಗಳು ಅಥವಾ ನೀತಿಗಳ ಮೂಲಕ ಮಾಡೆಲ್ ನಿಯಂತ್ರಣಗಳನ್ನು ಸೇರಿಸಬಹುದು.

ದೊಡ್ಡ ಕಂಪನಿಯಲ್ಲಿ ಇದು ಸಾಂಸ್ಥಿಕವಾಗಿ ಅತ್ಯಂತ ಕಡಿಮೆ ಪ್ರತಿರೋಧದ ಮಾರ್ಗವಾಗಬಹುದು. ಸ್ವತಂತ್ರ ಗೇಟ್‌ವೇಗಳಿಗೆ ಹೋಲಿಸಿದರೆ ಇವುಗಳ AI ವೈಶಿಷ್ಟ್ಯಗಳು ಇನ್ನೂ ಹೊಸವು. ನೀವು ಬಳಸಲು ಯೋಜಿಸಿರುವ ಸಂಪೂರ್ಣ ಪ್ಲಗಿನ್‌ಗಳು ಅಥವಾ ನೀತಿಗಳ ಮೂಲಕ ಟೋಕನ್-ಆಧಾರಿತ ರೇಟ್ ಲಿಮಿಟಿಂಗ್ ಮತ್ತು ಸ್ಟ್ರೀಮಿಂಗ್ ಅನ್ನು ಪರೀಕ್ಷಿಸಲು ಮರೆಯದಿರಿ.

ಹಾಗಾಗಿ, ಖಂಡಿತವಾಗಿಯೂ ಮಾಸ್ಟರ್ ವಾಲ್ವ್ ಅನ್ನು—ಸರ್ವಶಕ್ತ ಗೇಟ್‌ವೇಯನ್ನು—ಅಳವಡಿಸಿ. ಆದರೂ, ಪರಿಚಯದಲ್ಲಿ ಉಲ್ಲೇಖಿಸಿದ ಎಂಜಿನಿಯರ್ ಹೇಳುವುದರಲ್ಲಿ ಹುರುಳಿದೆ. ಕಂಪನಿಯೊಂದರ ಮಾಡೆಲ್ ಪ್ರವೇಶವು ಡ್ರಾಯರ್‌ನಲ್ಲಿ ಸರಿಯಾದ ಕೀಲಿಯನ್ನು ಇಟ್ಟುಕೊಂಡಿರುವ ಯಾರೋ ಒಬ್ಬರ ಮೇಲೆ ಅವಲಂಬಿತವಾಗಿರಬಾರದು.

ಆ ಕೀಲಿಗಳನ್ನು ಕೇಂದ್ರೀಕೃತ ನಿಯಂತ್ರಣಕ್ಕೆ ಒಳಪಡಿಸುವ ಮೂಲಕ ಗೇಟ್‌ವೇ ಈ ಸಮಸ್ಯೆಯನ್ನು ಬಗೆಹರಿಸುತ್ತದೆ, ಆದರೆ ಇದರಿಂದ ಡ್ರಾಯರ್ ಅನ್ನು ತೆರೆದಿಡುವುದರ ಅಪಾಯ ಇನ್ನಷ್ಟು ಹೆಚ್ಚುತ್ತದೆ. ಆ ಡ್ರಾಯರ್ ಯಾರದ್ದು ಎಂಬುದು ನಿಮಗೆ ತಿಳಿದಿರಬೇಕು.

LLM ಗೇಟ್‌ವೇ ಕುರಿತು ಪದೇ ಪದೇ ಕೇಳಲಾಗುವ ಪ್ರಶ್ನೆಗಳು

LLM ಗೇಟ್‌ವೇ ಉಚಿತವೇ?

ನೀವು ಸಾಮಾನ್ಯವಾಗಿ ಈ ವರ್ಗದ ಬಗ್ಗೆ ಕೇಳುತ್ತಿದ್ದರೆ, ಕೆಲವು LLM ಗೇಟ್‌ವೇಗಳು ಉಚಿತ ಆವೃತ್ತಿಗಳನ್ನು ಹೊಂದಿವೆ.

LLM ಗೇಟ್‌ವೇಗಳು ಉಚಿತ ಓಪನ್-ಸೋರ್ಸ್ ಸಾಫ್ಟ್‌ವೇರ್‌ನಿಂದ ಹಿಡಿದು ತಿಂಗಳಿಗೆ ಸುಮಾರು $50 ರಿಂದ ಆರಂಭವಾಗುವ ಪಾವತಿಸಿದ ಪ್ಲ್ಯಾನ್‌ಗಳವರೆಗೆ ಲಭ್ಯವಿವೆ, ಹಾಗೆಯೇ ಎಂಟರ್‌ಪ್ರೈಸ್ ನಿಯೋಜನೆಗಳಿಗೆ ಕಸ್ಟಮ್ ಬೆಲೆ ನಿಗದಿ ಇರುತ್ತದೆ. ಕೆಲವು ಗೇಟ್‌ವೇಗಳು ಇದರ ಬದಲಿಗೆ ಶೇಕಡಾವಾರು ಶುಲ್ಕ ವಿಧಿಸುತ್ತವೆ; ಉದಾಹರಣೆಗೆ, OpenRouterನ Standard ಪ್ಲ್ಯಾನ್ ಕ್ರೆಡಿಟ್‌ಗಳ ಖರೀದಿಯ ಮೇಲೆ 5.5% ಹೆಚ್ಚುವರಿ ಶುಲ್ಕ ಸೇರಿಸುತ್ತದೆ.

ಯಾವ LLM ಗೇಟ್‌ವೇ ಅತ್ಯುತ್ತಮ?

ಯಾವ ಕೆಲಸದ ಹೊಣೆಯನ್ನು ನೀವೇ ಹೊರಲು ಸಿದ್ಧರಿದ್ದೀರಿ?

• ನೀವು ಸ್ವಯಂ-ಹೋಸ್ಟ್ ಮಾಡಿ ಕಾನ್ಫಿಗರೇಶನ್ ಅನ್ನು ನಿಯಂತ್ರಿಸಲು ಬಯಸಿದರೆ, Bifrost ಅಥವಾ Helicone ಅನ್ನು ಪರಿಶೀಲಿಸಿ.
• ಸೇವೆಯನ್ನು ಬೇರೆಯವರು ನಿರ್ವಹಿಸಬೇಕೆಂದು ಬಯಸುವ ತಂಡಗಳಿಗೆ OpenRouter ಅಥವಾ Vercel AI Gateway ನಂತಹ ನಿರ್ವಹಿತ ಆಯ್ಕೆ ಸೂಕ್ತವಾಗಿದೆ.
• ನೀವು ಈಗಾಗಲೇ Kong ಅಥವಾ Azure API Management ಬಳಸುತ್ತಿದ್ದರೆ, ಮೊದಲು ಅವುಗಳ AI ಸಾಮರ್ಥ್ಯಗಳನ್ನು ಪರಿಶೀಲಿಸಿ.

ಪೂರೈಕೆದಾರರು ವಿಫಲವಾದಾಗ ಏನಾಗುತ್ತದೆ ಎಂಬುದನ್ನೂ ಒಳಗೊಂಡಂತೆ, ನೀವು ಆಯ್ಕೆಮಾಡಿದ ಕಿರುಪಟ್ಟಿಯನ್ನು ನಿಮ್ಮದೇ ವಿನಂತಿಗಳೊಂದಿಗೆ ಪರೀಕ್ಷಿಸಿ.

AWS ತನ್ನದೇ ಆದ LLM ಗೇಟ್‌ವೇ ಹೊಂದಿದೆಯೇ?

ಹೌದು. AWS “ಇನ್ಫರೆನ್ಸ್ ಟಾರ್ಗೆಟ್‌ಗಳು” (inference targets) ಎಂದು ಕರೆಯುವ ವ್ಯವಸ್ಥೆಯ ಮೂಲಕ Amazon Bedrock AgentCore Gateway ಮಾಡೆಲ್ ಕರೆಗಳನ್ನು ಬೆಂಬಲಿಸುತ್ತದೆ. ಇವುಗಳ ಸಹಾಯದಿಂದ ಅಪ್ಲಿಕೇಶನ್‌ಗಳು ಒಂದೇ ಎಂಡ್‌ಪಾಯಿಂಟ್ ಬಳಸಿ Amazon Bedrock, OpenAI ಮತ್ತು Anthropic ಸೇರಿದಂತೆ ವಿವಿಧ ಪೂರೈಕೆದಾರರನ್ನು ತಲುಪಬಹುದು; ಪೂರೈಕೆದಾರರ ಕ್ರೆಡೆನ್ಶಿಯಲ್‌ಗಳು ಮತ್ತು ರೂಟಿಂಗ್ ಅನ್ನು ಗೇಟ್‌ವೇ ನಿರ್ವಹಿಸುತ್ತದೆ.