12 ചോദ്യങ്ങളുള്ള ഒരു പരീക്ഷണത്തിൽ, ഏഴ് സ്കീമകളുള്ള മോഡൽ കോൺടെക്സ്റ്റ് പ്രോട്ടോക്കോളിനേക്കാൾ (MCP) കൂടുതൽ ടോക്കണുകൾ ബാഷ് (Bash) റാപ്പറുകൾ ഉപയോഗിച്ചു. ഇത് പല എഞ്ചിനീയർമാരും കരുതുന്നതുപോലെ ഷെൽ (shell) ഒരു ലാഭകരമായ എളുപ്പവഴിയല്ലെന്ന് കാണിക്കുന്നു. വലിയ തോതിൽ പ്രവർത്തിക്കുന്ന ലാർജ് ലാംഗ്വേജ് മോഡൽ (LLM) ഏജന്റുകളെ സംബന്ധിച്ചിടത്തോളം ടോക്കൺ ഉപയോഗം നേരിട്ട് ചെലവായി മാറുന്നു.

കഥ മാറ്റിവരച്ച പരീക്ഷണം

ഒരു LLM ഏജന്റിന് വെസൽ (vessel) ഡാറ്റ ശേഖരിക്കാൻ കഴിയുന്ന നാല് രീതികൾ ഒരു ഡെവലപ്പർ അളന്നു:

  • MCP – മോഡൽ കോൺടെക്സ്റ്റ് പ്രോട്ടോക്കോളിന് പിന്നിൽ ഹോസ്റ്റ് ചെയ്തിട്ടുള്ള ഏഴ് ടൂൾ സ്കീമകൾ.
  • Bash + curl (cold) – അധിക പ്രോംപ്റ്റുകളില്ലാത്ത ഒരു റോ (raw) ഷെൽ കോൾ.
  • Bash + curl (warm) – സുരക്ഷിതമായ ഉപയോഗത്തിന് സഹായിക്കുന്ന സിസ്റ്റം പ്രോംപ്റ്റുകൾ ഉൾപ്പെടുത്തിയ അതേ ഷെൽ കോൾ.
  • Dedicated CLI tool – പ്രത്യേകമായി നിർമ്മിച്ച ഒരു കമാൻഡ്-ലൈൻ ഇന്റർഫേസ്.

ഇവ നാല് രീതികളും 12 ചോദ്യങ്ങളുള്ള ഒരു സംഭാഷണത്തിലൂടെ പരീക്ഷിച്ചു. API ബില്ലുകൾ നിർണ്ണയിക്കുന്ന ടോക്കൺ ഉപയോഗം താഴെ പറയുന്ന രീതിയിലായിരുന്നു:

  • MCP: 109,779 ടോക്കണുകൾ
  • Bash + curl (cold): 158,021 ടോക്കണുകൾ
  • Bash + curl (warm): 178,577 ടോക്കണുകൾ

ഡെഡിക്കേറ്റഡ് CLI ടൂളിന്റെ കണക്കുകൾ വെളിപ്പെടുത്തിയിട്ടില്ല, എങ്കിലും രണ്ട് ബാഷ് വേരിയന്റുകളും ഇതിനകം തന്നെ MCP-യേക്കാൾ കൂടുതൽ ചെലവ് വരുത്തിക്കഴിഞ്ഞു.

എന്തുകൊണ്ടാണ് പ്രോട്ടോക്കോളിനേക്കാൾ കൂടുതൽ ചെലവ് ഷെല്ലിന് വന്നത്?

ഓരോ ബാഷ് ടൂളിനും ഏകദേശം 2,700 ടോക്കണുകൾ വരുന്ന "ഹാർനസ് പ്രോംപ്റ്റുകൾ" (harness prompts) ആവശ്യമായിരുന്നു – അതായത് ഷെൽ എങ്ങനെ സുരക്ഷിതമായി ഉപയോഗിക്കണം, ഔട്ട്‌പുട്ട് എങ്ങനെ വിശകലനം ചെയ്യണം, പിശകുകൾ എങ്ങനെ കൈകാര്യം ചെയ്യണം എന്ന് ഏജന്റിന് നിർദ്ദേശിക്കുന്ന പ്രോംപ്റ്റുകൾ. ഈ പ്രോംപ്റ്റുകൾ മാത്രം ഏഴ് MCP സ്കീമകളുടെയും ആകെ ടോക്കൺ അളവിനേക്കാൾ കൂടുതലാണ്.

ചെലവ് എന്നത് ആദ്യത്തെ കോളിന് മാത്രം ഒതുങ്ങുന്നതല്ല. പ്രൊഡക്ഷനിൽ, അതേ ഏജന്റ് സ്റ്റാർട്ടപ്പിൽ തന്നെ 11 MCP സെർവറുകൾ പ്രീ-ലോഡ് ചെയ്യുന്നു, ഇത് ആദ്യത്തെ ഉപയോക്താവിന്റെ ചോദ്യം വരുന്നതിന് മുമ്പ് തന്നെ 19,800 ടോക്കണുകൾ ഉപയോഗിക്കുന്നു. പിന്നീട്, ഓരോ ഘട്ടത്തിലും (turn), ഏജന്റ് ഓരോ സെർവറിലെയും എല്ലാ സ്കീമകളും വീണ്ടും വായിക്കുന്നു, അതിനാൽ "ഇപ്പോൾ സമയം എത്രയാണ്?" എന്നതുപോലെയുള്ള ലളിതമായ ഒരു ചോദ്യത്തിന് പോലും മറ്റെല്ലാ ടൂൾ വിവരണങ്ങളുടെയും ടോക്കൺ വില നൽകേണ്ടി വരുന്നു.

ഈഗർ ലോഡിംഗിന്റെ (eager loading) മറഞ്ഞിരിക്കുന്ന നഷ്ടം

ഒരു LLM ഏജന്റ് ഓരോ ഘട്ടത്തിലും എല്ലാ ടൂൾ സെർവറുകളും ഈഗർ ലോഡ് (eagerly load) ചെയ്യുമ്പോൾ, ടോക്കൺ ബില്ല് ഗണ്യമായി വർദ്ധിക്കുന്നു. ബാഷ് ഉപയോഗിക്കുന്നതിന്റെ "യഥാർത്ഥ" ചെലവ് ഷെൽ കമാൻഡ് അല്ലെന്നും, മറിച്ച് ഓരോ തവണയും മോഡലിലേക്ക് കൈമാറേണ്ടി വരുന്ന ചുറ്റുമുള്ള കോൺടെക്സ്റ്റ് (context) ആണെന്നും പരീക്ഷണം കാണിച്ചുതരുന്നു.

  • സ്ഥിരമായ ചെലവുള്ള ടൂളുകൾ (MCP സ്കീമകൾ) ഓരോ ഘട്ടത്തിലും പ്രവചിക്കാവുന്ന ഒരു ടോക്കൺ അധികച്ചെലവ് ഉണ്ടാക്കുന്നു.
  • ഡൈനാമിക് പേലോഡുകൾ (curl റെസ്പോൺസുകൾ) സംഭാഷണത്തിന്റെ ദൈർഘ്യത്തിനും ഡാറ്റയുടെ വലുപ്പത്തിനും അനുസരിച്ച് വർദ്ധിക്കുന്ന ഒരു ബാധ്യത ഉണ്ടാക്കുന്നു.

അതിനാൽ, ഉപരിതലത്തിൽ "സൗജന്യമായി" തോന്നുന്ന ഒരു ഷെൽ യഥാർത്ഥത്തിൽ വലിയൊരു മാറിക്കൊണ്ടിരിക്കുന്ന ടോക്കൺ നികുതിയാണ് ചുമത്തുന്നത്.

AI എഞ്ചിനീയർമാർ ഇനി എന്തുചെയ്യണം?

  • ലേസി ലോഡിംഗ് (lazy loading) സ്വീകരിക്കുക. ഒരു ടൂൾ സ്കീം ആവശ്യമായി വരുമ്പോൾ മാത്രം ആ ടൂൾ സെർവർ ലോഡ് ചെയ്യുക, കൂടാതെ ഓരോ തവണയും വീണ്ടും വായിക്കുന്നതിന് പകരം അത് മെമ്മറിയിൽ സൂക്ഷിക്കുക.
  • ടൂൾ സ്കീമകളെ ഓരോ ഘട്ടത്തിലെയും സ്ഥിരമായ ചെലവായി കണക്കാക്കുക. ഷെൽ കമാൻഡുകൾ സൗജന്യമാണെന്ന് കരുതുന്നതിന് പകരം, MCP നിർവചനങ്ങളുടെ അറിയപ്പെടുന്ന വലുപ്പത്തെ അടിസ്ഥാനമാക്കി ടോക്കൺ ബജറ്റുകൾ ആസൂത്രണം ചെയ്യുക.
  • "ഷെൽ = ലാഭകരം" എന്ന അനുമാനങ്ങൾ പുനർവിചിന്തനം ചെയ്യുക. ഒരു ഡിസൈനിൽ ഉറച്ചുപോകുന്നതിന് മുമ്പ് ഓരോ ടൂൾ പാതയിലെയും ടോക്കൺ ഉപയോഗം പരിശോധിക്കുക.
  • ചെറിയ മോഡലുകൾക്കായി കൃത്യമായി രൂപപ്പെടുത്തിയ ടൂളുകൾ ഉപയോഗിക്കുക. പരിമിതമായ കോൺടെക്സ്റ്റ് വിൻഡോകൾ ആണെങ്കിൽ പോലും, കൃത്യമായി നിർവചിക്കപ്പെട്ട സ്കീമകൾ റീസണിംഗ് (reasoning), യൂണിറ്റ് കൺവേർഷൻ, എറർ ഹാൻഡ്‌ലിംഗ് എന്നിവ മെച്ചപ്പെടുത്തുന്നു.

ചുരുക്കത്തിൽ: പ്രോട്ടോക്കോൾ ഡിസൈനല്ല, മറിച്ച് ടോക്കൺ ഇക്കണോമിക്സാണ് ചെലവ് നിർണ്ണയിക്കുന്നത്. ടൂൾ സെർവറുകൾ എപ്പോൾ, എങ്ങനെ ലോഡ് ചെയ്യുന്നു എന്നത് നിയന്ത്രിക്കുന്നതിലൂടെ ഒരു സംഭാഷണത്തിൽ നിന്ന് പതിനായിരക്കണക്കിന് ടോക്കണുകൾ ലാഭിക്കാനും പ്രവർത്തന ചെലവ് നേരിട്ട് കുറയ്ക്കാനും കഴിയും.

സ്രോതസ്സ്: https://dev.to/clarkbw--/enabling-bash-costs-more-context-than-seven-mcp-tool-schemas-2h82