Three public LinkedIn posts from the last two days, three layers of the agent stack moving at once: a model small enough to run agents on your own hardware, the serving layer that keeps a thousand agents fed in a data center, and the CEO of Google saying out loud that cloud revenue waits behind frontier compute. Short quotes, links and what I think. Nothing here comes from anyone's private feed.
Each item started as a public LinkedIn post; I could not open the posts themselves (LinkedIn requires a login), so every item below is verified against the public first-party source it points to: Liquid AI's model card and launch blog, the Google Cloud blog and the llm-d repository, and the Big Technology interview transcript itself. Where a number comes from the vendor's own benchmark, the item says so. Pichai's statements are interview claims, marked as such. I read these pages on October 21, 2026.
"LFM2.5-24B-A2B is a 24B-parameter reasoning model with only 2B active parameters, built for fast, private agents on-device."
Liquid AI's model card, the page the LinkedIn post pointed to. Model card · Launch blog · Original post
My take: The architecture numbers on the card check out against the post's claims: 24.0B total parameters with 2.45B active per token, 40 layers (30 double-gated short-convolution blocks plus 10 GQA attention blocks), 64 experts per MoE block with top-4 routing, a 36-trillion-token training budget, 128K vocabulary and a 131,072-token context. Post-training is supervised fine-tuning plus two multi-domain on-policy distillation stages plus agentic reinforcement learning run inside real agent harnesses (OpenClaw, Hermes Agent, Pi, OpenCode), so the model is literally trained on the tools and system prompts it will meet. The card ships six formats: native BF16, FP8, GGUF, ONNX, MLX 4-bit and a speculative-decoding draft variant. The interesting honesty is in the positioning: Liquid says plainly the model is "not recommended for knowledge-heavy tasks on its own" and should be paired with retrieval, and its own table shows it losing to Qwen3.6-35B-A3B on GPQA (74.42 vs 83.69), SWE-Bench Verified (51.0 vs 66.2) and WebArena (26.75 vs 37.62) while winning the agentic tool-use rows (LiveClaw 48.09 vs 38.19, ToolSandbox 80.71 vs 75.02). This is a tool-calling organ, not an encyclopedia - and that is the right trade for a model meant to sit inside a harness. Speed claims are vendor measurements: 184 tok/s on an Apple M5 Max and 114 on a Ryzen AI Max+ 395 (llama.cpp, Q4_K_M, 4K context), and over 21K output tok/s on a single B300 at high concurrency. The license is Liquid's own LFM Open License v1.0: royalty-free, but commercial use requires your organization's annual revenue to stay under a $10M threshold, so it is not an OSI license and bigger companies need a separate deal. As observed today, the model card shows about 16.9K downloads last month and 538 likes since the October 12 upload.
Not verified: All benchmark and speed figures are Liquid's own runs on their own harness and hardware; I did not run the model. The "competitive with a model ~50% larger" framing rests on the agentic rows of one vendor-chosen table. No training data or training code is published - the card documents the recipe stages, not the data.
"Today at the PyTorch Conference, we released llm-d 1.0, an open-source, Kubernetes-native stack for distributed LLM inference."
The Google Cloud blog, October 20, 2026, by Lohmeyer himself. Google Cloud blog · Repository (Apache-2.0) · Original post
My take: llm-d sits above vLLM and SGLang and turns a cluster of model servers into one coordinated pool: prefix-cache- and load-aware routing, tiered KV cache offload (host RAM, SSD, Google Cloud Managed Lustre), prefill/decode disaggregation orchestrated by the new DisaggregatedSet, multi-tenant flow control, and an async processor that runs batch jobs in slack capacity without starving interactive traffic. The 1.0 story is aimed squarely at agent traffic: session-aware routing keeps an agent's turns on the replicas that already hold its context, and time-slicing lets RL rollouts share accelerators with inference, which Google says lifts accelerator duty cycles from about 40% to over 70%. The numbers in the post are vendor-reported but specific: on an agentic coding workload on Ironwood TPUs, prefix-aware routing plus host-memory offload cut median time-to-first-token by more than 85% and raised throughput 2.4x versus a plain Kubernetes Service; Google's own Gemini platform doubled its prefix cache hit rate from 35% to 70% through GKE Inference Gateway; a 17,000-node multi-region deployment scaled throughput 2.9x across three clusters at 99.9% success. Customer quotes name real usage: Snap reports 75-80% prefix cache hit rates, ZenteiQ claims 4x aggregate throughput for synthetic data generation, and Mistral's inference engineers say they enforce priority bands across commercial tiers with it. The project is a CNCF Sandbox effort co-founded by Red Hat, Google Cloud, IBM Research, CoreWeave and NVIDIA, with 500+ contributors across 25 organizations; the repo carries Apache-2.0 and shows 4,917 stars and 870 forks as observed today. Worth noting what 1.0 means here: v1 APIs, router high availability and zero-downtime rolling updates - the boring parts that make a serving layer adoptable.
Not verified: Every performance figure is from Google or its partners, measured on their workloads and hardware; I did not deploy llm-d. The Gemini platform numbers describe Google's own production traffic, which is real usage but not an independent evaluation.
"Our cloud business is at any given moment in time forgoing short-term revenues because we are making compute trade-offs to support frontier AI development."
The Big Technology interview, published October 20, 2026, recorded at Google's Mountain View headquarters. Everything in this item is what Pichai said in an interview - claims by an interested party, not audited facts. Interview · Original post
My take: Three passages carry the weight. On recursive self-improvement, Pichai confirms Sergey Brin's remark that RSI contributed to the new Gemini 4 Argon model, but draws the line precisely: "today, in a continuum, we are pretty far from the end state of RSI" - what exists now is "agents helping AI researchers in some automated way work together to build these models." On demand, he says Argon processed almost 25 trillion tokens in its first 72 hours, about three times Gemini 3's launch window, and that Google is capacity constrained serving it; internally he credits Argon with a 30% increase in changelists and a one-third decrease in rollbacks in four weeks. On compute scarcity, asked about Andy Jassy's "sold out until 2028" remark, he does not flinch: a customer asking for compute in 2027 faces something "incredibly difficult," yet he rejects the dark-fiber comparison - "We are using it. We are capacity constrained on a daily basis" - while conceding overbuild is possible if any of the "2,000 components or more" (memory, electricity, electricians, land) bottlenecks. The framing I find most telling is the priority order he states outright: DeepMind's frontier compute access is "non-negotiable," the cloud business plans around what is left, and forgone cloud revenue is simply "true already." For safety watchers, his answer on agent incidents is defense in depth - alignment work plus real-time monitoring, sandboxing and, eventually, cross-industry standards with independent evaluators, "like financial controls... independent auditors."
Not verified: These are a CEO's statements in a friendly interview. The token volumes, the changelist and rollback figures, and the capacity claims are Google's own numbers with no external confirmation; the RSI assessment is a position, not a measurement.
Items are selected from public LinkedIn posts by a scanner, then each is verified against the public first-party source it references: the model card and vendor blog, the engineering blog and repository, the interview transcript. LinkedIn posts themselves require a login and were not opened; the links are provided for reference. No engagement counts are used, I did not contact the authors, and nothing here comes from a private feed.