40 คะแนน โดย GN⁺ 2026-03-14 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • เครื่องโลคัลสามารถตรวจสอบได้ว่า รันโมเดล AI ใดได้จริงบ้าง ผ่านเครื่องมือบนเว็บ
  • ใช้ WebGPU API ของเบราว์เซอร์เพื่อประเมินประสิทธิภาพฮาร์ดแวร์ โดยผลลัพธ์อาจแตกต่างจากสเปกจริง
  • แสดงข้อมูลตามโมเดล เช่น ความต้องการหน่วยความจำ, ความเร็วในการประมวลผลโทเค็น, ความยาวคอนเท็กซ์, ระดับการรัน (S~F)
  • รวมทั้งโมเดลโอเพนซอร์สและเชิงพาณิชย์หลัก ๆ เช่น Qwen, Llama, Gemma, Mistral, DeepSeek, GPT-OSS
  • ช่วยประเมินความเป็นไปได้ในการรัน AI แบบโลคัลได้อย่างรวดเร็ว จึงเป็น ตัวชี้วัดอ้างอิงที่มีประโยชน์สำหรับนักพัฒนาและนักวิจัย

ภาพรวมของบริการ

  • CanIRun.ai เป็นเว็บไซต์สำหรับสำรวจโมเดล AI ที่สามารถรันได้ในสภาพแวดล้อมแบบโลคัล
    • ผู้ใช้เพียงเปิดเว็บไซต์จากเบราว์เซอร์ ก็สามารถดูรายชื่อโมเดลที่รันได้ตามสมรรถนะของระบบตนเอง
    • ผลลัพธ์ได้มาจากการประเมินผ่าน WebGPU API และอาจแตกต่างจากประสิทธิภาพฮาร์ดแวร์จริง
  • แต่ละโมเดลถูกจัดหมวดหมู่ด้วย ระดับประสิทธิภาพ (S~F) ทำให้เข้าใจความเป็นไปได้และประสิทธิภาพในการรันได้อย่างเป็นธรรมชาติ

ระบบจัดระดับโมเดล

  • ระดับแบ่งเป็น S, A, B, C, D, F โดย S หมายถึงรันได้ลื่นไหลที่สุด
    • ตัวอย่าง: อ้างอิงจาก NVIDIA GeForce RTX 4070 12GB
    • Qwen 3.5 9B, Llama 3.1 8B เป็นต้น ถูกแสดงเป็น S(90/100) จึงรันได้อย่างลื่นไหล
    • Phi-4 14B เป็น A(70/100) หมายถึง 'ทำงานได้ดี'
    • GPT-OSS 20B, Mistral Small 3.1 24B เป็นต้น เป็น D(34~39/100) หมายถึง ‘แทบจะรันไม่ได้’
    • ส่วน Gemma 3 27B, Qwen 3 32B และโมเดลส่วนใหญ่ที่มีขนาดเกิน 27B ถูกแสดงเป็น F(0/100) ว่า ‘หนักเกินไป’

แหล่งข้อมูลและพื้นฐานทางเทคนิค

  • ข้อมูลโมเดลรวบรวมมาจาก llama.cpp, Ollama, LM Studio
  • ในหน้าแต่ละโมเดลจะแสดงรายละเอียด เช่น การใช้หน่วยความจำ, ความยาวคอนเท็กซ์, ความเร็วโทเค็น, ประเภทสถาปัตยกรรม (Dense/MoE)

ความสำคัญในการใช้งาน

  • เป็นข้อมูลอ้างอิงที่ใช้ได้จริงสำหรับ นักพัฒนา นักวิจัย และผู้ใช้โอเพนซอร์ส ที่ต้องการรันโมเดล AI ด้วยตนเองในสภาพแวดล้อมแบบโลคัล
  • ช่วยเปรียบเทียบขนาดและประสิทธิภาพของโมเดลกับสมรรถนะ GPU เพื่อวาง กลยุทธ์การเลือกโมเดลและการนำไปใช้งานที่เหมาะสม
  • จุดเด่นคือทำงานบนเบราว์เซอร์ จึง ทดสอบได้ทันทีโดยไม่ต้องติดตั้ง

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

 
GN⁺ 2026-03-14
ความคิดเห็นบน Hacker News
  • ตลอด 2 ปีที่ผ่านมา ฉันทุ่มเวลาอย่างมากกับการทดลอง โมเดลรันโลคัล
    โมเดลขนาดเล็ก เช่น qwen3.5:9b เหมาะมากกับการใช้เครื่องมือแบบโลคัล การดึงข้อมูล และแอปพลิเคชันแบบฝังตัว
    สำหรับงานเขียนโค้ด เครื่องมือบนคลาวด์อย่าง Google Antigravity, gemini-cli หรือ Anthropic Claude มีประสิทธิภาพมากกว่า
    ฉันลองตั้งค่า Emacs กับ Claude Code แบบโลคัลมามากกว่า 100 ชั่วโมง แต่ไม่แนะนำสำหรับผู้ใช้ทั่วไป
    กลับกัน ฉันคิดว่าจุดที่คุ้มที่สุดคือการใช้งาน โมเดลโลคัลแบบฝังตัวที่เล็กและใช้งานได้จริง ให้เชี่ยวชาญ

    • ขอแนะนำ qwen3.5:9b อย่างมาก
      แม้จะเป็นโมเดลเล็ก แต่มี ความสามารถด้านการให้เหตุผลแบบมัลติโหมด ที่ยอดเยี่ยม และโครงสร้างการคิดภายใน (CoT) ก็เสถียร
      โดยเฉพาะโครงสร้าง trade-off แบบใหม่ระหว่าง VRAM กับขนาดคอนเท็กซ์ที่น่าประทับใจ — จัดการได้ 100K โทเค็นด้วย VRAM 1.5GB ทำให้ RTX 3060 ก็รองรับบทสนทนายาวหรือการประมวลผลเอกสารได้
    • ฉันเคยลองใช้ qwen3.5 กับเครื่องมือโลคัลแล้วผลไม่ค่อยดี
      Discord chatbot ที่ทำงานได้ดีกับ GPT-OSS-120B กลับมีปัญหาใน Qwen คือ แค่ทำท่าเหมือนเรียกใช้เครื่องมือแต่ไม่รันจริง
      สุดท้ายเลยแยกให้ Qwen จัดการรูปภาพ และให้ GPT จัดการบทสนทนาทั่วไป
    • ฉันลอง qwen3.5 9b แล้วพบว่าอัตรา หลอนข้อมูล (hallucination) สูง
      ตอนสำรวจ local code repo มีผลลัพธ์ราว 30~50% ที่สร้างชื่อไฟล์หรือชื่อฟังก์ชันผิดขึ้นมา
      พอลองตรวจด้วย KimiK2 ก็พบว่าส่วนใหญ่ผิดจริง โมเดลเล็กนั้นดี แต่ต้องระวังเรื่องความน่าเชื่อถือ
    • อยากรู้ว่าคนอื่นเอาโมเดลเล็กไปผนวกเข้ากับ workflow จริงอย่างไร
      ฉันกำลังทดลองด้วย ollama บน M4 MacBook Pro (RAM 128GB) แต่ยังหาวิธีการทำงานที่น่าพอใจไม่เจอ
    • สงสัยว่าการใช้โมเดลใหญ่สำหรับ วางแผน และใช้โมเดลโลคัลเล็กสำหรับ เขียนโค้ด จะเป็นชุดผสมที่ดีไหม
      อยากลดการพึ่งพา Claude Code หรือ Codex
  • ดูเหมือนว่าเว็บไซต์นี้จะประเมินประสิทธิภาพจาก แบนด์วิดท์หน่วยความจำและขนาดของโมเดล
    แต่โมเดลแบบ MoE (เช่น GPT-OSS-20B) ไม่ได้ใช้ทุกพารามิเตอร์ในทุกโทเค็น จึงสร้างโทเค็นได้เร็วกว่าแม้อยู่บนฮาร์ดแวร์เดียวกัน
    GPT-OSS-20B มีพารามิเตอร์ที่แอ็กทีฟ 3.6B จึงให้ความเร็วใกล้เคียงกับโมเดล dense 3~4B แต่ VRAM ยังต้องรองรับขนาดเต็มของโมเดล 20B
    ในด้านความฉลาด มักถูกประเมินว่าอยู่ราวระดับโมเดล dense 8.5B

    • จากที่ฉันทดสอบจริง โมเดลบนโน้ตบุ๊ก Strix Halo ของฉันทำงานได้ดีกว่าที่คาดไว้มาก
      สำหรับโมเดล MoE ควรคำนวณแบนด์วิดท์หน่วยความจำโดยอิง เฉพาะพารามิเตอร์ที่แอ็กทีฟ
    • ดูเหมือนว่าการคำนวณนี้จะอิงจากขนาดคอนเท็กซ์เต็ม
      แต่ในการใช้งานจริง หลายครั้งคอนเท็กซ์ที่เล็กกว่านั้นก็เพียงพอ
      llama-fit-params ของ llama.cpp มีประโยชน์ในกรณีแบบนี้
    • เอกสารก็อธิบายจุดนี้ไว้ชัดเจน
      โมเดล MoE อย่าง Mixtral 8x7B จะมีพารามิเตอร์ที่แอ็กทีฟเพียงประมาณ 12.9B จากทั้งหมด 46.7B
      หมายความว่าได้ทั้งคุณภาพของโมเดลใหญ่และความเร็วของโมเดลเล็ก แต่ตัวโมเดลทั้งหมดก็ยังต้องอยู่ในหน่วยความจำ
      เอกสาร canirun.ai
    • แต่ก็ยังมีความคลาดเคลื่อนอยู่บ้าง
      ความเร็วการสร้างโทเค็นใกล้เคียงกันก็จริง แต่ ความเร็ว prefill ของ MoE ขนาดใหญ่จะช้ากว่า
      อีกทั้งถ้าใช้ speculative decoding โมเดล dense ขนาดเล็กอาจเร็วขึ้นได้สูงสุด 3 เท่า แต่โมเดล MoE แทบไม่ได้ประโยชน์
  • ความพยายามอย่าง TFA หรือ llmfit นั้นดี แต่สิ่งที่น่าหงุดหงิดคือการหาว่าโมเดลไหนให้คุณภาพดีที่สุดบนฮาร์ดแวร์ของฉันทำได้ยาก
    เช่น Qwen 3.5 27B Q6 @ 100k context ทำงานได้ดี แต่ในลิสต์แนะนำกลับให้ Qwen 2.5 รุ่นเก่ามาก่อน
    สำหรับฉัน ถ้าได้ tok/s มากกว่า 50 ก็พอแล้ว จึงอยากให้เรียงตามคุณภาพได้

    • คำถามนี้กว้างเกินไป
      ตัวอย่างเช่น “open model สำหรับงานโค้ดคุณภาพสูง บน 8GB VRAM, 32GB RAM, t/s ≥ 30, context ≥ 32K” ก็อาจเป็น Qwen2.5-Coder-7B-Instruct
      “สำหรับงาน web research บน 24GB VRAM, 32GB RAM” ก็อาจเป็น Qwen3-30B-A3B-Instruct-2507
      “สำหรับ RAG embedding บน 40GB VRAM, 128GB RAM” ก็อาจเป็น Qwen3-Embedding-8B
      กล่าวคือจำเป็นต้องมี คำแนะนำโมเดลแบบเจาะจงตามฮาร์ดแวร์
    • อยากรู้ประสิทธิภาพด้านต้นทุนของการรันโลคัล ($/Mtok)
      ถ้าไม่คิดค่าไฟก็แทบฟรี แต่ความเร็วและคุณภาพด้อยกว่า
      หรือจริง ๆ แล้วคนชอบรันโลคัลเพียงเพราะ ความเป็นส่วนตัวของข้อมูล?
    • ปัญหานี้ยากมากจริง ๆ และฉันก็ศึกษาเรื่องนี้มานานกว่าปีแล้ว
      พอต้องพิจารณาทั้งหลายอุปกรณ์และหลายโมเดลพร้อมกัน เพื่อปรับ คุณภาพและการจัดสรรทรัพยากร ให้เหมาะสม ความซับซ้อนก็พุ่งสูงมาก
      สุดท้ายตอนนี้เลยยอมประนีประนอมด้วยการเลือก quant model ที่ใหญ่ที่สุดไปเลย
    • LLM ก็เป็นเพียง เครื่องคิดเลขเฉพาะทาง เท่านั้น
      มันไม่จำเป็นต้องแม่นยำแบบเครื่องคิดเลขทั่วไป และเพราะเป้าหมายของผู้สร้างโมเดลกับผู้ใช้ไม่เหมือนกัน จึงคาดเดายากว่าจะได้ผลลัพธ์แบบที่ต้องการหรือไม่
  • นี่ดูเหมือนจะเป็นแค่ เวอร์ชันเว็บของ llmfit
    ลิงก์ GitHub ของ llmfit

    • ใช่ แต่ llmfit ตรวจจับทรัพยากรระบบอัตโนมัติได้ จึงมีประโยชน์กว่ามาก
    • ขอบคุณสำหรับลิงก์ ใช้งานได้จริงมากกว่าเว็บไซต์เสียอีก
      บน M2 Max MBP (RAM 96GB) ของฉันก็บอกว่า local LLM ส่วนใหญ่รันได้ดี
      แปลกใจเหมือนกันที่มี โมเดลจำนวนมากที่รันโลคัลได้ มากกว่าที่คิด
  • แนะนำ สแต็ก Rust+Wasm เป็นทางเลือกที่เบากว่า Docker หรือ Python
    โปรเจกต์ LlamaEdge

  • มันตรวจพบ RTX 6000 Pro Max-Q (VRAM 96GB) ของฉันได้ถูกต้อง แต่ใน UI กลับแสดงเป็น 4GB
    อีกทั้งยังไม่คำนึงถึง โมเดลที่ผ่านการ quantization และแสดงแต่โมเดลความละเอียดเต็ม
    ยังต้องปรับปรุงอีก

  • รายการ mobile GPU ยังไม่ครบ และดูเหมือนจะไม่เข้าใจกลยุทธ์อย่างการแชร์หน่วยความจำกับ CPU หรือ KV cache offloading
    ระบบของฉันแสดงเป็น Arc 750 (RAM ที่แชร์ 2GB) แต่ของจริงคือ RTX1000 Ada (6GB GDDR6)
    Qwen3 Coder Next, Devstral Small, Qwen3.5 4B และรุ่นอื่น ๆ ทำงานได้ดีเกือบเรียลไทม์
    โมเดลที่ใหญ่กว่านี้ช้ากว่า แต่ ไม่มีปัญหาโทเค็นไม่พอ

  • เป็นไอเดียที่ดีมาก
    แต่ฉันใช้ M3 Ultra (RAM 256GB) และมีตัวเลือกแค่ถึง 192GB
    ถ้าเลือกโมเดลแล้วสามารถ เปรียบเทียบประสิทธิภาพตามโปรเซสเซอร์ ได้ด้วยก็น่าจะดี

    • น่าเสียดายที่ Apple เลิกทำรุ่น 512GiB ไปแล้ว
  • เพิ่งรู้เป็นครั้งแรกว่าเบราว์เซอร์ของฉัน ส่งข้อมูลฮาร์ดแวร์ให้เว็บไซต์โดยอัตโนมัติ

    • จริง ๆ แล้วมันไม่แม่นยำทั้งหมด
      เว็บไซต์ระบุว่าฉันใช้ iPhone 19 Pro แต่จริง ๆ คือ iPhone SE รุ่นแรก
    • Librewolf เวอร์ชันล่าสุดจะขอสิทธิ์เข้าถึง WebGL
      ดูเหมือนว่าจะใช้สิ่งนั้นในการตรวจจับฮาร์ดแวร์
    • ข้อมูลแบบนี้มักถูกใช้เพื่อ ติดตามลายนิ้วมือเบราว์เซอร์ (fingerprinting)
      เบราว์เซอร์ที่เน้นความเป็นส่วนตัวจะส่งข้อมูลแบบสุ่มแทน
    • ฉันเดาว่าสายการบินก็คงใช้วิธีนี้ในการตั้งราคาต่างกันตาม OS
  • มันดูแปลกที่ แทบไม่เห็นความต่างด้านประสิทธิภาพระหว่างชิป M4 กับ M5 เลย
    ขนาดหน่วยความจำก็ดูเหมือนไม่มีผลต่อประสิทธิภาพของโมเดลขนาดใหญ่
    โดยรวมแล้วดูเหมือนจะอิงจาก ค่าประมาณมากกว่าข้อมูลจริง จึงควรมีป้าย “ESTIMATE”