วิเคราะห์และรีวิว Ornith-1.0: โมเดลโอเพนซอร์สที่ปรับปรุงตัวเองได้ สำหรับงาน Agentic Coding

Ornith-1.0 คือโมเดล open-source ที่เคลมความสามารถ self-improving สำหรับงาน agentic coding โดยเฉพาะ — ตัวโมเดลปรับปรุงตัวเองจากผลลัพธ์การรันโค้ดจริง ไม่ใช่แค่ fine-tune ทีเดียวจบ จุดขายหลักคือ loop ที่ให้ agent เขียนโค้ด รันเทส แล้วป้อนผลกลับไปปรับโมเดลต่อเนื่อง เหมาะกับทีมที่ต้องการ agent เขียนโค้ดที่ “ฉลาดขึ้นเรื่อยๆ” ตามงานที่ทำจริง สรุปสั้น: ถ้าทีมมีงาน coding agent ซ้ำๆ และพร้อมลงทุนเวลา setup loop นี้คุ้มลอง แต่ถ้าต้องการโมเดลสำเร็จรูปพร้อมใช้ทันที ยังต้องรอดูความเสถียรก่อน

ภาพรวมก่อนลงลึก

ก่อนลงรายละเอียด ลองดูภาพรวมของวงจรนี้ก่อนว่าหน้าตาเป็นยังไง จากภาพจะเห็นสามจุดหลัก: ส่วนที่ agent เขียนโค้ด ส่วนรันเทสอัตโนมัติ และส่วน feedback ที่ป้อนกลับเข้าไปปรับพฤติกรรมโมเดล

จุดที่น่าสนใจคือ loop นี้ไม่ได้ต้องรอ human review ทุกรอบ ทำให้ agent ปรับตัวไวขึ้นตามงานจริงที่ทีมป้อนเข้าไป แต่ก็แปลว่าต้องมี guardrail ที่ดีพอ ไม่งั้น error จะสะสมในลูปได้เช่นกัน

ผมว่าภาพนี้ช่วยให้เห็นภาพรวมก่อนไปดูรายละเอียดแต่ละส่วนในหัวข้อถัดไปได้ชัดขึ้นนะ

ตอนที่ยังต้องรอ AI เก่งขึ้นเอง

ใครที่ลอง agentic coding tool รุ่นก่อนๆ คงเจอซีนเดิม: สั่งให้ refactor ฟังก์ชันหนึ่ง แต่ agent วนลูปแก้ผิดจุดซ้ำๆ จนต้องเข้าไปเขียน prompt ใหม่เองทุกครั้ง

พอ error pattern เดิมโผล่มาอีก ก็ทำได้แค่จด issue ไว้แล้วรอ vendor ปล่อยโมเดลเวอร์ชันถัดไป ซึ่งบางทีก็หลายเดือน ระหว่างนั้นทีมต้อง fine-tune เองหรือเขียน rule เสริมปะผุไปก่อน

นี่คือช่องว่างที่ Ornith-1.0 บอกว่าจะเข้ามาแก้ — โมเดลที่ปรับพฤติกรรมตัวเองจาก feedback loop ของงานจริง โดยไม่ต้องรอ release cycle ถัดไปถึงจะฉลาดขึ้นล่ะ

Ornith-1.0 อยู่ตรงไหนในแผนที่ open-source coding model

Ornith-1.0 วางตัวเป็นสาย open-source สำหรับงาน agentic coding โดยเฉพาะ — ไม่ใช่โมเดล all-purpose ที่เอามาทำ chat ทั่วไปแล้วพ่วง coding มาด้วย ตัวโมเดลถูก post-train ต่อยอดจาก Gemma 4 กับ Qwen 3.5 จุดขายหลักคือ self-improving loop ที่ใช้ RL หา search trajectory ที่ดีขึ้นเอง ต่างจากสาย DeepSeek-Coder หรือ Qwen-Coder ที่ต้องรอ fine-tune รอบใหม่หรือ release ถัดไปถึงจะขยับ

License MIT ดาวน์โหลดมา self-host ได้เต็มรูป ไม่มีข้อจำกัดตามประเทศ กลุ่มเป้าหมายจึงเป็นทีมที่อยากคุม pipeline เอง ตั้งแต่ solo dev ที่ไม่อยากผูก API กับ vendor เดียว ไปจน startup/enterprise ที่มีข้อมูล proprietary ต้องรันในวงปิด

เทียบกับ Claude/GPT ที่เป็น closed-source ควบคุมทุกอย่างฝั่ง vendor — จุดยืนของ Ornith คือ transparency กับ control: เห็น weight, ปรับ behavior เองได้, ไม่ต้องรอ vendor roadmap แต่ก็ต้องแบกภาระ infra เองเต็มๆ ด้วยนะ

หน้าตาของตระกูล Ornith-1.0 มีขนาดไหนบ้าง

Ornith-1.0 ออกมาเป็นตระกูลสามขนาดพร้อมกัน ไม่ใช่รุ่นเดียว ตัวเล็กสุดคือ 9B แบบ dense ส่วนตัวใหญ่ขึ้นเป็น 35B และ 397B ที่ใช้สถาปัตยกรรม Mixture-of-Experts ทั้งคู่ context window เท่ากันหมดที่ 256K token ปล่อยน้ำหนักในรูป bf16, FP8 และ GGUF สำหรับสาย quantized

เรื่อง benchmark ก็เปิดตัวเลขไว้ครบเทียบระหว่างขนาดกันเอง จะเห็นชัดว่า self-improving loop ให้ผลตามสเกล — โมเดลใหญ่หา trajectory ได้ลึกกว่า คะแนน SWE-bench Verified กับ Terminal-Bench 2.1 ไต่ขึ้นเป็นขั้นตามพารามิเตอร์

สรุปคือถ้าอยาก self-host ตัวเบาสุด 9B ก็ยังต้องมี GPU 80GB ต่อใบอยู่ (FP8 ลดได้ประมาณครึ่ง) — ส่วน 35B/397B ต้องคิดถึงระดับ multi-GPU node ตั้งแต่วางแผน อย่าคิดว่ารุ่นนี้จะรันด้วยการ์ดเกมมิ่งใบเดียวได้เหมือนโมเดล 7B รุ่นเก่าๆ

สถานการณ์จริงที่เอาไปวางในทีมได้

Self-refactor loop เหมาะกับงาน legacy code ที่กองไว้นาน ปล่อยให้ Ornith-1.0 ไล่ scan แล้วเสนอ refactor เป็นรอบๆ แทนที่จะนั่งไล่เองทีละไฟล์

Auto test-fix ใช้ได้จริงตอน CI แดงกลางดึก โมเดลอ่าน log แล้วแก้ test ที่พังให้ก่อน คนค่อยมา review ตอนเช้า

Learning from repo history ช่วยตอนทีมใหม่ join โปรเจกต์เก่า โมเดลดึง pattern จาก commit เก่าๆ มาแนะนำ code style ให้ตรงทีมโดยไม่ต้องมี doc ยาวๆ

ส่วน multi-agent debugging เหมาะกับบั๊กข้ามโมดูล ให้หลาย agent แยกกันไล่ทีละ layer พร้อมกัน แทนที่จะให้คนเดียว trace ทั้งระบบ

สาย solo dev ที่ไม่มี GPU 80GB ในบ้าน ทางตรงที่สุดคือเช่า GPU cloud รายชั่วโมงตอนต้องใช้ หรือรอสาย GGUF ที่ชุมชนควอนไทซ์มาให้พอวิ่งบนการ์ดเกมมิ่งได้ (แลกด้วยคุณภาพที่หายไปตามระดับ quantization)

วางข้างคู่แข่งสายเดียวกันแล้วเป็นยังไง

จุดขายของ Ornith-1.0 คือ “โตขึ้นตามที่เราใช้” ไม่ใช่โมเดลนิ่งๆ แบบ DeepSeek-Coder — แต่แลกมาด้วยเพดานฮาร์ดแวร์ที่สูงกว่าและความเสี่ยงเรื่อง consistency ที่ยังไม่มีใครการันตี ถ้าทีมต้องการความชัวร์ระดับ production Claude/Copilot ยังตอบโจทย์กว่า แต่ถ้าอยากทดลองอะไรใหม่ๆ แบบคุมเองได้ทุกขั้นตอน Ornith-1.0 น่าเล่นสุดในกลุ่มนี้

จุดแข็งชัดๆ กับหลุมพรางที่ต้องเผื่อไว้

บิลจริงที่ไม่ได้โผล่บนหน้า repo

License MIT อ่านแล้วดูเหมือนใช้ฟรีทั้งหมด แต่พอกางแผน self-host ออกมา ตัวเลขที่แท้จริงมันไปโผล่ที่ค่า GPU ล้วนๆ รุ่น 9B dense ระบุชัดว่าต้อง GPU 80GB ต่อใบสำหรับ bf16 (ระดับ H100/A100) ส่วน 35B และ 397B ที่เป็น MoE ต้องกระโดดไป multi-GPU node พร้อม tensor parallelism ตั้งแต่วันแรก การเลือก FP8 ช่วยลด VRAM ลงได้ประมาณครึ่งบน GPU ที่รองรับ แต่ก็ยังไม่ใช่ระดับที่การ์ดเกมมิ่งใบเดียวจะรับไหวอยู่ดี

นอกจาก GPU ยังมีต้นทุนที่ไม่โผล่ในสเปก: self-improving loop ต้องมีทีมเฝ้า data pipeline ที่ป้อนกลับเข้าโมเดลตลอดเวลา ไม่ใช่ตั้งแล้วปล่อยทิ้ง — และความเสี่ยง model drift มาพร้อมกันเสมอ โมเดลปรับพฤติกรรมเองเรื่อยๆ จนอาจเบี่ยงจากที่ทีมต้องการ ต้องมี checkpoint และแผน rollback สำรองไว้ตลอด

ทีมแบบไหนควรหยิบมาลอง

ทิศทางที่น่าจับตาต่อจากนี้

ถ้าแนวคิด self-improving แบบ Ornith-1.0 แพร่หลายจริง งาน agentic coding จะไม่ใช่แค่ “เลือกโมเดลที่เก่งสุด” อีกต่อไป แต่กลายเป็น “เลือกโมเดลที่ปรับตัวเข้ากับ codebase ของทีมได้เร็วสุด” — สนามแข่งขันจะย้ายจาก benchmark ทั่วไปไปที่ความสามารถในการเรียนรู้เฉพาะทาง

สำหรับฝั่ง infra เทรนด์นี้กดดันในทางกลับกัน — self-improving loop ต้องรัน RL rollout ต่อเนื่อง ทำให้เพดาน VRAM ต่ำสุดยังยืนอยู่ที่ระดับ data-center GPU (80GB) เพื่อรับ dense 9B ใบเดียว และวิ่งไป multi-GPU node ทันทีสำหรับ MoE ทีมที่คิดจะเริ่มควรมองไปที่ H100/A100 หรือเช่า cloud รายชั่วโมงก่อน อย่าคาดหวังการ์ด consumer

ก่อนตัดสินใจ scale ทั้งทีม แนะนำให้ pilot กับ repo เล็กๆ ก่อน วัด compute cost จริง แล้วค่อยขยาย — ดีกว่าเชื่อ hype แล้วลงทุนทีเดียว