รัน Google Gemma 4 แบบโลคัลด้วย Headless CLI ของ LM Studio และ Claude Code

 (ai.georgeliu.com)
17 คะแนน โดย GN⁺ 23 일 전 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • Gemma 4 ใช้สถาปัตยกรรม mixture-of-experts ที่เปิดใช้งานเพียงบางพารามิเตอร์ จึงรองรับ การอนุมานประสิทธิภาพสูงแม้บนฮาร์ดแวร์สเปกไม่สูง
  • LM Studio 0.4.0 เพิ่ม Headless CLI (llmster) แบบใหม่ ทำให้สามารถดาวน์โหลด โหลด แชตกับโมเดล และรัน API server ได้โดยไม่ต้องใช้แอปเดสก์ท็อป
  • ผ่าน API ที่เข้ากันได้กับ OpenAI·Anthropic จึงสามารถ ให้บริการ Gemma 4 เป็นโลคัลเซิร์ฟเวอร์ และใช้ Claude Code เป็นผู้ช่วยเขียนโค้ดแบบออฟไลน์เต็มรูปแบบได้
  • สามารถปรับแต่งฮาร์ดแวร์อย่างละเอียด เช่น ความยาวคอนเท็กซ์, GPU offloading, คำขอแบบขนาน เพื่อจูนทั้งประสิทธิภาพและการใช้หน่วยความจำ
  • การอนุมานแบบโลคัลบนโมเดล MoE ช่วยให้ทำ code review และทดสอบพรอมป์ต์ได้รวดเร็วโดยไม่เสียค่า API และกำลังกลายเป็น เทคโนโลยีสำคัญสำหรับการสร้างสภาพแวดล้อม AI แบบออฟไลน์สำหรับนักพัฒนา

รัน Google Gemma 4 แบบโลคัล — การเชื่อมต่อ Headless CLI ใหม่ของ LM Studio กับ Claude Code

  • ทำไมจึงควรรันแบบโลคัล

    • Cloud AI API มีข้อจำกัดด้าน ค่าใช้จ่าย, rate limit, ความเป็นส่วนตัว, network latency
    • งานที่ต้องวนซ้ำเร็ว เช่น code review, การเขียนร่าง, การทดสอบพรอมป์ต์ เหมาะกับ การรันโมเดลแบบโลคัล มากกว่า
    • การรันแบบโลคัลมีข้อดีคือ ค่า API เป็น 0, ไม่มีการส่งข้อมูลออกนอกเครื่อง, และ ใช้งานได้ตลอดเวลา

    • Gemma 4** ใช้สถาปัตยกรรม mixture-of-experts (MoE) โดยในโมเดล 26B จะเปิดใช้งานเพียง 4B พารามิเตอร์เท่านั้น** จึงให้ประสิทธิภาพสูงได้แม้บนฮาร์ดแวร์สเปกไม่สูง

      • บน M4 Pro MacBook (48GB) ทำความเร็วได้ 51 โทเคนต่อวินาที และจะช้าลงเล็กน้อยเมื่อใช้ภายใน Claude Code

  • ตระกูลโมเดล Gemma 4

    • Google เปิดตัว Gemma 4 มา 4 ตระกูลโมเดล เพื่อปรับให้เหมาะกับฮาร์ดแวร์หลากหลายแบบ
    • ซีรีส์ E (E2B, E4B) ใช้ Per-Layer Embeddings และรองรับ อินพุตเสียง (รู้จำเสียงพูด·แปลภาษา)
    • โมเดล dense 31B ทำได้ MMLU Pro 85.2%, AIME 2026 89.2%
    • โมเดล 26B-A4B จะเปิดใช้งานเพียง 8 จาก 128 experts (3.8B พารามิเตอร์) ทำให้ได้ คุณภาพระดับ 10B ในต้นทุนระดับ 4B
    • ด้วย MMLU Pro 82.6%, AIME 88.3% จึงใกล้เคียงกับโมเดล dense 31B และมี Elo 1441 แข่งขันกับโมเดลระดับ 400B+
    • รองรับ คอนเท็กซ์ 256K, อินพุตภาพ, function calling, และ การตั้งค่าโหมด reasoning จึงเหมาะกับการอนุมานแบบโลคัล

  • การเปลี่ยนแปลงสำคัญใน LM Studio 0.4.0

    • มีเอนจินอนุมานแบบแยกอิสระชื่อ llmster** ทำให้รันแบบ CLI ได้เต็มรูปแบบโดยไม่ต้องใช้แอปเดสก์ท็อป**

      • ผ่าน CLI lms จึงทำได้ทั้งหมดทั้งดาวน์โหลดโมเดล โหลดโมเดล แชต และรันเซิร์ฟเวอร์
      • ความสามารถหลัก:
      • llmster daemon: จัดการการโหลดโมเดลและการอนุมานในเบื้องหลัง
      • การจัดการคำขอแบบขนาน: รองรับหลายคำขอพร้อมกันด้วย continuous batching
      • Stateful REST API: เก็บประวัติการสนทนาผ่านเอนด์พอยต์ /v1/chat
      • การผสาน MCP: รองรับ Model Context Protocol แบบโลคัล

  • การติดตั้งและดาวน์โหลดโมเดล

    • คำสั่งติดตั้ง: 
      curl -fsSL https://lmstudio.ai/install.sh | bash
    • รัน daemon: lms daemon up
    • อัปเดตรันไทม์: lms runtime update llama.cpp, lms runtime update mlx
    • ดาวน์โหลดโมเดล Gemma 4 26B: lms get google/gemma-4-26b-a4b
    • การ quantize เริ่มต้นคือ Q4_K_M (17.99GB)
    • หลังดาวน์โหลดให้โหลดด้วย lms load google/gemma-4-26b-a4b

  • การจัดการโมเดลแบบโลคัล

    • ดูรายการโมเดลที่ติดตั้ง: lms ls
    • ในตัวอย่างเอาต์พุตมีทั้ง Gemma 4, Qwen 3.5, GLM 4.7 Flash และ โมเดล MoE อีกหลายตัว
    • โมเดล MoE ใช้เพียง บางพารามิเตอร์ที่ถูกเปิดใช้งาน จึงอนุมานได้อย่างมีประสิทธิภาพ

  • การสนทนาและประสิทธิภาพ

    • เริ่มแชต: lms chat google/gemma-4-26b-a4b --stats
    • ตัวอย่างเอาต์พุต: 
      Tokens/Second: 51.35
Time to First Token: 1.551s
    • 51 tok/sec และ ตอบกลับแรกใน 1.5 วินาที ถือว่าเร็วพอสำหรับการใช้งานแบบโต้ตอบ

  • ตรวจสอบสถานะโมเดลและหน่วยความจำ

    • ตรวจดูโมเดลที่ถูกโหลดอยู่: lms ps
    • ตัวอย่าง: ใช้หน่วยความจำ 17.99GB, คอนเท็กซ์ 48K, คำขอแบบขนาน 2 รายการ, TTL 1 ชั่วโมง
    • รายการสำคัญที่ดูได้จากเอาต์พุต JSON (lms ps --json | jq):
      • "architecture": "gemma4"
      • "quantization": {"name": "Q4_K_M", "bits": 4}
      • "vision": true, "trainedForToolUse": true
      • "maxContextLength": 262144, "parallel": 2

  • การประเมินหน่วยความจำตามความยาวคอนเท็กซ์

    • ใช้ตัวเลือก --estimate-only เพื่อคาดการณ์ความต้องการหน่วยความจำได้
    • ตัวโมเดลพื้นฐานใช้ประมาณ 17.6GiB และเมื่อคอนเท็กซ์เพิ่มเป็น 2 เท่า จะเพิ่มอีก 3~4GiB
    • หากใช้คอนเท็กซ์ 48K จะต้องใช้ราว 21GiB และที่ 256K จะอยู่ที่ 37.48GiB
    • ตัวอย่างคำสั่ง: 
      lms load google/gemma-4-26b-a4b --estimate-only --context-length 48000
    • ความสัมพันธ์เชิงเส้นระหว่างความยาวคอนเท็กซ์กับหน่วยความจำ มีประโยชน์ต่อการวางแผนทรัพยากร

  • การจูนการโหลดตามฮาร์ดแวร์

    • ความยาวคอนเท็กซ์

      • ตั้งค่าให้อยู่ในขอบเขตหน่วยความจำที่เหลือหลังหักการใช้งานของ OS (4~6GB)
      • ตัวอย่าง: lms load google/gemma-4-26b-a4b --context-length 128000

    • GPU offloading

      • Apple Silicon ใช้ สถาปัตยกรรม unified memory จึงใช้ GPU ได้เต็มด้วย --gpu=1.0
      • ระบบ NVIDIA สามารถแบ่งตามข้อจำกัดของ VRAM ได้ เช่น --gpu=0.5

    • คำขอแบบขนาน

      • รองรับหลายคำขอพร้อมกันด้วย continuous batching
      • ตั้งค่า Max Concurrent Predictions ใน GUI (ค่าเริ่มต้น 4)
      • สำหรับ Gemma 4 บนเครื่อง 48GB ค่าเหมาะสมคือคอนเท็กซ์ 48K และขนาน 2 คำขอ

    • การ unload อัตโนมัติด้วย TTL

      • ใช้ --ttl 1800 เพื่อลบโหลดอัตโนมัติเมื่อไม่มีการใช้งาน 30 นาที
      • ค่าเริ่มต้นคือ 1 ชั่วโมง และปิดได้ด้วย 0 หรือ -1

    • บันทึกค่าเริ่มต้นรายโมเดล

      • ในแอปเดสก์ท็อปไปที่ My Models → ไอคอนตั้งค่า เพื่อบันทึกค่าเริ่มต้นของ GPU, คอนเท็กซ์, Flash Attention

    • Speculative Decoding

      • สำหรับโมเดล MoE ไม่มีประสิทธิภาพ, จึงแนะนำให้ปิดกับ Gemma 4
      • ผลทดสอบบน Mixtral พบว่างานโค้ดดีขึ้น 39% แต่งานคณิตศาสตร์แย่ลง 54%

    • Flash Attention

      • ช่วย ลดหน่วยความจำของ KV cache จึงรองรับคอนเท็กซ์ยาวได้ดีขึ้น
      • เมื่อเปิดใช้บน Apple Silicon จะช่วยประหยัดหน่วยความจำ

  • แอปเดสก์ท็อป LM Studio

    • ใน GUI สามารถดู สถานะเซิร์ฟเวอร์, การโหลดโมเดล, API endpoint, log stream ได้แบบภาพรวม
    • รองรับ Anthropic protocol (POST /v1/messages) ด้วย
    • สามารถวิเคราะห์ภาพได้ผ่าน ความสามารถด้าน vision
    • ตัวอย่าง: วิเคราะห์ภาพ Timezone Scheduler แล้วสร้าง 504 โทเคนที่ 54.51 tok/sec
    • ผลจากการมอนิเตอร์ระบบ:
      • ใช้หน่วยความจำ 46.69GB/48GB, swap 27.49GB
      • GPU ใช้งาน 90%, CPU 91°C, GPU 92°C
      • พลังงาน 23.56W (CPU 11.06W, GPU 13.32W)
    • ด้วย สถาปัตยกรรม unified memory จึงไม่ต้องคัดลอกข้อมูลระหว่าง CPU/GPU

  • ให้บริการโมเดลผ่าน API server

    • เริ่มเซิร์ฟเวอร์: lms server start
    • OpenAI-compatible API: http://localhost:1234/v1
    • เอนด์พอยต์ที่เข้ากันได้กับ Anthropic: POST /v1/messages
    • เปลี่ยนพอร์ต: --port 8080
    • รองรับ JIT model loading โดยโหลดอัตโนมัติเมื่อมีคำขอ และ unload อัตโนมัติหลัง TTL
    • สตรีมล็อกแบบเรียลไทม์: lms log stream --source model --stats
    • อุปกรณ์อื่นในเครือข่ายเดียวกันก็เข้าถึงได้ และรองรับ การยืนยันตัวตนด้วย API token

  • การเชื่อมต่อกับ Claude Code

    • ผ่านเอนด์พอยต์ที่เข้ากันได้กับ Anthropic จึงสามารถ รัน Claude Code โดยใช้โมเดลโลคัล ได้
    • เพิ่มฟังก์ชัน claude-lm ใน ~/.zshrc: 
      export ANTHROPIC_BASE_URL=http://localhost:1234
export ANTHROPIC_MODEL="gemma-4-26b-a4b"
...
claude "$@"
    • การเรียกใช้โมเดลทั้งหมดใน Claude Code (Opus, Sonnet, Haiku) จะถูกส่งต่อไปยัง Gemma 4
    • ตั้งค่าเป็น คอนเท็กซ์ 48K, จำกัดเอาต์พุต 8K โทเคน, และ สภาพแวดล้อมแบบโลคัลเท่านั้น
    • เมื่อรัน claude-lm ก็สามารถใช้ผู้ช่วยเขียนโค้ดแบบออฟไลน์เต็มรูปแบบได้
    • แม้ความเร็วจะช้ากว่าคลาวด์ แต่ก็ เหมาะกับ code review, การแก้ไขขนาดเล็ก, และงานสำรวจโค้ด

  • บทเรียนสำคัญ

    • โมเดล MoE คือหัวใจของการอนุมานแบบโลคัล: Gemma 4 26B-A4B ให้คุณภาพระดับ 10B ในต้นทุนระดับ 4B
    • Headless daemon ทำให้ทำงานแบบ CLI ล้วนได้ทั้งเวิร์กโฟลว์
    • ความยาวคอนเท็กซ์ เป็นตัวแปรหลักของการใช้หน่วยความจำ
    • ใช้ --estimate-only เพื่อ ป้องกัน OOM
    • ด้วย เอนด์พอยต์ที่เข้ากันได้กับ Anthropic จึงรัน Claude Code แบบออฟไลน์เต็มรูปแบบบนเครื่องโลคัลได้

  • ข้อจำกัด

    • lms chat ไม่แสดงชื่อโมเดลโดยตรง
    • คอนเท็กซ์เริ่มต้น 48K ค่อนข้างระมัดระวัง และควรขยายเมื่อมีหน่วยความจำเหลือ
    • การรัน Claude Code แบบโลคัล ยังไม่สามารถแทนที่ Anthropic API ได้ทั้งหมด, จึงยังมีข้อจำกัดกับงานขนาดใหญ่
    • บนเครื่อง 48GB จะเกิด แรงกดดันด้านหน่วยความจำและมีการใช้ swap, จึงแนะนำ 64GB ขึ้นไป

  • ขั้นตอนถัดไป

    • มีแผนจะ ทดสอบเปรียบเทียบ กับ Qwen 3.5 35B, GLM 4.7 Flash, Nemotron 3 Nano
    • สรุปขั้นตอนการใช้งาน: 
      curl -fsSL https://lmstudio.ai/install.sh | bash
lms daemon up
lms get google/gemma-4-26b-a4b
lms chat google/gemma-4-26b-a4b --stats
    • การเชื่อมต่อกับ Claude Code: เพิ่มฟังก์ชัน claude-lm แล้วรัน claude-lm
    • สามารถนำไปใช้สร้าง local AI workflow และผสานเข้ากับเว็บแอปหรือสภาพแวดล้อมนักพัฒนาได้

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

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

 
GN⁺ 23 일 전
ความคิดเห็นจาก Hacker News

  • สามารถใช้ llama.cpp server โดยตรงเพื่อรัน LLM แบบโลคัล และนำไปใช้กับ Claude Code หรือ CLI agent อื่น ๆ ได้
    ได้สรุป คู่มือตั้งค่าฉบับเต็ม สำหรับการทดสอบ LLM แบบ open-weight รุ่นใหม่อย่าง Gemma4 บน MacBook M1 Max 64GB
    โมเดล 26BA4B น่าสนใจที่สุดบนฮาร์ดแวร์นี้ และมี ความเร็วในการสร้างโทเคน (40 tok/s) เร็วกว่า Qwen3.5 35BA3B เกือบสองเท่า
    แต่ผล benchmark ของ tau2 ต่ำกว่าโมเดลสาย Qwen (68% เทียบกับ 81%) จึงคาดว่าไม่น่าจะเหมาะกับ งานซับซ้อนที่เน้นการใช้เครื่องมือ

    • สงสัยว่าใน Claude Code มีปัญหา ข้อกำหนดสเปกขัดกัน ระหว่าง Anthropic กับ OpenAI หรือไม่
      ฉันใช้ mlx_vlm กับ vMLX อยู่ และเจอข้อผิดพลาด 400 Bad Request ใน Claude Code
      เลยอยากถามว่าใน llama-server ไม่มีปัญหาแบบนั้นใช่ไหม

  • รู้สึกว่าโมเดลโลคัลตอนนี้ไม่ได้อยู่แค่ระดับ “พอทำได้” อีกต่อไป แต่เข้าสู่ช่วงที่ ใช้งานได้สบายจริง แล้ว
    โดยเฉพาะเวิร์กโฟลว์ headless LM Studio ที่น่าประทับใจ เพราะทำให้ใช้การอนุมานแบบโลคัลในเครื่องมือจริงได้
    ฉันกำลังพัฒนา open-source CLI coding agent ชื่อ cloclo ซึ่งรองรับแบ็กเอนด์หลายแบบ เช่น LM Studio, Ollama, vLLM, Jan, llama.cpp ฯลฯ
    โมเดลโลคัลกำลังเข้าใกล้การเป็นชุดผสมที่เหมาะที่สุด คือ ใช้ส่วนตัวในชีวิตประจำวันแบบเป็นส่วนตัวและประหยัด ส่วนโมเดลคลาวด์ใช้กับงานที่ต้องการประสิทธิภาพสูง

    • สงสัยว่า cloclo ต่างจาก pi-mono อย่างไร

  • แก่นสำคัญของเรื่องนี้ไม่ใช่ตัว Gemma 4 เอง แต่คือการที่ harness ถูกแยกออกจากโมเดลอย่างสมบูรณ์
    Claude Code, OpenCode, Pi, Codex ต่างก็ทำงานกับแบ็กเอนด์ใดก็ได้
    นั่นหมายความว่า coding agent กำลังกลายเป็น ชั้นกลางแบบทั่วไป มากขึ้นเรื่อย ๆ และการแข่งขันกำลังย้ายไปที่คุณภาพโมเดลกับต้นทุน
    นี่เป็นเรื่องดีสำหรับผู้ใช้ และเป็นภัยคุกคามต่อบริษัทที่เคยพึ่งพา harness

    • ฉันกลับคิดว่าตรงกันข้าม โมเดลต่างหากที่กำลังกลายเป็นของทั่วไป และ harness กับ tooling คือหัวใจของการเพิ่มประสิทธิภาพจริง
      ตัวอย่างเช่นในบทความ “Improving 15 LLMs at Coding in One Afternoon” ก็ระบุว่าแค่เปลี่ยน harness ก็ปรับปรุงได้มากแล้ว
    • จริง ๆ แล้วสามารถต่อ Claude Code หรือ OpenCode เข้ากับ local HTTP endpoint ได้โดยตรงอยู่แล้ว

  • สามารถรันได้ง่าย ๆ ด้วยคำสั่ง ollama launch claude --model gemma4:26b

    • ถ้าไม่เพิ่มขนาด context window ความสามารถในการเรียกใช้เครื่องมือจะไม่ทำงาน
    • น่าทึ่งที่แค่ติดตั้ง ollama กับ claude ก็ใช้งานได้ง่ายขนาดนี้
    • แต่ในกรณีของฉันมันไม่ทำงาน โดย claude เข้า ลูปไม่สิ้นสุด และไม่ตอบกลับ
      Nemotron, glm, qwen 3.5 ใช้ได้ปกติ แต่ gemma มีปัญหา

  • แนวทางนี้น่าจะมีประโยชน์กับ การทำระบบอัตโนมัติสำหรับการทดสอบซอฟต์แวร์เว็บ ด้วย
    Selenium หรือ Puppeteer มักทำให้เทสต์พังง่ายเมื่อดีไซน์เว็บเปลี่ยนเพียงเล็กน้อย
    แต่โมเดลแบบนี้น่าจะปรับตัวกับความเปลี่ยนแปลงได้ จึงทำให้การทดสอบ ยืดหยุ่นกว่า
    โดยเฉพาะดูเหมือนว่าแม้แต่โมเดลขนาดเล็กก็น่าจะเพียงพอ

  • MoE ไม่ได้ช่วยประหยัด (V)RAM จริง
    น้ำหนักทั้งหมดต้องอยู่ในหน่วยความจำ และเพียงแค่ใช้บางส่วนในแต่ละครั้งของการอนุมานเท่านั้น
    ดังนั้น tok/s จึงดีขึ้น แต่การใช้ VRAM ยังเท่าเดิม

    • ตอนแรกฉันก็สับสนเหมือนกัน expert ที่ไม่ทำงานจะถูกข้ามการคำนวณ แต่ยังคงถูกโหลดอยู่ในหน่วยความจำ
      สื่อภาพอธิบายนี้ ช่วยให้เข้าใจได้มาก
    • ใน inference engine บางตัวสามารถ offload expert บางส่วนไปยัง CPU RAM ได้
      เช่น สามารถรัน MoE ขนาด 35B พารามิเตอร์ได้ด้วย GPU VRAM 12GB + RAM 16GB
    • ไม่จำเป็นต้องเก็บน้ำหนักทั้งหมดไว้ในหน่วยความจำพร้อมกันเสมอไป
      สามารถ สลับโหลดเฉพาะส่วนที่ต้องใช้ จาก RAM, ดิสก์, เครือข่าย ฯลฯ ได้
      MoE ช่วยลดปริมาณข้อมูลที่ต้องสลับโหลดในขั้นอนุมานครั้งถัดไป

  • ฉันใช้ Claude Code เป็น อินเทอร์เฟซหลักสำหรับงานวนซ้ำใน data pipeline
    โดยเฉพาะงานทำข้อมูลเปิดเผยตามข้อกำกับของภาครัฐ (XBRL) ให้เป็นมาตรฐาน และเปิดให้ใช้ผ่าน REST กับ MCP
    ส่วนที่น่าสนใจคือ MCP เพราะแทนที่จะเรียก client โดยตรง มันใช้การ ประกาศเครื่องมือแบบ declarative และให้โมเดลเป็นผู้ตัดสินใจว่าจะเรียกเมื่อไร
    ตัวอย่างเช่นคำถามอย่าง “เปรียบเทียบแนวโน้ม leverage ตลอด 10 ปีของบริษัทนี้กับค่าเฉลี่ยอุตสาหกรรม” สามารถถูกแยกเป็นลำดับการเรียกเครื่องมือที่เหมาะสมได้โดยอัตโนมัติ
    แต่ในการใช้งาน MCP แบบโต้ตอบ latency มีความสำคัญมากกว่าอย่างเห็นได้ชัด
    การตอบใน 2 วินาทีอาจพอรับได้ในสคริปต์ แต่จะทำให้จังหวะการสนทนาสะดุด
    ฉันเลยแคชตารางที่ใช้บ่อยไว้ในหน่วยความจำ จนได้เวลาตอบต่ำกว่า 100ms
    เลยสงสัยว่าคนอื่น ๆ ก็เจอ threshold ของ latency แบบนี้เหมือนกันหรือไม่

    • ฉันก็ใช้ MCP อย่างมีประโยชน์ แต่ การใช้โทเคน อาจเพิ่มขึ้นมาก
      ถ้าเป็น implementation แบบตรงไปตรงมา มันอาจใช้โทเคนเพิ่มขึ้นเป็นหลักหลายหมื่นเมื่อเทียบกับฟังก์ชันเดียวกัน
      มี บทความอธิบายของ Anthropic แต่เป็นข้อมูลที่ค่อนข้างเก่าแล้ว
    • จากประสบการณ์ของฉัน 300~500ms ต่อการเรียกใช้เครื่องมือหนึ่งครั้งคือ เพดานบนที่ยังรู้สึกเป็นธรรมชาติ
      ถ้ามากกว่านั้น chain หลายขั้นจะช้าลง และโมเดลจะเพิ่มการอนุมานที่ไม่จำเป็นจนบริบทบวม
      นอกจากการแคชแล้ว กลยุทธ์ ลดจำนวนรอบการเรียกกลับไปกลับมา โดยให้คืนข้อมูลหลายอย่างในครั้งเดียวก็ได้ผลดี

  • มีการแชร์วิธีตั้งค่า Gemma 4 26B บน macOS ให้เป็น local inference สำหรับ Claude Code

    • คิดว่าเป็นสรุปที่ยอดเยี่ยม

  • ต่อไปสถาบันวิจัย AI รายใหญ่ต่าง ๆ อาจเดินไปสู่โครงสร้างที่ รัน local LLM ควบคู่กัน เพื่อลดภาระบนคลาวด์ และใช้คลาวด์เฉพาะงานคำนวณหนักก็ได้

    • แต่ก็สงสัยว่านั่นจะ ขัดกับโมเดลธุรกิจ ของพวกเขาหรือไม่

  • สงสัยว่าโมเดล Gemma 4 ทำงานกับ งานเขียนโค้ดแบบเอเจนต์ ได้ดีแค่ไหน และความประทับใจจากการใช้งานจริงเป็นอย่างไร