Tek cümlelik fikirden yayındaki Short'a: 16 GB'lık tek bir ekran kartıyla uçtan uca yapay zekâ video üretimi

Kısaca

• Ne yaptım: Tek cümlelik bir fikri alıp YouTube'a yüklenmiş, yayına hazır bir Short'a dönüştüren bir sistemi tek başıma geliştirdim. Senaryo, tutarlı karakterler, animasyon, seslendirme, ses efektleri, kurgu, upscale ve SEO hep bu sistemin içinde. Masraflı her adımdan önce de benim onayımı bekliyor.
• Asıl zorluk: Her şey tek bir 16 GB'lık ekran kartında, 31 GB RAM'le ve kendi cebimden çıkan bir bütçeyle çalışmak zorundaydı. Tasarım kararlarının çoğunu donanım ve maliyet sınırları belirledi.
• Bir modeli kanıta dayanarak bıraktım: LongCat-Video yaklaşık 13 denemede de çöktü. Neden olmadığını yazıya döküp bıraktım. Yerine, LongCat'i düşüren sorunların hiçbirini yaşatmayacak olan HunyuanVideo 1.5'i seçtim.
• Ayar yapmadan önce modeli tanımak: Model cfg = 1.0'da çalıştığı için negatif prompt'lar hiçbir işe yaramıyordu. Video kısıtlarını "ne olmasın" yerine "ne olsun" diye yeniden yazdım ve kalite emeğini ilk kareye kaydırdım.
• Geçici çözüm, hatanın ta kendisi çıktı: Zayıf yerel model için yazdığım prompt kuralları, 2,36 dolarlık bir bulut render'ını çöpe çevirdi. Artık prompt'lar kullanılan backend'in gücüne göre şekilleniyor. Ücretli backend'lerde de otomatik bir maliyet freni devrede.
• "Bitti"nin dört seviyesi var: derleniyor, unit testleri geçiyor, canlıda doğrulandı, gerçek render'da doğrulandı. Henüz doğrulanmamış her şey açıkça öyle işaretleniyor.

Bir bakışta

Problem

Kısa video kanalları üretim hacmiyle ayakta durur. 60 saniyelik tek bir Short'u elle hazırlamak bile ciddi iş: senaryoyu yazacaksın, karakterleri her sahnede aynı görünecek şekilde üreteceksin, her çekimi canlandıracaksın, sesi kaydedecek ya da sentezleyeceksin, efekt ve müzik bulacaksın, hepsini kurgulayıp başlığı, açıklamayı yazacaksın. Üstelik bunu her video için baştan yapacaksın.

Benim istediğim şuydu: bir fikir yazayım, çıkan taslağa göz atayım, onaylayayım ve karşıma gerçekten yayınlayacağım kalitede bitmiş bir video gelsin. Şans eseri güzel çıkmış tek bir klip üreten bir demo değil; aynı karakterlerle tutarlı bir sahne akışı kuran, sesi aksiyona tam oturtan ve pahalı her adımdan önce bir insanın onayını bekleyen bir sistem.

Her şeyi belirleyen kısıtlar

Projedeki kararların çoğunun arkasında üç sayı var:

• 16 GB VRAM: Aynı anda yalnızca bir render yapılabiliyor ve en güncel video modellerinin çoğu bu belleğe sığmıyor.
• 31 GB RAM: İşe başladığım modelin çalışırken ihtiyaç duyduğu bellekten bile az.
• Kişisel bütçe: Bulutta yapılan her ücretli render doğrudan benim cebimden çıktı.

Mühendislik açısından en keyifli kısım, aslında bir veri merkezi isteyen bu sistemi tek bir masaüstü bilgisayarda çalışır hale getirmekti.

Mimari

                idea
                 │
        ┌────────▼─────────┐
        │  React control   │  draft review · timeline editor · models · analytics
        │  room (Vite)     │
        └────────┬─────────┘
                 │ REST
┌────────────────▼──────────────────────────────────────────────┐
│ NestJS                                                        │
│                                                               │
│  Scenario Engine ── LLM (Gemini / Groq / Claude / MUapi)      │
│     idea → art style + location + cast + ordered scenes       │
│     + per-scene render profile, dialogue, SFX, music mood     │
│  RAG memory (pgvector) ── what this channel already made      │
│  Profile resolver ── validate against installed models        │
│  Character reconciler ── reuse or generate reference images   │
│                                                               │
│  RabbitMQ (prefetch = 1, manual ack)                          │
│   video.generate ──► Video Worker ── ComfyUI / OpenRouter /   │
│        │   (each scene enqueues the next)          Muapi      │
│   video.postprocess ──► FFmpeg assembly                       │
│   [ AWAITING_UPSCALE — human gate ]                           │
│   video.upscale ──► upscale + frame interpolation             │
│   metadata.generate ──► title / description / hashtags       │
│   ──► YouTube upload ──► analytics fed back into prompts      │
└───────────────┬──────────────────────────────┬────────────────┘
                │                              │
         PostgreSQL + pgvector          ComfyUI on the GPU

Adım adım akış

1. Taslak. LLM, fikri düzenlenebilir bir taslağa dönüştürür: sanat stili, mekân, karakterler ve sahne sahne senaryo, yanında önizleme portreleriyle. Onaylamadan önce istediğim her şeyi yeniden adlandırabilir, yeniden ürettirebilir ya da baştan yazabilirim.
2. Karakter eşleştirme. Her karakter ve mekân için bir referans görsel hazırlanır. Karakter kütüphanede zaten varsa onun görseli kullanılır, yoksa yenisi üretilir.
3. Her sahnenin ilk karesi. SDXL sahnenin açılış karesini çizer. IP-Adapter sayesinde bu kare, sahnenin ana karakterine ve mekânına görsel olarak kilitlenir. Birkaç aday üretilir; CLIP içlerinden karaktere en çok benzeyeni seçer.
4. Animasyon. Seçilen kare bir image-to-video modelinin başlangıç noktası olur. Sahneler sırayla, birer birer render edilir.
5. Kurgu. FFmpeg klipleri seslendirmeye göre hizalar, ses efektlerini tam yerlerine koyar, konuşma sırasında müziği kısar, altyazıları ve kapanış kartını ekler, sonra hepsini birleştirir.
6. Onay kapısı. Birleştirilen video AWAITING_UPSCALE durumunda bekler. Videoyu izler, gerekirse timeline editöründe düzenlerim; upscale'in bedelini ancak bundan sonra öderim.
7. Upscale ve ara kare üretimi ile video nihai çözünürlüğüne ve kare hızına getirilir.
8. Metadata ve yükleme. LLM SEO'ya uygun başlık, açıklama ve hashtag'leri yazar; video YouTube Data API ile yüklenir ve kanalın analitik verileri sisteme geri döner.

Önemli kararlar

1. Paralel worker havuzu yerine sıralı işleme

Tek bir GPU varken sahneleri paralel render etmek, işlerin VRAM için birbirleriyle boğuşması demek. Bu yüzden her sahne işi prefetch = 1 ile tek tek alınıyor ve bitince bir sonraki sahneyi kuyruğa ekliyor. Bu tercih ileride sahneler arası geçişi de mümkün kıldı: N. sahne, N − 1. sahnenin tam olarak son karesinden başlayabiliyor, çünkü o sahnenin önceden bitmiş olacağı kesin.

ComfyUI'ı Docker yerine doğrudan makinede çalıştırıyorum. Windows'ta GPU'yu container'a geçirmek hiçbir getirisi olmayan bir baş ağrısıydı. Postgres, RabbitMQ ve Kokoro TTS sunucusu ise Compose'da duruyor.

2. Video modeli macerası: bir yolu kanıta dayanarak bırakmak

Projedeki en öğretici karar zinciri bu, çünkü içinde yarıda bıraktığım bir geçiş var.

Belirti. Render başlattığım anda disk %100'e kilitleniyor ve bilgisayar donuyordu. Diski en çok kullanan süreç ComfyUI değil, System idi; yani Windows sayfa dosyası sürekli diske yazıp okuyordu. Wan 2.2 14B fp8 iki "uzman" modelden oluşuyor ve çalışırken yaklaşık 33 GB belleğe ihtiyaç duyuyor (14'er GB'lık iki UNet ve 5 GB'lık bir metin kodlayıcı). Makinede ise 31 GB RAM var. ComfyUI, uzmanlar arasında her geçişte yaklaşık 14 GB'ı bellekten atıp diskten yeniden okuyordu.

Seçenekler. Önümde dört yol vardı: Wan'ı GGUF ile küçültmek (asıl çözüm buydu ama kurulu olmayan bir node ve baştan dışa aktarılmış bir iş akışı gerekiyordu), 64 GB RAM almak (maliyetli), WSL2'nin belleğini sınırlamak (sadece yama, 33 hâlâ 31'den büyük) ya da tek uzmanlı, daha küçük bir modele geçmek. Önce yamayı uyguladım, ardından LongCat-Video'ya (~20 GB) geçtim.

LongCat yaklaşık 13 denemede de çöktü. Önce LoRA birleştirirken segfault'lar aldım. Sonra modelin aslında yalnızca metinden video ürettiğini, yani başlangıç karesinden video üretemediğini fark ettim; oysa bu, sistemin temel ihtiyacıydı. Ardından VRAM yetmedi, en sonunda da üçüncü parti eklentisindeki bellek boşaltma özelliğinin bozuk olduğu çıktı. Küçültülmüş bir sürümü de yoktu. 21,9 GB'lık model dosyalarını sildim ve bu çıkmaz sokağı nedenleriyle birlikte "bu 16 GB'lık kartta tekrar deneme" diye not ettim ki ileride kimse aynı yola yeniden girmesin.

Yeni modeli bir sıralama tablosuna bakarak değil, yaşadığım sorunlara bakarak seçtim. HunyuanVideo 1.5'i tam da bu sorunların hiçbirini yaşatmayacağı için tercih ettim: fp8'de 8,3 milyar parametre (~8 GB), gerçek image-to-video desteği ve üçüncü parti eklenti gerektirmeyen yerleşik ComfyUI desteği. İlk denemede 33 karelik, 480p bir video 191 saniyede ve bellek hatası olmadan çıktı. Üstelik uzun süredir açık duran "videolar cansız görünüyor" şikâyetini de kendiliğinden çözdü.

3. Model kartını okumak: negatif prompt'lar boşa çalışıyordu

HunyuanVideo 1.5, CFG'si damıtılmış bir model ve cfg = 1.0 ile çalışıyor. cfg = 1.0'da classifier-free guidance'ın koşulsuz kolu hiç kullanılmıyor; dolayısıyla negatif prompt'ların video aşamasında matematiksel olarak hiçbir etkisi yok. Kodda yazan "fazladan uzuv olmasın, kedi iki ayak üstünde durmasın, şekil değiştirmesin" gibi bütün yasaklar, meğer yalnızca SDXL'in çizdiği ilk karede işe yarıyormuş.

Bu tek bulgu kalite çalışmasının yönünü değiştirdi:

• Video aşamasındaki kısıtları olumlu ifadelerle yeniden yazdım ("dört ayak üstünde, dört patisi de yerde").
• Kalite emeğini, bütün klibin çıkış noktası olan ilk kareye taşıdım.
• "CFG'yi yükselt" önerisini bir anti-pattern olarak kayda geçirdim; bu modelde değeri artırmak her şeyi bozuyor.

4. Maliyete göre sıralanmış bir halüsinasyon planı

Video üretiminde halüsinasyon üzerine yapılmış araştırmalardan yola çıkarak düzeltmeleri bir sıraya koydum: ucuz ve etkisi büyük olanlar önce, pahalı olanlar sona. Her birini de koddaki somut bir yere bağladım:

1. Sahne prompt'larını çok daha ayrıntılı betimlemek
2. Negatif prompt'ları olumlu ifadelere çevirmek
3. İlk kareyi sağlamlaştırmak
4. Bir doğrulayıcıyla birden fazla video üretip en iyisini seçmek
5. Bir görüntü-dil modeliyle (VLM) kontrol edip gerekirse yeniden üretmek
6. Yapısal yönlendirme (ControlNet)
7. Sampler ayarları
8. Birden fazla karakteri bölge bölge kilitlemek
9. İleride DPO eğitimi için tercih çiftlerini kaydetmek

İki fikri ise ilk altı adım tıkanmadıkça kapsam dışı bıraktım: bir JEPA doğrulayıcısı ve render ile simülasyonu karıştıran hibrit bir yaklaşım. Kapsamı o gün yazıya dökerek sınırladım.

Bir de her değişikliği aynı sahneyle sınamak için standart bir test prompt'u belirledim: bir kedi, üç kırmızı elma, bir mavi kâse, tek bir zıplama. Bu sahne nesne sayısını, rengin doğru nesneye oturmasını, fiziği ve karakterin kayıp kaymadığını aynı anda zorluyor.

Sonraları "N tane üret, en iyisini seç" yaklaşımını bütçeli ve doğrulayıcı destekli bir aramayla değiştirdim: adaylar tek tek üretiliyor, çıtayı geçen ilk aday kabul ediliyor. Kolay sahneler tek render'la geçiyor, bütçeyi yalnızca zor sahneler harcıyor.

5. Sahneler ve kareler arasında tutarlılık

Bir Short'u tutarlı tutmak aslında birbirinden ayrı iki problem:

• Sahneden sahneye (görünüm). Bütün videoda tek bir sanat stili var ve IP-Adapter referansı her sahne için ayrı ayrı, o sahnede gerçekten yer alan karakterden seçiliyor. İlk sürümdeki bir hata her sahneyi ana karaktere kilitliyordu; kendi hata kaydımdaki ifadeyle sonuç "kedi kafalı bir sincap" oldu. Sahne bazında odak karakter seçimini düzeltince sorun ortadan kalktı.
• Kareden kareye (hareket). LLM her sahneyi continues_previous ile işaretliyor. Önceki sahnenin devamı olan sahneler, önceki klibin son karesinden başlıyor; gerçek bir kesme olduğunda ise karakterlere kilitli, sıfırdan çizilmiş yeni bir kare kullanılıyor. Prompt'a şu kural da gömülü: ekran dışında olan bir çarpışmanın sonrasını gösteren sahne asla önceki kareden devam etmemeli, çünkü o karede her şey hâlâ sağlam görünüyor.

Hareketin ters yönde de ayarlanması gerekti. İlk stabilizasyon denemesi dozu kaçırdı ve ortaya "kedi sadece bakıp yürüyor, kamera da sadece uzaklaşıyor" gibi videolar çıktı. Sebebin bir kısmı hataydı: üretilen motion_hint kaydediliyor ama video modeline hiç gönderilmiyordu. Bir kısmı da prompt tasarımıydı. Artık her çekimde güçlü bir eylem fiili şart; edilgen fiiller ve ağır ağır uzaklaşan zoom'lar yasak.

6. "Sıra tabanlı RPG" videosu: geçici çözüm hataya dönüşünce

Arayüzden anında değiştirilebilen üç video backend'i kurdum: yerel ComfyUI (ücretsiz ama yavaş), OpenRouter (saniye başına ücret) ve Muapi (video başına ücret, ucuz bir taslak seçeneğiyle).

"Tesla vs Edison" videosunun bulutta yapılan ilk render'ı 2,36 dolara mal oldu ve sıra tabanlı bir RPG gibi göründü: iki karakter sırayla tek başına poz veriyor, hiçbir zaman aynı karede buluşmuyor, birbirine hiç dokunmuyordu. Suçlu benim kendi prompt kurallarımdı. Zayıf yerel modeli zorlamamak için senaryo prompt'una çarpışmaları ekran dışında tut, aynı anda tek bir karakteri hareket ettir yazmıştım. Üst düzey bir bulut modelinde bu kurallar, bir dövüş sahnesinin tam da ihtiyaç duyduğu şeyi yasaklıyordu.

Çözümü yapısal olarak kurdum: prompt'lar artık backend'in gücüne göre ayrılıyor.

Bu ayrımın gerekçesini, "ikisini yeniden tek bir kurala birleştirmeyin" notuyla birlikte kodun hemen yanına yazdım.

7. Maliyet de bir tasarım girdisi

8. Otonom, ama pahalı adımlarda asla başıboş değil

• Herhangi bir şey render edilmeden önce taslak incelemesi.
• Timeline editörü: sahneleri yeniden sıralamak, kesmek ve kırpmak; her kanalın ses seviyesini ayarlamak; sahne bazında müzik ve seslendirme seçmek; tek bir klibi yeniden render etmek. Düzenlemeler bir kurgu karar listesi (JSON) olarak saklanıyor ve yalnızca Yeniden birleştir dendiğinde uygulanıyor.
• Sistem açılışta GPU işlerine kendiliğinden devam etmiyor. Kuyrukta kalmış eski mesajlar işlenmek yerine bekletiliyor, çünkü belki başka bir şey başlatmak isteyeceğim. Devam ettirmek için ayrı bir endpoint var.
• Çalışan bir görevi durdurmak kuyruğu boşaltmıyor, kalıcı bir bayrak koyuyor. İşleme sıralı olduğu için o anki sahne tamamlanıyor, bir sonraki sahne ise hiç kuyruğa eklenmiyor.

Birden fazla kez tökezleyip sonunda belgelediğim bir tuzak da var: Kaydetmek, uygulamak demek değil. Birbirinden bağımsız iki ayrı veri oluşturucu var ve ikisinin de düzenleme listesini dikkate alması gerekiyor. Aksi halde baştan yapılan bir render, yaptığınız düzenlemeleri sessizce çöpe atıyor.

9. Aksiyona oturan ses

Ses efektleri her sahnenin içinde oransal bir konuma yerleştiriliyor (örneğin klibin at: 0.42 noktası; render sırasında gerçek süreyle çarpılıyor). Neredeyse aynı anda çalacak efektler arasında en az 0,3 saniye bırakılıyor ki üst üste binmek yerine art arda duyulsunlar.

Klip render edildikten sonra bir görüntü analizi adımı videoyu izliyor ve ekranda gerçekten olana bakarak her efektin zamanlamasını düzeltiyor, açıklamasını yeniden yazıyor ya da efekti tamamen çıkarıyor. Yeni bir efekt üretmeden önce de mevcut kütüphanede benzerini arıyor. Müzik sahne bazında planlanıyor; aynı parçayı kullanan ardışık sahnelerde müzik kesintisiz çalıyor.

10. Veriye dayalı içerik kararları

• RAG ile kanal hafızası. "Son beş başlığa bak" gibi bir geçici çözüm yerine her kanalın daha önce neler yayınladığını hatırlayan, pgvector tabanlı bir hafızası var. Kanalların birbirine karışmadığını canlı ortamda doğruladım.
• Kanalın konusu tonu belirler, videonun konusunu değil. Kanalın teması fikirleri ele geçiriyordu; kanalın sürekli kedisi, başka bir konudaki videolarda bile ortaya çıkıyordu. Kural: belirleyici olan fikirdir, kanalın teması sadece havayı belirler.
• SEO'yu gerçek analitik verilerine göre yeniden yazdım. Gerçek kanaldaki izlenmeler video başına 1,1 bin–21 binden 9–56'ya düşmüştü. Yaptığım analiz dört neden ortaya çıkardı: kanalın uzun süre sessiz kalması, başlıklarda hashtag olmaması, merak uyandırmak yerine sadece betimleyen başlıklar ve ilk saniyede dikkat çeken bir ses olmaması. Üçünü kodda düzelttim; bunlardan biri, doğrudan senaryo prompt'una eklenen "ilk saniyede sesle yakala" kuralı.
• Bu çalışmadan çıkan gerçek bir hata: Açıklamalar 4.900 karakterde kesiliyordu, ama YouTube'un sınırı 5.000 bayt, ve her emoji 3–4 bayt tutuyor. Sınırı artık bayt üzerinden hesaplıyorum.

Ancak ölçerek fark edilen kısıtlar

Bunların hiçbiri mimari diyagramında görünmez, ama her biri bana ciddi bir hata ayıklama süresine mal oldu:

"Bitti" benim için ne demek

Projede dört farklı "bitti" seviyesi var ve bunları asla birbirine karıştırmıyorum:

Notlarımda sık sık "build ve 38 test yeşil; render tarafı GPU'da denenmedi" gibi cümleler geçiyor. Bu ayrım kendini kanıtladı: bir özelliğin derlendiği ve testlerinin geçtiği söylendikten sonra karşıma iki hata çıktı. Biri güncelliğini yitirmiş bir doğrulama listesiydi, diğeri bir sağlayıcının yanıt formatını tanımayan bir parser. Yeşil build'ler ikisini de yakalayamamıştı.

Şu anki durum, açık açık

• Her şey gerçek render'da doğrulanmadı. Sahne bazında müzik, kesintisiz döngüler ve en son eklenen LLM sağlayıcısı derleniyor ve testleri geçiyor ama henüz ücretli, canlı bir render'da denenmedi.
• Tek bir ilk kare yalnızca tek bir karakteri kilitleyebiliyor. Aynı çekimdeki iki karakterin görünümü hâlâ kayabiliyor. Çözüm ya bölgesel çoklu karakter kilidi (geliştirildi, GPU'da doğrulanması gerekiyor) ya da bir bulut backend'inde referans görselden video üretmek.
• Kareden kareye tutarlılık hâlâ en zayıf halka. Çözüldü demek yerine model seviyesinde üzerine gitmeye devam ediyorum.
• Bazı üçüncü parti entegrasyonlarda, API'nin formatı dokümantasyondan doğrulanamadığı için, ayarlardan değiştirilebilen endpoint'lerin arkasında en makul tahmine dayanan model adları kullanılıyor.

Yapay zekâyla nasıl çalıştım

Bu projeyi Claude Code'u araştırma, kodlama ve kayıt tutma ortağım olarak kullanarak geliştirdim. Kapsam, maliyet ve mimariyle ilgili kararları ise hep kendim verdim, birkaç kez onun önerisinin tersine. Zamanla şöyle bir çalışma düzeni oturdu:

1. Gerçek bir çıktıdaki somut bir kusurla başla ("köpek zıplıyor ve molekül boyutuna küçülüyor"), sonra bu kusuru yaratan modele, ayara ya da koda kadar izini sür. Asla sadece belirtiyi yamalama.
2. Seçenekleri maliyetleriyle birlikte, birkaç alternatif olarak masaya koy, sonra karar ver.
3. Büyük adımları dışarıdan bir kaynağa dayandır: halüsinasyon için bir araştırma makalesine, SEO için kanalın kendi analitiklerine.
4. Para harcamadan önce tutarı açıkça gör ve beklenmedik bir maliyet ortaya çıktığı anda bir fren ekle.
5. Doğrulanmış küçük adımlarla ilerle. Unit test sayısı proje boyunca 9'dan 90'ın üzerine çıktı.
6. Tarihli bir karar günlüğü tut ve her notun ne kadar güncel olduğunu belirt. "Bunu tekrar deneme" ya da "bunları yeniden tek bir yerde birleştirme" gibi notlar sayesinde ileride yapılacak bir refactor, zor öğrenilmiş bir dersi sessizce geri alamaz.

Bir sonraki projeye götüreceğim dersler

• Kısıtlar, tasarımın ta kendisidir. Kuyruk yapısını, video modelini, maliyet frenlerini ve onay adımlarını 16 GB'lık ekran kartı belirledi.
• Yerine yenisini seçerken benchmark skorlarına değil, yaşadığın sorunlara bak.
• Ayar yapmadan önce modeli tanı. Model kartındaki tek bir satır, yaptığım bütün bir ayar grubunu anlamsız hale getirdi.
• Telafi amaçlı kuralların bir son kullanma tarihi vardır. Zayıf bir bileşen için yazılmış geçici bir çözüm, o bileşen güçlendiğinde hataya dönüşür. Bu tür kuralları, telafi ettikleri eksikliğe bağlı tut.
• Bir filtrenin iddia ettiği şeyi gerçekten yapıp yapmadığını ölç. PSNR ve dB ölçümleri, "gözüme iyi görünüyor"un asla bulamayacağı sorunları ortaya çıkardı.