Morph (YC S23), yapay zeka kod düzenlemelerini saniyede 4.500 token ile uyguluyor

 (news.ycombinator.com)
1 puan yazan GN⁺ 2025-07-09 | 1 yorum | WhatsApp'ta paylaş
  • Yapay zeka kodlama araçlarının ürettiği değişiklikleri mevcut dosyalara uygulama süreci darboğaz haline gelince, Morph Fast Apply modeli ile tüm dosyayı yeniden yazma ve kırılgan arama-değiştirme yöntemlerinin yerini almayı hedefliyor
  • Ajanlar, değiştirilmemiş satırları //...existing code... gibi bırakan gevşek düzenleme çıktıları üretiyor; Morph ise özgün dosyayı temel alarak gerçek değişiklikleri uyguluyor
  • Sunulan modeller arasında morph-v3-fast 4.500+ tok/sec, morph-v3-large ise 2.500+ tok/sec hız sunuyor ve create.xyz, databutton, continue.dev gibi ürünlerde kullanılıyor
  • Arama için embedding ve yeniden sıralama modelleri de sunuluyor; sıradaki ürünler arasında Cmd-K tarzı satır içi düzenleme modeli ile sub-500ms gecikmeli Morph Tab API bulunuyor
  • Bu yaklaşımın öncülüğünü önce Cursor yaptı, ancak bunu API olarak açmadı; Morph ise geliştiricilerin doğrudan entegre edebileceği bir API ve geniş bir ücretsiz katmanla öne çıkıyor

Yapay zeka kod düzenlemelerini uygulamadaki darboğaz

  • Morph'un temel problemi, yapay zekanın ürettiği kod değişikliklerini mevcut koda güvenilir şekilde yerleştirme süreci
    • Tüm dosyayı yeniden yazmak yavaş olabilir ve maliyeti artırabilir
    • Arama-değiştirme yaklaşımı ise küçük farklarda bile kolayca bozulup hata üretebilir
  • Morph, ajanların değişiklikleri gevşek biçimde çıktılaması için tasarlandı
    • Değiştirilmeyen mevcut satırlar // ...existing code... gibi referans veriliyor
    • Özgün dosya ve gevşek yama girdi olarak alınarak, Fast Apply modeli ve speculative decoding ile gerçek düzenleme uygulanıyor
  • Amaç, yapay zeka yamalarını daha hızlı, daha güvenilir ve üretimde kullanımı daha kolay hale getirmek
  • İlgili kaynaklara aşağıdan ulaşabilirsiniz

Model serisi ve sıradaki ürünler

  • Morph iki farklı Fast Apply modeli sunuyor
    • morph-v3-fast: 4.500+ tok/sec
    • morph-v3-large: 2.500+ tok/sec
  • Bu modeller, create.xyz, databutton, continue.dev gibi ürünlerde Fast Apply'ı çalıştırmak için kullanılıyor
  • Kod araması için embedding ve reranking amaçlı arama modelleri de birlikte sunuluyor
  • Sıradaki özellikler, düzenleme akışını daha da kısaltmaya odaklanıyor
    • Inline Edit Model, Cmd-K: geliştirme akışını bölmeyen çok hızlı satır içi düzenleme
    • Morph Tab API: bir sonraki kod düzenlemesini ve eylemleri tahmin eden model; sub-500ms gecikmeyi hedefliyor ve şu anda kapalı beta aşamasında
  • Morph'a göre geliştirici deneyiminde ham çıkarım hızı önemli ve Fast Apply düzenlemeleri, tüm dosyayı yeniden yazmaya kıyasla hız, maliyet ve güvenilirlik açısından daha iyi
  • Dar görev benchmark'ları %99'un üzerinde doygunluğa ulaştığında, karmaşıklığın tek bir frontier modelden uzmanlaşmış çıkarım optimizasyonu modellerine kaydığı düşünülüyor

İlgili okumalar

1 yorum

 
GN⁺ 2025-07-09
Hacker News görüşü

  • Geliştirici deneyiminde ham çıkarım hızından çok doğruluğun daha önemli olduğu iddiasına pek katılmıyorum. Kullanıcıların çok daha yavaş tok/sec değerlerine katlanarak daha büyük modelleri tercih etmesinin nedeni sonuçta kod kalitesinin birinci ölçüt olması. Büyük kod değişikliklerinde (ör. 5.000 token) 200~300 ms civarındaki gecikme çok anlamlı bir sayı değil. Düzenleme hızının kendisinden ziyade kalite daha büyük bir etken. Kod değişikliğinde 200 ms kısalma kalitenin önüne geçiyorsa buna hiç katılamam. 1~2 ajanı paralel kullanırsanız, siz kodu incelerken düzeltmelerin çoğu zaten tamamlanmış oluyor. Kaliteyi hangi ölçütlerle değerlendirdiğinizi ve hızlı model ile büyük model arasındaki hata oranı farkının ne kadar olduğunu merak ediyorum

    • Bana göre çıkarım hızı yaklaşık %50 artarsa, doğruluğun tek haneli bir oranda iyileşmesinden çok daha fazla değer katıyor. Sonuçta değişiklikleri zaten kendim kontrol etmek zorundayım; bu yüzden daha hızlı yineleme döngüsü bana daha iyi geliyor. Ancak doğruluk yeterince yüksek olur da daha az veya daha seyrek doğrulama yapabilecek seviyeye gelirse, o zaman çıkarım hızı avantajı neredeyse anlamsız hale gelir

    • Kesinlikle katılıyorum. Bir yapay zeka modeli kod değişikliği önerdikten sonra yapılacak ilk iş, ortaya çıkan çıktıyı mutlaka dikkatle incelemektir. Çoğu durumda prompt'ta eksik kalan bağlam ya da belirli bir token yüzünden kodun yinelendiği veya alakasız şekilde üretildiği çok oluyor. Değişiklikleri topluca uygularsanız hata ayıklama daha da zorlaşıyor ve bu tür büyük kod eklemeleri biriktikçe kod tabanının beklenenden hızlı bozulma ihtimali yükseliyor

    • Benim anladığım kadarıyla mesele sadece ±300 ms değil; 300 ms ile 10 saniye gibi çok büyük bir fark var. Bu tür büyük modellerin yanıtını beklemek benim açımdan gerçekten kısıtlayıcı oluyor. Üstelik bu kadar basit işler için gereksiz kaynak tüketimi de var. Aslında kod değişikliklerini akıllıca uygulama işi, mevcut programlama ortamlarında da gayet ele alınabilecek bir alan diye düşünüyorum. Bunun gerçekten LLM gerektirecek kadar zor bir iş olup olmadığını merak ediyorum

    • Görünüşe göre sana göre darboğaz inceleme süresi. Ben şu anda birinin kod ajanı çıktısını çok daha hızlı incelemesine yardımcı olacak bir özellik geliştiriyorum. Vaktin varsa iş akışın hakkında daha ayrıntılı bir görüşme yapmak isterim. Yorumlardan ya da profilimdeki iletişim bilgisinden bana ulaşabilirsin

    • Asıl mesele geliştiricinin flow durumunu koruması diye düşünüyorum. Hem hatalar hem de gecikmeler bu akışı bozuyor. Sonuç olarak kodlamada en önemli unsur kalite (doğruluk). Kalite değerlendirmesinde büyük ölçüde iki ölçüt kullanıyoruz. Birincisi, kullanıcının sorgusundan görevin tamamlanmasına kadar tüm hattı değerlendiren uçtan uca performans (aider tarzı bench); ikincisi ise uygulama doğruluğu (gramer/sözdizimi sorunları, karakter düzeyinde diff vb.). Büyük ve hızlı modeller arasındaki hata oranı farkı yaklaşık %2 civarında. Karmaşık ya da zor diller için büyük model daha uygun ve göreve en uygun modeli otomatik yönlendiren bir seçenek de var

  • microsoft copilot kullandım ve özellikle kod uygulama aşamasında çok yavaş ve kullanışsız geldi. Kaynakları bol bir yerde modelin düzgün eğitilememiş olması tuhaf. İstek: En iyi diff formatını LLM'nin üretebilmesi için sistem prompt'unu resmi dokümantasyona ekleseniz iyi olur. LLM her yükseltildiğinde diff formatı sık sık değişiyor; hangi formatın en iyisi olduğunu sürekli tahmin etmek zorunda kalmak yorucu. Ayrıca gizlilik politikasını tam anlayamadım; benim yorumuma göre ücretli kullanıcıların verileri de saklanıyor/eğitimde kullanılıyor mu? (Telefon olmadan) sadece hizmet için ödeme yapıp verilerimin eğitimde kullanılmamasını sağlamanın bir yolu var mı merak ediyorum. Morph Privacy Policy referans alınmıştır

    • ZDR (Zero Data Retention) seçeneği de mümkün. info@morphllm.com adresine e-posta gönderirseniz ayarlayabiliriz. Morph'u OpenRouter üzerinden kullanırsanız her zaman Zero Data Retention olur

    • “Modeli benim verilerimle eğitmeyin” talebi biraz komik bir iddia. Bu modellerin ortaya çıkma biçimi zaten başkalarının kodlarıyla eğitilmelerine dayanıyor. Bu araçları kullanırken kendi verilerimin eğitime dahil edilmesini istememek, aslında bencilce bir düşünce; bir tür kolektif fayda ikilemi gibi. Modelin daha iyi hale gelmesi de bu şekilde oluyor

  • Resmî demoda verilen HTML örneğini https://morphllm.com/dashboard/playground/apply üzerinde aynen uyguladım; hiçbir değişiklik istememiş olmama rağmen CSS eklendi, hatta bir contact bölümü oluştu. Bunlar güncelleme talimatlarında yoktu

    • Bunu çok iyi yakalamışsın. HTML örneğinde hardcoded snippet'in yorumu kaldırılmamıştı. Şimdi düzelttik

  • Maliyet açısından bakınca Morph'un Gemini Flash'tan epey pahalı olduğu izlenimi var. Gemini Flash da gayet iyi kod üretebiliyor ve düzenlemeleri hızlı yansıtan yapay zeka hoş, ama fiyat bandı hafif değil. Örneğin Morph v3 fast için input $1.20/M token, output $2.70/M token; Gemini 2.5 Flash için ise input $0.30/M token, output $2.50/M token (kaynak: OpenRouter)

    • Bu fiyatlar 0 veri saklama seçeneği için. Morph'un resmî web sitesi fiyatları input $0.80 / 1M token, output $1.20 / 1M token. Yüksek hacim/ayrılmış instance için indirim politikamız da var

  • Karışıklık olmasın diye soruyorum: Morph, başka LLM'lerin çıktısını “uygulayan” bir araç mı, yoksa kendi LLM'i de var mı? Yani saniyede 4.500 token üretmekten değil, uygulama hızından mı söz ediliyor?

    • Evet. Ama Morph'un kendisi de bir LLM. Pratikte yapı, büyük bir LLM'nin küçük bir LLM'yi araç çağrısı gibi kullanması şeklinde

  • Oldukça etkileyici. İç yapay zeka kodlama sistemimiz için böyle bir çözüm arıyoruz; açık kaynak Osmosis Apply 1.7B gibi projelerle kıyaslandığında farkı nedir merak ediyorum. Morph modelinin açık kaynak/açık ağırlık olmadığını varsayıyorum

    • En iyisi ikisini de bizzat denemeniz! Bizim modelimiz hız ve doğruluk açısından belirgin şekilde üstün

  • Daha önce Morph'u OpenRouter'da görmemiştim, şimdi eklenmiş gibi duruyor. Ancak listelenen model eski sürüm gibi? Daha aktif destekleme planınız var mı? Ayrıca fast apply modelinin Relace ya da Llama/Cerebras ile performansını, özellikle de doğruluk açısından, karşılaştıran benchmark sonuçlarını merak ediyorum

    • Hacker News'in gücü işte! Artık yeni modeller orada da listeleniyor

    • Şu anda v2 modeli morph-v3-large'a işaret ediyor. Yakında v3-large ve v3-fast da eklenecek

  • Relace ile karşılaştırmayı merak ediyorum. İkisi de YC çıkışlı şirket ve işlevleri de oldukça benzer görünüyor Relace

    • Güzel soru. Müşteri listesi bile aynı görünüyor (create.xyz, continue.dev)

  • ChatGPT ile VSCode arasında köprü kuran bir tarayıcı eklentisi olsa, araya Morph (veya Claude) konup agentic coding doğrudan web arayüzü üzerinden kullanılabilse harika olurdu. Fikir, API yerine web arayüzünü kullanmak

    • Bu amaç için MCP kullanılabilir. Çok yakında çıkıyor

  • Yapay zekanın akıllıca rebase+merge otomasyonu yapabilmesi geliştirme hızını inanılmaz artırır diye düşünüyorum. Birden çok kullanıcının kod değişikliğini, niyetlerini de anlayarak otomatik birleştirebilirse bu gerçekten büyük bir verimlilik artışı olur

    • Claude Code kullanırsanız bu özellik zaten var. Sadece “diğer branch'i birleştir ve çatışmaları çöz” demeniz yeterli

    • Merge conflict durumlarını ne sıklıkla yaşıyorsunuz?