Yapay Zeka 27 Ağustos 2026 · 9 dk okuma

Hugging Face'te Sekiz Model Yayınladık: MLX ve Ölçülmüş Sonuçlar

Done Dynamics, Qwen3.8-27B tabanlı sekiz MLX model sürümünü Hugging Face'te yayımladı: dördü metin, dördü görüntü okuyan; 4-bit, 6-bit, 8-bit ve bf16. Boyut, saniyedeki token üretimi ve tepe bellek kullanımı M3 Ultra üzerinde ölçüldü.

Devrim Tunçer Devrim Tunçer

Done Dynamics Mac Studio yapay zeka sunucu filosu

Mayısta 1.000.000 TL’lik Mac Studio yatırımını duyurmuştuk: 512 GB unified memory’li bir M3 Ultra ve 36 GB’lık bir M4 Max. O yazının sonunda bir cümle vardı — verilerimizi dışarı çıkarmadan çalıştırabileceğimiz modelleri kendimiz hazırlayacağız. Bu yazı o cümlenin karşılığı.

Hugging Face profilimizde sekiz model sürümü yayında. Dördü yalnız metin okuyor, dördü görüntü de okuyor. Her ailede dört ayrı hassasiyet var: 4-bit, 6-bit, 8-bit ve bf16. Hepsi aynı kaynak revizyonundan dönüştürüldü, hepsi aynı makinede aynı istemle ölçüldü. Rakamlar model kartlarında yazılı; aşağıda hem rakamlar hem de onları üretirken öğrendiklerimiz var.

Neden dönüştürmek gerekiyor?

Apple Silicon’da bir dil modeli çalıştırmanın iki yolu var. Birincisi PyTorch’u Metal arka ucuyla kullanmak; çalışır ama unified memory mimarisinin sunduğu avantajın büyük kısmını masada bırakır. İkincisi MLX — Apple’ın kendi dizi çerçevesi. MLX, CPU ile GPU arasında tensör kopyalamaz, çünkü Apple Silicon’da ikisi zaten aynı belleğe bakıyor. 512 GB’lık bir makinede bu, “modelin GPU belleğine sığması” diye bir sorunun ortadan kalkması demek.

Karşılığında MLX kendi ağırlık biçimini istiyor. Hugging Face’teki bir depo genellikle PyTorch için hazırlanmış safetensors dosyaları taşır; MLX bunları okuyabilmek için yeniden düzenlenmiş bir yapı bekler. Dönüşüm işte bu: ağırlıkları okuyup MLX’in beklediği düzende, istenen hassasiyette yeniden yazmak.

Bu dönüşümü her seferinde kendi makinemizde yapmak yerine bir kez yapıp yayımlamak daha mantıklıydı. Aynı işi yapan başka biri için de öyle.

Sekiz sürüm, iki aile

Kaynak model çok kipli: hem metin hem görüntü okuyor. Ama dönüşüm araçları bu konuda ikiye ayrılıyor ve bu ayrım sessizce sonuç değiştiriyor.

mlx-lm yalnızca dil kulesini dönüştürür. Görüntü kulesine ait tek bir tensör bile çıktıya girmez, üretilen yapılandırma dosyasında vision_config bulunmaz. Sonuç çalışır, hızlıdır, biraz da küçüktür — ama görüntü göndermeye kalkarsanız hiçbir şey olmaz. Hata bile vermez; model o girdiyi görmez.

mlx-vlm ise görüntü kulesini korur. Toplam 2180 tensörün 333’ü görüntü kulesine ait ve bunlar çıktıya dahil edilir.

Aynı kaynaktan iki farklı şey çıktığı için ikisini de yayımladık.

Metin sürümleri — Qwen3.8-27B-heretic-MLX-*

SürümBoyutAğırlık başına bitÜretimTepe bellek
4-bit15,1 GB4,50137,9 token/sn15,5 GB
6-bit21,9 GB6,50127,9 token/sn22,2 GB
8-bit28,6 GB8,50122,2 token/sn28,9 GB
bf1650,0 GB1612,7 token/sn54,1 GB

Görüntü sürümleri — Qwen3.8-27B-heretic-VL-MLX-*

SürümBoyutAğırlık başına bitÜretimTepe bellek
4-bit15,0 GB4,69538,9 token/sn19,2 GB
6-bit21,3 GB6,66129,2 token/sn27,0 GB
8-bit27,5 GB8,62723,1 token/sn34,7 GB
bf1651,0 GB1613,2 token/sn55,8 GB

Ölçüm koşulları: Mac Studio M3 Ultra, 512 GB unified memory, macOS 26.5.2. Metin tarafında mlx-lm 0.31.3, 68 token’lık istem, 120 token üretim. Görüntü tarafında mlx-vlm 0.6.13, görüntü ve metin içeren 470 token’lık istem. Tek çalıştırma, tek makine, tek istem — bu bir kıyaslama testi değil, büyüklük mertebesi rehberi.

Rakamlardan çıkan üç sonuç

Birincisi: 4-bit ile bf16 arasında üç kat hız farkı var. 37,9’a karşı 12,7 token/saniye. Aynı model, aynı makine. Nicemleme burada bir sıkıştırma numarası değil, doğrudan gecikme bütçesi.

İkincisi: bellek tasarrufu hızdan daha çarpıcı. bf16 sürümü 54 GB tepe bellek istiyor; 4-bit 15,5 GB ile yetiniyor. 36 GB’lık M4 Max’imizde bf16 sürümü hiç çalışmaz, 8-bit’e kadar olan her şey rahatça çalışır. Yani nicemleme bir “biraz daha hızlı” ayarı değil, bazı makinelerde çalışıp çalışmama sorusu.

Üçüncüsü: görüntü kulesi hızı değil belleği vuruyor. Görüntü sürümlerinin üretim hızı metin sürümleriyle neredeyse aynı — hatta 4-bit’te bir tık daha yüksek. Ama tepe bellek her sürümde 4-6 GB daha fazla. Görüntü kulesinin kendisi ve görüntü parçalarının ara aktivasyonları oraya yerleşiyor. İstem işleme tarafında dört sürüm de 303-331 token/saniye aralığında kaldı: sürümler arasındaki fark üretimde ortaya çıkıyor, ön işlemede değil.

Token bütçesi: düşünme kipi sessizce yiyor

Bu ailenin sohbet şablonu enable_thinking ve reasoning_effort parametrelerini destekliyor ve düşünme varsayılan olarak açık. Model cevaba başlamadan önce bir muhakeme bloğu üretiyor, o blok da token bütçenizden yiyor.

Pratikte şu oluyor: max_tokens değerini 128 gibi küçük bir sayıda bırakırsanız, bütçenin tamamı muhakemeye gidebilir ve elinize hiç cevap geçmez. Sorunun cevabını almak yerine modelin düşünme sesini alırsınız.

İki yol var. Cevabın kısa olması gerekiyorsa düşünmeyi kapatın:

prompt = tokenizer.apply_chat_template(
    messages, add_generation_prompt=True, enable_thinking=False
)

Muhakemeye ihtiyacınız varsa bütçeyi ona göre açın — 512 ve üstü. Ara bir yol olarak reasoning_effort ile derinliği ayarlayabilirsiniz.

Bu, ölçüm yaparken de önemli. Saniyede kaç token ürettiği rakamı düşünme açıkken de kapalıyken de aynıdır, ama cevabın kaç saniyede geldiği ikiye katlanabilir. Bir uygulamanın gecikme bütçesini hesaplarken bakılacak sayı ikincisi.

Kullanımı

Metin sürümü için mlx-lm yeterli:

pip install mlx-lm

mlx_lm.generate --model donedynamics/Qwen3.8-27B-heretic-MLX-4bit \
  --prompt "Kendini kısaca tanıt." --max-tokens 256

from mlx_lm import load, generate

model, tokenizer = load("donedynamics/Qwen3.8-27B-heretic-MLX-4bit")
messages = [{"role": "user", "content": "Kendini kısaca tanıt."}]
prompt = tokenizer.apply_chat_template(messages, add_generation_prompt=True)
print(generate(model, tokenizer, prompt=prompt, max_tokens=256))

Görüntü sürümü için mlx-vlm gerekiyor — mlx-lm ile yüklerseniz görüntü kulesi sessizce devre dışı kalır:

pip install mlx-vlm

mlx_vlm.generate --model donedynamics/Qwen3.8-27B-heretic-VL-MLX-4bit \
  --image fotograf.png --prompt "Bu görüntüde ne var?" --max-tokens 256

from mlx_vlm import load, generate
from mlx_vlm.prompt_utils import apply_chat_template

model, processor = load("donedynamics/Qwen3.8-27B-heretic-VL-MLX-4bit")
prompt = apply_chat_template(processor, model.config, "Bu görüntüde ne var?", num_images=1)
print(generate(model, processor, prompt, ["fotograf.png"], max_tokens=256))

Görüntü tarafını varsaymadık, test ettik

Görüntü kulesinin korunduğu cümlesi yapılandırma dosyasına bakarak da yazılabilirdi. Yazmadık. Üretilmiş bir test görüntüsü hazırladık: solda kırmızı kare, ortada mavi daire, sağda yeşil üçgen, üstünde MAC512 VISION TEST yazısı ve 7391-ZQ kodu.

Dört görüntü sürümüne de aynı görüntüyü verdik. Dördü de üç şekli doğru renk ve doğru konumla adlandırdı, iki metni de birebir okudu. 4-bit dahil.

Bu, nicemlemenin görüntü tarafını bozmadığını gösteren küçük ama gerçek bir kanıt. Küçük diyoruz çünkü tek bir sentetik görüntü, gerçek bir belge ya da fatura setinin yerini tutmaz — kendi verinizle kendiniz denemeden üretime almayın.

Dönüşüm süreci ve doğrulama

Dönüşüm komutları tek satır:

mlx_lm.convert --hf-path trohrbaugh/Qwen3.8-27B-heretic-ara -q --q-bits 4 \
  --mlx-path Qwen3.8-27B-heretic-MLX-4bit

mlx_vlm.convert --hf-path trohrbaugh/Qwen3.8-27B-heretic-ara -q --q-bits 4 \
  --mlx-path Qwen3.8-27B-heretic-VL-MLX-4bit

Ama komutu çalıştırmadan önce kaynağı doğruladık: 7 parça dosya, 1199 tensör, tüm safetensors başlıkları ayrıştırıldı, eksik dosya yok. Sekiz sürümün tamamı aynı revizyondan (a67ae100…) dönüştürüldü — böylece aralarındaki fark yalnızca hassasiyet, kaynak farkı değil.

Nicemleme afin, grup boyutu 64. Tablodaki ağırlık başına bit değerlerinin tam sayı olmamasının sebebi bu: 4-bit sürümde gerçek maliyet 4,501 bit, çünkü grup başına ölçek ve sıfır noktası da saklanıyor.

Modelin köken zinciri ve bir uyarı

Zincir şöyle: Qwen/Qwen3.8-27B → trohrbaugh/Qwen3.8-27B-heretic-ara → bizim MLX sürümlerimiz.

Ortadaki halka önemli: kaynak model abliterated (“heretic”) bir türev. Reddetme davranışı cerrahi biçimde çıkarılmış, yani güvenlik ayarlı bir modelin reddedeceği istemlere de cevap veriyor. Bizim depolarımız yalnızca biçim ve hassasiyet değiştiriyor — hizalama eklemiyor, kaldırmıyor da.

Bunu pazarlama cümlesi olarak değil uyarı olarak yazıyoruz: kullanıcı önüne koymadan önce kendi değerlendirmenizi yapın ve kullanım senaryonuzun gerektirdiği filtrelemeyi kendiniz uygulayın. Kurumsal bir asistanda, müşteriye açık bir sohbet arayüzünde ya da çocuklara yönelik bir üründe bu modelleri filtresiz çalıştırmak doğru bir tercih değildir. Dahili bir analiz aracında, belge okuma hattında ya da geliştirici aracında ise davranış öngörülebilir ve kontrollü olur.

Lisans zincir boyunca Apache-2.0. Model için kredi Alibaba Group Tongyi Lab’deki Qwen ekibine, abliterasyon için trohrbaugh’a ait. Bizim katkımız yalnızca MLX dönüşümü ve ölçümü.

Bu iş neden bizim işimize yarıyor?

Sorunun ticari karşılığı şu: müşteri verisini bir yapay zeka sağlayıcısına göndermeden çalışan bir hat kurabiliyor muyuz?

Sekiz sürüm bu sorunun cevabının parçaları. 512 GB’lık makinede bf16 sürümünü çalıştırıp kalite tavanını görüyoruz; 4-bit sürümü aynı makinede üç kat hızlı çalıştığı için gerçek zamanlı işlerde onu kullanıyoruz; 36 GB’lık M4 Max’e yalnızca nicemlenmiş sürümler sığdığı için hafif işleri oraya alıyoruz. Görüntü sürümleri sayesinde belge, fatura ve ekran görüntüsü okuyan hatlar aynı altyapıda kalıyor — görüntü işleme sistemleri geliştirme tarafındaki işlerimizin çoğu bu sürümlerin üzerinde duruyor.

Bunu bir müşteri projesine dönüştürdüğümüzde adı kurumlara özel yapay zeka geliştirme oluyor: modelin seçimi, nicemleme kararı, gecikme bütçesi ve verinin nerede durduğu aynı masada konuşuluyor. Yayımladığımız sekiz sürüm de o masaya getirdiğimiz ölçülmüş veri.

Kendi kurulumunuzda denemek isterseniz depolar açık, model kartlarında ölçüm koşulları yazılı, lisans izin veriyor. Bize yazın — hangi sürümün hangi işe uygun olduğunu konuşmak bizim de işimize yarıyor.

Sertifikalar

Ağ ve siber güvenlik işlerini, uluslararası geçerli Cisco sertifikasyonuna sahip ekiple yürütüyoruz.

Cisco CyberOps Associate rozeti

Cisco CyberOps Associate

Veren kurum: Cisco · Sahibi: Devrim Tunçer

Güvenlik operasyon merkezi (SOC) yetkinliğini belgeleyen sertifika: güvenlik izleme, olay müdahalesi ve ağ saldırılarının analizi. Sızma tespiti, log korelasyonu ve olay sonrası müdahale gerektiren işlerde dayandığımız temel budur.

Credly'de doğrula Siber güvenlik hizmetimiz

Cisco CCNA Eğitimi

süresi doldu

Cisco eğitim sertifikası · Ocak 2023'te tamamlandı

Ağ temellerini kapsar: yönlendirme, anahtarlama, IP adresleme ve ağ güvenliği. Kurumsal ağ kurulumu ile segmentasyon işlerinde kullandığımız bilgi tabanı.

LinkedIn duyurusu Ağ altyapısı hizmetimiz

Teknik içeriğin büyük kısmı ikinci elden yazılıyor

Teknik içeriğin büyük kısmı ikinci elden yazılıyor

Bir konu aratıldığında ilk on sonucun çoğu birbirinin cümle sırası değişmiş hâlidir. Aynı tanım, aynı beş madde, aynı kapanış. Hiçbirinde bir şey denenmemiştir. Bu yazılım blogu tam o boşluk için var: burada yazılan her şey ya kendi altyapımızda ya bir müşterinin sahasında karşılığı olan bir karardan çıkıyor. Fark okurken hemen belli olmuyor. Uygularken oluyor.

Done Dynamics bir kurumsal yazılım şirketi; günün büyük bölümü sunucu, ağ, uygulama ve arama görünürlüğü tarafında geçiyor. Yazıların çıkış noktası da orası. Bir donanım alındığında, bir mimari değiştirildiğinde ya da yapılan bir tahmin tutmadığında not tutuluyor; notların bir kısmı burada yayımlanıyor. Şirket tanıtımı değil, karar dökümü.

Bu sayfanın altında beş şey anlatılıyor: pazarlama yazısıyla saha notunun farkı, derleme içeriğin neyi gizlediği, burada hangi sorulara cevap arandığı, teknik karar alırken tekrar eden hatalar ve ele alınan konu başlıkları. Sonda da yayında olan yazıya dair kısa bir not var.

Bir uyarı da baştan: burada yazılanların hepsi belirli bir zamana ve belirli bir donanıma ait. Altı ay sonra bazı sayılar değişmiş olacak. Değiştiğinde yazı silinmeyecek, üstüne not düşülecek. Teknik metnin en dürüst hâli, eskidiğini kabul edenidir.

Pazarlama yazısı ile saha notu arasındaki fark

Pazarlama amaçlı yazı bir sonuca doğru ilerler. Sonuç baştan bellidir: aranan ürün ya da hizmet. Metin o sonuca giden yolu döşer, karşı argümanları hafifçe geçer, riskleri dipnota indirir. Kötü niyetli olması gerekmez; yalnızca yönü sabittir. Okuyucu da genelde bunu sezer, çünkü hiçbir cümlede tereddüt yoktur.

Saha notunda yön sabit değildir. Bir karar alınmış, uygulanmış ve sonucu görülmüştür. Sonuç bazen beklendiği gibi çıkar, bazen çıkmaz. Yazının değeri de tam olarak burada birikir: neyin işe yaramadığını yazmak, neyin yaradığını yazmaktan daha az satar ama daha çok işe yarar. Bir teknoloji kararının maliyeti çoğu zaman kararın kendisinde değil, geri dönüşünde saklıdır.

İkinci fark ölçekte. Pazarlama metni genellemeyi sever: "işletmeler için ideal çözüm". Saha notu koşulu söylemek zorundadır — kaç kullanıcı, hangi veri hacmi, hangi bağlantı hızı, hangi bütçe. Aynı mimari on kişilik bir ofiste mükemmel çalışırken üç yüz kişilik bir yapıda çöker. Koşulu yazmayan metin, okuyucuya kendi durumunu değerlendirme imkânı bırakmaz.

Üçüncü fark zaman. Pazarlama yazısı yayımlandığı gün en doğrudur, sonra eskir. Saha notu tersine çalışır: altı ay sonra "o karar tuttu mu" sorusu sorulabilir hâle gelir ve metnin gerçek sınavı orada başlar. Bir yazılım blogu ancak eski yazılarının arkasında durabildiği ölçüde okunmaya değer. Bu yüzden burada tarih ve donanım modeli gibi bağlayıcı ayrıntılar açık yazılıyor.

Bir de okuyucu tarafı var. Pazarlama metnini okuyan kişi karar vermeye hazırdır; saha notunu okuyan kişi genelde bir şeyi çözmeye çalışıyordur. İkisinin sorusu aynı değil. Birincisi "kiminle çalışayım" diye sorar, ikincisi "bu yapı benim yükümü kaldırır mı" diye. İstanbul yazılım taleplerinde ikinci grup ağır basıyor; karşımızdaki kişi çoğu zaman kendi teknik ekibi olan, kıyaslama yapmak isteyen biri. Ona satış metni göndermek vakit kaybı. Ölçüm göndermek işe yarıyor.

Kaynak göstermeyen derleme neyi gizler

Derleme içerik kolay üretilir. Beş kaynaktan okunur, sıra değiştirilir, bir giriş ve bir kapanış eklenir. Ortaya çıkan metin teknik olarak yanlış olmayabilir. Sorun başka: hangi cümlenin ölçülmüş bir gerçek, hangisinin bir başkasının varsayımı olduğu kaybolur. Kaynak zinciri koptuğunda hata da düzeltilemez hâle gelir, çünkü hatanın nereden girdiği bilinmez.

Yaygın bir örnek var: yıllar önce doğru olan bir eşik değeri, bugünkü metinlerde hâlâ dolaşır. Donanım değişmiştir, kütüphane sürümü değişmiştir, sınır artık orada değildir. Ama cümle her derlemede bir sonrakine geçtiği için ölmez. Birinci elden yazılmış metinde bu olmaz; yazan kişi kendi ölçümünü verdiği için tarih de, koşul da metnin içindedir.

İkinci gizlenen şey maliyet. Derleme içerik bir teknolojinin kurulumunu anlatır, bakımını anlatmaz. Oysa bir sistemin gerçek bedeli kurulum gününde değil, on sekizinci ayında görünür: sürüm yükseltmesi, yedek doğrulaması, personel değişimi, mevzuat güncellemesi. Alanya yazılım ekibimizin sahada en sık düzelttiği durum da bu — internetten okunmuş bir tarife göre kurulmuş, bakımı hiç konuşulmamış bir yapı.

Üçüncü gizlenen şey bağlam. Bir çözümün hangi ölçekte doğrulandığı yazılmadığında okuyucu onu kendi ölçeğine taşıdığını sanır. Oysa taşımaz. On kullanıcıyla denenmiş bir kurulum üç yüz kullanıcıda bambaşka davranır ve bunu ancak canlıya alındıktan sonra öğrenirsiniz — en pahalı öğrenme biçimi. Bu yazılım blogu içinde bir yaklaşım anlatılırken hangi ölçekte denendiği de yazılıyor. Kısıtı yazmak metni zayıflatmaz; sınanabilir kılar.

Yapay zekâ üretimi içerik çoğaldıkça okuyucu ne kaybediyor

Arama sonuçları hızla dolduruluyor. Bir konu hakkında yüzlerce metin üretmek artık dakikalar sürüyor ve bu metinlerin çoğu birbirinin ortalaması. Ortalamanın sorunu yanlış olması değil, karar verdirmemesi. Okuyucu üç sayfa gezer, hepsinde aynı beş maddeyi görür ve kendi sorusunun cevabını hiçbirinde bulamaz. Kaybedilen şey zaman.

İkinci kayıp aykırı bilginin silinmesi. Bir modelden çıkan metin, veri kümesindeki en yaygın görüşü tekrarlamaya eğilimlidir. Sahada işe yarayan çözümlerin bir kısmı ise yaygın değil, koşula özgüdür. Küçük bir işletmede doğru olan bir mimari, çoğunluk öyle yapmadığı için ortalama metinlerde hiç geçmez. Bu yazılım blogu için ilkeler arasında ilk sırada duran şey de bu: azınlıkta kalan ama ölçülmüş kararı yazmak.

Üçüncü kayıp sorumluluk. Bir metnin arkasında adı geçen bir insan yoksa, yanlış çıktığında kimse hesap vermez. Burada yayımlanan yazıların yazarı belli ve o yazar aynı kararı kendi altyapısında uygulamış kişi. Yapay zekâyı kullanmıyor muyuz? Kullanıyoruz — hem de kendi donanımımızda çalıştırdığımız modellerle. Fark şurada: metni model yazmıyor, karar veren insan yazıyor.

Dördüncü kayıp doğrulanabilirlik. Ölçüm yapılmadan yazılan cümleler birbirine benzer; ölçüm yapılarak yazılanlar benzemez, çünkü her ortamın sayısı farklıdır. Bir metinde donanım modeli, sürüm numarası, süre ya da tutar geçiyorsa o metin sınanabilir. Geçmiyorsa yalnızca hoş bir anlatı vardır ortada.

Beşinci kayıp daha sinsi: aramanın kendisi bozuluyor. Ortalama metin çoğaldıkça iyi metni bulmak zorlaşıyor ve okuyucu bir yerden sonra aramayı bırakıp ilk gördüğüne göre karar veriyor. Karar da genelde yanlış çıkıyor. Alanya yazılım ekibimize gelen taleplerin bir bölümü tam buradan doğuyor — altı ay önce kurulmuş, bugün sökülmesi gereken bir yapı. Sökmek kurmaktan pahalı.

Bir ölçüt önerelim. Bir metni okurken kendinize şunu sorun: burada, yazarın kendi başına gelmiş olması gereken tek bir ayrıntı var mı? Bir hata mesajı, bir sürüm numarası, gece yaşanmış bir aksaklık, bir tedarikçiyle yapılmış tartışma. Yoksa metin muhtemelen başka metinlerden derlenmiştir. Kusursuz bir ölçüt değil. Pratikte iyi çalışıyor ve hiçbir araç gerektirmiyor.

Burada hangi soruya cevap aranıyor

İlk soru teknoloji seçimi. Hangi çerçeve, hangi veritabanı, hangi barındırma modeli? Bu sorunun tek doğru cevabı yok, ama yanlış cevaplama biçimi var: popülerlik sırasına bakarak seçmek. Seçim ekibin bildiği şeye, işin ömrüne ve bakımı kimin üstleneceğine bağlı. Yazılarda karşılaştırma yapılırken kazanan ilan edilmiyor; hangi koşulda hangisinin oturduğu yazılıyor. Kazanan yok. Koşul var.

İkinci soru altyapı kararı. Bulutta mı, kendi donanımında mı, ikisi karışık mı? Bu karar aylık faturayla değil, üç yıllık toplam maliyetle ve veri hassasiyetiyle veriliyor. Kiralanan kaynak esnektir, satın alınan kaynak öngörülebilir. İkisinin doğru olduğu senaryolar birbirinden çok farklı ve genelde işin trafik profiline bakılarak ayrışıyor. Yük dalgalıysa kirala. Sabitse hesapla.

Üçüncü soru maliyet karşılaştırması. Bir sistemin gerçek maliyeti lisans bedeli değil; lisans, barındırma, bakım, eğitim ve duruş riskinin toplamı. Sayılar yan yana konmadan yapılan tartışma fikir alışverişinden ibaret kalıyor. Burada tutarlar yazıldığında kaleminin de yazılmasına dikkat ediliyor, çünkü toplam rakam tek başına yanıltıcı. Tek satır az şey anlatır.

Dördüncü soru mevzuat uyumu. KVKK yükümlülükleri, verinin nerede tutulduğu, kayıt saklama süreleri, erişim yetkisinin nasıl belgelendiği. Bunlar hukuki metinlerde soyut, sahada çok somut. Antalya yazılım ve turizm tarafında en sık gelen soru misafir verisinin nerede durduğu; sağlık tarafında ise kimin hangi kaydı görebildiği. İki soru da mimariyi doğrudan değiştiriyor. Sonradan eklenmiyor.

Beşinci soru sahadan çıkarılan dersler. Bir kurulumun ikinci ayında ortaya çıkan aksaklık, ilk gün yazılan plandan daha öğreticidir. Yedeğin geri dönmediği bir gece, bir ağ kesintisinin nasıl yayıldığı, bir güncellemenin neyi bozduğu — bunlar kimsenin övünmediği ama herkesin ihtiyaç duyduğu notlar. İstanbul yazılım tarafındaki projelerde çok lokasyonlu yapılar, bu dersleri en hızlı üreten ortam oluyor.

Altıncı bir soru daha var: ne zaman hiçbir şey yapmamak doğru? Her teknik şikâyetin karşılığında bir proje olması gerekmiyor. Bazı sistemler eski ama ayakta ve dokunmanın maliyeti dokunmamanın maliyetinden yüksek. Bunu söylemek bir yazılım şirketi için ticari olarak kârlı değil, okuyucu için doğru. Yenilemenin gerçekten gerektiği eşiği yazmak, yenilemeyi övmekten zor bir iş.

Beş sorunun ortak yanı şu: hiçbirinin cevabı tek kelimelik değil. "Hangisi daha iyi" sorusuna verilen tek kelimelik cevaplar koşulu atladıkları için yanlış. Bu yazılım blogu içinde bir kıyaslama yapılırken önce koşul yazılıyor, sonra sonuç. Sıra tersine döndüğünde metin reklama dönüşüyor. Okuyucu da kendi durumunu ancak koşul yazılıysa tanıyabiliyor.

Teknik karar alırken tekrar eden dört hata

Birincisi popülerliğe göre teknoloji seçmek. Bir aracın çok konuşuluyor olması, sizin işinize uyduğunu göstermez. Topluluk büyüklüğü faydalıdır; işin ömrü, ekibin bildiği dil ve bakımı kimin yapacağı ondan daha belirleyici. Beş yıl yaşayacak bir sistemi, iki yıl sonra kimsenin bakmayacağı bir moda üzerine kurmak pahalı bir tercih. Sıkıcı teknoloji çoğu zaman doğru teknolojidir.

İkincisi kıyaslama yapmadan taahhüt vermek. "Bu mimari bizim yükümüzü kaldırır" cümlesi ölçülmeden söylendiğinde bir temenni. Küçük bir yük testi, gerçek veriyle yapılmış bir deneme ya da bir günlük pilot kurulum, aylarca sürecek bir yanlıştan çok daha ucuz. Ölçüm yapmanın maliyeti neredeyse her zaman ölçüm yapmamanın maliyetinden düşük çıkıyor. Önce ölçün. Sonra söz verin.

Üçüncüsü bakım maliyetini hesaba katmamak. Kurulum tek seferlik, bakım süreklidir. Sürüm yükseltmeleri, güvenlik yamaları, sertifika yenilemeleri, yedek doğrulama ve izleme — hiçbiri ilk teklifte görünmez, hepsi ikinci yıldan itibaren gündelik iş hâline gelir. Bir sistemi seçerken sorulacak asıl soru şu: bunu on sekiz ay sonra kim güncelleyecek?

Dördüncüsü tek kişiye bağımlı sistem kurmak. Bir yapıyı yalnız bir kişi anlıyorsa, o yapı çalışsa bile kırılgandır. Şifreler bir yerde, kurulum mantığı bir başka yerde, kararların gerekçesi hiçbir yerde. Kişi ayrıldığında geriye dokunulmaya korkulan bir sistem kalır. Yazılı mimari, ortak erişim ve devredilebilir dokümantasyon; üçü de kurulum aşamasında ucuz, sonradan pahalıdır. Yazın. Bugün yazın.

Beşinci bir madde daha eklenebilir: bir sistemi çıkış planı olmadan seçmek. Veriyi dışarı almanın yolu yoksa, o tedarikçiyle olan ilişki teknik değil hukuki bir bağa dönüşür. Dışa aktarma biçimi ve veri sahipliği ilk gün konuşulmalı. Bir kurumsal yazılım şirketi ile çalışırken bunu sormak, sözleşmedeki her maddeden daha çok şey anlatır.

Altıncısı kararı tek masada almak. Sunucu tarafını bilen kişi ile uygulamayı yazan kişi aynı toplantıda değilse ortaya iki ayrı doğru çıkar ve ikisi birbirini bozar. Veritabanı seçimi bunun en net örneği — geliştirici için rahat olan yapı, sistem tarafı için bakımı zor olabiliyor. İstanbul yazılım projelerinde bu iki masayı erken birleştirmek, sonradan yapılacak göç işlerinin çoğunu baştan siliyor. Toplantı ucuz. Göç değil.

Bu hataların ortak kaynağı acele. Karar toplantısında en yüksek sesle savunulan seçenek kazanıyor, ölçüme vakit ayrılmıyor ve bakım tarafı "sonra bakarız" listesine düşüyor. İki hafta gecikmek pahalı görünür. İki yıl yanlış mimariyle yaşamak daha pahalı. Bir kararın geri alınabilir olup olmadığını sormak, çoğu zaman kararın kendisinden değerli. Geri alınabiliyorsa hızlı ilerleyin. Alınamıyorsa yavaşlayın.

Ele alınan konu başlıkları

Sunucu ve altyapı yatırımı ilk başlık. Ne zaman kiralamak, ne zaman satın almak mantıklı? Amortisman süresi, elektrik ve soğutma, yedek donanım, arıza anında geçiş planı. Kâğıt üzerinde ucuz görünen kiralamanın hangi yük profilinde pahalıya döndüğü ve tersi. Bu hesabın en can alıcı tarafı, kullanımın sabit mi dalgalı mı olduğu. Cevap değişince mimari de değişiyor.

İkinci başlık yapay zekâ modellerinin kendi donanımda çalıştırılması. Hangi model boyutu hangi bellekle çalışır, bir sorgunun gerçek gecikmesi nedir, dışarıya veri göndermeden ne kadarını halledebilirsiniz? Bu alanda pazarlama gürültüsü yüksek olduğu için ölçümlü yazı ihtiyacı da yüksek. Alanya yazılım ve altyapı ekibimizin son iki yıldaki en büyük yatırımı da tam bu başlıkta yapıldı.

Üçüncü başlık veri egemenliği ve KVKK. Verinin fiziksel olarak nerede durduğu, hangi ülkenin hukukuna tabi olduğu, alt yüklenicilerin kim olduğu ve bir denetimde nelerin belgelenmesi gerektiği. Yurt dışındaki bir servise gönderilen her istek, aynı zamanda bir hukuki soru. Bu yazılım blogu içindeki en teknik olmayan ama en çok sonuç doğuran konu başlığı bu.

Dördüncü başlık yedekleme mimarisi. Kaç kopya, kaç konum, kaç sürüm; geri dönüş hedefi ne kadar; tatbikat ne sıklıkla yapılıyor? Yedek almak kolay, geri yüklemek zordur ve aradaki fark ancak felaket anında öğrenilir. Beşinci başlık arama motoru görünürlüğü: teknik düzeltmelerin ne zaman okunmaya başladığı, iç bağlantı yapısı, sayfa hızının payı. Altıncısı ölçüm ve analitik — hangi verinin gerçekten karar değiştirdiği, hangisinin yalnız panoyu doldurduğu. Antalya yazılım ve otelcilik projelerinde bu iki başlık genelde birlikte gündeme geliyor.

Yedinci başlık ağ ve erişim tarafı: misafir ağının ayrılması, kayıt yükümlülükleri, uzaktan çalışan personelin bağlantısı. Sekizincisi sıkıcı görünen ama en çok soru gelen konu — dosya paylaşımı ve ortak çalışma alanı. Kimin hangi klasöre eriştiği, sürüm çakışmalarının nasıl çözüldüğü, verinin şirket dışına çıkmadan paylaşılabilmesi. Alanya yazılım ekibimizin kendi günlük işini de aynı yapı üzerinde yürütmesi yazılara doğrudan yansıyor: kullanmadığımız bir kurulumu tavsiye etmiyoruz. Bir yazılım blogu için en sağlam ölçüt bu olsa gerek.

Yayındaki yazı: bir milyon liralık donanım kararının gerekçesi

Şu an yayında olan yazı Yapay Zeka Sunucu Yatırımı: 1.000.000 TL'lik Mac Studio Filosu başlığını taşıyor. İçeriği bir duyuru gibi başlıyor, gerekçe bölümünde başka bir şeye dönüşüyor: müşteri verisinin dışarıya çıkmaması ve dışa bağımlı yapay zekâ kullanımının sıfıra indirilmesi için kendi donanımımıza yatırım yapıldı. İki Mac Studio, iki ayrı iş yükü için yapılandırıldı.

Yazının değerli kısmı rakam değil, gerekçe zinciri. Neden kiralamak yerine satın alma? Hangi model hangi bellekle çalıştırılıyor, hangi iş yükü hangi makineye düşüyor, bu kararın geri dönüşü nasıl hesaplandı? Bir müşterinin sözleşmesinde "veriler yurt dışına çıkmayacak" maddesi varsa, o madde bir cümle değil bir donanım faturasıdır. Yazı tam olarak bunu anlatıyor.

Bu tür bir yatırımın herkese uyduğunu söylemiyoruz. Kendi donanımında model çalıştırmak elektrikten soğutmaya, yedek parçadan nöbet planına uzayan bir sorumluluk zinciri getiriyor; küçük ölçekte kiralamak hâlâ daha akıllıca. Karar, işlenen verinin hassasiyetine ve kullanım yoğunluğuna bakılarak veriliyor. Antalya yazılım tarafındaki bir otel için doğru olan çözüm ile bir hukuk bürosu için doğru olan çözüm aynı değil. Bir kurumsal yazılım şirketi olarak kendi kararımızı yazmamızın sebebi tavsiye vermek değil, gerekçeyi görünür kılmak.

Yazının içinde bir tablo var. İki makine, iki çip, iki bellek yapılandırması ve her birine düşen iş yükü. Okunması iki dakika süren, arkasında haftalarca hesap olan türden bir tablo. Hangi model hangi bellekte sığıyor, hangi iş gece hangisi gündüz çalışıyor, elektrik ve soğutma tarafı nereye oturuyor. Özü şu: yatırım duyurusu değil, kapasite planı. Rakamı görmek isteyen rakamı bulur. Asıl mesele rakamın altındaki hesap.

Aynı yazı İngilizce olarak da yayımlandı; yurt dışındaki iş ortaklarımızın aynı gerekçe zincirini okuyabilmesi için. Yeni yazılar takvimle değil, anlatmaya değer bir karar çıktığında yayımlanıyor. Bir yazılım blogu için haftalık yayın sözü vermek kolay; o sözü tutmak için içerik uydurmak da kolay. İkisini de yapmıyoruz.

Sıkça sorulan sorular

Ne sıklıkta yazı yayımlıyorsunuz?
Sabit bir takvim yok ve olduğunu söylemiyoruz. Yazı, anlatılmaya değer bir karar alındığında ya da bir kurulumdan sonra ölçülebilir bir sonuç çıktığında yayımlanıyor. Zorlama bir ritim, kaçınılmaz olarak doldurma metin üretir; ortalıkta zaten fazlasıyla var. Bu yazılım blogu az sayıda ama arkasında durulabilen yazıyla ilerliyor. Belirli bir konuyu merak ediyorsanız yazın; sırayı okuyucu talebi de belirliyor.
Yazıları kim yazıyor?
Kararı veren ve uygulayan kişi. Yayındaki yazının yazarı Devrim Tunçer ve anlatılan yatırım kararı da kendisine ait. Metni sahadan uzak bir içerik ekibine yazdırmıyoruz, çünkü ölçümü yapmayan kişinin yazdığı cümlede koşul kaybolur. İstanbul yazılım ve altyapı taraflarındaki çalışmalarda da aynı kural geçerli: yazan, işin içinde olan.
Yazılardaki rakamlar ve donanım bilgileri gerçek mi?
Gerçek. Tutar, model adı, bellek miktarı ve tarih yazıldığı gibi. Bunları yazmak bir risk barındırıyor — birkaç yıl sonra eskiyecekler ve o zaman herkes kararın tutup tutmadığını görebilecek. Risk kasıtlı. Sınanamayan bir metnin okuyucuya faydası da sınırlı kalıyor. Yanlış çıkan bir tahmin varsa sonraki yazıda düzeltiliyor, sessizce silinmiyor. Düzeltme notu tarihiyle birlikte duruyor; bir yazılım blogu için en zor ama en gerekli alışkanlık bu.
İçerikleri yapay zekâ mı üretiyor?
Hayır. Yapay zekâ modellerini günlük işlerde kullanıyoruz, kendi sunucularımızda çalıştırıyoruz ve bu konuda yazıyoruz; yazının kendisini modele yazdırmak ise başka bir iş. Bir modelin ürettiği metin, veri kümesindeki ortalamayı tekrar etme eğilimindedir ve tam da bu yüzden sahadan çıkan aykırı bulguyu yazamaz. Bu yazılım blogu zaten o aykırı bulgular için var. Model, taslak düzenlemek ya da terminoloji kontrolü gibi işlerde yardımcı; karar ve gerekçe insana ait.
Buradaki bir yaklaşımı kendi işletmemize uyarlamak istiyoruz, nasıl ilerliyoruz?
Önce koşulları karşılaştırmak gerekiyor. Bir yazıdaki mimari sizin veri hacminizde, kullanıcı sayınızda ve bütçenizde aynı sonucu vermeyebilir; metinlerde koşulları açık yazmamızın sebebi de bu. Kısa bir görüşmede mevcut durumunuza bakıp yaklaşımın uyup uymadığını söyleyebiliyoruz. Uymuyorsa nedenini de söylüyoruz. Bir kurumsal yazılım şirketi için en pahalı hata, kendi yazdığı çözümü her işletmeye giydirmeye çalışmak.
Yazılar İngilizce de yayımlanıyor mu?
Evet, site iki dilli ve yayındaki yazının İngilizce sürümü de mevcut. Çeviri otomatik değil; teknik terimlerin karşılığı kontrol edilerek hazırlanıyor, çünkü yanlış çevrilmiş tek bir terim bütün gerekçeyi bozabiliyor. Yurt dışıyla çalışan işletmeler için bu ayrım işe yarıyor. Antalya yazılım ve turizm tarafındaki müşterilerimizin bir kısmı zaten yabancı ortaklarıyla aynı belgeyi paylaşmak istiyor; iki dilli yayın o paylaşımı kolaylaştırıyor.