Ana Sayfa Etiketler Hakkında |

Etiketli yazılar personal

Eric Jang'ın AlphaGo'yu Yeniden Kurmasını İzledim, Siz İzlemek Zorunda Kalmayın

2026-05-25
18 dk okuma3,469 kelimeartificial intelligencecomputer sciencepersonalwriting

Nisan ayında Eric Jang, AlphaGo Zero'yu sıfırdan yeniden kurmak için iki hafta harcadı ve sonucu autogo adıyla, uzun ve etkileşimli bir yazıyla birlikte internete koydu. Geçen hafta da Dwarkesh Patel ile öğrendikleri üzerine iki buçuk saatlik bir kara tahta dersine oturdu. Sohbeti bir arada tutan ana soru şu: Baskın paradigmanın policy-gradient RL ile eğitilmiş büyük dil modellerine kaydığı bir dünyada AlphaGo tarifi bize hala ne öğretebilir?Bu yazı, konuşmadaki on kavramsal bloğu, anlatıldıkları sırayla ele alıyor. Kayıttan sonra Eric'in errata olarak yayımladığı önemli bir düzeltmeyi de dahil ediyorum. Amaç, AlphaGo'nun eğitim döngüsünü bu kadar zarif yapan şeyi, neden kimsenin bunu LLM'lere temiz biçimde taşıyamadığını ve AlphaGo açısından bakınca bugünkü RL'in sınırlarının nasıl göründüğünü anlamak.Başlığın ima ettiğinin aksine, bu tür işlerle ilgileniyorsanız podcast bölümünü izlemenizi öneririm.1. Kaba kuvvet arama Go'da neden ölür?Go, Tromp-Taylor puanlaması altında alan hesabıyla karara bağlanır. Bilgisayar bilimcilerin kullandığı kural seti genelde budur, çünkü oyunun ne zaman bittiği konusunda belirsizlik bırakmaz. Bu kulağa olduğundan daha önemli geliyor: AI için terminal state'lerde temiz bir reward sinyali vardır. İnsan profesyonel oyununda bu yoktur, çünkü insanlar istifa eder.19×19 bir tahtada açılışta en fazla 361 legal hamle vardır. Taşlar hareket etmediği için branching factor her ply'de bir azalır. Tromp-Taylor altında oyunlar yaklaşık 300 ply sürer. Bu yüzden naif oyun ağacının yaklaşık $361^{300}$ yaprağı vardır; bu, gözlemlenebilir evrendeki atom sayısından daha fazla state demektir.Naif Go ağaç patlamasıSıfırdan başlayan herhangi bir Go programının karşılaştığı durum bu. Sayıp bitiremezsiniz. Hangi dalların araştırmaya değer olduğuna karar vermeniz gerekir. Eric, AlphaGo'nun kırılma noktasını birbirine bağlı iki soruya uygulanabilir bir cevap olarak çerçeveliyor: Ağacın genişliğini nasıl budarsınız, yani hangi hamleleri düşünmeye değer görürsünüz? Ve ağacın derinliğini nasıl budarsınız, yani ne zaman simülasyonu durdurup ortaya çıkan pozisyonun değerini tahmin edersiniz?AlphaGo'dan önce klasik Monte Carlo Tree Search bu ilk soruyu UCB1 (Upper Confidence Bound 1) ile ele alıyordu. Bu, şu ifadeyi maksimize eden child node'u seçen bir multi-armed-bandit sezgiseli:$$ a^* = \arg\max_{a},\Bigl[,Q(s,a) + c\sqrt{\frac{\ln N(s)}{N(s,a)}},\Bigr]. $$Veri yapılarını anlamak için netleştirmem gereken birkaç tanım:root node: tahtanın mevcut state'i.children: root'tan bir legal hamleyle ulaşılabilen state'ler.$Q(s,a)$: bu edge üzerinden ulaşılan leaf'lerin ortalama değeri.$P(s,a)$: $s$ state'inde $a$ action'ını alma olasılığı. Bu ancak policy network geldiğinde devreye girer.İlk terim exploit terimidir; bu edge üzerinden ulaşılan leaf değerlerinin online running mean'idir. İkinci terim explore bonus'udur; parent'ın visit count'u $N(s)$ ile büyür, bu child'ın visit count'u $N(s,a)$ ile küçülür. UCB1'in regret bound'ları vardır ve simülasyonları dallar arasında paylaştırmak için ilkeli bir yol verir.Sorun şu: UCB1'in hangi child'ların a priori ziyaret etmeye değer olduğuna dair hiçbir fikri yoktur. 361 aday hamle varken, erken aşamada aptal hamleleri de umut veren hamleleri de aynı şekilde örnekleyerek devasa sayıda simülasyon harcarsınız. Eric'in buradaki çerçevesi keskin: klasik MCTS her action'ı geniş bir bandit üzerinde uniform prior gibi ele alır. 10 kollu bir bandit için bu fena değildir. 361 kollu ve 300 seviye derinliğinde iç içe geçmiş bir bandit için umutsuzdur.2. PUCT ve prior neden oyunun tamamıdır?AlphaGo'nun ilk büyük değişikliği, UCB1'i PUCT (Predictor + Upper Confidence applied to Trees) ile değiştirmektir:$$ a^* = \arg\max_a,\Bigl[, Q(s,a) + c_{\text{puct}}, P(s,a),\frac{\sqrt{N(s)}}{1+N(s,a)},\Bigr]. $$PUCT formülüYeni terim $P(s,a)$, yani policy prior. Bu, $s$ üzerinde değerlendirilen neural network'ün $a$ action'ına verdiği olasılıktır ve node genişletildiği anda tree node'una tam bir kez yazılır. Formüldeki diğer her şey search-time istatistiği olarak kalır: $Q$ leaf değerlerinin running mean'i, $N(s)$ parent'ın visit count'u, $N(s,a)$ ise bu edge'in visit count'u.Yeni bir node'a ilk ziyarette $N(s,a)=0$ olduğu için explore terimi $c_{\text{puct}},P(s,a)\sqrt{N(s)}$ olur. Yüksek prior'a sahip child'lar, yani yüksek $P(s,a)$ alanlar, önce ziyaret edilir. Bir child'ı ziyaret etmeye devam ettikçe paydadaki $1+N(s,a)$ lineer büyür, paydaki $\sqrt{N(s)}$ ise sadece karekök hızında büyür. Böylece explore terimi söner ve $Q(s,a)$ devralır. Prior, child'ların hangi sırayla deneneceğini belirler; visit count'lar ne zaman denemeyi bırakacağını belirler; search yeterince kanıt topladığı anda $Q$ öne çıkar.Sıfırdan eğitilen bir Go botunda prior, hangi hamlelerin bariz aptalca olmadığına dair search-time bilgisinin neredeyse tamamını taşır. Value head ise aramayı ne zaman durduracağınızı söyler. İyi bir prior olmadan MCTS yine 361 hamlenin tamamına yayılır ve search depth asla yönetilebilir hale gelmez. Bu bölüm genişliği çözüyor; derinliği ise network'ün ikinci çıktısı olan value head çözüyor.3. İki başlı networkEric'in söylediği gibi: insanlar tahtaya bakar ve oyun bitmeden 100 hamle önce kazanma olasılığını içgüdüsel olarak hesaplar. Bir neural network bu hesabı amortize edebilir; 100 hamlelik rollout yerine tek bir forward pass koyabilir. Value head'iniz olduğunda leaf'e kadar simüle etmek zorunda kalmazsınız. Terminal olmayan herhangi bir state'te durur ve value head'in tahminine güvenirsiniz.AlphaGo'nun neural network'ü bir board state alır ve iki şey üretir:Policy head, $\pi_\theta(a\mid s)$: iyi action'lar üzerinde olasılık dağılımı. Genişliği budar.Value head, $V_\theta(s)$: bu state'ten kazanma olasılığı. Derinliği budar.AlphaGo'nun iki başlı policy ve value network'üDoğal bir soru şu: policy head gerçekten gerekli mi? Eğer $V_\theta$ herhangi bir state'ten kazanma olasılığını söylüyorsa, neden her legal hamle $a$ ile oluşan sonraki state'leri $s'$ tek tek çıkarıp, her biri için $V_\theta(s')$ hesaplayıp, en yüksek değeri veren hamleyi oynamıyoruz? Derste iki sebep geçiyor. Birincisi, bu her hamle için network'ü 361 kere forward çalıştırmayı gerektirir; policy head'in tek forward pass'i ise tüm hamle olasılıklarını birden verir. İkincisi, value üzerinden argmax tek bir nokta tahminidir. Eğitimin asıl amacı MCTS'nin hesapladığı şeyi, yani tek bir argmax'tan fazlasını, policy network'e damıtmaktır. Tek bir forward pass bir search'ü kodlayamaz.İkinci, daha mimari bir soru da şu: Alanın geri kalanı Transformer'lara geçmişken neden convolutional ResNet? Eric kendi ölçeğinde Transformer'ları denedi ve ResNet'leri geçemedi. Okuması şu: Go savaşları, yani capture'lar, ladder'lar, life-and-death problemleri yoğun biçimde lokaldir. Convolutional receptive field'lar "bu taşın yakınında ne olduğu en önemli şeydir" öncülünü kodlar ve faydalı bir lokal pattern tahta boyunca yeniden kullanılır. Daha büyük ölçeklerde Transformer'ların bu inductive bias'ı veriden öğrenebileceğini düşünüyor, ama kendi bütçesinde CNN prior kazandı.Son olarak, network sadece mevcut tahtayı görür, geçmişi görmez. Go perfect-information bir oyundur ve yalnızca $s$'ye bağlı bir Nash equilibrium strategy vardır. Poker veya Diplomacy gibi hidden-information oyunlarında elinizin değeri rakiplerin önceki blöflerine ya da ittifaklarına bağlıdır ve zaman boyunca state taşıyan bir mimariye ihtiyacınız olur. Go için buna gerek yoktur.4. Self-play ve neyin damıtıldığıNetwork ve PUCT elinizde olduğunda eğitim döngüsü basittir. Her self-play oyunundaki her hamle için agent $N$ MCTS simülasyonu yapar. Eric 200 ile 2048 arasında sayılar kullandı; üst aralık KataGo ile aynı seviyede. Bir simülasyonun dört adımı şunlardır: expand edilmemiş bir leaf'e ulaşana kadar argmax PUCT ile tree'de bir path seç; leaf'i node olarak ekleyip genişlet; leaf üzerinde network'ü çalıştırarak $P$ ve $V$ alıp değerlendir; değeri root'a geri yürütüp visit count'ları artırarak ve her edge'de $Q$'nun running mean'ini güncelleyerek back up yap.Monte Carlo Tree Search'ün dört adımıBelirli bir root'tan tüm $N$ simülasyonlar bittikten sonra agent bir hamle seçer. Eğitim sırasında root visit count'larına orantılı seçer, inference'ta argmax alır. O state için iki şeyi kaydeder: MCTS visit dağılımı $\pi_{\text{MCTS}}(\cdot\mid s)$ ve hamle sırası kendisinde olan tarafa göre final oyun sonucu $z \in {-1, +1}$. Bu tuple'lar $(s, \pi_{\text{MCTS}}, z)$ replay buffer'a gider.Eğitim de buffer üzerinde supervised learning'den ibarettir:$$ \mathcal{L}(\theta) = \underbrace{\bigl(V_\theta(s) - z\bigr)^2}{\text{value: MSE}} ;+; \underbrace{-,\pi{\text{MCTS}}(s)^\top \log \pi_\theta(\cdot\mid s)}_{\text{policy: cross-entropy}}. $$Bu kadar. Advantage estimation yok, TD (Temporal Difference) learning yok, PPO (Proximal Policy Optimization) yok, off-policy importance weight yok. Sadece MCTS visit distribution'a karşı cross-entropy loss ve oyun sonucuna karşı MSE loss; ağırlıkları zevkinize göre ölçekleyebilirsiniz.AlphaGo self-play eğitim döngüsüBirçok turdan sonra policy network, gördüğü her state'te MCTS'nin hesaplayacağı şeyi içselleştirmiş olur. Network'ten geçen forward pass'ler tek başına search distribution'a giderek yaklaşır. Bu, bir sonraki MCTS turunun daha keskin bir prior ile başladığı anlamına gelir; search daha verimli olur; visit distribution daha da keskinleşir.MCTS damıtması öncesi ve sonrası policyBunun naif winner-imitation'dan neden çok daha iyi olduğunu görebilirsiniz. MCTS ile damıtılmış policy, sadece kazanıp kazanmadığınızı öğrendiğiniz terminal pozisyonlarda değil, her state'te search'ten faydalanır. Aşağıdaki win-rate curve'leri kazancı gösteriyor: inference'ta tek bir forward pass ve hiç MCTS olmasa bile, MCTS hedefleriyle eğitilmiş bir network yalnızca oyun sonuçlarıyla eğitilmiş olandan çok daha güçlüdür. Inference'ta MCTS'yi tekrar üstüne koyduğunuzda bir artış daha alırsınız.Policy ve MCTS agent'ları için win rate curve'leriKesikli çizgi, hiç MCTS kullanmayan ham policy network'tür. Mavi çizgi, üstüne MCTS eklenmiş aynı network'tür. Kırmızı çizgi, MCTS hedefleriyle damıtılmış ve inference'ta yeniden MCTS ile kullanılan network'tür. Sıfır MCTS simülasyonunda bile damıtılmış network çok daha güçlüdür. Distillation, search'ü forward pass'in içine paketlemiştir.Eric ders boyunca AlphaGo'ya birkaç kez "zarif" diyor. Kastettiği şey bu. Her zaman supervision sinyalinin temiz ve yoğun olduğu bir rejimde çalışırsınız, çünkü MCTS ziyaret ettiğiniz her state'te size daha iyi bir label verir; sadece kazanca götüren az sayıdaki state'te değil. Podcast'in sonlarına doğru söylediği gibi: AlphaGo'da "non-zero success rate'e nasıl ulaşırım" şeklindeki exploration problemini çözmek zorunda kalmazsınız. Her adım güzel bir supervised signal üzerinde hill-climb'dır.5. Naif REINFORCE neden plateau yapar?AlphaGo/MCTS distillation'ın neden özel olduğunu görmek için ders, neyin çalışmadığına sapıyor. MCTS'yi tamamen atlayıp sadece naif policy-gradient self-play yaptığınızı varsayın: policy checkpoint'lerinden oluşan bir ligi birbirine karşı oynatın, bir tarafın kazandığı oyunları bulun ve o oyunlardaki action'ları reinforce edin.Eric'in örneği şöyle: iki denk policy 300 hamlelik 100 oyun oynuyor. Şans eseri biri 51'e 49 kazanıyor. Bu 51 galibiyetin yalnızca birinin gerçekten daha iyi bir hamleden geldiğini, diğer 50'sinin istatistiksel gürültü olduğunu düşünün. Naif REINFORCE update'i kazanan her oyundaki her action'ı yukarı ağırlıklandırmak ister. Böylece yaklaşık 30.000 gürültülü label'ın içine gömülü tek faydalı gradient elde edersiniz.Variance matematiği:$$ \hat g = R \sum_{t=1}^T S_t \quad\Rightarrow\quad \mathrm{Var}(\hat g) = \sum_t \mathrm{Var}(R S_t) + 2\sum_{i<j}\mathrm{Cov}(R S_i, R S_j), $$burada $S_t = \nabla_\theta \log \pi_\theta(y_t \mid x, y_{<t})$. $T(T-1)/2$ covariance terimi, sequence length'te $O(T^2)$ worst-case variance verir. Bu, LLM tartışmasında daha sonra ortaya çıkan "$T$'de kuadratik" noktasıdır.İşaret etmeye değer bir düzeltme. Podcast'te Eric kuadratik büyümeyi policy gradient'in multi-step formülasyonuna bağlıyor ve LLM lab'lerinin single-step RL'i bu yüzden tercih ettiğini söylüyor. Kayıttan sonra errata yayımladı: variance, gradient'i full sequence üzerinden de formüle etseniz per-token da formüle etseniz, sequence length ile kuadratik büyür. Hatta per-token reward'larınız varsa multi-step RL'in variance'ı single-step'ten daha düşüktür. LLM lab'lerinin single-step yapmasının gerçek sebebi, sadece sequence-level reward'lara sahip olmalarıdır: kod geçti mi, cevap yardımcı oldu mu? Bu yüzden per-token formülasyon size aynı şeyi verir. Çıkarım şu: uzun sequence'lerde credit assignment worst case'te kuadratik zordur; blowup'a sebep olan şey formülasyon seçimi değildir.MCTS'nin farklı yaptığı şey, credit-assignment problemini tamamen kenardan dolaşmaktır. "Bu oyun kazanıldı, bu hamleleri kopyala" demek yerine MCTS şunu der: "Ziyaret ettiğin her state'te, oynadığından daha iyi bir hamle burada." Ziyaret edilen her state yoğun bir supervision target olur. Sinyali gürültüden kazıp çıkarmanız gerekmez.Klasik RL variance düzeltmeleri, yani advantage estimation $R(a) - b(s)$, TD learning ve Generalized Advantage Estimation, return'den ortalama performans tahminini çıkararak variance'ı azaltmaya çalışır. Gittikleri yere kadar doğrudurlar. Ama zaten gürültülü bir sinyalin variance'ını azaltırlar. MCTS sinyali tamamen daha yoğun bir sinyalle değiştirir.6. MCTS, NFSP ve iki yönde searchZiyaret edilen her state'e daha iyi bir action atamanın tek yolu MCTS değildir. Bir diğer seçenek de DeepMind'ın AlphaStar'ında ve OpenAI Five'da çok etkili kullanılan Neural Fictitious Self-Play (NFSP)'dir.MCTS ve NFSP search yönleriNFSP'de bir opponent $\pi_b$ sabitlenir ve ona karşı "best response" policy $\pi_a$ model-free RL ile eğitilir. PPO, V-MPO, Q-learning, hangisini isterseniz. Reward, $\pi_a$ kazanırsa 1, aksi halde 0'dır. Bunu farklı opponent'lara karşı tekrar edersiniz ve her best response'u ilgili state'ler için label sağlayıcı olarak kullanırsınız.MCTS ve NFSP aynı şeyi üretir: replay buffer'daki her state $s$ için student policy'nin taklit edeceği iyileştirilmiş bir action $a^*$. Fark, iyileştirilmiş action'ın nereden geldiğidir. MCTS simüle edilmiş geleceklerde ileri doğru rollout yapar ve hayal edilen leaf'leri score etmek için value function kullanır. NFSP terminal reward'a kadar gerçek rollout'lar yürütür, sonra win/lose sinyalini agent'ın gerçekten ziyaret ettiği state'ler üzerinden TD tarzı update'lerle geriye doğru yayar.MCTS hayal edilen trajectory'ler üzerinde ileri doğru search yapar; NFSP gerçekleşmiş trajectory'ler üzerinde geriye doğru search yaparTarif şudur: buffer'ınızdaki her state'i search ile iyileştirilmiş bir action'la etiketleyin ve bunun üzerinde supervise edin. Go'da bunu yapmanın en ucuz yolu MCTS'dir, çünkü oyun fully observable'dır ve ileri doğru simüle edebilirsiniz. Imperfect-information oyunlarında NFSP aynı şeyi geriye doğru başarır.7. MCTS neden LLM'lere aktarılmıyor?DeepSeek-R1 makalesi, LLM reasoning için MCTS'yi çalıştıramadıklarını bildirdi. Eric'in teşhisi iki yapısal başarısızlık belirliyor:Sınırsız genişlik. Go'da ply başına en fazla 361 legal hamle vardır. "Reasoning trace'te olası bir sonraki düşünce" uzayı ise fiilen sınırsızdır. PUCT'nin $\sqrt{N(s)}/(1+N(s,a))$ yapısı, aynı child'ı birkaç kez ziyaret edip $Q$ değerini rafine edeceğinizi varsayar. Dil tarafında aynı continuation'ı neredeyse hiçbir zaman iki kez örneklemezsiniz. Visit-count mekaniği dağılır.Derinlik sınırsızdır ve value head'i eğitmek zordur. Go'da $V_\theta(s)$, tam tanımlanmış bir pozisyondan tam tanımlanmış bir oyunu kazanma olasılığıdır. LLM reasoning'de yarım kalmış bir ispatın değeri nedir? Kısmen yazılmış bir fonksiyonun? Partial reasoning trajectory'leri üzerinde value head eğitmek kolay değildir, çünkü temiz bir termination condition ve temiz bir reward yoktur.Bunlardan birini telafi edebilirsiniz. İkisini aynı anda telafi etmek çok daha zordur. İnsanlar çeşitli Tree-of-Thoughts varyantlarıyla bunu denedi. PUCT, Go'nun boyutuna ve derinliğine göre ayarlanmış bir sezgiseldir. Dilin kombinatoriğine zarif biçimde ölçeklenmez.Bugünkü LLM'lerde çalışan şey, açık bir tree yapısı olmadan reasoning'e benzeyen bir şeydir: modeller bir yaklaşım dener, çalışmadığını fark eder, geri çekilir, başka bir yaklaşım dener. Bu açıkça inşa edilmekten çok eğitimden çıkmıştır. Eric, LLM reasoning'de forward search'ün geri dönme ihtimalini dışlamıyor; sadece muhtemelen token'lar üzerinde PUCT olarak değil. MuZero tarzı yöntemler continuous control'de hala zorlanıyor.Konuşmadan ilgili bir dipnot: 2021'de Andy Jones, Scaling Scaling Laws with Board Games'i yayımladı. Bu çalışma MCTS güdümlü board game'lerde training compute ile test-time compute'un öngörülebilir oranlarda takas edilebildiğini gösterdi. Bu, daha sonra o1 sınıfı reasoning modelleriyle popülerleşen test-time scaling paradigmasının, beş yıl önce bir Go botu üzerinde görülmüş haliydi. Ama sorun şu: scaling law'lar ancak alttaki tarif çalışmaya başladıktan sonra ortaya çıkar. Data'nız kötüyse veya mimariniz yanlışsa, scaling law'lar size kendinden emin ama yanlış extrapolation verir. Eric autogo'ya kısmen scaling law'larla güçlü bir Go botuna Bitter-Lesson tarzı yol alıp alamayacağını görmek için başladı. Dürüst cevabı: yapamazsınız, çünkü önce scaling law'ların fit edeceği datayı üretecek çalışan bir sisteme ihtiyacınız var.8. Off-policy training ve DAggerAlphaGo Zero'nun pratikte daha şaşırtıcı yönlerinden biri, replay buffer'ının fiilen off-policy olması ve buna rağmen çalışmasıdır. Gradient step yaptığınız zamana gelindiğinde, batch'teki çoğu (state, action) çifti policy'nin eski versiyonları tarafından üretilmiştir. RL araştırmacıları normalde bunun için endişelenir; off-policy bilinen bir instability kaynağıdır.Defterimde tanımları şöyle netleştirdim:Off-policy, agent'ın action'ları üreten policy'den farklı bir policy'yi değerlendirip iyileştirerek optimal strategy öğrenmesi demektir. Başka policy'lerin, ya da geçmiş benliklerin, yaptıklarından öğrenir. Q-learning, deep deterministic policy gradient ve soft actor-critic klasik off-policy yöntemlerdir. Sample-efficient ve exploratory'dirler, ama unstable olabilirler.On-policy, agent'ın yalnızca mevcut policy'sinin ürettiği action'lardan öğrenmesi demektir. PPO bunun kanonik örneğidir.AlphaGo Zero'daki bilmece şu: off-policy replay buffer neden stable?Cevap DAgger'dır (Dataset Aggregation; Stéphane Ross'un imitation learning çalışmasından). On-policy imitation learning'in failure mode'u, yalnızca optimal trajectory'nin state'leri üzerinde eğitilmenizdir. İlk kez yoldan saptığınızda training data'nızın kapsamadığı bir state'e düşersiniz ve hatalar birikir. DAgger training set'i, off-optimal state'leri sizi geri hunileyecek expert action ile etiketlenmiş halde ekleyerek büyütür.DAgger dataset aggregation diyagramıAlphaGo'nun replay buffer'ı doğal bir DAgger dataset'idir. Buffer'daki state'ler çoğunlukla policy'nin tipik trajectory'leri üzerindedir, arada biraz drift vardır. Buffer'daki her state, tanımı gereği kazanmaya doğru işaret eden MCTS türevi bir label taşır. Bu yüzden eski state'leri örneklediğinizde bile supervision network'e winning trajectory manifold'una doğru huni oluşturmayı öğretir.Bunu bozacak failure mode, buffer'ın mevcut policy'nin asla ziyaret etmeyeceği state'lerle dolu olmasıdır. O zaman actual play için ilgisiz state space bölgeleri üzerinde eğitim yaparsınız. AlphaGo-Zero tarzı sistemler bunu fresh self-play data karıştırarak kontrol altında tutar.Eric autogo'da bunu daha ileri götürdü: bir self-play oyununun her hamlesinde MCTS yapmak yerine, rastgele board state'leri örnekleyip her birinde mevcut network ile MCTS'yi yeniden çalıştırdığı bir deney yaptı. Bu, robotics'teki off-policy setup'a çok daha benzer; bir Bellman updater sürekli "bu state'te ne yapmalıydım?" diye yeniden düşünür. Çalışır. MCTS label'ları rastgele board state'lerinden bile winning play'e geri huniler.Bu aynı zamanda AlphaGo ile modern robotics off-policy learning arasındaki en güçlü bağlantıdır. QT-Opt ve benzeri sistemler tam olarak bunu yapar: bir pusher transition'ları replay buffer'a yazar, bir Bellman updater sürekli $Q$ target'larını yeniden hesaplar, bir trainer da bu target'lara karşı supervised regression yapar. AlphaGo, target üretmek için Bellman backup yerine search kullanır.9. RL düşündüğünüzden daha bilgi-verimsizdirPodcast'in en alıntılanabilir bölümü Dwarkesh ve Eric'in bits per sample üzerine konuştuğu yer. RL hakkındaki standart endişe sample inefficiency'dir: herhangi bir sinyal almak için bütün bir trajectory rollout etmeniz gerekir. Agent'lar çok günlük task'lara girdikçe FLOP başına sample sayısı düşmeye devam eder.Daha az takdir edilen problem bits per sample'dır. Eğitilmemiş bir LLM'in "the sky is..." prompt'u ile karşılaştığını ve vocabulary size'ın 100K olduğunu düşünün. Supervised learning altında size cevabın "blue" olduğu söylenir ve cross-entropy loss'unuz $-\log_2 p_{\text{blue}}$ olur; modeliniz "blue"ya düşük olasılık veriyorsa bu büyük bir sayıdır. RL altında ise herhangi bir sinyal almadan önce "blue"yu sample etmeniz gerekir. Random initialization ile bunu örnekleme olasılığınız kabaca $1/100{,}000$'dir. "Blue"ya bir kez denk gelmek için yaklaşık 100K sample gerekir. O ana kadar her sample size hiçbir şey öğretmez.Bits per sample karşılaştırmasıFormel olarak: pass rate $p$ iken supervised learning sample başına $-\log_2 p$ bit sağlar. $p$ çok küçükken bu büyüktür. Binary outcome üzerinde RL ise binary entropy sağlar:$$ -(p \log_2 p + (1-p)\log_2(1-p)), $$Bu ifade $p=0.5$'te tepe yapar. Yazı tura bir bittir. Her iki uçta da sıfıra gider. Eğitimin neredeyse tamamını küçük-$p$ rejiminde geçirirsiniz; bu rejimde RL sample başına neredeyse sıfır bit verirken SL çok bit verirdi.AlphaGo döngüsünün özel olmasının en derin sebebi bu. Her supervision step'i tek bir en iyi hamleye one-hot değil, visit distribution üzerinde soft target'tır. Soft target'lar sample başına one-hot label'lardan çok daha fazla bilgi taşır: dark-knowledge distillation argümanı budur. Bu yüzden AlphaGo'nun policy network'ü her adımda sample başına maksimum bit alır. MCTS mevcut policy'den kesin biçimde daha iyi bir labeler olduğu için supervision sinyali asla düzleşmez.Podcast'ten hatırlanacak cümle: AlphaGo'da policy network'ü MCTS action'ını taklit etsin diye eğitmezsiniz; MCTS distribution'ını taklit etsin diye eğitirsiniz. Action one-hot'tır; distribution yoğundur. Dark knowledge budur.Bunun çalışması için üç şeyin aynı anda doğru olması gerekir: value function ucuz ve somut olmalı, action space PUCT'nin davranabileceği kadar küçük olmalı, hızlı bir simulator olmalı. Go'da üçünün üçü de var. Coding, multi-step reasoning ve ekonomik değeri yüksek task'ların çoğunda üçte sıfır var.10. Bu automated AI research için ne anlama geliyor?Podcast'in kapanış bölümü algoritmalardan research workflow'a dönüyor. Eric autogo için coding agent'ları yoğun biçimde kullandı. Dürüst raporu şu: bugünkü frontier modeller, yol tanımlandıktan sonra hill-climbing'de iyi. Bir hyperparameter sweep çalıştırabilir, bazı layer'larda gradient'ların küçük olduğunu fark edebilir, code change önerebilir, experiment çalıştırabilir ve follow-up önerebilirler. Buna sabit bir objective üzerinde "grad-student-like" execution diyor.Henüz yapamadıkları ve Eric'in tekrar tekrar çarptığı şey lateral thinking. Mevcut yol yanlış olduğunda, metric plateau yaptığında, infra'da ince bir bug olduğunda ya da problemin framing'i yanlış olduğunda, modeller first principles'a geri çekilmek yerine yanlış eksende öğütmeye devam eder. Gerçek research insight genelde insanın "dur, bu deney dalının tamamı yanlış bir varsayımdan çıkıyor" diye fark etmesinden gelir.Bu, AlphaGo dersinin tersidir. AlphaGo çalışır çünkü MCTS policy network'e her state'te daima daha iyi bir öğretmen verir. Mevcut LLM coding agent'larının böyle bir öğretmeni yoktur. Bir reward'ları vardır, yani test geçti mi, ve gürültülü ara seçimlerle dolu uzun bir horizon'ları vardır. Eric'in iki saat boyunca anlattığı yüksek-variance, düşük-bits-per-sample rejimindedirler.Rebuild-AlphaGo egzersizinden tek bir çıkarım istiyorsanız, bence şu: bir agent'a per-state öğretmen vermeyi çözmek, yani MCTS'nin "oynadığından kesinlikle daha iyi bir action burada" eşdeğerini bulmak, sparse terminal reward'lar üzerinde RL'i ölçeklemekten muhtemelen daha yüksek kaldıraçtır. Bu öğretmenin forward search'ten mi, backward TD'den mi, daha güçlü bir modelden distillation'dan mı, yoksa henüz icat etmediğimiz bir şeyden mi geleceğini bilmiyoruz. Ama AlphaGo tarifi neyin eksik olduğunu çok net gösteriyor.Eric Jang ve Dwarkesh Patel'e teşekkürler.Eric'in etkileşimli AlphaGo tutorial'ı kanonik referanstır; tüm kod GitHub'daki autogo reposunda. Policy-gradient variance üzerine errata'sı kısa ve okumaya değer

Frontier LLM'ler Nasıl Eğitiliyor ve Sunuluyor

2026-05-03
21 dk okuma4,010 kelimeartificial intelligencecomputer sciencepersonalwriting

Frontier LLM'ler nasıl eğitiliyor ve sunuluyorBu yazı, Reiner Pope'un Dwarkesh Patel ile yaptığı kara tahta tarzı röportajdan aldığım el yazısı notlara, ayrıca yayınlanan transkript ve Dwarkesh'in bu podcast bölümü için hazırladığı flashcard'lar ile yaptığım çapraz kontrollere dayanıyor.Bunu videoyla birlikte, bir çalışma rehberi gibi açmanızı öneririm.Bazı röportajlar sohbet gibidir. Reiner Pope'un Dwarkesh ile yaptığı bölüm ise pek sohbet sayılmaz; bütün AI ekonomisinin nasıl çalıştığının, tek bir kara tahtaya sıkıştırılmış bir özeti gibi.Bu yazı boyunca aşağıdaki soruların cevaplarını öğreneceksiniz.Neden "Slow Mode" ayrı bir ürün olarak yok?Neden MoE katmanları doğal biçimde bir rack'e denk düşüyor?Neden pipeline parallelism inference tarafında aslında çok şey kazandırmıyor ve Ilya neden bunun akıllıca olmadığını söyledi?Neden frontier modeller Chinchilla optimumunun yaklaşık 100 katı ötesinde over-trained ediliyor?Gemini 3.1 neden 200K context üstünde %50 daha fazla ücret alıyor ve output token'ları neden input token'larından 5 kat pahalı?Bölüm 1: Batch size token maliyetini ve hızı nasıl etkiler?Öncelikle matematikten korkmayın. Burada tek bir ana fikir var. Bir modeli çalıştıran çip aynı anda iki şey yapıyor: hesaplama yapıyor ve veriyi hareket ettiriyor. Bunlardan biri her zaman bottleneck oluyor. Her birinin ne kadar sürdüğünü yazabilirseniz, geri kalan neredeyse her şeyi tahmin edebilirsiniz.Bütün ders tek bir eşitsizlik üzerine kurulu:$$ t ;\geq; \max!\left(t_{\text{compute}},; t_{\text{mem}}\right) $$t, bir forward pass için geçen süre.t compute ve t mem terimleri şöyle açılıyor:$$ t_{\text{compute}} = \frac{B \cdot N_{\text{active}}}{\text{FLOPS}} \quad\quad t_{\text{mem}} = \frac{N_{\text{total}} + B \cdot \text{len}{\text{ctx}} \cdot \text{bytes}{\text{tok}}}{\text{mem_bw}} $$B, batch size; başka bir deyişle tek bir forward pass sırasında canlı olan sequence sayısı. "Kullanıcı" değil. "Eş zamanlı oturum" değil. Model aynı matmul'u (matrix multiplication) bir kez çalıştırdığı anda uçuşta olan sequence'ler. N_active, aktif parameter count, yani token başına gerçekten kullanılan çarpanlar. N_total, total parameter count; yani HBM'de (High bandwidth memory) duran ve içeri çekilmesi gereken her şey.Compute terimi attention'ın kendisini ihmal ediyor; bu, bilinçli bir sadeleştirme. Memory teriminde iki alt terim var: weight fetch için sabit bir terim ve KV-cache fetch için hem batch hem context uzunluğuyla lineer artan bir terim. KV cache = B x length of context x bytes per token.mem_bw = memory bandwidthBu yazıdaki geri kalan her şey bu denklemlerden çıkıyor.Latency curveBatch size'a göre latencyCompute orijinden başlayarak lineer büyür.KV fetch de B ile lineer büyür, ama eğimi context length ve bytes per token tarafından belirlenir.Weight fetch düz bir sabittir; N_total / mem_bw. Kaç sequence'in birlikte yolculuk ettiğini umursamaz.Gerçek latency, memory terimlerinin toplamı ile compute teriminin maksimumudur. Grafikte kalın kırmızı çizgi budur: küçük batch'lerde memory curve'e sarılır, sonra compute bottleneck olduğunda compute curve'e devreder.Bu grafikten çıkan iki sonuç:1. Sert bir latency zemini vardır. Bu zemin N_total / mem_bw değeridir. Bütün weight'leri HBM'den compute unit'lere bir kez sürüklemek için gereken süreden daha hızlı servis veremezsiniz. Bu temel alt sınırdır ve LLM'lerde "Slow Mode"un ayrı bir ürün olarak gerçekten var olmamasının nedeni budur. Sağlayıcılar rekabetçi kalmak için zaten mümkün olduğunca ucuza servis veriyor ve çoğu bunun üstüne inference'ı sübvanse ediyor.2. Crossover hedef noktadır. t_KV eğimi t_compute eğimiyle eşleştiğinde aynı anda hem memory-bound hem compute-bound olursunuz. Bu noktanın iki tarafında da silikon boşta kalır. O kesişimi yakalamak operasyonel sweet spottur.Latency'den cost'a: Cost-per-token grafiğiCost, latency'den farklı bir sorudur. Müşteri süre için ödeme yapmaz; servis edilen token'lara yayılmış rental second'lar için ödeme yapar. Bu yüzden her curve'ü B'ye böleriz:Batch size'a göre token başına maliyetCompute curve lineerdi -> düz hale gelir.KV fetch lineerdi -> o da düz hale gelir.Weight fetch sabitti -> hiperbole dönüşür ve B büyüdükçe hızla düşer.B = 1 olduğunda cost sonsuza gider; tek bir token bütün weight fetch yükünü omuzlar. Büyük B değerlerinde weight fetch'ler amortize olur ve cost compute floor'a çöker.İki şey asla amortize olmaz: compute, çünkü her token kendi matmul'unu alır; KV fetch, çünkü her sequence kendi context'ini getirir.Optimal batch size'i çözmekŞimdilik KV'yi yok sayarak t_compute ile t_mem içindeki weight-fetch kısmını eşitleyelim:$$ \frac{N_{\text{total}}}{\text{mem_bw}} = \frac{B \cdot N_{\text{active}}}{\text{FLOPS}} $$Donanımı bir tarafa, modeli diğer tarafa alalım:$$ \underbrace{\frac{\text{FLOPS}}{\text{mem_bw}}}{\text{hardware}} ;=; \underbrace{\frac{B \cdot N{\text{active}}}{N_{\text{total}}}}_{\text{model}} $$FLOPS / mem_bw oranı şu soruyu sorar: Saniyede hareket ettirebildiğiniz her byte memory için çip saniyede kaç matematik işlemi yapabiliyor?Blackwell GPU'da yaklaşık olarak:FLOPS ≈ saniyede 4.500 trilyon FP4 multiplymem_bw ≈ saniyede 8 trilyon byteHer FP4 weight yarım byteYani çip, memory bandwidth'ün her byte'ı için yaklaşık 4,500 / 8 ≈ 560 multiply yapabilir. Ama her FP4 weight sadece yarım byte olduğu için 560 × 0.5 ≈ 280. Yuvarlayınca ~300. Bu sayı A100 -> H100 -> B100 boyunca pek değişmedi; FLOPS ve bandwidth birlikte ölçeklendi.O halde:$$ \boxed{;B \geq 300 \times \frac{1}{\text{sparsity}};} $$DeepSeek V3 için token başına 256 expert'in 32'si aktif, yani N_total/N_active = 8; bu da B ≥ 300 × 8 = 2,400 verir. Pratikte operatörler bunun 2-3 katı yüksek çalıştırır, çünkü gerçek verimlilik roofline'ın gerisinde kalır. Yuvarlak sayı: 2.000-3.000 token taşıyan 20 milisaniyelik bir tren.20 milisaniyelik trenNeden özellikle 20 ms? Çünkü HBM drain time, yani capacity divided by bandwidth, neredeyse her modern HBM generation'da 20 ms'dir. Rubin generation'da bu yaklaşık ~288 GB / ~20 TB/s ≈ 15 ms'ye daha yakın.Bu neden önemli? Çünkü 20 ms içinde HBM'in tamamını tam olarak bir kez okuyabilirsiniz. Bir pass içinde iki kez okumak istemezsiniz; weight matrix'leri read-only'dir ve KV cache'inizi yeniden fetch etmek istemezsiniz. Bu yüzden 20 ms doğal cycle time'dır.Bir "tren" her drain-time'da kalkar. Tren geldiğinde hazır olan sequence'ler biner. Tren dolarsa kalanlar bekler. Yarı boşsa yine de kalkar. Worst-case queueing latency: ~40 ms. Kaçırdığınız ilk tren, artı bir sonraki trene binme süresi.Concurrent users değil, tokens per second"Concurrent users" bulanık bir kavramdır; tokens per second ise nettir:$$ \text{tok/s} = \frac{B}{t_{\text{train}}} \approx \frac{2{,}000}{15\text{ms}} \approx 128{,}000;\text{tok/s} $$Gemini'nin bildirilen trafiği global ölçekte saniyede yüz milyonlarca token seviyesinde. Yani optimal batch'lenmiş tek bir serving cell, Gemini load'unun yaklaşık binde birini taşır. Bu da şu demek: ticari olarak rekabet etmek için Gemini trafiğinin en az binde birine sahip olmanız gerekir. Bunun altında treni bile dolduramazsınız.Bölüm 2: MoE modeller GPU rack'lerine nasıl yerleştirilir?İşte bir mixture-of-experts (MoE) katmanı:MoE katman yerleşimiToken'lar içeri girer, router token başına E expert'ten k tanesini aktive eder; burada E katmandaki toplam expert sayısı, k ise her token için çalışan expert sayısıdır (DeepSeek: 256'nın 32'si). k/E oranına sparsity deriz.Her expert tam bir MLP'dir (multi-layer perceptron). Basitçe söylemek gerekirse sırayla üç şey yapar: "genişlet → düşün → sıkıştır".1. Up-projection: Token'ın vector'ünü uzun bir matrix ile çarpar ve çok daha yüksek boyutlu bir alana genişletir. Token 4.000 boyutlu bir vector ise up-proj onu 16.000 dimension'a çıkarabilir.2. Nonlinearity: ReLU, GELU veya SwiGLU gibi bir fonksiyonu element-wise uygular. Bunlar farklı activation function'lardır ve şimdilik görmezden gelinebilir. Katmanın gerçekten non-trivial function'lar hesaplayabildiği yer burasıdır; nonlinearity olmadan üst üste iki matrix multiplication sadece tek bir matrix multiplication'a çökerdi.3. Down-projection: Başka bir matrix ile vector'ü yeniden orijinal dimension'a, mesela 4.000'e, indirir. Sonuç artık input ile aynı shape'tedir ve bir sonraki katmana akabilir.Seçilen expert'lerin output'ları toplanır ve bu toplam residual stream'e eklenir.Somutlaştırırsak:new_token = old_token + MoE(old_token)old_token, residual stream'dir; modelin baştan sona içinden akan running vector. MoE(old_token) bu katmanın yaptığı katkıdır. Her attention ve MLP katmanı residual stream'i okur ve katkısını geri ekler. Modelin final cevabı, bütün katmanlar yazdıktan sonra residual stream'den okunur.Standart yerleşim expert parallelism'dir: farklı expert'ler farklı GPU'lardadır. DeepSeek'te 256 expert var; bir Blackwell rack'inde 72 GPU var (bölünebilirlik için 64 kullanın, diğer sekizi yok sayın). Bu GPU başına 4 expert demek. Routing böylece all-to-all traffic pattern'e dönüşür: herhangi bir GPU'daki token, herhangi bir GPU'daki expert'e gönderilebilir.Bu yüzden tek rack doğal bir sınırdır. Rack içinde NVLink/NVSwitch her GPU'yu diğer tüm GPU'lara full bandwidth ile bağlar; all-to-all için mükemmel bir eşleşme. Rack dışına çıktığınızda scale-out network'e düşersiniz ve bandwidth yaklaşık 8 kat azalır.Scale-up vs scale-outScale-up ve scale-outÜç sağlayıcı, aynı şey için üç isim:| Sağlayıcılar | Scale-up (rack içi) | Scale-out (rack arası) | | --------- | ----------------------------- | ---------------------------- | | NVIDIA | NVLink / NVSwitch | Ethernet (RoCE) / InfiniBand | | AMD | Infinity Fabric | Ethernet / InfiniBand | | Google | Inter-Chip Interconnect (ICI) | Ethernet |Scale-up bandwidth'leri GPU başına multi-TB/s aralığındadır ve latency yüzlerce nanosaniye seviyesindedir. Blackwell NVLink yaklaşık 1.8 TB/s/GPU'dur. Scale-out ise GPU başına 400-800 Gbps'dir; Blackwell için rack içi ile dışı arasında yaklaşık 3 kat, genel bandwidth karşılaştırmasında yaklaşık 8 kat fark vardır.NVIDIA GPU'ları veriyi doğrudan bir GPU'dan diğerine gönderebilir.TPU'lar farklı route eder: TPU'lar belirli bir hedefe ulaşmak için pod içindeki tüm TPU'lardan geçmek zorundadır. TPU v4'ten (2021) başlayarak Google, TPU block'ları arasına Optical Circuit Switches ekledi; bunlar hangi block'ların fiziksel komşu olduğunu job başına dinamik olarak yeniden yapılandırır.Scale-up domain'leri neden büyümeye devam ediyor?| Generation | GPUs in scale-up | Form factor | |---|---|---| | Hopper | 8 | Tray | | Blackwell | 72 | Rack | | Rubin | ~500 | Rack (çok daha yoğun) |Hopper'dan Blackwell'e geçiş çoğunlukla bir ürün kararıydı: tray'den rack'e geçmek. Blackwell'den Rubin'e geçiş ise daha agresif cable routing ve power delivery sayesinde kabaca 4 kat density artışı. Bir rack'i sınırlayan şey power, weight, cooling ve kabloların bend radius'udur. Modern rack'ler bunların her birini fiziksel sınıra kadar iter.Makro sonuç, "model size'ları neden ancak yakın zamanda tekrar ölçeklenmeye başladı?" sorusunun cevabıdır. GPT-4'ün 2023'te trilyon civarı parameter'a sahip olduğu söylentisi vardı. Anlamlı ölçüde daha büyük modeller ise ancak son altı ayda çıkmaya başladı. Kısıt algoritma değildi; scale-up domain yeterince büyüyüp multi-trillion-param bir modeli ve binlerce sequence için KV cache'i ekonomik olarak barındırabilecek hale gelene kadar bunu servis edemezdiniz.Active parameters compute cost tarafından sınırlanır. Total parameters scale-up size tarafından sınırlanır.Google'ın erken avantajı da bu denklemdeydi: TPU pod'ları yıllardır büyük scale-up domain'lere sahipti.Bölüm 3: Pipeline parallelism, micro-batching ve bubbleExpert parallelism tek bir MoE katmanını halleder. Bir modeli tek rack'ten daha derine uzatmak için pipeline parallelism'e başvurursunuz: layer 1 rack 1'de, layer 2 rack 2'de, böyle devam eder. Tensor parallelism, yani hidden dimension veya FFN (Feed-Forward Network) dimension boyunca kesmek, prensipte üçüncü bir seçenek. Ama expert'ler artık küçük olduğu için bu matematik artık çalışmıyor. Tensor-parallel kesimler her transformer block içinde sık all-reduce / all-gather operation'ları zorlar; dimension'lar çok büyük ve interconnect çok hızlı değilse communication overhead kazanımı yer.Buna karşılık layer parallelism ve expert parallelism, modeli kendi içinde kapalı computational unit'lere böler; her device konuşmadan önce anlamlı iş yapar. Layer'lar ve expert'ler transformer'ın "chunky" dimension'larıdır ve chunky kesimler daha iyi compute-to-communication ratio verir.Pipelining scale-up'a ne zaman zarar verir?Scale-up time ile scale-out time oranını kuralım. Scale-up'ın dominate etmesini isteriz, çünkü değerli resource odur:$$ \frac{t_{\text{scale-up}}}{t_{\text{scale-out}}} ;=; \frac{1}{8},(\text{BW penalty}) ;\cdot; n_{\text{activated experts}} ;\cdot; n_{\text{layers per stage}} ;\cdot; 2 ;\geq; 1 $$2 ile çarpma, all-to-all up ve all-to-all down içindir.Üç pozitif terimin çarpımının 8 kat bandwidth penalty'yi yenmesi gerekir. Tek başına activated expert sayısı çoğu zaman 8'dir. Birkaç layer per pipeline stage ekleyince rahatça barajın üstüne çıkarsınız.Yani: rack'leri pipeline ile bağlamak forward pass için iyidir; all-to-all communication rack içinde kalır, rack sınırlarını sadece residual stream geçer.Inference: Bubble yokPipeline inferenceInference'ta backward pass yoktur. Her rack kendi layer'ını çalıştırır; token'lar ileri akar; bir rack batch 0'ı bitirdiği anda batch 1'i alır. n_micro_batches = n_pipeline_stages yaparsanız wraparound pürüzsüz olur. Bubble yok. Latency açısından bu neutraldır; layer'lar tek rack'te de yaşasa dört rack'te de yaşasa full forward pass aynı süreyi alır, çünkü pipeline stage'ler tek bir inference için sırayla çalışır. Pipelining sadece rack başına memory capacity kazandırır.Training: Bubble kaçınılmazPipeline parallelism training bubbleTraining'de pipeline'ın önce dolması, sonra boşalması gerekir. Forward pass boruyu doldurur; sonra sert bir duruşa çarparsınız (F3 ile B3 arasında), çünkü backward tüm batch'in gradient'ine aynı anda ihtiyaç duyar; sonra backward pass boruyu boşaltır. Taranmış bölgeler bubble'dır: boru dolar veya boşalırken rack'ler hiçbir şey yapmaz.Neden sert duruş var? Çünkü ML convergence için optimal batch size vardır (küçük batch'ler daha taze gradient verir) ve buna rakip olan total training time için optimum vardır (küçük batch'ler systems açısından kötüdür). Seçilen batch size bu ikisinin arasında bir yerdedir ve trade-off buradan doğar. Batch seçildikten sonra tamamını forward, sonra tamamını backward yaparsınız; bubble'ı yaratan şey de budur.Bölüm 4: Ilya neden "As we now know, pipelining is not wise" dedi?Pipeline bubble için akıllı workaround'lar var; zero bubble ve one-forward-one-backward denen schedule'lar yönleri iç içe geçirerek rack'leri meşgul tutar. Ama meşhur Ilya cümlesinin çarptığı yer burası: "As we now know, pipelining is not wise."Memory capacity rack başınadır. Modeliniz sığmıyorsa pipelining onu rack'lere bölmenizi sağlar. Ilya'nın meşhur cümlesi, bunun biriktirdiği architectural debt ile ilgilidir. Kimi'nin residual-attention'ı gibi yaklaşımlar — her block'un birden fazla önceki layer'ın residual'ına attend ettiği yapılarda — bu residual'ların aynı yerde bulunduğunu varsayar; residual'lar farklı stage'lerde yaşadığında bunu uygulamak çok zorlaşır. Interleaved sliding-window ve global attention layer'ları load imbalance yaratır. Her kısıt research iteration'ı yavaşlatır ve frontier lab'de bu büyük bir günahtır.Daha büyük memory equationSistem başına total memory:$$ \text{Capacity}{\text{mem}} ;=; N{\text{total}} ;+; B \cdot \text{len}{\text{ctx}} \cdot \text{bytes}{\text{tok}} $$GPU başına, E = expert parallelism (örneğin 64) ve P = pipelining (örneğin 4 rack) ile:$$ c_{\text{mem}} ;=; \frac{N_{\text{total}}}{E \cdot P} ;+; \frac{b \cdot \text{len}{\text{ctx}} \cdot \text{bytes}{\text{tok}}}{E} $$İkinci terimin denominator'ında sadece E olduğuna dikkat edin, E · P değil. P'ler birbirini götürür. Nasıl ve neden? Pipelining, P rack'in her birinin weight'lerin farklı bir parçasını tutmasını sağlar. Weight footprint rack başına P kadar düşer. Ama her rack, meşgul kalmak için slot'unda aynı anda P farklı sequence tutmak zorundadır; micro-batching bunu yapar. Bu yüzden KV-cache footprint rack başına micro-batch yüzünden P ile çarpılır ve cache'in stage'ler arasında sharding edilmesi yüzünden P'ye bölünür. Net sonuç sıfır.Çünkü B = n_micro · b ve n_micro = P; pipeline'ı dolu tutmak için uçuşta bu kadar micro-batch gerekir. Pipelining GPU başına weight footprint'i küçültür ama KV cache footprint için hiçbir şey yapmaz. P ≥ 2 olduğunda KV cache GPU başına dominant memory bottleneck haline gelir.Bu tam olarak DeepSeek'in V3 inference için yayınladığı reçetedir ve frontier lab'ler muhtemelen bunu yapıyor. Tek bir scale-up domain içinde expert parallelism'i maksimize et ve çok az pipelining kullan. Frontier inference muhtemelen tek bir scale-up üzerinde çalışıyor.Daha büyük scale-up'ın gizli bandwidth kazancıScale-up'ın capacity'den bile daha önemli olmasının başka bir nedeni var:$$ t_{\text{mem, weights}} = \frac{N_{\text{total}}}{\text{mem_bw}} $$Buradaki mem_bw, weight'leri paralel şekilde yükleyen tüm GPU'ların aggregate memory bandwidth'üdür; yani (scale-up size) × (per-GPU BW). Per-GPU bandwidth her generation'da yaklaşık ~1.5-2 kat büyüdü. Scale-up size ise Hopper'dan Blackwell'e 8 kat büyüdü. Latency improvement'ın çoğu daha hızlı HBM'den değil, weight yükleyen daha fazla HBM port'una sahip olmaktan geldi.Daha büyük scale-up, daha düşük latency inference sağlar ve bu da daha uzun context length'leri mümkün kılar. Hala KV-fetch term tarafından sınırlıyız; sparse attention kalite pahasına yardımcı olsa da memory wall'u kırmaz. Son iki yılda context length'lerin 100-200K civarında plato yapmasının bir nedeni de budur.Bölüm 5: Reinforcement learning ve Chinchilla'nın ötesinde over-training6ND sayısı nereden geliyor?Training cost için her tahmin, Chinchilla'nınki, GPT-4'ünki, scaling-law paper'lardaki herhangi bir tahmin, aynı formülden geçer: 6ND; burada N active parameters, D training tokens. 6'nın nereden geldiği şöyle.Tek bir multiply-add için forward pass, parameter başına token başına 2 FLOPs'tur (bir multiply + bir add). Backward pass, forward pass'in 2 katıdır; matrix multiplication'da hem input matrix'lere göre gradient hesaplarsınız. Yani backward için parameter başına token başına 4 FLOPs, toplamda 2 + 4 = 6.Üç bucket, tek cost equationModel yaşamının üç stage'i boyunca total compute cost:$$ C_{\text{total}} ;=; \underbrace{6 N_{\text{act}} D_{\text{PT}}}{\text{pre-train}} ;+; \underbrace{(2 \text{ to } 6), N{\text{act}} D_{\text{RL}} \cdot \text{ineff}}{\text{RL}} ;+; \underbrace{2 N{\text{act}} D_{\text{inf}} \cdot \text{ineff}}_{\text{inference}} $$RL coefficient 2-6 arasındadır; rollout'ların her birinde backward-pass yapıp yapmadığınıza bağlıdır. Inefficiency factor, RL rollout'larında ve inference'ta kullanılan decode'un prefill veya saf training'e kıyasla çok daha düşük MFU (Model Flops Utilization) ile çalıştığını hesaba katar.Equality heuristicTrade-off yapan maliyetlerde bir terim büyür, diğeri küçülür. Minimum çoğu zaman iki terimin eşit olduğu yerde oturur. Sezgi şudur: başka herhangi bir noktada bir tarafta, diğer tarafta tasarruf ettiğinizden daha fazla ödeme yaparsınız; yani bedava hareket alanı vardır.Hızlı örnek: f(x) = ax + b/x minimumuna x = √(b/a) noktasında ulaşır ve burada iki terim de √(ab)'ye eşittir. Bu fikir, training cost (model size ile büyür) artı inference cost (model size ile küçülür, çünkü küçük modeller daha ucuza servis edilir) gibi, büyüyen ve küçülen terimlerin toplamına gevşek biçimde genellenir.Buraya uygularsak: Frontier lab makul ölçüde iyi optimize ediyorsa üç bucket (pre-training, RL ve inference) şunu sağlamalıdır:$$ C_{\text{PT}} \approx C_{\text{RL}} \approx C_{\text{inf}} $$N_active sadeleşir. ineff ≈ 1/3 ile şuna ulaşırsınız:$$ D_{\text{PT}} \approx 1.5 \cdot D_{\text{RL}} \approx D_{\text{inf}} $$Bu üç sayı aynı mertebede olmalıdır: pre-training token'ları, RL token'ları ve lifetime inference token'ları.Bazı gerçek sayıları yerine koymakInference: Global ölçekte ~50M tokens/s, obsolete olmadan önce 2 ay deployment. -> D_inf ≈ 2.6 × 10¹⁴ tokens = (~200T).Pre-training (söylenti): ~150T tokens. Aynı mertebe. Heuristic tutuyor.Active parameters: ~100B.Chinchilla optimum: D_chinchilla ≈ 20 × N_active = 2T tokens.Frontier ratio: 200T / 2T = 100× Chinchilla ötesi.Neden artık kimse Chinchilla-optimal train etmiyor?Chinchilla, belirli bir final loss için training compute'u minimize eder. Ama production'da:Training faturası bir kez gelir. Inference faturası bütün deployment lifetime boyunca gelir.50 kat daha fazla data ile eğitilmiş daha küçük bir model, training-FLOP başına biraz daha kötüdür (çünkü Chinchilla optimum o constraint altında optimumdu), ama servis etmek çok daha ucuzdur. Bu yüzden over-train edersiniz.Sonuç: Ship ettiğiniz her model, eğittiğiniz data'nın yaklaşık olarak lifetime boyunca üreteceği data'ya eşit olduğu noktada, tam olarak yeterince büyüktür. Training corpus ve output stream yaklaşık aynı boyuttadır. Bu garip ve güzel bir simetridir ve kara tahtadaki equality heuristic'in doğrudan sonucudur.Bölüm 6: API pricing üzerinden long context memory cost çıkarmakBölüm 6, Bölüm 1'in farklı x-axis ile tekrar edilmesidir.Bölüm 1'deki latency plot'u hatırlayın. Compute batch ile lineerdi, memory küçük batch'te çoğunlukla flat sonra büyük batch'te lineerdi, ve ikisinin kesiştiği bir regime transition vardı. X-axis'i context length ile değiştirin; aynı plot, sadece döndürülmüş gibi yeniden ortaya çıkar. 200K'deki crossover, farklı bir sweep variable'a uygulanmış aynı crossover'dır. API pricing bunu takip eder, çünkü Google'ın cost'ları bunu takip eder.Gemini'de 200K crossoverGemini 3.1, 200K context length üstünde %50 daha fazla ücret alıyor. Nedeni şu:Context length'e göre maliyett_compute = B·N_act / FLOPS, len_ctx'e göre esasen flat'tir.t_mem, len_ctx ile lineer yükselir; KV-fetch term büyür.Pricing tier, alttaki cost envelope'u takip eder. Kink, memory time'ın compute time'ı geçtiği yerdir. Crossover'da:$$ \frac{B \cdot \text{len}{\text{ctx}} \cdot \text{bytes}{\text{tok}}}{\text{mem_bw}} = \frac{B \cdot N_{\text{act}}}{\text{FLOPS}} $$Bytes per token için çözelim:$$ \text{bytes}{\text{tok}} = \frac{\text{mem_bw}}{\text{FLOPS}} \cdot \frac{N{\text{act}}}{\text{len}_{\text{ctx}}} = \frac{1}{300} \cdot \frac{100\text{B}}{200\text{K}} \approx 1.7;\text{KB / tok} $$Bunu şöyle parçalayabiliriz:$$ N_{\text{bytes/tok}} = N_{\text{attn layers}} \cdot 2 \cdot d_{\text{head}} \cdot N_{\text{KV heads}} $$d_head (dimension of the vector) = 128 ve küçük bir KV-head count (1-8) ile 1.7 KB, dense attention plus heavy cross-layer KV-cache reuse ile tutarlıdır; Character.AI / Gemma trick'inde global KV bütün attention layer'ları arasında paylaşılır. Ya da sparse attention ile. Her iki durumda da pricing architectural information sızdırmış olur.Competitive pricing pressure her API tarifesini alttaki cost structure'ına oldukça sıkı bağlar; fiyatlarınız gerçek cost'larınızın çok üstüne çıkarsa, daha düşük cost'lu bir rakip margin'inizi yer.Output token'ları neden input token'larından 5 kat pahalı?Decode ve prefillPrefill tüm prompt'u paralel işler. Pass başına çok sayıda token. Highly parallelizable. Compute-limited.Decode her pass'te autoregressively tek token üretir. Her token full weights + KV cache yükler. Memory-bandwidth limited.Time-per-token chart'ta:t_compute / len_pass flat'tir.t_mem / len_pass hiperboldür.İki regime de aynı GPU'yu aynı dolara kiralar. Değişen şey, GPU'nun FLOPS budget'ının saniye başına ne kadarının gerçekten kullanıldığıdır. Prefill FLOPS'u saturate eder, compute-bound'dur. Decode ise onları underuse eder, çünkü çip HBM beklerken boşta oturur. Pricing'deki 5 kat oran, iki regime arasındaki effective FLOPS-utilization oranıdır.len_pass = 1 olduğunda (decode), memory dominate eder ve cost ≈ 5× olur. Büyük len_pass değerlerinde (prefill), curve compute floor'a çöker ve cost ≈ 1× olur.Yani pricing'deki 5× oran, iki regime arasındaki MFU ratio'yu söyler. Decode, prefill MFU'sunun yaklaşık %20'sinde çalışır.Cache hit'ler neden 10 kat ucuz?Bir token'ın KV cache'ini materialize etmek için üç yer vardır:| Strateji | Retrieval cost (token başına) | Hold cost (saniye başına) | | ------------------------------- | ----------------------------- | ------------------------------------ | | Rematerialize (recompute) | N_act / FLOPS × GPU $/s | 0 | | Store in HBM | ≈ 0 (zaten orada) | bytes_tok / HBM_capacity × GPU $/s | | Store in DDR / Flash / Disk | bytes_tok / DDR_bw | bytes_tok × DDR $/s |Optimal tier, hold time'ınızı tier'ın drain time'ına (capacity / bandwidth) eşler:| Tier | Drain time | | ------------------- | ------------ | | HBM | ~20 ms | | DDR | ~1-10 s | | Flash (SSD) | ~1 dakika | | Spinning disk (HDD) | ~18-22 saat |Bazı sağlayıcıların 5 dakikalık cache pricing VE 1 saatlik cache pricing sunması, arkadaki tier'ların flash + spinning disk olduğunu güçlü biçimde ima eder.Million-token wallNeden kimse million-token-context model ship etmiyor? Compute term attention içinde quadratic büyür, ama slope o kadar küçüktür ki bunu ancak multi-million token aralığında hissedersiniz. Asıl bağlayıcı constraint memory bandwidth'tir: context ile lineer büyüyen KV-fetch term.Sparse attention lineerliği yaklaşık √len_ctx'e çevirir (DeepSeek'in önemli bir sonucu, open source'a teşekkürler). Bu büyük bir iyileştirme, sonsuz değil; sparsity'yi fazla zorlarsanız kalite çöker.Empirically, frontier context length'ler son iki yıldır 100-200K civarında plato yaptı. Bu da bunun cost-balanced point olduğunu gösteriyor. Dario'nun continual learning'in yerini alabileceğini savunduğu türden 100M-token context'e ulaşmak için bugün var olmayan bir memory-wall breakthrough gerekir.Bölüm 7: Okunabilir AI ekonomisiMemory wall, bütün endüstrinin omurgası ve bottleneck'idir.İki roofline equation'ı ve sihirli ~300 oranını içselleştirdiğinizde, AI ekonomisinin şaşırtıcı derecede büyük bir kısmı okunabilir hale gelir:| Soru | Denklemlerin verdiği cevap | | ------------------------------------------------- | ------------------------------------------------------------------------------- | | Optimal batch size? | ~300 × sparsity | | Minimum ne kadar hızlı servis verilebilir? | N_total / mem_bw | | Frontier modeller ne kadar over-trained? | Chinchilla'nın ~100 katı ötesinde | | Gemini'nin KV cache'i token başına kaç byte? | ~1.7 KB | | Output token'ları neden input'tan 5 kat pahalı? | Decode MFU ≈ 1/5 prefill MFU | | Neden 1M-token context yok? | Memory wall'un çatısı yok | | Yavaş storage tier'lar neden pricing'de görünüyor?| Hold time'lar her tier'ın drain time'ına eşleniyor; dakikalar için flash, saatler için disk | | MoE katmanları neden rack'e denk düşüyor? | All-to-all NVLink topology ile tam olarak eşleşiyor |Benim tekrar tekrar döndüğüm şey equality result: pre-training tokens ≈ inference tokens. Ship ettiğiniz her model, kabaca, eğittiğiniz data'nın lifetime boyunca üreteceği data'ya eşit olduğu noktada tam olarak yeterince büyüktür. Training corpus ve output stream yaklaşık aynı boyuttadır. Bu garip ve güzel bir simetridir ve kara tahtadaki iki heuristic equation'ın doğrudan sonucudur.Önce ne kırılacak? Sparse attention memory wall'u kırarsa context length'ler 1M'e sıçrar. FLOPS-to-bandwidth ratio değişirse optimal batch size da onunla birlikte hareket eder.Bu bölüm Dwarkesh'ten izlediğim favori bölümdü ve Reiner Pope bu karmaşık detayları bu kadar temiz açıkladığı için büyük övgüyü hak ediyor. Her şeyin kara tahtada serilmesi de yanında çalışmak için harikaydı. (Merak etme Dwarkesh, yeni studio yatırımı kesinlikle buna değdi.)Neyse. Kapatmadan önce birkaç teşekkür.Teşekkürler Dwarkesh; farklı disiplinlerden bilgi paylaşımının teşvik edildiği ve derinlemesine incelendiği bir ortam yarattığın için. Teknik ile teknik olmayan arasındaki çizgide mükemmel yürüyorsun. Bu konudaki anlayışını ve bilgisini paylaştığı için Reiner Pope'a da teşekkürler; harika bir konuşmacı ve berrak bir düşünür

Claude Code vs. Codex

2026-01-13
7 dk okuma1,311 kelimeartificial intelligencecomputer sciencepersonalwriting

Bu noktaya kadar bir yılı aşkın süredir kodla ilgili hiçbir şeye dokunmamıştım. O zamanlar günlük araçlarım Sonnet 3.7/3.5 ile eşleştirilmiş Cursor'dı. Bu yüzden firmam için bir CRM inşa etmeye başladığımda, bana sunulan tüm yeni oyuncaklarla oynamak için sabırsızlanıyordum. Opus 4.5 çıkmıştı ve herkes ne kadar iyi olduğundan bahsediyordu.20$ ödeyip Cursor'da bir pro plan satın aldım. Geçmişte agent modunu nadiren kullanıyordum ve her zaman ask moduna bağlı kalıyordum çünkü agent modu genellikle kod tabanımı bozuyor ve istediğim sonuca ulaşmak için birkaç temizlik turu ve manuel düzenleme gerektiriyordu. Aynı şekilde davrandım ve çoğunlukla ask moduna bağlı kaldım ama Cursor, kodu inceledikten sonra değişiklikleri uygulayabilmesi için sürekli agent moduna geçmemi istiyordu. Böylece, yavaş yavaş agent modunu kullanmaya başladım.Opus 4.5 kullanarak başladım ve sonuçlardan çok memnundum. Opus hızlı ve çalışkan bir şekilde işini yapıyordu; ancak 1.5 gün sonra kullanımıma baktığımda çenem düştü. Aylık kullanım hakkımın %50'sinden fazlasını tüketmiştim. Bu hızda Opus 4.5'i Cursor'da günlük kullanmam imkansızdı. Bu yüzden ertesi gün Sonnet 4.5'e geçtim. İşte burada işler bozulmaya başladı ve model sürekli hata yapıyor veya talimatlarımı görmezden geliyordu. Ne kadar uğraşsam da 3. günde aylık kullanımımı tükettim ve daha fazla kullanmak isteseydim ödeme yapmam gerekiyordu. Composer-1'i (Cursor'ın kendi kodlama modeli) denedim ama çok eskiydi. Sayısız hata yaptı ve beni akıştan çıkardı. Composer-1 kullanırken yaptığım tüm değişiklikleri geri aldım. Opus 4.5'in yeteneklerini tatmıştım ve artık geri dönemezdim.https://x.com/cursor_ai/status/1999147953609736464Cursor'da kullanmaktan gerçekten keyif aldığım bir şey, 25 Aralık'ın 11'inde tanıttıkları görsel editördü. Web sitenizdeki bir bileşene tıklayıp doğrudan ona başvurabilir, rengini, konumunu veya boyutunu değiştirebilirdiniz. (Yukarıdaki tam demoyu görebilirsiniz.) Bu, web sitesindeki küçük şeyleri düzenlemeyi kusursuz hale getirdi. Belirli bir düğmenin nerede olduğunu bulmak için yüzlerce/binlerce satır kodu gözden geçirmeniz veya bahsettiğiniz düğmeyi bulmak için LLM'yi kötü bir şekilde yönlendirmeniz gerekmiyordu. Bileşene doğrudan başvurup LLM'ye değişiklikler için talimat verebilirdiniz.<p align="center"> <img src="/images/center-the-div-clanker.jpeg" /> </p>O sırada, Windsurf (Devin tarafından satın alındı) yeni modeli SWE-1.5 ile çıktı. Model Windsurf'te ücretsiz kullanılabiliyordu, ben de denemek için fırsata atladım. Bir gün onunla çalıştım ve Opus 4.5 tarafından şımartıldığım için standartlarıma uymadığı sonucuna vardım. Sonnet 4.5 bile susuzluğumu gideremiyordu, bu yüzden SWE-1.5'in standartlarımı karşılamaması sürpriz olmadı. O gün Windsurf'ü kaldırdım çünkü bana o noktada hiçbir değer sağlamıyordu.Zaten bir Claude aboneliğim vardı ve Claude Code'u duymuştum ama denememiştim. Bu yüzden, neden olmasın dedim ve terminalimi açıp Claude Code CLI'ı kurdum. Claude Code'da yine Opus 4.5 kullandım ama birebir aynı modeli kullanmama rağmen Cursor'dan farklı bir şey hissettim. Claude Code'un talimatlarımı çok daha iyi anladığı ve istediğim sonuçları verdiği hissine kapıldım. Bir CLAUDE.md yazdım ve CRM'in nasıl görünmesini ve hissettirmesini istediğimi, istediğim özellikleri ve güvenlik gereksinimlerini belirttim. Kullanıcı deneyimi oldukça keyifliydi - düşünürken söylediği küçük anlamsız kelimelerden, bana ipuçları ve dahili COT'unu göstermesine, renk seçimlerine kadar her şey çok hoştu.Claude Code bana net bir yapılacaklar listesi ve üzerinde çalıştığı şeyleri gösteriyordu, ayrıca mevcut kodumu nasıl değiştirdiğine dair tüm farkları da gösteriyordu. Beni en çok etkileyen şey model değildi - Cursor'da kullandığım aynı Opus 4.5'ti. Claude Code'un modelle nasıl konuştuğuydu. Başka bir deyişle, altındaki modeli yönlendiren harness. Şeffaflık da yardımcı oldu. Bir yapılacaklar listesini tamamlamasını izlemek, çalışırken yüzeye çıkan düşünce parçalarını görmek, çıktıya daha fazla güvenmemi sağladı.Ara sıra ona yürütmesi için bir talimat listesi veriyordum ve o bir yapılacaklar listesi oluşturuyordu. Yapılacaklar listesini adım adım işleyip sonra bana tüm talimatlarımı uyguladığını söylüyordu ama açıkça yalan söylüyordu. Bir görevi uygulamayı unutuyor ve bana zaten yaptığını söylüyordu ama açıkça yapmamıştı. Kusurları fark etmeye başladım. Ayrıca 5 saatlik hız limitimi 2-3 promptta tükettiğimi ve sıfırlanmasını beklemem gerektiğini fark ettim. Noel tatillerinde tüm büyük yapay zeka laboratuvarları 2x hız limiti verdi ki bu benim için harikaydı ama tatillerden sonra tekrar beklemeye ve terminale bakmaya döndüm.Bu arada hız limitlerini beklerken, sevgili Opus 4.5'ime sahip olan Antigravity'yi (Cursor'a rakip Google'ın IDE'si) indirdim. Çalışmama devam ettim ve Antigravity'de de oldukça hızlı bir şekilde hız limitlerine takıldım. Cursor kadar iyi olmasa da ücretsizdi ve piyasadaki en iyi modelleri sunuyordu (GPT-5.2 hariç). Gemini 3 Pro'yu kod tabanımda denedim ve anında her şeyi bozdu. Birkaç prompttan sonra Gemini'nin akıl sağlığı için endişelenmeye başladım. Akıl bozukluğu olan kilitli bir savaş esiri gibiydi. Antigravity'yi kapattım, Gemini'yi kitaplığa geri koydum ve geceyi bitirdim. Bir daha asla.Bu arada hız limitlerimi Opus kadar hızlı tüketmemek için Claude Code'u Sonnet 4.5 ile eşleştirmeyi denedim ama boşunaydı. Sonnet'e prompt veriyordum ve istediğim değişiklikleri yapıyordu, sonra yaptıklarını/bozduklarını düzeltmek için 2-3 kez daha prompt vermem gerekiyordu, yani baştan Opus kullansam aynı miktarda token kullanıyordum. Bu deneyimden sonra Opus'a döndüm çünkü tüm yollar aynı sonuca çıkıyordu.GPT-5.2 ile eşleştirilmiş Codex'i denemek istedim çünkü zor problemleri ele almada daha iyi olduğunu duymuştum. Bu yüzden, yapay zeka imparatorunun web sitesini açtım ve Codex'i kullanma fırsatı için 20$'ımı ödedim. Bu noktada, Opus 4.5'e Claude Code üzerinden uzun talimatlar vermekte tereddütlüydüm çünkü bazı talimatlarımı uygulamayacağını biliyordum, bu yüzden promptlarımı kısa ve öz tuttum.İlk bakışta, Codex Claude Code'dan çok daha çirkin. Eğlence yok, renkli kelime oyunları yok, sadece saf iş. Ayrıca promptlarınızda çok daha spesifik olmanız gerekiyor, söylediklerinizi ilk denemede Claude Code kadar iyi anlamıyor. Ayrıca Claude Code kadar iyi bir harness'a sahip değil ama kesinlikle bir iş makinesi. Daha iyi ve daha temiz kod yazıyor. Bu, Opus 4.5'in kodunun kötü olduğu anlamına gelmiyor ama GPT-5.2 biraz daha öne çıkıyor; ancak Opus ve Claude Code'a göre en büyük gelişme güvenilirlik. Talimatlarınızı Opus kadar unutmuyor ve bu güvenilirlik benim için çok önemli bir şey. OpenAI ayrıca hız limitleri konusunda Anthropic'e kıyasla çok daha cömert. Claude Code kullanırken anında hız limitine takılmak yerine Codex ile gerçekten makul miktarda iş yapabileceğimi hissediyorum. (Anthropic ve OpenAI, benim gibi kullanıcılara 20$'lık abonelik planında kan kaybediyor.) Aynı 20$'lık planda OpenAI'ın Anthropic'ten 4-5 kat daha fazla kullanım verdiğini söyleyebilirim. Opus ayrıca daha ayrıntılı, bu yüzden GPT-5.2'nin söylediği aynı şeyi söylemek için daha fazla token harcıyor. Uzun formatlı yazıdan bahsediyorsak Opus 4.5 daha iyi bir model.Yukarıda listelenen nedenlerden dolayı, farklı kullanımlar için hem Claude Code hem de Codex'in bir kombinasyonunu kullanıyorum. Kod tabanını yeniden düzenliyorsam veya tüm web sayfalarını ve UI bileşenlerini İngilizce'den Türkçe'ye çevirmek gibi uzun bir talimat uyguluyorsam Codex kullanıyorum. Frontend tasarlıyorsam ve UI ile uğraşıyorsam frontend-design eklentisi ile Claude Code kullanıyorum. Claude Code daha iyi bir kullanıcı deneyimi ve çok turlu konuşma sunarken, Codex zor problemlerde ve güvenilirlikte çok iyi. Her iki araç da hala talimatları uygulamayı unutuyor ve yetenekler açısından gidecek uzun bir yolları var. Bir yılda yaşanan ilerleme akıl almaz. Her zaman olduğu gibi, tekrarlamak gerekirse bu modellerin en kötü halleri. Yıllar geçtikçe daha ucuz, daha hızlı, daha zeki ve daha yetenekli olacaklar.Bu yazıyı Claude Code veya Codex'i nasıl kullanıp üretkenliğinizi 100 katına çıkaracağınız hakkında yazmadım. Sadece bu modellerden/araçlardan bir yılı aşkın süredir uzak olduğum için yeni modelleri ve yeni CLI araçlarını kullanma konusundaki kişisel deneyimlerimi yazmak istedim. Claude Code'un neler yapabileceği hakkında derinlemesine bir rehber isterseniz, Sankalp'in yüzeyin altını kazırsanız nelerin mevcut olduğunu ayrıntılı olarak anlatan iki harika makalesi var. (Skills, plugins, sub-agents, compaction, MCP, hooks vb.)https://sankalp.bearblog.dev/my-claude-code-experience-after-2-weeks-of-usage/https://sankalp.bearblog.dev/my-experience-with-claude-code-20-and-how-to-get-better-at-using-coding-agents/Unutmayın, bunların hepsi benim kişisel deneyimlerim. Sizin deneyiminiz benimkinden farklı olabilir ve bu tamamen normal.Kesilen kısımlar: Daha önce Warp terminali kullanıyordum, harikadı çünkü yerleşik yapay zeka özellikleri vardı ve terminal komutlarını otomatik olarak çalıştırıyordu. Uzun süre kullandıktan sonra ne kadar enerji tüketen bir uygulama olduğunu fark ettim. O zamandan beri Ghostty'ye geçtim ve Warp'ta bir mühendisle konuştum. Enerji kullanımının öncelik listelerinde olduğunu söyledi, bu yüzden gelecekte tekrar değerlendirebilirim. Ayrıca Mistral'in altında Devstral 2 kullanan CLI aracı Vibes'ı denedim ama dürüst olmak gerekirse adil bir değerlendirme yapacak kadar kullanmadım