Ornith-1.0 - โมเดลโอเพนซอร์สแบบปรับปรุงตัวเองสำหรับการเขียนโค้ดเชิงเอเจนต์

 (github.com/deepreinforce-ai)
2 คะแนน โดย GN⁺ 3 시간 전 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • Ornith-1.0 เป็นโมเดลโอเพนซอร์สแบบปรับปรุงตัวเองสำหรับการเขียนโค้ดเชิงเอเจนต์ โดยมีตัวเลือก 9B Dense, 31B Dense, 35B MoE และ 397B MoE และผ่านการ post-train บน Gemma 4 และ Qwen 3.5
  • เฟรมเวิร์กการฝึกใช้ reinforcement learning เพื่อให้โมเดลเรียนรู้ไม่เพียงการสร้าง solution rollout แต่ยังรวมถึงการสร้าง scaffold ที่นำทาง rollout ด้วย ทำให้สามารถปรับเหมาะทั้ง scaffold และโซลูชันผลลัพธ์ไปพร้อมกัน
  • ตาม README, Ornith-1.0 ทำผลงานระดับ state-of-the-art เมื่อเทียบกับโมเดลโอเพนซอร์สขนาดใกล้เคียงกันบนโค้ดดิ้งเบนช์มาร์กอย่าง Terminal-Bench 2.1, SWE-Bench, NL2Repo และ OpenClaw
  • ทุก checkpoint เปิดใช้ อินเทอร์เฟซที่เข้ากันได้กับ OpenAI และรองรับ context window 256K โทเค็น พร้อมใช้งานผ่าน vLLM, SGLang, Hugging Face Transformers, llama.cpp, Ollama และอื่น ๆ
  • ใช้ไลเซนส์ MIT และเข้าถึงได้ทั่วโลกโดยไม่มีข้อจำกัดตามภูมิภาค อีกทั้งยังสามารถแยก reasoning block และการเรียกใช้เครื่องมือผ่าน reasoning_content และ tool_calls เพื่อนำไปเชื่อมกับ agent framework และ coding CLI ได้

ภาพรวมโมเดลและวิธีการฝึก

  • Ornith-1.0 เป็นตระกูลโมเดลโอเพนซอร์สแบบปรับปรุงตัวเองสำหรับการเขียนโค้ดเชิงเอเจนต์
  • ขนาดโมเดลที่มีให้คือ 9B Dense, 31B Dense, 35B MoE และ 397B MoE โดยผ่านการ post-train บน Gemma 4 และ Qwen 3.5
  • เฟรมเวิร์กการฝึกแบบปรับปรุงตัวเอง ใช้ reinforcement learning
    • โมเดลถูกฝึกให้สร้างไม่เพียง solution rollout แต่ยังรวมถึง scaffold ที่นำทาง rollout ด้วย
    • มีการปรับเหมาะทั้ง scaffold และโซลูชันผลลัพธ์ร่วมกัน เพื่อค้นหาเส้นทางการค้นหาที่ดีกว่าและโซลูชันที่มีคุณภาพสูงกว่า
  • ไลเซนส์คือ MIT ใช้งานได้ทั่วโลกและไม่มีข้อจำกัดตามภูมิภาค

ผลลัพธ์เบนช์มาร์ก

  • แต่ละโมเดลถูกเปรียบเทียบกับโมเดลอ้างอิงที่เหมาะกับขนาดของตน และทั้งสามโมเดลใช้ harness และ decoding setting เดียวกัน

  • Ornith-1.0-9B

    • บน Terminal-Bench 2.1 ทำได้ 43.1 ตามเกณฑ์ Terminus-2 และ 40.6 ตามเกณฑ์ Claude Code
    • ทำได้ SWE-bench Verified 69.4, SWE-bench Pro 42.9, SWE-bench Multilingual 52
    • ทำได้ NL2Repo 27.2, Claw-eval Avg 63.1
    • สำหรับ SWE Atlas ทำได้ QnA 17.9, RF 16.6, TW 15.3

  • Ornith-1.0-35B

    • บน Terminal-Bench 2.1 ทำได้ 64.2 ตามเกณฑ์ Terminus-2 และ 62.8 ตามเกณฑ์ Claude Code
    • ทำได้ SWE-bench Verified 75.6, SWE-bench Pro 50.4, SWE-bench Multilingual 69.3
    • ทำได้ NL2Repo 34.6, Claw-eval Avg 69.8
    • สำหรับ SWE Atlas ทำได้ QnA 37.1, RF 29.7, TW 27.8

  • Ornith-1.0-397B

    • บน Terminal-Bench 2.1 ทำได้ 77.5 ตามเกณฑ์ Terminus-2 และ 78.2 ตามเกณฑ์ Claude Code
    • ทำได้ SWE-bench Verified 82.4, SWE-bench Pro 62.2, SWE-bench Multilingual 78.9
    • ทำได้ NL2Repo 48.2, Claw-eval Avg 77.1
    • สำหรับ SWE Atlas ทำได้ QnA 41.2, RF 42.6, TW 39.1

การตั้งค่าการประเมิน

  • การประเมิน Terminal-Bench 2.1 Terminus-2 ใช้เฟรมเวิร์ก Harbor/Terminus-2, parser=json, temperature=1.0, top_p=1.0 และ context window 128K
    • แต่ละรันมี timeout 4 ชั่วโมง ใช้ 32 CPU cores, RAM 48GB และคิดค่าเฉลี่ยจาก 5 รอบ
    • Qwen chat template ถูกปรับเพื่อความสอดคล้องระหว่างการฝึกและการอนุมาน และ Harbor ถูกแก้ไขให้สอดคล้องกับคีย์ reasoning_content ของ vLLM
  • การประเมิน Terminal-Bench 2.1 Claude Code ใช้ Claude Code 2.1.126, parser=json, temperature=1.0, top_p=1.0, max_new_tokens=131072 และคิดค่าเฉลี่ยจาก 5 รอบ
  • SWE-bench Verified / Pro / Multilingual ใช้ OpenHands harness, temperature=1.0, top_p=0.95 และ context window 256K
  • SWE Atlas QnA / RF / TW ใช้ mini-SWE-agent harness, temperature=1.0, top_p=0.95 และ context window 128K พร้อมคิดค่าเฉลี่ยจาก 5 รอบ
  • NL2Repo ใช้ temperature=1.0, top_p=1.0, context 400K, output 48K และ anti-hacking filters
  • ClawEval เป็น agentic code benchmark ที่อิงการกระจายตัวของงานผู้ใช้จริง โดยใช้ temperature=0.6 และ context 256K

การรันและ checkpoint

  • Ornith-1.0 เป็น reasoning model และโดยปกติ assistant turn จะเริ่มด้วยบล็อก <think> … </think> ก่อนส่งคำตอบสุดท้าย
  • สูตรการเสิร์ฟโมเดลเปิดใช้ reasoning parser เพื่อคืนค่า chain-of-thought ในฟิลด์ reasoning_content แยกต่างหาก และเปิดใช้ tool-call parser เพื่อแสดงบล็อก <tool_call> เป็น tool_calls แบบสไตล์ OpenAI
  • เวอร์ชันรันไทม์ที่ต้องการมีดังนี้
    • Transformers ≥ 5.8.1
    • vLLM ≥ 0.19.1
    • SGLang ≥ 0.5.9
  • พารามิเตอร์การสุ่มตัวอย่างที่แนะนำคือ temperature=0.6, top_p=0.95, top_k=20
    • หากต้องการทำซ้ำการตั้งค่าเบนช์มาร์กที่รายงานไว้ ให้ใช้ temperature=1.0
  • ทุก checkpoint เปิดใช้อินเทอร์เฟซที่เข้ากันได้กับ OpenAI แบบเดียวกัน และรองรับ context window 256K หรือ 262,144 โทเค็น
    • Dense 9B เหมาะกับ GPU 80GB เดี่ยว
    • checkpoint แบบ MoE ถูก shard ข้ามหลาย GPU node ด้วย tensor parallelism
  • checkpoint ที่มีให้
    • Ornith-1.0-9B: Dense ราว 9B, bf16, สำหรับการเสิร์ฟบน GPU เดี่ยวและการ fine-tune
    • Ornith-1.0-9B-GGUF: Dense ราว 9B, quantized แบบ GGUF, สำหรับ local inference บน llama.cpp / Ollama
    • Ornith-1.0-35B: MoE 35B, bf16, สำหรับการเสิร์ฟแบบ full-precision บนหลาย GPU
    • Ornith-1.0-35B-FP8: MoE 35B, FP8, สำหรับการเสิร์ฟบน GPU ที่รองรับ FP8 เพื่อลดการใช้ VRAM ลงประมาณครึ่งหนึ่ง
    • Ornith-1.0-35B-GGUF: MoE 35B, quantized แบบ GGUF, สำหรับ local inference บน llama.cpp / Ollama
    • Ornith-1.0-397B: MoE 397B, bf16, สำหรับการเสิร์ฟแบบ full-precision บนหลาย GPU node
    • Ornith-1.0-397B-FP8: MoE 397B, FP8, สำหรับการเสิร์ฟที่ประหยัดหน่วยความจำบน GPU ที่รองรับ FP8

OpenAI-compatible API และการใช้งานแบบเอเจนต์

  • เมื่อรันเซิร์ฟเวอร์ vLLM หรือ SGLang แล้ว สามารถเรียก endpoint /v1/chat/completions ผ่านไคลเอนต์ที่เข้ากันได้กับ OpenAI ได้
  • ตัวอย่าง local server ใช้ base_url="http://localhost:8000/v1";, api_key="EMPTY", model="Ornith-1.0"
  • ในข้อความตอบกลับ reasoning_content จะเก็บ trace การให้เหตุผลจาก <think> และ content จะเก็บคำตอบสุดท้าย
  • หากส่งเครื่องมือไปด้วย Ornith-1.0 จะสร้าง function call ที่มีรูปแบบถูกต้อง และเซิร์ฟเวอร์จะแปลงเป็นฟิลด์มาตรฐาน tool_calls
  • OpenAI-compatible SDK สามารถใช้ endpoint เดียวกันได้ทั้งใน Python, Node.js, curl และอื่น ๆ

เฟรมเวิร์กที่รองรับและ coding CLI

  • Ornith-1.0 ถูกปรับให้เหมาะกับการเรียกใช้เครื่องมือและความสามารถการเขียนโค้ดเชิงเอเจนต์
  • เนื่องจากให้ทั้ง OpenAI-compatible endpoint และการเรียกใช้เครื่องมือ จึงสามารถใช้ร่วมกับ agent framework มาตรฐานได้
  • ใน README มีตัวอย่างการเชื่อมเครื่องมือผ่าน MCP server และตัวอย่างการเรียกใช้ฟังก์ชัน run_shell
  • harness และ runtime แบบเอเจนต์ที่ยกตัวอย่างมีดังนี้
    • Hermes Agent: ตั้งค่า OPENAI_BASE_URL, OPENAI_API_KEY, MODEL="Ornith-1.0"
    • OpenHands: ใช้พาธ openai/Ornith-1.0 ของ LiteLLM และ local base URL
    • llama.cpp / Ollama: โหลดบิลด์ GGUF ของ 9B และ 35B เพื่อทำ local inference
    • Unsloth Studio: ใช้ FastLanguageModel.from_pretrained สำหรับ local inference หรือ fine-tune
    • OpenClaw: กำหนด OpenAI-compatible endpoint ให้ชี้ไปยังเซิร์ฟเวอร์ Ornith
  • coding CLI สามารถเชื่อมต่อได้โดยตั้ง OPENAI_BASE_URL และ OPENAI_API_KEY ให้ชี้ไปยัง endpoint ของ Ornith-1.0
  • ตัวอย่าง OpenCode ลงทะเบียน local provider ของ Ornith ใน ~/.config/opencode/opencode.json และใช้โมเดล Ornith-1.0

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 3 시간 전
ความเห็นจาก Hacker News

  • การพูดคุยก่อนหน้า: https://news.ycombinator.com/item?id=48709744
    https://swelljoe.com/post/will-it-mythos/: “ประสิทธิภาพค่อนข้างไม่ดี เจอบั๊กได้แค่ตัวเดียวที่แทบทุกรุ่นหาเจอ แม้ว่าประสิทธิภาพบนเบนช์มาร์กอื่นเมื่อเทียบกับขนาดจะโดดเด่นก็ตาม […] แม้แต่ในแชตที่ไม่มีเครื่องมือก็ยังทำได้แย่ และมีอาการ หลอนข้อมูล ค่อนข้างหนัก ตอนนี้กำลังพยายามทำซ้ำโดยให้สิทธิ์เข้าถึงเครื่องมือครบรวมถึง bash/Python ซึ่งถ้าเป็นแบบนั้นโมเดลนี้ก็อาจแข่งขันได้”

    • แปลกดีที่ในปี 2026 ยังมีการพูดกันอย่างจริงจังว่า “ทำได้แย่ในแชตที่ไม่มีเครื่องมือ” ฉันยังไม่รู้ว่าการ fine-tune นี้ดีไหมเพราะยังไม่ได้ลองเอง แต่การเอา โมเดลแบบเอเจนต์ ไปทดสอบโดยไม่ให้เข้าถึงเครื่องมือแล้วหวังว่าจะออกมาดีนี่มันไม่สมเหตุสมผลไม่ใช่เหรอ? ไม่เข้าใจเลยว่าจริง ๆ แล้วเขาทดสอบอะไร
    • เบนช์มาร์กนั้นจัด Kimi K2.6 กับ K2.7 Code ไว้เกือบท้ายสุด ทั้งคู่ต่ำกว่า Ornith 35B และยังให้ Gemma 4 26B สูงกว่า GLM-5.2 มากด้วย ผลลัพธ์มันไม่น่าเชื่อถือเท่าไร

  • นี่เป็น Qwen fine-tune ตัวแรกที่ไม่ได้โดนชุมชน LLM แบบรันท้องถิ่นปัดตกทันที และในบางกรณียังถูกแนะนำด้วย จากที่ลองแบบจำกัดก็ดูใช้ได้ และเสนอวิธีแก้ปัญหาการเขียนโค้ดที่สร้างสรรค์ดี ฉันไม่ได้คาดหวังให้โมเดล 9~35B สร้างแอปทั้งตัวให้ได้ด้วยการคลิกครั้งเดียว ดูเหมือนว่าคนที่บ่นส่วนใหญ่จะคาดหวังแบบนั้น

    • ในชุมชน LLM แบบรันท้องถิ่น พวก พ่อค้า crypto/NFT จากยุคก่อนหลั่งไหลเข้ามา พร้อมหิ้ววัฒนธรรมการโฆษณาเกินจริงจากชุมชนเดิมมาด้วย ทุกวันนี้ยังมีคนสายเทคนิคที่ลงลึกอยู่บ้าง แต่กำลังถูกเสียงการตลาดกลวง ๆ กลบมากขึ้นเรื่อย ๆ
    • น่าเสียดายที่มันเป็นแบบนี้มาตั้งแต่แรก การลองใช้โมเดลท้องถิ่นกับงานท้องถิ่น พร้อมมีรั้วกันพลาดที่เหมาะสม ก็ไม่ได้มีอะไรเสียหาย
      โมเดลส่วนใหญ่ เช่น Qwen, Gemma, Llama, gpt-oss ตอนนี้น่าปวดหัวมากกับการต้องไปค้นหากับดักจุกจิกอย่าง special token, โครงสร้างพรอมป์ต์, หรือสิ่งที่โมเดลชอบ แต่ถ้าฝ่าฟันจนได้พรอมป์ต์และพารามิเตอร์ที่เหมาะแล้ว คุณก็จะได้โมเดลที่ทำงานได้ดีมากใน สภาพแวดล้อมการรันแบบเอเจนต์
    • ก็ไม่ได้ดีขึ้นหรอก คนส่วนใหญ่ในชุมชน LocalLLama ไม่ค่อยชอบสิ่งนี้ มีแค่คนหน้าใหม่ไม่กี่คนที่โพสต์เรื่องนี้
    • เหมือนเราอยู่กันคนละชุมชน โมเดล Qwen เป็นหนึ่งในรุ่นที่ถูกแนะนำมากที่สุดในบรรดาโมเดลที่รันได้จริงบน ฮาร์ดแวร์ท้องถิ่น ที่คนทั่วไปพอเข้าถึงได้

  • ทำไมโมเดลแนว “self-improving” พวกนี้สุดท้ายถึงไม่พัฒนาตัวเองจนเหนือกว่าโมเดลล้ำหน้าที่สุดไปเลยล่ะ?

  • จากที่ทดสอบเอง Ornith-1.0 35B ดีกว่า Qwen-3.6 35B อยู่เล็กน้อย
    การทดสอบของฉันเป็นงานเพิ่มหรือแก้ฟีเจอร์ในโค้ดเบส C++ ขนาดใหญ่ สิ่งที่น่าสนใจคือโมเดลนี้เร็วกว่า Qwen3.6 35B มาก ดูเหมือน Ornith จะสร้างกระบวนการคิดที่สั้นกว่า
    ในการทดสอบของฉัน มันสร้างคำตอบได้เร็วกว่าเดิมสูงสุด 3 เท่า ใช้งานผ่าน llamacpp และ codex-cli

  • ฉันทดสอบ Ornith-1.0 35B ด้วย FP8 block quantization ที่ทำเองแล้วชอบมาก บน RTX PRO 6000(sm120) ผ่าน vLLM ได้เกิน 200 โทเค็นต่อวินาที และช่วงไม่กี่วันที่ผ่านมาได้รันโทเค็นแคชไปมากกว่า 140 ล้านโทเค็นในงานเขียนโค้ดแบบเอเจนต์
    โดยรวมดูอยู่แถว ๆ ระหว่าง Qwen 3.6 35B-A3B กับ 27B แต่ข้อดีคือมันคิดมากเกินไปหรือติดลูปเดิมซ้ำน้อยกว่า Qwen 3.6 มาก พอดู trace ของกระบวนการคิดแล้วก็ชอบเทมเพลตแนวแยกปัญหาเป็นส่วน ๆ
    มันทำงานวิเคราะห์พื้นฐาน จัดการงาน และแก้ทั้งฝั่งฟรอนต์เอนด์/แบ็กเอนด์บางส่วนได้ดีในโค้ดเบส Go ขนาดกลาง แต่พอเป็นงานเขียนเคอร์เนลแบบตรงไปตรงมาที่ยาวขึ้นก็ชนเพดานชัดเจน ฉันลองวนประมาณ 100 รอบในสภาพแวดล้อมรัน Pi Agent แล้วมันพัง ซึ่งเป็นงานประเภทที่โมเดลเปิดที่แกร่งกว่านี้อย่าง Kimi K2.6 หรือ GLM 5.2 ทำได้

    • สำหรับขนาดโมเดลระดับนี้ ดูเหมือนว่า สภาพแวดล้อมการรัน จะสำคัญกว่า ส่วนตัวฉันย้ายจาก raw pi ไปใช้ little-coder กับ qwen3.6 27b แล้ว น่าลองดู

  • มีใครอธิบายได้ไหมว่าเกิดอะไรขึ้นตรงนี้? แค่เอา Qwen มาเปลี่ยนเปลือกหรือเปล่า? deepreinforce-ai คือใคร แล้วทำไมโมเดลนี้ถึงไม่มีอยู่บนเว็บไซต์ของพวกเขา?
    ฉันสงสัยว่ามัน self-improving ยังไง โมเดลบนดิสก์เปลี่ยนไปจริงไหม หรือแค่เก่งขึ้นระหว่างการรันในคอนเท็กซ์เดียว?

    • มันไม่ได้ self-improving ชื่อนี่ทำให้เข้าใจผิด
      เท่าที่ฉันเข้าใจคือเขาเอา Qwen กับ Gemma 4 มาฝึกด้วย reinforcement learning ของตัวเอง ไม่รู้ว่าเขารวม weight ของทั้งสองยังไง หรือจริง ๆ ใช้ Qwen เป็นฐานแล้วใช้ Gemma 4 ช่วยในกระบวนการฝึกหรือเปล่าก็ไม่แน่ใจ คำว่า “self-improving” ตรงนี้น่าจะหมายถึง กระบวนการฝึก มากกว่าวิธีที่โมเดลใช้ weight

  • พวกนี้ดูเหมือนเป็นแค่ Qwen หรือ Gemma 4 เวอร์ชันที่ ปรับแต่งเพื่อเบนช์มาร์ก

    • ถ้าเป็นแบบนั้นก็ถือว่าน่าประทับใจที่ยังดัน Qwen ซึ่งถูกปรับให้เข้ากับเบนช์มาร์กมาเยอะอยู่แล้วได้อีก

  • “dense 9B ใส่ลงใน GPU 80GB เดี่ยวได้”
    คนธรรมดาแบบพวกเราใช้ไม่ได้หรอก

    • ฟังดูแปลกนะ โมเดล 9B ปกติก็ลง GPU 24GB ได้แบบไม่ต้อง quantize แล้ว
    • ตอนนี้มีเวอร์ชัน quantized ออกมาแล้ว

  • ฉันใช้โมเดลท้องถิ่นมาเยอะแล้วและรู้สึกว่าทุกตัวเหมือนของเล่น แต่ตัวนี้ให้ความรู้สึกว่าใช้งานจริงได้ Qwen 36-A3B ก็ได้ยินมาว่าดี แต่ยังไม่ได้ลอง

  • ระบบ self-improving น่าสนใจ แต่ทำให้การติดตามที่มาและการกำกับดูแลยากขึ้นมาก ถ้าเอเจนต์สามารถเปลี่ยนพฤติกรรมของตัวเองได้เมื่อเวลาผ่านไป การเข้าใจว่าทำไมมันถึงทำแบบใดแบบหนึ่งก็จะยิ่งสำคัญขึ้นเรื่อย ๆ