Morph (YC S23), áp dụng chỉnh sửa mã bằng AI với 4.500 token mỗi giây

 (news.ycombinator.com)
1 điểm bởi GN⁺ 2025-07-09 | 1 bình luận | Chia sẻ qua WhatsApp
  • Khi quá trình áp các thay đổi do công cụ lập trình AI tạo ra vào tệp hiện có trở thành nút thắt cổ chai, Morph muốn thay thế việc ghi lại toàn bộ tệp và cách tìm-đổi mong manh bằng mô hình Fast Apply
  • Agent tạo ra đầu ra chỉnh sửa lỏng giữ lại các dòng không bị sửa dưới dạng như //...existing code..., và Morph áp dụng thay đổi thực tế dựa trên tệp gốc
  • Các mô hình được cung cấp gồm morph-v3-fast đạt 4.500+ tok/sec và morph-v3-large đạt 2.500+ tok/sec, đang được dùng tại create.xyz, databutton, continue.dev
  • Với mục đích tìm kiếm, công ty cũng cung cấp mô hình embedding và reranking, đồng thời đang chuẩn bị sản phẩm tiếp theo là mô hình chỉnh sửa inline kiểu Cmd-K và Morph Tab API với độ trễ dưới 500ms
  • Đây là cách làm do Cursor đi đầu, nhưng chưa được công khai dưới dạng API; Morph nhấn mạnh API mà lập trình viên có thể tự tích hợp cùng hạn mức miễn phí lớn

Nút thắt cổ chai khi áp dụng chỉnh sửa mã bằng AI

  • Vấn đề cốt lõi mà Morph nhắm tới là quá trình chèn ổn định các thay đổi mã do AI tạo ra vào code hiện có
    • Ghi lại toàn bộ tệp có thể chậm và tốn kém
    • Cách tìm-đổi có thể dễ vỡ chỉ vì khác biệt nhỏ và dẫn tới lỗi
  • Morph thiết kế để agent xuất thay đổi theo kiểu lỏng
    • Các dòng hiện có không bị sửa sẽ được tham chiếu như // ...existing code...
    • Nhận tệp gốc và bản vá lỏng làm đầu vào, rồi áp dụng chỉnh sửa thực tế bằng mô hình Fast Apply và speculative decoding
  • Mục tiêu là biến các bản vá AI thành thứ nhanh hơn, ổn định hơn và dễ dùng trong production hơn
  • Có thể xem tài liệu liên quan bên dưới

Dòng mô hình và sản phẩm tiếp theo

  • Morph cung cấp hai mô hình Fast Apply
    • morph-v3-fast: 4.500+ tok/sec
    • morph-v3-large: 2.500+ tok/sec
  • Các mô hình này được dùng để vận hành Fast Apply tại create.xyz, databutton, continue.dev
  • Công ty cũng cung cấp mô hình tìm kiếm cho embedding và reranking để hỗ trợ tìm kiếm mã
  • Các tính năng tiếp theo tập trung vào việc rút ngắn hơn nữa luồng chỉnh sửa
    • Inline Edit Model, Cmd-K: chỉnh sửa inline cực nhanh mà không làm gián đoạn luồng phát triển
    • Morph Tab API: mô hình dự đoán lần chỉnh sửa và hành động mã tiếp theo, nhắm tới độ trễ dưới 500ms và hiện đang ở beta kín
  • Morph cho rằng trong trải nghiệm lập trình viên, tốc độ suy luận thô là quan trọng, và chỉnh sửa Fast Apply tốt hơn việc ghi lại toàn bộ tệp về mặt tốc độ, chi phí và độ tin cậy
  • Khi các benchmark tác vụ hẹp bão hòa trên 99%, công ty nhận định độ phức tạp sẽ dịch chuyển từ một frontier model đơn lẻ sang các mô hình tối ưu hóa suy luận chuyên biệt

Bài viết liên quan

1 bình luận

 
GN⁺ 2025-07-09
Ý kiến trên Hacker News

  • Tôi không đồng ý với quan điểm cho rằng trong trải nghiệm lập trình, độ chính xác kém quan trọng hơn tốc độ suy luận thô. Lý do người dùng chấp nhận tok/sec chậm hơn để dùng model lớn hơn rốt cuộc vẫn là vì chất lượng code là tiêu chí số một. Với những chỉnh sửa code lớn, ví dụ 5.000 token, độ trễ khoảng 200~300ms gần như không có nhiều ý nghĩa. Bản thân tốc độ áp dụng chỉnh sửa không phải nút thắt lớn bằng chất lượng. Nếu việc rút ngắn 200ms khi thay đổi code lại được ưu tiên hơn chất lượng thì tôi hoàn toàn không đồng cảm. Nếu dùng song song 1~2 agent thì trong lúc đang review code, phần lớn chỉnh sửa đã xong rồi. Tôi tò mò tiêu chí đo chất lượng là gì, và tỷ lệ lỗi giữa model nhanh với model lớn chênh lệch bao nhiêu

    • Tôi cảm thấy nếu tốc độ suy luận nhanh hơn khoảng 50% thì nó mang lại giá trị cho workflow của tôi lớn hơn nhiều so với việc độ chính xác chỉ cải thiện ở mức một chữ số. Dù sao tôi vẫn phải tự kiểm tra các thay đổi, nên chu kỳ lặp nhanh hơn có cảm giác tốt hơn. Tuy vậy, nếu độ chính xác đủ cao đến mức tôi cần xác minh ít hơn hoặc ít thường xuyên hơn, thì lúc đó lợi thế về tốc độ suy luận gần như không còn nhiều ý nghĩa

    • Hoàn toàn đồng ý. Việc đầu tiên phải làm sau khi AI model đề xuất thay đổi code luôn là review kỹ đầu ra đó. Trong đa số trường hợp, do thiếu ngữ cảnh trong prompt hoặc vì một token cụ thể nào đó, code thường bị lặp hoặc được tạo ra sai lệch. Nếu áp dụng hàng loạt thay đổi cùng lúc thì việc debug sẽ còn khó hơn, và kiểu chèn code số lượng lớn như vậy càng tích lũy thì code càng dễ hỏng nhanh hơn tưởng tượng

    • Theo cách tôi hiểu thì đây không chỉ là mức ±300ms, mà là khoảng cách rất lớn như 300ms với 10 giây. Việc phải chờ các model lớn phản hồi rõ ràng là một ràng buộc với tôi. Hơn nữa, với các tác vụ đơn giản như vậy thì việc tiêu tốn tài nguyên là điều khá đáng tiếc. Thật ra tôi nghĩ việc áp dụng thay đổi code một cách thông minh là thứ mà môi trường lập trình truyền thống cũng xử lý được. Tôi tự hỏi liệu việc này có thực sự khó đến mức cần LLM hay không

    • Có vẻ với bạn thì thời gian review mới là nút thắt. Hiện tôi đang làm một tính năng giúp ai đó review đầu ra của code agent nhanh hơn nhiều. Nếu bạn có thời gian, tôi muốn phỏng vấn chi tiết hơn về workflow của bạn. Hãy liên hệ qua bình luận hoặc thông tin trong hồ sơ của tôi nếu thấy phù hợp

    • Tôi nghĩ cốt lõi là giúp developer giữ được trạng thái tập trung (flow). Cả lỗi lẫn độ trễ đều là những yếu tố làm đứt mạch tập trung. Kết luận là trong lập trình, chất lượng (độ chính xác) vẫn là yếu tố quan trọng nhất. Việc đánh giá chất lượng chủ yếu dùng 2 tiêu chí. Thứ nhất là hiệu năng end-to-end trên toàn bộ chuỗi từ truy vấn của người dùng đến khi hoàn thành tác vụ (bench kiểu aider); thứ hai là độ chính xác khi áp dụng thay đổi (vấn đề cú pháp/ngữ pháp, diff ở mức ký tự, v.v.). Tỷ lệ lỗi giữa model lớn và model nhanh vào khoảng 2%. Với ngôn ngữ phức tạp hoặc khó thì model lớn phù hợp hơn, và cũng có tùy chọn tự động route model phù hợp theo tác vụ

  • Tôi đã dùng microsoft copilot và thấy nó quá chậm, quá bất tiện, đặc biệt ở giai đoạn áp dụng code. Thật khó hiểu khi một nơi nhiều tài nguyên như vậy lại không train model cho tốt hơn. Yêu cầu: hãy đưa system prompt vào tài liệu chính thức để LLM có thể tạo ra diff format tốt nhất. Mỗi lần LLM được nâng cấp thì diff format lại hay thay đổi, nên lúc nào cũng phải đoán format nào là tối ưu, khá phiền. Ngoài ra, tôi vẫn chưa hiểu rõ chính sách riêng tư; nếu tôi hiểu đúng thì kể cả người dùng trả phí thì dữ liệu vẫn có thể bị lưu lại/dùng để huấn luyện đúng không. Tôi muốn biết có cách nào chỉ trả tiền cho dịch vụ mà không bị dùng dữ liệu để train hay không, không cần gọi điện. Tham khảo Morph Privacy Policy

    • Có cả tùy chọn ZDR (Zero Data Retention). Chỉ cần gửi email đến info@morphllm.com là sẽ được thiết lập. Nếu dùng Morph qua OpenRouter thì luôn là Zero Data Retention

    • Yêu cầu kiểu “đừng dùng dữ liệu của tôi để huấn luyện model” nghe hơi buồn cười. Bản chất những model này được tạo ra cũng là nhờ được train trên code của người khác. Dùng các công cụ như vậy mà lại bảo dữ liệu của mình không được dùng để train thì thực chất là một cách nghĩ ích kỷ, giống bài toán tiến thoái lưỡng nan vì lợi ích tập thể. Chính nhờ vậy mà model mới ngày càng tốt hơn

  • Tôi thử áp dụng nguyên xi ví dụ HTML trong demo chính thức tại https://morphllm.com/dashboard/playground/apply, thì dù tôi không yêu cầu thay đổi gì, CSS vẫn được thêm vào và cả phần contact cũng xuất hiện. Những nội dung này không hề có trong instruction cập nhật

    • Phát hiện rất sắc. Ví dụ HTML đã để nguyên một snippet hardcoded mà chưa bỏ comment. Giờ đã sửa rồi

  • Xét về chi phí thì tôi có cảm giác Morph đắt hơn Gemini Flash khá nhiều. Gemini flash cũng tạo code khá ổn, AI áp dụng chỉnh sửa nhanh cũng rất hay nhưng mức giá không hề dễ chịu. Ví dụ Morph v3 fast là input $1.20/M token, output $2.70/M token, còn Gemini 2.5 Flash là input $0.30/M token, output $2.50/M token (tham khảo: OpenRouter)

    • Đó là mức giá theo tùy chọn giữ lại 0 dữ liệu. Giá chính thức trên website Morph là input $0.80 / 1M token, output $1.20 / 1M token. Cũng có chính sách giảm giá cho khối lượng lớn / reserved instance

  • Tôi hỏi để tránh nhầm: Morph là công cụ “áp dụng” đầu ra của các LLM khác, chứ không phải LLM riêng của họ đúng không. Tức là con số 4.500 token mỗi giây là tốc độ áp dụng chứ không phải tốc độ sinh token đúng không

    • Đúng. Nhưng bản thân Morph cũng là một LLM. Trên thực tế, kiến trúc là một LLM lớn dùng một LLM nhỏ như kiểu tool call

  • Rất ấn tượng. Tôi đang tìm một giải pháp như thế này cho hệ thống AI coding nội bộ, nên muốn hỏi so với các dự án như Osmosis Apply 1.7B mã nguồn mở thì khác biệt ở đâu. Tôi hiểu là model của Morph không phải open source/open weight

    • Tốt nhất là bạn nên tự dùng thử cả hai! Model của chúng tôi vượt trội rõ rệt về tốc độ và độ chính xác

  • Trước đây tôi không thấy Morph trên OpenRouter, nhưng giờ có vẻ đã lên rồi. Tuy nhiên model được đăng ký trông như là phiên bản cũ? Có kế hoạch hỗ trợ tích cực hơn không. Ngoài ra tôi cũng tò mò benchmark so sánh model fast apply với Relace hay Llama/Cerebras về hiệu năng, đặc biệt là độ chính xác

    • Sức mạnh của Hacker News thật đáng nể! Giờ các model mới cũng đã được đăng ký ở đó

    • Hiện model v2 đang trỏ tới morph-v3-large. Sắp tới sẽ thêm cả v3-large và v3-fast

  • Tôi tò mò về so sánh với Relace. Cả hai đều là công ty từ YC và chức năng trông cũng khá giống nhau Relace

    • Câu hỏi hay. Danh sách khách hàng cũng hiển thị giống nhau (create.xyz, continue.dev)

  • Nếu có một browser extension làm cầu nối giữa ChatGPT và VSCode, rồi chèn Morph (hoặc Claude) vào giữa để tận dụng agentic coding trực tiếp từ web UI thì sẽ rất tuyệt. Ý tưởng là dùng web interface thay vì API

    • Có thể đạt mục đích này bằng MCP. Sắp ra mắt rồi

  • Nếu AI có thể tự động hóa thông minh việc rebase+merge thì tốc độ phát triển sẽ tăng vọt. Nếu AI hiểu được cả ý đồ đằng sau thay đổi code của nhiều người dùng và tự động merge thì đúng là tăng năng suất cực lớn

    • Nếu dùng Claude Code thì bạn đã có thể làm vậy rồi. Chỉ cần yêu cầu “hãy merge nhánh khác và xử lý conflict giúp tôi” là được

    • Tôi tò mò bạn gặp tình huống merge conflict thường xuyên đến mức nào