LLM கேட்வே எவ்வாறு செயல்படுகிறது? பொறியியல் குழுக்களுக்கான ஒரு நடைமுறை வழிகாட்டி

LLM கேட்வே என்பது உங்கள் பயன்பாடுகளுக்கும், அதன் வழியாக நீங்கள் இணைக்கும் மாடல் வழங்குநர்களுக்கும் இடையில் அமைந்து, அங்கீகாரச் சான்றுகளை நிர்வகிக்கவும் பயன்பாட்டைக் கண்காணிக்கவும் உங்களுக்கு ஒரே இடத்தை வழங்குகிறது.

“இப்போதைக்கு, இது ஒரு படுமோசமான குளறுபடி,” என்று ஒரு பொறியாளர் செப்டம்பர் 2026-இல் Reddit-இன் r/LLMDevs பகுதியில் எழுதினார்.

“நாங்கள் பயன்படுத்தும் Claude, OpenAI, AWS Bedrock மற்றும் பிற அனைத்து இன்ஃபெரன்ஸ் வழங்குநர்களுக்கும் ஒவ்வொருவரிடமும் தனித்தனி கீகள் உள்ளன.”

இலகுரக FastAPI கேட்வேயான llm-proxy-tk பற்றிய BigGo-வின் செய்தி அறிக்கை, இந்த அமைப்பை LLM-களை “நிறுவனக் குழாய் நீராக” மாற்றுவதோடு ஒப்பிடுகிறது; இதில் கேட்வே என்பது கட்டடத்தின் பிரதான வால்வு.

ஆனால் இந்தக் குழாய் அமைப்பின் மீது அவ்வளவு நம்பிக்கை வைப்பதற்கு முன், நீங்கள் எதை நிறுவுகிறீர்கள் என்பதைப் பார்ப்போம்.

LLM கேட்வே என்றால் என்ன?

LLM கேட்வே என்பது மாடல் அழைப்புகளுக்கான ஒரு ரிவர்ஸ் ப்ராக்ஸி. உங்கள் பயன்பாடுகள் OpenAI, Anthropic, Google அல்லது நீங்கள் பயன்படுத்தும் எந்த LLM வழங்குநருக்கும் நேரடியாக அனுப்புவதற்குப் பதிலாக, கோரிக்கைகளை அதற்கு அனுப்புகின்றன. கேட்வே அந்தக் கோரிக்கைகளை முன்னனுப்புகிறது; அவ்வாறு செல்லும் வழியில் உங்கள் விதிகளைப் பயன்படுத்துகிறது.

ஒவ்வொரு LLM வழங்குநருக்கும் ஒரு API உள்ளது: அதற்கென தனி கோரிக்கை வடிவம், தனி அங்கீகார முறை, பிழைகளைத் திருப்பி அனுப்பும் தனி வழி ஆகியவை உள்ளன. ஒவ்வொன்றுக்கும் தனித்தனி வீத வரம்புகளும் தோல்வி முறைகளும் உள்ளன. இப்போது, அவற்றுக்கு முன்னால் பொதுவான அடுக்கு எதுவும் இல்லையென்றால், ஒரு வழங்குநரை அழைக்கும் ஒவ்வொரு பயன்பாடும் எல்லாவற்றையும் தானே செய்கிறது, அதுவும் சற்று வித்தியாசமாகச் செய்கிறது.

குழாய் நீர் ஒப்புமை ஓரளவுக்குத்தான் பொருந்தும், ஆனால் இந்த அளவுக்குப் பொருந்துகிறது—வழங்குநர்கள் ஒருமுறை, கேட்வேயில் இணைக்கப்படுகிறார்கள். அதன் பிறகு, ஒவ்வொரு பயன்பாட்டுக்கும் அளவீடு செய்யப்படும் தனி இணைப்பு கிடைக்கிறது; இதனால் யார் எதைப் பயன்படுத்துகிறார்கள் என்பதைப் பார்க்கலாம், மற்றவற்றைத் தொடாமலேயே எந்த ஒரு இணைப்பையும் துண்டிக்கலாம்.

LLM, AI, MCP மற்றும் API கேட்வேகள்: என்ன வேறுபாடு?

LLM கேட்வே எவ்வாறு செயல்படுகிறது?

உங்கள் பயன்பாட்டிலிருந்து மாடலுக்குச் சென்று திரும்பும் ஒரு கோரிக்கையைப் பின்தொடருங்கள்.

1. கோரிக்கை கேட்வேயை அடைகிறது: உங்கள் பயன்பாடு, பெரும்பாலும் OpenAI-இணக்கமான வடிவத்தில், சாதாரணமாகத் தோன்றும் ஒரு அரட்டைக் கோரிக்கையை கேட்வேயின் எண்ட்பாயிண்டுக்கு அனுப்புகிறது. பயன்பாட்டின் பார்வையில், மாடலை அடைய அது அழைக்கும் முகவரி இதுதான்.
2. யார் கேட்கிறார்கள், அவர்கள் என்ன செய்ய அனுமதிக்கப்பட்டுள்ளனர் என்பதை கேட்வே சரிபார்க்கிறது: கோரிக்கையை முன்னனுப்புவதற்கு முன், அது அங்கீகாரச் சான்றுகளைச் சரிபார்க்கிறது. பெரும்பாலும், அது ஒரு குழுவுக்கோ தயாரிப்புக்கோ வழங்கப்பட்ட மெய்நிகர் கீயாக இருக்கும். நீங்கள் உள்ளீட்டுப் பாதுகாப்பு வரம்புகளை (guardrails) இணைத்திருந்தால், உணர்திறன் மிக்க தரவுக்காகவோ மாடலின் அறிவுறுத்தல்களை மீறும் முயற்சிகளுக்காகவோ ப்ராம்ப்ட்களும் ஸ்கேன் செய்யப்படலாம்.
3. தன்னிடம் ஏற்கெனவே பதில் உள்ளதா என்பதை கேட்வே சரிபார்க்கிறது: கேச்சிங் இயக்கப்பட்டிருந்தால், தகுதியான பொருந்தும் கோரிக்கைக்கு மற்றொரு வழங்குநர் அழைப்பு இல்லாமலேயே சேமிக்கப்பட்ட பதிலிலிருந்து பதிலளிக்க முடியும். சில கேட்வேகள் செமாண்டிக் கேச்சிங்கையும் வழங்குகின்றன; இது ஒரே மாதிரியான கோரிக்கைகளுக்குப் பதிலாகப் போதுமான அளவு ஒத்தவை எனக் கருதப்படும் கோரிக்கைகளைத் தேடுகிறது. இது FAQ பாணி டிராஃபிக்குக்குப் பொருத்தமாக இருக்கலாம்.
4. கோரிக்கை எங்கு செல்ல வேண்டும் என்பதை கேட்வே தேர்ந்தெடுக்கிறது: கோரிக்கை ஒரு குறிப்பிட்ட மாடலையோ ஒரு மாற்றுப்பெயரையோ குறிப்பிடலாம். கேட்வே உங்கள் உள்ளமைவில் பொருந்தும் வழித்தடத்தைத் தேடுகிறது. நீங்கள் ஒரு காப்பு வழித்தடத்தையும் உள்ளமைக்கலாம். வழங்குநர் A-இடமிருந்து குறித்த நேரத்தில் பதில் வராவிட்டால், கேட்வே வழங்குநர் B-ஐ முயற்சிக்கலாம்.
5. கேட்வே அழைப்பைத் தயார்செய்து பதிலைத் திருப்பி அனுப்புகிறது: கேட்வே உங்கள் கோரிக்கையைத் தேர்ந்தெடுக்கப்பட்ட வழங்குநரின் வடிவத்துக்கு மாற்றி, வெளிச்செல்லும் அழைப்பை அங்கீகரிக்கிறது. பதில் கிடைத்தவுடன், அது உங்கள் பயன்பாட்டுக்குத் தேவையான வடிவத்துக்கு மாற்றப்படுகிறது.
6. நடந்ததை கேட்வே பதிவுசெய்கிறது: லாகிங் இயக்கப்பட்டிருக்கும்போது, அழைப்பை யார் மேற்கொண்டார்கள், எந்த மாடல் அதைக் கையாண்டது, டோக்கன் எண்ணிக்கைகள், லேட்டன்சி, செலவு உள்ளிட்ட விவரங்களை கேட்வே பதிவுசெய்கிறது. அறிமுகத்தில் குறிப்பிட்ட Reddit பொறியாளரிடம் இல்லாத பதிவு இதுதான்.

கேட்வேயைப் புரொடக்‌ஷனில் பயன்படுத்துவதற்கு முன் நீங்கள் தெரிந்துகொள்ள வேண்டிய 4 விஷயங்கள்

மேலே உள்ள பகுதியில் உள்ள அனைத்தும் சாத்தியமாவதற்குக் காரணம், தன் வழியாக அனுப்பப்படும் ஒவ்வொரு கோரிக்கையையும் கேட்வே பார்ப்பதுதான். அதுதான் இதன் விளம்பர வாக்குறுதி. ஆனால், நீங்கள் திட்டமிட வேண்டிய தாக்குதல் பரப்பு மற்றும் விற்பனையாளர் சார்புநிலை பற்றிய விவரிப்பும் அதுவே.

இப்போது உங்கள் AI ஸ்டாக்கில் மிக மதிப்புமிக்க பெட்டி கேட்வேதான்

கேட்வே அணுகலை மையப்படுத்துகிறது. எனவே, அது பல அங்கீகாரச் சான்றுகளை ஒரே சேவையின் கைக்கெட்டும் தூரத்தில் வைக்கிறது. ஒரு LiteLLM வரிசைப்படுத்தல் வைத்திருக்கக்கூடிய அல்லது பெறக்கூடியவற்றை Microsoft-இன் பாதுகாப்புக் குழு பட்டியலிடுகிறது: வழங்குநர் API கீகள், அதன் சொந்த மாஸ்டர் கீ, மெய்நிகர் கீ பதிவுகள், தரவுத்தள இணைப்புச் சரங்கள், ரூட்டிங் அமைப்புகள், டெனன்ட் கொள்கைகள்.

அக்டோபர் 2026-இல், LiteLLM-இல் உள்ள இரண்டு அதிக அபாயமுள்ள பாதிப்புகளை Check Point Research வெளிப்படுத்தியது:

• CVE-2026-35029, படிக்க மட்டுமேயான பயனர்கள் உட்பட அங்கீகரிக்கப்பட்ட பயனர்கள் நிர்வாகச் செயல்பாடுகளை அணுகவும், இன்ஸ்டன்ஸைக் கைப்பற்றவும் வழிவகுத்தது.
• CVE-2026-59823, பயனர்கள் தங்கள் கட்டுப்பாட்டில் உள்ள சர்வருக்குக் கோரிக்கைகளைத் திசைதிருப்பி வழங்குநர் கீகளைக் கைப்பற்ற வழிவகுத்தது.

இவை இரண்டும் பதிப்பு 1.83.9-இல் சரிசெய்யப்பட்டன. கேட்வேயைப் பயன்படுத்தும் ஒரு பயன்பாட்டால் அதன் அமைப்புகளை மாற்ற முடியக்கூடாது.

உங்கள் பாதுகாப்பு வரம்புகளுக்கு ஒரு தோல்விக் கொள்கை தேவை

LiteLLM, Kong, TrueFoundry, Portkey, Azure API Management, Apigee உள்ளிட்ட முக்கிய கேட்வேகளில் உள்ள மூன்றாம் தரப்பு பாதுகாப்பு வரம்பு ஒருங்கிணைப்புகளை அக்டோபர் 4, 2026 அன்று Pillar Security வெளியிட்ட மதிப்பாய்வு ஆவணப்படுத்துகிறது. (Pillar பாதுகாப்பு வரம்புகளை விற்பனை செய்கிறது, எனவே அதன் பரிந்துரைகளைப் படிக்கும்போது அதை நினைவில் கொள்ளுங்கள்.)

ஹூக் என்பது கோரிக்கைப் பாதையில் உள்ள ஒரு புள்ளி; பொதுவாக ப்ராம்ப்ட் மாடலுக்குச் செல்வதற்கு முன் அல்லது பதில் திரும்பி வந்த பின், கேட்வே அந்த உள்ளடக்கத்தை ஒரு வெளிப்புற ஸ்கேனரிடம் தீர்ப்புக்காக ஒப்படைக்கும் இடம் இது. தடுக்கும் சரிபார்ப்பு (blocking check), டிராஃபிக்கைத் தொடர அனுமதிப்பதற்கு முன் அந்தத் தீர்ப்புக்காகக் காத்திருக்கிறது. 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 கிளையன்ட் லைப்ரரிகளை மீண்டும் பயன்படுத்தலாம்.
• விதிகள் இணைக்கப்பட்ட மெய்நிகர் கீகள்: ஒவ்வொரு குழுவுக்கும் தயாரிப்புக்கும் தனி கீ கிடைக்கிறது; அனுமதிக்கப்பட்ட மாடல்கள், கோரிக்கை வரம்புகள், செலவு ஆகியவற்றை நிர்வகிக்கும் விதிகள் அதனுடன் இணைந்திருக்கும்.
• ரூட்டிங் மற்றும் மாற்று வழி (fallback): உங்கள் அமைப்புகளின் அடிப்படையில் கேட்வே கோரிக்கைகளை மாடல்களுக்கு அனுப்புகிறது; அந்த அமைப்புகள் செலவு, வேகம் அல்லது ஒரு குறிப்பிட்ட வழங்குநருக்கு முன்னுரிமை அளிக்கலாம். ஒரு அழைப்பு தோல்வியடைந்தால், அது வேறொன்றை முயற்சிக்கலாம். Perplexity-இன் Agent API, வெவ்வேறு வழங்குநர்களின் மாடல்கள் உட்பட ஐந்து மாடல்கள் வரை நீங்கள் விரும்பும் வரிசையில் பட்டியலிட அனுமதிக்கிறது.
• கேச்சிங்: சேமிக்கப்பட்ட பதில் மற்றொரு வழங்குநர் அழைப்பைத் தவிர்க்க உதவும். சில கேட்வேகள் ஒரே மாதிரியான கோரிக்கைகளைப் பொருத்துகின்றன; மற்றவை ஒத்த பொருள் கொண்ட கோரிக்கைகளையும் பொருத்த முடியும். கேச் செய்யப்பட்ட பதில்களைப் பயனர் அல்லது குழு வாரியாகப் பிரிக்க முடியுமா என்பதையும், தனிப்பயனாக்கப்பட்ட அல்லது நேரம் சார்ந்த பதில்களுக்கு கேச்சிங்கை முடக்க முடியுமா என்பதையும் சரிபாருங்கள்.
• ஸ்ட்ரீமிங் மற்றும் சீரான பிழைகள்: பதில்கள் உருவாக்கப்படும்போதே வந்துசேர்கின்றன; வழங்குநர் பிழைகள் உங்கள் பயன்பாடு கையாளக்கூடிய வடிவத்துக்கு மொழிபெயர்க்கப்படுகின்றன. AI பாதுகாப்பு வரம்புகளைச் சேர்க்கும்போது என்ன நடக்கிறது என்பதைச் சரிபாருங்கள்.
• லாகிங் மற்றும் செலவு ஒதுக்கீடு: அழைப்பை யார் மேற்கொண்டார்கள், எந்த மாடல் அதைக் கையாண்டது, எத்தனை டோக்கன்களைப் பயன்படுத்தியது, எவ்வளவு நேரம் எடுத்தது, அதன் மதிப்பிடப்பட்ட செலவு ஆகியவற்றை கேட்வே பதிவுசெய்கிறது. பதிவுகளில் ப்ராம்ப்ட்களும் பதில்களும் உள்ளனவா, அவை எவ்வளவு காலம் வைத்திருக்கப்படுகின்றன என்பதைச் சரிபாருங்கள்.
• பாதுகாப்பு வரம்பு ஹூக்குகள்: இவை கோரிக்கைப் பாதையில், கேட்வே உள்ளடக்கத்தை ஒரு வெளிப்புற ஸ்கேனருக்குத் தீர்ப்புக்காக அனுப்பக்கூடிய புள்ளிகள். இவை பொதுவாக ஒரு மாடல் கோரிக்கைக்கு முன்போ அதன் பதிலுக்குப் பின்போ அமைந்திருக்கும். ஸ்கேனர் தோல்வியடையும்போது கோரிக்கைகள் நிற்கின்றனவா அல்லது தொடர்கின்றனவா என்பதையும், வேறொரு ஸ்கேனரை இணைக்க முடியுமா என்பதையும் சரிபாருங்கள்.
• நீங்கள் பூட்டிவைக்கக்கூடிய நிர்வாக இடைமுகம்: வழங்குநர் அங்கீகாரச் சான்றுகளுக்கான அணுகலையும், அனைவரும் பயன்படுத்தும் விதிகளையும் கேட்வே நிர்வகிக்கிறது. பயன்பாட்டு டிராஃபிக்கிலிருந்து தனியாக நிர்வாக அணுகலைக் கட்டுப்படுத்த முடியுமா என்பதையும், படிக்க மட்டுமேயான பயனர்களால் அமைப்புகளை மாற்ற முடியாது என்பதையும் சரிபாருங்கள். பிரதான வால்வுக்கு ஒரு பூட்டு தேவை.

உங்கள் LLM கேட்வேயை உருவாக்க எந்தக் கருவிகளைப் பயன்படுத்தலாம்?

சந்தை முழுவதும் அம்சப் பட்டியல்கள் ஒன்றுடன் ஒன்று ஒத்துப்போகின்றன. உள் மாடல் அணுகல் பற்றிய ஒரு Reddit த்ரெட்டில், பதிவிட்டவர் இப்படிக் கேட்டார்: எந்த கேட்வேக்கு ஒரு பிரத்யேகப் பொறியாளர் தேவைப்படாது?

எங்கள் கருத்தில் அதுதான் சரியான கேள்வி; நீங்கள் எவ்வளவு வேலையைப் பொறுப்பேற்கத் தயாராக இருக்கிறீர்கள் என்பதைப் பொறுத்து அதற்கு நான்கு பதில்கள் உள்ளன.

நீங்களே எழுதுங்கள்

குறைந்தபட்ச கேட்வே ஒரு சிறிய பணிப் பட்டியலைக் கையாள்கிறது—கோரிக்கைகளை ஏற்பது, அழைப்பவரின் கீயைச் சரிபார்ப்பது, வழங்குநர் அங்கீகாரச் சான்றைச் சேர்ப்பது, அழைப்பை முன்னனுப்புவது, முடிவைப் பதிவுசெய்வது. ஆனால் வெவ்வேறு வழங்குநர் வடிவங்களை ஆதரிப்பது வேலையை அதிகரிக்கிறது. முழு அமைப்பையும் இயக்கத்தில் வைத்திருப்பதும் அப்படியே.

நீங்கள் ஏற்கெனவே Envoy-ஐ இயக்கினால், அதன் external-processing வடிப்பான், கோரிக்கைகளையும் பதில்களையும் ஆய்வுசெய்து மாற்றும் ஒரு சேவையை இணைக்க உங்களை அனுமதிக்கிறது. இருப்பினும் அந்தச் சேவையை நீங்களே உருவாக்கி இயக்க வேண்டும்.

கேட்வே செலவுகளைக் குறைக்கிறதா என்பது பற்றிய r/LLMDevs த்ரெட்டில், ஒவ்வொரு அழைப்பிலும் டோக்கன்களையும் ஒரு cache-hit கொடியையும் பதிவுசெய்தது, ஒரே மாதிரியான ப்ராம்ப்ட்களுக்கு முழு விலையைச் செலுத்திக்கொண்டிருந்த இரண்டு ஜாப்களைக் கண்டறிய உதவியது என்று u/QuanTradin கூறினார்.

“...எந்த ரூட்டிங் அடுக்கும் தந்திருக்கக்கூடியதை விட, அதைச் சரிசெய்ததே அதிக மதிப்புடையதாக இருந்தது.”

இது ஒருவர் பகிர்ந்த அனுபவம், தொடங்குவதற்கு நல்ல இடமும் கூட. அதை ரூட்டிங் செய்வதற்கான விரிவான வழிகளை உருவாக்கும் முன், நீங்கள் எதற்காகப் பணம் செலுத்துகிறீர்கள் என்பதைக் கண்டறியுங்கள்.

திறந்த மூல கேட்வேயை நீங்களே ஹோஸ்ட் செய்யுங்கள்

இங்கு LiteLLM ஒரு பொதுவான தேர்வு: இது OpenAI-இணக்கமானது, பரந்த அளவிலான வழங்குநர்களை ஆதரிக்கிறது, பெரிய சமூகத்தையும் கொண்டுள்ளது. Bifrost ஒரு மாற்று; ஒவ்வொரு கோரிக்கைக்குமான கூடுதல் சுமை குறைவாக இருக்கும்படி உருவாக்கப்பட்டது. உங்கள் அம்சப் பட்டியலில் அப்சர்வபிலிட்டி முதலிடத்தில் இருந்தால், Helicone-ஐப் பார்க்கலாம்.

எந்தத் தயாரிப்பையும் போலவே, LiteLLM-க்கும் சில குழுக்களுக்கு வரம்புகள் உள்ளன. சொந்தமாக உருவாக்குவதற்கான மாற்றுகள் பற்றிய r/aiagents த்ரெட்டில், LiteLLM ரூட்டிங்கை நன்றாகக் கையாண்டது, ஆனால் குழுக்களுக்கு இடையிலான ப்ராம்ப்ட் பதிப்பாக்கம், மாடல்களை மாற்றும்போது தொடர் மதிப்பீடுகள் (evals) ஆகியவற்றில் தங்களுக்குப் போதவில்லை என்றும், அதனால் தனி கருவிக்கு மாற வேண்டியிருந்தது என்றும் u/Own_Bar_920 கூறினார்.

அவை அடிப்படை கேட்வே ரூட்டிங்கைத் தாண்டியவை, அதுதான் முக்கியம்—ரூட்டிங்தான் முக்கியத் தேவை என்றால், LiteLLM அவர்களுக்குச் சிறப்பாகச் செயல்பட்டது.

சில அம்சங்கள் பதிப்பைப் பொறுத்து அமைந்தாலும், தயாரான அம்சப் பட்டியல் உங்களுக்குக் கிடைக்கிறது; கேட்வேயை உங்கள் நெட்வொர்க்குக்குள்ளேயே வைத்திருக்கலாம். பேட்ச் செய்வதும் உங்கள் பொறுப்பே—முன்னர் குறிப்பிட்ட 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 கேட்வே உள்ளதா?

ஆம். Amazon Bedrock AgentCore Gateway, AWS “inference targets” (அனுமான இலக்குகள்) என்று அழைப்பவற்றின் மூலம் மாடல் அழைப்புகளை ஆதரிக்கிறது. Amazon Bedrock, OpenAI, Anthropic உள்ளிட்ட வழங்குநர்களை அணுக, பயன்பாடுகள் ஒரே எண்ட்பாயிண்டைப் பயன்படுத்த இவை உதவுகின்றன; வழங்குநர் நற்சான்றுகளையும் ரூட்டிங்கையும் கேட்வே கையாளுகிறது.