Running local large language models often forces you into a hardware corner. NVIDIA users live inside the CUDA ecosystem

ലോക്കൽ ലാർജ് ലാംഗ്വേജ് മോഡലുകൾ (LLMs) പ്രവർത്തിപ്പിക്കുന്നത് പലപ്പോഴും നിങ്ങളെ ഹാർഡ്‌വെയർ പരിമിതികളിലേക്ക് തള്ളിവിടാറുണ്ട്. NVIDIA ഉപയോക്താക്കൾ CUDA ഇക്കോസിസ്റ്റത്തിന് ഉള്ളിലാണ് പ്രവർത്തിക്കുന്നത്. Apple ഡെവലപ്പർമാർ Metal ഉപയോഗിക്കുന്നു. മറ്റുള്ളവർ തങ്ങളുടെ GPU OpenCL പിന്തുണയ്ക്കുന്നു എന്ന് പ്രതീക്ഷിക്കുന്നു അല്ലെങ്കിൽ സിപിയുവിനെ (CPU) ആശ്രയിക്കുന്നു. ഈ വിഭജനം ഒരു ഡെസ്ക്ടോപ്പ് AI ആപ്ലിക്കേഷൻ വികസിപ്പിക്കുന്നത് അനാവശ്യമായി പ്രയാസകരമാക്കുന്നു. വ്യത്യസ്ത വെണ്ടർമാരുടെ ഡിസ്ക്രീറ്റ് GPU-കളിലൂടെ പ്രവർത്തിക്കാൻ സാധിക്കുന്ന ഒരു വിശ്വസനീയമായ പാത ഒരുക്കിക്കൊണ്ട്, ഒരു Vulkan backend ചേർത്ത് TensorSharp ഈ പ്രശ്നത്തിന് പരിഹാരം കാണുന്നു.

എന്തുകൊണ്ടാണ് Vulkan ഈ സാഹചര്യം മാറ്റുന്നത്?

Vulkan സാധാരണയായി ഗെയിമിംഗ് രംഗത്താണ് ചർച്ച ചെയ്യപ്പെടാറുള്ളത്, എന്നാൽ കുറഞ്ഞ ഓവർഹെഡ് ഉള്ള ഒരു ക്രോസ്-പ്ലാറ്റ്‌ഫോം കമ്പ്യൂട്ട് API എന്ന നിലയിൽ, ഇൻഫറൻസിനും (inference) ഇത് ഒരുപോലെ പ്രധാനമാണ്. CUDA അവഗണിക്കുന്ന ഹാർഡ്‌വെയറുകളിലേക്ക് ഇത് എത്തുന്നു. Intel UHD, Iris Xe ഇന്റഗ്രേറ്റഡ് ചിപ്പുകൾ, പഴയ ഡിസ്ക്രീറ്റ് കാർഡുകൾ, NVIDIA സ്റ്റിക്കറില്ലാത്ത ബജറ്റ് വിൻഡോസ് ലാപ്ടോപ്പുകൾ എന്നിവ ഇതിൽ ഉൾപ്പെടുന്നു. ഒരു ലോക്കൽ ഇൻഫറൻസ് എഞ്ചിനെ സംബന്ധിച്ചിടത്തോളം, ഈ വ്യാപ്തി വലിയൊരു കരുത്താണ്. ഒരു CUDA-അധിഷ്ഠിത പരിഹാരത്തേക്കാൾ എത്രയോ കൂടുതൽ മെഷീനുകളിൽ പ്രവർത്തിക്കുന്ന രീതിയിൽ ഒരു സിംഗിൾ ബൈനറി പാത്ത് ഡെവലപ്പർക്ക് നൽകാൻ സാധിക്കും.

TensorSharp-ന്റെ Vulkan സപ്പോർട്ട് GGML പ്രോജക്റ്റിലൂടെയാണ് അവതരിപ്പിച്ചത്. ഈ ഇന്റഗ്രേഷൻ ഇപ്പോൾ പ്രവർത്തനക്ഷമമാണ്, എങ്കിലും പിന്നീട് ഒരു നേറ്റീവ് Vulkan backend നിർമ്മിക്കാൻ ഡെവലപ്പർ പദ്ധതിയിടുന്നുണ്ട്. GGML ഒരു പാലമായി ഉപയോഗിച്ചത് ശരിയായ ഒരു നീക്കമായിരുന്നു. ഇത് ആർക്കിടെക്ചർ പരിശോധിക്കാനും ടെസ്റ്റർമാരുടെ കൈകളിലേക്ക് ഉടൻ തന്നെ ഹാർഡ്‌വെയർ എത്തിക്കാനും സഹായിക്കുന്നു. അബ്സ്ട്രാക്ഷൻ ഓവർഹെഡ് കുറയ്ക്കാനും C#-കേന്ദ്രീകൃതമായ എഞ്ചിന് കമാൻഡ് ബഫറുകൾക്കും മെമ്മറി ബാരിയറുകൾക്കും മേൽ കൂടുതൽ നിയന്ത്രണം നൽകാനും ഒരു നേറ്റീവ് ബാക്കെൻഡ് പിന്നീട് വരും.

ഇതുവരെയുള്ള ടെസ്റ്റിംഗ് ഫലങ്ങൾ എന്തൊക്കെയാണ്?

രണ്ട് വ്യത്യസ്ത വിൻഡോസ് കോൺഫിഗറേഷനുകളിൽ ഇതിനോടകം തന്നെ പരിശോധനകൾ പൂർത്തിയായിട്ടുണ്ട്. ഡെവലപ്പർ ഒരു NVIDIA GeForce RTX 3080 ലാപ്ടോപ്പ് GPU-യിലും സാധാരണ Intel UHD ഗ്രാഫിക്സിലും ഇത് പരീക്ഷിച്ചു. രണ്ടും മികച്ച രീതിയിൽ പ്രവർത്തിച്ചു. ഈ വ്യത്യാസം ശ്രദ്ധേയമാണ്. ഇൻഫറൻസ് ലോകത്ത്, ഉയർന്ന വാട്ടേജ് ഉപയോഗിക്കുന്ന ഡിസ്ക്രീറ്റ് സിലിക്കണും അടിസ്ഥാനപരമായ ഇന്റഗ്രേറ്റഡ് ഗ്രാഫിക്സും ഇത്ര എളുപ്പത്തിൽ ഒരേപോലെ പ്രവർത്തിക്കുന്നത് അപൂർവ്വമാണ്. ഒരു ഡെഡിക്കേറ്റഡ് GPU ഇല്ലാത്ത ലഘുവായ ലാപ്ടോപ്പാണ് നിങ്ങൾ ഉപയോഗിക്കുന്നതെങ്കിൽ, NVIDIA ഡ്രൈവറുകളെ ആശ്രയിക്കാതെ പ്രവർത്തിക്കാൻ TensorSharp ഇപ്പോൾ ഒരു വേഗതയേറിയ മാർഗ്ഗം വാഗ്ദാനം ചെയ്യുന്നു.

ഇതിൽ വിട്ടുപോയത് AMD ആണ്. ഇതുവരെ ഒരു Radeon ഹാർഡ്‌വെയറും പരീക്ഷിച്ചിട്ടില്ല. നിങ്ങൾ ഒരു AMD GPU ഉപയോഗിക്കുന്ന ആളാണെങ്കിൽ, ഈ പ്രോജക്റ്റിന് നിങ്ങളുടെ ഫീഡ്‌ബാക്ക് ആവശ്യമാണ്. RX 6000 അല്ലെങ്കിൽ 7000 സീരീസ് കാർഡുകളിൽ കമ്മ്യൂണിറ്റി നടത്തുന്ന പരിശോധനകളാണ് ഒരു പരീക്ഷണാടിസ്ഥാനത്തിലുള്ള ബാക്കെൻഡിനെ പ്രൊഡക്ഷൻ ഗ്രേഡ് ഓപ്ഷനായി മാറ്റുന്നത്. ഇത് പ്രവർത്തിക്കുന്നില്ലെങ്കിൽ ഒരു ഇഷ്യൂ (issue) ഫയൽ ചെയ്യുക, നന്നായി പ്രവർത്തിക്കുന്നുണ്ടെങ്കിൽ അതും അറിയിക്കുക. ഏത് ഫലവും പ്രോജക്റ്റിനെ മുന്നോട്ട് നയിക്കും.

TensorSharp ഒരു റാപ്പർ (Wrapper) അല്ല

ഈ കാര്യം പ്രത്യേകം ശ്രദ്ധിക്കേണ്ടതാണ്. TensorSharp എന്നത് llama.cpp-ക്ക് ചുറ്റുമുള്ള ഒരു C# ബൈൻഡിംഗ് അല്ല. ഡെവലപ്പർ ഈ എഞ്ചിൻ പൂർണ്ണമായും പൂജ്യത്തിൽ നിന്ന് നിർമ്മിച്ചതാണ്. ഇതിന്റെ CPU ബാക്കെൻഡ് പൂർണ്ണമായും C# ആണ്. ഒരു GPU ഇല്ലാതെ നിങ്ങൾ ഇൻഫറൻസ് നടത്തുമ്പോൾ, ഒരു C++ ബൈനറിയിലേക്ക് ഫോറിൻ ഫംഗ്ഷൻ ഇന്റർഫേസ് (FFI) വഴി മാറ്റുന്നതിന് പകരം നിങ്ങൾ മാനേജ്ഡ് കോഡ് (managed code) ആണ് പ്രവർത്തിപ്പിക്കുന്നത്. CUDA, Apple-ന്റെ MLX, GGML എന്നിവയ്ക്കായി ഈ പ്രോജക്റ്റ് പ്രത്യേക ബാക്കെൻഡുകൾ നിലനിർത്തുന്നുണ്ട്. ഈ ആർക്കിടെക്ചറൽ സ്വതന്ത്ര്യമുണ്ടെങ്കിലും, പ്രകടനം llama.cpp-ക്ക് തുല്യമാണ്. മിക്ക ലോക്കൽ ഇൻഫറൻസ് പ്രോജക്റ്റുകളും ലക്ഷ്യമിടുന്ന റെഫറൻസ് പോയിന്റ് llama.cpp ആണ്. ഈ തുല്യത കൈവരിക്കുക എന്നത് പ്രയാസകരമായ കാര്യമാണ്. ഇതിനർത്ഥം മെമ്മറി ലേഔട്ട്, കർണൽ ഡിസ്പാച്ച്, ടെൻസർ ഓപ്‌സ് എന്നിവയെല്ലാം യഥാർത്ഥ ലോഡിൽ മികച്ച രീതിയിൽ പ്രവർത്തിക്കുന്നു എന്നാണ്.

Gemma4, DiffusionGemma, Qwen3.6 എന്നിവയ്ക്കുള്ള മോഡൽ സപ്പോർട്ട് ഇതിലുണ്ട്. റൺടൈം മൾട്ടിമോഡൽ ജോലികളും കൈകാര്യം ചെയ്യുന്നു. വിഷൻ, ഓഡിയോ, റീസണിംഗ് പൈപ്പ്‌ലൈനുകൾ ഒരേ എഞ്ചിനിലൂടെയാണ് പ്രവർത്തിക്കുന്നത്. സ്ക്രീൻഷോട്ടുകൾ വായിക്കുകയും വോയ്‌സ് കമാൻഡുകൾ സ്വീകരിക്കുകയും ചെയ്യുന്ന ഒരു ഡെസ്ക്ടോപ്പ് അസിസ്റ്റന്റ് നിർമ്മിക്കുകയാണെങ്കിൽ, മൂന്ന് വ്യത്യസ്ത റൺടൈമുകൾ കൂട്ടിച്ചേർത്ത് അവയുടെ മെമ്മറി ഉപയോഗം നിങ്ങളുടെ മെഷീനിൽ ഒതുങ്ങുമോ എന്ന് ആശങ്കപ്പെടേണ്ടതില്ല.

പ്ലാറ്റ്‌ഫോം, API വഴക്കം

TensorSharp വിൻഡോസ്, macOS, ലിനക്സ് എന്നിവയിൽ പ്രവർത്തിക്കുന്നു. നിലവിലുള്ള CUDA, Metal പാതകൾക്കൊപ്പം പുതിയ Vulkan ബാക്കെൻഡും ഇതിൽ കൃത്യമായി ചേർന്നുനിൽക്കുന്നു. OpenAI, Ollama API എന്നിവയുമായുള്ള പൊരുത്തവും ഈ എഞ്ചിൻ ഉറപ്പാക്കുന്നു. ഇത് ഇന്റഗ്രേഷൻ എളുപ്പമാക്കുന്നു. പ്രോംപ്റ്റ് ടെംപ്ലേറ്റുകൾ മാറ്റുകയോ പുതിയ റെസ്പോൺസ് ഫോർമാറ്റ് പഠിക്കുകയോ ചെയ്യാതെ തന്നെ നിലവിലുള്ള ക്ലയന്റ് കോഡ് ഒരു ലോക്കൽ TensorSharp സെർവറിലേക്ക് തിരിച്ചുവിടാൻ നിങ്ങൾക്ക് സാധിക്കും. നിലവിൽ Ollama ഉപയോഗിക്കുന്നതോ അല്ലെങ്കിൽ OpenAI-യുടെ REST സർവീസ് ഉപയോഗിച്ച് നിർമ്മിക്കുന്നതോ ആയ ടീമുകൾക്ക്, ഒരു ബേസ് URL മാറ്റുന്നതിലൂടെ എളുപ്പത്തിൽ ലോക്കൽ TensorSharp-ലേക്ക് മാറാൻ സാധിക്കും.

ഫലപ്രദമായ മറ്റ് ഒപ്റ്റിമൈസേഷനുകൾ

പ്രകടനം എന്നത് ഏത് API ആണ് GPU-യുമായി സംസാരിക്കുന്നത് എന്നതിനെക്കുറിച്ച് മാത്രമല്ല. മറ്റ് പ്രൊഡക്ഷൻ സാഹചര്യങ്ങളിൽ തെളിയിക്കപ്പെട്ട പല ഒപ്റ്റിമൈസേഷനുകളും TensorSharp ഉൾപ്പെടുത്തിയിട്ടുണ്ട്.

vLLM-ൽ നിന്ന് കടമെടുത്ത Paged KV cache, ദൈർഘ്യമേറിയ സംഭാഷണങ്ങൾക്കിടയിൽ മെമ്മറി അമിതമായി വർദ്ധിക്കുന്നത് തടയുന്നു. ഓരോ സീക്വൻസിനും ഒരു വലിയ മെമ്മറി ഭാഗം മാറ്റിവയ്ക്കുന്നതിന് പകരം, എഞ്ചിൻ നിശ്ചിത വലുപ്പമുള്ള പേജുകൾ അനുവദിക്കുകയും അവ ആവശ്യാനുസരണം മാപ്പ് ചെയ്യുകയും ചെയ്യുന്നു. ഇതിലൂടെ RAM ഉപയോഗം പെട്ടെന്ന് കൂടുന്നത് ശ്രദ്ധിക്കാതെ തന്നെ നിങ്ങൾക്ക് കൂടുതൽ സമയം കോൺടെക്സ്റ്റ് വിൻഡോകൾ തുറന്നുപിടിക്കാൻ കഴിയും.

vLLM-ൽ നിന്നുള്ള continuous batching രീതി throughput വർദ്ധിപ്പിക്കുന്നു. നിലവിലെ ഗ്രൂപ്പ് അവസാനിക്കാനായി കാത്തുനിൽക്കുന്നതിന് പകരം പുതിയ റിക്വസ്റ്റുകൾ ആക്റ്റീവ് ബാച്ചുകളിലേക്ക് ഉൾപ്പെടുത്താൻ എഞ്ചിന് സാധിക്കും. ഒരു ഉപയോക്താവിന്റെ പ്രോംപ്റ്റ് പത്ത് ടോക്കണുകളും മറ്റൊരാളുടേത് ഇരുന്നൂറ് ടോക്കണുകളും ആണെങ്കിൽ, ഹാർഡ്‌വെയർ കൂടുതൽ കാര്യക്ഷമമായി ഉപയോഗിക്കാനും ശരാശരി ലേറ്റൻസി (latency) കുറയ്ക്കാനും ഇത് സഹായിക്കുന്നു.

Mixture-of-Experts മോഡലുകൾക്കായി, oMLX-ൽ നിന്നുള്ള ഒരു SSD അധിഷ്ഠിത കാഷെ സ്ട്രാറ്റജി TensorSharp നടപ്പിലാക്കുന്നു. ഇടയ്ക്കിടെ ഉപയോഗിക്കുന്ന എക്സ്പെർട്ട് വെയ്റ്റുകൾ (expert weights) സിസ്റ്റം RAM-നായി മത്സരിക്കുന്നതിന് പകരം വേഗതയേറിയ സ്റ്റോറേജിൽ തയ്യാറായിരിക്കും. പരിമിതമായ മെമ്മറിയും എന്നാൽ നല്ല NVMe ഡ്രൈവുകളുമുള്ള മെഷീനുകളിൽ, ഇത് MoE ആർക്കിടെക്ചറുകൾ ഉപയോഗപ്രദമായി നിലനിർത്തുന്നു.

Quantization, llama.cpp നിശ്ചയിച്ചിട്ടുള്ള GGUF സ്റ്റാൻഡേർഡ് പിന്തുടരുന്നു. നിങ്ങളുടെ ക്വാണ്ടൈസ് ചെയ്ത 4-bit, 5-bit മോഡലുകൾ ഒരു കൺവേർഷൻ ഘട്ടവും കൂടാതെ നേരിട്ട് ലോഡ് ചെയ്യാം.

പ്രധാനമായ കാര്യം

Vulkan സപ്പോർട്ട് TensorSharp-നെ ഒരു രസകരമായ C# പരീക്ഷണത്തിൽ നിന്ന് വൈവിധ്യമാർന്ന ഹാർഡ്‌വെയറുകൾക്കായി (heterogeneous hardware) പ്രായോഗികമായ ഒരു ഇൻഫറൻസ് ഓപ്ഷനായി മാറ്റുന്നു. ഇതിന്റെ റോഡ്മാപ്പ് വ്യക്തമാണ്: AMD, Intel ഡിസ്ക്രീറ്റ് സിലിക്കണുകളിൽ ഇത് പരിശോധിക്കുക, തുടർന്ന് ഒരു നേറ്റീവ് Vulkan ബാക്കെൻഡ് ഉപയോഗിച്ച് ഇതിന്റെ പ്രവർത്തനം കൂടുതൽ മെച്ചപ്പെടുത്തുക. നിങ്ങളുടെ വർക്ക്സ്റ്റാറിലോ ലാപ്ടോപ്പിലോ ഒരു AMD കാർഡ് ഉണ്ടെങ്കിൽ, ഈ ബിൽഡ് റൺ ചെയ്ത് നിങ്ങളുടെ ഫലങ്ങൾ പങ്കുവെക്കുക. പരീക്ഷണാടിസ്ഥാനത്തിലുള്ള കോഡുകളെ വിശ്വസനീയമായ ഉൽപ്പന്നങ്ങളാക്കി മാറ്റുന്നത് ഇത്തരം ഫീഡ്‌ബാക്കുകളാണ്.

റിലീസ് വിവരങ്ങൾ ഡെവലപ്പറുടെ കുറിപ്പിൽ കാണാം. CUDA ടൂൾകിറ്റുകൾ കൈകാര്യം ചെയ്യുന്നതിനോ macOS വേർഷൻ ലോക്കുകളുമായി പൊരുതുന്നതിനോ ഉള്ള ബുദ്ധിമുട്ടുകളിൽ നിന്ന് ഈ പ്രോജക്റ്റ് നിങ്ങളെ രക്ഷിക്കുന്നുണ്ടെങ്കിൽ, റെപ്പോസിറ്ററിയിൽ (repository) ഒരു സ്റ്റാർ നൽകുക. തുടർച്ചയായ ചർച്ചകൾക്കും കമ്മ്യൂണിറ്റി ടെസ്റ്റിംഗിനുമായി ടെലിഗ്രാം ഗ്രൂപ്പ് സജീവമാണ്.