รัน Gemma 4 เป็นโมเดลโลคัลใน Codex CLI

 (blog.danielvaughan.com)
40 คะแนน โดย GN⁺ 16 일 전 | 6 ความคิดเห็น | แชร์ทาง WhatsApp
  • กรณีศึกษาการรัน Gemma 4 ใน สภาพแวดล้อม Codex CLI แบบโลคัล แทนคลาวด์ เพื่อตรวจสอบประสิทธิภาพและความเสถียรของการเรียกใช้เครื่องมือ พร้อมยืนยัน ข้อได้เปรียบด้านต้นทุนและความเป็นส่วนตัว เมื่อเทียบกับ GPT-5.4
  • บน Mac(M4 Pro) 24GB ใช้ 26B MoE และบน NVIDIA GB10 128GB ใช้ 31B Dense โดยใช้ llama.cpp และ Ollama ตามลำดับเพื่อทำงานสร้างโค้ดเดียวกัน แล้วเปรียบเทียบประสิทธิภาพตามความต่างของการตั้งค่า
  • อัตราความสำเร็จของการเรียกใช้เครื่องมือดีขึ้นจาก 6.6% เป็น 86.4% แสดงให้เห็นว่าโมเดลโลคัลนำไปใช้งานจริงได้ และในสภาพแวดล้อม GB10 สามารถสร้างโค้ดได้สมบูรณ์
  • Mac มีความเร็วในการสร้างโทเคนสูงกว่า 5.1 เท่า แต่เพราะข้อจำกัดด้านหน่วยความจำและการตั้งค่า quantization จึงต้องลองซ้ำหลายครั้ง ขณะที่ GB10 แม้ช้ากว่าแต่สำเร็จตั้งแต่ครั้งแรก
  • โดยสรุป โมเดลโลคัลก็สร้างโค้ดในระดับใช้งานจริงได้ และแนะนำ แนวทางแบบไฮบริด ที่ใช้การประมวลผลโลคัลสำหรับงานที่เน้นความเป็นส่วนตัว และสลับไปคลาวด์สำหรับงานซับซ้อน

แรงจูงใจในการเปลี่ยนไปใช้โมเดลโลคัล

  • ปัญหาเรื่อง ต้นทุน เพราะรัน Codex CLI หลายเซสชันต่อวัน และบางครั้งรันพร้อมกันแบบขนาน ทำให้ค่า API สะสม
  • ความต้องการด้าน ความเป็นส่วนตัว เพราะบางโค้ดเบสไม่ควรถูกส่งออกไปยังเซิร์ฟเวอร์ภายนอก
  • ต้องการ ความเสถียร เพราะ cloud API มีความเสี่ยงเรื่อง throttling, outage และการเปลี่ยนแปลงราคา
  • เหตุผลที่ก่อนหน้านี้ยังไม่ลองโมเดลโลคัลคือไม่รองรับ การเรียกใช้เครื่องมือ (tool calling) ซึ่งเป็นคุณค่าหลักของ Codex CLI ที่ให้โมเดลอ่านไฟล์ เขียนโค้ด รันทดสอบ และ apply patch ได้
  • Gemma รุ่นก่อนหน้ามีคะแนน benchmark การเรียกฟังก์ชันใน tau2-bench เพียง 6.6% (ล้มเหลว 93 ครั้งจาก 100 ครั้ง) แต่ Gemma 4 31B กระโดดขึ้นเป็น 86.4% จนคุ้มค่าจะนำมาทดสอบ

ขั้นตอนการตั้งค่าบน Mac

  • เริ่มจาก Ollama แต่ใน v0.20.3 เกิดบั๊กสตรีมมิงที่ทำให้การตอบสนองแบบเรียกใช้เครื่องมือของ Gemma 4 ถูกส่งผิดไปเป็น reasoning output แทนที่จะอยู่ในอาร์เรย์ tool_calls
  • เมื่อใช้ Gemma 4 บน Apple Silicon จะเกิด Flash Attention freeze กับพรอมป์ตที่ยาวเกินประมาณ 500 โทเคน ขณะที่ system prompt ของ Codex CLI ยาวราว 27,000 โทเคน จึงแทบใช้งานไม่ได้
  • จึงเปลี่ยนไปใช้ llama.cpp ติดตั้งผ่าน Homebrew และคำสั่งเซิร์ฟเวอร์ที่ใช้งานได้ต้องมีแฟล็กสำคัญ 6 ตัว
    • -np 1: จำกัดไว้ที่ 1 slot เพราะหลาย slot จะเพิ่มการใช้หน่วยความจำของ KV cache แบบทวีคูณ
    • -ctk q8_0 -ctv q8_0: quantize KV cache เพื่อลดจาก 940MB เหลือ 499MB
    • --jinja: จำเป็นสำหรับเทมเพลตการเรียกใช้เครื่องมือของ Gemma 4
    • ต้องระบุพาธ GGUF โดยตรงใน -m และไม่ใช้แฟล็ก -hf เพราะจะดาวน์โหลด vision projector ขนาด 1.1GB อัตโนมัติจนทำให้ OOM crash
  • ในการตั้งค่า Codex CLI ต้องกำหนด web_search = "disabled" เพราะ Codex CLI จะส่งชนิดเครื่องมือ web_search_preview ที่ llama.cpp ปฏิเสธ

ขั้นตอนการตั้งค่าบน GB10

  • vLLM 0.19.0 คอมไพล์มาบน PyTorch 2.10.0 แต่ PyTorch ที่รองรับ CUDA สำหรับ aarch64 Blackwell(compute capability sm_121) มีเพียง 2.11.0+cu128 จึงเกิด ImportError จาก ABI ไม่ตรงกัน
  • หากคอมไพล์ llama.cpp จากซอร์สด้วย CUDA แม้คอมไพล์และ benchmark จะผ่าน แต่ llama.cpp ปฏิเสธชนิดเครื่องมือที่ไม่ใช่ฟังก์ชันซึ่งถูกส่งมาจาก wire_api = "responses" ของ Codex CLI
  • ใช้งานได้สำเร็จบน Ollama v0.20.5 และบั๊กสตรีมมิงที่เจอบน Apple Silicon ไม่เกิดซ้ำบน NVIDIA
    • รัน ollama pull gemma4:31b แล้วทำ SSH tunnel เพื่อ forward พอร์ต 11434 มายัง Mac (เพราะโหมด --oss ของ Codex CLI ตรวจเฉพาะ localhost)
    • ใช้ codex --oss -m gemma4:31b แล้วทั้งการสร้างข้อความและการเรียกใช้เครื่องมือทำงานได้ตั้งแต่ครั้งแรก
  • การตั้งค่าบน Mac ใช้เวลาเกือบทั้งบ่าย ส่วน GB10 ใช้เวลาประมาณ 1 ชั่วโมง รวมเวลารอดาวน์โหลดโมเดล

ผลลัพธ์เบนช์มาร์ก

  • ทั้งสามการตั้งค่าได้รับงานเดียวกัน: ใช้ codex exec --full-auto เพื่อเขียนฟังก์ชัน Python ชื่อ parse_csv_summary พร้อมการจัดการข้อผิดพลาด เขียนและรันทดสอบ
  • GPT-5.4 (คลาวด์): สร้างโค้ดที่มี type hints, exception chaining ที่เหมาะสม, การตรวจจับชนิด boolean และ helper function ที่สะอาด ผ่านการทดสอบ 5 รายการตั้งแต่ครั้งแรก ใช้เวลา 65 วินาที และไม่ต้องเก็บงานต่อ
  • GB10 31B Dense: ไม่มี type hints หรือการตรวจจับ boolean แต่มีการจัดการข้อผิดพลาดที่แข็งแรง ไม่มี dead code ผ่านการทดสอบ 5 รายการตั้งแต่ครั้งแรกด้วยการเรียกใช้เครื่องมือ 3 ครั้ง ใช้เวลา 7 นาที
  • Mac 26B MoE: เหลือ dead code อยู่ในส่วน implementation เขียนลูปอนุมานชนิดข้อมูลแล้วปล่อยทิ้งไว้ ก่อนจะเขียนใหม่ด้านล่างพร้อมคอมเมนต์ว่า Actually, let's simplify และต้อง ลอง 5 ครั้ง กว่าจะเขียนไฟล์ทดสอบได้สำเร็จ
    • แต่ละครั้งเกิดข้อผิดพลาด heredoc คนละแบบ เช่น filerypt → file_path, encoding=' 'utf-8' (มีการแทรกช่องว่าง), fileint(file_path) เป็นต้น
    • งานที่ GB10 ทำเสร็จใน 3 ครั้ง ต้องใช้ 10 ครั้งของการเรียกใช้เครื่องมือ บน Mac
    • ผลนี้เป็นผลของสภาพแวดล้อม Codex CLI แบบ Q4_K_M บนเครื่อง 24GB และไม่ควรตีความว่าเป็นข้อสรุปทั่วไปต่อ Gemma 4 บน Apple Silicon ทั้งหมด

การวิเคราะห์ความเร็ว: ทำไม Mac ถึงเร็วเกินคาด

  • ใช้ llama-bench วัดทั้งสองเครื่องด้วยความยาวคอนเท็กซ์เท่ากัน พบว่า Mac สร้างโทเคนได้เร็วกว่า GB10 5.1 เท่า
  • ทั้งสองเครื่องมีแบนด์วิดท์หน่วยความจำ 273 GB/s LPDDR5X เท่ากัน แต่การสร้างโทเคนเป็นงานที่ติดคอขวดด้านแบนด์วิดท์หน่วยความจำ
    • 31B Dense ต้องอ่านพารามิเตอร์ทั้งหมด 31.2 พันล้านตัว ต่อหนึ่งโทเคน (ประมาณ 17.4GB)
    • 26B MoE เปิดใช้งานเพียง 3.8 พันล้านตัว ต่อหนึ่งโทเคน (ประมาณ 1.9GB)
    • ภายใต้แบนด์วิดท์เท่ากัน Mac ทำได้ 52 tok/s ส่วน GB10 ทำได้ 10 tok/s
  • ความเร็วในการประมวลผลพรอมป์ตก็ดีกว่าที่คาด โดย Mac ทำได้ใกล้เคียง: ที่คอนเท็กซ์ 8K Mac ได้ 531 tok/s เทียบกับ GB10 ที่ 548 tok/s ซึ่งสะท้อนว่า sparse activation ของ MoE ช่วยในการประมวลผลพรอมป์ตด้วย

บทเรียนสำคัญ: อัตราสำเร็จตั้งแต่ครั้งแรกสำคัญกว่าความเร็วโทเคน

  • แม้ Mac จะสร้างโทเคนได้เร็วกว่า 5.1 เท่า แต่เวลาจบงานจริงสั้นลงเพียง 30% (4 นาที 42 วินาที เทียบกับ 6 นาที 59 วินาที)
  • สาเหตุของความต่างด้านเวลาคือ การลองซ้ำ: เรียกใช้เครื่องมือ 10 ครั้งเทียบกับ 3 ครั้ง, ล้มเหลวในการเขียนเทสต์ 5 ครั้ง และมี dead code ที่โมเดลไม่เก็บกวาด
  • โมเดลคลาวด์ยิ่งพิสูจน์ประเด็นนี้ชัดกว่า: เร็วที่สุด ใช้โทเคนน้อยที่สุด ไม่ต้องมีรอบซ่อม และจบ 5/5 ใน 65 วินาที
  • อย่างไรก็ดี การรันแบบโลคัลก็ใช้งานได้จริง เพราะทั้งสองเครื่องสร้างโค้ดที่ทำงานได้และผ่านการทดสอบ
  • ช่องว่างด้านคุณภาพจาก Gemma 3 (tool calling 6.6%) ไปสู่ Gemma 4 (86.4%) คือจุดเปลี่ยนสำคัญ จากระดับ “ใช้ไม่ได้” ไปสู่ “ใช้ได้” ซึ่งทำให้ local agentic coding ใช้งานได้จริง
  • ข้อสังเกตต่อผลบน Mac: Q4_K_M คือ quantization สูงสุดที่พอใส่ในเครื่อง 24GB ได้ และผลลัพธ์อาจเปลี่ยนหากนำไปรันใหม่บน Apple Silicon ที่มีหน่วยความจำมากกว่าและใช้ quantization สูงกว่า
  • สามารถใช้ แนวทางแบบไฮบริด ได้: ใช้ codex --profile local กับงานซ้ำ ๆ และงานที่อ่อนไหวต่อความเป็นส่วนตัว แล้วใช้ค่าปริยายบนคลาวด์กับงานที่ซับซ้อน โดยสลับผ่านระบบ profile ของ Codex CLI ด้วยแฟล็กเพียงตัวเดียว

เคล็ดลับเชิงปฏิบัติระหว่างตั้งค่า

  • Apple Silicon: ใช้ Ollama กับ Gemma 4 ไม่ได้ จึงแนะนำ llama.cpp + --jinja
    • ตั้งค่า web_search = "disabled" ในโปรไฟล์ของ Codex CLI
    • ระบุพาธ GGUF โดยตรงด้วย -m และอย่าใช้ -hf
    • ตั้งคอนเท็กซ์เป็น 32,768 (เพราะ system prompt ของ Codex CLI ต้องใช้ขั้นต่ำ 27,000 โทเคน)
    • quantize KV cache: -ctk q8_0 -ctv q8_0
  • NVIDIA GB10: Ollama v0.20.5 เป็นเส้นทางแรกที่ทำงานได้เสถียร ใช้ codex --oss -m gemma4:31b และถ้าเป็นเครื่องระยะไกลให้ทำ SSH tunnel พอร์ต 11434
  • ในการตั้งค่า provider ต้องกำหนด stream_idle_timeout_ms อย่างน้อย 1,800,000 เพราะบน Mac หนึ่งรอบของการเรียกใช้เครื่องมือใช้เวลา 1 นาที 39 วินาที ซึ่งจะทำให้เซสชันถูกตัดด้วย timeout ปริยาย
  • แนะนำให้ ตรึงเวอร์ชัน ของ llama.cpp เพราะมีรายงานว่าแต่ละบิลด์อาจทำให้ความเร็วลดลงได้ถึง 3.3 เท่า จนผล benchmark เปลี่ยนได้ข้ามคืน

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

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

 
tsboard 16 일 전

ผมลองรัน Gemma4-31B ในบริษัทด้วย H100 2 ใบแล้วพบว่า

  1. คุณภาพคำตอบถือว่าใช้ได้ทีเดียว และรองรับภาษาเกาหลีได้ดี
  2. มันตัดสินใจเรื่องการเรียกใช้เครื่องมือได้ดี และยังสรุปผลหลังการรันได้ดีด้วย
  3. แต่ก็ต้องบอกว่านี่คือระดับที่ว่า "น่าทึ่งเมื่อพิจารณาว่าเป็นโมเดล 31B พารามิเตอร์" เท่านั้น และแน่นอนว่าเมื่อเทียบกับโมเดลที่มีพารามิเตอร์ใหญ่กว่า (เช่น MiniMax-M2.5) ก็เป็นความจริงที่คุณภาพโดยรวมของคำตอบยังด้อยกว่า

โดยรวมแล้ว ถ้าต้องการการทำงานที่เล็กและรวดเร็ว Gemma4 ก็น่าจะเพียงพอแล้ว สำหรับผม เปลี่ยนจาก GPT-OSS-120B → Qwen3.5-35B-A3B แล้วตอนนี้มาลงตัวที่ Gemma4-31B ซึ่งค่อนข้างน่าพอใจ คิดว่าน่าจะใช้ต่อไปเรื่อย ๆ ครับ
 
kaydash 16 일 전

โห ใช้เว็บเสิร์ชไม่ได้เหรอ! ถึงจะตั้งค่า searxng ก็ใช้ไม่ได้เหรอ
 
ysm0622 16 일 전

https://github.com/ysm-dev/skills/blob/main/skills/web-search/SKILL.md

ลองใช้แทนสกิลนี้ดูครับ 555
 
yangeok 16 일 전

อยากลองเช็กดูว่าใช้งานภาษาเกาหลีได้ดีไหมเหมือนกัน
 
GN⁺ 16 일 전
ความคิดเห็นจาก Hacker News

  • Gemma 4 26B แสดงประสิทธิภาพที่โดดเด่นมากเมื่อเทียบกับโมเดลที่มีขนาดพารามิเตอร์ใกล้เคียงกัน
    ในเบนช์มาร์กภายในทำคะแนนได้ใกล้กับ GPT 5.2 และ Gemini 3 Pro Preview แต่ยังอ่อนกว่าในงานด้านagentic codingและการตัดสินใจที่ไม่ใช่งานโค้ด
    คะแนนตกในด้านการใช้เครื่องมือ การปรับปรุงซ้ำหลายรอบ และการจัดการคอนเท็กซ์ขนาดใหญ่ แถมในสถานการณ์ที่ควรต้องใช้เครื่องมือกลับทำผลงานได้แย่ลง
    น่าจะเป็นการ overfit กับ harness หรือ benchmark ทั่วไปอยู่พอสมควร ถึงอย่างนั้นความเร็วบน Macbook ชิปตระกูล M ก็ยังน่าทึ่งมาก
    ดูเบนช์มาร์กได้ที่ gertlabs.com

    • ในการทดสอบ ‘hello world’ ของฉันมันไม่ผ่าน
      โจทย์คือ “ทำเครื่องคำนวณ 1D bin fitting เป็นเว็บเพจเดียว” โดย Qwen3.5, Nematron, Step 3.5 และ gpt-oss ผ่านหมด แต่ Gemma ทำไม่ได้
    • โดยรวมถือเป็นโมเดล open weights ที่ดี
      แต่บน M5 ของฉันมันยังพลาดเรื่องโค้ดพื้นฐานบ่อยกว่า GPT-OSS ถึงอย่างนั้นภาพรวมก็ยังอยู่ในระดับใกล้เคียงกัน
    • แปลกใจที่ Gemma 31B ได้คะแนนต่ำกว่า 26B-A4B

  • มีคนบอกว่าน่าแปลกที่ผลลัพธ์ออกมาว่า “คุณภาพของโมเดลสำคัญกว่าความเร็วโทเคน”
    จริง ๆ ฟังดูเป็นเรื่องปกติอยู่แล้ว และแทนที่จะจำกัดคอนเท็กซ์ไว้ที่ 32k ก็ยังสามารถ offload งาน MoE ไปที่ CPU ด้วยตัวเลือก --cpu-moe ได้

    • ฉันมองว่าความเร็วโทเคนสุดท้ายแล้วมีผลแค่กับความเร็วในการทำงานให้เสร็จเท่านั้นไม่ใช่หรือ
    • มันเหมือนดื่มกาแฟตอนเหนื่อย ๆ ยังเหนื่อยเหมือนเดิม แค่ขยับตัวได้ “เร็วขึ้น” เท่านั้น
    • ในมุมของคนที่ใช้ Codex ทุกวัน สิ่งที่สำคัญกว่าความเร็วคือโมเดลต้องไม่ติดลูปไร้สาระ
      ถ้ามีแต่ความเร็วโทเคนสูง สุดท้ายก็จะมีแต่ ‘AI slop codebase’ เพิ่มขึ้นเต็มไปหมด

  • ตอนนี้ฉันกำลังรัน google/gemma-4-26b-a4b บน M3 Ultra (RAM 48GB) ด้วย LM Studio และ Opencode
    ต้องเพิ่มคอนเท็กซ์เป็น 65536 แต่ก็ทำงานได้ดี และเชื่อมกับ Zed กับ ACP ได้ง่ายด้วย
    ตอนนี้ใช้หลัก ๆ กับรีวิวโค้ดง่าย ๆ หรือสร้างโค้ดฟรอนต์เอนด์

    • ฉันก็ใช้สภาพแวดล้อมคล้ายกัน ลอง pi-coding-agent ดูได้
      system prompt กับ overhead ของเครื่องมือรวมกันยังไม่ถึง 2k tokens ทำให้prefill latency สั้นลงมาก
    • ฉันใช้บน AMD RX7900XTX (VRAM 24GB) โดยเปิด 4 แชตพร้อมกันด้วยคอนเท็กซ์ 512K
      ความเร็วประมาณ 100t/s เร็วแทบจะทันที และเริ่มใช้ Claude Code น้อยลงเรื่อย ๆ
    • ฉันลองรันเวอร์ชัน MLX บน M1 Macbook แล้วผูกกับ XCode แต่กับ iOS codebase ขนาดเล็กมันกลับค้างกลางทาง
      ใช้เป็นแชตบอตพอได้ แต่ไม่เหมาะกับการผูกกับ XCode
    • ฉันลองรันตัวเต็ม 31B บน GPU ของ Runpod แล้วค่อนข้างประทับใจ
      ตอนนี้เลยใช้ Google API ที่ให้ฟรีวันละ 1500 requests อยู่
    • ฉันใช้การตั้งค่าเดียวกันบน MacBook Pro M4 Max (64GB)
      ก่อนอัปเดต LM Studio 0.4.11+1 การเรียกใช้เครื่องมือยังใช้ไม่ได้ แต่ตอนนี้ใช้ได้ดีทั้ง Codex และ Opencode

  • คำพูดที่ว่า “โมเดลโลคัลเรียกใช้เครื่องมือไม่ได้” นั้นไม่จริง
    ฉันใช้การเรียกเครื่องมือบนโลคัลมาตั้งแต่ 2 ปีก่อนแล้ว และการที่บอกว่า Gemma3 มีอัตราสำเร็จของการเรียกเครื่องมือแค่ 7% มันไม่น่าเป็นไปได้
    แม้แต่ Llama3.3 ยังได้อย่างน้อย 75%

    • ฉันก็สะดุดกับประโยคนั้นเหมือนกัน คงเป็นเพราะผู้เขียนเพิ่งลองรันโมเดลโลคัลครั้งแรก
      โมเดลที่ถูก quantize หนักเกินไปอย่าง Gemma 4 gguf Q4 (16GB) จะทำให้ประสิทธิภาพตกลงมาก
    • แต่ก็จริงที่เบนช์มาร์ก Tau function calling ของ Gemma 3 กับ 4 ต่างกันมาก
    • ทั้งบทความให้อารมณ์เหมือน AI สร้างขึ้นมา
      ถ้ามีเครื่อง GB10 ก็แนะนำให้ลองเซ็ต spark-vllm-docker หรือใช้ Qwen 3.5 122B A10B เวอร์ชันปรับแต่งแล้ว เร็วพอตัวที่ราว 50tk/s

  • ฉันอัปเกรดจาก M4 Pro (24GB) ไปเป็น M5 Pro (48GB) และ Gemma 4 MoE (Q4) ตัวเดิมให้ค่า t/s เร็วขึ้น 8 เท่า
    แม้แต่ความเร็วในการโหลดจากดิสก์เข้าเมมโมรีก็เร็วขึ้น 2 เท่า

    • ถ้า RAM เยอะพอ แนะนำให้รัน Q8_0 โดยตรง นอกจากตอนโหลดครั้งแรกแล้วก็ไม่ได้ช้า และคุณภาพก็แทบไม่ต่างกัน
      ควรเช็กด้วยว่าใช้เวอร์ชัน MLX หรือไม่ เวอร์ชัน quantization ของชุมชน mlx-lm เพิ่งถูกแก้ไขไปไม่นานนี้
      สำหรับฉัน 16GB M1 Macbook ค่อนข้างไม่ไหว แต่บน AMD Framework 13 ที่มี RAM 64GB แม้ใช้แต่ CPU ก็ยังเร็วพอ
      ฟีเจอร์prompt cacheมีประโยชน์มากเวลาใส่ system prompt ขนาดใหญ่

  • มีการเสนอแนวคิด harness ที่ปล่อยให้ฮาร์ดแวร์โลคัลทำงาน 24/7 เพื่อรันการทดลองอัตโนมัติด้วยโมเดลอย่าง Gemma 4 แล้วค่อยส่งการตัดสินใจใหญ่ ๆ ให้ Claude Opus
    โครงสร้างคือให้โมเดลโลคัลทำการทดลองย่อยและ POC ก่อน แล้วถ้าติดขัดค่อยขอความช่วยเหลือจาก Opus
    วิธีนี้ทำให้ควบคุม prompt caching ได้ทั้งหมดและมีค่าใช้จ่ายแทบเป็นศูนย์

    • Nico Bailon ผู้พัฒนาส่วนขยายของ Pi coding agent ของ Mario กำลังลองแนวทางคล้ายกันอยู่
      ดูได้จากวิดีโอเดโม และรีโป pi-model-switch

  • สำหรับงานโค้ด การ quantize ต่ำกว่า Q6_K แทบไม่มีประโยชน์
    เพราะเมื่อ quantize ต่ำกว่านั้นอัตราความผิดพลาดของโค้ดจะพุ่งขึ้นมาก

    • คนส่วนใหญ่ไม่รู้เรื่องนี้ จำนวนโทเคนสำคัญน้อยกว่าคุณภาพของโทเคน
      ถ้าเมมโมรีพอ ก็ควรใช้ quantization ที่สูงที่สุดเท่าที่จะทำได้

  • อยากเห็นการเปรียบเทียบคุณภาพตามวิธี quantization อย่าง Q4_K_M, Q8_0, Q6_K ฯลฯ น่าจะมีประโยชน์กว่าดูแค่ตัวเลข tok/s อย่างเดียว

  • อยากรู้ว่า Qwen3.5 กับ Gemma 4 ต่างกันอย่างไร
    โดยเฉพาะโมเดล Qwen3.5-27B-Claude-4.6-Opus ที่ทำมาสำหรับการเรียกใช้เครื่องมือโดยเฉพาะ และมียอดดาวน์โหลดเกิน 5 แสนครั้งแล้ว

    • ฉันกำลังดู คู่มือ fine-tuning ที่ Jackrong เผยแพร่อยู่ ตัวอย่างบนโน้ตบุ๊กก็จัดไว้ดีมาก
    • ฉันทดสอบเองบน DGX Spark แล้ว สุดท้ายก็กลับมาใช้ Gemma 4
      โมเดล Qwen มีปัญหาขอให้ช่วยแก้ข้อผิดพลาดระหว่าง orchestration บ่อยเกินไปจนประสิทธิภาพการทำงานลดลง
      ฉันรันผ่าน weights สำหรับ Ollama
    • ฉันค่อนข้างสงสัยกับคำอ้างว่าผู้พัฒนาเดี่ยวจะดันประสิทธิภาพได้เหนือกว่าสถาบันวิจัยใหญ่ ๆ
      เวอร์ชันล่าสุดคือ Qwopus3.5-27B-v3

  • ฉันใช้ Gemma 4 มาหลายวันแล้ว มันเร็วและฉลาด แต่ปัญหาการใช้เครื่องมือก็ยังอยู่
    ข้อจำกัดคือสติปัญญามากกว่าความเร็ว ทำให้ผลิตภาพยังถูกจำกัด และมันยังติดลูปบ่อย
    ถ้าตรวจจับสถานการณ์แบบนี้ได้แล้วให้มัน “ขอความช่วยเหลือ” จากโมเดลที่ฉลาดกว่าก็คงดี
    ตอนนี้ฉันทำงานเหมือนผู้ควบคุม orchestration ของเอเจนต์มากกว่าจะเป็นคนเขียนโค้ดแล้ว คือคอยจัดการเอเจนต์หลายตัวที่ทำงานขนานกัน

    • ไม่นานมานี้ Google ได้เปลี่ยน chat_template.jinja และ tokenizer_config.json ของ gemma-4-31B-it
      เขาว่าจะแก้ปัญหาเกี่ยวกับการเรียกใช้เครื่องมือแล้ว ดังนั้นควรอัปเดตโมเดล
 
boolsee 15 일 전

การตั้งค่า local LLM ด้วย ollama นั้นทำได้ง่ายก็จริง แต่บอกกันว่ามีโอกาสสูงที่การเรียกใช้เครื่องมือของโมเดลโอเพนซอร์สแต่ละตัวจะล้มเหลว สาเหตุน่าจะมาจากการผสมกันระหว่างข้อกำหนดที่ค่อนข้างหลวมภายใน ollama กับปัญหา parser สำหรับการเรียกใช้เครื่องมือที่แตกต่างกันไปในแต่ละโมเดล
แต่ปัญหาที่เป็นรากฐานที่สุดของ Local LLM จริง ๆ คือการต้องใช้ฮาร์ดแวร์ราคาแพงเพื่อรันโมเดลขนาดกลางถึงขนาดใหญ่ โดย MAC Studio รุ่น 32GB ก็อยู่ที่ราว 3 ล้านวอนกลาง ๆ ส่วน GB10 ก็ประมาณ 5–6 ล้านวอน ทำให้คนทั่วไปจะซื้อมาเพื่อเป็นงานอดิเรก(?) ก็ค่อนข้างเป็นภาระอยู่ดี สำหรับ Local LLM นั้นเหมาะกับโมเดลขนาดเล็ก ส่วนโมเดลขนาดกลางถึงใหญ่ก็ดูเหมือนจะไม่มีทางเลือกอื่นนอกจาก Cloud