Ornith-1.0
Agentic Coding Model Analysis

1. ทำไม Ornith-1.0 ถึงน่าพูดถึงตอนนี้

ทุกสัปดาห์มีโมเดล open-source ใหม่เปิดตัวบน Hugging Face เป็นสิบตัว ส่วนใหญ่เงียบหายไปในไม่กี่วัน แต่ Ornith-1.0 จาก DeepReinforce.AI ต่างออกไปตรงที่มันไม่ได้พยายามเป็น "โมเดลอเนกประสงค์" อีกตัว — มันถูกออกแบบมาเพื่องานเดียวเท่านั้นคือ agentic coding การเขียนโค้ด แก้บั๊ก และรัน tool-calling แบบ autonomous ผ่าน terminal

จุดที่ทำให้ทีมงานสาย Local LLM และ enterprise architect เริ่มหันมามองพร้อมกันคือการผสมกันของสี่อย่าง: license แบบ MIT ที่ใช้เชิงพาณิชย์ได้ตรงไปตรงมา, ขนาดโมเดลที่ครอบคลุมตั้งแต่ 9B ไปจนถึง 397B, เทคนิค self-scaffolding RL ที่เป็นแนวทางใหม่ในการเทรน agentic model, และคะแนน benchmark ที่ vendor รายงานว่าสูงเทียบเท่าหรือดีกว่าโมเดลระดับ flagship บางตัวในหมวด agentic coding

2. Ornith-1.0 คืออะไร

Ornith-1.0 คือตระกูลโมเดล AI แบบ open-weight ภายใต้ MIT License จาก DeepReinforce.AI ซึ่งเป็น independent AI lab/team (ตำแหน่งที่ตั้งสำนักงาน/นิติบุคคลยังไม่มีการยืนยันอิสระในรายงานนี้) เปิดตัวเมื่อ 25 มิถุนายน 2026 โดยวางตำแหน่งตัวเองชัดเจนว่าเป็น agentic coding model — ไม่ใช่ general-purpose chatbot

ตระกูลนี้มีสี่ขนาด:

• Ornith-1.0-9B (Dense) — เป้าหมายคือ edge device และ laptop มี artifact และ GGUF ที่ตรวจสอบได้บน Hugging Face
• Ornith-1.0-31B (Dense) — ประกาศไว้ใน official blog และ coverage ภายนอกว่าเป็นส่วนหนึ่งของตระกูล แต่ ณ ตอนที่ตรวจสอบ ยังไม่พบ artifact ที่ยืนยันได้ชัดเจนใน Hugging Face collection ควรมองเป็น announced / pending artifact verification ยังไม่ควรวางแผนใช้งานจริงจนกว่าจะเห็น model card
• Ornith-1.0-35B (MoE) — รุ่นที่ได้รับความสนใจมากที่สุดในกลุ่ม local deployment มี artifact, GGUF และ FP8 ครบ
• Ornith-1.0-397B (MoE) — รุ่นใหญ่สุดของตระกูล ใช้สำหรับ flagship benchmark claim

โมเดลทั้งหมด post-trained บนฐาน Gemma 4 และ Qwen 3.5 ตาม official statement

เรื่อง license มีข่าวดีระดับหนึ่ง: Ornith weights เป็น MIT ตาม official model card และฐานทั้งสอง (Qwen 3.5 และ Gemma 4) ก็เป็น Apache 2.0 ยืนยันได้จาก LICENSE file ทางการของทั้งคู่ (Gemma 4 เป็นรุ่นแรกที่ DeepMind เปลี่ยนจาก Gemma Terms of Use มาเป็น Apache 2.0 ตั้งแต่เมษายน 2026) นั่นแปลว่าความเสี่ยงด้าน license ลดลงอย่างมีนัยสำคัญ แต่ "license เข้ากันได้" ไม่เท่ากับ "license เคลียร์แล้ว" — องค์กรยังต้องทำ license review มาตรฐานเรื่อง attribution, NOTICE preservation, การ redistribution และ hosted-service ตามปกติก่อนใช้งานจริง

จุดที่ทำให้ Ornith แตกต่างจากการ fine-tune ทั่วไปคือเทคนิคการเทรนที่เรียกว่า Self-Scaffolding Reinforcement Learning ซึ่งจะอธิบายในหัวข้อถัดไป

3. ทำไมชุมชน Local LLM ถึงสนใจ Ornith-1.0

สิ่งที่ทำให้ Ornith-1.0 ไม่ได้เป็นแค่ข่าวเปิดตัวโมเดลอีกตัว คือความเข้าถึงได้จริงสำหรับคนที่รันโมเดลบนเครื่องตัวเอง

• GGUF พร้อมใช้ ทั้ง 9B และ 35B มี quantization ให้เลือกครบตั้งแต่ Q4_K_M ไปจน Q8_0 และ BF16 ไฟล์ 9B เล็กสุดอยู่ที่ 5.63 GB ส่วน 35B เริ่มที่ 21.2 GB
• Ollama native library ยืนยันแล้ว — ollama run ornith:9b และ ornith:35b ใช้งานได้ตรง มี quant variants ให้เลือก และมียอด download แล้วกว่า 188,600 ครั้งในช่วงสั้น ๆ หลังเปิดตัว
• LM Studio รองรับผ่าน official listing — HF repo card มีปุ่ม lmstudio://open_from_hf ให้กดโหลดเข้า LM Studio ได้ตรง ไม่ต้องเดา
• 9B และ 35B คือช่วงที่ hardware ผู้บริโภคเอื้อมถึง — 9B รันได้บนการ์ดจอระดับ 8-16GB VRAM ส่วน 35B เหมาะกับเครื่องระดับ RTX 4090/5090 หรือ Mac unified memory 32GB ขึ้นไป

พูดง่าย ๆ คือนี่เป็นครั้งแรก ๆ ที่โมเดล agentic coding ระดับที่ได้คะแนน benchmark สูงในหมวดนี้ ไม่ต้องพึ่ง API และรันได้บนเครื่อง workstation ทั่วไป ความรู้สึกนี้เองที่จุดกระแสใน r/LocalLLaMA และ Hugging Face discussions ตั้งแต่วันแรก

เรื่อง community sentiment ต้องพูดอย่างระมัดระวัง: มี early hype และ FOMO ชัดเจนในกลุ่ม Local LLM — thread หลักบน Reddit มี engagement หลักร้อย upvotes และคอมเมนต์เชิงบวกจำนวนมาก แต่ตัวเลข engagement บน X/Twitter (เช่น likes, views) ยังนับเป็น low-confidence signal เพราะไม่มีวิธี sampling ที่ตรวจซ้ำได้ทางสถิติ และในหลายกระทู้ก็มี skepticism คู่ขนานอยู่จริง โดยเฉพาะคำถามว่า benchmark อาจ overfit กับ harness ที่ผ่อนปรน หรือ Ornith เป็นแค่ fine-tune ที่ปรับแต่งมาดี ไม่ใช่นวัตกรรมใหม่จริง สรุปคือ early community interest ที่ชัดเจน แต่ยังไม่ใช่ production validation

4. Architecture Insight: Self-Scaffolding RL และ MoE

Self-Scaffolding RL คืออะไร (แบบเข้าใจง่าย)

โมเดล agentic ทั่วไปส่วนใหญ่เรียนจาก "คำตอบ" — ให้ทำ task แล้ว reward ตาม solution ที่ได้ Ornith เดินไปอีกขั้น: มันเรียนรู้วิธี สร้าง scaffold หรือ workflow ของตัวเองก่อน แล้วค่อยทำ solution ตาม scaffold นั้น reward จะไหลกลับไปทั้งสอง stage คือทั้งการวางแผน workflow และการลงมือแก้ปัญหา ทำให้ scaffold กลายเป็นสิ่งที่โมเดล "เรียนรู้ที่จะออกแบบเอง" ไม่ใช่ template ตายตัวที่ทีมพัฒนาเขียนไว้ล่วงหน้า

ผลลัพธ์ในทางปฏิบัติคือโมเดลที่รู้จักวางแผนขั้นตอนก่อนลงมือ, เรียก tool ได้เองพร้อมตรวจผลลัพธ์และลองใหม่เมื่อพลาด, และมี self-repair ที่ตรวจจับข้อผิดพลาดแล้วแก้ไขต่อได้ในลูปเดียวกัน — สิ่งเหล่านี้คือทักษะที่ agentic coding workflow ต้องการจริง ๆ ไม่ใช่แค่ตอบคำถามเก่ง

เพื่อป้องกันปัญหาคลาสสิกของ RL agent คือ "reward hacking" (โมเดลหาทางแฮกตัวชี้วัดแทนที่จะแก้ปัญหาจริง) DeepReinforce ใส่การป้องกันสามชั้น: immutable environment ที่ล็อกสภาพแวดล้อมภายนอกไม่ให้โมเดลแก้ไข, deterministic monitor ที่ตรวจเงื่อนไขแบบตายตัวไม่ใช้ AI ตัดสิน, และ LLM judge veto เป็นด่านสุดท้ายที่ตรวจซ้ำก่อนให้ผ่าน

MoE: เร็วขึ้นด้าน compute แต่ไม่ได้ประหยัด VRAM

Ornith-35B และ 397B ใช้สถาปัตยกรรม Mixture-of-Experts (MoE) ซึ่งในแต่ละ token จะ activate เฉพาะบางส่วนของ parameter ทั้งหมด ทำให้ throughput ต่อ token เร็วกว่าโมเดล dense ขนาดเท่ากันมาก

จุดที่ต้องพูดให้ตรงคือ active-parameter count ของ Ornith ไม่ได้ถูก vendor เปิดเผยอย่างเป็นทางการ ตัวเลขที่หลายคนพูดถึงกัน เช่น ~3B สำหรับ 35B นั้นเป็นการคาดการณ์จากโครงสร้างพื้นฐานที่ Ornith ใช้ฐานสถาปัตยกรรมเดียวกับ Qwen3.5-35B-A3B (HF tag ระบุ qwen3_5_moe) ไม่ใช่ตัวเลขที่ DeepReinforce ยืนยันตรง ๆ สำหรับ 397B ก็เช่นกัน ตัวเลข active param ใด ๆ ที่หลุดมาตามกระแส (เช่น ~17B/~24B/~30B) ยังไม่มีแหล่งยืนยันและไม่ควรนำไปใช้วางแผน capacity

5. Benchmark Reality Check

ตัวเลขที่ทำให้ Ornith-1.0 เป็นข่าวคือคะแนนในกลุ่ม agentic coding benchmark ที่ DeepReinforce รายงานเอง:

ตัวเลขเหล่านี้สูงจริง และ Ornith-35B ยัง vendor-report ว่าเอาชนะ Qwen3.5-397B ในบาง benchmark ทั้งที่เล็กกว่ามาก (Terminal-Bench 2.1: 64.2 vs 53.5) ซึ่งเป็นสัญญาณที่น่าสนใจเรื่อง MoE efficiency แต่ต้องอ่านด้วยกรอบที่ถูกต้องสามข้อ

หนึ่ง — ตัวเลขทั้งหมดเป็น vendor-reported ทุกคะแนนในตารางข้างต้นมาจาก official DeepReinforce blog และ Hugging Face model card ณ วันที่ตรวจสอบ (2026-07-02) ยังไม่มี independent third-party reproduction ของคะแนน Ornith นี่ไม่ได้แปลว่าตัวเลขเท็จ — DeepReinforce เปิดเผย methodology ระดับพารามิเตอร์ค่อนข้างละเอียด (harness, sampling, context, timeout, จำนวนรอบเฉลี่ย) แต่ยังขาดรายละเอียดที่จำเป็นสำหรับ reproduce เต็มรูปแบบ เช่น hardware ที่ใช้ eval, dataset/harness version ที่ตรวจสอบได้ และ per-run variance

สอง — SWE-bench Pro ต้องแยก regime ให้ชัด Ornith-397B ขึ้นอันดับ 1 บน HF SWE-bench Pro leaderboard ด้วยคะแนน 62.2 แต่ leaderboard นี้เป็นระบบ self-submitted (ส่งผลผ่าน PR) third-party aggregator รายงานว่ามีเพียง "0 verified / 34 self-reported results" บน dataset เดียวกัน ขณะที่ Scale AI standardized public-set leaderboard ซึ่งเป็นคนละ evaluation regime รายงานคะแนน top frontier model อยู่ที่ประมาณ 23% เท่านั้น ตัวเลข 62.2 ของ Ornith ไม่ควรถูกนำไปเทียบตรงกับผลจาก Scale AI standardized leaderboard เพราะเป็นคนละมาตรฐานการวัดโดยสิ้นเชิง

สาม — Ornith ไม่ได้ชนะทุกอย่าง ในตาราง flagship comparison เดียวกันที่ DeepReinforce เผยแพร่เอง Claude Opus 4.8 ยังนำใน SWE-bench Verified (87.6 vs 82.4) และ Terminal-Bench 2.1 (85.0 vs 77.5) ส่วน GLM-5.2 นำใน Terminal-Bench บาง variant Ornith-397B ควรถูกมองเป็น SOTA-style result เฉพาะในกรอบ "open-source/open-weight รุ่นขนาดใกล้เคียงกัน" ไม่ใช่ผู้ชนะทุก metric เหนือทุก frontier model

6. Deployment Reality: 9B, 35B, 397B

การเลือกขนาดโมเดลควรเริ่มจากคำถามว่า "hardware ที่มีคืออะไร" มากกว่า "อยากได้คะแนนสูงสุด"

Ornith-1.0-9B เหมาะกับ laptop, edge device และการทดสอบเร็ว ๆ บนการ์ดจอผู้บริโภคใบเดียว (8-16GB VRAM) เหมาะกับงาน single-file coding, bug fix ง่าย ๆ และ quick local test แต่ไม่เหมาะกับ multi-file refactoring ที่ซับซ้อนหรือ workflow แบบ autonomous เต็มรูปแบบ

Ornith-1.0-35B คือ local PoC candidate ที่น่าสนใจที่สุดในตระกูล ด้วย GGUF Q4_K_M ที่ 21.2 GB มันพอดีกับเครื่องระดับ RTX 4090/5090 24GB หรือ Mac/AMD unified memory รุ่นใหญ่ แต่ต้องระวังเรื่อง context length: ยิ่งเปิด context ยาว KV cache ยิ่งกินหน่วยความจำเพิ่มจากขนาดไฟล์โมเดลเปล่า ๆ มาก สำหรับงานที่ต้อง context 64K-128K ขึ้นไป ควรมองหา GPU class 48GB หรือ multi-GPU

Ornith-1.0-397B เป็นของ research lab หรือ enterprise GPU node ไม่ใช่ workstation ทั่วไป ตัวอย่าง serving ทางการใช้ tensor parallel 8 GPU ร่วมกับ context 262,144 tokens — นี่คือ scale ที่ต้องมี GPU cluster และงบ serving รองรับจริง ไม่ใช่เป้าหมายสำหรับทีมที่อยากรันบนเครื่องเดียว

สำหรับ path การ deploy: GGUF ผ่าน Ollama หรือ LM Studio เหมาะกับ workstation/edge test ทั้งสองช่องทางยืนยันใช้งานได้จริงแล้ว แต่ยังมี template-handling risk ที่ต้องระวัง (อธิบายในหัวข้อถัดไป) ส่วน vLLM (v0.19.1+) และ SGLang (v0.5.9+) ผ่าน BF16/FP8 คือ path ที่แนะนำสำหรับการทดสอบระดับองค์กร เพราะตรงกับเงื่อนไขที่ vendor ใช้วัด benchmark มากที่สุด และช่วยหลีกเลี่ยงปัญหาการจัดการ GGUF template ได้ทั้งหมด

7. Risk and Governance

ก่อนพา Ornith-1.0 เข้าไปใกล้ระบบงานจริง มีความเสี่ยงที่ต้องรู้และวางแผนรับมือล่วงหน้า

Benchmark overread risk — ความเสี่ยงที่ทีมจะอ่านตัวเลข vendor-reported แล้วสรุปเป็น production capability ทันที ทางแก้คือติด evidence tier label ทุกครั้งที่อ้างตัวเลข (vendor-reported / vendor-submitted leaderboard / anecdotal) และรัน internal reproduction ก่อนอ้างอิงต่อ

GGUF template-handling risk — มีรายงานปัญหา repetition loop ที่เชื่อมโยงกับ tokenizer.chat_template metadata ที่ขาดหรือไม่ถูกต้องใน official GGUF บาง artifact ต้นตอที่แท้จริงยังไม่ถูกยืนยันร้อยเปอร์เซ็นต์ ควรมองเป็น confirmed deployment-compatibility risk ที่ต้องทดสอบเป็นรายอาร์ติแฟกต์ ไม่ใช่ bug ที่แก้เสร็จแล้ว ทางแก้คือใช้ --jinja พร้อม chat-template file ใน llama.cpp, ใช้ Modelfile ที่ embed template ใน Ollama, หรือเลือก path vLLM/SGLang ที่ไม่พึ่ง GGUF เลย

Tool-call / JSON fragility risk — ผู้ใช้รายงานปัญหา JSON parsing ใน strict harness และ multi-line bash command ที่บางครั้งมีปัญหา ยังไม่มี independent reproduction ที่ยืนยัน pattern นี้ชัดเจนพอ แต่ควรอยู่ใน test matrix ของทุก PoC

License review ยังจำเป็นเสมอ — แม้ Ornith จะเป็น MIT และฐาน Qwen 3.5/Gemma 4 จะยืนยันเป็น Apache 2.0 แล้วก็ตาม แต่นี่คือการยืนยัน license ไม่ใช่การเคลียร์ license องค์กรยังต้องตรวจ attribution, NOTICE preservation, เงื่อนไข redistribution และ hosted-service ตามกระบวนการ OSS intake ปกติ

Sandbox, audit trail, fallback, PoC gate — สำหรับใครที่จะปล่อยให้โมเดลรัน tool-calling หรือ shell command จริง ต้องมี sandbox isolation (Docker/gVisor/VM), filesystem allowlist ที่กัน secrets และ .env, network egress control แบบ default-deny, deterministic monitor, และ audit trail ที่บันทึกทุก prompt/tool-call/diff/test สำหรับ governance evidence ที่สำคัญไม่แพ้กันคือต้องมี fallback route ที่ทำงานได้จริงตั้งแต่วันแรกของ PoC ไม่ใช่ผูก Ornith ไว้เป็น single point of failure

8. Enterprise View: ทำไม Ornith ควรเริ่มจาก PoC ก่อนเสมอ

สำหรับทีม enterprise architecture ที่กำลังพิจารณา Ornith-1.0 คำแนะนำคือ อย่าข้ามขั้น controlled internal evaluation ไปสู่การ commit ใช้งานจริง ไม่ว่าตัวเลข benchmark จะน่าดึงดูดแค่ไหนก็ตาม

เหตุผลไม่ใช่เพราะ Ornith ไม่ดี แต่เพราะยังไม่มีหลักฐานระดับที่องค์กรควรใช้ตัดสินใจแบบถาวร โมเดลอายุประมาณหนึ่งสัปดาห์ ยังไม่มี production track record ยังไม่มี independent benchmark reproduction และ ecosystem ของ framework (Ollama template handling, tool-call reliability) ยังอยู่ระหว่างการเก็บ maturity

แนวทาง PoC ที่แนะนำมีสี่องค์ประกอบ:

เทียบกับ baseline ที่มีอยู่จริงเสมอ ไม่ประเมิน Ornith แบบโดดเดี่ยว ต้องเทียบกับอย่างน้อย: coding model ปัจจุบันที่ใช้อยู่, โมเดล API ที่แข็งแรงกว่าเป็น quality ceiling, โมเดลเล็กกว่าเป็น cost/latency floor, และ workflow ที่มี human review เป็น baseline สำหรับงานความเสี่ยงสูง

กำหนด security boundary ตั้งแต่วันแรก sandbox isolation, filesystem allowlist, network egress control และ tool schema validator ไม่ใช่ของที่เพิ่มทีหลังได้ ต้องมีตั้งแต่ PoC run แรก

วัดด้วย test matrix ที่ครอบคลุมกว่า raw benchmark เช่น repository-level coding บน private repo issue ที่รู้ผลลัพธ์ที่ถูกต้อง, tool-call reliability rate, prompt injection resistance, context robustness ที่ context length ต่าง ๆ, และที่สำคัญคือ cost per successful accepted patch ไม่ใช่แค่ tokens ต่อวินาที

เตรียม fallback route ให้พร้อมใช้จริง เมื่อ malformed tool-call เกินเกณฑ์ หรือเกิด security policy violation ต้องมี route สำรองที่ทดสอบแล้วว่าทำงานได้ ไม่ใช่แผนบนกระดาษ

9. สรุปส่งท้าย

Ornith-1.0 คือหนึ่งในโมเดล open-source ที่น่าติดตามที่สุดในหมวด agentic coding ตอนนี้ ด้วยการรวมกันของ MIT license, self-scaffolding RL ที่เป็นแนวทางเทรนแบบใหม่, ขนาดที่หลากหลายตั้งแต่ edge ถึง enterprise scale, และคะแนน benchmark ที่ vendor รายงานว่าแข่งขันได้กับโมเดลระดับ flagship บางตัว

แต่ความน่าสนใจนี้ต้องมาพร้อมกับความมีวินัยในการอ่านหลักฐาน: benchmark เป็น vendor-reported ยังไม่มี independent reproduction, active parameter count ของ MoE ยังไม่เปิดเผยอย่างเป็นทางการ, และ community signal ยังเป็นแค่ early interest ไม่ใช่ production validation

หมายเหตุด้าน Source Discipline

• อ้างอิงจากรายงานวิเคราะห์ภายใน "Ornith-1.0 Comprehensive Analysis Report v2.1.3a" เท่านั้น
• ตัวเลข benchmark ทั้งหมดเป็น vendor-reported จาก DeepReinforce official blog และ Hugging Face model card ยังไม่มี independent reproduction เว้นแต่ระบุไว้เป็นอย่างอื่นอย่างชัดเจน
• ข้อมูลเรื่อง LMArena/Artificial Analysis absence อ้างอิง ณ วันที่ 2026-07-03 และไม่ใช่การตรวจสอบแบบ exhaustive
• ข้อมูลเรื่อง known bug ในเส้นทาง NVFP4-AWQ อ้างอิงแหล่งข้อมูลที่เกี่ยวข้องแต่ไม่ตรงประเด็นเป๊ะ (related-not-exact) ยังคงสถานะ internally observed เท่านั้น