Tencent ปล่อย Hy-Memory-30B-A3B (Apache-2.0): โมเดล MoE active 3B ที่ทำหน้าที่ 'เขียนความจำ' แทน LLM ใหญ่ใน Mem0/MemOS — ชนะ Claude Opus 5 แบบฉิวเฉียด 55.49 ต่อ 54.62 พร้อมเปิดซอร์ส MemHub

Tencent Hunyuan อัปโหลด Hy-Memory-30B-A3B ขึ้น Hugging Face เมื่อ 15 ต.ค. 2026 พร้อมรายงานเทคนิคบน arXiv (2610.22196) ในวันเดียวกัน โมเดลตัวนี้ไม่ใช่แชตบอตทั่วไป แต่เป็นโมเดลขนาดเล็กที่ฝึกมาทำงานเดียวคือ “write path” ของระบบความจำภายนอก ได้แก่ตัดสินใจว่าข้อมูลไหนควรจำ ควรเขียนละเอียดแค่ไหน และเมื่อมีข้อมูลใหม่ที่ขัดกับของเดิมควรอัปเดตความจำอย่างไร ตามการ์ดโมเดล มันถูกออกแบบมาเพื่อเสียบแทน LLM ทั่วไปที่อยู่หลัง Mem0, MemOS และ Hy-Memory ได้ทันที

ประเด็นนี้สำคัญกับคนทำเอเจนต์ เพราะระบบความจำส่วนใหญ่ทุกวันนี้เรียกโมเดลใหญ่ราคาแพงทุกครั้งที่ต้องสรุปบทสนทนาลงฐานความจำ ถ้าโมเดลที่ active แค่ราว 3B ทำงานนี้ได้ดีเท่า frontier model ต้นทุนส่วนนี้จะลดลงมาก และย้ายมารันเองในเครื่องได้

สเปกและไลเซนส์

• สถาปัตยกรรม: hy_v3 MoE จำนวน 48 ชั้น (ชั้นแรก dense ที่เหลือ sparse) มี 128 experts เลือกใช้ 8 ตัวต่อโทเคน บวก shared expert อีก 1 ตัว hidden size 2048 และ max_position_embeddings 262,144 ตามที่ระบุใน config.json
• ขนาดไฟล์: BF16 ประมาณ 60 GB ส่วนรุ่น FP8 ที่ตามมาเมื่อ 16 ต.ค. ประมาณ 30.6 GB ทั้งคู่ทดสอบกับ vLLM v0.31.0 และเรียกผ่าน API แบบ OpenAI-compatible ได้ (--served-model-name hy-memory) มีโหมด no_think ผ่าน chat_template_kwargs ส่วน config.json ระบุ transformers 5.6.0.dev0
• รันบนการ์ดจอ 24GB ได้ไหม: รุ่นทางการยังไม่ได้ FP8 ต้องการ VRAM ราว 31GB ขึ้นไป ถ้าจะลงการ์ด 24GB ต้องรอ quant 4-bit จากชุมชน ซึ่งตอนเขียนข่าวนี้ Tencent ยังไม่ได้ปล่อยเอง
• ไลเซนส์: ไฟล์ LICENSE ในรีโประบุ Apache-2.0 และบอกชัดว่า “does not impose any additional restrictions” ต่างจากโมเดล Hunyuan หลายตัวก่อนหน้าที่ใช้ไลเซนส์เฉพาะของ Tencent ซึ่งมีเงื่อนไขจำกัดพื้นที่ใช้งาน
• วิธีฝึก: เริ่มจาก Hy3-A3B Base แล้วฝึกสองขั้น ขั้นแรกคือ Memory On-Policy Distillation โดยใช้ Hy3 รุ่นเรือธงเป็น teacher ให้คะแนนโทเคนบนข้อความที่ตัวโมเดลเขียนเอง ขั้นที่สองคือ Memory RL ที่ให้รางวัลตามว่าความจำที่เขียนไว้ช่วยตอบคำถามได้จริงหรือไม่ ใช้ GRPO ระดับ chunk และมีตัวคุมไม่ให้จดมากเกินจำเป็น

ตัวเลข: ชนะจริง แต่ห่างน้อยมาก

Tencent ทดสอบโดยเปลี่ยนเฉพาะ “ตัวเขียนความจำ” ส่วนโมเดลที่ตอบคำถาม ตัวให้คะแนน และการตั้งค่า retrieval คงไว้เหมือนเดิมทุกชุด ใช้ 6 เมตริก ได้แก่ LoCoMo, LongMemEval, PersonaMem-v2, Travel, Shopping และ Code Memory Bench บน 4 harness ผลเฉลี่ย (macro average) ออกมาดังนี้

ตัวเขียนความจำ	Mem0	Hy-Memory	MemOS	EverMemOS (ไม่ได้ใช้ฝึก)	เฉลี่ย
Hy-Memory-30B-A3B	54.02	60.55	50.51	56.89	55.49
Claude Opus 5	53.43	60.53	50.50	54.04	54.62
DeepSeek V4.1 Flash	49.73	60.20	49.17	55.47	53.64
Qwen3.6-35B-A3B	47.51	55.87	47.36	50.75	50.37
Qwen3-30B-A3B	39.81	45.67	45.44	46.57	44.37

ข้อควรสังเกตก่อนเชื่อพาดหัว:

• ทุกตัวเลขมาจากชุดทดสอบย่อย 20% ที่ Tencent เลือกไว้ตายตัว ไม่ใช่ benchmark เต็มชุด และยังไม่มีใครทดสอบซ้ำแยกต่างหาก
• บน Hy-Memory harness ซึ่งเป็นระบบของ Tencent เอง ชนะ Opus 5 แค่ 0.02 คะแนน (60.55 ต่อ 60.53) และบน MemOS ชนะแค่ 0.01 ช่องว่างระดับนี้น่าจะอยู่ในช่วงความคลาดเคลื่อนปกติ
• ช่องว่างที่ชัดที่สุดอยู่บน EverMemOS ซึ่งไม่ได้ใช้ฝึก (56.89 ต่อ 54.04) จึงเป็นหลักฐานที่ดีที่สุดว่าโมเดลใช้ได้ข้ามระบบ แต่ DeepSeek V4.1 Flash ก็ตามมาใกล้ที่ 55.47
• ในตารางย่อย Opus 5 ยังชนะ LoCoMo บนเกือบทุก harness และทุกโมเดลได้คะแนน Shopping แค่ราว 15–24 แปลว่างานบางประเภทยังยากสำหรับทุกตัว

ข้อสรุปที่ตรงกว่าคือ “เทียบชั้น Opus 5 ได้ในงานเขียนความจำ ด้วยโมเดลที่ active ~3B” ไม่ใช่ “เหนือกว่าแบบขาด” แต่ข้อสรุปนี้ก็มีความหมายมากในแง่ต้นทุน

ของที่มาด้วย: SDK hy-memory 2.0 และ MemHub

Tencent เปิดซอร์สรีโป Tencent-Hunyuan/Hy-Memory (Apache-2.0) ไปพร้อมกัน ข้างในมี SDK hy-memory 2.0 บน PyPI (2.0.1 ออก 15 ต.ค. และขยับถึง 2.0.4 แล้วเมื่อ 17 ต.ค.) แยกความจำเป็นสามแบบ คือ Chat, Working และ Coding ซึ่งแบบหลังเก็บประวัติการแก้โค้ดเป็น diff chain

อีกตัวคือ MemHub แอปเดสก์ท็อปกับ CLI แบบ local-first ที่ดึงประวัติแชตและ trace การเขียนโค้ดจากแอป AI ที่ผู้ใช้อนุญาต ได้แก่ Claude Code, Cursor, Codex, OpenCode และ Qwen Code มารวมเป็นความจำชุดเดียวในเครื่อง แล้วให้เครื่องมือแต่ละตัวเรียกใช้ผ่าน Skill, Hook, plugin หรือ MCP README ระบุว่ายังเป็น preview รองรับ Linux x64/arm64 กับ macOS ยังไม่รองรับ Windows และบอกชัดว่าไม่เก็บหน้าจอ, OCR, คีย์บอร์ด/เมาส์, คลิปบอร์ด หรืออัดเสียงเบื้องหลัง

มุมมอง AI Curator

โมเดลตัวนี้เป็นตัวอย่างที่ดีของแนวโน้มที่เราเห็นมาหลายเดือน คือการแยกงานย่อยในระบบเอเจนต์ออกมาให้โมเดลเฉพาะทางขนาดเล็กทำ แทนที่จะส่งทุกอย่างให้ frontier model งานเขียนความจำเหมาะกับแนวทางนี้มาก เพราะเกิดบ่อย (ทุกเทิร์นหรือทุก chunk), ไม่ต้องการความรู้รอบตัวกว้าง และวัดผลได้ชัดว่าความจำที่เขียนไว้ช่วยตอบคำถามภายหลังได้หรือไม่ การได้ผลเท่า Opus 5 ด้วย active 3B แปลว่าส่วนที่เคยเป็นค่าใช้จ่ายแฝงก้อนใหญ่ของระบบ memory ย้ายมารันบน GPU ตัวเดียวในองค์กรได้

สำหรับทีมไทยมีสองเรื่องที่ต้องคิด เรื่องแรกคือภาษา การ์ดโมเดลระบุแค่ภาษาอังกฤษกับจีน และทุก benchmark เป็นภาษาอังกฤษ ระบบที่ต้องจำบทสนทนาภาษาไทย เช่น ชื่อลูกค้า ที่อยู่ หรือความชอบ ควรทดสอบกับข้อมูลจริงก่อน เพราะงานเขียนความจำพลาดได้ทั้งแบบตกหล่นและแบบแต่งเติม เรื่องที่สองคือ MemHub แนวคิดรวมประวัติจาก Claude Code, Cursor และ Codex ไว้ที่เดียวน่าสนใจมาก แต่ก็หมายถึงไฟล์เดียวที่มีทั้งโค้ด คีย์ที่เผลอแปะในแชต และบริบทงานของทุกโปรเจกต์ ถ้าจะใช้ในองค์กรควรตรวจ data lifecycle ใน docs/INSTALLATION.md และกำหนดสิทธิ์ให้ชัดก่อน โดยเฉพาะในสัปดาห์เดียวกับที่เพิ่งมีข่าวคีย์ API รั่วจากบริการฝั่งเครื่องมือเขียนโค้ด

ข้อดีที่ชัดที่สุดคือไลเซนส์ Apache-2.0 ที่ไม่มีเงื่อนไขพ่วง ทำให้นำไปใช้เชิงพาณิชย์และ fine-tune ต่อได้โดยไม่ติดปัญหากฎหมาย ซึ่งไม่ใช่สิ่งที่โมเดลจาก Tencent ให้มาเสมอ

แหล่งข่าว

• tencent/Hy-Memory-30B-A3B — Hugging Face (model card + LICENSE)
• Hy-Memory-30B-A3B: Attributed Reinforcement Learning for Long-Term Memory Writing — arXiv 2610.22196
• Tencent-Hunyuan/Hy-Memory (SDK + MemHub) — GitHub
• hy-memory — PyPI