วิธีตั้งค่าเอเจนต์เขียนโค้ดแบบโลคัลบน macOS

 (ikyle.me)
1 คะแนน โดย GN⁺ 3 시간 전 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • การตั้งค่า เอเจนต์เขียนโค้ดแบบโลคัล คือการทำให้สามารถรันโมเดลผ่าน API ที่เข้ากันได้กับ OpenAI บน macOS ได้แม้ตอนอินเทอร์เน็ตล่ม และให้ Pi จัดการอินพุตทั้งข้อความและรูปภาพได้
  • ใช้ llama.cpp Metal และโมเดล Gemma 4 26B-A4B GGUF บน Apple M1 Max 64GB, macOS 15.7.7 โดยความเร็วการสร้างข้อความพื้นฐานอยู่ที่ 58.2 tok/s
  • หลังเพิ่ม MTP draft model และปรับ --spec-draft-n-max 3 ความเร็วการสร้างข้อความเพิ่มเป็น 72.2 tok/s หรือดีขึ้นราว 24%
  • ต้องโหลด mmproj-BF16.gguf ด้วย --mmproj และตั้งค่าอินพุตโมเดลของ Pi เป็น ["text", "image"] จึงจะส่งต่อ อินพุตรูปภาพ อย่างสกรีนช็อตได้
  • การตั้งค่าขั้นสุดท้ายคือรันเซิร์ฟเวอร์ llama.cpp ที่ 127.0.0.1:8080/v1 แล้วให้ Pi ใช้เป็นผู้ให้บริการแบบโลคัล ส่วน Qwen3.6 35B-A3B ให้ผล benchmark ของเอเจนต์เขียนโค้ดดีกว่า แต่ในการทดสอบนี้ช้ากว่าที่ 55 tok/s

เป้าหมายของการตั้งค่าเอเจนต์เขียนโค้ดแบบโลคัล

  • มีอินเทอร์เน็ตล่มหลายครั้งจนไม่สามารถใช้เอเจนต์เขียนโค้ดได้ จึงเป็นจุดเริ่มต้นที่ลองตั้งค่าให้รันแบบโลคัล
  • การตั้งค่าที่ต้องการคือต้องเร็วพอสำหรับใช้งานจริงบน Mac และต้องใช้งานจากเครื่องมืออื่นได้ผ่าน OpenAI-compatible API
  • เป้าหมายคือให้รองรับการประมวลผลสกรีนช็อตหรือรูปภาพเมื่อจำเป็น เพื่อป้อนผลลัพธ์ที่เอเจนต์สร้างขึ้นกลับเข้าไปเป็นอินพุตได้
  • การตั้งค่าขั้นสุดท้ายประกอบด้วย llama.cpp, Gemma 4 26B-A4B GGUF, Q8 MTP draft model, Gemma 4 multimodal projector และเอเจนต์เขียนโค้ดบนเทอร์มินัล Pi
  • สภาพแวดล้อมที่ใช้ทดสอบคือ Apple M1 Max, unified memory 64GB และ macOS 15.7.7

โมเดล

  • โมเดลหลักคือ gemma-4-26B-A4B-it-UD-Q4_K_XL.gguf ซึ่งอยู่ใน repository unsloth-gemma-4-26B-A4B-it-GGUF บน Hugging Face
  • ไฟล์นี้มีขนาดราว 16GB และเมื่อรวม MTP draft head กับ multimodal projector แล้ว โฟลเดอร์โมเดลจะมีขนาดประมาณ 17GB
  • พรอมป์ต์สำหรับ benchmark คือ Write a compact Python function that parses a unified diff and returns the changed file paths. Then explain two edge cases.
  • benchmark แต่ละครั้งสร้างข้อความประมาณ 128 โทเค็น

การรันพื้นฐาน: llama.cpp + Metal

  • รันโมเดลหลักโดยตรงด้วย llama.cpp และ Metal acceleration
  • คำสั่งรันใช้ llama-cli โดยระบุ path ของโมเดล พร้อม -ngl 999, -fa on, -c 4096, -n 128
  • ในการตั้งค่าพื้นฐาน ความเร็วประมวลผลพรอมป์ต์อยู่ที่ 298.0 tok/s และความเร็วการสร้างข้อความอยู่ที่ 58.2 tok/s
  • 58 tok/s ไม่ได้เร็วมากแต่ยังอยู่ในระดับที่ใช้งานได้ และงานของเอเจนต์เขียนโค้ดต้องการความเร็วให้มากที่สุดเท่าที่ทำได้ เพราะมีการเรียกใช้เครื่องมือจำนวนมาก

เพิ่ม MTP draft model

  • Gemma 4 มี MTP draft model ให้ในรูปแบบ MTP/gemma-4-26B-A4B-it-Q8_0-MTP.gguf
  • ใน llama.cpp จะโหลดโมเดลนี้สำหรับ speculative decoding ผ่าน --model-draft, --spec-type draft-mtp, --spec-draft-n-max
  • การรัน MTP ครั้งแรกทำได้ 69.2 tok/s ที่ draft token 4 ตัว
  • เอกสารของ Unsloth แนะนำให้เริ่มที่ --spec-draft-n-max 2 แต่ให้ทดสอบตั้งแต่ 1 ถึง 6 ตามฮาร์ดแวร์เพื่อหาค่าที่เร็วที่สุด
  • หลังปรับ --spec-draft-n-max พบว่าค่า draft token 3 ตัวเร็วที่สุดที่ 72.2 tok/s
  • โมเดลหลักเดี่ยว ๆ ได้ 58.2 tok/s ส่วนการตั้งค่าที่เพิ่ม Q8 MTP draft model ได้ 72.2 tok/s
  • ความเร็วประมวลผลพรอมป์ต์แทบไม่เปลี่ยน แต่ความเร็วการสร้างข้อความดีขึ้นราว 24%

ผลการจูน MTP

  • มีการทดสอบค่า --spec-draft-n-max ตั้งแต่ 1 ถึง 6
  • ค่า 1 ได้พรอมป์ต์ 295.5 tok/s, สร้างข้อความ 68.4 tok/s
  • ค่า 2 ได้พรอมป์ต์ 299.1 tok/s, สร้างข้อความ 72.0 tok/s
  • ค่า 3 ได้พรอมป์ต์ 295.6 tok/s, สร้างข้อความ 72.2 tok/s ซึ่งเร็วที่สุด
  • ค่า 4 สร้างข้อความได้ 70.7 tok/s, ค่า 5 ได้ 63.7 tok/s, ค่า 6 ได้ 61.2 tok/s ซึ่งช้าลง
  • บน M1 Max ค่าที่เร็วที่สุดคือ 3 และค่า 2 ก็ให้ผลใกล้เคียงมาก

เปรียบเทียบกับ MLX

  • เพื่อดูว่ามีวิธีที่เร็วกว่าสำหรับรันโมเดลบน Mac หรือไม่ จึงทดสอบโมเดล MLX ที่ใช้ mlx-lm ด้วย
  • llama.cpp Metal + MTP ทำได้ 72.2 tok/s ด้วยชุด Unsloth GGUF Q4 + Q8 MTP
  • llama.cpp Metal เดี่ยว ๆ ทำได้ 58.2 tok/s ด้วย Unsloth GGUF Q4
  • MLX-LM ทำได้ 45.8 tok/s บน Unsloth UD MLX 4-bit
  • MLX-LM ทำได้ 43.9 tok/s บน mlx-community 4-bit และ 38.1 tok/s บน mlx-community OptiQ 4-bit
  • ในการตั้งค่านี้ llama.cpp เร็วกว่า MLX และ llama.cpp ที่ใช้ MTP เป็นตัวเลือกที่ดีที่สุด
  • ยังได้ลอง Gemma 4 MTP ผ่าน gemma-4-swift-mlx ด้วย แต่ checkpoint MLX 26B 4-bit ที่ทดสอบไม่ตรงกับ weight key ที่ loader คาดไว้ จึงหยุดไว้ก่อนโดยไม่ดาวน์โหลดและปรับแต่งโมเดลใหม่

เพิ่มการรองรับรูปภาพ

  • หากต้องการแนบสกรีนช็อตใน Pi อินพุตของโมเดลต้องไม่ใช่ข้อความอย่างเดียว
  • เดิมทีรายการโมเดลโลคัลถูกตั้งเป็น "input": ["text"] และในกรณีนี้ Pi จะส่งเอาต์พุตจากเครื่องมือรูปภาพเข้าโมเดลได้ไม่ถูกต้อง
  • ฝั่งเซิร์ฟเวอร์ llama.cpp ก็ต้องใช้ Gemma 4 multimodal projector คือ mmproj-BF16.gguf สำหรับความสามารถแบบ multimodal
  • เมื่อโหลด projector ด้วย --mmproj แล้ว llama.cpp จะประกาศการรองรับ multimodal และ Pi จะสามารถส่งรูปภาพได้
  • การทดสอบ llama.cpp Metal + MTP โดยไม่ใช้ projector ได้ความเร็วพรอมป์ต์ 120.3 tok/s และสร้างข้อความ 71.4 tok/s
  • การรันขั้นสุดท้ายที่โหลด mmproj-BF16.gguf ได้ความเร็วพรอมป์ต์ 297.4 tok/s และสร้างข้อความ 72.2 tok/s
  • การรันขั้นสุดท้ายที่โหลด projector แล้วไม่พบว่าความเร็วการสร้างข้อความลดลง

การติดตั้ง llama.cpp

  • ติดตั้ง dependency cmake, git, tmux, python@3.11 ด้วย Homebrew
  • สร้าง path ~/Developer/ML-Models/Gemma4/repos แล้ว clone repository ggml-org/llama.cpp ไปที่ repos/llama.cpp
  • ตั้งค่าการ build ด้วย cmake -B build -DCMAKE_BUILD_TYPE=Release -DGGML_METAL=ON -DGGML_ACCELERATE=ON
  • จากนั้นทำ release build ด้วย cmake --build build --config Release -j
  • build ที่ทดสอบใช้การตั้งค่า GGML_METAL=ON, GGML_ACCELERATE=ON, GGML_BLAS=ON, GGML_BLAS_VENDOR=Apple

ดาวน์โหลดไฟล์โมเดล

  • สร้าง Python 3.11 virtual environment แล้วติดตั้ง huggingface_hub และ hf_xet
  • ใช้ huggingface-cli download เพื่อดาวน์โหลดโมเดลหลัก Gemma 4, mmproj-BF16.gguf และ MTP draft model
  • ไฟล์เป้าหมายที่ดาวน์โหลดคือ gemma-4-26B-A4B-it-UD-Q4_K_XL.gguf, mmproj-BF16.gguf, MTP/gemma-4-26B-A4B-it-Q8_0-MTP.gguf
  • โฟลเดอร์โมเดลสุดท้ายมีทั้งสามไฟล์อยู่ภายใต้ models/unsloth-gemma-4-26B-A4B-it-GGUF/

เริ่มต้นเซิร์ฟเวอร์โลคัล

  • เซิร์ฟเวอร์ขั้นสุดท้ายรันด้วย llama-server โดยระบุทั้งโมเดลหลัก, MTP draft model และ multimodal projector
  • ออปชันสำคัญคือ --spec-type draft-mtp, --spec-draft-n-max 3, -ngl 999, -fa on, -c 65536, --parallel 1
  • เซิร์ฟเวอร์รันด้วย --host 127.0.0.1 --port 8080
  • endpoint ที่เข้ากันได้กับ OpenAI คือ http://127.0.0.1:8080/v1
  • wrapper start_server.sh จะรันเซิร์ฟเวอร์ใน session ของ tmux และเก็บ log ไว้ที่ logs/llama-server-mtp.log
  • หลัง chmod +x start_server.sh ให้เริ่มเซิร์ฟเวอร์ด้วย ./start_server.sh
  • ตรวจสอบว่าเซิร์ฟเวอร์ทำงานอยู่หรือไม่ด้วย curl http://127.0.0.1:8080/v1/models

การตั้งค่า Pi

  • Pi อ่านการตั้งค่าผู้ให้บริการโมเดลจาก ~/.pi/agent/models.json
  • baseUrl ของผู้ให้บริการโลคัล gemma4-local ชี้ไปที่ http://127.0.0.1:8080/v1
  • api คือ openai-completions และเพราะเป็นเซิร์ฟเวอร์โลคัลจึงตั้ง authHeader เป็น false
  • model ID คือ gemma-4-26B-A4B-it-UD-Q4_K_XL.gguf และตั้งชื่อเป็น Gemma 4 26B-A4B Q4 + MTP
  • input ต้องเป็น ["text", "image"] ไม่เช่นนั้น Pi จะมองว่าโมเดลรองรับเฉพาะข้อความ
  • context window ตั้งเป็น 65536 และ max token ตั้งเป็น 8192
  • หากต้องการ สามารถกำหนด defaultProvider เป็น gemma4-local และ defaultModel เป็นชื่อไฟล์ GGUF ดังกล่าวใน ~/.pi/agent/settings.json
  • เมื่อรัน pi --offline --list-models gemma ควรเห็นว่าการรองรับรูปภาพแสดงเป็น yes
  • การรันโมเดลโลคัลทำได้ด้วย pi --provider gemma4-local --model gemma-4-26B-A4B-it-UD-Q4_K_XL.gguf
  • การรันแบบไม่โต้ตอบทำได้ในรูปแบบ pi -p --provider gemma4-local --model gemma-4-26B-A4B-it-UD-Q4_K_XL.gguf "Explain what this repository does"
  • การป้อนสกรีนช็อตทำได้ในรูปแบบ pi -p @"/path/to/screenshot.png" "Describe this image and point out anything relevant to the UI"

การตั้งค่าขั้นสุดท้าย

  • runtime สำหรับ inference ขั้นสุดท้ายคือ llama.cpp
  • การเร่งความเร็วบน macOS ใช้ชุด Metal + Accelerate
  • โมเดลหลักคือ gemma-4-26B-A4B-it-UD-Q4_K_XL.gguf
  • draft model คือ gemma-4-26B-A4B-it-Q8_0-MTP.gguf
  • การตั้งค่า MTP คือ --spec-draft-n-max 3
  • multimodal projector คือ mmproj-BF16.gguf
  • เซิร์ฟเวอร์คือ llama-server ที่ 127.0.0.1:8080
  • API คือ /v1 ที่เข้ากันได้กับ OpenAI
  • เอเจนต์เขียนโค้ดคือ Pi และอินพุตโมเดลของ Pi คือ ["text", "image"]
  • MTP draft model ช่วยเพิ่มความเร็วการสร้างข้อความของ Gemma 4 ในสภาพแวดล้อมนี้จาก 58.2 tok/s เป็น 72.2 tok/s และการตั้งค่าก็เรียบง่ายพอที่จะรันเป็นเซิร์ฟเวอร์โลคัลที่เข้ากันได้กับ OpenAI

ทางเลือก Qwen3.6 35B-A3B

  • บางคนแนะนำให้ใช้ Qwen3.6 35B-A3B แทน Gemma 4 26B-A4B
  • จาก benchmark ที่ตรวจสอบได้ Qwen ถูกประเมินว่าเป็นเอเจนต์เขียนโค้ดที่ดีกว่า Gemma 4 อย่างมาก
  • แต่การตั้งค่า Qwen ช้ากว่า โดยชุด Qwen3.6-35B-A3B-UD-Q4_K_XL.gguf, unsloth-Qwen3.6-35B-A3B-MTP-GGUF, mmproj-BF16.gguf ทำได้ 55 tok/s
  • 55 tok/s แทนที่จะเป็น 72 tok/s เป็นความต่างที่มีนัยสำคัญในสถานการณ์ที่ผู้ใช้ต้องรอ
  • การดาวน์โหลดโมเดล Qwen ทำได้จาก unsloth/Qwen3.6-35B-A3B-MTP-GGUF โดยดาวน์โหลด Qwen3.6-35B-A3B-UD-Q4_K_XL.gguf และ mmproj-BF16.gguf
  • เซิร์ฟเวอร์ Qwen ใช้ llama-server ตัวเดียวกัน แต่รันด้วย --port 8081
  • ชื่อผู้ให้บริการ Qwen ในการตั้งค่า Pi คือ qwen36-local และ baseUrl คือ http://127.0.0.1:8081/v1
  • การตั้งค่าโมเดล Qwen ใช้ reasoning: true, input: ["text", "image"], contextWindow: 65536, maxTokens: 8192

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

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

 
GN⁺ 3 시간 전
ความคิดเห็นจาก Hacker News

  • พรอมป์ต์เบนช์มาร์กคือ “เขียนฟังก์ชัน Python แบบกระชับที่พาร์ส unified diff แล้วคืนค่าเส้นทางไฟล์ที่มีการเปลี่ยนแปลง พร้อมอธิบาย edge case สองกรณี” และถ้าแต่ละเบนช์มาร์กสร้างผลลัพธ์ราว 128 โทเค็น ก็ดูเหมือนว่า 128 โทเค็น จะน้อยเกินไปสำหรับการได้ผลลัพธ์ที่ดี
    การเร่งความเร็วด้วย MTP ขึ้นอยู่กับว่ามีการยอมรับโทเค็นที่คาดเดาไว้บ่อยแค่ไหน ซึ่งจากประสบการณ์ ช่วงต้นของเอาต์พุตจะมีอัตราการยอมรับสูงกว่า จึงทำให้การทดสอบสั้น ๆ อาจสร้าง ความเร็วลวงแบบ false positive ได้
    ใน llama.cpp มีเครื่องมือสำหรับเบนช์มาร์กโดยเฉพาะที่ไล่อาร์กิวเมนต์ให้ได้เลยโดยไม่ต้องรีสตาร์ตเซิร์ฟเวอร์และส่งพรอมป์ต์ใหม่: https://github.com/ggml-org/llama.cpp/blob/master/tools/llam...
    ส่วนดาวน์โหลดโมเดลก็ควรพูดถึงด้วยว่าอาร์กิวเมนต์ -hf ของ llama.cpp สามารถดาวน์โหลดโมเดลให้แทนได้ ขอบคุณที่ผู้เขียนแชร์ประสบการณ์ แต่สำหรับมือใหม่ มันอาจไม่ใช่คู่มือที่ดีที่สุด

    • เดิมทีไม่ได้เขียนเป็นคู่มือสำหรับนักพัฒนาแบบจริงจัง แค่มีคนกดบันทึกวิดีโอบันทึกหน้าจอไว้เยอะ แล้วเริ่มมีข้อความมาถามว่าตั้งค่ายังไง เลยสรุปแบบเร็ว ๆ ว่าผมจัดการทดสอบนี้อย่างไร
      พอเห็นประกาศ “เร็วขึ้น 2 เท่า” ของ Unclothe ก็เลยสงสัยว่า “ระดับนี้จะเร็วพอให้ใช้งานจริงไหม?” เลยลองตั้งค่าดูเอง
      ปีก่อนก็เคยทดสอบกับของอย่าง Devstral แต่ตอนนั้นมันทั้งช้าและไม่ฉลาดจนไม่อยากใช้ต่อ ส่วนครั้งนี้รู้สึกว่าในที่สุดก็มาถึงจุดที่ทั้งความเร็วและความฉลาด ใช้งานได้จริง แล้ว
    • ในทางปฏิบัติ ควรทดลองโดยใส่ system prompt ที่มากพอควบคู่กับพรอมป์ต์ผู้ใช้ตามปกติ อย่างน้อย 1000 โทเค็น และจริง ๆ แล้วราว 3000 โทเค็นน่าจะดีกว่า
      llama.cpp มีเครื่องมือสำหรับเรื่องนี้ และถ้าจะวัดให้ถูกต้องก็ควรใส่ prefill ก่อนเริ่มสร้างโทเค็น ตอนนี้การวัดความเร็วการสร้างโทเค็นในคอนเท็กซ์ยาว ๆ อย่าง 32k หรือ 64k ก็ยิ่งสำคัญขึ้นเรื่อย ๆ
    • ถ้าใช้แค่ 128 โทเค็น ก็เหมือนกำลังเบนช์มาร์กแค่ โอเวอร์เชอร์ ไม่ใช่โอเปรา
    • มันคล้ายกับการพูดว่า “บนเครื่องผมมันรันได้” โดยไม่ได้ดูปัญหาจริงเลย 128 โทเค็นนี่แทบไม่มีอะไรเลย ยาวกว่าคำทักทายสั้น ๆ แค่นิดเดียว

  • ก่อนหน้านี้ผมเคยเขียนโพสต์คล้าย ๆ กันโดยใช้ ollama กับ opencode: https://blog.kulman.sk/running-local-llm-coding-server/

    • Ollama ไม่ใช่ตัวเลือกที่ดี: https://sleepingrobots.com/dreams/stop-using-ollama/
      opencode ใช้ system prompt กินคอนเท็กซ์มากเกินไปหรือเปล่า? โมเดลโลคอลมีข้อจำกัดด้านคอนเท็กซ์มากอยู่แล้ว เท่าที่จำได้ opencode ใช้ไปประมาณ 10k หรือใกล้เคียงนั้น
    • ใช้งานได้จริง และถ้าใช้ ollama GUI ก็น่าจะทำให้ง่ายขึ้นได้อีก

  • ถ้าใช้แค่ llama.cpp ก็ดูเหมือนไม่จำเป็นต้องมี huggingface-cli เพื่อดาวน์โหลดอะไรเลย แค่ส่ง -hf ... ไปก็จะดาวน์โหลดโมเดลให้
    ถ้าอยากเปลี่ยนตำแหน่งดาวน์โหลดก็แค่ตั้งค่า LLAMA_CACHE:
    LLAMA_CACHE="models" ./llama-server \
    -hf unsloth/gemma-4-31B-it-GGUF:UD-Q4_K_XL \
    ...

    • สำหรับ draft model ให้ใช้ -hfd

  • ถ้าเป็น unified memory RAM ที่ใหญ่ แต่มีเทราฟลอปส์และแบนด์วิดท์ GB/s แค่ระดับกลางหรือต่ำกว่า โดยทั่วไป MoE มักจะมีความหวังที่สุด สำหรับสภาพแวดล้อมของผมคือ M2 Max 96GB ตอนนี้อันดับ 1 ตามเกณฑ์ (ความฉลาด, tok/s, ความลึกคอนเท็กซ์) คือ DeepSeek-V4-Flash REAP25 <65gb gguf + ds4-server + pi agent
    แน่นอนว่ามันยังไม่ดีกว่า cloud API แต่ถ้าจำเป็นก็ยังยอมรับได้จนพอจะใช้จริงได้ ตอนขึ้นเครื่องบิน 4 ชั่วโมงแบบไม่มีอินเทอร์เน็ต local LLM กินไฟ 60W แต่แบตเตอรี่ก็ยังเอาอยู่
    ds4 branch ที่รองรับ REAP อยู่ที่นี่: https://github.com/ljubomirj/ds4/tree/reap-compact-support
    ความต่างสำคัญคือ DS4F จะเพิ่งตกลงไปต่ำกว่า 10 tok/s จนใช้งานไม่ได้จริง ๆ ก็ต่อเมื่ออยู่ที่ 784K คอนเท็กซ์

  • สงสัยว่าโมเดลโลคอลแบบนี้จะช่วยแก้ปัญหาได้จริงไหม แม้สำหรับผู้ใช้ที่ไม่ได้เชี่ยวชาญภาษาโปรแกรมนั้นโดยเฉพาะ
    นอกเหนือจาก inline autocomplete หรือการทำ implementation เป็นหน่วยย่อย ผมยังไม่มั่นใจว่ามันจะสามารถออกแบบและประกอบ สเปกทางเทคนิค ที่ใช้งานได้จริงได้หรือไม่

  • การรัน local LLM ด้วย llama.cpp/server แล้วใช้คู่กับ Claude Code หรือ Codex-CLI นั้นค่อนข้างง่าย
    การตั้งค่า llama server ที่ต้องใช้มักกระจัดกระจายอยู่หลายที่ ผมเลยดูแลคำแนะนำสำหรับ open LLM ยอดนิยมบางตัวไว้ที่นี่: https://pchalasani.github.io/claude-code-tools/integrations/...

    • ใช้มันเป็น งานประจำวัน เลยไหม? พรอมป์ต์ของ Claude Code ใหญ่มาก จนบนโมเดลโลคอลใช้เวลาประมวลผลพรอมป์ต์นานมาก และอีกไม่นานก็กินคอนเท็กซ์จนหมด

  • ผมใช้ omlx.ai ดาวน์โหลด โมเดล MLX หลายตัวที่เหมาะกับฮาร์ดแวร์ของตัวเอง และใช้โมเดลเหล่านั้นรันทั้งฮาร์เนสแบบโอเพนซอร์สและแบบปิด (Claude Code, Codex) ได้ค่อนข้างสำเร็จแบบอัตโนมัติ
    ทำได้ทั้งบนเว็บและเดสก์ท็อป UI ดังนั้นสำหรับผม ถ้าใช้ omlx ก็ไม่จำเป็นต้องทำตามบทความบล็อกนี้

    • บน M1 Max 64GB ผมไม่เห็นว่า oMLX หรือ MLX มีข้อได้เปรียบเหนือ GGUF ของ llama.cpp อย่างชัดเจน
      บิลด์ Gemma 4 MLX ที่ผมหาเจอมาจนถึงตอนนี้ช้ากว่าที่ quantization เท่ากัน และใน MTP ก็ช้ากว่ามาก
      พอเลือกโมเดลได้แล้ว เว็บ UI ในตัวของ llama.cpp ก็ค่อนข้างดี และถ้าอยากลองปรับนู่นนี่ LM Studio ก็ใช้ได้ดี
      Gemma-4 และ Qwen 3.6 ไม่ต้องการ system prompt ก้อนใหญ่แบบทั่วไปของ opencode เลย และเอาออกน่าจะดีกว่า
    • ถ้ากำลังมองหา sandbox สำหรับต่อเข้ากับ oMLX และ Pi ก็มีอันนี้: https://github.com/Dotnaught/pi-sandbox
    • ผมมองว่านี่คือ ล้ำสมัยที่สุด สำหรับการทำ local inference บน Mac ต่อให้มี regression เกิดขึ้น นักพัฒนาก็ตอบสนองเร็วมาก และเป็นหนึ่งในโปรเจกต์โอเพนซอร์สที่น่าประทับใจที่สุดที่ผมเห็นเมื่อไม่นานมานี้

  • DeepSeek v4 Flash ที่รันด้วย ds4 ของ antirez ค่อนข้างน่าประทับใจ
    ในแง่ “ความรู้ที่เก็บไว้” มันให้ความรู้สึกเหมือนโมเดลระดับ GPT-4 แต่กับการเรียกใช้เครื่องมือแบบเป็นลำดับยาว ๆ มันทำได้ดีกว่าโมเดลระดับ GPT-4 เสียอีก
    บน MBP M4 Max 128GB การสร้างข้อความได้ราว 24 t/s และ prefill ราว 200 t/s เดิมทีผมคิดว่ามันจะช้า และกับงานอย่างการสร้างโค้ดมันก็ช้าจริง แต่ในฐานะ ตัวประสานงานเครื่องจักร สำหรับงานง่าย ๆ มันมีประโยชน์อย่างน่าประหลาดใจ
    สำหรับงานที่ไม่ใช่แบบเอเจนต์ มันก็คุยได้ดีพอสมควร และยังมีข้อดีที่ทำงานได้เองทั้งหมดและเป็นส่วนตัวอย่างสมบูรณ์
    [0]https://github.com/antirez/ds4

  • ถ้าอยากทำแบบขี้เกียจสุด ๆ ก็เปิด Claude Code ในเทอร์มินัล ชี้ไปที่บทความนี้ แล้วสั่งแค่ว่า “ทำให้หน่อย”

    • ตอนนี้ผมแทบไม่ใช้ Google Search แล้ว เพราะ 9 ใน 10 ครั้ง คุณภาพข้อมูลแย่มาก และยากที่จะคัดเอาสิ่งที่ต้องการออกมาจากสแปมรอบตัว
      แต่ Claude กลับทำให้ได้ในครั้งเดียว หรือแค่ปรับนิดหน่อยก็เสร็จ
      ตอนนี้ประตูสู่ความรู้และการลงมือทำคือ LLM ส่วน Google Search ให้ความรู้สึกเหมือนไดโนเสาร์
      มันน่าทึ่งยิ่งกว่าสมาร์ตโฟนเสียอีก ราวกับได้หลุดเข้าไปอยู่ในอนาคตอีกสักศตวรรษ