28 คะแนน โดย GN⁺ 2026-03-03 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • เครื่องมือที่ช่วยค้นหา โมเดลที่สามารถรันได้จริง บน RAM·CPU·GPU ของระบบคุณ จาก โมเดล LLM และผู้ให้บริการนับร้อยราย ได้ด้วยคำสั่งเดียว
  • ให้คะแนนแต่ละโมเดลตามคุณภาพ·ความเร็ว·ความเหมาะสม·คอนเท็กซ์ พร้อมแสดงว่าสามารถรันได้หรือไม่ และรองรับทั้ง TUI (เทอร์มินัล UI) และ โหมด CLI
  • รองรับหลาย GPU, โครงสร้าง MoE, การทำ quantization แบบไดนามิก, การประมาณความเร็ว และการผสานรวมกับ local runtime (Ollama, llama.cpp, MLX)
  • วิเคราะห์ โหมดการรัน (GPU, CPU+GPU, CPU) และ ระดับความเหมาะสม (Perfect, Good, Marginal, Too Tight) ของแต่ละโมเดล เพื่อเสนอชุดค่าที่เหมาะสมที่สุด
  • มอบ ระบบอัตโนมัติสำหรับการเลือกโมเดลตามฮาร์ดแวร์ แก่นักพัฒนาที่ต้องการใช้งาน LLM ในสภาพแวดล้อมโลคัลอย่างมีประสิทธิภาพ

ภาพรวมความสามารถหลัก

  • llmfit เป็นเครื่องมือบนเทอร์มินัลที่ตรวจจับสเปกฮาร์ดแวร์ของระบบและประเมินว่าโมเดล LLM สามารถรันได้จริงหรือไม่
    • อ่านข้อมูล RAM, CPU, GPU แล้วคำนวณคะแนนคุณภาพ·ความเร็ว·ความเหมาะสม·คอนเท็กซ์ของแต่ละโมเดล
    • แสดงผลในรูปแบบ TUI แบบอินเทอร์แอ็กทีฟ หรือ CLI แบบดั้งเดิม
  • รองรับฟีเจอร์ หลาย GPU, Mixture-of-Experts(MoE), การเลือก quantization แบบไดนามิก, การประมาณความเร็ว, และ การผสานรวมกับ local runtime
  • รองรับ Ollama, llama.cpp, MLX เป็น local runtime พร้อมตรวจจับโมเดลที่ติดตั้งไว้และดาวน์โหลดได้อัตโนมัติ
  • ผ่าน โหมด Plan สามารถคำนวณย้อนกลับเพื่อหา hardware ขั้นต่ำ·ที่แนะนำสำหรับโมเดลที่ต้องการได้
  • ทำงานได้บนหลายแพลตฟอร์ม เช่น macOS, Linux, Windows, Ascend

การติดตั้งและการรัน

  • บน macOS/Linux สามารถติดตั้งด้วยคำสั่ง brew install llmfit หรือ curl -fsSL https://llmfit.axjns.dev/install.sh | sh
  • บน Windows สามารถติดตั้งได้ผ่าน cargo install llmfit
  • เมื่อรันคำสั่ง llmfit จะเปิด TUI และแสดงสเปกระบบพร้อมรายการโมเดล
  • ในโหมด CLI มีคำสั่งย่อยหลากหลาย เช่น llmfit --cli, llmfit fit --perfect -n 5, llmfit recommend --json

วิธีการทำงาน

  • การตรวจจับฮาร์ดแวร์: ใช้ sysinfo, nvidia-smi, rocm-smi, system_profiler เป็นต้น เพื่อรวบรวมข้อมูล RAM·CPU·GPU
  • ฐานข้อมูลโมเดล: ดึงโมเดลหลายร้อยรายการจาก HuggingFace API และบันทึกไว้ใน data/hf_models.json
    • รวมโมเดลหลักอย่าง Meta Llama, Mistral, Qwen, Google Gemma, Microsoft Phi, DeepSeek, IBM Granite เป็นต้น
  • quantization แบบไดนามิก: ไล่ระดับตั้งแต่ Q8_0 ถึง Q2_K และเลือก quantization คุณภาพสูงสุดที่พอดีกับหน่วยความจำที่มีอยู่โดยอัตโนมัติ
  • การประมาณความเร็ว: ใช้สูตรจากแบนด์วิดท์หน่วยความจำ GPU (bandwidth_GB_s / model_size_GB) × 0.55
    • มีตารางแบนด์วิดท์ของ GPU ราว 80 รุ่นฝังมาในตัว
  • การวิเคราะห์ความเหมาะสม: ประเมินความสามารถในการรันและระยะเผื่อหน่วยความจำในโหมด GPU·CPU+GPU·CPU

ส่วนติดต่อผู้ใช้

  • ปุ่มควบคุมใน TUI:
    • f สำหรับตัวกรองความเหมาะสม, a สำหรับตัวกรองความพร้อมใช้งาน, s สำหรับเปลี่ยนเกณฑ์การเรียงลำดับ
    • p เพื่อเข้าสู่โหมด Plan, d เพื่อดาวน์โหลดโมเดล, t เพื่อเปลี่ยนธีม
  • ใน โหมด Plan สามารถปรับความยาวคอนเท็กซ์, quantization, ความเร็วโทเคนเป้าหมาย เป็นต้น เพื่อคำนวณ VRAM/RAM/CPU ที่ต้องใช้
  • ธีม: มีธีมสีในตัว 6 แบบ ได้แก่ Default, Dracula, Solarized, Nord, Monokai, Gruvbox

รันไทม์และความสามารถในการผสานรวม

  • การผสานรวมกับ Ollama: เชื่อมต่อกับอินสแตนซ์ Ollama แบบโลคัลหรือรีโมต (OLLAMA_HOST environment variable) เพื่อตรวจจับและดาวน์โหลดโมเดลที่ติดตั้งไว้
  • การผสานรวมกับ llama.cpp: ดาวน์โหลดไฟล์ GGUF จาก HuggingFace ไปยัง local cache และแสดงสถานะการติดตั้ง
  • การผสานรวมกับ MLX: รองรับ model cache และการเชื่อมต่อเซิร์ฟเวอร์สำหรับ Apple Silicon
  • การเชื่อมต่อกับ OpenClaw: ผ่านสกิล llmfit-advisor ให้เอเจนต์ OpenClaw แนะนำและตั้งค่าโมเดลที่เหมาะกับฮาร์ดแวร์โดยอัตโนมัติ

การจัดการฐานข้อมูลโมเดล

  • ใช้สคริปต์ scripts/scrape_hf_models.py เพื่อสร้างรายการโมเดลจาก HuggingFace API โดยอัตโนมัติ
  • ใช้คำสั่ง make update-models เพื่ออัปเดตข้อมูลและสร้างไบนารีใหม่
  • โมเดลถูกจัดหมวดหมู่เป็นทั่วไป, โค้ดดิ้ง, การให้เหตุผล, มัลติโหมด, แชต, เอ็มเบดดิ้ง เป็นต้น
  • ใช้ GGUF source cache (data/gguf_sources_cache.json) เพื่อแคชเส้นทางดาวน์โหลดไว้ 7 วัน

การรองรับแพลตฟอร์ม

  • Linux/macOS(Apple Silicon): รองรับเต็มรูปแบบ
  • Windows: รองรับการตรวจจับ RAM·CPU และ NVIDIA GPU (nvidia-smi)
  • หาก ตรวจจับ GPU ไม่สำเร็จ สามารถกำหนด VRAM เองได้ด้วยตัวเลือก --memory=

ใบอนุญาต

  • ใบอนุญาต MIT

1 ความคิดเห็น

 
GN⁺ 2026-03-03
ความคิดเห็นจาก Hacker News
  • โปรเจ็กต์นี้ดูเจ๋งและมีประโยชน์มาก แต่ถ้าเป็น เว็บไซต์ น่าจะดีกว่า
    รู้สึกกังวลกับการต้องรันไฟล์ executable แบบนี้ ฟังก์ชันลักษณะนี้น่าจะทำบนเว็บได้เพียงพอ

    • เครื่องมือนี้พึ่งพา การตรวจจับฮาร์ดแวร์ จึงมีข้อจำกัดหากทำบนเว็บ
      ตาม คำอธิบายใน GitHub จำเป็นต้องอ่านข้อมูลระดับระบบ เช่น ปริมาณ RAM, จำนวน GPU, และประเภท backend (CUDA, Metal เป็นต้น)
      เนื่องจากข้อจำกัดของ sandbox ในเบราว์เซอร์ JavaScript จึงไม่สามารถเข้าถึงข้อมูลเหล่านี้ได้โดยตรง
      ถ้าจะทำเป็นเวอร์ชันเว็บ ผู้ใช้อาจต้องอัปโหลดรายงานจาก .spx ของ macOS หรือ inxi ของ Linux หรือเลือกสเปกฮาร์ดแวร์ด้วยตนเอง
      วิธีนี้อาจสะดวกน้อยกว่า แต่มีข้อดีคือสามารถทดสอบชุดฮาร์ดแวร์เสมือนได้
    • Hugging Face ก็มีฟังก์ชันคล้ายกัน แต่ต้อง กรอกข้อมูลฮาร์ดแวร์เอง
      จริง ๆ แล้วคนที่รันโมเดลแบบโลคัลส่วนมากคงไม่ได้ไม่รู้สเปกเครื่องตัวเอง
    • เมื่อไม่นานมานี้ฉันเห็นเว็บไซต์ชื่อ whatmodelscanirun.com ซึ่งน่าเอาไปอ้างอิง
    • ใน Hugging Face ก็มีฟีเจอร์นี้ฝังมาอยู่แล้ว
    • ยังมีเว็บไซต์ฐานข้อมูลโมเดล LLM แบบขับเคลื่อนโดยชุมชนอย่าง inferbench.com ด้วย มีการแชร์ความเร็วโทเค็นและข้อมูลการตั้งค่าต่าง ๆ
  • โปรเจ็กต์นี้ยอดเยี่ยมจริง ๆ
    ที่จริงสิ่งที่ต้องรู้มีแค่ ขนาดของ LLM กับแบนด์วิดท์หน่วยความจำ เท่านั้น
    ใช้สมการง่าย ๆ ก็พอตัดสินได้ว่าโมเดลนั้นเหมาะหรือไม่
    ตัวอย่างเช่น ถ้าจะรันโมเดล 32B แบบ 4bit ต้องมี VRAM อย่างน้อย 16GB
    ถ้าคำนวณด้วย tok/s = memory_bandwidth / llm_size แล้ว RTX3090 (960GB/s) จะได้ประมาณ 60 tok/s
    สำหรับโมเดล MoE จำนวนพารามิเตอร์ที่ active จะเป็นตัวกำหนดความเร็ว
    ถ้าเผื่อเพิ่มอีกประมาณ 10% ก็จะเป็นค่าประเมินที่สมจริง

    • KV cache มีการเขียนต่อโทเค็นไม่มาก จึงสลับออกไปเก็บได้ง่าย
      หากโหลดพารามิเตอร์โมเดลด้วย mmap ก็สามารถขยายได้โดยแทบไม่เสียประสิทธิภาพเมื่อมี RAM เพียงพอ
    • นี่เป็นกฎคร่าว ๆ ที่ดี แต่โดยมากแล้วเมื่อ ขนาด context window ใหญ่ขึ้น การใช้ RAM มักเพิ่มขึ้นแบบก้าวกระโดด
    • ฉันไม่เคยรู้สูตรนี้มาก่อน ขอบคุณที่แชร์
  • หน้าตาดูดี แต่ในเครื่องของฉัน Qwen 3.5 รันได้ดี ทว่าเครื่องมือกลับบอกว่าใช้ไม่ได้
    สุดท้ายแล้วเครื่องมือแบบนี้คงใช้ได้แค่เป็น ข้อมูลอ้างอิงคร่าว ๆ
    ถ้าใช้การปรับแต่งแบบคัสตอมอย่าง Unsloth ในความเป็นจริงอาจรันโมเดลได้มากกว่านี้
    โมเดลใหม่ออกเร็วเกินไปจนรู้สึกว่าไม่น่าดูแลรักษาได้ง่าย

    • เป็นไปได้ว่าอาจกำลังเกิด การสลับข้อมูลระหว่างดิสก์กับ RAM อยู่
      วิธีนี้อาจทำให้อายุการใช้งานของดิสก์สั้นลงในระยะยาว
  • ไอเดียดี แต่โมเดลที่แนะนำค่อนข้าง เก่า
    มันแนะนำ Qwen 2.5 หรือ Starcoder 2 ให้กับ M4 MacBook Pro (RAM 128GB) ของฉัน

  • อย่างที่หลายคนพูด นี่ควรทำเป็น เว็บไซต์มากกว่าเครื่องมือ CLI
    แค่มีฟอร์มให้กรอกสเปก CPU, RAM, GPU ก็คำนวณได้เพียงพอแล้ว

  • ไม่เข้าใจว่าทำไมต้องดาวน์โหลดมารันด้วย
    แค่ กรอกสเปกผ่านดรอปดาวน์ แล้วดูผลลัพธ์ก็น่าจะพอ

  • โดยรวมครอบคลุมกรณีส่วนใหญ่ได้ดี แต่ในกรณีอย่าง AMD iGPU ที่ ROCm ไม่รองรับ ก็ยังสามารถรันแบบ อิง Vulkan ได้
    หากตั้งค่าไดรเวอร์ให้ใช้ RAM ของระบบเสมือนเป็น VRAM ก็สามารถโหลดโมเดลที่เดิมทีรันไม่ได้ได้
    มีประโยชน์มากโดยเฉพาะกับ layer offload หรือโมเดล MoE แบบ quantized

  • Claude เองก็แนะนำโมเดลได้ค่อนข้างดีถ้าใส่สเปกเครื่องเข้าไป

    • ฉันก็เคยถาม Claude ว่า “local LLM ที่ดีที่สุดที่รันได้บนคอมเครื่องนี้คืออะไร?” แล้วมันก็แนะนำทั้งโมเดลที่ติดตั้งอยู่แล้วและอีกหนึ่งตัว
      ไม่แน่ใจว่าเป็นข้อมูลล่าสุดหรือเปล่า ฉันทดสอบโดยอิงจาก Ollama และ LM Studio
  • ฉันให้ Claude หรือ Codex ไล่รันหลายโมเดลด้วย Ollama ทีละตัว แล้วให้มัน ประเมินประสิทธิภาพอัตโนมัติ
    ใช้เวลาประมาณ 30 นาทีก็หาโมเดลที่เหมาะกับระบบของฉันได้

    • อยากรู้ว่าพอจะแชร์พรอมป์ต์นั้นได้ไหม