การใช้ LLM แบบโลคัลสำหรับการเขียนโค้ดแบบเอเจนต์

 (blog.alexewerlof.com)
10 คะแนน โดย GN⁺ 3 시간 전 | 3 ความคิดเห็น | แชร์ทาง WhatsApp
  • ท่ามกลางราคาของโมเดลเรือธงบนคลาวด์ที่พุ่งสูงขึ้น ได้มีการสรุป วิธีใช้โมเดลแบบโลคัล เพื่อทำงานเขียนโค้ดต่อได้โดยไม่ต้องแบกรับต้นทุนสูง
  • แม้โมเดลแบบโลคัลจะยังไม่ถึงระดับประสิทธิภาพของโมเดล SOTA แต่ด้วย ความคุ้มค่าต่อราคา และการเสริมด้วย deterministic harness ก็สามารถยกระดับคุณภาพได้สูงสุดถึง 6 เท่า
  • สำหรับงานเขียนโค้ด Gemma 4 มีสมดุลที่ดีระหว่างงานทั่วไปกับการสร้างโค้ด และด้วยการรองรับ Tools Use·Vision·Reasoning จึงเหมาะกับการเชื่อมต่อกับ VS Code
  • มีขั้นตอนการตั้งค่าครบชุดสำหรับเปิดเซิร์ฟเวอร์โมเดลด้วย LM Studio และเชื่อมต่อเข้ากับ custom endpoint ของ VS Code Copilot·Pi
  • หากฮาร์ดแวร์ไม่พอ สามารถใช้ โมเดลฟรีของ OpenRouter เป็นทางเลือกได้ และโมเดลโลคัลก็ยังได้เปรียบในด้านออฟไลน์และความเป็นส่วนตัว

เบื้องหลังการขึ้นราคา

  • GitHub Copilot เปลี่ยนจากโมเดลแบบเครดิตมาเป็น การคิดค่าบริการตามการใช้งาน และแม้แต่โมเดลฟรีเดิมก็ไม่ฟรีอีกต่อไป
  • เนื่องจาก GitHub เป็นผู้ขายต่อโทเค็น จึงยิ่งรู้สึกถึงการขึ้นราคาได้ชัดกว่าเดิม โดยโมเดลเรือธงถูกออกมาทั้งที่ความเร็วในการพัฒนาประสิทธิภาพยังตามไม่ทันความเร็วในการขึ้นราคา
    • Google Flash 3.5 แพงกว่า 3 เท่า เมื่อเทียบกับ Flash 2.5
    • GPT 5.5 แพงกว่า 3 เท่า เมื่อเทียบกับ GPT 5
    • Claude เดิมก็ แพงมากอยู่แล้ว จนสุดท้ายกลับต้องปรับลดราคา

ความจริงและจุดแข็งของโมเดลโลคัล

  • โมเดลโลคัลยังสู้ประสิทธิภาพของโมเดล SOTA อย่าง Claude·GPT·Gemini ไม่ได้ แต่ก็มี ความละเอียดอ่อนบางอย่าง (nuance) อยู่
    • อัตราส่วนราคา/ประสิทธิภาพ: โมเดลคลาวด์มีต้นทุนที่เพิ่มขึ้นแบบก้าวกระโดดเมื่อเทียบกับการปรับปรุงประสิทธิภาพ
    • deterministic harness: ด้วย tooling และคำสั่งที่ดีขึ้น สามารถเพิ่มคุณภาพของโมเดลที่อ่อนกว่าได้สูงสุดถึง 6 เท่า
    • กับดักของ benchmark: ยากที่จะสรุปโมเดลเป็นตัวเลขเดียว และแต่ละ AI lab ก็มักเน้น benchmark ที่เข้าทางตัวเอง จึงจำเป็นต้อง ประเมินด้วย workload ของตัวเองโดยตรง
    • ผลกระทบทางภูมิรัฐศาสตร์: สิ่งที่แล็บในสหรัฐปล่อยให้ใช้ฟรีไม่ใช่ของระดับสูงสุดเสมอไป gpt-oss-20b เก่าเกินไป และ Anthropic ก็ยังไม่ปล่อย open weights โดย Gemma 4 เป็นโมเดลเดียวที่ถือว่าน่าจริงจัง ขณะเดียวกันก็ควรจับตาโมเดลฝีมือดีจากแล็บจีนอย่าง Qwen·Kimi·GLM
  • ในมุมของปรากฏการณ์ "brain rot" โมเดลที่อ่อนกว่าจะบังคับให้ผู้ใช้มีส่วนร่วมมากขึ้น จึง ดีต่อสุขภาพทางความคิด
    • มันให้ความรู้สึกเหมือนปั่นจักรยาน คือช้ากว่าแต่ดีต่อสุขภาพ ในงานความรู้ "ช้าคือเร็ว"
    • เป้าหมายไม่ใช่การทำอัตโนมัติให้สุดจนโยนการคิดทั้งหมดให้เครื่อง อย่าแลก คุณค่าของตัวเองในอนาคต (relevance) กับความเร็วระยะสั้น
    • เทคนิคที่ใช้กับโมเดลอ่อนกว่ายังนำไปใช้กับโมเดลใหญ่ได้ การรับมือกับโมเดลอ่อนก็เหมือน การเล่นโหมดฮาร์ด ซึ่งถ้าชำนาญแล้วจะใช้เครื่องมือใหญ่ได้มีประสิทธิภาพยิ่งขึ้น

การเลือกโมเดล — Gemma 4

  • สำหรับงานโค้ด โมเดลจากจีนครองอันดับบน ๆ ของ Huggingface leaderboard โดยมีทั้ง Qwen·DeepSeek·Kimi·Llama·Gemma เป็นต้น
  • Gemma 4 มีหลายเวอร์ชัน
    • E2B: ตัว "E" หมายถึง edge มี 2B พารามิเตอร์ จึงรันได้บนฮาร์ดแวร์ส่วนใหญ่ แต่มี ความเสี่ยงสูงที่จะหลอนหรือทำงานไม่จบ
    • E4B: มีขนาดเป็นสองเท่าของ E2B ค่าโหลดและการตั้งค่าต่ำ จึง แนะนำให้ใช้เป็นตัวเริ่มต้น
    • 12B: เข้าใจ ภาพได้โดยตรงแบบเนทีฟ โดยไม่ต้องมี decoder จึงเร็วกว่าในงานฟรอนต์เอนด์และการเขียนโค้ดเชิงภาพ รองรับเสียงแบบเนทีฟด้วยแต่ไม่ค่อยสำคัญกับ workload ด้านโค้ด
    • 26B A4B: เป็นสถาปัตยกรรม MoE (mixture of experts) ที่มี 26B พารามิเตอร์แต่เปิดใช้งานจริงเพียง 4B ฉลาดกว่า E4B และเหมาะกับการ์ดจอ VRAM 8~12GB (เป็นโมเดลที่ผู้เขียนชอบ)
    • 31B: เป็นโมเดล open weights ที่ใหญ่ที่สุดของ Google ไม่ใช่ MoE จึงต้องใช้ VRAM มาก บน AMD APU ได้ความเร็วเพียง 1~2 TPS ซึ่งช้าเกินใช้งานจริง
    • เวอร์ชัน QAT (เช่น E4B QAT) ใช้หน่วยความจำน้อยลงแต่คุณภาพแทบไม่ต่าง โดย Unsloth กำลังทำงานเพิ่มด้านการปรับแต่งประสิทธิภาพ

องค์ประกอบที่จำเป็นสำหรับการรันโมเดลโลคัล

  • การรันโมเดลโลคัลต้องมี harness·model·runtime·model manager
    • Harness: เช่น VS Code Copilot, Copilot CLI, Pi เป็น องค์ประกอบแบบกำหนดผลลัพธ์ได้แน่นอน (โค้ดดั้งเดิม) ที่ห่อหุ้มรอบโมเดลซึ่งมีความน่าจะเป็นอยู่ภายใน
    • Model: ไฟล์น้ำหนักของโครงข่ายประสาทเทียมเชิงลึก โดย quantization (Q8, Q4 ฯลฯ) มีแนวคิดคล้ายความละเอียดของภาพ และมีฟอร์แมตอย่าง GGUF·MLX

  • Runtime (เอนจินสำหรับ inference)

    • Llama.cpp: runtime โอเพนซอร์ซที่ได้รับความนิยมที่สุด รองรับการโหลด GGUF·MLX ไม่เกี่ยวข้องกับโมเดล Llama ของ Meta และ LM Studio ก็ใช้ตัวนี้ภายใน
    • MLX: runtime ของ Apple สำหรับ Mac อย่าง M1·M2
    • ONNX Runtime: ทำงานบนเบราว์เซอร์ผ่าน WebGPU โดยอิง transformers.js และรองรับมือถือ iOS·Android ด้วย
    • vLLM: โอเพนซอร์ซจาก UC Berkeley ใช้กับเซิร์ฟเวอร์สมรรถนะสูงเป็นหลัก และตั้งค่ายากกว่า

  • Model manager

    • Ollama: เริ่มจาก CLI บนเทอร์มินัลแล้วค่อยเพิ่ม GUI แบบเบา เป็น Go wrapper ที่ครอบ Llama.cpp และเป็นโอเพนซอร์ซ
    • LM Studio: ฟรีแต่ ไม่ใช่โอเพนซอร์ซ มี SDK (Python/TypeScript) และ REST API ให้ใช้งาน และควบคุมฟีเจอร์เฉพาะของโมเดลโลคัลได้ เช่น dynamic loading
    • Jan: ทางเลือกคล้าย LM Studio ที่ฟรีและเป็นโอเพนซอร์ซ แต่ความสามารถยังน้อยกว่า
    • การรองรับ API ที่เข้ากันได้กับ OpenAI เป็นฟีเจอร์สำคัญ เพราะแอป AI จำนวนมากทำงานกับมาตรฐานโดยพฤตินัยนี้

การตั้งค่าเซิร์ฟเวอร์ LM Studio

  • เริ่มเซิร์ฟเวอร์ได้ด้วยการสลับปุ่มในเมนู "Developer" หากรันบนเครื่องอื่นหรือในคอนเทนเนอร์ให้เปิด Serve on Local Network และหากต้องเข้าจากเว็บแอปให้เปิด Enable CORS
  • LM Studio ใช้การโหลดแบบ JIT (Just In Time) โดยจะโหลดโมเดลเมื่อมีคำขอเข้ามา และกำหนดเวลาเก็บไว้ในหน่วยความจำได้ด้วยค่า TTL
    • Cold start: หากโมเดลยังไม่ถูกโหลด คำขอแรกจะใช้เวลาเพิ่มอีกราว 10~30 วินาที คล้าย cold start ของ AWS Lambda และมีผลต่อค่า TTFT (Time To First Token)
    • หน้าต่างคอนเท็กซ์สั้น: ค่าเริ่มต้นอาจมี context window เพียง 4k จึงต้องเพิ่มเอง ขณะที่โมเดลส่วนใหญ่ใน VS Code Copilot มี 200~400k

  • การตั้งค่าความยาวคอนเท็กซ์และหน่วยความจำ

    • ความต้องการ VRAM ตามความยาวคอนเท็กซ์: 262144 (สูงสุด) = 25.74GB, 4096 (ค่าเริ่มต้น) = 18.16GB, 150000 (ค่าที่ผู้เขียนชอบ) = 22.45GB
    • สำหรับงานโค้ด system prompt เพียงอย่างเดียวก็อาจกิน 20~40k โทเค็น จึงควรโหลดได้อย่างน้อย 100k โทเค็น
    • ถ้าคอนเท็กซ์ใหญ่เกินไป ความเร็วในการสร้างโทเค็นจะลดลง จุดที่เหมาะที่สุดคือช่วงที่ harness บีบอัดคอนเท็กซ์ให้อัตโนมัติ
    • โดยอุดมคติควรรันทุกเลเยอร์ของโมเดลบน GPU และแนะนำให้ดันสไลเดอร์ "GPU Offload" ไปสูงสุด การรันบางเลเยอร์บน CPU ต้องมีการคัดลอกข้อมูลระหว่าง CPU-GPU ยกเว้นบน Apple Silicon (UMA)

  • ทริกการทำ quantization ให้ KV cache

    • ตั้งค่า K Cache Quantization Type เป็น Q8_0 และ V Cache Quantization Type เป็น Q4_0
    • เป็นวิธีคงความละเอียดของ key ให้สูงกว่า value ด้วยการตั้งค่านี้ ความต้องการหน่วยความจำ GPU จะลดจากค่าเริ่มต้น 28.75GB เหลือ 22.45GB
    • ต้องบันทึกการตั้งค่าไว้เสมอ ไม่เช่นนั้นเมื่อลงโมเดลครั้งถัดไปจะกลับไปใช้ค่าเริ่มต้น
    • VS Code Copilot ไม่มีแนวคิดเรื่องการขอ custom context window ดังนั้น LM Studio ต้องจำค่าตั้งเหล่านี้ไว้เมื่อถูกเรียกผ่าน REST API
  • หาก TPS ต่ำกว่า 10 จะทนใช้งานสำหรับงานเขียนโค้ดได้ยาก เพราะเสียเวลาไปกับการรอโมเดลมากเกินไป

การเชื่อมต่อ custom endpoint ของ Copilot

  • ต้องใช้ VS Code เวอร์ชันใหม่พอสมควร (ขณะเขียนคือ 1.122.1) ไปที่ตัวเลือกโมเดล → ไอคอนเฟือง → "Add Models" → "Custom Endpoint" เพื่อเพิ่ม
    • ตั้งชื่อ (เช่น "Local LM Studio") กรอก API Key (หากไม่ได้ตั้งไว้ให้กด Enter) แล้วเลือกประเภท inference API
    • จาก API ทั้ง 3 แบบ มีเพียง Chat Completions ที่ทำงานได้ลื่นไหล
  • ในไฟล์ตั้งค่า JSON ต้องกำหนดค่าอย่าง url, maxInputTokens, maxOutputTokens เอง
    • ตั้งค่า thinking ให้ถูกต้อง (Gemma 4 รองรับ)
    • อาร์เรย์ supportsReasoningEffort จะแตกต่างกันไปในแต่ละโมเดล โดยเวอร์ชัน 26B รองรับการควบคุมที่ละเอียดกว่า E4B
    • รุ่น 4B ให้ตั้ง maxInputTokens 64000/maxOutputTokens 16000 ส่วน 26B MoE ตั้งเป็น 100000/50000
  • พรอมป์แรกจะทำให้ Copilot ส่ง system prompt และนิยามเครื่องมือขนาดใหญ่มาก จึงเกิด ความหน่วง 2~5 นาทีในการโต้ตอบครั้งแรก โดยใช้เวลาโหลดโมเดล 30 วินาที และประมวลผลพรอมป์อีกราว 5 นาที
    • สิ่งนี้เกิดเพียงครั้งเดียวต่อเซสชัน และ LM Studio ใช้ prompt caching ช่วยไว้ ส่วน Pi ไม่มีปัญหานี้เพราะ system prompt เล็กกว่า

  • การทดสอบอย่างรวดเร็วและสภาพแวดล้อม

    • มีการสาธิตประสิทธิภาพของ Gemma 4 26B A4B ด้วยการสั่งสร้าง เกมงู แบบ one-shot prompt โดยไม่ใช้ AGENTS.md หรือ SKILL
    • สภาพแวดล้อมที่ใช้: Lenovo Thinkpad L16 Gen 2, AMD Ryzen 7 PRO 250 APU, 64GB DDR5 (5,600MT/s), Aurora Linux และผู้เขียนมองว่า 32GB ก็เพียงพอ

การตั้งค่า Pi

  • การเชื่อมต่อกับเซิร์ฟเวอร์ LM Studio แบบโลคัลทำได้ง่าย และการตั้งค่า contextWindow ก็สอดคล้องกับรูปแบบการตั้งค่าของ LM Studio มากกว่า
  • กำหนด baseUrl เป็น http://host.containers.internal:1234/v1 และ api เป็น openai-completions
    • รุ่น 4B ตั้ง contextWindow 64000/maxTokens 16000 ส่วน 26B MoE ตั้งเป็น 150000/50000 พร้อมกำหนด mapping ของ thinkingLevelMap

สรุปข้อดีข้อเสียของโมเดลโลคัล

  • ข้อดี: ทำงานแบบออฟไลน์, ความเป็นส่วนตัวสูง, และตอบสนองได้เร็วขึ้นตามฮาร์ดแวร์ เวิร์กโฟลว์ โมเดล และการตั้งค่าที่ใช้
  • ข้อเสีย
    • โมเดล open weights ยังไม่ฉลาดเท่าโมเดลเรือธงแบบปิด แต่หากมี harness ที่มี guardrail เหมาะสม (lint·test·AGENTS.md) ก็ช่วยเพิ่มความแม่นยำในการเขียนโค้ดได้มาก
    • หากรัน LLM บนเครื่องเดียวกันจะเกิด ความช้าจากภาระฮาร์ดแวร์
    • มีทั้ง cold start, การประมวลผลพรอมป์แรก (cache miss) และต้นทุนเริ่มต้นของฮาร์ดแวร์ที่สูง
  • เมื่อคุ้นกับ LM Studio แล้ว ก็สามารถไปใช้ Llama.cpp โดยตรงได้โดยไม่ต้องมี GUI และ harness ส่วนใหญ่ก็รองรับ custom endpoint จึงเชื่อมต่อกับ LLM แบบโลคัลได้

ทางเลือกด้วยโมเดลฟรีของ OpenRouter

  • OpenRouter คือบริการ API และ routing แบบรวมศูนย์ที่เปิดให้เข้าถึงโมเดลนับร้อยผ่าน endpoint และบัญชีเดียว
  • Copilot·Zed·Pi รองรับ OpenRouter แบบเนทีฟทั้งหมด เพียงออก API token แล้วเชื่อมต่อได้ทันที
    • เพื่อป้องกันค่าใช้จ่ายพุ่ง แนะนำให้สร้าง custom guardrail จำกัดเพดาน $1/เดือน แล้วเพิ่มเฉพาะโมเดลฟรีลงใน allowlist
    • เมื่อสร้าง API key ใหม่ แนะนำให้ตั้ง max credit เป็น 0
  • ข้อเสีย: พรอมป์และข้อมูลอาจถูกนำไปใช้ฝึกได้ (มีตัวเลือก ZDR), ต้องเชื่อมต่ออินเทอร์เน็ต และมีความเป็นไปได้ที่ OpenRouter จะหยุดให้บริการโมเดลฟรี
  • ข้อดี: ไม่ต้องดาวน์โหลดหรือตั้งค่าแบบโลคัล และไม่ทำให้คอมพิวเตอร์ช้าลงระหว่างใช้งาน

  • อัปเดต 2026-06-09

    • เปลี่ยนมาใช้ Deepseek V4 Pro ซึ่งให้ประสิทธิภาพใกล้เคียง Claude Opus 4.8 มาก แต่มี context window ใหญ่กว่า 5 เท่า และมีราคาถูกกว่าราว 17~86 เท่า
    • ราคาใช้งานระหว่าง Pi กับ OpenRouter ต่างกันประมาณ 3 เท่า โดยสาเหตุมาจาก OpenRouter ส่งคำขอไปยัง endpoint ที่แพงกว่า (GMICloud)
    • สำหรับงานซับซ้อน ผู้เขียนจึงไปเปิดบัญชี Deepseek โดยตรง ส่วนงานง่าย ๆ การทำความเข้าใจพฤติกรรม และกรณีที่ให้ความสำคัญกับความเป็นส่วนตัว โมเดลโลคัลก็ยังเป็นตัวเลือกแรกอยู่เสมอ

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

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

 
click 3 시간 전

สรุปสุดท้ายก็กลายเป็นว่าระหว่างใช้โมเดลโลคัลก็ลงเอยไปใช้ deepseek v4 pro อยู่ดี
พอเวลาทำงานต้องคอยสลับโมเดลไปมาทุกครั้งก็ไม่ใช่เรื่องง่าย เลยรู้สึกว่านโยบายว่าจะใช้โลคัลสำหรับงานง่าย ๆ อย่างเดียวก็บังคับใช้ได้ยากเหมือนกัน
 
kirinonakar 1 시간 전

ไม่จำเป็นต้องเป็น local ก็ได้ เพราะมีตัวเลือกการสมัครใช้งานราคาประหยัดมากมาย เช่น opencode, ollama, cursor เป็นต้น
 
kurthong 2 시간 전

ผมกำลังสร้างและใช้งานปลั๊กอินให้เข้ากับยุคของ LLM ขนาดใหญ่ครับ เคยแนะนำมันใน GN SHOW อยู่ครั้งหนึ่งด้วย และคิดว่าการทำขึ้นมาใช้ให้เข้ากับความต้องการแบบนี้ก็น่าจะเป็นอีกวิธีหนึ่ง

https://github.com/hang-in/tunaLlama