Cihazdaki model ve saha filosu: firmware gibi güncellemek, sohbet gibi değil

Red Hat binlerce cihazdaki modelleri yönetme konusunu açtı, Hugging Face iPhone ya da Mac'teki uygulamanın yerel modelle çalıştığı kütüphanenin 1.0 sürümünü yayımladı, NVIDIA sekiz masaüstü DGX Spark'ı nasıl bağlayacağını gösterdi, n8n ise böyle tek bir kutuda küçük bir şirketin bütün model setini bulut API'si olmadan topladı. Birkaç sahası olan işletme sahibi için asıl soru şu: her birindeki modeli kim ve nasıl güncelleyecek.

Neler yayımlandı

Red Hat 20 Ekim'de uç bilişimde yapay zeka için MLOps hakkında bir yazı yayımladı: model optimize edilip paketlendikten sonra yönetim soruları kalıyor. Hangi sürüm nerede çalışıyor ve bütün filoda olay çıkarmadan nasıl güncellenir. Elimde yalnızca yazının başı var, bu yüzden Red Hat'in cevaplarını aktarmıyorum.

Hugging Face 20 Ekim'de Apple Foundation Models çerçevesinin yerine geçen AnyLanguageModel 1.0'ı yayımladı: import satırını değiştiriyorsunuz ve aynı oturum kodu sistem modeliyle, llama.cpp, MLX ve Core ML üzerinden açık modellerle ya da OpenAI, Anthropic, Gemini ve Ollama gibi bulut sağlayıcılarıyla çalışıyor. Araç çağırma ve yapılandırılmış çıktı bütün sağlayıcılarda çalışıyor. API anahtarı string değil fonksiyonla veriliyor, böylece uygulama kendi sunucusundan kısa ömürlü token alabiliyor. Başlangıç için Gemma 4 E2B, yaklaşık 3,4 GB, ve LFM2.5 2.6B, yaklaşık 1,7 GB, öneriliyor; ikisi de iPhone'a sığıyor. Qwen3.8 27B yaklaşık 16 GB tutuyor ve 32 GB bellekli Mac istiyor.

NVIDIA 22 Ekim'de GTC Berlin'de yüzlerce gigabayt bellek isteyen modeller için en fazla sekiz DGX Spark düğümünü bağlama imkânını duyurdu. Bu bir duyuru, ayrıntı az.

n8n 19 Ekim'de 128 GB paylaşımlı bellekli tek bir DGX Spark üzerinde küçük bir şirketin iş akışları için bütün modellerin nasıl tutulduğunu gösterdi: sohbet ve veri çıkarma Qwen3.6-35B-A3B üzerinde, embedding'ler, reranker, konuşma için Whisper, belgeler için GLM-OCR, görsel üretimi ve konuşma sentezi; hepsi LiteLLM üzerinden tek bir OpenAI uyumlu adreste, ekip başına anahtarlarla. Yazar, kliniğin, hukuk bürosunun ya da muhasebecinin müşteri verilerini çoğu zaman bulut API'sine gönderemediğini yazıyor ve rakam veriyor: tek kullanıcı için saniyede 120 token, sekiz kullanıcıda toplam 359. Benim için en yararlı kısım disiplinle ilgili. Her model bir kez indiriliyor ve tam commit models.lock'a yazılıyor, konteynerler sürüme sabitleniyor, imajın içindeki vLLM sürümü başlatmadan önce kontrol ediliyor. Yazarın nightly etiketi beş aylık çıktı, içinde vLLM 0.19 vardı ve model bozuk checkpoint'e benzeyen bir hatayla yüklenmedi.

Örnek: iki sahalı çiftlik

İki sahası ve her sahada kontrolcüleri olan bir çiftliği ele alalım. Diyelim ki sahalarda fotoğraftan bitki hastalığını tanıyan küçük bir model duruyor. Bir sahada güncellendi, diğerinde güncellenmedi. Bir ay boyunca iki saha da “her şey yolunda” gönderiyor, ama farklı kurallara göre. Farkı bir ay sonra bulurlar ve kimse hangi sürümün nerede, hangi günden beri durduğunu hatırlamaz.

Cihazdaki model firmware gibi yönetilmeli: sürüm numarasıyla, her cihazdaki kurulum tarihiyle, geri alma planıyla. Buluttaki sohbeti sizin yerinize güncelliyorlar; sahanızdaki modeli siz güncelliyorsunuz.

Bende nasıl çalışıyor

2023'ten beri ABD'deki bir hidroponik çiftliğin sunucusundan ve ağından sorumluyum. Ekipmanı 2 sahada Raspberry Pi tabanlı 25 kontrolcü yönetiyor. Sahaların ağlarının genel IP'si yok, bu yüzden ters proxy'ler, NAT, firewall ve VPN kurdum; Google Cloud'da Debian üzerinde MariaDB'li sunucunun bütün kontrolcüleri gördüğü tek bir ağ çıktı. Kontrolcülerden veriler veritabanına geliyor, komutlar geri gidiyor: sulama, pompalar.

Kontrolcülerdeki sistem kapalı. REST API'si yoktu, yalnızca yerel soketler. Bu arayüzün nasıl kurulduğunu çözdüm ve üzerine sunucuyla entegrasyonu kurdum; bu bağlantı bugün de çalışıyor. Otomasyon mantığını ve arayüzü başka bir ekip yapıyor; bende ağ, veritabanı, güncellemeler ve destek var. Buna kendim DevOps diyorum.

Bu iş bana güncellemeleri önceden planlamayı öğretti: güncellemeleri ve hata ayıklamayı uzaktan, aynı ağ üzerinden, tek sunucudan yürütüyorum. Çiftlikte sahada bir model gerekseydi, onu kontrolcülerin diğer yazılımlarıyla aynı yoldan yönetirdim: sürüm, tarih, cihaz, geri dönüş yolu. Bu haberlerdeki donanımı ve stack'leri kendimde denemedim.

Ben ne yapardım

Her cihazda hangi model sürümünün ve hangi konteynerin durduğunu bilen tek bir sunucu kurardım. Çiftlikte kontrolcü verileri zaten MariaDB'li tek sunucuya gidiyor; sürüm kaydını da orada tutardım.

Sürümleri n8n'in models.lock'u gibi bir dosyayla sabitlerdim ve yalnızca ona göre başlatırdım. İnternetsiz sahada latest etiketi hiçbir anlam taşımaz.

Kademeli güncellerdim: bir cihaz, bir saha, hepsi. Kademeler arasında eski ve yeni sürümün sonuçlarını aynı veriler üzerinde karşılaştırırdım.

Geri alma yolunu olay sırasında değil, güncellemeden önce denerdim.

Modelin yerinde ne yapacağına, neyin yine de sunucuya gideceğine karar verirdim. Fotoğrafı sahada tanımak mümkün; bitki partisiyle ne yapılacağı kararını ise iki sahanın da göründüğü yerde vermek daha iyi.

İlgili yazılar

Sisteme durumu tutan ve işlemeyi koordine eden ortak bir merkezin neden gerektiğini Sunucu: veri, erişim ve sürecin yürütülmesi yazısında anlattım. Hizmet alanları: sera ve hidroponik otomasyonu ve ekipman izleme ve bildirimler. Projenin kendisi: ABD'de hidroponik çiftlik: 2 sahada 25 kontrolcü. Komşu yazılarım: kendi model ile API arasında yönlendirme, tek sunucuda gözlemlenebilirlik ve 30 kişilik şirket için zero trust. Daha önce cihazdaki modelin yayımlanmasının tek hızlı cevaptan daha önemli olduğunu ve endüstriyel arşivin yanındaki analitiği yazmıştım. Birkaç sahada ekipmanınız varsa ve oraya model koymayı düşünüyorsanız, orada şu an neyin durduğunu ve nasıl güncellendiğini anlatın. Görevi konuşalım.