การรัน Large Language Models (LLM) แบบ local มักจะทำให้คุณติดอยู่ในข้อจำกัดด้านฮาร์ดแวร์ ผู้ใช้ NVIDIA ต้องอยู่ภายใต้ระบบนิเวศของ CUDA นักพัฒนาฝั่ง Apple ก็ใช้ Metal ส่วนคนอื่นๆ ก็ได้แต่หวังว่า GPU ของตนจะรองรับ OpenCL หรือไม่ก็ต้องถอยกลับไปใช้ CPU แทน ความแตกแยกของมาตรฐานเหล่านี้ทำให้การพัฒนาแอปพลิเคชัน AI บนเดสก์ท็อปนั้นยากกว่าที่ควรจะเป็น TensorSharp เพิ่งจะเริ่มแก้ปัญหานี้ด้วยการเพิ่ม Vulkan backend ซึ่งช่วยให้ engine มีเส้นทางที่ใช้งานได้จริงในการทำงานข้าม discrete GPU จากผู้ผลิตรายต่างๆ

Why Vulkan Changes the Equation

ปกติแล้ว Vulkan มักจะถูกพูดถึงในวงการเกม แต่ในฐานะ compute API แบบ cross-platform ที่มี overhead ต่ำ มันมีความสำคัญไม่แพ้กันสำหรับการทำ inference มันเข้าถึงฮาร์ดแวร์ที่ CUDA มองข้าม เช่น ชิปแบบ integrated อย่าง Intel UHD และ Iris Xe, การ์ดจอ discrete รุ่นเก่า หรือแม้แต่โน้ตบุ๊ก Windows ราคาประหยัดที่ไม่มีสติกเกอร์ NVIDIA ติดอยู่ สำหรับ local inference engine การเข้าถึงฮาร์ดแวร์ได้กว้างขวางเช่นนี้คือพลังที่ใช้งานได้จริง นักพัฒนาสามารถส่งมอบไฟล์ binary เพียงชุดเดียวที่สามารถทำงานบนเครื่องคอมพิวเตอร์ได้หลากหลายกว่าโซลูชันที่รองรับแค่ CUDA มากนัก

การรองรับ Vulkan ของ TensorSharp เปิดตัวผ่านโปรเจกต์ GGML การรวมระบบนี้สามารถใช้งานได้แล้วในปัจจุบัน แม้ว่าผู้พัฒนาจะมีแผนที่จะสร้าง native Vulkan backend ในภายหลังก็ตาม การใช้ GGML เป็นสะพานเชื่อมถือเป็นก้าวเตรียมการที่ถูกต้อง มันช่วยพิสูจน์สถาปัตยกรรมและทำให้ผู้ทดสอบสามารถเข้าถึงฮาร์ดแวร์ได้ทันที โดยจะมี native backend ตามมาเพื่อลด abstraction overhead และช่วยให้ engine ที่เน้น C# สามารถควบคุม command buffers และ memory barriers ได้ละเอียดขึ้น

What the Testing Surface Looks Like So Far

การตรวจสอบความถูกต้องครอบคลุมการตั้งค่า Windows ที่แตกต่างกันอย่างสิ้นเชิงสองรูปแบบแล้ว ผู้พัฒนาได้ทดสอบบน NVIDIA GeForce RTX 3080 Laptop GPU และบน Intel UHD Graphics ธรรมดา ซึ่งทั้งคู่ทำงานได้ดี ช่วงความหลากหลายนี้เป็นสิ่งที่น่าสังเกต เพราะในโลกของการทำ inference นั้น การที่ discrete GPU ประสิทธิภาพสูงและ integrated graphics พื้นฐานจะสามารถทำงานร่วมกันได้อย่างราบรื่นในขอบเขตการทดสอบเดียวกันนั้นเป็นเรื่องที่เกิดขึ้นได้ยาก หากคุณใช้โน้ตบุ๊กน้ำหนักเบาที่ไม่มี GPU แยก TensorSharp ก็มีเส้นทางการเร่งความเร็วที่ใช้งานได้จริงโดยไม่ต้องพึ่งพาไดรเวอร์ของ NVIDIA

ช่องว่างที่ยังขาดหายไปคือ AMD ยังไม่มีฮาร์ดแวร์ Radeon ตัวไหนที่ได้รับการทดสอบ หากคุณมี GPU ของ AMD โปรเจกต์นี้ต้องการคำแนะนำจากคุณ การตรวจสอบจากชุมชนบนการ์ดซีรีส์ RX 6000 หรือ 7000 คือสิ่งที่จะเปลี่ยน backend เชิงทดลองให้กลายเป็นตัวเลือกในระดับ production หากพบปัญหาให้แจ้ง issue หากมันทำงานได้ยอดเยี่ยมก็แจ้งมาเช่นกัน ไม่ว่าผลลัพธ์จะเป็นอย่างไร มันจะช่วยขับเคลื่อนโปรเจกต์ต่อไป

TensorSharp Is Not a Wrapper

ประเด็นนี้ควรค่าแก่การเน้นย้ำ TensorSharp ไม่ใช่แค่ C# binding ที่หุ้ม llama.cpp ไว้ ผู้พัฒนาสร้าง engine ทั้งหมดขึ้นมาใหม่ตั้งแต่ต้น CPU backend เป็นภาษา C# แท้ๆ เมื่อคุณรัน inference โดยไม่มี GPU คุณกำลังรัน managed code แทนที่จะเป็นการส่งผ่านข้อมูล (marshaling) ผ่าน foreign function interface เข้าไปยัง binary ของ C++ โปรเจกต์นี้ยังคงรักษา backend เฉพาะสำหรับ CUDA, Apple’s MLX และ GGML ไว้ด้วย แม้จะมีความเป็นอิสระทางสถาปัตยกรรม แต่ประสิทธิภาพก็เทียบเท่ากับ llama.cpp ซึ่งยังคงเป็นจุดอ้างอิงที่โปรเจกต์ local inference ส่วนใหญ่พยายามไล่ตาม ความเท่าเทียมนี้ได้มาอย่างยากลำบาก ซึ่งหมายความว่า memory layout, kernel dispatch และ tensor ops ทั้งหมดสามารถทำงานได้อย่างมั่นคงภายใต้ภาระงานจริง

การรองรับโมเดลครอบคลุมถึง Gemma4, DiffusionGemma และ Qwen3.6 runtime ยังรองรับงานแบบ multimodal โดยที่ pipeline สำหรับ vision, audio และ reasoning จะทำงานผ่าน engine เดียวกัน หากคุณกำลังทำต้นแบบผู้ช่วยบนเดสก์ท็อปที่สามารถอ่านภาพหน้าจอและรับคำสั่งเสียงได้ คุณไม่จำเป็นต้องนำ runtime สามตัวที่แยกกันมาเย็บรวมกันแล้วภาวนาให้การใช้หน่วยความจำของพวกมันไม่เกินขีดจำกัดของเครื่อง

Platform and API Flexibility

TensorSharp ทำงานบน Windows, macOS และ Linux Vulkan backend ใหม่นี้สามารถเข้ากับระบบเดิมได้อย่างลงตัวเคียงคู่ไปกับเส้นทาง CUDA และ Metal ที่มีอยู่แล้ว engine ยังรองรับการทำงานร่วมกับทั้ง OpenAI และ Ollama APIs ทางเลือกนี้ช่วยลดความยุ่งยากในการรวมระบบ คุณสามารถชี้โค้ดฝั่ง client ที่มีอยู่ไปยัง local TensorSharp server ได้โดยไม่ต้องเขียน prompt templates ใหม่ หรือต้องมานั่งแกะรูปแบบการตอบกลับ (response shape) แบบใหม่ สำหรับทีมที่รัน Ollama ภายในอยู่แล้ว หรือกำลังพัฒนาบน OpenAI’s REST surface การเปลี่ยนมาใช้ local TensorSharp instance ก็เป็นเพียงแค่การเปลี่ยน base URL เท่านั้น

Borrowed Optimizations That Work

ประสิทธิภาพไม่ได้ขึ้นอยู่กับว่า API ไหนคุยกับ GPU เท่านั้น TensorSharp ยังได้รวมการเพิ่มประสิทธิภาพ (optimizations) หลายอย่างที่ได้รับการพิสูจน์แล้วในการใช้งานจริงที่อื่นมาด้วย

Paged KV cache ซึ่งหยิบยืมมาจาก vLLM ช่วยป้องกันไม่ให้หน่วยความจำพุ่งสูงขึ้น (ballooning) ระหว่างการสนทนาที่ยาวนาน แทนที่จะจองพื้นที่หน่วยความความจำแบบต่อเนื่อง (contiguous scratchpad) ต่อหนึ่ง sequence ตัว engine จะจัดสรรหน้าหน่วยความจำ (pages) ขนาดคงที่และทำ mapping ตามความต้องการใช้งาน คุณสามารถเปิด context windows ทิ้งไว้ได้นานขึ้นโดยไม่ต้องกังวลว่าการใช้งาน RAM จะพุ่งสูงขึ้นอย่างรวดเร็ว

Continuous batching, also from vLLM, improves throughput. The engine can slip new requests into active batches instead of waiting for the current group to finish. If one user’s prompt is ten tokens and another’s is two hundred, the hardware stays busier and average latency drops.

For Mixture-of-Experts models, TensorSharp implements an SSD-based cache strategy drawn from oMLX. Frequently accessed expert weights sit ready on fast storage rather than fighting for system RAM. On machines with limited memory but decent NVMe drives, this keeps MoE architectures usable.

Quantization follows the GGUF standard established by llama.cpp. Your quantized 4-bit and 5-bit models load directly without a conversion step.

The Real Takeaway

Vulkan support turns TensorSharp from an interesting C# experiment into a practical inference option for heterogeneous hardware. The roadmap is clear: validate across AMD and Intel discrete silicon, then tighten the implementation with a native Vulkan backend. If you have an AMD card in your workstation or laptop, run the build and share your results. That feedback loop is what hardens experimental code into something you can ship.

You can find the release details on the developer’s write-up. If the project saves you from juggling CUDA toolkits or wrestling with macOS version locks, leave a star on the repository. For ongoing discussion and community testing threads, the Telegram group stays open.