ระบบนิเวศ LLM แบบโลคัลไม่จำเป็นต้องมี Ollama

 (sleepingrobots.com)
26 คะแนน โดย GN⁺ 13 일 전 | 3 ความคิดเห็น | แชร์ทาง WhatsApp
  • Ollama เคยเป็นเครื่องมือยุคแรกที่ทำให้การรัน LLM แบบโลคัลง่ายขึ้น แต่ภายหลังสูญเสียความน่าเชื่อถือจาก การปกปิดที่มาและการหันไปเน้นคลาวด์
  • มีการ ลดทอนเครดิตของเอนจินหลักอย่าง llama.cpp และเมื่อเปลี่ยนไปใช้แบ็กเอนด์ ggml ของตนเอง ก็เกิดทั้ง ประสิทธิภาพตกลงและบั๊กที่เคยแก้ไปแล้วกลับมาอีก
  • ชุมชนยังวิจารณ์ต่อเนื่องเรื่อง การตั้งชื่อโมเดลชวนให้เข้าใจผิด, การปล่อยแอป GUI แบบปิดซอร์ส, และ โครงสร้าง Modelfile ที่ไม่มีประสิทธิภาพ
  • คอขวดของรีจิสทรีโมเดล, ช่องโหว่ด้านความปลอดภัย, และ โครงสร้างแบบ vendor lock-in ขัดกับแนวคิด local-first
  • ทางเลือกโอเพนซอร์สอย่าง llama.cpp, LM Studio, Jan มีทั้ง ประสิทธิภาพและความโปร่งใสที่ดีกว่า และได้กลายเป็นศูนย์กลางของระบบนิเวศ LLM แบบโลคัลไปแล้ว

ปัญหาของ Ollama และทางเลือกในระบบนิเวศ LLM แบบโลคัล

  • จุดกำเนิดและบทบาทช่วงแรกของ Ollama

    • Ollama ได้รับความสนใจในฐานะ wrapper ของ llama.cpp รายแรก ๆ ที่ทำให้การรัน LLM แบบโลคัลง่ายขึ้น
      • ผู้ใช้สามารถรันโมเดลได้โดยไม่ต้องคอมไพล์ C++ เองหรือตั้งค่าเซิร์ฟเวอร์
    • แต่หลังจากนั้นกลับ ปกปิดที่มา, ทำให้ผู้ใช้เข้าใจผิด, และ ถอยห่างจากแนวคิดที่ยึดโลคัลเป็นศูนย์กลาง ไปสู่โครงสร้างคลาวด์ที่ขับเคลื่อนด้วยเงินทุนร่วมลงทุน
    • ผู้ก่อตั้งคือ Jeffrey Morgan และ Michael Chiang ซึ่งเคยพัฒนา Kitematic GUI สำหรับ Docker และถูก Docker Inc. เข้าซื้อกิจการมาก่อน
    • เป็นสตาร์ตอัปจาก Y Combinator (W21) เปิดตัวสู่สาธารณะในปี 2023 พร้อมวางตัวเองว่าเป็น “Docker for LLMs”

  • การให้เครดิต llama.cpp อย่างไม่เหมาะสม

    • ความสามารถด้าน inference ของ Ollama พึ่งพา llama.cpp ของ Georgi Gerganov ทั้งหมด
    • เป็นเวลากว่าหนึ่งปีที่ไม่มีการกล่าวถึง llama.cpp เลยใน README เว็บไซต์ หรือเอกสารการตลาด และ ยังละเว้นการแจ้งเตือนสัญญาอนุญาต MIT
    • issue ของชุมชนที่ขอให้ปฏิบัติตามไลเซนส์ (#3185) ไม่ได้รับคำตอบนานกว่า 400 วัน
    • หลังจากนั้นผู้ร่วมก่อตั้งจึงเพิ่มข้อความเพียงหนึ่งบรรทัดที่ท้าย README ว่า “llama.cpp project founded by Georgi Gerganov”
    • ฝั่ง Ollama ระบุว่า “เรากำลังทำแพตช์จำนวนมาก และจะค่อย ๆ เปลี่ยนไปใช้เอนจินของเราเอง” ซึ่งสะท้อนว่า มีเจตนาลดทอนเครดิต

การเปลี่ยนไปใช้แบ็กเอนด์ของตัวเองและประสิทธิภาพที่ลดลง

  • นำแบ็กเอนด์คัสตอมบนพื้นฐาน ggml มาใช้

    • ช่วงกลางปี 2025 Ollama เปลี่ยนจาก llama.cpp ไปใช้ implementation ของตัวเองที่อิง ggml
    • แม้จะอ้างเรื่องความเสถียร แต่ผลลัพธ์คือ นำบั๊กที่เคยถูกแก้แล้วกลับเข้ามาใหม่
    • เกิดปัญหาหลายอย่าง เช่น structured output ผิดพลาด, โมเดล vision ใช้งานไม่ได้, และการชนกันจาก GGML assertion
    • โมเดลใหม่อย่าง GPT-OSS 20B ใช้งานไม่ได้หรือมีปัญหาไม่รองรับชนิดเทนเซอร์
    • Gerganov ชี้ตรง ๆ ว่า Ollama fork ggml อย่างผิดพลาด

  • ผลการเปรียบเทียบด้านประสิทธิภาพ

    • เบนช์มาร์กจากชุมชนพบว่า llama.cpp เร็วกว่า Ollama 1.8 เท่า (161 เทียบกับ 89 tokens/s)
    • บน CPU ก็ยังมีส่วนต่างด้านประสิทธิภาพราว 30~50%
    • ในการทดสอบ Qwen-3 Coder 32B นั้น llama.cpp มี throughput สูงกว่า 70%
    • สาเหตุถูกระบุว่าอยู่ที่ โครงสร้างแบบ daemon ของ Ollama, การ offload ไป GPU ที่ไม่มีประสิทธิภาพ, และแบ็กเอนด์ที่ล้าสมัย

การตั้งชื่อโมเดลที่ทำให้เข้าใจผิด

  • กรณีของ DeepSeek-R1

    • Ollama แสดงโมเดลย่ออย่าง DeepSeek-R1-Distill-Qwen-32B เป็นเพียง “DeepSeek-R1”
    • ทั้งที่ไม่ใช่โมเดล 671B พารามิเตอร์ตัวจริง แต่กลับใช้ชื่อเดียวกัน
    • ทำให้ผู้ใช้เข้าใจผิดว่า “ได้รัน DeepSeek-R1 แบบโลคัลแล้ว” และ กระทบต่อชื่อเสียงของ DeepSeek
    • GitHub issue ที่เกี่ยวข้อง (#8557, #8698) ถูกจัดเป็นรายการซ้ำทั้งหมดและยังไม่ได้รับการแก้ไข
    • ปัจจุบัน ollama run deepseek-r1 ก็ยังคงรันโมเดลย่ออยู่

การออกแอปแบบปิด

  • การปล่อยแอป GUI แบบไม่เปิดซอร์ส

    • เดือนกรกฎาคม 2025 มีการเปิดตัว Ollama GUI app สำหรับ macOS และ Windows
    • แอปถูกพัฒนาใน repository แบบปิด และปล่อยใช้งานโดยไม่มีไลเซนส์ พร้อมทั้งไม่เปิดเผยซอร์สโค้ด
    • สำหรับโปรเจกต์ที่เคยรักษาภาพลักษณ์โอเพนซอร์สมาก่อน นี่ถือเป็น การหันไปสู่ความปิดอย่างฉับพลัน
    • ชุมชนตั้งข้อกังวลว่าอาจมีการพึ่งพา AGPL-3.0 และเสี่ยง ละเมิดไลเซนส์
    • เว็บไซต์วางปุ่มดาวน์โหลดไว้ข้างลิงก์ GitHub ทำให้ ดูคล้ายว่าเป็นโอเพนซอร์ส
    • หลังเงียบอยู่นานหลายเดือน จึงค่อย merge เข้าสู่ repository หลักในเดือนพฤศจิกายน 2025
    • XDA วิจารณ์ว่า “โปรเจกต์ที่อ้างว่าเป็นโอเพนซอร์สควรทำให้ชัดเจนว่าเปิดหรือไม่เปิด”

ความไม่มีประสิทธิภาพของ Modelfile

  • ความซ้ำซ้อนกับฟอร์แมต GGUF

    • ฟอร์แมต GGUF มีข้อมูลทั้งหมดที่จำเป็นต่อการรันโมเดลอยู่แล้วในไฟล์เดียว
    • แต่ Ollama กลับเพิ่มไฟล์ตั้งค่าแยกชื่อ Modelfile ที่มีโครงสร้างคล้าย Dockerfile เข้ามาอีก
    • สิ่งนี้ทำให้ต้องนิยามข้อมูลที่มีอยู่ใน GGUF ซ้ำ และสร้าง ความซับซ้อนโดยไม่จำเป็น
    • Ollama รู้จำอัตโนมัติได้เฉพาะ รายการเทมเพลตที่ hardcode ไว้ เท่านั้น ส่วนเทมเพลตใหม่จะถูกมองข้าม
    • ผลคือ รูปแบบคำสั่งของโมเดลเสียหาย และผู้ใช้ต้องแปลงเองด้วยมือ

  • การแก้พารามิเตอร์ที่ไม่มีประสิทธิภาพ

    • หากต้องการเปลี่ยนพารามิเตอร์ ต้องดึงออกด้วย ollama show --modelfile แล้วแก้ไข ก่อนจะสร้างใหม่ด้วย ollama create
    • ระหว่างกระบวนการนี้จะเกิดการ คัดลอกโมเดลทั้งก้อนขนาด 30~60GB
    • ชุมชนวิจารณ์ว่านี่คือ “การทำซ้ำที่ไม่มีประสิทธิภาพและไม่จำเป็น”
    • ฝั่ง llama.cpp สามารถปรับพารามิเตอร์ได้ง่าย ๆ ผ่าน argument ในบรรทัดคำสั่ง

  • ปัญหาความเข้ากันได้ของเทมเพลต

    • Ollama ใช้ ไวยากรณ์เทมเพลตของ Go ซึ่งไม่ตรงกับ เทมเพลต Jinja ที่ผู้สร้างโมเดลใช้กัน
    • LM Studio และ llama.cpp รองรับ Jinja ได้โดยตรง แต่ Ollama ต้องมีขั้นตอนแปลง
    • มีรายงานจำนวนมากว่าการแปลงนี้ทำให้ รูปแบบบทสนทนาเสียหาย

คอขวดของรีจิสทรีโมเดล

  • ความล่าช้าในการลงทะเบียนโมเดล

    • แม้โมเดลใหม่จะถูกอัปโหลดขึ้น Hugging Face แล้ว แต่บน Ollama จะต้อง แพ็กและลงทะเบียนโดยตรงอีกครั้ง ก่อนจึงใช้งานได้
    • ฟอร์แมต quantization ที่รองรับก็ยัง จำกัดอยู่แค่ Q4_K_M, Q8_0 เป็นต้น
    • ส่งผลให้เกิด ความล่าช้าระหว่างการเปิดตัวโมเดลกับการใช้งานบน Ollama
    • ในชุมชนจึงมีโพสต์ PSA แพร่หลายว่า “ถ้าจะทดสอบโมเดลใหม่ ให้ใช้ llama.cpp หรือ vLLM”

  • ข้อจำกัดด้าน quantization

    • Ollama ไม่รองรับตระกูล Q5, Q6 และ IQ
    • แม้ผู้ใช้จะร้องขอ ก็ได้รับคำตอบว่า “ให้ไปใช้เครื่องมืออื่น”
    • แม้ตอนนี้จะสามารถเรียก Hugging Face ได้โดยตรงด้วยคำสั่ง ollama run hf.co/{repo}:{quant} แต่ก็ยังคง ถูกคัดลอกเข้า internal hash store และแชร์ต่อไม่ได้ อีกทั้งปัญหาเรื่องเทมเพลตก็ยังมีอยู่

การหันไปใช้คลาวด์และปัญหาด้านความปลอดภัย

  • การนำโมเดลคลาวด์เข้ามา

    • ปลายปี 2025 Ollama เพิ่ม โมเดลที่โฮสต์บนคลาวด์ เข้ามา
    • ทั้งที่เดิมเป็นเครื่องมือที่ยึดโลคัลเป็นศูนย์กลาง แต่กลับมีบางโมเดลที่ ส่งพรอมป์ต์ไปยังเซิร์ฟเวอร์ภายนอก
    • เมื่อใช้ โมเดลจากผู้ให้บริการภายนอก เช่น MiniMax ข้อมูลอาจถูกส่งออกไปยังบุคคลที่สาม
    • Ollama ระบุว่า “ไม่เก็บล็อก” แต่ นโยบายของบุคคลที่สามยังไม่ชัดเจน
    • ในกรณีของโมเดลที่อยู่บน Alibaba Cloud ก็ ไม่มีการรับประกันเรื่องการเก็บรักษาข้อมูล

  • ช่องโหว่ด้านความปลอดภัย

    • CVE-2025-51471: ช่องโหว่ที่ทำให้ registry server อันตรายสามารถขโมย authentication token ได้
    • แม้จะมี PR สำหรับแก้ไขแล้ว แต่ก็ ไม่ถูก merge อยู่นานหลายเดือน
    • สำหรับเครื่องมือที่ชูเรื่องความเป็นส่วนตัวแบบโลคัลเป็นคุณค่าหลัก นี่ถือเป็น ปัญหาเชิงโครงสร้างที่ร้ายแรง

โครงสร้างที่ขับเคลื่อนด้วยเงินทุนร่วมลงทุน

  • รูปแบบที่เกิดซ้ำ

    • ใช้โปรเจกต์โอเพนซอร์สมา ครอบเป็นผลิตภัณฑ์เพื่อสะสมฐานผู้ใช้ → ระดมทุน → เปลี่ยนไปสู่การสร้างรายได้
    • ลำดับการเดินเกมของ Ollama
      • เริ่มจากโอเพนซอร์สและสร้างบนฐานของ llama.cpp
      • ลดทอนที่มาและทำให้ดูเหมือนเป็นผลิตภัณฑ์อิสระ
      • สร้าง lock-in ผ่านรีจิสทรีและฟอร์แมตของโมเดล
      • ปล่อย GUI แบบปิดซอร์ส
      • เพิ่มบริการคลาวด์ เพื่อหารายได้

  • โครงสร้างแบบ vendor lock-in

    • Ollama จัดเก็บโมเดลด้วย ชื่อไฟล์แบบ hash ทำให้ใช้งานร่วมกับเครื่องมืออื่นได้ยาก
    • แม้จะนำเข้า GGUF ได้ แต่ การส่งออกถูกออกแบบให้ทำได้ไม่สะดวก
    • โครงสร้างนี้ทำให้ผู้ใช้ ถูกผูกติดอยู่กับระบบนิเวศของ Ollama

เครื่องมือทางเลือก

  • llama.cpp

    • มีทั้ง เซิร์ฟเวอร์ API ที่เข้ากันได้กับ OpenAI (llama-server), เว็บ UI, การควบคุมพารามิเตอร์อย่างละเอียด และ throughput สูง
    • เดือนกุมภาพันธ์ 2026 ggml.ai เข้าร่วม Hugging Face ทำให้มีความยั่งยืนในระยะยาวมากขึ้น
    • ใช้สัญญาอนุญาต MIT และมีผู้มีส่วนร่วมมากกว่า 450 คน

  • ทางเลือกอื่น ๆ

    • llama-swap: รองรับการโหลดหลายโมเดลและ hot-swap
    • LiteLLM: ให้พร็อกซีที่เข้ากันได้กับ OpenAI ข้ามหลายแบ็กเอนด์
    • LM Studio: ใช้ GUI, ใช้ llama.cpp, และรองรับ GGUF อย่างสมบูรณ์
    • Jan, Msty: แอปเดสก์ท็อปโอเพนซอร์สที่ออกแบบแบบ local-first
    • koboldcpp, Red Hat ramalama: รันโมเดลแบบคอนเทนเนอร์ พร้อม ระบุที่มาอย่างชัดเจน

บทสรุป: ทิศทางของระบบนิเวศ LLM แบบโลคัล

  • llama.cpp ของ Georgi Gerganov คือรากฐานของนวัตกรรม AI แบบโลคัล
    • ด้วยความร่วมมือของชุมชน จึงทำให้สามารถรันโมเดลทรงพลังบนฮาร์ดแวร์ผู้บริโภคได้
  • Ollama เติบโตขึ้นบนรากฐานนี้ แต่ สูญเสียความเชื่อถือจากการปกปิดที่มา, คุณภาพที่ตกลง, การปิดมากขึ้น, และการหันไปสู่คลาวด์
  • สิ่งที่ระบบนิเวศ LLM แบบโลคัลต้องการไม่ใช่ Ollama แต่คือ llama.cpp
    • เพราะความเปิดกว้างและประสิทธิภาพที่แท้จริงนั้น เครื่องมือที่ชุมชนขับเคลื่อนได้มอบให้แล้ว

บทความที่เกี่ยวข้อง

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

 
shblue21 12 일 전

ค่อนข้างเห็นด้วย และถ้าจะใช้งานบนเครื่องโลคัลได้อย่างจริงจัง ผมว่า LM Studio ดูจะดีกว่า
 
kirinonakar 12 일 전

ผมก็เริ่มต้นด้วย ollama เหมือนกันในตอนแรก แต่ช่วงนี้เปลี่ยนมาใช้ LM Studio นานแล้วครับ
 
GN⁺ 13 일 전
ความเห็นจาก Hacker News

  • ผู้ใช้ local LLM ส่วนใหญ่คิดว่าปัญหา UX ได้รับการแก้ไขแล้วด้วย Ollama
    สามารถรันโมเดลได้ด้วยคำสั่งบรรทัดเดียว และยังจัดการไดรเวอร์ ROCm ให้อัตโนมัติ
    ในทางกลับกัน llama.cpp แค่ชื่อก็ดูเหมือนไลบรารี C++ ทำให้ผู้ใช้ทั่วไปเข้าถึงได้ยาก
    ฉันแค่ไม่อยากต้องมาคอมไพล์โปรแกรมเอง แต่อยากลองใช้สนุก ๆ เท่านั้น

    • ตอนนี้ llama.cpp มี GUI มาให้เป็นค่าเริ่มต้นแล้ว เมื่อก่อนอาจไม่มี แต่ตอนนี้ยุคสมัยเปลี่ยนไปแล้ว
    • มีทางเลือกมากมายอย่าง “LM Studio, Jan, Msty, koboldcpp…” แต่ก็ยังสงสัยว่า ตัวสืบทอดที่แทนที่ Ollama ได้จริง คืออะไร
      ฉันใช้ Mac Mini แต่ก็โอเคกับเครื่องมือ CLI เช่นกัน จุดแข็งของ Ollama คือการติดตั้งและดาวน์โหลดโมเดลที่ง่ายมาก ดังนั้นก็หวังว่าเครื่องมือทดแทนจะสะดวกได้ในระดับนั้น
    • มีคนแนะนำให้ลอง kobold.cpp หรือ LM Studio ดู LM Studio ไม่ได้เป็นโอเพนซอร์ส แต่ให้เครดิต llama.cpp อย่างเหมาะสม
      คิดว่า การควบคุมคุณภาพ สำคัญ เพื่อไม่ให้มีการรวมการรองรับโมเดลแบบที่ยังพังอยู่หรืออัปโหลด GGUF ที่ผิดพลาด
    • เห็นด้วย นี่คล้ายกับกรณีของ Docker
      แน่นอนว่าคุณใช้ runc ตรง ๆ ก็ได้ แต่คนส่วนใหญ่เลือก docker run
      UX เป็นปัจจัยสำคัญของการยอมรับเทคโนโลยี และถ้าโปรเจ็กต์ทำอินเทอร์เฟซได้ไม่ดี ก็ไม่มีเหตุผลว่าทำไมการทำ wrapper ถึงจะเป็นเรื่องไม่ดี
    • ต่อให้ Ollama จะแก้ปัญหา UX ได้ ก็ไม่ได้ทำให้ การละเมิดไลเซนส์ กลายเป็นเรื่องยกเว้นความรับผิด

  • เหนื่อยที่จะต้องพูดข้ออ้างเดิมซ้ำ ๆ เลยรวบรวม ไทม์ไลน์และแหล่งข้อมูล ที่ตัวเองรู้ไว้ทีเดียว

    • มีคนบอกว่าขอบคุณที่เขียนบทความนี้ ฉันเองก็เคยมีส่วนร่วมกับ llama.cpp อยู่บ้าง และพฤติกรรมของผู้ก่อตั้ง Ollama ก็น่าผิดหวังมากจริง ๆ
      ทางเลือกที่แนะนำคือ llama-file โดย llamafile ของ Mozilla AI ทำงานได้ข้ามระบบปฏิบัติการในรูปแบบไฟล์รันเดี่ยว และเป็นโอเพนซอร์สเต็มรูปแบบ
      มันใช้ llama.cpp อย่างเป็นทางการบนพื้นฐาน CosmopolitanC ที่สร้างโดย Justine Tunney
    • ในฐานะคนที่ให้ความสำคัญกับจิตวิญญาณของ FOSS บอกว่านี่เป็น บทความที่ให้ความรู้มาก
    • มีคนบอกว่ามีหลายเรื่องที่ไม่เคยรู้มาก่อน
    • มีคนชื่นชมว่าสรุปและไทม์ไลน์ทำได้ยอดเยี่ยม

  • คิดว่า Ollama ใช้ง่ายกว่า 1000 เท่า
    llama.cpp ยอดเยี่ยม แต่ไม่เป็นมิตรกับผู้ใช้ทั่วไป
    ฉันเริ่มจาก Ollama แต่ย้ายไป llama.cpp เพื่อใช้การแก้ไขล่าสุด
    ถึงอย่างนั้นก็ยังใช้ Ollama จัดการโมเดลอยู่ มันสะดวกมากจนฉันทำ สคริปต์มาจัดการไดเรกทอรีแคช เอง

    • ในบล็อกโพสต์บอกว่าทางเลือกอื่นใช้งานได้ตรงไปตรงมา แต่ความจริงไม่ใช่แบบนั้น
      ถ้าเป็นแค่แอปแชตธรรมดาอาจพอได้ แต่ถ้าต้องการ OpenAI-compatible API และการจัดการโมเดล ความเข้าถึงง่ายจะลดลงอย่างมาก
    • มีคนบ่นเยอะว่า context size ค่าเริ่มต้นของ Ollama เล็กเกินไปจนโมเดลดูโง่
      ถ้าจะเปลี่ยนแบบถาวรก็ต้องสร้างไฟล์โมเดลใหม่ ซึ่งยิ่งซับซ้อนกว่าเดิม
      มองว่าวิธีแบบ Docker กลับไม่สะดวกสำหรับผู้ใช้ทั่วไป และสำหรับผู้ใช้ขั้นสูง llama.cpp ดีกว่า
    • อ้างอิงไว้ว่า ตอนนี้ llama.cpp มี router mode แล้ว จึงสลับโมเดลแบบเรียลไทม์ได้
    • เวอร์ชันล่าสุดทรงพลังขึ้นมาก ดูได้ที่ llama.cpp tools/serv
    • ฉันใช้ LM Studio มาตั้งแต่ 3 ปีก่อน และตอนนั้นมันก็ดีกว่า Ollama มากอยู่แล้ว

  • มีการสรุปมุมมองต่อไลเซนส์ MIT ไว้สองแบบ

    1. “แค่ให้เครดิตหนึ่งบรรทัด จะทำอะไรก็ได้”
    2. “ในทางกฎหมายอิสระก็จริง แต่ก็มี ความรับผิดชอบทางศีลธรรมต่อชุมชน”
      ผู้สร้าง llama.cpp อย่าง Georgi Gerganov แสดงความไม่พอใจแค่เรื่องการไม่ให้เครดิตเท่านั้น กล่าวคือเขามีพฤติกรรมใกล้เคียงกับการตีความแบบแรก
    • คิดว่าการตีความแบบที่สองไม่สมเหตุสมผล ถ้าอยากได้ ข้อผูกมัดแบบ GPL ก็ใช้ GPL ไปเลย
      MIT เป็นเอกสารทางกฎหมาย ไม่ใช่แนวทางศีลธรรม
      ส่วนตัวมองว่าซอฟต์แวร์สำหรับผู้ใช้ควรใช้ GPL มากกว่า
      ใช้ MIT แล้วค่อยมาบ่นว่าบริษัทเอาโค้ดไปก็เป็นเรื่องขัดแย้งในตัวเอง
      คิดว่าบริษัท ไม่มีศีลธรรม มีแต่คนเท่านั้นที่มี
    • ถ้า Georgi ต้องการ เขาก็เปลี่ยนเป็น GPL ได้ทุกเมื่อ แต่เขาไม่ได้ทำ
      สุดท้ายทั้งสองโปรเจ็กต์ก็ยังพัฒนาต่อ และผู้ใช้ก็มีทางเลือกมากขึ้น

  • เมื่อก่อนมันไม่สะดวกเพราะ เปลี่ยนโฟลเดอร์โมเดลเริ่มต้นไม่ได้
    ถ้าจะลงทะเบียนโมเดลต้องผ่านขั้นตอนคล้าย Dockerfile และโมเดลจะถูกคัดลอกไปเก็บใน hash storage ทำให้ย้ายตำแหน่งไม่ได้
    เลยย้ายไปใช้ LM Studio แทน ถึงจะไม่ใช่โอเพนซอร์สเต็มรูปแบบ แต่เปิดให้เห็นโฟลเดอร์โมเดลและเชื่อมกับ Hugging Face ได้

    • ตอนนี้ทำได้แล้ว สามารถกำหนด path ได้ด้วยตัวแปรแวดล้อม OLLAMA_MODELS ในไฟล์ตั้งค่าเซิร์ฟเวอร์
    • ฉันก็เคยเจอปัญหานี้เหมือนกัน ตอนจะเทียบกับ LM Studio ก่อนและหลังอัปเกรด SSD ขั้นตอนตามหาและจัดระเบียบตำแหน่งโมเดลมัน ซับซ้อนและทรมานโดยไม่จำเป็น มาก

  • โครงสร้างที่ Ollama คัดลอกไฟล์โมเดลไปไว้ใน hash blob storage ทำให้แชร์กับเครื่องมืออื่นไม่ได้
    มันน่าจะเป็นการออกแบบเพื่อ deduplication แต่ผลลัพธ์คือทำให้การลองใช้เครื่องมืออื่นยากขึ้น
    เพราะไฟล์โมเดลมีขนาดใหญ่มาก ทั้งพื้นที่เก็บข้อมูลและการดาวน์โหลดจึงเป็นภาระหนัก

  • บน Arch Linux ถ้ารัน pacman -Ss ollama จะได้ 16 รายการ แต่ llama.cpp หรือ lmstudio กลับได้ 0
    หวังว่าสักวันจะเปลี่ยนไป

    • llama.cpp อัปเดตเร็วเกินไป เลยอาจทำเป็นแพ็กเกจเสถียรได้ยาก แต่ติดตั้งจาก AUR ได้
      รองรับทั้ง Vulkan, ROCm และ CUDA
    • ส่วนบน openSUSE สามารถหา llamacpp ได้ด้วย zypper
      เวอร์ชันและการรองรับต่างกันไปตามดิสโทร ซึ่งสุดท้ายก็คือ เหตุผลที่มีลินุกซ์ดิสโทรจำนวนมาก
    • ฉันติดตั้งบน CachyOS ด้วย yay -S llama.cpp แล้วพบว่า เร็วกว่าและดีกว่า Ollama มาก

  • ชื่อ “llama.cpp” ตอนนี้ ฟังดูไม่เป็นมิตรแล้ว
    เมื่อก่อนมันหมายถึงโมเดล Llama ของ Meta แต่ตอนนี้มีโมเดลโอเพนซอร์สที่ทรงพลังกว่านั้นอีกมาก

  • ฉันหลีกเลี่ยง Ollama มาตั้งแต่แรก เพราะมันให้กลิ่นเหมือน พยายามควบคุม workflow ทั้งหมด
    และสุดท้ายก็คิดว่า เป็นการตัดสินใจที่ถูกต้อง

  • โครงสร้าง hash blob storage ของ Ollama คือกับดักที่ใหญ่ที่สุด
    ถ้าคุณดาวน์โหลดโมเดลมาหลายเดือนแล้ว พอต้องย้ายไปเครื่องมืออื่นก็ต้องดาวน์โหลดใหม่ทั้งหมด
    ผู้ใช้ส่วนใหญ่มักจะมารู้เรื่องนี้ก็ตอนลงทุนลงแรงไปลึกมากแล้ว และจะรู้สึกถึง ต้นทุนในการย้ายออก อย่างชัดเจน