หลังจากรีวิว DGX Spark ไปแล้ว หลายคนถามว่า "แล้วเอาไปทำอะไรได้บ้าง?" - คำตอบหนึ่งที่น่าสนใจคือ DiffusionGemma ตัวล่าสุดจาก Google DeepMind ที่เพิ่ง release บน Hugging Face ไม่กี่วันก่อน
บทความนี้จะเล่าเรื่อง DiffusionGemma คืออะไร ทำไม NVFP4 quantization ถึงสำคัญ และลองรันบน DGX Spark จริงๆ จะเป็นอย่างไร
ผมตั้งค่า vLLM มาหลายเดือนด้วยสูตรเดียวตลอด — temperature: 0.6, top_p: 0.95, top_k: 20 แล้วก็ปล่อยให้ client ไป override เอาเอง ไม่ว่าจะเป็น trading bot, Hermes agent, code review — ใช้ค่าเดียวกันหมด
จนเมื่อวานนี้ผมเปิด Hugging Face model card ของ Qwen3.6-35B-A3B อ่านเล่น ๆ ในส่วน Sampling Parameters ถึงได้รู้ว่า — Qwen team แนะนำ sampling ตาม mode และ task type ไม่ใช่ตาม benchmark หรือ use case แบบที่ผมเข้าใจ
อ้าว ผมเลยต้องกลับมานั่งคิดใหม่
ผมเคยตั้งค่า vLLM มาหลายเดือนด้วยสูตรเดียวตลอด — temperature: 0.6, top_p: 0.95 แล้วก็ปล่อยให้ทุก client ไป override เอาเอง ไม่ว่าจะเป็น Claude Code, Hermes Agent หรือ OpenWebUI — ใช้ค่าเดียวกันหมด
ผมคิดว่า "โมเดลตัวเดียวกัน ก็ต้องตั้งค่าเหมือนกันสิ" — จนกระทั่งลองเปลี่ยน sampling ตาม use case แล้วเห็นว่า โมเดลตัวเดียวกัน + sampling ต่างกัน = พฤติกรรมต่างกันโดยสิ้นเชิง
Qwen3.6-35B-A3B รันอยู่บน DGX Spark (port 8001, vLLM v0.23.0, 128K context)
ที่ผ่านมาใช้ temperature 0.6 ตาม --override-generation-config ของ recipe แต่พออ่าน HF model card ละเอียด ๆ เจอว่า Qwen team เองใช้ค่า ต่างกัน ในแต่ละ benchmark category
เลยรวบรวมมาเป็น note สั้น ๆ เพื่อใช้อ้างอิง
ช่วงนี้ผมเขียนบล็อกไป 6 บทความ — แต่ละบทความเป็นเรื่องราว (journey) แยกกัน แต่ทั้งหมดเชื่อมโยงกันในธีมเดียวกัน: การสร้าง AI infrastructure เอง เริ่มจาก optimize model serving → debug API → ออกแบบโปรโตคอลสำหรับ agent → จนถึง workflow การทำงานร่วมกับ AI agents
ถ้าเพิ่งเข้ามาอ่าน อาจงงว่า "เริ่มบทความไหนดี" — เลยเขียน overview นี้ขึ้นมาเป็น landing page พร้อม reading order
ตอน DGX Spark มาถึงบ้าน ผมตื่นเต้นมาก — GB10 chip, 128GB unified memory, Blackwell architecture ผมคิดว่า "แค่เสียบปลั๊ก ติดตั้ง vLLM ก็ให้บริการ LLM ได้แรงๆ แล้ว" — แต่ความจริงหาเป็นแบบนั้นไม่
DGX Spark ไม่ใช่เครื่อง plug-and-play มันเป็นเครื่องสำหรับคนที่พร้อมจะเรียนรู้ - เรียนรู้เรื่อง serving engines, โครงสร้างของ model, รูปแบบ quantization และอีกหลายเรื่อง ก่อนที่จะดึงพลังออกมาได้เต็มที่
การเดินทางนี้กินเวลาหลายวัน ผมต้องศึกษา vLLM, llama.cpp, ความแตกต่างระหว่าง MoE กับ Dense, quantization ทุกแบบ (FP4, FP8, BF16, NVFP4) จนในที่สุดก็เข้าใจว่าทำไมคนอื่นถึงบอกว่า "DGX เป็นเครื่องสำหรับนักพัฒนาที่ใช้เฉพาะทาง"
หลังจากยุ่งกับการทดลอง model + tune config + debug API มาเกือบอาทิตย์แล้ว วันนี้ได้ฤกษ์นั่งเขียนรีวิว DGX Spark ที่ซื้อมา จะเล่าแบบตรงๆ ตามประสบการณ์จริงทั้งข้อดีและข้อเสีย ไม่มี hype ไม่มี marketing — แค่ "ซื้อมา ใช้มา เจออะไรมา" ครับ
Note: เครื่องที่ผมได้ — MSI EdgeXpert MS-C931 (รหัส SKU: 60STH-BGB104TG5) ใช้ chip NVIDIA GB10 Grace Blackwell เหมือนกับ NVIDIA DGX Spark แต่ MSI อ้างว่า thermal design ดีกว่า ทำให้เร็วกว่า 5-10% ในงานส่วนใหญ่
หลังจาก optimize DGX Spark และ debug LiteLLM มาหลายวัน ผมเริ่มเข้าใจว่า "AI infrastructure" ไม่ได้จบแค่ตรงรัน model — มันคือการออกแบบ layer ทั้งหมด ตั้งแต่ model serving → routing → agent framework → tool integration และหนึ่งในเรื่องที่ developer หลายคน (รวมถึงผม) ต้องเรียนรู้เพิ่มคือ Model Context Protocol (MCP) — มาตรฐานที่ Anthropic สร้างขึ้นเพื่อให้ agent คุยกับ tool ได้แบบเสียบแล้วใช้ได้เลย
วันนี้จะมาเล่าเรื่อง MCP architecture แบบครบวงจร — ตั้งแต่ transport types, การออกแบบ server, การออกแบบ client, ไปจนถึงการเชื่อมต่อกับ self-hosted models ของเราเอง
ปัญหาหนึ่งของ AI agent ที่ผมเจอตอนเริ่มใช้งานจริง: ทุกครั้งที่เริ่ม session ใหม่ agent จะจำอะไรไม่ได้เลย ถามคำถามเดิมซ้ำ ต้องอธิบายบริบทใหม่ทุกครั้ง ไม่รู้ว่าผู้ใช้ชอบอะไร ไม่ชอบอะไร ผมลองหลายวิธี — เขียนบันทึกสนทนาลงไฟล์ ใช้ vector store เก็บข้อมูล สร้างระบบความจำเอง — จนมาเจอ Honcho ซึ่งเป็น open-source memory infrastructure จาก Plastic Labs ที่ตอบโจทย์ตรงนี้
วันนี้เล่าเรื่อง Honcho ตั้งแต่ "ทำไมต้องมี memory layer" → "Honcho architecture" → "ผมใช้งานยังไง" → "เทียบกับ Mem0/Letta/Zep"
เรื่องมันเริ่มจากปัญหาที่น่ารำคาญมากตอนเที่ยงคืนครับ API ที่ผมใช้รัน backtest trading bot มัน timeout แบบสุ่ม — บาง call ผ่าน บาง call ไม่ผ่าน แถมพอลองยิง prompt เดิมซ้ำ ก็ได้ output กลับมาทันที ฟังดูขัดแย้งใช่ไหมครับ?
ผมใช้เวลาทั้งคืนไล่หาสาเหตุ จนในที่สุดก็พบว่า ปัญหาไม่ได้อยู่ที่ vLLM ไม่ได้อยู่ที่ DGX Spark และไม่ได้อยู่ที่ model เลย — มันอยู่ที่ LiteLLM proxy layer ที่ผมตั้งใจใช้เป็น "แค่ทางผ่าน" ตั้งแต่ต้น