@nanobro.eth

nanobrohttps://blog.nanobro.co ai, blockchain, tech, and lifestyleSun, 19 Jul 2026 02:14:17 GMThttps://validator.w3.org/feed/docs/rss2.htmlhttps://github.com/jpmonette/feedennanobrohttps://storage.googleapis.com/papyrus\_images/5ce3eccbb4eeb5bbdf74f263915477e4https://blog.nanobro.co

All rights reserved<![CDATA[Deploy Unsloth Quantized Models on AWS]]>https://blog.nanobro.co/deploy-unsloth-quantized-models-on-aws CdKjClsu48eZwyZ71vdjMon, 13 Jul 2026 15:35:45 GMTภาพประกอบ Unsloth Quantization บน AWS

รันโมเดล AI ให้ถูกลงด้วย Unsloth Quantization บน AWS: เลือกไฟล์ให้ถูกก่อนเลือกเครื่อง

โมเดลเก่งๆ มักมีปัญหาเดียวกันคือ "ใหญ่เกิน"

เอาโมเดลไป serve แบบ BF16 หรือ FP16 ตรงๆ ก็ต้องใช้ GPU ใหญ่ ค่าเครื่องสูง เปิด endpoint นาน แถมลองผิดลองถูกทีหนึ่งก็เสียเงินไปเรื่อยๆ

ทางออกที่น่าสนใจคือ quantization

พูดง่ายๆ คือย่อขนาดน้ำหนักของโมเดล เช่น จาก 16-bit เหลือ 4-bit เพื่อให้ใช้ RAM หรือ VRAM น้อยลงมาก

แต่ก็มีจุดที่ต้องระวัง ถ้าย่อแรงเกินไป คุณภาพโมเดลก็ดรอปได้

Unsloth เลยมีแนวทางที่เรียกว่า Dynamic Quantization ซึ่งไม่ลด precision ทุก layer เท่ากันแบบเหมาๆ แต่เก็บส่วนสำคัญของโมเดลไว้ที่ precision สูงกว่า แล้วบีบเฉพาะส่วนที่ทนต่อการลด precision ได้

ผลคือโมเดลเล็กลง แต่พยายามรักษาคุณภาพคำตอบไว้ให้ใกล้ต้นฉบับที่สุด

มันลดได้เยอะแค่ไหน?

โมเดล BF16 ใช้ 16 บิตต่อพารามิเตอร์

ถ้าทำเป็น 4-bit ในทางทฤษฎีขนาดจะลดลงราว 75%

ตัวอย่างโมเดลขนาด 8B parameters ที่เดิมกิน memory ประมาณ 16 GB อาจลงมาอยู่แถว 5 GB ได้ หลังรวม metadata สำหรับ quantization แล้ว

ตรงนี้สำคัญมาก เพราะบางงานจากเดิมต้องใช้หลาย GPU อาจพอดีกับ GPU เดียว หรือบางงานเล็กพอจะวิ่งบน CPU ได้เลย

แต่ไม่ได้แปลว่า 4-bit เหมาะกับทุกงาน

ถ้าคุณทำงานที่ต้องการความแม่นสูงมาก เช่น extraction, reasoning เฉพาะทาง หรือ multimodal ที่มีภาพซับซ้อน ต้อง benchmark กับข้อมูลจริงของตัวเองก่อนเสมอ

หลักคิดที่ AWS และ Unsloth แนะนำ: เลือกไฟล์ก่อนเลือก infrastructure

หลายคนเริ่มจากคำถามว่า "ต้องเปิด SageMaker instance เบอร์ไหนดี?"

แต่ลำดับที่ใช้งานจริงควรกลับกัน

  1. จะ export โมเดลเป็นไฟล์อะไร

  2. ไฟล์นั้นใช้กับ runtime ไหน

  3. แล้วค่อยเลือกว่า EC2, SageMaker, EKS หรือ ECS เหมาะกับทีมเรา

มี 2 ทางหลักที่จำง่ายๆ

1. GGUF: ทางเล็ก เบา ลองไว

GGUF เป็นไฟล์โมเดลแบบรวม weights, tokenizer และ metadata ไว้ด้วยกัน

เหมาะกับ runtime สายเบา เช่น llama.cpp, llama-server, Ollama และ Unsloth

เหมาะเมื่อ:

ตัวเลือก quantization ที่เจอบ่อย:

2. Merged safetensors: ทาง production ที่เน้น throughput

ถ้าคุณ fine-tune LoRA แล้วอยากรวม adapter เข้ากับ base model เพื่อ serve จริงจัง ให้ดู merged weights ในรูป safetensors

ไฟล์กลุ่มนี้เหมาะกับ vLLM, SGLang และ SageMaker LMI containers

เหมาะเมื่อ:

สรุปสั้นๆ:

4 แบบในการ deploy บน AWS

แบบที่ 1: GGUF บน EC2

นี่คือจุดเริ่มที่แอดชอบสุด เพราะเห็นทุกอย่างชัดและ debug ง่าย

เอา GGUF ไปเปิดด้วย llama.cpp หรือ Unsloth บน EC2 แล้วลองเทียบ q4, q8 และ full precision กับ prompt จริงของเรา

สิ่งที่ควรเช็ก:

อย่าดูแค่ขนาดไฟล์นะครับ

โมเดลไฟล์ 128 GB ควรมี RAM หรือ VRAM ว่างมากกว่า 128 GB ไม่งั้นตอน inference จริงอาจพังได้ โดยเฉพาะเมื่อมี context ยาวหรือ concurrent request

ถ้าเปิด API บน EC2 เพื่อทดสอบ อย่าเปิด public ทิ้งไว้

⚠️ จำกัด Security Group ให้เฉพาะ CIDR ที่เชื่อถือได้, bind ที่ private interface และวางไว้หลัง authenticated API gateway หรือ load balancer ก่อนเอาไปใช้จริง

แบบที่ 2: GGUF บน SageMaker AI ด้วย custom container

พอโมเดลผ่านการทดสอบแล้ว แต่ไม่อยากดูแล server เอง SageMaker AI inference endpoint จะเริ่มน่าสนใจ

SageMaker ให้ autoscaling, monitoring, IAM และ endpoint ที่จัดการเป็นระบบมากกว่า EC2

สำหรับ GGUF ปกติจะห่อ llama.cpp เข้า custom container

container ต้องทำตามสัญญาของ SageMaker:

ในตัวอย่างของ AWS มีการวาง nginx เป็นตัวแปลง path จาก SageMaker ไปหา llama-server ภายใน container

จุดนี้ฟังดูเหมือนงานเพิ่ม แต่เป็นส่วนที่ทำให้ runtime เบาๆ อย่าง llama.cpp ไปอยู่บน managed endpoint ได้

AWS ยกตัวอย่าง Qwen3-VL-8B-Instruct แบบ Q4_K_XL GGUF บน ml.g5.xlarge ราคาประมาณ $1.41/ชั่วโมง เทียบกับ BF16 ที่ใช้ vLLM บน ml.g5.12xlarge ประมาณ $7.09/ชั่วโมง

ตัวเลขเป็นราคา ณ มิถุนายน 2026 และควรเช็กราคาปัจจุบันก่อนเปิดใช้งานจริง

แบบที่ 3: merged weights บน SageMaker AI + vLLM/LMI

ถ้า GGUF คือทางประหยัดและเบา ทางนี้คือทางที่เน้น serve ให้คุ้มตอน traffic มาเยอะ

SageMaker LMI containers เปิดทางให้ใช้ vLLM ได้โดยไม่ต้องเขียน custom container เองทั้งหมด

จุดที่ได้คือ:

ถ้างานเริ่มมีผู้ใช้จริงหรือ API ถูกเรียกพร้อมกันเยอะๆ การจ่ายเพิ่มกับ runtime ที่ serve เก่งกว่า อาจคุ้มกว่าการฝืนใช้ GGUF แล้ว latency ร่วง

แบบที่ 4: EKS หรือ ECS

ถ้าทีมคุณมี Kubernetes หรือ ECS อยู่แล้ว และระบบ inference ต้องอยู่ใน network, observability และ deployment flow เดียวกับ service อื่น ก็ไม่จำเป็นต้องสร้างโลกใหม่บน SageMaker

แพ็ก runtime ที่เลือกไว้ลง container แล้ว deploy ไปกับ platform เดิมได้เลย

โจทย์ในแบบนี้ไม่ใช่ "ต้องใช้ SageMaker ไหม"

แต่คือ "ไฟล์จาก Unsloth แบบไหนเข้ากับ runtime ที่เราจะ containerize มากที่สุด"

จุดที่คน deploy โมเดลพลาดกันบ่อย

Chat template ไม่ตรง

บางทีโมเดลทำงานดีใน environment ตอน train แต่พอ deploy แล้วตอบแปลก คนก็มักโทษ quantization ก่อน

ความจริงอาจเป็น chat template, EOS token หรือรูปแบบ prompt ไม่ตรงกับตอน train

ให้เช็กส่วนนี้ก่อนครับ โดยเฉพาะโมเดล instruction-tuned

Benchmark แค่ระดับ quantization

อย่าทดสอบแค่ q4 vs q8 แล้วจบ

ของจริงต้องดูพร้อมกันทั้ง:

ไฟล์เล็กสุดไม่ได้แปลว่าระบบถูกสุดเสมอ

ถ้า context ยาวมาก หรือ traffic พุ่งเป็นช่วงๆ โมเดลที่เล็กกว่าอาจกลายเป็น bottleneck ได้

โหลดโมเดลจากภายนอกทุกครั้งที่ start

พอ finalize โมเดลแล้ว ควรเก็บ artifact ใน S3 ให้ path ชัดเจนและ promote เป็นลำดับ

การโหลดจาก Hugging Face หรือแหล่งภายนอกทุกครั้งที่ endpoint start ทำให้ cold start คาดเดายาก และลำบากขึ้นใน VPC ที่จำกัด network

วัดแค่คุณภาพโมเดล ไม่วัด service

production ไม่ได้มีแค่คำตอบดีหรือไม่ดี

ต้องดู startup time, tail latency, concurrency, scaling behavior และเวลาโหลดโมเดลด้วย

บน SageMaker ดู metric ผ่าน CloudWatch ได้เลย ส่วน EC2 ก็ควร expose metric เทียบเท่ากัน

สรุปแบบคนจะเอาไปทำจริง

ถ้าเพิ่งเริ่ม:

  1. export โมเดลเป็น GGUF

  2. ลองบน EC2 ด้วย llama.cpp หรือ Unsloth

  3. เปรียบเทียบ q4, q8 และ model เต็มกับชุดทดสอบของเรา

  4. ตรวจ chat template และ memory peak

  5. ถ้าต้องการ managed endpoint ค่อยย้าย GGUF ไป SageMaker custom container

ถ้า traffic เริ่มมา หรือ throughput คือโจทย์หลัก:

  1. merge weights เป็น safetensors

  2. ใช้ vLLM, SGLang หรือ SageMaker LMI

  3. ทดสอบ batching, concurrency และ tensor parallelism

  4. ตัดสินใจด้วย cost ต่อ request และ latency จริง ไม่ใช่แค่ราคา instance

Unsloth ทำให้เรื่องนี้สนุกขึ้น เพราะเราไม่ได้ถูกบังคับให้เอาโมเดลไฟล์เดียวไปใช้กับทุก environment

งานที่ต้องประหยัดก็ใช้ quantized GGUF

งานที่ต้องรับโหลดก็ใช้ merged weights กับ runtime ที่เหมาะกว่า

สุดท้ายแล้ว เลือก model artifact ให้ตรงกับงานก่อน แล้ว infrastructure จะเลือกง่ายขึ้นมากๆ

แหล่งอ้างอิง

บทความนี้เรียบเรียงและสรุปจากบทความ AWS Machine Learning Blog เผยแพร่วันที่ 10 กรกฎาคม 2026 ไม่ใช่คำแปลตรงตัว และราคา AWS เปลี่ยนแปลงได้เสมอ

]]>nanobro.eth@newsletter.paragraph.com (nanobro_rit)aiawsunslothsagemaker<![CDATA[Spark Doctor for DGX Spark]]>https://blog.nanobro.co/spark-doctor-for-dgx-spark S4WPUlo7gaBp9KrE6FFmSun, 12 Jul 2026 07:39:40 GMTDoctor สำหรับ dgx sparkโดยเฉพาะ

Doctor สำหรับ dgx sparkโดยเฉพาะ

Doctor สำหรับ dgx sparkโดยเฉพาะ

Spark Doctor คือเครื่องมือช่วยวินิจฉัยปัญหาสำหรับคนใช้ NVIDIA DGX Spark และ GB10 ที่เจออาการรัน AI แล้วหาสาเหตุไม่เจอ

อัปเดตล่าสุดเพิ่มการเช็กปัญหา PyTorch/CUDA โดยเฉพาะ เช่น

สั่งครั้งเดียว:

spark-doctor scan

ยังเช็กปัญหาเฉพาะ DGX Spark ได้ เช่น GPU ติดเพดานไฟ 14W, unified memory ตึง, ความเสี่ยงความร้อน, Docker/NVIDIA runtime และ recipe ที่ตั้งค่าไม่เหมาะกับเครื่อง

เป็นเครื่องมือ read-only - ไม่แก้เครื่องเอง ไม่ส่ง telemetry แต่บอกชัดว่าอะไรผิด ทำไมถึงผิด และควรลองแก้อะไรต่อ

Credit: @aijoey #DGXSpark #NVIDIA #CUDA #PyTorch #LocalAI

]]>nanobro.eth@newsletter.paragraph.com (nanobro_rit)ainvidiadgx sparkcudapytorchnanobro<![CDATA[Cloudflare Drop: ดีพลอยเว็บสแตติกเสร็จใน 5 วินาทีแบบ Zero Friction]]>https://blog.nanobro.co/cloudflare-drop-fast-deploy PovNBBhJBvuLI4fR6XqUThu, 09 Jul 2026 11:50:30 GMTQ: Cloudflare Drop คืออะไร?

A: Cloudflare Drop คือวิธีดีพลอย (deploy) เว็บไซต์แบบด่วนที่สุดผ่านเว็บเบราว์เซอร์ของคุณโดยตรง เพียงแค่ทำตามแนวคิดลากแล้ววาง (Drag and Drop) โดยเอาโฟลเดอร์ของเว็บหรือไฟล์ ZIP ไปวางบนหน้าเว็บ ก็เตรียมรับ URL ออกสู่สายตาชาวโลกบนเครือข่าย Edge Global ของ Cloudflare ได้ทันที

จุดเด่นที่น่าสนใจ

มุมการนำไปใช้งานจริง (Real-World Use Cases)

แนวคิดเบื้องหลังของ Cloudflare Drop คือการขจัดอุปสรรคในการขึ้นระบบให้เหลือศูนย์ที่สุด (Zero Friction) ที่น่าจับตาคือ Cloudflare กำลังนิยามคำว่า ”เอาโฟลเดอร์ขึ้นเว็บให้เร็วที่สุด” ใหม่ เพื่อให้ทุกคนเข้าถึงประสิทธิภาพระดับโปรได้โดยไม่มีความรู้เรื่อง Infra ด้วยซ้ำ

ถ้าอยากไปลองใช้งานด้วยตัวเอง เข้าลิงก์โดยตรงได้ที่ cloudflare.com/drop แล้วสัมผัสความเร็วแสงของการดีพลอยได้เลยครับ!

]]>nanobro.eth@newsletter.paragraph.com (nanobro_rit)ainanobro<![CDATA[Personal take]]>https://blog.nanobro.co/personal-take jkA3p9UfWfiwRqYtPvBaWed, 01 Jul 2026 18:23:08 GMT💬 ความเห็นส่วนตัว:

💬 ความเห็นส่วนตัว:

คนประมาณ 11% ของอินเทอร์เน็ตยังใช้ password ในลิสต์นี้ — ดูสิเพื่อนๆ ยังใช้กันอยู่รึเปล่า 😂

แอดเคยใช้ "qwertyu" นี่แหละ ตอนคิดได้รู้สึกจีเนียสมากๆ 55555

🔐 Password ไหนที่แฮ็กง่ายที่สุด? (และคุณอาจใช้มันอยู่ตอนนี้)

ถ้าคุณตั้ง password ว่า "123456" — หยุดอ่านตรงนี้ แล้วเปลี่ยนเดี๋ยวนี้ 🚨

จากการวิเคราะห์ข้อมูล breach หลายล้านบัญชีทั่วโลก (Have I Been Pwned, SplashData, Adobe, LinkedIn ฯลฯ) นี่คือ Top 10 Password ที่คนใช้บ่อยที่สุด และแฮ็กเกอร์รู้หมด:

1️⃣ 123456 — เบอร์หนึ่งตลอดกาล 2️⃣ password — ชื่อเดียวกับคำศัพท์ dictionary 3️⃣ 123456789 — ต่อเลขไปเรื่อยๆ 4️⃣ 12345678 — ย่อมาหน่อย 5️⃣ 12345 — สั้นแต่ยังใช้กันเพียบ 6️⃣ 1234567 — อีกตัวที่ต่อเลข 7️⃣ qwerty — พิมพ์แถวบนสุดของคีย์บอร์ด 8️⃣ abc123 — ตัวอักษร + ตัวเลขง่ายๆ 9️⃣ 111111 — เลขซ้ำ 🔟 1234 — สั้นที่สุดที่ยังมีคนใช้

💀 ความจริงที่น่ากลัว:

• Password เหล่านี้แฮ็กได้ใน "เสี้ยววินาที" ด้วย brute force • แฮ็กเกอร์มี dictionary password เหล่านี้พร้อมอยู่แล้ว ไม่ต้องเดา • คนประมาณ 11% ของอินเทอร์เน็ตยังใช้ password ในลิสต์นี้ (ข้อมูลจาก SplashData) • ถ้าแฮ็กเกอร์ได้ email + password นี้ — เขาจะลองกับเว็บอื่นต่อ เพราะคนส่วนใหญ่ตั้ง password เดียวกันทุกที่

✅ วิธีแก้ (ง่ายมาก):

  1. เปลี่ยน password ที่ซ้ำกันทุกเว็บ — ใช้ password manager เช่น Bitwarden (ฟรี), 1Password, หรือ KeePass

  2. เปิด 2FA ทุกที่ที่ทำได้ — แม้ password จะรั่ว เขาก็เข้าไม่ได้

  3. เช็คตัวเองที่: haveibeenpwned.com — ดูว่า email เราไปโผล่ใน breach ไหนบ้าง

  4. อย่าใช้ชื่อสัตว์เลี้ยง, วันเกิด, หรือคำศัพท์ dictionary อย่างเดียว

🎯 กฎง่ายๆ สำหรับ password ที่ดี:

• ยาวอย่างน้อย 12 ตัวอักษร (ยาว = ดีกว่าซับซ้อน) • ใช้วลีแบบ pass phrase เช่น "ช้าง-กิน-กล้วย-6โมง" — จำง่าย แฮ็กยาก • ไม่ซ้ำกันทุกเว็บ • เก็บใน password manager

⚠️ ถ้าคุณอ่านบทความนี้แล้วรู้สึก "อ๋อ ฉันใช้ 123456 อยู่" — อย่าอายครับ คนส่วนใหญ่ใช้ แต่สิ่งที่ต่างกันระหว่างคนปลอดภัยกับโดนแฮ็ก คือการเปลี่ยนมันตอนนี้ ไม่ใช่ตอนโดนล้วงข้อมูลไปแล้ว

แชร์ให้เพื่อนที่อาจยังใช้ password เก่าอยู่ — อาจช่วยเขาไว้ก็ได้ 🙏

#CyberSecurity #PasswordSafety #InfoSec

]]>nanobro.eth@newsletter.paragraph.com (nanobro_rit)ainanobro<![CDATA[Ornith 1.0 AEON Ultimate Uncensored on DGX Spark]]>https://blog.nanobro.co/ornith-10-aeon-ultimate-uncensored-on-dgx-spark mvBtX74LwyHj7efvX5UNSun, 28 Jun 2026 08:15:45 GMTมีคนเอา Qwen3.5b มา fine tune เป็น Ornith ซึ่งหลายๆคนชมว่าฉลาดขึ้น

มีคนเอา Qwen3.5b มา fine tune เป็น Ornith ซึ่งหลายๆคนชมว่าฉลาดขึ้น

มีคนเอา Qwen3.5b มา fine tune เป็น Ornith ซึ่งหลายๆคนชมว่าฉลาดขึ้น

ทีนี้ Aeon อัพเกรดขึ้นอีกด้วย NVFP4 + Dflash + Uncensor

AEON-7 ปล่อย Orinth 1.0 Ultimate Uncensored — โมเดล AI โค้ดดิ้งเทพ 35B ที่รันบน DGX Spark ได้ เต็มสปีด DFlash ~740 tok/s

ÆON FORGE (@SpaceTimeViking) ประกาศเปิดตัว Orinth 1.0 AEON ULTIMATE UNCENSORED ซึ่งเป็นเวอร์ชัน abliterated/uncensored ของโมเดล Ornith-1.0-35B จาก DeepReinforce AI ที่มีความสามารถด้าน coding สูงระดับต้นแถว

สเปกเด่นๆ:

亮点ใหญ่: มี NVFP4 quantization variant (~23.7GB) สำหรับ DGX Spark / Blackwell architecture โดยเฉพาะ — เล็กพอที่จะรันบน GB10 (128GB unified memory) และเมื่อจับคู่กับ DFlash speculative decoding สามารถทำความเร็วได้ถึง ~740 tok/s aggregate ที่ concurrency 64

AEON-7 ทำ container พิเศษมาให้: ghcr.io/aeon-7/aeon-vllm-ultimate:latest (vLLM 0.23.0 built from source for sm_121a) พร้อม production deployment guide บน GitHub

ใครที่มี DGX Spark อยู่แล้ว นี่คือโมเดลที่น่าสนใจมากสำหรับลองเทียบกับ Qwen3.6-35B-A3B-heretic ที่มีอยู่เดิม โดยเฉพาะเรื่อง coding capability + ไม่มี filter

Credit: @SpaceTimeViking · โมเดลบน HuggingFace: AEON-7/Ornith-1.0-35B-AEON-Ultimate-Uncensored

]]>nanobro.eth@newsletter.paragraph.com (nanobro_rit)aillmdgx_sparkuncensored<![CDATA[hermes-agent-interrupt-explained]]>https://blog.nanobro.co/hermes-agent-interrupt-explained qo4pgRaYfgQ3GTJoSLX6Fri, 26 Jun 2026 16:46:06 GMTHermes Agent: พฤติกรรม Interrupt บน Discord

Hermes Agent: พฤติกรรม Interrupt บน Discord — อธิบายแบบละเอียด

เมื่อใช้ Hermes Agent บน Discord แล้วพิมพ์ข้อความขณะที่ agent กำลังทำงานอยู่ Discord จะแสดงคำว่า "interrupt" ขึ้นมา หลายคนสงสัยว่ามันทำงานอย่างไรกันแน่ — มันสร้างสองคำสั่งขนานกัน? หรือเข้าไปแก้ไขงานที่กำลังทำ? หรือมันแค่หยุดแล้วเริ่มใหม่?

คำตอบสั้นๆ คือ: Interrupt = ยกเลิกงานรอบปัจจุบันทันที แล้วจัดคิวข้อความของคุณเป็น prompt รอบต่อไป — ไม่ใช่คำสั่งขนาน ไม่ใช่การแก้งานกลางคัน

สิ่งที่เกิดขึ้นทันทีเมื่อพิมพ์ระหว่าง Agent ทำงาน

1. Agent หยุดทันที (Hard Kill)

Hermes ใช้ระบบ interrupt แบบ hard kill ไม่ใช่ soft pause ดังนั้นเมื่อข้อความของคุณถูกรับ กระบวนการต่อไปนี้จะเกิดขึ้นภายในเวลาไม่กี่มิลลิวินาที:

2. LLM Response ที่กำลัง Stream หายไป

นี่คือจุดที่หลายคนสับสน — partial response ที่ LLM กำลัง stream อยู่ตอนที่โดน interrupt จะไม่ถูก inject เข้า conversation history เลย เหมือน turn นั้นไม่เคยเกิดขึ้น ระบบไม่บันทึกข้อความกลางคันลง SQLite session ดังนั้นดูเหมือน agent "ลืม" ว่ากำลังทำอะไรอยู่

3. ข้อความใหม่ของคุณกลายเป็น Prompt ถัดไป

ข้อความที่คุณพิมพ์ระหว่าง interrupt ไม่ได้ถูก inject เข้ากลาง turn เดิม แต่จะถูกจัดเป็น prompt เริ่มต้นของรอบใหม่ ทันทีหลัง agent หยุด

Bonus: ถ้าคุณพิมพ์หลายข้อความตามกันขณะที่ agent กำลังหยุด ทุกข้อความเหล่านั้นจะถูก join ด้วย \n แล้ว combine เป็น prompt เดียว เช่น พิมพ์ "หยุดก่อน" แล้วพิมพ์ต่อ "ทำแบบนี้แทน" → agent จะรับ prompt ว่า "หยุดก่อน\nทำแบบนี้แทน" เป็น input เดียว

สิ่งที่ "หาย" และสิ่งที่ "ยังอยู่"

นี่คือส่วนที่สำคัญที่สุด เพราะหลายคนเข้าใจผิดว่า interrupt ทำให้ Hermes ลืมทุกอย่าง

| สิ่ง | สถานะหลัง Interrupt | | Conversation history ทุก turn ก่อน interrupt | ✅ ยังอยู่ครบ (บันทึกใน SQLite ทุก turn) | | System prompt และ MEMORY.md | ✅ ยังอยู่ ถูก rebuild ปกติ | | Tool results จาก tools ที่รันเสร็จแล้วก่อนหน้า | ✅ ยังอยู่ใน context | | LLM response ที่กำลัง stream อยู่ตอน interrupt | ❌ ถูกทิ้ง ไม่บันทึก | | Tool call ที่กำลัง run อยู่ตอน interrupt | ❌ ถูก kill + ผลลัพธ์หาย | | Tool calls ที่ยังรอคิวอยู่ (ยังไม่ได้รัน) | ❌ ถูก skip ทั้งหมด |

กล่าวคือ Hermes จำบทสนทนาทั้งหมดก่อนหน้าได้ แค่ "งานใน turn ที่โดน interrupt" เท่านั้นที่หายไป

ทำไมต้องทำแบบนี้ — ปัญหาระดับ API

มีเหตุผลทางเทคนิคที่ Hermes ต้องตัด unfinished tool calls ออกจาก history ก่อน submit ครั้งถัดไป

ปัญหาคือ LLM API เช่น OpenAI หรือ Anthropic ไม่ยอมรับ conversation history ที่มี assistant message ซึ่งมี tool_call อยู่แต่ยังไม่มี tool_result ตอบกลับ — มันจะ reject ด้วย error ทันที ดังนั้น Hermes จึงต้องล้าง partial turn ออก ซึ่งทำให้ดูเหมือน "ลืม" งานที่กำลังทำอยู่

Interrupt vs /steer — ต่างกันอย่างไร

หลายคนนึกว่า interrupt น่าจะทำงานแบบ /steer คือ ปรับทิศทางได้โดยยัง context เดิมอยู่ แต่จริงๆ แล้วสองอย่างนี้ต่างกันมาก:

| | Interrupt (พิมพ์ระหว่างทำงาน) | /steer | | หยุด task ปัจจุบัน? | ✅ ทันที (hard kill) | ✅ แต่เป็น soft redirect | | Tool calls ที่ทำไปแล้วยังอยู่? | เฉพาะที่เสร็จก่อน interrupt | ✅ ยังอยู่ทั้งหมด | | Context ของ turn ปัจจุบัน? | ❌ หายไปทั้ง turn | ✅ ยังอยู่ แค่เปลี่ยนทิศทาง | | ข้อความกลายเป็นอะไร? | Fresh prompt ของรอบใหม่ | Steering hint ใน turn เดิม | | เหมาะกับ? | หยุดแล้วสั่งงานใหม่เลย | ปรับแนวทางการทำงานกลางคัน |

Analogy ง่ายๆ:

Queue Mode — ทางเลือกที่หลายคนไม่รู้จัก

Hermes มี queue mode ซึ่งเป็นทางเลือกที่ดีกว่า interrupt ในหลายกรณี แทนที่จะ kill งานปัจจุบัน ข้อความของคุณจะถูกจัดคิวไว้รอจนกว่างานปัจจุบันจะเสร็จ แล้วค่อยรันต่อเนื่อง

เหมาะกับกรณีที่คุณต้องการ เพิ่ม follow-up task โดยไม่ทำลายงานที่กำลังดำเนินอยู่ — บริบทและ tool results ทั้งหมดจะสมบูรณ์กว่าการใช้ interrupt

สรุปพฤติกรรมจริงในหนึ่งประโยค

Interrupt = hard kill งาน + ลบ partial turn ออกจาก history + จัดข้อความคุณเป็น prompt รอบใหม่ โดยความจำของบทสนทนาก่อนหน้าทั้งหมดยังคงอยู่ครบ — มีแค่ turn ที่โดน interrupt นั้นเองที่หายไป

]]>nanobro.eth@newsletter.paragraph.com (nanobro_rit)hermesagentdiscordai<![CDATA[Apple Raises Prices in Thailand]]>https://blog.nanobro.co/apple-raises-prices-in-thailand 8DgCnTWaol5R3U0d0ZvLThu, 25 Jun 2026 16:18:43 GMTตั้งใจจะชายเครื่องเก่าๆแล้วอัพ ไม่ทันละมั้ง 😂😂

ตั้งใจจะชายเครื่องเก่าๆแล้วอัพ ไม่ทันละมั้ง 😂😂

ตั้งใจจะชายเครื่องเก่าๆแล้วอัพ ไม่ทันละมั้ง 😂😂

Apple ขึ้นราคาสินค้าในไทย! Mac และ iPad ปรับขึ้นหลายรุ่น รับต้นทุนชิปพุ่งจากกระแส AI

Apple ปรับขึ้นราคาสินค้าในไทย โดยเฉพาะกลุ่ม Mac และ iPad หลังต้นทุนชิปหน่วยความจำและสตอเรจพุ่งแรงจากกระแส AI

ก่อนหน้านี้ Tim Cook ให้สัมภาษณ์กับ Wall Street Journal ว่าการขึ้นราคาสินค้าของ Apple เป็นเรื่อง “หลีกเลี่ยงไม่ได้” เพราะต้นทุนชิ้นส่วนหน่วยความจำและสตอเรจปรับตัวสูงขึ้นต่อเนื่อง ขณะที่หลายสำนักข่าวต่างประเทศอย่าง TechCrunch, CNBC และ WSJ ก็รายงานไปในทิศทางเดียวกันว่า Apple เริ่มส่งผ่านต้นทุนที่เพิ่มขึ้นไปยังราคาขายแล้ว

เทียบราคาที่ปรับขึ้นทุกรุ่น

รุ่นที่ขึ้นแรงสุด

  1. iPad Air M4 11 นิ้ว - เพิ่ม 27.40%

  2. MacBook Pro M5 (1TB) - เพิ่ม 27.32%

  3. MacBook Neo (256GB) - เพิ่ม 25.13%

  4. iPad mini - เพิ่ม 22.35%

  5. MacBook Air M5 (512GB) - เพิ่ม 21.68%

สรุปเร็ว

หน่วย: บาท ตัวเลขตามข้อมูลที่ผู้ใช้ให้มา

MEDIA:/Users/ritrit/.hermes/image_cache/img_7b6fe8c34a7e.png

]]>nanobro.eth@newsletter.paragraph.com (nanobro_rit)ainanobro<![CDATA[Nerve vs Muscle Cramp]]>https://blog.nanobro.co/nerve-vs-muscle-cramp chrk49R0mh1WF8pyN8m7Thu, 25 Jun 2026 03:13:38 GMTQ: เหน็บกับตะคริวเหมือนกันมั้ย?

Q: เหน็บกับตะคริวเหมือนกันมั้ย?

Q: เหน็บกับตะคริวเหมือนกันมั้ย?

A: ไม่เหมือนกันครับ! ❌

เหน็บ (ชา/เข็มทิ่ม) ← เส้นประสาทถูกกดทับ แค่เปลี่ยนท่านั่งก็หาย ตะคริว (เจ็บกล้ามเนื้อแข็ง) ← กล้ามเนื้อหดเกร็ง ต้องยืด นวด เติมเกลือแร่

สรุป: ระบบประสาท vs ระบบกล้ามเนื้อ — คนละอาการ คนละระบบเลย!

#เหน็บ #ตะคริว #ความรู้รอบตัว #สาระน่ารู้ #สุขภาพ

]]>nanobro.eth@newsletter.paragraph.com (nanobro_rit)ainanobrohealthscience<![CDATA[Qwen3.6 benchmark on DGX thai]]>https://blog.nanobro.co/qwen36-benchmark-on-dgx-thai 28wComb64UACJiofeuSGTue, 23 Jun 2026 15:18:20 GMTเราเกือบ benchmark Qwen3.6 บน DGX ผิดไปแล้ว

บทความ benchmark โมเดล local ส่วนใหญ่ชอบเริ่มจากตารางคะแนนเลย แต่รอบนี้ถ้าเราทำแบบนั้นก็คงพลาดเรื่องสำคัญไป

เรากำลังทดสอบโมเดล Qwen3.6 แบบ GGUF บน DGX ผ่าน LM Studio แล้วใช้ lm-evaluation-harness ครอบอีกชั้น ตอนแรกตัวเลขออกมาดูน่ากังวลมาก มีรอบหนึ่งที่ GSM8K ได้ประมาณ 10 เปอร์เซ็นต์ exact match สำหรับโมเดล reasoning ระดับ 35B ซึ่งเป็นตัวเลขที่ควรทำให้สงสัยทันที แต่สิ่งที่ควรสงสัยก่อนอาจไม่ใช่ตัวโมเดลเสมอไป บางครั้ง benchmark path กำลังบอกเราว่า setup ยังหลอกเราอยู่

และนั่นคือสิ่งที่เกิดขึ้นจริง

หลังจากไล่ดู pipeline ทั้งเส้น เราพบว่าคะแนนที่แย่ส่วนใหญ่เกิดจาก evaluation path ไม่ใช่ตัวโมเดลเอง LM Studio ส่ง reasoning ออกมาแยกจาก final answer content และ token budget ที่เราให้ไว้ก็น้อยเกินไปสำหรับ Qwen3.6 สาย reasoning พูดง่าย ๆ คือโมเดลใช้ budget ไปกับการคิด แล้วถูกตัดก่อนที่จะพ่นคำตอบสุดท้ายออกมาใน field ที่ตัว scorer ใช้อ่าน

พอเราแก้ adapter และเพิ่ม output budget ให้ GSM8K มากพอ ตัวเลขจาก stack เดิมก็เริ่มกลับมาสมเหตุสมผล

บทความนี้สรุปว่าเราแก้อะไรไปแล้ว ตอนนี้เราเชื่อ metric อะไรได้บ้าง และยังมีอะไรที่ไม่ควรเชื่ออยู่

โครงของระบบที่ใช้

เราทำ benchmark โมเดล Qwen3.6 แบบ local บน DGX ด้วย stack นี้

โมเดลหลักที่ใช้ในรอบนี้มีดังนี้

ผลจริงจาก full run แรก

นี่คือผลจากรอบทดสอบเต็มบน DGX สำหรับ task ที่เราเชื่อได้ใน stack ปัจจุบัน

| Model | GSM8K exact match | IFEval inst loose | IFEval inst strict | IFEval prompt loose | IFEval prompt strict | | qwen3.6-27b-mtp-pi-reasoning | 0.00 | 0.375 | 0.375 | 0.40 | 0.40 | | qwopus3.6-27b-coder-mtp | 1.00 | 0.625 | 0.625 | 0.80 | 0.80 | | qwopus3.6-27b-coder-compat-mtp | 1.00 | 0.625 | 0.625 | 0.80 | 0.80 |

นี่ไม่ได้แปลว่า reasoning variant ใช้งานไม่ได้ แต่แปลว่าใน benchmark path นี้ มันยังมีปัญหาในการปล่อย final answer ที่ scorer เอาไปคิดคะแนนได้อย่างเสถียร ในขณะที่ coder สองตัวนิ่งกว่าชัดเจน

ตรงนี้แหละที่ทำให้เรื่อง benchmark method สำคัญมาก ถ้าเราไม่แก้ stack ให้ถูกก่อน เราอาจเล่าเรื่องผิดเกี่ยวกับทั้งสามโมเดลได้ง่ายมาก

บทเรียนแรก: benchmark plumbing สำคัญกว่าที่หลายคนคิด

ผล GSM8K แย่รอบแรกดูเหมือนโมเดลพัง แต่จริง ๆ ไม่ใช่

สิ่งที่เกิดขึ้นคือ

  1. LM Studio ส่ง reasoning แยกจาก final answer content

  2. lm-eval ให้คะแนนจาก final answer text ที่มันมองเห็นใน field ที่คาดไว้เท่านั้น

  3. ตอนใช้ max_tokens=1024 บางรันของ Qwen3.6 ใช้ budget หมดไปก่อนที่ final answer text จะถูกส่งออกมา

  4. scorer เห็น output ว่าง เลยมองว่า invalid แล้วคะแนนพังลงทันที

นี่ไม่ใช่การทดสอบโมเดลอย่างยุติธรรม แต่มันคือการทดสอบว่า adapter กับ token budget ของคุณตั้งถูกหรือยัง

พอเราเปลี่ยนไปใช้ normalized proxy และเพิ่ม GSM8K เป็น max_tokens=4096 ผล benchmark ก็หยุดพังแบบผิดธรรมชาติ

สิ่งที่เราแก้ไปแล้ว

ตอนนี้เราใช้ LM Studio proxy ตัวเล็กวางไว้หน้า lm-eval

หน้าที่ของมันตรงไปตรงมา

วิธีนี้ทำให้เราได้ chat-style evaluation path ที่นิ่งขึ้น โดยไม่ต้องรอ upstream support สำหรับ Qwen3.6 GGUF architecture ชุดนี้ใน runtime อื่น

อีกจุดที่สำคัญมากพอ ๆ กันคือการเพิ่ม output budget ของ GSM8K

สำหรับ Qwen3.6 สาย reasoning ค่า 1024 ไม่พอ 3072 ดีขึ้นมาก และ 4096 คือค่าชุดแรกที่ดูน่าเชื่อถือสม่ำเสมอใน smoke test ของเรา

สิ่งที่เราเชื่อได้ตอนนี้

1. การเทียบ latency, load time และ VRAM

อันนี้ตรงไปตรงมาและมีประโยชน์ทันที

จาก direct LM Studio runs ก่อนหน้า ภาพรวมออกมาประมาณนี้

| Model | Load time | VRAM | Quick reasoning/code latency | | qwen3.6-27b-mtp-pi-reasoning | ~7.6s | ~14.8 GiB | ~9s | | qwopus3.6-27b-coder-mtp | ~7.6s | ~15.6 GiB | ~9 to 10s | | qwopus3.6-27b-coder-compat-mtp | ~8.4s | ~15.6 GiB | ~9 to 10s | | qwen3.6-35b-a3b-mtp | ~9.4s | ~27.0 GiB | ~3s |

สิ่งที่น่าสนใจคือ 35B A3B MoE เร็วกว่ากลุ่ม 27B dense ชัดเจน แม้จะกิน VRAM มากกว่าเยอะ ถ้าเครื่องมี memory budget พอ ตัวนี้ดูเป็นผู้ชนะด้านความเร็วจากการทดสอบช่วงแรก

2. GSM8K ผ่าน proxy ถ้าตั้ง config ถูก

ตอนนี้ path นี้ใช้งานได้จริงแล้ว

กติกาง่าย ๆ คือ

ถ้าทำครบนี้ คะแนนที่ออกมาจะเริ่มใช้เปรียบเทียบได้จริง

3. IFEval ผ่าน proxy path เดียวกัน

IFEval ก็ใช้ normalized chat-completions path เดียวกันได้

เราจะเก็บ task นี้ไว้ใน benchmark stack เพราะมันให้สัญญาณอีกแบบหนึ่งนอกจากโจทย์คณิตศาสตร์ GSM8K บอกว่าโมเดลไปถึงคำตอบที่ถูกไหม ส่วน IFEval บอกว่าโมเดลทำตาม instruction ได้สะอาดแค่ไหน

สองอย่างนี้รวมกันมีประโยชน์กับการเลือก local model มากกว่าการดูแค่กราฟความเร็วอย่างเดียว

สิ่งที่เรายังไม่เชื่อ

อันนี้สำคัญมาก เพราะหลายโพสต์ benchmark ชอบข้ามประเด็นนี้ไป

ตอนนี้เรายัง ไม่เชื่อ task เหล่านี้บน LM Studio backend

ทำไมถึงยังไม่เชื่อ

เพราะ lm-eval ให้คะแนน task พวกนี้ผ่าน loglikelihood ซึ่งแปลว่า backend ต้องส่ง token logprobs ที่ใช้ได้จริงออกมา แต่ OpenAI-compatible completions path ของ LM Studio ตอนนี้ยังไม่ให้ logprobs ที่เชื่อถือได้สำหรับ workflow นี้ ในทางปฏิบัติคือคุณอาจรัน benchmark ได้ แต่ไม่ควรเชื่อ score ที่ออกมา

ดังนั้นเราควรพัฒนา benchmark ให้รวม ARC Easy และ HellaSwag ไหม

ควร แต่ไม่ใช่ด้วยการแกล้งทำเป็นว่า path ปัจจุบันดีพอแล้ว

ทางเลือกที่ถูกมีอยู่ 3 แบบ

  1. รอให้ runtime ส่ง usable logprobs สำหรับ task พวกนี้ได้จริง

  2. ย้าย task เหล่านี้ไปใช้ backend ที่รองรับ trustworthy loglikelihood scoring

  3. ใช้ GSM8K และ IFEval เป็น production benchmark path สำหรับ LM Studio GGUF ไปก่อนในตอนนี้

คำแนะนำของเราตอนนี้คือข้อ 3 เพราะมันตรงไปตรงมาและซื่อสัตย์ที่สุด

ทำไมเรื่องนี้สำคัญกว่าการ benchmark รอบเดียว

เรื่องนี้ใหญ่กว่าการเทสต์ Qwen รอบเดียวมาก

ตอนนี้หลายทีมกำลังจะใช้ local benchmark stacks ที่ยัง verify ไม่ครบ ไปตัดสินใจทั้งเรื่อง content เรื่องการซื้อเครื่อง และเรื่อง deployment ถ้า setup ผิด โมเดลที่ดีอาจดูแย่ โมเดลที่แย่อาจดูพอใช้ได้ และกราฟสวย ๆ อาจมีความหมายน้อยกว่าการเปิด sample log ที่ผิดขึ้นมาดูสักหนึ่งตัวอย่าง

เพราะแบบนั้น เราเลยมอง local benchmarking เป็น 3 ชั้น

Layer 1: ความจริงระดับ infrastructure

Layer 2: ความจริงระดับ benchmark path

Layer 3: ความจริงระดับโมเดล

ถ้าข้ามสองชั้นแรกไป ชั้นสามก็แทบกลายเป็นการแสดงมากกว่าการวัดจริง

benchmark stack ที่เราจะใช้ต่อจากนี้

สำหรับ Qwen3.6 GGUF บน DGX benchmark path ใหม่ของเราจะเป็นแบบนี้

ชุดนี้ทำให้เราได้ benchmark system ที่ใช้งานจริง ทำซ้ำได้ และซื่อสัตย์กับข้อจำกัดของมันในตอนนี้

ข้อสรุปแรก

ข้อสรุปที่มีประโยชน์ที่สุดตอนนี้ยังไม่ใช่ว่า 27B ตัวไหนชนะ

แต่คือ benchmark setup สามารถกำหนด benchmark outcome ได้มากกว่าที่หลายคนคิด

ถ้าคุณรัน local reasoning-heavy model ผ่าน stack ที่ทำ final answer หล่นหาย benchmark ก็ไม่ได้กำลังวัดโมเดล แต่มันวัด plumbing ของคุณอยู่

พอเราแก้ path แล้ว ตัวเลขถึงเริ่มสมเหตุสมผล และนั่นแหละคือจุดที่การเปรียบเทียบโมเดลเริ่มมีความหมาย

ต่อจากนี้

ตอนนี้เราได้ benchmark workflow ที่ใช้ได้จริงสำหรับ Qwen3.6 แบบ local แล้ว แค่นี้ก็เป็น content ที่มีประโยชน์ เพราะมันตอบคำถามที่หลายคนกำลังติดอยู่เงียบ ๆ ว่า

จะ benchmark local GGUF reasoning models ยังไงโดยไม่หลอกตัวเอง

โพสต์ถัดไปควรเป็นโพสต์แบบ scoreboard ล้วน

หลายคนอาจคิดว่าโพสต์แบบนั้นควรออกก่อน แต่สำหรับกรณีนี้มันควรออกทีหลัง

เพราะเรื่องแรกที่ต้องเล่าคือ เราทำให้ benchmark พูดความจริงได้ก่อน

]]>nanobro.eth@newsletter.paragraph.com (nanobro_rit)benchmarkllmlocal-aiqwenlmstudiothai<![CDATA[Qwen3.6 local benchmark on DGX]]>https://blog.nanobro.co/qwen36-local-benchmark-on-dgx MIwow0MfUVzQdGymr9VATue, 23 Jun 2026 15:15:42 GMTWe almost benchmarked Qwen3.6 wrong on DGX

Most local model benchmark posts jump straight to the scoreboard. Ours almost did too, and that would have been a mistake.

We were testing Qwen3.6 GGUF models on our DGX through LM Studio, with lm-evaluation-harness on top. At first the numbers looked ugly. One GSM8K run came back around 10 percent exact match for a 35B-class reasoning model. That kind of score is a red flag, but not always for the model. Sometimes it is the benchmark path telling you your setup is lying.

That turned out to be the real story.

After tracing the full pipeline, we found that the weak score was mostly caused by the evaluation path, not the model itself. LM Studio was returning reasoning separately from final answer content, and our token budget was too small for these reasoning-heavy Qwen3.6 variants. In other words, the model was spending its budget thinking, then getting cut off before it could finish the answer in the field that the scorer actually reads.

Once we fixed the adapter and gave GSM8K enough output budget, the same stack started producing sane results.

This article is the write-up of that process, what we fixed, what we trust now, and what we still do not trust yet.

The setup

We are benchmarking local Qwen3.6 models on DGX with this stack:

The main models in this round are:

Actual results from the first full run

Here is what the completed DGX run gave us on the tasks we trust in this stack right now.

That does not mean the reasoning variant is useless. It does mean that, in this benchmark path, it still struggled to emit stable scoreable final answers, while the two coder variants were much more benchmark-stable.

This is exactly why the benchmark-method story matters. Without fixing the stack first, it would be too easy to tell the wrong story about all three models.

The first lesson: benchmark plumbing matters more than people want to admit

Our first bad GSM8K result looked like a model failure. It was not.

Here is what was happening:

  1. LM Studio returned reasoning separately from final answer content.

  2. lm-eval only scores the final answer text it sees in the expected field.

  3. With max_tokens=1024, some Qwen3.6 reasoning runs used the whole budget before final answer text was emitted.

  4. The scorer then saw empty output, treated it as invalid, and the benchmark cratered.

That is not a fair test of the model. It is a test of whether your adapter and token budget are configured correctly.

Once we switched to a normalized proxy and increased GSM8K to max_tokens=4096, the benchmark stopped producing obviously broken results.

What we fixed

We now use a small LM Studio proxy in front of lm-eval.

Its job is simple:

That gave us a stable interface for chat-style evaluation without waiting on upstream support for these exact Qwen3.6 GGUF architectures in other runtimes.

The second fix was even more important than the first: we raised the output budget for GSM8K.

For these reasoning-heavy Qwen3.6 models, 1024 was not enough. 3072 was much better. 4096 was the first setting that looked consistently trustworthy in our smoke tests.

What we trust now

1. Latency, load time, and VRAM comparisons

These are straightforward and already useful.

From our direct LM Studio runs, the broad picture was clear:

The surprising result is that the 35B A3B MoE reference was much faster than the 27B dense models, despite using far more VRAM. If you have the memory budget, that model is the clear speed winner in our early tests.

2. GSM8K through the proxy, if configured correctly

This now looks good enough to use.

The practical rule is simple:

That gets you from misleading numbers to something you can actually compare.

3. IFEval through the same proxy path

IFEval also works through the normalized chat-completions route.

We are keeping it in the stack because it gives us a useful second signal beyond math-word-problem accuracy. GSM8K tells us whether the model can get to the right answer. IFEval tells us whether it actually follows instructions cleanly.

That combination is already more useful for local model selection than raw speed charts alone.

What we do not trust yet

This is the important part, because a lot of benchmark posts skip it.

We do not currently trust these tasks through the LM Studio backend:

Why not?

Because lm-eval scores these through loglikelihood, which means the backend needs to expose usable token logprobs. LM Studio's current OpenAI-compatible completions path does not give us reliable token logprobs for this workflow. In practice that means you can run the benchmark, but you should not trust the resulting score.

So should we improve the benchmark to include ARC Easy and HellaSwag?

Yes, but not by pretending the current path is good enough.

The right move is one of these:

  1. wait until the runtime exposes usable logprobs for these tasks

  2. switch those specific tasks to a backend that supports trustworthy loglikelihood scoring

  3. keep GSM8K and IFEval as the production benchmark path for LM Studio GGUF runs today

Our recommendation is option 3 for now. It is the honest path.

Why this matters beyond benchmarking

This is bigger than one Qwen run.

A lot of teams are about to make content, buying, and deployment decisions off local benchmark stacks that are only half verified. When the setup is wrong, a strong model can look weak, a weak model can look usable, and a pretty chart can say less than a single well-inspected sample log.

That is why we now treat local benchmarking in three layers:

Layer 1: infrastructure truth

Layer 2: benchmark path truth

Layer 3: model truth

If you skip the first two layers, the third layer is mostly theater.

The benchmark stack we will use from now on

For Qwen3.6 GGUF models on DGX, our benchmark path now looks like this:

This gives us a benchmark system that is practical, repeatable, and honest about what it can and cannot measure today.

Early takeaway

The first useful conclusion is not even about which 27B variant wins.

It is this: benchmark setup can dominate benchmark outcome.

If you run reasoning-heavy local models through a stack that drops the final answer, the benchmark is grading your plumbing, not your model.

Once we fixed the path, the numbers started making sense. That is the only point where model comparison becomes worth discussing.

What comes next

We now have a real benchmark workflow for these local Qwen3.6 runs, and that alone is useful content because it answers a question a lot of people are quietly struggling with:

How do you benchmark local GGUF reasoning models without fooling yourself?

The next post should be the scoreboard post:

That is the piece most people expect first. In our case, it should come second.

The first story was getting the benchmark to tell the truth.

]]>nanobro.eth@newsletter.paragraph.com (nanobro_rit)benchmarkllmlocal-aiqwenlmstudio<![CDATA[Sakana Fugu Japan AI Model]]>https://blog.nanobro.co/sakana-fugu-japan-ai-model yBU2qJDnZwh7kwzzHevrMon, 22 Jun 2026 06:09:34 GMTSakana Fugu โมเดลจากญี่ปุ่น บอกว่าเก่งกว่า Fable และ Mythos ซะอีก หรือว่าญี่ปุ่นกำลังเป็นขาขึ้นๆๆๆ อีกครั้ง

Sakana Fugu โมเดลจากญี่ปุ่น บอกว่าเก่งกว่า Fable และ Mythos ซะอีก หรือว่าญี่ปุ่นกำลังเป็นขาขึ้นๆๆๆ อีกครั้ง

Sakana Fugu โมเดลจากญี่ปุ่น บอกว่าเก่งกว่า Fable และ Mythos ซะอีก หรือว่าญี่ปุ่นกำลังเป็นขาขึ้นๆๆๆ อีกครั้ง

ไปซุ่มมากจากไหนพรี้

มี model เดียว สั่งไป แล้วมันจะกระรายงานที่เหมาะสมให้ model ย่อยเอง subscription เริ่มต้น $20

🏢 รู้จัก Sakana AI บริษัทเบื้องหลัง Fugu

Sakana AI เป็น startup AI จากญี่ปุ่น ก่อตั้งเมื่อปี 2023 โดย Kenji Kawaguchi (CEO/CTO) และ Hiroki Sakai ตั้งสำนักงานที่โตเกียว

จุดเด่นของ Sakana AI คือ:

🇯🇵 ญี่ปุ่นกำลังกลับมา?

ก่อนหน้านี้ญี่ปุ่นดูเหมือนจะตามหลัง US และ China ในด้าน AI อย่างชัดเจน แต่ช่วง 2-3 ปีที่ผ่านมาเห็นสัญญาณที่น่าสนใจ:

อาจเป็นสัญญาณว่าญี่ปุ่นกำลังฟื้นคืนชีพในวงการเทคโนโลยีอีกครั้ง เหมือนช่วงยุค 90s ที่เคยเป็นผู้นำด้าน electronics และ gaming

]]>nanobro.eth@newsletter.paragraph.com (nanobro_rit)ainanobro<![CDATA[hermes update]]>https://blog.nanobro.co/hermes-update hkVKUoUcE8poNJFijEjKSat, 20 Jun 2026 03:46:10 GMTคุณ: อันนี้นาาสนใจ ดี hermes update ให้ความจำดีขึ้น

คุณ: อันนี้นาาสนใจ ดี hermes update ให้ความจำดีขึ้น

คุณ: อันนี้นาาสนใจ ดี hermes update ให้ความจำดีขึ้น

Hermes Agent อัปเดตใหญ่: ระบบ Memory จัดการแบบ Batch Operations ลดจำนวน Tool Call ลง 52%

Teknium (เทคนิอัม) Co-founder และ Lead Engineer ของ Nous Research ประกาศอัปเดตสำคัญสำหรับ Hermes Agent — เครื่องมือจัดการหน่วยความจำ (Memory Management) ที่ใช้บันทึก แก้ไข และลบข้อมูลถาวรของเอเจนต์ ได้รับการขยายให้รองรับ Batch Operations หรือการทำงานหลายคำสั่งพร้อมกันในครั้งเดียว

ปัญหาเดิม: ระบบ Single-Op ไม่พอแล้ว

ก่อนหน้านี้ Hermes Agent ใช้รูปแบบ single-operation tool ซึ่งต้องเรียกทีละคำสั่ง — เพิ่ม 1 ครั้ง, ลบ 1 ครั้ง, แก้ไข 1 ครั้ง เมื่อหน่วยความจำใกล้เต็ม (เช่น 2,087 จาก 2,200 ตัวอักษร) การเพิ่มข้อมูลใหม่จะล้มเหลวเพราะ overflow และเอเจนต์ต้องลบข้อมูลเก่าออกก่อน แล้วค่อยเรียกเพิ่มใหม่ข้ามรอบการสนทนา ซึ่งเปลือง context window และจำนวน tool call อย่างมาก

ทางแก้: Batch Operations แบบ Atomic

อัปเดตนี้เปลี่ยนให้ Hermes Agent สามารถรวมหลายคำสั่งไว้ใน operations array เดียว เช่น ลบ 2 รายการ + เพิ่ม 1 รายการ ใน call เดียวกัน โดยระบบจะตรวจสอบขนาดสุดท้ายหลังจากประมวลผลทั้งหมดเสร็จ — ไม่ใช่เช็คทีละขั้นตอน ทำให้สามารถเคลียร์พื้นที่และเพิ่มข้อมูลใหม่ได้ในครั้งเดียว โดยไม่ล้มเหลวระหว่างทาง

ผลลัพธ์ที่วัดได้:

วิธีอัปเดต:

รันคำสั่ง hermes update ใน CLI หรืออัปเดตผ่าน GUI เพื่อเริ่มใช้งานฟีเจอร์นี้ทันที

Source: @Teknium (Nous Research) via X/Twitter

]]>nanobro.eth@newsletter.paragraph.com (nanobro_rit)aihermesagentnanobro<![CDATA[Hermes Profile Distributions]]>https://blog.nanobro.co/hermes-profile-distributions Oy8Rdusq9jC9ykUDQtkGFri, 19 Jun 2026 15:34:15 GMTProfile Distributions: แชร์ Agent ทั้งตัว

Profile Distribution คือการแพ็กเกจ Hermes agent ทั้งหมด — บุคลิกภาพ, skills, cron jobs, การเชื่อมต่อ MCP, config — ลงใน git repository คนที่มีสิทธิ์เข้าถึง repo ก็สามารถติดตั้ง agent ตัวเต็มได้ด้วยคำสั่งเดียว อัปเดตได้ทันที โดยที่ memories, sessions และ API keys ของแต่ละคนยังคงแยกกันอยู่

ถ้า profile คือ agent ที่ทำงานบนเครื่อง local แล้ว distribution ก็คือ agent นั้นที่ถูกทำให้แชร์ได้ง่าย

ความหมายของ Distribution

ก่อนมี distribution การแชร์ Hermes agent หมายถึงการส่งให้คนอื่น:

  1. SOUL.md ของคุณ

  2. รายการ skills ที่ต้องติดตั้ง

  3. config.yaml (ตัด secrets ออก)

  4. คำอธิบายว่าต่อ MCP servers อะไรไว้บ้าง

  5. cron jobs ที่เคยตั้งไว้

  6. คำแนะนำเรื่อง env vars ที่ต้องใช้

…แล้วหวังว่าเขาจะประกอบถูก ทุกครั้งที่อัปเดตเวอร์ชันหรือแก้ bug ก็ต้องส่งใหม่ซ้ำเดิม

แต่ด้วย distribution สิ่งทั้งหมดนี้รวมอยู่ใน git repo เดียว:

my-research-agent/
├── distribution.yaml    # manifest: ชื่อ, เวอร์ชัน, ข้อกำหนด env vars
├── SOUL.md              # บุคลิกภาพ / system prompt ของ agent
├── config.yaml          # model, temperature, reasoning, tool defaults
├── skills/              # bundled skills ที่มากับ agent
├── cron/                # งานที่ agent จะรันตามกำหนด
└── mcp.json             # MCP servers ที่ agent เชื่อมต่อ

ผู้รับแค่รัน:

hermes profile install github.com/you/my-research-agent --alias

พวกเขาก็ได้ agent ตัวเต็มทันที กรอก API keys ของตัวเอง (.env.EXAMPLE → .env) แล้วเริ่มใช้ my-research-agent chat หรือติดต่อผ่าน Telegram / Discord / Slack / gateway platform ใดๆ ก็ได้ เมื่อคุณ push เวอร์ชันใหม่ ผู้ใช้ก็รัน hermes profile update my-research-agent เพื่อดึงการเปลี่ยนแปลง — memories และ sessions ของพวกเขาไม่โดนแตะ

ทำไมต้องใช้ git?

เราเคยพิจารณา tarballs, HTTP archives, รูปแบบเฉพาะของตัวเอง แต่ไม่มีอะไรดีกว่า git:

ข้อแลกเปลี่ยน: ผู้ใช้ต้องมี git ติดตั้ง แต่บนเครื่องที่รัน Hermes ในปี 2026 นั่นเป็นเรื่องปกติอยู่แล้ว

เมื่อไหร่ควรใช้ Distribution?

เหมาะสำหรับ:

ไม่เหมาะสำหรับ:

Lifecycle: ผู้สร้าง → ผู้ติดตั้ง → อัปเดต

สำหรับผู้สร้าง: การเผยแพร่ Distribution

ขั้นตอนที่ 1 — เริ่มจาก profile ที่ทำงานได้แล้ว

hermes profile create research-bot
research-bot setup                    # ตั้งค่า model, API keys
# แก้ไข ~/.hermes/profiles/research-bot/SOUL.md
# ติดตั้ง skills, ต่อ MCP servers, ตั้ง cron jobs ฯลฯ
research-bot chat                     # ทดสอบจนกว่าจะรู้สึกดี

ขั้นตอนที่ 2 — เพิ่ม distribution.yaml

สร้าง ~/.hermes/profiles/research-bot/distribution.yaml:

name: research-bot
version: 1.0.0
description: "Autonomous research assistant with arXiv and web tools"
hermes_requires: ">=0.12.0"
author: "Your Name"
license: "MIT"

env_requires:
  - name: OPENAI_API_KEY
    description: "OpenAI API key (for model access)"
    required: true
  - name: SERPAPI_KEY
    description: "SerpAPI key for web search"
    required: false
    default: ""

นั่นคือ manifest ทั้งหมด ทุก field นอกจากชื่อมีค่า default ที่สมเหตุสมผลอยู่แล้ว

ขั้นตอนที่ 3 — Push ขึ้น git repo

cd ~/.hermes/profiles/research-bot
git init
git add .
git commit -m "v1.0.0"
git remote add origin git@github.com:you/research-bot.git
git tag v1.0.0
git push -u origin main --tags

repo นี้คือ distribution แล้ว คนที่มีสิทธิ์เข้าถึงก็สามารถ install ได้

ขั้นตอนที่ 4 — Tag เวอร์ชันที่เสถียร

ทุกครั้งที่ agent ถึงจุดที่เสถียร ให้ bump version และ tag:

# แก้ไข distribution.yaml: version: 1.1.0
git add distribution.yaml SOUL.md skills/
git commit -m "v1.1.0: tighter research SOUL, add arxiv skill"
git tag v1.1.0
git push --tags

ผู้รับที่รัน hermes profile update research-bot จะดึงเวอร์ชันล่าสุดมา

สำหรับผู้ติดตั้ง: การใช้ Distribution

Install:

hermes profile install github.com/you/research-bot --alias

สิ่งที่เกิดขึ้น:

  1. Clone repo ลง temporary directory

  2. อ่าน distribution.yaml แสดง manifest (ชื่อ, เวอร์ชัน, คำอธิบาย, ผู้สร้าง, env vars ที่จำเป็น)

  3. ตรวจสอบแต่ละ env var กับ shell environment และ .env ที่มีอยู่ บอกว่า ✓ set หรือต้องตั้งค่า

  4. ขอ confirmation (ใช้ -y / --yes เพื่อข้าม)

  5. คัดลอกไฟล์ที่ distribution เป็นเจ้าของลง ~/.hermes/profiles/research-bot/

  6. เขียน .env.EXAMPLE พร้อม key ที่จำเป็นแบบ comment — copy ไป .env แล้วกรอกค่า

Source types: git URL ใดๆ ก็ใช้ได้:

# GitHub shorthand
hermes profile install github.com/you/research-bot

# Full HTTPS
hermes profile install https://github.com/you/research-bot.git

# SSH
hermes profile install git@github.com:you/research-bot.git

# Self-hosted, GitLab, Gitea, Forgejo — git host ใดๆ ก็ได้
hermes profile install https://git.example.com/team/research-bot.git

# Private repo ใช้ git auth ที่ตั้งค่าไว้แล้ว
hermes profile install git@github.com:your-org/internal-bot.git

# Local directory ระหว่างพัฒนา (ไม่ต้อง push git)
hermes profile install ~/my-profile-in-progress/

Override ชื่อ profile:

ผู้ใช้สองคนต้องการ distribution เดียวกันแต่ชื่อต่างกัน:

# Alice
hermes profile install github.com/acme/support-bot --name support-us --alias
# Bob (distribution เดียวกัน แต่ชื่อ local ต่างกัน)
hermes profile install github.com/acme/support-bot --name support-eu --alias

กรอก env vars:

หลัง install profile จะมี .env.EXAMPLE:

cp ~/.hermes/profiles/research-bot/.env.EXAMPLE ~/.hermes/profiles/research-bot/.env
# แก้ไข .env ใส่ API keys จริงของคุณ

env var ที่จำเป็นซึ่งมีอยู่แล้วใน shell environment (เช่น OPENAI_API_KEY ใน ~/.zshrc) จะถูกทำเครื่องหมาย ✓ set ตอน install — ไม่ต้อง duplicate ใน .env

ตรวจสอบสิ่งที่ติดตั้ง:

hermes profile info research-bot

แสดงข้อมูล: distribution, เวอร์ชัน, คำอธิบาย, ผู้สร้าง, requirements, source URL, วันที่ติดตั้ง, และ env vars ที่จำเป็น

hermes profile list ยังแสดงคอลัมน์ Distribution ให้เห็นได้ทันทีว่า profile ไหนมาจาก repo กับไหนสร้างเอง

อัปเดต:

hermes profile update research-bot

สิ่งที่เกิดขึ้น:

  1. Re-clone repo จาก source URL ที่บันทึกไว้

  2. แทนที่ไฟล์ distribution-owned (SOUL, skills, cron, mcp.json)

  3. รักษา config.yaml ไว้ — คุณอาจ tune model, temperature หรือ setting อื่นๆ ใช้ --force-config เพื่อ overwrite

  4. ไม่แตะ user data เลย: memories, sessions, auth, .env, logs, state

ลบ:

hermes profile delete research-bot

ก่อนลบจะแสดงข้อมูล distribution ให้คุณรู้ที่มาที่ไป ก่อนยืนยันการลบ

Use Cases และ Patterns

Personal: ซิงค์ agent เดียวกันข้ามเครื่อง

สร้าง research assistant บนแล็ปท็อป อยากให้ agent เดียวกันบนเวิร์กสเตชัน:

# แล็ปท็อป
cd ~/.hermes/profiles/research-bot
git init && git add . && git commit -m "initial"
git remote add origin git@github.com:you/research-bot.git
git push -u origin main

# เวิร์กสเตชัน
hermes profile install github.com/you/research-bot --alias
# กรอก .env จบ

ทุก iteration บนแล็ปท็อป (git commit && push) จะ pull ไปเวิร์กสเตชันด้วย hermes profile update Memories แต่ละเครื่องแยกกัน — แล็ปท็อปจำการสนทนาของตัวเอง เวิร์กสเตชันก็เช่นกัน ไม่ชนกัน

Team: ส่ง agent ภายในทีมที่ผ่านการ review

ทีม engineering ต้องการ PR-review bot ที่มี SOUL เฉพาะ, skills เฉพาะ และ cron ที่รันทุก PR ผ่าน bot:

# Engineering lead
cd ~/.hermes/profiles/pr-reviewer
git init && git add . && git commit -m "v1.0 PR reviewer"
git tag v1.0.0
git push -u origin main --tags

# วิศวกรแต่ละคน
hermes profile install git@github.com:your-org/pr-reviewer.git --alias
pr-reviewer chat

เมื่อ lead ส่ง v1.1 (SOUL ดีขึ้น, skill ใหม่) วิศวกรรัน hermes profile update pr-reviewer ทุกคนก็ได้เวอร์ชันใหม่ภายในนาที

Community: เผยแพร่ agent สาธารณะ

สร้างอะไรที่แปลกใหม่ — "Polymarket trader" หรือ "academic paper summarizer" อยากแชร์ให้ทุกคนใช้:

# คุณ
cd ~/.hermes/profiles/polymarket-trader
git init && git add . && git commit -m "v1.0"
git tag v1.0.0
git remote add origin https://github.com/you/hermes-polymarket-trader.git
git push -u origin main --tags

# ทุกคน
hermes profile install github.com/you/hermes-polymarket-trader --alias

ทวีตคำสั่ง install คนที่ลองส่ง issue และ PR ให้คุณ ถ้าใครอยาก customize ก็ fork — workflow git แบบเดิมที่ทุกคนคุ้นเคย

Product: ส่ง agent เป็น product

สร้าง Hermes-on-top — compliance-monitoring harness, customer-support stack, research platform เฉพาะโดเมน อยาก distribute เป็น product:

# distribution.yaml
name: telemetry-harness
version: 2.3.1
description: "Compliance telemetry harness"
hermes_requires: ">=0.13.0"
author: "Acme Compliance Inc."
license: "Commercial"

env_requires:
  - name: ACME_API_KEY
    description: "Your Acme Compliance license key"
    required: true

ลูกค้า install ด้วยคำสั่งเดียว อัปเดต rollout ทันทีที่ tag release ใหม่ — compliance data (memories/, sessions/) ไม่เคยออกจากเครื่องพวกเขา

Ephemeral: สคริปต์ชั่วคราวบน shared infra

คุณเป็น ops lead ต้องการ agent ชั่วคราวที่วินิจฉัย production incident — SOUL พร้อม tools และ MCP connections ที่ถูกต้อง — รันบนแล็ปท็อปของ on-call engineers 3 คนในสัปดาห์หน้า:

# คุณ
git push -u origin main

# On-call แต่ละคน
hermes profile install git@github.com:your-org/incident-2026-q2.git --alias

# Incident แก้ไขแล้ว — ลบทิ้ง
hermes profile delete incident-2026-q2

cycle install-delete ถูกพอที่จะเป็น disposable ได้

Recipes

Pin เวอร์ชันเฉพาะ: Git ref pinning (#v1.2.0) ยังไม่มาในเวอร์ชันแรก ตอนนี้อัปเดตตาม default branch ตรวจสอบเวอร์ชันที่ติดตั้งด้วย hermes profile info <name>

ตรวจสอบเวอร์ชันปัจจุบัน vs ล่าสุด:

# เวอร์ชันที่ติดตั้งของคุณ
hermes profile info research-bot | grep Version

# Latest upstream (โดยไม่ต้อง install)
git ls-remote --tags https://github.com/you/research-bot | tail -5

รักษา local config customization ผ่านการอัปเดต:

ค่า default ของ update รักษา config.yaml ไว้แล้ว เพื่อความปลอดภัย ให้เขียน tweak ของคุณลงไฟล์ที่ distribution ไม่เป็นเจ้าของ:

# ~/.hermes/profiles/research-bot/local/my-overrides.yaml

Force clean re-install:

# ลบและ install ใหม่ทั้งหมด (เสีย memories/sessions ด้วย)
hermes profile delete research-bot --yes
hermes profile install github.com/you/research-bot --alias

# อัปเดตเป็น current main แต่ reset config.yaml เป็น default ของ distribution
hermes profile update research-bot --force-config --yes

Fork และ customize:

# Fork repo บน GitHub แล้ว install fork ของคุณ
hermes profile install github.com/yourname/forked-research-bot --alias

# Iterate ใน ~/.hermes/profiles/forked-research-bot/
# แก้ SOUL.md, commit, push ไปที่ fork ของคุณ
# อัปเดตจาก upstream: pull เข้า fork ตามปกติ

ทดสอบ distribution ก่อน push:

# Install จาก local directory (ไม่ต้อง push git)
hermes profile install ~/.hermes/profiles/research-bot --name research-bot-test --alias

# Tweak, delete, re-install จนกว่าจะถูกต้อง
hermes profile delete research-bot-test --yes
hermes profile install ~/.hermes/profiles/research-bot --name research-bot-test

สิ่งที่ NOT อยู่ใน distribution (ตลอดกาล)

Installer จะยกเว้น path เหล่านี้เสมอ แม้ผู้สร้างจะเผลอใส่เข้ามา ไม่มี config option ให้ override — safety guard นี้เป็น regression-tested invariant:

เมื่อคุณ clone distribution path เหล่านี้ไม่มีอยู่จริง เมื่อคุณ update พวกมันยังคงอยู่ ถ้าคุณ install distribution เดียวกันบน 5 เครื่อง คุณจะมีข้อมูลแยกกัน 5 ชุด — หนึ่งในแต่ละเครื่อง

Security และ Trust

Profile distributions ยังไม่ได้ sign โดย default คุณต้อง trust:

cron jobs จาก distribution ไม่ถูก schedule อัตโนมัติ — installer จะพิมพ์ hermes -p <name> cron list แล้วคุณ enable เอง SOUL.md และ skills จะ active ทันทีที่คุณเริ่ม chat กับ profile ดังนั้นควรอ่านก่อนรันครั้งแรกถ้าติดตั้งจากคนที่ไม่รู้จัก

เปรียบเทียบแบบหยาบ: การ install distribution เหมือนการติดตั้ง browser extension หรือ VS Code extension — low friction, high power, trust the source สำหรับ internal company distributions ใช้ private repo และ git auth ปกติ ไม่ต้องตั้งค่าอะไรใหม่

เวอร์ชันในอนาคตอาจเพิ่ม signing, lockfile (.distribution-lock.yaml) พร้อม commit SHA ที่ resolve แล้ว และ --dry-run flag ที่แสดง diff ก่อน apply update แต่สิ่งเหล่านี้ยังไม่ได้ release ในตอนนี้

อ้างอิง: Profile Distributions — Hermes Agent Documentation

]]>nanobro.eth@newsletter.paragraph.com (nanobro_rit)hermesagentdistributiongitmulti-agent<![CDATA[GLM-52 Runs on RTX 4090]]>https://blog.nanobro.co/glm-52-runs-on-rtx-4090 8rHd6wXbw5X0JpXYLz4vThu, 18 Jun 2026 18:20:58 GMTรันได้ด้วย 4090 x 24 อัน ประมาณ 1.5 ล้านบาท

ได้พลังใกล้เคียง Opus 4.6(?)

GLM-5.2 โมเดล 753B พารามิเตอร์ รันบน RTX 4090 ได้แล้ว — frontier model ออกจากการ์ด数据中心 สู่ผู้บริโภค

เมื่อสัปดาห์ที่แล้ว @totheagi (Ning) ประกาศความสำเร็จที่น่าตื่นเต้นมากในวงการ AI — เขาเป็นคนแรกที่สามารถรัน GLM-5.2 แบบเต็มๆ บน NVIDIA RTX 4090 การ์ดคอนซูมเมอร์ได้สำเร็จ

GLM-5.2 คือโมเดล open-weights ขนาด 753B พารามิเตอร์ ที่พัฒนาโดย Zai-org (ทีมเดิมที่เกี่ยวข้องกับ DeepSeek) และถูกจัดว่าเป็น SOTA (State of the Art) ในกลุ่ม open-weight models ปัจจุบัน

แต่ปัญหาคือ — โมเดลนี้ officially รองรับเฉพาะ Datacenter GPU เท่านั้น ได้แก่ H100, H200 และ B200 เพราะ sparse-attention kernel stack ของมันถูก lock ไว้ที่ sm_90 / sm_100 architecture โดยไม่มี fallback สำหรับการ์ดคอนซูมเมอร์อย่าง RTX 4090 (sm_89)

แล้วเขาทำยังไง?

ทีมของ renning22 ได้เขียน ada_dsa.py — ไฟล์ที่ monkeypatch kernel ทั้งหมดของ GLM-5.2 ให้ทำงานบน Ada generation (RTX 4090) ได้ โดยแทนที่จะใช้ WGMMA tilelang path ที่เฉพาะ Hopper/Blackwell มี เขาใช้ Triton + non-WGMMA tilelang path แทน

kernel ที่ถูก port กลับไปมี 3 ส่วนหลัก:

  1. Lightning-indexer GEMM — matrix multiplication สำหรับ sparse attention

  2. Top-k + page-mapping transforms — การเลือกและจัดหน้าข้อมูลใน KV cache

  3. MLA sparse decode — sparse decoding mechanism ของโมเดล

ทุก kernel ถูก validate กับ reference แล้วได้ความแม่นยำ ~1e-6 (cosine similarity 0.999999 บน real tensors ของโมเดลจริง)

สเปกที่ต้องใช้

เนื่องจาก FP8 weights ของ GLM-5.2 มีขนาดประมาณ 753 GB การรันแบบ full model จึงต้องการการ์ดจำนวนมาก:

• RTX 4090 48GB: 24 การ์ด (3 โหนด × 8 การ์ด) — TP=8 × PP=3 → ทดสอบแล้ว ทำงานได้จริง • RTX 4090 24GB: ประมาณ 40-48 การ์ด (ประมาณการ) • RTX 5090 32GB: ประมาณ 32 การ์ด (ประมาณการ)

ความเร็วที่ได้ประมาณ 10 tokens/sec ต่อ single stream (ใช้ CUDA-graph) ซึ่งถือว่า interactive speed สำหรับโมเดลขนาด 753B บนการ์ดคอนซูมเมอร์ ถ้าไม่ใช้ CUDA-graph จะได้ประมาณ 2.5 tokens/sec เท่านั้น

ทำไมเรื่องนี้สำคัญ?

GLM-5.2 ไม่ใช่โมเดลเล็กๆ — มันคือ frontier model ที่ปกติเฉพาะห้องแล็บและบริษัทใหญ่ๆ ที่มี H100 cluster ถึงจะเข้าถึงได้ การที่ใครสักคนสามารถ port kernel stack ทั้งหมดไปรันบน RTX 4090 ได้สำเร็จ แสดงว่า:

  1. Frontier open models กำลัง democratize เข้าถึงได้ง่ายขึ้น

  2. Sparse attention architecture ทำให้โมเดลขนาดใหญ่ทำงานบน hardware ที่จำกัดได้ดีขึ้น

  3. Port นี้ model-agnostic — สามารถนำไปใช้กับ DSA models อื่นๆ ได้ด้วย เช่น DeepSeek-V3.2-style

วิธีติดตั้งและรัน

โปรเจกต์มี one-call installer (apply_sglang_patches.py) ที่ patch sglang ให้รองรับ ada_dsa kernels โดยอัตโนมัติ ต้องใช้ sglang build ที่มี nsa / tilelang DSA backend และต้องตั้ง --disable-shared-experts-fusion บน Ada (เป็น MoE fix จำเป็น)

License ของโปรเจกต์เป็น Apache-2.0 — เปิดให้ใช้งานเชิงพาณิชย์ได้เต็มที่

ลิงก์ต้นฉบับ: https://x.com/totheagi/status/2067589730104213740 GitHub: https://github.com/renning22/glm-5.2-4090

]]>nanobro.eth@newsletter.paragraph.com (nanobro_rit)ainanobrodeepseekglm5.2gpu<![CDATA[DGX Spark Comparison 2026]]>https://blog.nanobro.co/dgx-spark-comparison-2026 ljIbynbWSXeVREoDOWaTWed, 17 Jun 2026 19:38:21 GMTเปรียบเทียบแบรนด์ DGX Spark แต่ละค่าย (อัปเดตปี 2026)

ทุกแบรนด์ในสาย DGX Spark ใช้ชิปเดียวกันคือ NVIDIA GB10 Grace Blackwell Superchip (128GB Unified Memory) จึงมีประสิทธิภาพหลักคล้ายกันมาก ความแตกต่างอยู่ที่ดีไซน์ตัวเครื่อง, การระบายความร้อน, ราคา, การรองรับ, และคุณสมบัติเล็กน้อย

1. NVIDIA DGX Spark (Founders Edition)

| หัวข้อ | รายละเอียด | | ดีไซน์ | ทอง-แชมเปญ พรีเมี่ยม ด้านข้างมีลาย Texture สวยงาม (Cool Factor สูง) | | ราคา | แพงที่สุด (~$3,999–$4,699) มักมาพร้อม SSD 4TB | | จุดเด่น | ดีไซน์สวยที่สุดในกลุ่ม, รู้สึกเป็น "ของแท้" จาก NVIDIA | | จุดด้อย | ไม่มีไฟ LED แสดงสถานะเครื่อง, PSU 240W, การระบายความร้อนปานกลาง (บางรีวิวบอก throttling ง่ายกว่า Dell/ASUS) | | เหมาะกับใคร | คนที่ชอบดีไซน์สวย พรีเมี่ยม อยากได้ของ NVIDIA โดยตรง |

2. Dell Pro Max with GB10 (Dell DGX Spark)

| หัวข้อ | รายละเอียด | | ดีไซน์ | ดำด้าน ดู Professional มีช่องระบายลมแบบ Honeycomb | | ราคา | ค่อนข้างแพง (แพงกว่า NVIDIA นิดหน่อย) | | จุดเด่น | แก้ปัญหาของ NVIDIA ได้หลายอย่าง, มีไฟ LED แสดงสถานะ, PSU 280W (มี headroom มากกว่า), การระบายความร้อนดีกว่า → เสียงเงียบกว่า + ทนร้อนได้ดีกว่า → ประสิทธิภาพยั่งยืนกว่า, รองรับองค์กรดี มี Warranty และ Support ดี | | จุดด้อย | ดีไซน์ดูธรรมดากว่า NVIDIA | | เหมาะกับใคร | องค์กร,ทีมงาน, คนที่ต้องการเครื่องใช้งานจริงจังระยะยาว |

3. ASUS Ascent GX10

| หัวข้อ | รายละเอียด | | ดีไซน์ | ทันสมัย สวย ด้านบนมีครีบระบายลมแนวตั้ง (Modern Look) | | ราคา | มักถูกกว่า NVIDIA (บางรุ่นเริ่มต้น ~$2,999–$3,500) มักมีตัวเลือก SSD 1TB | | จุดเด่น | ราคาดีที่สุดในกลุ่ม, คุณภาพการประกอบดี, การระบายความร้อนดี (คล้าย Dell) | | จุดด้อย | SSD น้อยกว่า (1TB ในรุ่นถูก), ซอฟต์แวร์มีปรับแต่งเล็กน้อยจาก ASUS | | เหมาะกับใคร | คนงบจำกัด อยากได้เครื่องดีไซน์สวยในราคาที่ถูกกว่า |

สรุปเปรียบเทียบเร็ว ๆ

| แบรนด์ | ดีไซน์ | ราคา | การระบายความร้อน | คุณสมบัติเด่นพิเศษ | เหมาะกับ | | NVIDIA | พรีเมี่ยมทอง | แพงที่สุด | ปานกลาง | Cool Factor สูง | คนชอบสวย | | Dell | Professional ดำ | แพง | ดีที่สุด | แก้ปัญหา LED + PSU + ระบาย | องค์กร / ใช้งานจริง | | ASUS | ทันสมัย | ถูกที่สุด | ดี | คุ้มค่า | งบจำกัด | | HP/Lenovo | Professional | ปานกลาง-แพง | ดี | รองรับองค์กร + Warranty ดี | องค์กร |

สรุปความเห็นจากผู้ใช้/รีวิว

🎯 สรุปสั้น ๆ: เลือกตามความต้องการ

ถ้าชอบสวย          → NVIDIA
ถ้าต้องการใช้งานจริง + ระบายความร้อนดี → Dell
ถ้าอยากประหยัด     → ASUS

อัปเดตข้อมูล: ปี 2026

]]>nanobro.eth@newsletter.paragraph.com (nanobro_rit)aihardwarenvidiadgxgb10<![CDATA[Headroom May Harm Your Agent More Than Help]]>https://blog.nanobro.co/headroom-may-harm-your-agent-more-than-help-1 sIiFWgqXlrjKxzYY6ywVWed, 17 Jun 2026 18:07:55 GMT# Headroom อาจทำร้าย Agent ของคุณมากกว่าช่วย — บทวิเคราะห์จากประสบการณ์จริงของ Hermes Agent

\# Headroom อาจทำร้าย Agent ของคุณมากกว่าช่วย — บทวิเคราะห์จากประสบการณ์จริงของ Hermes Agent

Headroom อาจทำร้าย Agent ของคุณมากกว่าช่วย — บทวิเคราะห์จากประสบการณ์จริงของ Hermes Agent

เมื่อไม่นานมานี้ Teknium ผู้พัฒนา Hermes Agent ได้นำเอเจนต์ของตนเองมาทดสอบ Headroom โครงการ open-source ยอดนิยมสำหรับการบีบอัดบริบท (context compression) ที่กำลังเป็นกระแสในวงการ AI

ผลการทดสอบที่สำคัญ

ผลลัพธ์โดยรวม

Headroom สร้างผลกระทบเชิงลบ ต่อเวิร์กโฟลว์ของ Hermes Agent เกือบทั้งหมด โดยเฉพาะฟีเจอร์หลักที่โฆษณาไว้ เช่น การ remove-and-retrieve (CCR) และการบีบอัดข้อมูลแบบ in-flight

ปัญหาที่พบ:

จุดเด่นเดียวที่คุ้มค่า

อย่างไรก็ตาม มี หนึ่งส่วนที่ให้ผลลัพธ์ดีมาก คือ

การบีบอัดผลลัพธ์ของ Search File Tool (ข้อมูลที่ได้ในรูปแบบ JSON)

Hermes Agent กำลังนำเทคนิคนี้ไปพัฒนาและฝังเข้าไปในระบบโดยตรง เพื่อให้ผู้ใช้ได้รับประโยชน์โดยไม่ต้องติดตั้ง Headroom ทั้งก้อน

สรุปสำหรับผู้พัฒนาและผู้ใช้ Agent

Headroom อาจเหมาะกับบางโปรเจกต์ แต่สำหรับ Hermes Agent แล้ว การเลือกใช้เฉพาะส่วนที่ได้ผลจริง ๆ กลับเป็นวิธีที่ชาญฉลาดกว่า

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

เครื่องมือที่กำลังฮิตและอ้างตัวเลขลด token มาก ๆ ไม่ได้หมายความว่าจะเหมาะกับทุก Agent เสมอไป การทดสอบจริงด้วยตัวเอง (หรือให้ Agent ช่วยทดสอบ) ยังคงเป็นวิธีที่ดีที่สุด

อ่านฉบับเต็ม: https://blog.nanobro.co/w1BKOTshd9sueI24HKV7

]]>nanobro.eth@newsletter.paragraph.com (nanobro_rit)aiagenthermesteknium<![CDATA[Headroom May Harm Your Agent More Than Help]]>https://blog.nanobro.co/headroom-may-harm-your-agent-more-than-help w1BKOTshd9sueI24HKV7Wed, 17 Jun 2026 17:54:31 GMTHeadroom อาจทำร้าย Agent ของคุณมากกว่าช่วย — บทวิเคราะห์จากประสบการณ์จริงของ Hermes Agent

ผลการทดสอบที่สำคัญ

ผลลัพธ์โดยรวม

ปัญหาที่พบ:

จุดเด่นเดียวที่คุ้มค่า

อย่างไรก็ตาม มี หนึ่งส่วนที่ให้ผลลัพธ์ดีมาก คือ

การบีบอัดผลลัพธ์ของ Search File Tool (ข้อมูลที่ได้ในรูปแบบ JSON)

Hermes Agent กำลังนำเทคนิคนี้ไปพัฒนาและฝังเข้าไปในระบบโดยตรง เพื่อให้ผู้ใช้ได้รับประโยชน์โดยไม่ต้องติดตั้ง Headroom ทั้งก้อน

สรุปสำหรับผู้พัฒนาและผู้ใช้ Agent

Headroom อาจเหมาะกับบางโปรเจกต์ แต่สำหรับ Hermes Agent แล้ว การเลือกใช้เฉพาะส่วนที่ได้ผลจริง ๆ กลับเป็นวิธีที่ชาญฉลาดกว่า

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

คุณกำลังใช้ Hermes Agent อยู่หรือไม่? หรือมีคำถามเกี่ยวกับ Headroom เพิ่มเติมไหมครับ?

]]>nanobro.eth@newsletter.paragraph.com (nanobro_rit)aiagenthermestekniumaiagentsllm<![CDATA[Hermes Agent Stripe Payments]]>https://blog.nanobro.co/hermes-agent-stripe-payments kQrJsSdrp4nEaL316OZfTue, 16 Jun 2026 05:44:22 GMTAI Agent เริ่มมี “กระเป๋าตังค์” ของตัวเองแล้ว

AI Agent เริ่มมี “กระเป๋าตังค์” ของตัวเองแล้ว

AI Agent เริ่มมี “กระเป๋าตังค์” ของตัวเองแล้ว

Nous Research ประกาศว่า Hermes Agent จับมือกับ Stripe และตอนนี้รองรับชุดสกิลด้าน payments แบบเต็มรูปแบบแล้ว

ความหมายคือ AI agent ไม่ได้แค่ตอบแชตหรือเขียนโค้ด แต่เริ่มทำงานที่ต้อง “จ่ายเงิน” ได้จริง เช่น

  1. ซื้อของบนเว็บแทนเรา

  2. เรียกใช้ API แบบ pay-per-call

  3. เปิดหรือ provision SaaS ของตัวเองได้

ทั้งหมดนี้มาพร้อม safety layer เช่น จำกัดวงเงินได้, ตั้ง human approval gate ได้, credential หลักไม่หลุดเข้า transcript และ credential ชั่วคราวถูกลบทิ้งหลังใช้งาน

สกิลที่เปิดตัวมี 3 ตัวหลัก:

ติดตั้งผ่าน:

hermes skills install official/payments/<skill>

นี่เป็นก้าวสำคัญของ agentic AI เพราะ “การลงมือทำ” หลายอย่างในโลกจริงมักติดขั้นตอน payment เสมอ พอ agent มี payment rails ที่ควบคุมได้ ปลอดภัย และตรวจสอบได้ ขอบเขตของงานที่ agent ทำแทนมนุษย์จะกว้างขึ้นมาก

จากเดิม AI agent คือผู้ช่วย ต่อไปอาจกลายเป็น operator ที่ทำงานครบวงจรได้จริง

ที่มา: @NousResearch

]]>nanobro.eth@newsletter.paragraph.com (nanobro_rit)aihermesstripenanobro<![CDATA[ใช้ tmux - Claude Code session ยาว ไม่ต้อง login บ่อยๆ]]>https://blog.nanobro.co/claude-code-ssh-tmux a8h1JnG3cq3jaXrXxe1ZFri, 29 May 2026 17:55:19 GMTใช้ Claude Code ผ่าน SSH ยังไงไม่ให้หลุด: แก้ด้วย tmux

เวลา SSH เข้าเครื่อง dev หรือ server แล้วเปิด claude เพื่อใช้ Claude Code ปัญหาที่เจอบ่อยคือ session หลุดกลางทาง

เช่น เน็ตหลุด, SSH timeout, ปิด terminal ผิดหน้าต่าง, เครื่อง client sleep หรือย้ายที่ทำงานแล้ว connection หาย

ที่น่าหงุดหงิดคือบางครั้ง Claude Code กำลังคิด กำลังแก้ไฟล์ หรือกำลังรัน test อยู่ พอ SSH หลุด เราต้อง login ใหม่ เข้า folder ใหม่ เปิด Claude Code ใหม่ แล้วค่อยไล่ context ต่ออีกที เสียเวลามาก

วิธีแก้ง่าย ๆ คือใช้ tmux

tmux จะทำให้ terminal session อยู่ต่อบนเครื่องปลายทาง แม้ SSH จากเครื่องเราจะหลุดไปแล้วก็ตาม พอกลับมา SSH ใหม่ ก็ attach กลับเข้า session เดิมได้ทันที

Flow สั้น ๆ

แทนที่จะทำแบบนี้:

ssh user@server
cd ~/project
claude

ให้ทำแบบนี้แทน:

ssh user@server
cd ~/project
tmux new -s claude-work
claude

ถ้า SSH หลุด หรือเราปิด terminal ไปโดยไม่ตั้งใจ Claude Code จะยังอยู่ใน tmux

กลับเข้ามาใหม่ด้วย:

ssh user@server
tmux attach -t claude-work

แล้วจะกลับไปเจอ Claude Code session เดิม

ติดตั้ง tmux

บน Ubuntu หรือ Debian:

sudo apt update
sudo apt install tmux

บน macOS ให้รัน brew install tmux

เช็กว่าใช้ได้:

tmux -V

วิธีใช้แบบง่ายที่สุด

SSH เข้าเครื่องก่อน:

ssh user@server

เข้า project:

cd ~/project

สร้าง tmux session:

tmux new -s claude-work

เปิด Claude Code ด้วยคำสั่ง claude

จากนั้นใช้งานตามปกติ

ออกจาก SSH โดยไม่ปิด Claude Code

ถ้าจะออกจาก tmux แต่ให้ Claude Code ทำงานต่อ ให้กด:

Ctrl+B แล้วกด D

อันนี้เรียกว่า detach

หลัง detach แล้วจะกลับมาที่ shell ปกติ จากนั้นจะออกจาก SSH ก็ได้:

exit

Claude Code ยังไม่หาย เพราะมันยังอยู่ใน tmux บนเครื่องปลายทาง

กลับเข้ามาดู session เดิม

SSH กลับเข้าเครื่อง:

ssh user@server

ดู tmux session ที่เปิดอยู่:

tmux ls

ถ้าเห็นประมาณนี้:

claude-work: 1 windows

ก็ attach กลับเข้าไปได้เลย:

tmux attach -t claude-work

เท่านี้ก็กลับไปที่ Claude Code session เดิมได้แล้ว

ตั้งชื่อ session ตาม project

ถ้าใช้หลาย repo ให้ตั้งชื่อ session แยกกัน จะได้ไม่งง

tmux new -s claude-api

tmux new -s claude-web

tmux new -s claude-docs

ดู session ทั้งหมด:

tmux ls

attach เข้า session ที่ต้องการ:

tmux attach -t claude-api

เปิด Claude Code ใน tmux แบบคำสั่งเดียว

ถ้าอยากเปิด tmux แล้วเข้า project พร้อมเปิด Claude Code ทันที:

tmux new -s claude-work 'cd ~/project && claude'

ถ้าอยากสร้าง session ไว้เบื้องหลังแบบไม่ attach ทันที:

tmux new-session -d -s claude-work 'cd ~/project && claude'

แล้วค่อยกลับเข้าไปดู:

tmux attach -t claude-work

ส่ง prompt เข้า Claude Code จากข้างนอก tmux

บางครั้งเราไม่อยาก attach เข้าไป แต่แค่อยากส่ง prompt เข้า Claude Code ที่เปิดค้างไว้

ใช้คำสั่งนี้:

tmux send-keys -t claude-work 'ช่วยแก้ test ที่ fail แล้วรัน test ยืนยันให้ด้วย' Enter

ดู output ล่าสุด:

tmux capture-pane -t claude-work -p -S -100

คำสั่งนี้มีประโยชน์มากเวลาคุมหลาย session พร้อมกัน หรืออยากเช็กว่า Claude Code ทำงานถึงไหนแล้วโดยไม่ต้อง attach เข้าไป

คำสั่ง tmux ที่ใช้บ่อย

สร้าง session:

tmux new -s claude-work

สร้าง session แบบ background:

tmux new-session -d -s claude-work

ดู session ทั้งหมด:

tmux ls

attach เข้า session:

tmux attach -t claude-work

detach โดยไม่ปิดงาน:

Ctrl+B แล้วกด D

ส่งข้อความเข้า session:

tmux send-keys -t claude-work 'your prompt here' Enter

ดู output ล่าสุด:

tmux capture-pane -t claude-work -p -S -100

ปิด session:

tmux kill-session -t claude-work

ตัวอย่าง workflow จริง

สมมติ SSH เข้าเครื่อง dev แล้วอยากให้ Claude Code แก้ bug ใน repo

ssh user@server
cd ~/my-app
tmux new -s claude-my-app
claude

จากนั้นสั่งใน Claude Code:

ช่วยอ่าน repo นี้ แล้วแก้ bug login redirect ให้หน่อย หลังแก้เสร็จให้รัน test ที่เกี่ยวข้อง และสรุปว่าแก้อะไรไปบ้าง

ถ้าต้องปิดเครื่องหรือเน็ตเริ่มไม่นิ่ง ให้ detach:

Ctrl+B แล้วกด D

ออกจาก SSH:

exit

ผ่านไปสักพัก กลับมาดูใหม่:

ssh user@server
tmux attach -t claude-my-app

Claude Code session เดิมจะยังอยู่

Prompt ควรเขียนให้ชัด

เวลาใช้ Claude Code ใน session ยาว ๆ ควรสั่งให้ชัดว่าให้ทำอะไร ขอบเขตอยู่ตรงไหน ห้ามทำอะไร และต้องตรวจงานยังไง

ตัวอย่าง:

แก้ bug login redirect หลัง OAuth callback
เงื่อนไข:
- อ่าน codebase ก่อน
- แก้เฉพาะไฟล์ที่เกี่ยวข้องกับ auth และ routing
- อย่า commit
- หลังแก้เสร็จให้รัน test ที่เกี่ยวข้อง
- สรุปสาเหตุ bug, ไฟล์ที่แก้, และผล test จริง

หรือถ้าให้ refactor:

Refactor payment service ให้แยก validation, provider call, และ persistence ออกจากกัน
เงื่อนไข:
- รักษา public API เดิม
- เพิ่มหรือแก้ test ให้ครอบคลุม behavior เดิม
- อย่าเปลี่ยน business logic
- รัน test payment ทั้งหมดก่อนสรุป

อย่าสั่งแค่ “แก้ให้หน่อย” เพราะ agent จะต้องเดาขอบเขตเอง ควรบอกให้ครบว่าอยากให้มันทำอะไรและยืนยันผลยังไง

ใช้ slash command ผ่าน tmux ได้เหมือนเดิม

เพราะ Claude Code ยังเป็น interactive session ปกติ เราสามารถใช้ slash command ได้ เช่น:

/review

/compact focus on current auth bug and test failures

/context

/cost

ถ้าจะส่งจากข้างนอก tmux:

tmux send-keys -t claude-work '/compact focus on current implementation and unresolved errors' Enter

ข้อควรระวัง

1. อย่าเผลอปิด session จริง

ถ้าแค่อยากออกชั่วคราว ให้ detach ด้วย:

Ctrl+B แล้วกด D

แต่ถ้าพิมพ์ /exit ใน Claude Code หรือ kill tmux session งานจะจบจริง

2. ตั้งชื่อ session ให้จำง่าย

ชื่อที่ดีควรบอกว่าเป็นงานอะไร เช่น:

claude-api
claude-web
claude-payment
claude-bug-login

3. ปิด session เมื่อจบงาน

ถ้างานเสร็จแล้วควรปิด session:

tmux kill-session -t claude-work

หรือเข้า Claude Code แล้วพิมพ์:

/exit

4. ถ้า session ยาวมาก ให้ compact

ถ้าใช้ Claude Code session เดิมนาน ๆ context จะเริ่มแน่น ให้ใช้:

/compact focus on current task, files changed, test results, and remaining issues

5. แยก session ตามงาน

ถ้างานคนละเรื่อง ควรแยก tmux session เช่น backend, frontend, docs หรือ review จะคุมง่ายกว่าและ context ไม่ปนกัน

Script สั้น ๆ สำหรับเปิด Claude Code ใน tmux

ถ้าใช้บ่อย สร้างไฟล์ชื่อ claude-tmux.sh:

#!/usr/bin/env bash

SESSION_NAME="${1:-claude-work}"
PROJECT_DIR="${2:-$PWD}"

tmux new-session -d -s "$SESSION_NAME" "cd $PROJECT_DIR && claude"

echo "Started Claude Code in tmux session: $SESSION_NAME"
echo "Attach with:"
echo "tmux attach -t $SESSION_NAME"

ทำให้รันได้:

chmod +x claude-tmux.sh

ใช้งาน:

./claude-tmux.sh claude-my-app ~/my-app

attach เข้าไปดู:

tmux attach -t claude-my-app

สรุป

ถ้าใช้ Claude Code ผ่าน SSH แล้วเจอปัญหา session หลุด ต้อง login ใหม่ หรือเสีย context บ่อย ๆ ให้ใช้ tmux

จำ flow นี้พอ:

ssh user@server
cd ~/project
tmux new -s claude-work
claude

ถ้าจะออกชั่วคราว:

Ctrl+B แล้วกด D

กลับมาใหม่:

ssh user@server
tmux attach -t claude-work

แค่นี้ Claude Code ก็จะทำงานต่อได้แม้ SSH จะหลุด ไม่ต้องเริ่มใหม่ทุกครั้ง และเหมาะมากสำหรับงาน coding agent ที่ใช้เวลานานหรือมีหลายรอบตรวจแก้

]]>nanobro.eth@newsletter.paragraph.com (nanobro_rit)claude codetmuxsshai coding<![CDATA[Claude Opus 48 And Haiku 45]]>https://blog.nanobro.co/claude-opus-48-and-haiku-45 lQdS1u3u7fziu9b69irJThu, 28 May 2026 17:05:55 GMTClaude เปิดตัว Opus 4.8 แล้ว

Claude เปิดตัว Opus 4.8 แล้ว

Claude เปิดตัว Opus 4.8 แล้ว

แต่ Haiku ยัง 4.5 อยู่เลยนะ

]]>nanobro.eth@newsletter.paragraph.com (nanobro_rit)aiclaudenanobro