لوکل لارج لینگویج ماڈلز (local large language models) کو چلانا اکثر آپ کو ہارڈ ویئر کی حدود میں قید کر دیتا ہے۔ NVIDIA صارفین CUDA ecosystem کے اندر رہتے ہیں۔ Apple ڈویلپرز Metal کا انتخاب کرتے ہیں۔ باقی سب اس امید پر ہوتے ہیں کہ ان کا GPU OpenCL کو سپورٹ کرے گا یا پھر وہ صرف CPU پر ہی چل سکے گا۔ یہ تقسیم (fragmentation) ڈیسک ٹاپ AI ایپلی کیشنز کو لانچ کرنا اس سے کہیں زیادہ مشکل بنا دیتی ہے جتنا کہ ہونا چاہیے۔ TensorSharp نے ایک Vulkan backend شامل کر کے اس مسئلے کو حل کرنے کی طرف قدم بڑھایا ہے، جس سے انجن کو مختلف vendors کے discrete GPUs تک رسائی کا ایک قابل اعتماد راستہ مل گیا ہے۔
Vulkan مساوات کو کیسے بدلتا ہے
Vulkan پر عام طور پر گیمنگ حلقوں میں بحث کی جاتی ہے، لیکن ایک low-overhead، cross-platform compute API کے طور پر، یہ inference کے لیے بھی اتنا ہی اہم ہے۔ یہ اس ہارڈ ویئر تک پہنچتا ہے جسے CUDA نظر انداز کر دیتا ہے، جیسے Intel UHD اور Iris Xe integrated chips، پرانے discrete cards، اور بغیر NVIDIA sticker والے بجٹ Windows laptops۔ ایک local inference engine کے لیے، یہ رسائی عملی طاقت ہے۔ ایک ڈویلپر ایک ہی binary path فراہم کر سکتا ہے جو CUDA-only solution کے مقابلے میں کہیں زیادہ مشینوں پر کام کر سکتا ہے۔
TensorSharp کی Vulkan support کا آغاز GGML project کے ذریعے ہوا۔ یہ انٹیگریشن آج فعال ہے، اگرچہ مصنف کا منصوبہ بعد میں ایک native Vulkan backend بنانے کا ہے۔ GGML کو ایک پل (bridge) کے طور پر استعمال کرنا ایک درست مرحلہ تھا۔ یہ آرکیٹیکچر کی توثیق کرتا ہے اور فوری طور پر ٹیسٹرز کے ہاتھوں میں ہارڈ ویئر پہنچاتا ہے۔ abstraction overhead کو ختم کرنے اور C#-centric انجن کو command buffers اور memory barriers پر بہتر کنٹرول دینے کے لیے ایک native backend بعد میں پیش کیا جائے گا۔
اب تک ٹیسٹنگ کی صورتحال کیسی ہے
Validation پہلے ہی دو بہت مختلف Windows configurations کا احاطہ کر چکی ہے۔ ڈویلپر نے NVIDIA GeForce RTX 3080 Laptop GPU اور سادہ Intel UHD Graphics پر ٹیسٹ کیا ہے۔ دونوں نے اچھا کام کیا۔ اس رینج پر غور کرنا ضروری ہے۔ Inference کی دنیا میں، discrete high-wattage silicon اور بنیادی integrated graphics کا اس طرح آسانی سے ایک ہی ٹیسٹ سرفس پر ہونا کم ہی دیکھنے کو ملتا ہے۔ اگر آپ بغیر کسی dedicated GPU کے ہلکا پھلکا لیپ ٹاپ چلا رہے ہیں، تو TensorSharp اب ایک حقیقی acceleration path پیش کرتا ہے جو NVIDIA drivers پر منحصر نہیں ہے۔
اس میٹرکس میں کمی AMD کی ہے۔ ابھی تک کسی Radeon hardware کی ٹیسٹنگ نہیں کی گئی۔ اگر آپ کے پاس AMD GPU ہے، تو اس پروجیکٹ کو آپ کے فیڈ بیک کی ضرورت ہے۔ RX 6000 یا 7000 series کارڈز پر کمیونٹی کی توثیق ہی ایک تجرباتی backend کو production-grade آپشن میں بدلتی ہے۔ اگر یہ کام نہ کرے تو issue فائل کریں۔ اگر یہ بہترین کام کرے تو بھی فائل کریں۔ دونوں نتائج پروجیکٹ کو آگے بڑھاتے ہیں۔
TensorSharp کوئی Wrapper نہیں ہے
اس نکتے پر زور دینا ضروری ہے۔ TensorSharp، llama.cpp کے گرد کوئی C# binding نہیں ہے۔ ڈویلپر نے پورا انجن شروع سے بنایا ہے۔ CPU backend خالص C# ہے۔ جب آپ GPU کے بغیر inference چلاتے ہیں، تو آپ کسی foreign function interface کے ذریعے C++ binary میں منتقل ہونے کے بجائے managed code چلا رہے ہوتے ہیں۔ یہ پروجیکٹ CUDA، Apple کے MLX، اور GGML کے لیے مخصوص backends بھی برقرار رکھتا ہے۔ اس architectural independence کے باوجود، اس کی کارکردگی llama.cpp کے برابر ہے، جو کہ وہ ریفرنس پوائنٹ ہے جس کے پیچھے زیادہ تر local inference پروجیکٹس رہتے ہیں۔ یہ برابری مشکل سے حاصل کی گئی ہے۔ اس کا مطلب ہے کہ memory layout، kernel dispatch، اور tensor ops سب حقیقی لوڈ کے تحت برقرار رہتے ہیں۔
Model support میں Gemma4، DiffusionGemma، اور Qwen3.6 شامل ہیں۔ Runtime ملٹی موڈل (multimodal) کام بھی سنبھالتا ہے۔ Vision، audio، اور reasoning pipelines اسی انجن کے ذریعے چلتے ہیں۔ اگر آپ ایک ایسے ڈیسک ٹاپ اسسٹنٹ کا پروٹو ٹائپ بنا رہے ہیں جو اسکرین شاٹس پڑھتا ہے اور آواز کے ذریعے کمانڈز قبول کرتا ہے، تو آپ کو تین الگ الگ runtimes کو جوڑنے اور یہ دعا کرنے کی ضرورت نہیں ہے کہ ان کا memory footprint آپ کی مشین میں سما جائے۔
پلیٹ فارم اور API کی لچک
TensorSharp Windows، macOS، اور Linux پر چلتا ہے۔ نیا Vulkan backend موجودہ CUDA اور Metal paths کے ساتھ اس میٹرکس میں آسانی سے فٹ ہو جاتا ہے۔ انجن OpenAI اور Ollama APIs کے ساتھ مطابقت (compatibility) بھی فراہم کرتا ہے۔ یہ انتخاب انٹیگریشن کی رکاوٹوں کو ختم کرتا ہے۔ آپ پرامپٹ ٹیمپلیٹس (prompt templates) کو دوبارہ لکھنے یا نئے response shape کو پارس کرنے کے بغیر موجودہ کلائنٹ کوڈ کو مقامی TensorSharp سرور کی طرف موڑ سکتے ہیں۔ ان ٹیموں کے لیے جو پہلے سے اندرونی طور پر Ollama چلا رہی ہیں یا OpenAI کے REST surface کے لیے کام کر رہی ہیں، مقامی TensorSharp instance پر منتقل ہونا محض ایک base URL تبدیل کرنے کا معاملہ ہے۔
ادھار لیے گئے optimizations جو کام کرتے ہیں
کارکردگی صرف اس بارے میں نہیں ہے کہ کون سا API GPU سے بات کرتا ہے۔ TensorSharp کئی ایسے optimizations کو ضم کرتا ہے جو دوسری جگہوں پر پروڈکشن میں ثابت شدہ ہیں۔
vLLM سے لیا گیا Paged KV cache، طویل گفتگو کے دوران میموری کو بے قابو ہونے سے روکتا ہے۔ ہر sequence کے لیے ایک مسلسل (contiguous) scratchpad رکھنے کے بجائے، انجن مقررہ سائز کے pages مختص کرتا ہے اور انہیں ضرورت کے مطابق میپ کرتا ہے۔ آپ RAM کے استعمال میں اچانک اضافے کی فکر کیے بغیر context windows کو زیادہ دیر تک کھلا رکھ سکتے ہیں۔
Continuous batching، جو vLLM سے بھی لی گئی ہے، throughput کو بہتر بناتی ہے۔ انجن موجودہ گروپ کے مکمل ہونے کا انتظار کرنے کے بجائے نئے requests کو فعال batches میں شامل کر سکتا ہے۔ اگر ایک صارف کا prompt دس tokens کا ہے اور دوسرے کا دو سو کا، تو hardware زیادہ مصروف رہتا ہے اور اوسط latency کم ہو جاتی ہے۔
Mixture-of-Experts ماڈلز کے لیے، TensorSharp میں oMLX سے ماخوذ ایک SSD-based cache strategy نافذ کی گئی ہے۔ بار بار استعمال ہونے والے expert weights سسٹم RAM کے لیے مقابلہ کرنے کے بجائے تیز رفتار اسٹوریج پر تیار رہتے ہیں۔ محدود میموری لیکن بہتر NVMe drives والی مشینوں پر، یہ MoE architectures کو قابلِ استعمال رکھتا ہے۔
Quantization، llama.cpp کے ذریعے قائم کردہ GGUF standard کی پیروی کرتی ہے۔ آپ کے quantized 4-bit اور 5-bit ماڈلز بغیر کسی conversion step کے براہ راست لوڈ ہو جاتے ہیں۔
اصل نچوڑ
Vulkan support TensorSharp کو ایک دلچسپ C# تجربے سے بدل کر heterogeneous hardware کے لیے ایک عملی inference option بنا دیتی ہے۔ Roadmap واضح ہے: AMD اور Intel discrete silicon پر اس کی تصدیق کریں، پھر ایک native Vulkan backend کے ساتھ اس کے نفاذ کو مزید بہتر بنائیں۔ اگر آپ کے workstation یا laptop میں AMD card ہے، تو build چلائیں اور اپنے نتائج شیئر کریں۔ یہی feedback loop تجرباتی کوڈ کو ایک ایسی چیز میں تبدیل کرتا ہے جسے آپ ship کر سکیں۔
آپ release details ڈویلپر کی تحریر میں دیکھ سکتے ہیں۔ اگر یہ پروجیکٹ آپ کو CUDA toolkits کے چکروں یا macOS version locks سے بچاتا ہے، تو repository پر ایک star دیں۔ جاری بحث اور community testing threads کے لیے، Telegram group کھلا ہے۔