More data centers. Higher GPU rental prices. Both can be true. Nebius raising H100 prices by 17% supports my near-term view: customers still pay a premium for compute they can actually use, including older GPUs. For $NBIS, the next test is whether higher on-demand prices become realized revenue and cash after financing and equipment investment. My article starts with Goldman’s power forecast and follows the money through five operators. Full analysis, stress tests and earnings checklists on Substack:

The moat is moving outward from the accelerator. If NVIDIA’s reported d-Matrix investment closes, startups can compete on compute while NVIDIA owns the scale-up fabric around them. NVHBM extends the same strategy into memory. NVIDIA may not need to win every accelerator socket if competing chips still expand its rack-level control.

Goldman cut its 2027 data-center capacity forecast, but raised 2026. Who gets paid sooner? This @wallstengine post⁠ sent me down the rabbit hole ( I compared $APLD, $IREN, $NBIS, $CRWV and $WULF: when capacity starts billing, where financing eats the upside, and what to watch at earnings. My takeaway: through 2027, favor funded capacity becoming revenue over announced gigawatts. The short version is below. Full calculations, stress tests and company checklists on Substack:

$AEHR 's roughly $6M follow-on orders fund equipment that heats and electrically stresses finished AI processors to screen early failures. The same customer has selected Sonoma for a second chip program. I expect successive designs to support repeat system sales and custom sockets that connect chips to the tester. The 2027 production ramp remains a customer forecast. Watch shipments over the next six months, the equipment-versus-consumables revenue mix, margins, and wins beyond this customer.

Custom silicon is becoming a financing product as much as a chip product. Broadcom is reportedly arranging more than $50B for OpenAI’s custom accelerator, with Apollo and Blackstone among potential lenders. My view: financing lowers the deployment barrier, but makes Broadcom’s moat larger than chip design. It can bundle silicon, networking, and capital. The key question is who ultimately bears residual-value risk if OpenAI’s workload or chip roadmap changes.

$NVDA's RTX Spark laptops open for preorder today. They pair hardware built for local AI with CUDA, NVIDIA's software tools for using GPUs. I expect early adoption to lean toward developers already using that ecosystem. Running a coding assistant locally with familiar tools could ease adoption and expand NVIDIA's reach in premium PCs. Preorders alone do not prove demand. Watch shipments, software compatibility, and sustained performance during real coding sessions.

The Roofline card put prefill and decode at opposite corners of one chart. Disaggregated serving takes that seriously. It gives each corner its own machines. Prefill processes the prompt tokens in parallel. It is typically compute-bound. Decode makes one token at a time, and every step reads the weights and a growing KV cache again. It is often memory-bandwidth-bound. Put both on one GPU and they share it. A long prompt can slow the chats already streaming on that GPU. Chunked prefill makes each stall shorter. It does not separate the two latency targets. You still tune one machine for two goals. Split them and each pool has one goal. You size the prefill pool for time to first token. You size the decode pool to keep tokens arriving steadily at the target load. The cost is the handoff. Prefill builds the KV cache for the request's context. Decode needs that cache, so it must cross the network. DistServe, Splitwise, Mooncake, and NVIDIA Dynamo all make this trade. They pay for a KV transfer so the two phases stop competing for the same GPU. The trade can fail. If the network is the slow part, you did not remove the bottleneck. You moved it. It is also not always needed. With short prompts or quiet traffic, one machine is fine. The split pays off when prefill takes a large share of GPU time. Don't make streaming chats wait on someone else's prompt.

My view is that early HBM4 multi-sourcing will create more system variants and qualification work before it creates truly interchangeable supply. 8hi and 12hi may both ease supply, but different thermal, mechanical, and controller constraints can keep them as separate configurations. That favors vendors that can co-optimize memory, logic, packaging, and customer qualification, not simply those with more bit capacity. The tell is whether one accelerator can qualify both stack heights inside the same performance envelope.

$AMAT supplies the equipment used to make chips. Its expanded Intel partnership includes Foveros, which stacks chips vertically and needs reliable connections between them. I expect this early work on manufacturing processes to strengthen Applied's position when customers buy production equipment. The opportunity is to help develop the recipe before factories scale up; today's release discloses no order value. Watch which jointly developed processes reach volume production, the share of working packages, and the equipment orders that follow.

Spec sheets sell FLOPS. Decode spends bytes. Single-user BF16 decode can sit at roughly 1 FLOP per byte. On an H100 SXM, that puts its theoretical ceiling near 0.3% of peak math throughput.* Batching moves the point right: more tokens share each weight read. FP8 has a twist. Halving weight bytes moves the point right, but native FP8 math doubles the compute roof too. The ridge moves with you. Decode gets faster, yet the batch needed to reach the roof stays about the same. Attention limits the gains. Each user brings a KV cache. Longer contexts mean more bytes to read, so sharing weights buys less. Smaller caches and speculative decoding can help. *Teaching estimate for weight-dominated, batch-1 decode, not measured GPU utilization.

Nokia's CEO says supply constraints are slowing AI buildouts. If one campus cannot secure enough electricity, operators may spread compute across several sites. Those sites need optical links to exchange data. I expect this to support $NOK's networking business, although communication delays limit which workloads can span distant sites. For investors, watch whether multi-site AI projects become firm orders for Nokia, when equipment ships, and whether the added revenue improves margins.

My read on $TSM: Terafab could turn a push for chip independence into demand for TSMC's manufacturing expertise. Musk has confirmed preliminary discussions. Japan offers a useful precedent: Sony, Denso and Toyota invested in JASM, TSMC's majority-owned manufacturing venture. Funding a factory is only part of the job. Producing reliable chips at scale requires process knowledge and experience improving yield: the share of chips that work. If the talks produce a deal, my base case is customer capital and demand paired with TSMC's manufacturing capabilities. That could expand TSMC's production revenue. Who pays for the capacity and commits to buying its output will determine how attractive the business becomes.

16 TB per GPU sounds like a NAND supercycle. But even 3 million GPUs newly equipped at that capacity would buy only 2.7% of projected 2028 NAND demand. My call: enterprise SSDs and NVIDIA's platform win first in 2027. Full analysis on Substack:

NVLink's most important spec is not 1.8 TB/s. It is 72, the number of GPUs in one NVLink domain. The card draws the rack and the toll bridge. Here is what it leaves out. Earlier: NVLink inside the node, RDMA across nodes. That node was eight GPUs on one HGX baseboard. NVL72 stretches the island to a full rack: 72 Blackwell GPUs reach each other through switch trays, never through a NIC. Scale-out is InfiniBand or Ethernet NICs between racks. Compare per direction. NVIDIA's 1.8 TB/s per GPU is two-way, so halve it: 900 GB/s each way against 50 GB/s for one 400G NIC per GPU. About 18x (teaching math, not a benchmark). The 36x you may see is double that; it sets the two-way 1.8 TB/s against a one-way line rate. Why serving cares: tensor-parallel all-reduce fires in every layer, and MoE all-to-all fires in every MoE layer, so every decoded token waits on the fabric. A decode step is too short to hide that wait behind compute, so it lands in per-token latency. NVIDIA's wide-EP decode example for DeepSeek-R1 uses 64 GPUs in one domain. That fits inside NVL72. Across eight-GPU nodes it still runs, but most of the all-to-all crosses the bridge. NVLink is not a faster cable. It is a bigger island.

In my Jev article, I argued that a cheap decision is only the start. An agent still has to process or reuse context, turn each choice into an action, and handle failures. This Pokémon experiment makes that system-level work visible. Jev made 16,150 choices for about $1.65 in Jev calls, while separate software read the game state, found paths, and kept the run moving. It is a game demo, not a hardware benchmark. But it is a useful picture of the question: what does the whole loop cost?

Checking five draft tokens can take about as long as generating one, when memory bandwidth is the bottleneck. At small batch sizes, decode is often memory-bandwidth-bound. Moving the weights takes most of the time. A cheap drafter proposes a short block. The target scores the whole block in one pass, so the weights it loads serve several positions instead of one. The target accepts drafted tokens from the front and stops at the first one it rejects. The same pass also gives one more token: a fix at that position, or a bonus if the whole block held. The accept rule keeps the target's output distribution, so quality does not change. How many tokens one pass gives depends on how often the draft is right. So the drafter has to be small and still right most of the time. The discount has a limit. With enough users in one batch, the GPU becomes compute-bound and the extra verify work stops being free. So DSpark, DeepSeek's design, verifies a shorter prefix under load. DeepSeek measured it under live V4 traffic, against its earlier one-token draft (MTP-1) at the same total throughput: about 60–85% faster per-user generation on V4-Flash, 57–78% on V4-Pro. That is their stack, not a number that carries over. MLA and DSA made each target step cheaper. Speculative needs fewer of them. 3/3. Builds on MLA + DSA. Related: Expert Parallelism.

Since 2017, attention has been redesigned again and again to make decode cheaper. The changes pull on two different levers. Store less per past token: MHA (2017): every head keeps its own K and V. MQA (2019): all heads share one K and V. GQA (2023): groups of heads share one. Llama 3 uses this. MLA (2024): one short learned code per token. Shared weights let the heads use it without rebuilding past K and V. DeepSeek V2 and V3. Read fewer past tokens: Sparse attention (2025): a small index scans the past, and the main attention reads only the tokens it picks. DeepSeek V3.2, built on top of MLA. KV reads have often constrained decoding. These designs trade storage, memory traffic, and computation in different ways. MLA shows that trade clearly. The card shows the cache shrinking 57x per layer against same-size MHA, while the math per byte goes up. By my rough math, that puts MLA decode on an H800 close to where compute, not memory, becomes the limit. A third lever is fewer sequential generation steps: speculative decoding, multi-token prediction, and, for tasks that need a decision rather than prose, models like Jev that return a typed answer with probabilities instead of writing text.

My starting point for studying $NVTS was understanding what power semiconductors do in AI systems. onsemi’s September 16 announcement adds another question: how are the devices, controls and packaging designed to work together? On September 16, onsemi introduced its Embedded Power Platform. It is designed to integrate silicon, SiC and GaN technologies, including power switches, drivers and controllers, within one package. Electrical, thermal and mechanical design are optimized together. Sampling is expected to begin in 2026. That makes Navitas' planned acquisition of Claros worth a closer look. Claros develops vertical power delivery and integrated voltage regulators, targeting power delivery right at the processor. These are different approaches, not a head-to-head product comparison. But both highlight why material choice alone is not enough to evaluate an AI power solution. For NVTS, expanding the portfolio is one step. Turning it into qualified customer designs is another. My next checkpoint: which specific design demonstrates an advantage, under what conditions, and what evidence shows it moving toward production? Sources: onsemi EPP announcement: Navitas / Claros announcement: