Eigen Radar — Watt

Watt: Strata’da kısa kuyruk, daralan uzman önbelleği — Strata’s shorter queue takes memory from its expert cache

Mon, 05 Oct 2026 00:00:00 +0000

Yerel çıkarımda eşzamanlı oturumlar bekleme süresini azaltırken GPU belleğini yeniden bölüştürüyor. Strata’nın geliştirici ölçümleri, aynı kartta toplam çıktı ile erken hizmet arasında bir tercih ortaya koyuyor.

Aynı kartın iki hizmet hedefi

Strata’da dört konuşmanın birlikte çalışması, GPU belleğini yeniden paylaştırıyor. Yerel çıkarım motorunun geliştiricisi, RTX 5070 üzerindeki Q2_0 deneyinde son isteğin başlama süresini 11,2 saniyeden 1,8 saniyeye indirdiğini bildiriyor. Aynı denemede toplam üretim hızı saniyede 70,7 belirteçten 63,1 belirtece düştü. Bekleyen kullanıcı daha erken hizmet alırken kartın toplam çıktısı azaldı. Bu iki sonuç, aynı donanımda farklı hizmet hedeflerine karşılık geliyor.^[1]

Her açık oturum uzman önbelleğinden 0,56 GiB alıyor. Modelin kullandığı uzman parçalarını GPU’da tutan bu alan daraldığında, eşzamanlılık için yer açmanın bedeli mevcut işin hızına yansıyor. Geliştirici, tek isteğin bile iki yuva açıkken yüzde 11, dört yuva açıkken yüzde 22 yavaşladığını bildiriyor. Kart aynı kart; daha fazla oturum açmak, model parçaları için ayrılmış bellekle kullanıcı oturumlarının belleğini birbirine rakip hale getiriyor.^[1]

Benim buradan çıkardığım işletme tercihi şu: bir kartın verimini değerlendirirken toplam belirteç üretimiyle sıradaki kullanıcının bekleyişini birlikte ölçmek gerekiyor. Kısa süreli bir istek yığılmasında daha erken başlama değerli olabilir; sürekli yoğun işte toplam çıktının düşmesi daha ağır basabilir. Bellek açıklaması bu tercihe somut bir neden veriyor. Bununla birlikte, oturumları birlikte yönetmenin yazılım gideri de yavaşlamaya katkı yapabilir; açıklanan deney bu etkileri ayrı ayrı ölçmüyor.^[1]

Belleği ayırmak, donanımda çalıştırmak

Strata bu yüzden eşzamanlılığı isteğe bağlı tutuyor ve uzmanların çoğu GPU belleğine sığıyorsa öneriyor. Uzun istem, parça sınırında kısa isteğe yol verebiliyor; boş yuva kalmadığında yeni konuşmalar bekliyor. Tek başına kalan istek sırayla işleme yoluna dönüyor. Kullanıcının önündeki tercih, bilgisayarda daha çok konuşma açarken hangi belleği ve hangi bekleme süresini önceliklendireceği.^[1]

Donanımın genişlemesi de farklı teslim aşamalarında. Pascal ve Volta için CUDA 12.9 motoru derlenmiş durumda; geliştiricinin elinde bu kartlar bulunmuyor. Intel Arc yolu Linux’ta kaynak koddan derleniyor, çekirdek testleri CPU aygıtında yapılmış ve hazır Intel motoru sunulmuyor. Yeni seçenekleri kullanacak kişi, kendi kartında çalışan uygulamaya ulaşmak için deneysel yoldan geçiyor. Derlemenin tamamlanması, o kartta sürdürülen hizmet kapasitesinin ölçülmesinden önceki aşama.^[1]

Bir sonraki yararlı karşılaştırmada aynı kart, model ve istemler korunup eşzamanlı oturum sayısı değiştirilebilir. Toplam üretim hızı, son isteğin başlama süresi ve önbelleğe ayrılan bellek birlikte verildiğinde, daha kısa kuyruğun hangi çıktı bedeliyle geldiği anlaşılır. Strata’nın bu sürümünde kararın merkezi, mevcut GPU belleğinin bölüşümü. Sıraya öncelik veren kurulumla toplam üretime öncelik veren kurulum, aynı karttan farklı hizmet almayı seçiyor.^[1]

Kaynakça

[Haber kaynağı] Strata · 4 Ekim 2026 — Strata, yerel çıkarıma eşzamanlı istek ve Responses API desteği ekledi ↩1 ↩2 ↩3 ↩4 ↩5 ↩6

Concurrent local inference redistributes GPU memory while reducing waits. Strata’s developer measurements expose a choice between aggregate output and earlier service on the same card.

Two service objectives on one card

Running four conversations together in Strata redistributes GPU memory. The local inference engine’s developer reports that the final request started after 1.8 seconds rather than 11.2 seconds in a Q2_0 experiment on an RTX 5070. In that same experiment, combined generation speed fell from 70.7 to 63.1 tokens per second. The waiting user received service sooner while the card produced less overall. Those outcomes describe different service objectives on the same hardware.^[1]

Each open session takes 0.56 GiB from the expert cache, the GPU space holding expert components used by the model. Shrinking that space to accommodate concurrency imposes a cost on the work already running. The developer reports that even a lone request slowed by 11 percent with two slots enabled and 22 percent with four. The card is unchanged; opening more sessions makes session memory compete with memory allocated to model components.^[1]

My operational reading is that a card’s usefulness should be judged using both total token production and the next user’s wait. Earlier starts may matter during a short burst of requests; reduced aggregate output may weigh more heavily under sustained load. The memory explanation gives that choice a concrete mechanism. Software overhead from managing sessions together could also contribute to the slowdown, however; the published experiment does not measure those effects separately.^[1]

Allocating memory and delivering hardware support

Strata therefore keeps concurrency optional and recommends it where most experts fit in GPU memory. A long prompt can yield to a shorter request at a chunk boundary, new conversations wait when no slot is free, and a lone request returns to the sequential path. The practical choice is which memory allocation and waiting-time objective to prioritise when opening more conversations on the computer.^[1]

Hardware expansion is also at several delivery stages. A CUDA 12.9 engine has been compiled for Pascal and Volta, but the developer has neither card family. The Intel Arc path builds from source on Linux, its kernel tests used a CPU device, and no packaged Intel engine is supplied. Users of these options take an experimental route to an application running on their own card. Completing a build precedes measuring sustained service capacity on that device.^[1]

A useful next comparison would hold the card, model and prompts constant while varying concurrent sessions. Reporting combined generation speed, the last request’s start delay and memory allocated to the cache together would show the output cost of a shorter queue. In this Strata release, the central decision concerns allocation of existing GPU memory. A setup prioritising the queue and one prioritising aggregate production choose different services from the same card.^[1]

References

[News source] Strata · October 4, 2026 — Strata adds concurrent local inference and Responses API support ↩1 ↩2 ↩3 ↩4 ↩5 ↩6

Watt: BitNest’te hızın paydası eylem süresi — BitNest’s speed needs an action-time denominator

Mon, 05 Oct 2026 00:00:00 +0000

Aynı ağırlıkları paylaşmak bellek kazancı sağlıyor. OpenVLA deneyinde ise başlangıç işleme maliyeti, daha hızlı belirteç üretimini toplam eylem gecikmesine taşıyamıyor.

Kısa üretim, uzun eylem

BitNest’in OpenVLA-7B deneyinde aynı robotik eylemin belirteç üretim aşaması 135,6 milisaniyeden 100,8 milisaniyeye düşüyor. Fakat toplam eylem süresi 201,5 milisaniyeden 212,7 milisaniyeye çıkıyor. Araştırmacıların kendi ölçümünde hızlanan bölüm, kullanıcının beklediği bütün işi hızlandırmıyor. Görsel kodlama bu iki toplamın da dışında; açıklanan sınır içinde bile kazanç kayboluyor. Bir kontrol sistemi için karşılaştırılacak sayı, yalnızca son altı belirtecin üretim hızı değil, eylemi hazırlamakla üretmek arasındaki toplam bekleyiş.^[1]

Başlangıç işleme aşaması 65,9 milisaniyeden 111,7 milisaniyeye çıkıyor. Makale bunun mekanizmasını da veriyor: küçük matrisli üretim yolu paketlenmiş düşük bitli ağırlıkları doğrudan okuyor; büyük başlangıç matrislerinde mevcut uygulama ağırlıkları FP16 biçimine açıp cuBLAS kullanıyor. Niceleme ve diğer dönüşümlerin ek işi burada kalıyor. Sonuç, bellek trafiğini azaltan gösterimin her hesaplama aşamasında aynı verimi sağlamadığını gösteriyor.^[1]

Bellekteki kazancı ayrı tutalım

Bu gecikme sonucu, BitNest’in bellek kazanımını silmiyor. Taslak 4 bitlik tabanı okuyor; doğrulayıcı ek düzeltme düzlemiyle 8 bitlik gösterime erişiyor. Ayrı taslak ağırlığı saklanmıyor. Jetson Orin NX 16 GB üzerinde LLaMA-2-7B-32K için PyTorch tepe ayırması FP16 ile 13,9 GiB, W8A8 ile 8,2 GiB, BitNest ile 7,7 GiB. Aynı deneyin sistem genelindeki tepe belleği de raporlanıyor. Tahsis edilen model belleğiyle cihazın bütün bellek kullanımını eşitlemek bu farkı saklıyor.^[1]

Jetson karşılaştırmasında tek doğru payda da yok: FP16 ayrı bir hassasiyet noktası, W8A8 ise zaten sıkıştırılmış taban. Araştırmacıların verdiği üretim hızları sırasıyla 6,0 ve 7,8 belirteç/saniye; BitNest 9,0–9,3 aralığında. Belleği dar bir cihazda ikinci fark daha doğrudan karar desteği sağlıyor, çünkü niceleme kazancını taslak düzeninin ek kazancından ayırıyor. Alternatif açıklama, hızın yalnızca iç içe gösterimden değil, ayarlanmış bellek okuma çekirdeklerinden de gelmesi; makale bu çekirdek iyileştirmesini ayrıca ölçüyor.^[1]

Karar cihazdan ve işten çıkıyor

Donanımı seçen ekip için bu çalışma iki ayrı mühendislik sonucu taşıyor: sınırlı belleğe sığan uzun bağlam ve eylem başına toplam gecikme. Jetson’da çalıştırılabilir bağlamın büyümesi, OpenVLA’daki başlangıç yükünü ortadan kaldırmıyor; robotik deneydeki yavaşlama da dil modeli belleğindeki tasarrufu hükümsüz bırakmıyor. BitNest bir ön baskı ve bu ölçümler araştırmacıların düzeneğine ait. Uygulama seçiminin dayanağı, aynı cihazda aynı işin bütün aşamalarıyla karşılaştırılması. Darboğazın adı bu örnekte bellekten başlangıç işlemeye geçiyor.^[1]

Kaynakça

[Haber kaynağı] arXiv · 5 Ekim 2026 — BitNest, taslak ve doğrulayıcı modeli tek ağırlık gösteriminde birleştiriyor ↩1 ↩2 ↩3 ↩4 ↩5

Shared weights deliver a memory gain. In the OpenVLA experiment, prefill overhead prevents faster token decoding from becoming a faster complete action.

Shorter decoding, longer action

In BitNest’s OpenVLA-7B experiment, decoding for the same robotic action falls from 135.6 milliseconds to 100.8 milliseconds. Yet total action time rises from 201.5 milliseconds to 212.7 milliseconds. In the researchers’ own measurements, the faster component does not accelerate the complete job. Visual encoding is excluded from both totals, so the gain disappears even within that disclosed boundary. For a control system, the relevant comparison is the combined wait for preparing and generating an action, rather than just the rate of producing its final six tokens.^[1]

Prefill rises from 65.9 milliseconds to 111.7 milliseconds. The paper explains the mechanism: small-matrix decoding reads packed low-bit weights directly, whereas the current large-matrix prefill path dequantizes weights to FP16 and uses cuBLAS. Quantization and other transformations remain additional work. A representation that reduces memory traffic therefore does not deliver the same benefit in every computational phase.^[1]

Keep the memory gain separate

The latency result does not erase BitNest’s memory gain. Drafting reads a 4-bit base and verification adds a refinement plane to recover an 8-bit representation. No separate draft-weight copy is stored. On Jetson Orin NX 16 GB, LLaMA-2-7B-32K has reported PyTorch peak allocations of 13.9 GiB with FP16, 8.2 GiB with W8A8 and 7.7 GiB with BitNest. System-wide peak memory is reported separately in that experiment. Equating allocated model memory with all device memory would conceal that distinction.^[1]

There is more than one useful denominator on Jetson: FP16 is a different precision point, while W8A8 is already a compressed baseline. The researchers report decoding rates of 6.0 and 7.8 tokens per second respectively, with BitNest at 9.0–9.3. For a memory-constrained device, the latter comparison is more directly useful because it separates quantization savings from the additional drafting gain. An alternative explanation is that acceleration comes partly from tuned memory-access kernels rather than nesting alone; the paper separately measures that kernel improvement.^[1]

The decision follows the device and workload

For a team choosing hardware, the study provides two separate engineering outcomes: longer executable context within limited memory, and total latency per action. The larger context on Jetson does not remove OpenVLA’s prefill overhead; slower robotic actions do not invalidate the language-model memory savings. BitNest is a preprint and these measurements belong to the researchers’ setup. An implementation decision rests on comparing the same complete workload on the same device. In this example, the bottleneck moves from memory traffic to prefill.^[1]

References

[News source] arXiv · October 5, 2026 — BitNest nests draft and verifier in one weight representation ↩1 ↩2 ↩3 ↩4 ↩5

Watt: SpAx'in hesabı, GPU'ya taşınan baytta başlıyor — SpAx starts its speed ledger at the GPU memory boundary

Mon, 05 Oct 2026 00:00:00 +0000

GPU belleğine sığmayan ağırlıkları daha seçici okumak, yerel modelin aktarım yükünü azaltıyor. Kazancı belirleyen, okunan veriyle yeniden oluşturma süresinin ve kabul edilen kalitenin toplamı.

Belleğin dışındaki yol

SpAx, GPU belleğine sığmayan bir dil modelini çalıştırırken beklemenin nerede biriktiğini gösteriyor: ağırlıklar ana bellekten ya da depolamadan tekrar tekrar taşınıyor. İşlemcinin önündeki hesap, her belirteç için bu yolu izleyen bayt miktarı. Yeni ön baskıdaki yöntem, etkinleşmenin büyüklüğüne göre ağırlığı özgün biçimde okuyor, iki bitlik yaklaşık değerini alıyor veya hiç okumuyor. Küçük katkıları tümüyle silmek yerine bir ara düzey açıyor.^[1]

Bu işin fiziksel sınırı, GPU ile dış bellek arasındaki bağlantı. Araştırmacılar llama.cpp üzerinde RTX 4090, PCIe 4.0 x8, 128 GB ana bellek ve NVMe depolama kullandı. Girdi metni yoğun biçimde işlendi; seçici aktarım yanıt üretirken devreye girdi. Karşılaştırma aynı modelin aynı ağırlık biçimindeki yoğun üretimine dayanıyor. Böylece daha az veri taşımanın etkisi, başka bir GPU satın almanın etkisinden ayrı görülebiliyor.^[1]

Ana bellekten okumayla depolamadan okumak farklı işler. SpAx, birlikte kullanılan sütunları yan yana koyup bitişik okuma aralıklarını birleştiriyor. Depolamanın kaba okuma boyutu, küçük bir sütun seçilmiş olsa da daha fazla bayt taşıtıyor. İki bitlik değeri GPU üzerinde yeniden oluşturmak da süre tüketiyor. Bu nedenle en az baytı okuyan biçim her durumda en hızlı biçim çıkmıyor; kazanç, aktarım süresiyle yeniden oluşturma süresinin toplamında belirleniyor.^[1]

İşe yarar hızın paydası

Yerel model çalıştıran kullanıcı için çıkarımım şu: belleğe sığmama sorununun bir bölümü, ağırlıkları taşıma düzenini değiştirerek hafifletilebilir. Bunun karşısında başka bir olasılık var: kısıtlı GPU belleği altında dikkat verisi veya başka hesaplar süreyi belirleyebilir. Deneylerde sözcük gömme, çıktı katmanı ve dikkat önbelleği GPU'da kaldı. Deneyin kazancı, bu parçaları da dış belleğe taşımak zorunda olan bir kurulumun kazancı olarak okunamaz.^[1]

Kalite hesabı da taşınan veriyle birlikte duruyor. SpAx, WikiText-2 üzerinde dil modelinin sözcük dizilerine verdiği olasılığı, ayrı görevlerde ise yanıt doğruluğunu sınadı. Ağırlıkların okunmayan veya yaklaşık okunan kısmı hatasız bir sıkıştırma değil. Yerel kullanımda kabul edilen kalite sınırı, işe yarar üretim hızının paydasını değiştiriyor. Sadece daha az bayt aktarmak, kullanıcıya aynı doğrulukta daha çok yanıt verildiğini söylemeye yetmiyor.^[1]

Bu yöntem için somut mühendislik basamağı, tekli üretimde çalışan araştırma uygulaması. Yeni bir kurulumun hesabında modelin hangi kısmının GPU'da kaldığı, belirteç başına gerçekten taşınan bayt ve yaklaşık ağırlığın yeniden oluşturulma süresi birlikte yer almalı. NVMe tarafında seçilen baytlarla okunan baytların ayrılması özellikle gerekli. SpAx'in gösterdiği fırsat, mevcut donanımda ağırlık aktarımını değiştirmek; ölçülen sınır da aynı aktarım yolunu ve kaliteyi koruyan iş yükü.^[1]

Kaynakça

[Haber kaynağı] arXiv · 5 Ekim 2026 — SpAx, GPU dışındaki ağırlıkları seçerek okuyup bellek aktarımını azaltıyor ↩1 ↩2 ↩3 ↩4 ↩5 ↩6

Selective weight reads ease transfers for a model that exceeds GPU memory. Useful speed depends on bytes moved, reconstruction time and the accepted quality tolerance.

The route outside GPU memory

SpAx locates a concrete wait inside a language model that exceeds GPU memory: weights repeatedly travel from system memory or storage. The relevant unit is bytes moved for each generated token. The new preprint assigns each weight column to an original, two-bit approximate or unread tier according to activation magnitude. The middle tier preserves contributions that a binary read-or-skip decision would discard.^[1]

The physical boundary sits between the GPU and external memory. The researchers used llama.cpp with an RTX 4090, PCIe 4.0 x8, 128 GB of system memory and NVMe storage. Prompts were processed densely; selective transfers applied during decoding. Comparisons use dense decoding of the same model in the same weight format. That isolates the transfer strategy from a change in GPU hardware.^[1]

System-memory transfers and storage reads are different operations. SpAx places jointly accessed columns together and merges adjacent read ranges. Coarse storage granularity can move more bytes than a selected column needs. Reconstructing two-bit approximations also consumes GPU time. The format reading the fewest bytes therefore does not always run fastest; the gain depends on transfer time plus reconstruction time.^[1]

The denominator of useful speed

My implication for a local-model user is that changing the weight-transfer policy can ease one part of an oversized model's burden. An alternative bottleneck is attention state or other computation under tighter GPU-memory limits. The experiments retain embeddings, the output head and the attention cache on the GPU. Their benefit cannot be assigned unchanged to a setup that must also offload those components.^[1]

Quality travels alongside that byte ledger. SpAx evaluates language-model perplexity on WikiText-2 and accuracy on separate downstream tasks. Skipping or approximating weight columns is a lossy intervention. An acceptable quality tolerance changes the denominator of useful generation speed. Fewer transferred bytes alone do not establish more answers at unchanged accuracy.^[1]

The concrete engineering milestone is a research implementation operating at batch-one decoding. A deployment account needs the model components retained on the GPU, bytes actually moved per token and time spent reconstructing approximations together. For NVMe, selected bytes and bytes physically read deserve separate entries. SpAx demonstrates a way to feed existing hardware differently, within the measured transfer path and quality boundary.^[1]

References

[News source] arXiv · October 5, 2026 — SpAx reduces offloaded-weight transfers with selective approximation ↩1 ↩2 ↩3 ↩4 ↩5 ↩6

Watt: Terafab’da sahiplik ve üretim bilgisi ayrı masalarda — Terafab separates ownership from operating expertise

Sun, 04 Oct 2026 00:00:00 +0000

TSMC görüşmelerindeki olası yapılar, fabrikanın sermayesini sağlayan taraf ile üretim sürecini işleten tarafın farklı olabileceğini gösteriyor.

Sermaye ve müşteri taahhüdü

Terafab’ın masasında iki ayrı katkı var: çip isteyen şirketlerin sermayesi ve bu çipi üretebilen kuruluşun işletme bilgisi. Elon Musk, TSMC ile görüşüldüğünü doğruladı. Tom’s Hardware’ın aktardığı olası yapılardan birinde TSMC fabrikaya sahip olup tesisi işletiyor; SpaceX/Terafab ise yatırım, belirli hacimde çip alım garantisi veya ikisini birlikte sağlıyor. Bu yapıdaki alım garantisi ile sermaye aynı işi yapmıyor: sermaye kuruluş maliyetini, alım taahhüdü ise kurulmuş fabrikanın müşterisini ilgilendiriyor.^[1]

İkinci senaryoda SpaceX çoğunluk payına sahip, TSMC ise daha küçük bir yatırımla üretim teknolojisini ve işletme uzmanlığını getiriyor. Sahiplik oranı değişse de teknik katkı yine TSMC’ye dayanıyor. Bana göre burada fabrika sahibi olmak ile üretim sürecini bağımsız biçimde yönetebilmek arasındaki ayrım öne çıkıyor. Çoğunluk payı karar gücü sağlayabilir; aynı senaryoda dışarıdan gelen süreç ve işletme bilgisi, bu kararların üretime çevrilmesini sağlıyor. Bu, görüşmelerin ortak fabrikaya varacağını söylemez: yalnızca çip alımı veya paketleme üzerinden daha dar bir ilişki kurulması da mümkün.^[1]

Üretim sürecinin işletmecisi

Intel’in adı Terafab’a 1,4 nanometre sınıfındaki 14A üretim teknolojisini sağlama planında geçiyor. TSMC görüşmeleri bu rolü henüz değiştirmiş değil. İki şirketin aynı haberde yer alması, Terafab’ın iki üretim sürecini birden kullanabildiği anlamına da gelmiyor. TSMC’nin olası katkısı çip üretimiyse üretim süreci seçimi önem kazanıyor; ileri paketlemeyse Intel’in üretim süreciyle farklı bir aşamada buluşması mümkün. Bunlar iki farklı tedarik yapısı. Üretim ve paketlemeyi tek bir ortaklık başlığında toplamak, hangi aşamanın kimin sorumluluğunda olduğunu belirsizleştiriyor.^[1]

Terafab’ın açıklanan müşteri hedefi Tesla, SpaceX ve xAI’a özel silikon. Bu nedenle anlaşmanın mühendislik açısından anlamı, fabrikanın adından çok müşteri taahhüdü ile üretim sorumluluğunun birbirine nasıl bağlandığında yatıyor. TSMC’nin fabrikayı işlettiği bir düzenleme, bu şirketlere ayrılmış tedarik sağlayabilir ama üretim uzmanlığını aynı işletmeciye bağlar; mevcut dökümhanelerden çip satın almak ise fabrika yatırımını üstlenmeden talebi karşılayan alternatif. Terafab’ın bu iki yol arasında nerede durduğu, üretim sürecini ve işletmeciyi belirleyen bir sözleşmede somutlaşır. Bugünkü görüşme teyidi bu sözleşmenin yerine geçmiyor.^[1]

Kaynakça

[Haber kaynağı] Tom’s Hardware · 3 Ekim 2026 — Musk, Terafab için TSMC ile görüşüldüğünü doğruladı ↩1 ↩2 ↩3 ↩4

The possible structures in TSMC talks put fab capital and production operations in different hands.

Capital and customer commitments

Two distinct contributions sit at the Terafab negotiating table: capital from companies that want chips, and operating expertise from the company that can make them. Elon Musk has confirmed discussions with TSMC. In one possible structure reported by Tom’s Hardware, TSMC owns and operates the facility while SpaceX/Terafab provides investment, guaranteed chip purchases or both. Capital and a purchase commitment do different jobs here: one concerns the cost of establishing the fab, the other its customer once it exists.^[1]

In a second scenario, SpaceX holds the majority stake while TSMC contributes a smaller investment, process technology and operating expertise. Ownership changes, but the technical contribution still comes from TSMC. My reading is that owning a fab and independently managing its production process are separate forms of control. A majority stake can provide decision-making authority; externally supplied process knowledge and operations turn those decisions into production. This does not establish that the talks end in a jointly owned fab: a narrower purchase or packaging relationship remains possible.^[1]

The production-process operator

Intel is named in plans to supply Terafab with its 1.4-nanometre-class 14A process technology. The TSMC talks have not confirmed a change to that role. Seeing both companies in the report does not establish that Terafab can use two manufacturing processes. If TSMC’s contribution concerns chip fabrication, process selection matters; if it concerns advanced packaging, the relationship could sit downstream of Intel’s manufacturing process. These are different supply structures. Folding fabrication and packaging into a single partnership label obscures which company carries responsibility for each stage.^[1]

Terafab’s stated customer goal is custom silicon for Tesla, SpaceX and xAI. The engineering significance of an agreement therefore rests on how customer commitments connect to production responsibility, more than on the fab’s name. A TSMC-operated arrangement could provide dedicated supply while tying manufacturing expertise to that operator; buying chips from existing foundries is the alternative that meets demand without taking on a fab investment. Terafab’s position between those routes becomes concrete in a contract defining the process and operator. Today’s confirmation of discussions does not supply that contract.^[1]

References

[News source] Tom’s Hardware · October 3, 2026 — Musk confirms TSMC discussions over Terafab ↩1 ↩2 ↩3 ↩4

Watt: Kırsal veri merkezlerinin haritasında önce finansman değişiyor — Financing moves first on the rural data-center map

Sun, 04 Oct 2026 00:00:00 +0000

Yüzü aşkın uygun proje, yatırım kararlarının nereye yönelebileceğini gösteriyor. Hesaplama arzına giden yol ise tesisin gerçekleşme aşamalarından geçiyor.

Araziye yönelen sermaye

Kırsal bir veri merkezi projesi, ilk olarak bir konum ve yatırım kararıdır. Searchlight Institute’ın yeni çalışması, ABD’de geliştirilmekte olan 100’den fazla merkezin genişletilen vergi programına uygun alanlarda bulunduğunu gösteriyor. Bu, projeyi finanse eden taraf için somut bir seçenek: uygun konum, özel yatırım aracıyla birlikte vergi hesabını değiştirebilir. Fakat tesisin işletme hesabına giden yol daha uzundur. Sermayenin bir yere yönelmesi ile o yerde hesaplama hizmeti üretilmesi arasına inşaat, donanım kurulumu ve elektrik bağlantısı girer. Benim için bu haberin ağırlığı, yatırım haritasının hangi aşamada değiştiğidir.^[1]

Teşvik mekanizması bu zincirin finansman tarafına dokunuyor. Bir projenin uygun nüfus sayım bölgesinde bulunması yetmiyor; avantaj için özel yatırım aracı gerekiyor. Üstelik kullanım bilgisi vergi gizliliğine girebiliyor. Dolayısıyla aynı haritada yan yana duran iki proje farklı finansman düzenlerine sahip olabilir. Konum listesini, teşvik alınmış yatırımların toplamı gibi okumak bu farkı siler. Proje sahibi açısından anlamlı hesap, seçilen finansman yapısının tesisin sermaye giderine ne yaptığıdır; elektrik ve soğutma ihtiyaçları ise tesis tasarımının ayrı yükümlülükleri olarak kalır.^[1]

Proje sayısının paydası

Çalışmanın kullandığı payda da yer seçimi hesabını etkiliyor. Searchlight, planlanan veya yapımı süren 700’den az projeyi taramış; başka geliştirme veri tabanları yaklaşık 1.500 projeye ulaşıyor. Aynı nedenle Pew’in iki oranı bir büyüme katsayısı vermiyor: faal merkezlerin yüzde 13’ü kırsal bölgelerde, planlanan tesislerde bu pay yaklaşık yüzde 67. İlk oran işletmedeki tesislerin konumunu, ikincisi proje havuzunun konumunu anlatıyor. İki havuzun tamamlanma durumları ve büyüklükleri farklı. Proje sayısından raf sayısına veya elektrik gücüne geçmek için her tesisin ölçeği ve gerçekleşme aşaması gerekiyor.^[1]

Kırsal yönelimin tek açıklamasını vergi programında aramıyorum. Daha ucuz arazi ve kentlerdeki topluluk itirazları da yer seçiminde etkili olabilir. Microsoft, Meta ve Amazon programı kullandıklarını reddediyor. Amazon ayrıca fırsat bölgesi arazisini özel olarak aramadığını ve bunu seçim ölçütlerine eklemeyi planlamadığını söylüyor. Google’ın yanıt vermemesi, bu üç şirketin açıklamalarının karşı kutbu olarak okunamaz. Buradaki belirsizlik şirketten şirkete değişiyor. Vergi uygunluğu haritası bir finansman seçeneğini görünür kılıyor; gerçek yer seçimi gerekçesi, şirketin arazi ve altyapı kararlarında aranmalı.^[1]

Kasabanın teslim takvimi

Yerel yönetim için aşamalar arasındaki ayrım iş yükünde de hissediliyor. Searchlight’tan Emily Kraschel, programın sermaye yatırımı istediğini ancak istihdam yaratma şartı koymadığını belirtiyor. İnşaat sırasında gereken insan sayısı ile faal tesisi işletmenin işi farklı. Bu yüzden yatırım teklifini değerlendiren bir kasabanın tek proje toplamı üzerinden bütün dönemleri aynı görmesi zayıf bir pazarlık zemini yaratır. Finansman koşulu, inşaat dönemi ve sürekli işletme yükü ayrı ele alındığında, yerel taraf hangi taahhüdün ne zaman karşılık bulduğunu daha açık tartışabilir.^[1]

Bu haritayı bir kapasite tahmini yerine proje havuzunun erken aşamasına açılan pencere olarak okuyorum. Teşvikten yararlanma açıklaması finansman seçeneğini netleştirir; inşaat ve bağlantı aşamalarına ilişkin bilgiler ise teslim hesabını ilerletir. Hesaplama hizmeti satın alan taraf açısından son aşama, kurulmuş tesiste iş yükünün sürdürülebilmesidir. Yüzü aşkın uygun proje, aynı anda ve aynı ölçekte hazır bir arz oluşturmaz. Kırsal yatırım seçeneğinin değerini anlamak için para hesabıyla tesisin gerçekleşme takvimini birlikte tutmak gerekir.^[1]

Kaynakça

[Haber kaynağı] WIRED · 4 Ekim 2026 — Yeni araştırma, 100’den fazla kırsal veri merkezi projesinin vergi teşvikine uygun olabileceğini gösteriyor ↩1 ↩2 ↩3 ↩4 ↩5 ↩6

More than a hundred eligible projects show where investment decisions can go. Computing supply follows the facility’s stages of delivery.

Capital directed to land

A rural data-center project begins with a location and an investment decision. Searchlight Institute’s new work places more than 100 developing US centers in areas potentially eligible for an expanded tax program. That gives the financier a concrete option: an eligible location, combined with a specialized investment vehicle, can change the tax calculation. The operating calculation sits further along the project. Construction, hardware installation and an electricity connection stand between capital directed to a site and computing services produced there. For me, the consequential part of this development is the stage at which the investment map changes.^[1]

The incentive mechanism touches the financing side of that chain. A project needs a specialized investment vehicle as well as an eligible census tract, and participation can fall under tax confidentiality. Two neighboring sites on the same map can therefore have different financing arrangements. Reading the location list as a total of subsidized investments erases that distinction. For a project owner, the useful calculation is how the chosen financing structure changes the facility’s capital expense; electricity and cooling remain separate obligations of its design.^[1]

The project-count denominator

The denominator also matters to the siting calculation. Searchlight screened fewer than 700 planned or under-construction projects; other development databases reach about 1,500. For the same reason, Pew’s two percentages do not supply a growth multiplier: 13% of operating centers are rural, compared with approximately 67% of planned facilities. The first describes the locations of operating sites, the second the locations of a project pipeline. Their completion status and population sizes differ. Moving from project counts to racks or electricity capacity requires each facility’s scale and its stage of delivery.^[1]

I would not assign the rural shift a single tax explanation. Cheaper land and opposition in urban communities offer plausible alternative reasons for choosing a site. Microsoft, Meta and Amazon deny using the program. Amazon also says it does not seek opportunity-zone land or plan to add the program to its selection criteria. Google’s lack of a response cannot be treated as the opposite of those three disclosures. The uncertainty varies by company. The eligibility map makes a financing option visible; the actual siting rationale belongs in each company’s land and infrastructure decisions.^[1]

The town’s delivery timetable

Local governments feel the distinction between stages in their workload as well. Searchlight’s Emily Kraschel notes that the program requires capital investment but has no job-creation requirement. Construction work and the work of running an operating facility belong to different periods. Treating every period through a single project total gives a town a weak basis for negotiating an investment proposal. Separating the financing condition, the construction phase and continuing operating demands makes it easier for the local side to discuss when each commitment takes effect.^[1]

I read this map as a view into the early project pipeline rather than a capacity forecast. A disclosure of incentive use clarifies the financing option; construction and connection milestones advance the delivery calculation. For the customer buying computing services, the final stage is sustaining a workload in an installed facility. More than a hundred eligible projects do not form a ready supply at one moment and one scale. Understanding the rural investment option requires keeping its financing calculation alongside the facility’s delivery timetable.^[1]

References

[News source] WIRED · October 4, 2026 — Research identifies over 100 rural data-center projects potentially eligible for tax benefits ↩1 ↩2 ↩3 ↩4 ↩5 ↩6

Watt: TopK-Guided’da kazancın birimi işlem sayısı — TopK-Guided measures its gain in operations

Fri, 02 Oct 2026 00:00:00 +0000

40 GB A100 üzerinde hesaplamanın katmanlara dağılımı değişiyor. İşlem bütçesinden GPU süresine geçiş, ayrı bir uygulama ve ölçüm aşaması.

A100 üzerinde payda

40 GB belleğe sahip bir A100, bu çalışmanın fiziksel sınırı. Mukund Agarwalla ve Chih-Jen Lin, TopK-Guided ön baskısında aynı GPU üzerinde Llama-2-7B ve Llama-3-8B için çıkarım hesaplamasını dağıtıyor. Hedefleri yüzde 30, yüzde 50 ve yüzde 70 etkinleşme seyrekliği. Bu yüzde, matris işleminden çıkarılan etkinleşmelerin payı; cihazın elektrik çekişinin veya cevap bekleme süresinin aynı oranda azalması anlamına gelmiyor. İşlem bütçesini okurken paydanın bu ayrıntısını korumak gerekiyor.^[1]

Seyreklik burada modelin ağırlıklarını kalıcı olarak silmiyor. Her belirteç için sıfıra yakın etkinleşmelerle ilişkili sütunların bir bölümü işlem dışında kalıyor. Donanımın değişmediği bir karşılaştırmada yazılımın müdahale noktası açık: aynı modelin hangi hesaplamaları yaptığını seçmek. Watt cinsinden bir sonuç çıkarabilmek için cihazın çalışma süresi ve güç ölçümü de gerekiyor. Ön baskının sunduğu ölçüm seti kayan nokta işlem sayısı ve cevap kalitesiyle sınırlı.^[1]

Kesintinin yeri değişiyor

Bütçeyi korumanın iki ayrı sorunu var. TEAL’in eşik yaklaşımında farklı belirteçler farklı işlem miktarı alabiliyor; WINA’nın sabit sayıda seçiminde ise bütçe korunurken uyarlama alanı daralıyor. TopK-Guided önce eşik altındaki etkinleşme payını kestirip hedefin bir yüzde puanlık çevresine sıkıştırıyor. Quickselect adımı korunacak etkinleşmeleri seçiyor. Böylece belirtece göre değişen seçim ile önceden belirlenmiş hesaplama sınırı aynı düzende tutuluyor.^[1]

Katmanlar da eşit kesinti almıyor. Yoğun ve seyrek çıktılar arasındaki normalize edilmiş hata, kırılgan blokları belirliyor. Erken ve duyarlı bloklarda daha fazla etkinleşme tutulurken sonraki dayanıklı blokların hesaplaması azalıyor; toplam bütçe değişmiyor. Buradaki mühendislik katkısı, aynı işlem payını her yere dağıtmanın yerine hesaplamayı hatanın daha ağır olduğu yerde korumak. Kazanç, yeni bir çipin kapasitesinden önce mevcut hesaplamanın dağıtımında aranıyor.^[1]

Çekirdekten hizmet kapasitesine

Yazarların yüzde 70 seyrekli Llama-3-8B deneyinde sekiz görevin ortalama doğruluğu TopK-Guided için yüzde 57,85, WINA için yüzde 55,34 ve TEAL için yüzde 52,64. Bu karşılaştırmanın değeri, aynı model ve seyreklik hedefinde dağıtımın kaliteyi değiştirmesi. Buradan daha büyük modellerin veya farklı iş yüklerinin aynı sonucu verdiği çıkarılamıyor. 7B ve 8B modeller, kullanılan GPU ve bu görevler ölçümün kapsamını belirliyor.^[1]

İşlem sayısından hizmet kapasitesine geçişin eksik halkası çalışan çekirdek. Yazarlar hızlı çekirdek uygulamasını sonraki çalışmaya bırakıyor; uçtan uca gecikme ve enerji tasarrufu ölçmüyor. Dolayısıyla bu sonuçla bir veri merkezinin kaç ek isteği karşılayabildiğini hesaplamak mümkün değil. TopK-Guided’ın bugün gösterdiği, sabit işlem bütçesinin daha dikkatli dağıtılabildiği. GPU zamanına dönüşümün ayrı ölçümü, bu dağıtımın işletme giderine katkısını belirleyen aşama.^[1]

Kaynakça

[Haber kaynağı] arXiv · 1 Ekim 2026 — TopK-Guided, dil modeli çıkarımında seyrekliği işlem bütçesine bağlıyor ↩1 ↩2 ↩3 ↩4 ↩5 ↩6

Computation is reallocated across layers on a 40 GB A100. Moving from an operation budget to GPU time requires a separate implementation and measurement stage.

The denominator on an A100

An A100 with 40 GB of memory is this study’s physical boundary. In the TopK-Guided preprint, Mukund Agarwalla and Chih-Jen Lin allocate inference computation for Llama-2-7B and Llama-3-8B on that GPU. Their targets are 30%, 50% and 70% activation sparsity. Those percentages describe activations excluded from matrix computation; they do not establish corresponding reductions in the device’s electricity draw or answer latency. The denominator belongs to the operation budget.^[1]

Sparsity here does not permanently erase model weights. For each token, some columns associated with near-zero activations are left out of computation. With hardware held fixed, the software intervention is explicit: choosing which computations the same model performs. A result in watts also requires operating-time and power measurements. The preprint’s measurement set is confined to floating-point operation counts and output quality.^[1]

Moving the computational cut

Keeping the budget has two separate problems. TEAL’s threshold approach can assign different amounts of computation to different tokens, while WINA’s fixed-count selection preserves the budget with less adaptation. TopK-Guided first estimates the share of activations below the threshold and clips it within one percentage point of the target. Quickselect chooses which activations to retain. Token-dependent selection and a predefined computation limit therefore operate within the same arrangement.^[1]

Layers also receive unequal reductions. Normalized error between dense and sparse outputs identifies fragile blocks. More activations remain in sensitive early blocks, while robust later blocks take larger cuts; the total budget stays fixed. The engineering contribution is to preserve computation where its removal causes more error, instead of spreading the same cut everywhere. The gain concerns allocation of existing computation before it concerns capacity from another chip.^[1]

From a kernel to service capacity

In the authors’ Llama-3-8B experiment at 70% sparsity, average accuracy across eight tasks is 57.85% for TopK-Guided, 55.34% for WINA and 52.64% for TEAL. The comparison shows allocation affecting quality under the same model and sparsity target. It does not establish the same result for larger models or different workloads. The 7B and 8B models, the GPU and these tasks define the measurement boundary.^[1]

The missing link between operation counts and service capacity is an execution kernel. The authors leave a fast kernel implementation for subsequent work and provide no end-to-end latency or energy-savings measurement. Their result therefore cannot calculate how many additional requests a data center can serve. What TopK-Guided demonstrates today is more selective allocation of a fixed operation budget. Separate measurement of the conversion into GPU time determines the contribution to operating expenditure.^[1]

References

[News source] arXiv · October 1, 2026 — TopK-Guided ties inference sparsity to a compute budget ↩1 ↩2 ↩3 ↩4 ↩5 ↩6

Watt: Vera Rubin rafı çalışıyor; sayı yalnızca Cognition’ın işine ait — Vera Rubin is running; its throughput figure belongs to Cognition’s workload

Wed, 30 Sep 2026 00:00:00 +0000

CoreWeave, Vera Rubin sistemini Cognition’ın üretim yüküne taşıdı. Bu, donanım çizelgesinden çalışan kümeye geçiş; bildirilen hız artışı ise belirli bir iş yükünün ölçümü.

Rafın geçtiği eşik

CoreWeave’in Vera Rubin NVL72 duyurusundaki somut basamak, Cognition’ın sistemi üretim çıkarımında kullanması. Küme eylül başında kuruldu; Cognition mühendisleri kendi SWE-2 iş yüklerinde GB200 NVL72 kümesine karşı deneme yaptı. Aradaki fark bir sevkiyat vaadi ile müşteri çalışması arasındadır. Yine de hizmet sınırlı erişimde: bir müşterinin çalışan kümesi, bulutun bütün müşterileri için hazır ve ayrılmış kapasite anlamına gelmiyor.^[1]

Cognition’ın bildirdiği toplam belirteç üretimi, SWE-2 çıkarımında 4,8 kat; pekiştirmeli öğrenme işinde çıktı belirteci üretimi 3,8 kat arttı. Bu iki paydanın işi farklı. İlk sonuç, kodlama aracısının çıkarım yükünde iki raf kuşağını karşılaştırıyor. İkinci sonuç başka bir çalışma düzenine ait. Bu sayıları tek bir genel Vera Rubin hızı gibi okumak, iş yükü ve ölçüm sınırını kaybettirir. Şirketin daha önceki DeepSeek R1 için megavat başına bildirdiği sonuç da üçüncü ve ayrı bir deneydir.^[1]

Ölçümden kapasiteye

Aynı yönetim araçlarıyla GB200, GB300 ve Vera Rubin kümelerini çalıştırmak CoreWeave için gerçek bir işletme avantajı olabilir. Müşteri yeni donanımı kendi araç zincirini baştan kurmadan kullanabildiğinde devreye alma aralığı kısalabilir. Alternatif açıklama da açık: Cognition’ın kendi iş yükü ve ekibinin hazırlığı geçişi özellikle hızlandırmış olabilir. Duyuru, başka müşterilerde aynı sürenin ya da aynı başarımın tekrarlandığını ölçmüyor.^[1]

Bundan sonraki ölçülebilir basamak, farklı müşterilerin tanımlanmış iş yükleriyle Vera Rubin üzerinde düzenli hizmete alınması ve erişimin sınırlı kümenin ötesine genişlemesidir. Bir rafın çalıştığı artık açıklanmış durumda; bu rafın kaç müşteriye, hangi gecikme hedefiyle ve ne kadar süreyle hizmet verdiği ise duyuruda yer almıyor. Bu yüzden 4,8 katlık sonuç, Cognition’ın bildirdiği üretim sınaması olarak değerli; bütün bulut filosunun verimlilik bilançosu olarak kullanılamaz.^[1]

Kaynakça

[Haber kaynağı] CoreWeave · 30 Eylül 2026 — CoreWeave, Vera Rubin NVL72 üzerinde Cognition iş yüklerini çalıştırmaya başladı ↩1 ↩2 ↩3 ↩4

CoreWeave has moved Vera Rubin into Cognition’s production work. That is a step from hardware roadmap to operating cluster, while the reported throughput gain measures one workload.

The rung the rack has reached

The concrete milestone in CoreWeave’s Vera Rubin NVL72 announcement is Cognition running production inference on the system. The cluster was set up in early September, and Cognition engineers tested their SWE-2 workload against a GB200 NVL72 cluster. That moves the claim from a shipment plan to a customer workload. Access remains limited, though: one operating customer cluster does not establish ready, reserved capacity for every cloud customer.^[1]

Cognition reported 4.8 times the total token throughput on SWE-2 inference and 3.8 times the output-token throughput on a reinforcement-learning workload. Those are different denominators attached to different jobs. The first compares rack generations on the coding agent’s inference load. The second belongs to another execution pattern. Neither is a universal Vera Rubin speed figure. CoreWeave’s separate DeepSeek R1 result per megawatt is a third experiment and should be read on its own boundary.^[1]

From measurement to capacity

Running GB200, GB300, and Vera Rubin clusters under the same management tools may be an operational advantage for CoreWeave. A customer able to use new hardware without rebuilding its toolchain may shorten deployment time. There is another plausible explanation: Cognition’s own workload and preparation may have made this particular transition unusually quick. The release does not measure whether other customers reproduce the same timing or performance.^[1]

The next measurable rung is more customers entering sustained service on Vera Rubin with defined workloads and access expanding beyond the limited cluster. An operating rack has now been announced. The release does not say how many customers a rack serves, at what latency target, or for how long. The 4.8 times result therefore matters as Cognition’s reported production test. It cannot stand in for an efficiency ledger covering the cloud provider’s entire fleet.^[1]

References

[News source] CoreWeave · September 30, 2026 — CoreWeave starts Cognition workloads on Vera Rubin NVL72 ↩1 ↩2 ↩3 ↩4

Watt: Gimlet’in hız hedefi, veri merkezi açılışına bağlı — Gimlet’s speed target depends on a data-center launch

Tue, 29 Sep 2026 00:00:00 +0000

Cerebras yongalarıyla çalışan özel bir kurulum var. Gimlet’in geniş erişim ve saniyede 3.000 belirteç hedefi ise yeni merkezin işletime alınmasına ve karşılaştırılabilir ölçümlere dayanıyor.

Önce hangi sistem çalışıyor?

Gimlet Labs ile Cerebras’ın ortaklığı, tamamen kâğıt üzerindeki bir tasarımın ilanı değil. İki şirket geçen yıldan beri müşterilerle birlikte çalıştıklarını ve bütünleşik bir sistemin özel kurulumlarda belirteç ürettiğini söylüyor. Bu, donanımla yazılımın bir araya getirildiği dar bir kullanım alanı. Bir müşterinin özel ortamında yanıt üretmek, herkese açık bulut hizmetinin aynı yükü sürekli taşıdığı anlamına gelmiyor.^[1]

Sıradaki fiziksel basamak, Cerebras donanımıyla çalışan ilk Gimlet Cloud veri merkezinin açılması. Şirketler bunu yıl bitmeden bekliyor. Duyuru, veri merkezinin işletime alındığını veya geliştiricilerin aynı hizmete genel erişim kazandığını söylemiyor. Kurulum, doğrulama ve üretim işletimi de ortaklığın ilerideki çalışma alanları arasında. Dolayısıyla bugünkü somut teslim, özel kullanımda çalışan bütünleşik sistem; yeni merkez ayrı bir takvim hedefi.^[1]

Hızı hangi sınırda ölçeceğiz?

Mimari, Cerebras’ın Wafer Scale Engine sistemini GPU’larla birleştiriyor. Gimlet, çıkarımın farklı aşamalarını uygun yongalara dağıtacak yazılımdan söz ediyor. Bu düzen, tek bir donanımın bütün işi yapması yerine aşamalar arasında yönlendirme gerektiriyor. Buradaki mühendislik sınaması yalnızca bir yonganın hızlı belirteç üretmesi değil; aşamalar arası geçişte gecikmenin ve toplam kapasitenin nasıl değiştiği. İş yükü arttığında yönlendirme gideri veya veri aktarımı baskın hâle gelebilir; açıklama bunu ölçmüyor.^[1]

Şirketlerin saniyede en fazla 3.000 belirteç hedefi, açılacak hizmet için ileri sürülüyor. Açıklamada bu değeri karşılaştırmaya yarayacak model, eşzamanlı istek yükü, gecikme sınırı ve güç tüketimi birlikte verilmiyor. Bu bilgiler olmadan sayı, veri merkezinin sürdürülen çıktısı veya başka bir hizmetten üstünlük kanıtı sayılamaz. Gimlet’in sonraki anlamlı açıklaması, merkezin açılışıyla birlikte bu ölçüm sınırlarını ve gerçek kullanımda ulaşılan hızı göstermesi olur. Böylece hedef, özel kurulumdaki ilk işaretten müşterilerin kullanabildiği bir hizmetin sınanabilir sonucuna geçer.^[1]

Kaynakça

[Haber kaynağı] Gimlet Labs · 28 Eylül 2026 — Gimlet, Cerebras çiplerini yapay zekâ çıkarım bulutuna katma planını duyurdu ↩1 ↩2 ↩3 ↩4

A private deployment already serves tokens on Cerebras hardware. Gimlet’s broader service and target of 3,000 tokens per second depend on a new data center and measurements with a clear workload boundary.

What is running now?

Gimlet Labs and Cerebras have more than a design proposal: they say joint customer work began last year and an integrated system is serving tokens in private deployments. That establishes a narrow operating rung for their hardware and software together. Serving a private customer does not establish that a broadly available cloud service can sustain the same workload.^[1]

The next physical rung is the first Gimlet Cloud data center powered by Cerebras, which the companies expect before year-end. The release does not report that it has opened or that developers broadly have access to that service. Installation, validation and production operations remain in the partnership’s work plan. Today’s delivered step is the integrated private deployment; the new center has a separate timetable.^[1]

What boundary measures speed?

The proposed architecture combines Cerebras’ Wafer Scale Engine with GPUs. Gimlet describes software that assigns different inference phases to suitable chips. The design therefore has to move work between phases rather than run the entire request on one kind of processor. Its engineering test is more than a fast token stream from one chip: latency and total capacity across the phase boundary matter. Routing or data movement could become a constraint under load; the announcement does not measure that possibility.^[1]

The companies propose up to 3,000 output tokens per second for the future service. The release does not supply a model, concurrent request load, latency limit and power draw together for a comparable measurement. Without those boundaries, the figure cannot establish sustained data-center output or superiority over another service. A useful next disclosure from Gimlet would pair the center’s opening with those measurement conditions and the speed achieved in actual use. That would move the target from an early private deployment to a testable result for a service customers can access.^[1]

References

[News source] Gimlet Labs · September 28, 2026 — Gimlet plans to add Cerebras systems to its AI inference cloud ↩1 ↩2 ↩3 ↩4