Morph (YC S23) ใช้การแก้ไขโค้ดด้วย AI ที่ความเร็ว 4,500 โทเค็นต่อวินาที

 (news.ycombinator.com)
1 คะแนน โดย GN⁺ 2025-07-09 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • เมื่อกระบวนการนำการเปลี่ยนแปลงที่สร้างโดยเครื่องมือเขียนโค้ดด้วย AI ไปใส่ในไฟล์เดิมกลายเป็นคอขวด Morph จึงพยายามใช้ Fast Apply model เพื่อแทนที่การเขียนไฟล์ใหม่ทั้งไฟล์และการค้นหา-แทนที่ที่เปราะบาง
  • เอเจนต์จะสร้าง เอาต์พุตการแก้ไขแบบหลวม โดยเว้นบรรทัดที่ไม่ได้แก้ไว้ในลักษณะ //...existing code... แล้ว Morph จะนำการเปลี่ยนแปลงจริงไปใช้โดยอิงจากไฟล์ต้นฉบับ
  • โมเดลที่มีให้คือ morph-v3-fast ที่ 4,500+ tok/sec และ morph-v3-large ที่ 2,500+ tok/sec ซึ่งถูกใช้ใน create.xyz, databutton, continue.dev เป็นต้น
  • สำหรับการค้นหา มีโมเดล embedding และ reranking ให้ใช้ด้วย และผลิตภัณฑ์ถัดไปที่กำลังเตรียมคือโมเดลแก้ไขแบบ inline สไตล์ Cmd-K และ Morph Tab API ที่มี latency ต่ำกว่า 500ms
  • แม้ Cursor จะเป็นผู้บุกเบิกแนวทางนี้ก่อน แต่ไม่ได้เปิดเป็น API ขณะที่ Morph ชู API ที่นักพัฒนาสามารถนำไปเชื่อมใช้เองได้โดยตรง พร้อม free tier ขนาดใหญ่

คอขวดของการนำการแก้ไขโค้ดด้วย AI ไปใช้

  • ประเด็นหลักที่ Morph ให้ความสำคัญคือกระบวนการแทรกการเปลี่ยนแปลงโค้ดที่ AI สร้างขึ้นเข้าไปในโค้ดเดิมอย่างเสถียร
    • การเขียนไฟล์ใหม่ทั้งไฟล์อาจช้าและมีต้นทุนสูง
    • วิธีค้นหา-แทนที่เปราะบางแม้กับความแตกต่างเล็กน้อย และอาจเกิดข้อผิดพลาดได้
  • Morph ออกแบบให้เอเจนต์ ส่งออกการเปลี่ยนแปลงแบบหลวม
    • บรรทัดเดิมที่ไม่ได้แก้ไขจะถูกอ้างอิงในลักษณะ // ...existing code...
    • รับไฟล์ต้นฉบับและแพตช์แบบหลวมเป็นอินพุต แล้วใช้ Fast Apply model ร่วมกับ speculative decoding เพื่อนำการแก้ไขจริงไปใช้
  • เป้าหมายคือทำให้แพตช์จาก AI เร็วขึ้น เสถียรขึ้น และอยู่ในรูปแบบที่ใช้งานในโปรดักชันได้ง่ายขึ้น
  • ดูข้อมูลที่เกี่ยวข้องได้ด้านล่าง

ไลน์อัปโมเดลและผลิตภัณฑ์ถัดไป

  • Morph มี Fast Apply model ให้ใช้สองแบบ
    • morph-v3-fast: 4,500+ tok/sec
    • morph-v3-large: 2,500+ tok/sec
  • โมเดลเหล่านี้ถูกใช้เพื่อขับเคลื่อน Fast Apply ใน create.xyz, databutton, continue.dev เป็นต้น
  • สำหรับการค้นหาโค้ด ยังมี โมเดลค้นหา สำหรับ embedding และ reranking ให้ใช้ร่วมกันด้วย
  • ฟีเจอร์ถัดไปมุ่งไปที่การทำให้โฟลว์การแก้ไขสั้นลงยิ่งขึ้น
    • Inline Edit Model, Cmd-K: การแก้ไขแบบ inline ที่เร็วมาก โดยไม่รบกวนโฟลว์การพัฒนา
    • Morph Tab API: โมเดลที่คาดการณ์การแก้ไขโค้ดและแอ็กชันถัดไป โดยตั้งเป้า latency ต่ำกว่า 500ms และปัจจุบันอยู่ในช่วง private beta
  • Morph มองว่าความเร็ว inference ดิบมีความสำคัญต่อประสบการณ์นักพัฒนา และการแก้ไขแบบ Fast Apply ดีกว่าการเขียนไฟล์ใหม่ทั้งไฟล์ในด้านความเร็ว ต้นทุน และความน่าเชื่อถือ
  • เมื่อ benchmark สำหรับงานเฉพาะทางแคบ ๆ อิ่มตัวที่ระดับมากกว่า 99% ความซับซ้อนจะย้ายจาก frontier model เดี่ยวไปสู่ โมเดลที่ปรับแต่ง inference เฉพาะทาง

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

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

 
GN⁺ 2025-07-09
ความคิดเห็นใน Hacker News

  • ฉันค่อนข้างไม่เห็นด้วยกับข้ออ้างที่ว่าในประสบการณ์ของนักพัฒนา ความแม่นยำสำคัญกว่าความเร็วในการอนุมานดิบ ผู้ใช้ยอมทน tok/sec ที่ช้ากว่ามากเพื่อใช้โมเดลที่ใหญ่กว่า ก็เพราะคุณภาพของโค้ดเป็นเกณฑ์อันดับแรกอยู่ดี สำหรับการแก้โค้ดขนาดใหญ่ (เช่น 5,000 โทเค็น) ความหน่วงระดับ 200~300ms แทบไม่มีนัยสำคัญ ความเร็วในการ apply edit เองไม่ใช่คอขวดเท่ากับคุณภาพ ถ้าการลดเวลา 200ms ตอนเปลี่ยนโค้ดสำคัญกว่าคุณภาพ ฉันไม่เห็นด้วยเลย ถ้าใช้เอเจนต์ 1~2 ตัวแบบขนาน ระหว่างที่กำลังรีวิวโค้ด การแก้ส่วนใหญ่ก็มักเสร็จไปแล้ว อยากรู้ว่าใช้เกณฑ์อะไรในการวัดคุณภาพ และอัตราความผิดพลาดต่างกันแค่ไหนระหว่างโมเดลเร็วกับโมเดลใหญ่

    • ฉันรู้สึกว่าถ้าความเร็วในการอนุมานเร็วขึ้นราว 50% มันมีคุณค่าต่อ workflow ของฉันมากกว่าการที่ความแม่นยำดีขึ้นเพียงเลขหลักเดียวเสียอีก ยังไงฉันก็ต้องตรวจการเปลี่ยนแปลงด้วยตัวเองอยู่แล้ว ดังนั้นรอบการทำซ้ำที่เร็วขึ้นจึงรู้สึกดีกว่า แต่ถ้าความแม่นยำสูงพอจนต้องตรวจน้อยลงหรือไม่ต้องตรวจบ่อย แบบนั้นข้อได้เปรียบเรื่องความเร็วในการอนุมานก็แทบไม่มีความหมาย

    • เห็นด้วยทั้งหมด หลังจากที่โมเดล AI เสนอการเปลี่ยนแปลงโค้ดแล้ว สิ่งแรกที่ต้องทำเสมอคือรีวิวผลลัพธ์นั้นอย่างละเอียด ในกรณีส่วนใหญ่ โค้ดมักซ้ำหรือถูกสร้างออกมาผิดทิศทางเพราะบริบทที่ขาดไปในพรอมป์ต์หรือโทเค็นบางตัว ถ้า apply การเปลี่ยนแปลงรวดเดียว การดีบักจะยิ่งยากขึ้น และยิ่งมีการแทรกโค้ดจำนวนมากสะสมแบบนี้ โค้ดก็ยิ่งมีโอกาสพังเร็วกว่าที่คิด

    • เท่าที่ฉันเข้าใจ มันไม่ใช่แค่ระดับ ±300ms แต่เป็นช่องว่างใหญ่มากอย่าง 300ms กับ 10 วินาที การรอคำตอบจากโมเดลขนาดใหญ่แบบนี้เป็นข้อจำกัดชัดเจนสำหรับฉัน นอกจากนี้ยังรู้สึกเสียดายที่ใช้ทรัพยากรเกินจำเป็นกับงานง่าย ๆ แบบนี้ จริง ๆ แล้วงานอย่างการ apply การเปลี่ยนโค้ดอย่างชาญฉลาดเป็นสิ่งที่สภาพแวดล้อมการเขียนโปรแกรมเดิมก็จัดการได้อยู่แล้ว ฉันเลยสงสัยว่างานแบบนี้ยากถึงขั้นต้องใช้ LLM จริงหรือ

    • สำหรับคุณ เวลาที่ใช้รีวิวน่าจะเป็นคอขวด ฉันกำลังสร้างฟีเจอร์ที่ช่วยให้คนรีวิวผลลัพธ์จากโค้ดเอเจนต์ได้เร็วขึ้นมากในตอนนี้ ถ้ามีเวลา ฉันอยากสัมภาษณ์รายละเอียด workflow ของคุณเพิ่มเติม ถ้าสะดวก ช่วยติดต่อมาทางคอมเมนต์หรือช่องทางติดต่อในโปรไฟล์ของฉันได้เลย

    • ประเด็นสำคัญคือการที่นักพัฒนายังคงอยู่ในสภาวะลื่นไหล (flow) ทั้งข้อผิดพลาดและความหน่วงล้วนเป็นปัจจัยที่ทำให้หลุดจาก flow สรุปแล้ว ในการเขียนโค้ด คุณภาพ (ความถูกต้อง) คือปัจจัยที่สำคัญที่สุด การประเมินคุณภาพใช้เกณฑ์หลัก 2 อย่าง อย่างแรกคือประสิทธิภาพแบบ end-to-end ตลอดเส้นทางจากคำขอของผู้ใช้จนงานเสร็จ (bench สไตล์ aider) อย่างที่สองคือความแม่นยำในการ apply (ปัญหาไวยากรณ์/ไวยากรณ์โค้ด, diff ระดับตัวอักษร เป็นต้น) อัตราความผิดพลาดระหว่างโมเดลใหญ่กับโมเดลเร็วต่างกันราว 2% ถ้าเป็นภาษาที่ซับซ้อนหรือยาก โมเดลใหญ่จะเหมาะกว่า และยังมีตัวเลือกให้ route ไปยังโมเดลที่เหมาะกับงานโดยอัตโนมัติด้วย

  • ฉันเคยใช้ microsoft copilot แล้วรู้สึกว่ามันช้าและใช้งานลำบากมาก โดยเฉพาะในขั้นตอน apply โค้ด น่าแปลกที่องค์กรที่มีทรัพยากรพร้อมขนาดนั้นกลับฝึกโมเดลให้ดีไม่ได้ คำขอคือ อยากให้ใส่ system prompt สำหรับให้ LLM สร้าง diff format ที่ดีที่สุดลงในเอกสารทางการด้วย เพราะทุกครั้งที่ LLM อัปเกรด format ของ diff มักเปลี่ยนตามไปด้วย ทำให้ต้องเดาอยู่ตลอดว่า format ไหนดีที่สุด นอกจากนี้ฉันยังไม่เข้าใจนโยบายความเป็นส่วนตัวชัดเจน จากที่ฉันตีความ หมายความว่าแม้แต่ผู้ใช้แบบเสียเงินก็ยังมีข้อมูลถูกเก็บ/นำไปฝึกใช่ไหม อยากรู้ว่ามีวิธีจ่ายเงินใช้บริการโดยไม่ต้องให้ข้อมูลถูกนำไปฝึกไหม (โดยไม่ต้องโทรศัพท์) อ้างอิง Morph Privacy Policy

    • มีตัวเลือก ZDR(Zero Data Retention) ได้เช่นกัน ส่งอีเมลมาที่ info@morphllm.com แล้วเราจะตั้งค่าให้ ถ้าใช้ Morph ผ่าน OpenRouter จะเป็น Zero Data Retention เสมอ

    • ข้อเรียกร้องว่า “อย่าเอาข้อมูลของฉันไปฝึกโมเดล” ฟังดูตลกนิดหน่อย หลักการที่ทำให้โมเดลพวกนี้เกิดขึ้นก็คือการฝึกจากโค้ดของคนอื่นอยู่แล้ว การใช้เครื่องมือแบบนี้แต่บอกว่าอย่าเอาข้อมูลของฉันไปฝึก แทบจะเป็นความคิดแบบเห็นแก่ตัว คล้ายภาวะกลืนไม่เข้าคายไม่ออกของผลประโยชน์ส่วนรวม นี่แหละคือโครงสร้างที่ทำให้โมเดลดีขึ้น

  • ฉันลองเอาตัวอย่าง HTML จากเดโมทางการไป apply ตรง ๆ ที่ https://morphllm.com/dashboard/playground/apply แล้วพบว่ามีการเพิ่ม CSS และแม้แต่ section contact ทั้งที่ฉันไม่ได้ขอให้แก้อะไรเลย เนื้อหาเหล่านี้ไม่ได้อยู่ในคำสั่งอัปเดตด้วย

    • สังเกตได้เฉียบมาก ตัวอย่าง HTML มี snippet ที่ hardcode ไว้โดยยังไม่ได้ uncomment ตอนนี้แก้แล้ว

  • มองในแง่ต้นทุน Morph ดูแพงกว่า Gemini Flash มากพอสมควร Gemini flash ก็สร้างโค้ดได้ดีทีเดียว และ AI ที่ apply edit ได้เร็วก็ฟังดูดี แต่ระดับราคานี้ไม่เบาเลย ตัวอย่างเช่น Morph v3 fast ราคาอินพุต $1.20/M โทเค็น เอาต์พุต $2.70/M โทเค็น ขณะที่ Gemini 2.5 Flash ราคาอินพุต $0.30/M โทเค็น เอาต์พุต $2.50/M โทเค็น (อ้างอิง: OpenRouter)

    • นั่นเป็นราคาสำหรับตัวเลือกเก็บข้อมูลเป็น 0 ราคาอย่างเป็นทางการบนเว็บไซต์ Morph คืออินพุต $0.80 / 1M โทเค็น และเอาต์พุต $1.20 / 1M โทเค็น นอกจากนี้ยังมีส่วนลดสำหรับการใช้งานปริมาณมาก/อินสแตนซ์แบบจองล่วงหน้าด้วย

  • ถามเผื่อกันสับสน Morph เป็นเครื่องมือสำหรับ “apply” ผลลัพธ์จาก LLM อื่นใช่ไหม ไม่ใช่ LLM ของตัวเอง? หมายถึง 4,500 โทเค็นต่อวินาทีเป็นอัตราการ apply ไม่ใช่อัตราการสร้างใช่ไหม

    • ใช่ แต่ Morph เองก็เป็น LLM ด้วย ในความเป็นจริงเป็นโครงสร้างที่ LLM ขนาดใหญ่ใช้ LLM ขนาดเล็กเหมือนการทำ tool call

  • น่าประทับใจมาก ฉันกำลังมองหาโซลูชันแบบนี้สำหรับระบบ AI coding ภายในองค์กร อยากรู้ว่าถ้าเทียบกับโปรเจกต์โอเพนซอร์สอย่าง Osmosis Apply 1.7B แล้วต่างกันอย่างไร โดยตั้งต้นว่ารุ่นของ Morph ไม่ใช่โอเพนซอร์ส/โอเพนเวต

    • แนะนำให้ลองใช้ทั้งสองตัวด้วยตัวเอง! โมเดลของเรานำกว่าอย่างชัดเจนทั้งด้านความเร็วและความแม่นยำ

  • ก่อนหน้านี้ฉันไม่เคยเห็น Morph บน OpenRouter แต่ตอนนี้เหมือนจะมีแล้ว อย่างไรก็ตามโมเดลที่ลงทะเบียนดูเหมือนเป็นเวอร์ชันเก่า? มีแผนจะสนับสนุนให้มากกว่านี้ไหม แล้วก็อยากรู้ผล benchmark เปรียบเทียบโมเดล fast apply กับ Relace หรือ Llama/Cerebras ในด้านประสิทธิภาพ (โดยเฉพาะความแม่นยำ)

    • พลังของ Hacker News น่าทึ่งจริง ๆ! ตอนนี้โมเดลใหม่ก็ถูกลงทะเบียนที่นั่นแล้ว

    • ตอนนี้โมเดล v2 ชี้ไปที่ morph-v3-large อยู่ อีกไม่นานจะเพิ่ม v3-large และ v3-fast ด้วย

  • อยากรู้ว่าเทียบกับ Relace แล้วเป็นอย่างไร ทั้งคู่เป็นบริษัทจาก YC และฟีเจอร์ก็ดูคล้ายกันมาก Relace

    • เป็นคำถามที่ดี รายชื่อลูกค้า (create.xyz, continue.dev) ก็แสดงซ้ำกันเหมือนกัน

  • ถ้ามี browser extension ที่เป็นสะพานระหว่าง ChatGPT กับ VSCode แล้วแทรก Morph (หรือ Claude) ไว้ตรงกลางเพื่อใช้ agentic coding ผ่านเว็บ UI ได้เลย น่าจะดีมาก ไอเดียคือใช้เว็บอินเทอร์เฟซแทน API

    • ใช้ MCP ก็ทำได้ตามเป้าหมายนี้ กำลังจะเปิดตัวเร็ว ๆ นี้

  • ถ้า AI ช่วยทำ rebase+merge แบบอัตโนมัติอย่างชาญฉลาดได้ น่าจะช่วยเร่งความเร็วการพัฒนาได้แบบก้าวกระโดด ถ้า AI เข้าใจเจตนาของการแก้โค้ดจากผู้ใช้หลายคนแล้วรวมให้อัตโนมัติได้จริง นั่นคงเพิ่มผลิตภาพอย่างมาก

    • ถ้าใช้ Claude Code คุณใช้ฟีเจอร์นั้นได้อยู่แล้ว แค่สั่งว่า “ช่วย merge อีก branch และแก้ conflict ให้หน่อย” ก็พอ

    • คุณเจอสถานการณ์ merge conflict บ่อยแค่ไหน