[Misc] Update v0.7.0 remaining tasks (#39)

Signed-off-by: Jiaxin Shan <seedjeffwan@gmail.com>

Author: Jeffwan

content/posts/2026-06-16-single-node-pd.md

@@ -1,6 +1,6 @@
 ---
-date: '2026-06-16T12:00:00-00:00'
-draft: true
+date: '2026-06-16T14:00:00-00:00'
+draft: false
 title: 'AIBrix KVCache: Optimizing Single-Node P/D Disaggregation'
 author: ["The AIBrix Team"]
 

content/posts/2026-06-16-v0.7.0-release.md

@@ -1,6 +1,6 @@
 ---
 date: '2026-06-16T12:00:00-00:00'
-draft: true
+draft: false
 title: 'AIBrix v0.7.0 Release: Management Console, Self-Hosted Batch, KV-Centric Disaggregation, and a Highly-Available Gateway'
 author: ["The AIBrix Team"]
 
@@ -17,22 +17,13 @@ ShowToc: true
 tocopen: true
 ---
 
-<!--
-Pre-publish checklist (remove before publishing):
-  [ ] Reconcile "182 merged PRs" / "21 first-time contributors" with GitHub's auto-generated v0.7.0 release notes.
-  [ ] Fill Batch cost teaser: [N×] and [X tokens/month], and set the Batch Cost Study URL.
-  [ ] Replace /images/v0.7.0-release/* Console screenshots and hero diagram with real captures.
-  [ ] Re-verify every config snippet (incl. ModelDeploymentTemplate YAML) against the final tagged code.
-  [ ] Confirm the v0.8.0 roadmap issue link.
--->
-
 # 🚀 AIBrix v0.7.0 Release
 
 The pieces that make large-scale LLM inference fast — multi-engine serving, prefill/decode disaggregation, KV-cache reuse, high-throughput batch, multi-cloud GPU capacity — mostly exist already as discrete parts. The harder problem is making them compose into one platform: a KV path that serves both offload and disaggregation instead of two, a gateway that stays correct when it's replicated, an engine choice that isn't hard-wired, and an operational surface that doesn't require a standing Kubernetes-and-Envoy team to drive.
 
 **AIBrix v0.7.0** is our broadest release yet — it advances the platform on every layer of the stack at once: how you **operate** it (a new Console), the **workloads** it runs (a rebuilt Batch plane), the **engines and data plane** underneath (first-class TensorRT-LLM, plus a **KV-cache-centric** disaggregated serving path that does transfer *and* reuse in one store), and the **gateway** in front (composable routing, a P/D-disaggregation router refactored across engine / KV-transfer / worker-selection axes, now highly available). Adopt the layers you need.
 
-This release lands **182 merged PRs** over three months. For the complete list of changes, commit history, and contributor details, see the [**AIBrix v0.7.0 Release Notes**](https://github.com/vllm-project/aibrix/releases/tag/v0.7.0).
+This release lands **242 merged PRs** over three months. For the complete list of changes, commit history, and contributor details, see the [**AIBrix v0.7.0 Release Notes**](https://github.com/vllm-project/aibrix/releases/tag/v0.7.0).
 
 ## v0.7.0 Highlight Features
 
@@ -84,30 +75,58 @@ batch = client.batches.create(
     # Optional AIBrix extension — omit it and the job runs on the default template.
     extra_body={
         "aibrix": {
+            "job_id": "job_21799a92-6674-42fe-b7d0-fb58f651d9e6",
+            "runtime": {
+                "target": "Kubernetes"
+            },
+            "resource_allocation": {},
             "model_template": {
-                "engine":       {"type": "vllm"},                  # vllm | sglang | trtllm
-                "model_source": {"type": "huggingface", "uri": "meta-llama/Llama-3.3-70B-Instruct"},
-                "accelerator":  {"type": "H100", "count": 4},
-                "parallelism":  {"tp": 4},
-                "quantization": {"weight": "fp8"},
-                "resource":     {"provider": "kubernetes"},        # kubernetes | lambda | runpod
-            }
+                "name": "L20",
+                "version": "v1.0.0",
+                "spec": {
+                    "engine": {
+                        "type": "vllm",
+                        "version": "0.20.0",
+                        "image": "vllm/vllm-openai:latest",
+                    },
+                    "model_source": {
+                        "type": "hdfs",
+                        "uri": "hdfs://..../models/Qwen3.6-27B-Merlin-HF"
+                    },
+                    "accelerator": {
+                        "type": "NVIDIA-L20",
+                        "count": 1,
+                        "vram_gb": 48
+                    },
+                    "parallelism": {
+                        "tp": 1,
+                        "pp": 1,
+                        "dp": 1
+                    },
+                    "quantization": {},
+                    "supported_endpoints": [
+                        "/v1/chat/completions"
+                    ],
+                    "deployment_mode": "dedicated"
+                }
+            },
+            "model": "Qwen/Qwen3.6-27B"
         }
-    },
+    }
 )
 ```
 
 Under the hood, AIBrix runs the standard `validating → in_progress → finalizing → completed` lifecycle with `custom_id` matching, a 24-hour completion window, and pluggable storage backends (S3, TOS, Redis, or local). Because the datastore — not Kubernetes annotations — is the source of truth, jobs survive restarts and scale across workers.
 
-**The economics — why run batch on your own GPUs.** Batch is where self-hosting pays off most: it's latency-tolerant, so jobs pack GPUs to high utilization and soak up the idle capacity your online fleet leaves on the table. For workloads where an open model (Qwen, GLM, Kimi, DeepSeek) clears your quality bar, running it on AIBrix Batch lands around **[N×] cheaper per token** than the capability-matched closed-API batch tier once you're past roughly **[X tokens/month]** — below that, a managed API is still cheaper, and cold-start overhead matters. We work through exactly where that crossover sits — open vs. closed, managed vs. self-hosted, including the much cheaper Chinese-vendor APIs — in a companion deep-dive: [**AIBrix Batch Cost Study →**](#). <!-- TODO: fill [N×] / [X tokens/month] and set the study URL -->
-
 The optional `model_template` shown above is the model-centric part: it pins exactly how a given model runs — `engine` (vLLM, SGLang, or TRT-LLM), `model_source`, `accelerator`, `parallelism`, and `quantization` — while everything outside the `aibrix` key stays the standard OpenAI Batch contract, so existing SDKs and tooling keep working. Templates are reusable and versioned (keep a prod and an experimental variant side by side), and the same job can run as an in-cluster Kubernetes Job, on a long-lived Deployment acting as a worker, or — new in v0.7.0, in preview — on rented cloud GPUs (below).
 
 ### Running batch on cloud GPUs — Lambda Cloud & RunPod (preview)
 
 When your own cluster is full — or you don't have one — v0.7.0 can run a batch job on **rented cloud GPUs**. This is powered by a new **Resource Manager**: a pluggable provisioning layer (registry/provider pattern, idempotent `Provision`/`Release`/`List`) with three providers — **Kubernetes**, **Lambda Cloud**, and **RunPod** ([#2248](https://github.com/vllm-project/aibrix/issues/2248)). For an external provider it leases a GPU box, then the batch runtime brings up the engine over SSH and streams your job through it. You target one with a single field in the same `model_template` from the superset above — set `resource.provider` to `lambda` or `runpod` instead of the default `kubernetes`, with everything else in the payload unchanged and no SSH, leasing, or provisioning details in the request. From the caller's side, "run this batch on a rented RunPod box" is one field — the Resource Manager handles leasing, bring-up, and teardown behind it.
 
-> **Preview — honesty note.** The production-honored execution path today is **in-cluster Kubernetes**. The RunPod and Lambda Cloud runtimes and Resource-Manager providers ship in v0.7.0 and are wired end-to-end, but multi-cloud execution is still rolling out — treat cloud execution as preview, and it's deliberately scoped to **batch / offline** workloads, not online serving. *When* renting cloud GPUs for batch actually beats a managed API — and by how much — is the subject of our companion [Batch Cost Study](#).
+> **Preview — honesty note.** The production-honored execution path today is **in-cluster Kubernetes**. The RunPod and Lambda Cloud runtimes and Resource-Manager providers ship in v0.7.0 and are wired end-to-end, but multi-cloud execution is still rolling out — treat cloud execution as preview, and it's deliberately scoped to **batch / offline** workloads, not online serving.
+
+**The economics — why run batch on your own GPUs.** Batch is where self-hosting pays off most: it's latency-tolerant, so jobs pack GPUs to high utilization and soak up the idle capacity your online fleet leaves on the table. For workloads where an open model (Qwen, GLM, Kimi, DeepSeek) clears your quality bar, you keep your data **in-cluster**, pay **no per-request fee**, and your marginal cost is just the GPUs you already run. On raw token price the cheapest closed *batch* tiers can be very competitive — but the numbers we publish come from a deliberately **basic, un-tuned deployment**: a floor we expect to push down with higher batching, quantization, and the KV-reuse and P/D paths in this very release, not a verdict. We map out where the crossover sits — open vs. closed, managed vs. self-hosted, including the much cheaper Chinese-vendor APIs, and how far optimization moves the line — in a companion deep-dive AIBrix Batch Cost Study which comes soon.
 
 ## Multi-Engine: TensorRT-LLM Joins vLLM and SGLang
 
@@ -204,7 +223,13 @@ Yes. Local mode runs the gateway, router, and KV cache without a cluster, and Re
 
 ## Contributors & Community
 
-This v0.7.0 release includes **182 merged PRs**, with **21** from first-time contributors 💫. <!-- TODO: reconcile "182" and "21" with GitHub's auto-generated release notes before publishing -->
+This v0.7.0 release includes **242 merged PRs**, with **27** from first-time contributors 💫. Thank you to everyone who helped shape this release through code, issues, reviews, and feedback.
+
+We're excited to welcome the following new contributors to the AIBrix community:
+
+[@jasonlee-1024](https://github.com/jasonlee-1024), [@Lucas-Qian6](https://github.com/Lucas-Qian6), [@xvchris](https://github.com/xvchris), [@NJX-njx](https://github.com/NJX-njx), [@DhyeyTr](https://github.com/DhyeyTr), [@gabrnavarro](https://github.com/gabrnavarro), [@tmchow](https://github.com/tmchow), [@Peakpine](https://github.com/Peakpine), [@naroam1](https://github.com/naroam1), [@Yang1032](https://github.com/Yang1032), [@DaveLi8086](https://github.com/DaveLi8086), [@Genmin](https://github.com/Genmin), [@ianliuy](https://github.com/ianliuy), [@HeyZackWang](https://github.com/HeyZackWang), [@zhutong196](https://github.com/zhutong196), [@justinchen033](https://github.com/justinchen033), [@Jing-ze](https://github.com/Jing-ze), [@NelZyhh](https://github.com/NelZyhh), [@JustAnotherDevv](https://github.com/JustAnotherDevv), [@xiaoyu-xyz](https://github.com/xiaoyu-xyz), [@arnavnagzirkar](https://github.com/arnavnagzirkar), [@SarthakB11](https://github.com/SarthakB11), [@whalepark](https://github.com/whalepark), [@JinKim48](https://github.com/JinKim48), [@jan-stanek](https://github.com/jan-stanek), [@V-3604](https://github.com/V-3604), [@DebugSy](https://github.com/DebugSy) 🙌
+
+Your contributions continue to make AIBrix more scalable, production-ready, and welcoming as an open community. We're excited to see the ecosystem grow—keep them coming!
 
 Beyond the code, the community took real steps toward maturing the project this cycle — a [Call for Adopters](https://github.com/vllm-project/aibrix/issues/1719) and discussion of a formal release team and ownership model. Thank you to everyone who filed issues, reviewed PRs, and shipped features.
 
@@ -216,4 +241,4 @@ We're continuing to push AIBrix toward a fully production-grade, self-service, c
 - **High-density GPU pooling** — Control-plane orchestration of vLLM sleep mode and kvcached for warm-standby, multi-model GPU sharing ([#2290](https://github.com/vllm-project/aibrix/issues/2290)).
 - **Hardening the platform** — Graduate the Console, Batch API, and Resource Manager from preview to production, including a deployment provider abstraction ([#2198](https://github.com/vllm-project/aibrix/issues/2198)).
 
-If you're running LLMs in production or exploring architectures around serverless, KV cache, P/D disaggregation, or batch, we'd love your feedback and collaboration. Check out the v0.8.0 roadmap <!-- TODO: open the v0.8.0 Roadmap issue and link it here -->, join the discussion, and contribute on [GitHub](https://github.com/vllm-project/aibrix).
+If you're running LLMs in production or exploring architectures around serverless, KV cache, P/D disaggregation, or batch, we'd love your feedback and collaboration. Check out the [v0.8.0 roadmap](https://github.com/vllm-project/aibrix/issues/2346), join the discussion, and contribute on [GitHub](https://github.com/vllm-project/aibrix).