diff --git a/blog/2025-05-20_announce.md b/blog/2025-05-20_announce.md
index 04bee6905..1e9954491 100644
--- a/blog/2025-05-20_announce.md
+++ b/blog/2025-05-20_announce.md
@@ -188,7 +188,7 @@ llm-d builds brings together the performance of vLLM with the operationalizabili
We welcome AI engineers and researchers to join the llm-d community and contribute:
* Check out our repository on Github: [https://github.com/llm-d/llm-d](https://github.com/llm-d/llm-d)
-* Join our developer slack: /slack
+* Join our developer slack: /slack
* Try out our quick starts to deploy llm-d on your Kubernetes cluster: [https://github.com/llm-d/llm-d-deployer/tree/main/quickstart](https://github.com/llm-d/llm-d-deployer/tree/main/quickstart)
Please join us. The future of AI is open.
diff --git a/blog/2025-06-03_week_1_round_up.md b/blog/2025-06-03_week_1_round_up.md
index d328604d0..17c46409d 100644
--- a/blog/2025-06-03_week_1_round_up.md
+++ b/blog/2025-06-03_week_1_round_up.md
@@ -45,7 +45,7 @@ We use Google Groups to share architecture diagrams and other content. Please jo
- All SIG meetings
- Weekly Community Meeting, every Wednesday @ 12:30pm Eastern Time
* Join the [llm-d Google group](http://red.ht/llm-d-google-group) - this is where all engineering drafts are shared. You must join the group to have access to project google docs.
-* Join Slack
+* Join Slack
* [llm-d Roadmap for Q2](https://github.com/llm-d/llm-d/issues/26)
**Where to follow us on Social Media**
diff --git a/blog/2025-06-25_community_update.md b/blog/2025-06-25_community_update.md
index 1f9d590ed..fa5f02fdf 100644
--- a/blog/2025-06-25_community_update.md
+++ b/blog/2025-06-25_community_update.md
@@ -71,7 +71,7 @@ There are many ways to contribute to llm-d:
2. Review the [project public calendar](https://red.ht/llm-d-public-calendar) and join an upcoming community meeting
3. Subscribe to our [YouTube channel](https://youtube.com/@llm-d-project) for tutorials and meeting recordings
4. Fill out the [Use Case Survey](https://docs.google.com/forms/d/e/1FAIpQLScENfBNrN1q8XpugCmDUjy8sSn1cMzi_V0mCWTRwzixcPAQkw/viewform) to help shape our benchmarks
-5. Join our Slack workspace for real-time discussions
+5. Join our Slack workspace for real-time discussions
6. Check out our [Contributor Guidelines](https://llm-d.ai/community/contribute) to start contributing code
We're looking forward to hearing from you and working together to make llm-d even better!
diff --git a/blog/2025-09-24_kvcache-wins-you-can-see.md b/blog/2025-09-24_kvcache-wins-you-can-see.md
index af252efc7..e9718145c 100644
--- a/blog/2025-09-24_kvcache-wins-you-can-see.md
+++ b/blog/2025-09-24_kvcache-wins-you-can-see.md
@@ -18,7 +18,7 @@ tags: [blog, updates, llm-d]
The llm-d project provides a series of “well-lit paths” \- tested, benchmarked solutions for deploying large language models in production. Our first path, [**Intelligent Inference Scheduling**](/blog/intelligent-inference-scheduling-with-llm-d), established a baseline for AI-aware routing by balancing both cluster load and prefix-cache affinities. The default configuration for that path uses an *approximate* method for the latter, predicting cache locality based on request traffic.
-This blog illuminates a more advanced and powerful path: [**precise prefix-cache aware scheduling**](/docs/dev/guides/precise-prefix-cache-routing).
+This blog illuminates a more advanced and powerful path: [**precise prefix-cache aware scheduling**](https://github.com/llm-d/llm-d/tree/main/guides/precise-prefix-cache-routing).
We take a deep dive into the next generation of this feature, which moves beyond prediction and gives the scheduler direct introspection into distributed vLLM caches. This precision is key to maximizing cache hit rates and achieving a new level of performance and maximizing cost-efficiency in your distributed deployments.
@@ -284,7 +284,7 @@ The optimal scheduler depends on the complexity of the workload. Below is a hier
The llm-d project thrives on community contributions, and there are many ways to get involved:
* Explore the llm-d Community Quickstart Guide → [Start here](/community) to learn more about getting involved in the llm-d project.
-* Join our Slack → [Get your invite](/slack) and connect with maintainers and contributors
+* Join our Slack → [Get your invite](https://llm-d.ai/slack) and connect with maintainers and contributors
* Explore the code → Browse our [GitHub organization](https://github.com/llm-d) and find issues that interest you
* Attend meetings → All meetings are open\! Add our [public calendar](/community#public-meeting-calendar) and join discussions\`
@@ -324,4 +324,4 @@ The overhead for this global bookkeeping is that of storing KV-block hashes, and
A full KV-cache for the **DeepSeek R1** model running with FP8 on **8x** **NVIDIA H200 GPUs** with a total of **45.7 GB \* 8 \= 365 GB VRAM** dedicated to the KV-cache pool would be composed of thousands of individual memory blocks. Each block, representing **128 tokens**, consumes about **8.6 MB** of VRAM. However, the metadata needed to track each of these blocks in the global index is just a single 64-bit hash, which is **8 bytes**. The additional overhead of maintaining a data structure is trivial if efficient.
-This means that managing the entire **365 GB** cache pool requires only about **339 KB** of memory for the scheduler's index \- a data-to-metadata ratio of over **1,000,000-to-1**. The index's memory footprint is several orders of magnitude smaller than the GPU VRAM it tracks, making this a highly efficient, low-overhead solution.
\ No newline at end of file
+This means that managing the entire **365 GB** cache pool requires only about **339 KB** of memory for the scheduler's index \- a data-to-metadata ratio of over **1,000,000-to-1**. The index's memory footprint is several orders of magnitude smaller than the GPU VRAM it tracks, making this a highly efficient, low-overhead solution.
diff --git a/blog/2026-04-21_production-grade-llm-inference-at-scale-kserve-llm-d-vllm.md b/blog/2026-04-21_production-grade-llm-inference-at-scale-kserve-llm-d-vllm.md
index 958b3bf82..156412b44 100644
--- a/blog/2026-04-21_production-grade-llm-inference-at-scale-kserve-llm-d-vllm.md
+++ b/blog/2026-04-21_production-grade-llm-inference-at-scale-kserve-llm-d-vllm.md
@@ -73,7 +73,7 @@ We’d like to thank everyone from the community who has contributed to the succ
The work described here is just one example of what becomes possible when a community of engineers tackles hard problems together in the open. If you're running LLMs at scale and wrestling with the same challenges — storage, routing, efficiency, day-2 operations — we'd love to have you involved.
* **Explore the code** → Browse our [GitHub organization](https://github.com/llm-d) and dig into the projects powering this stack
-* **Join our Slack** → [Get your invite](/slack) and connect directly with maintainers and contributors from Red Hat, Tesla, and beyond
+* **Join our Slack** → [Get your invite](https://llm-d.ai/slack) and connect directly with maintainers and contributors from Red Hat, Tesla, and beyond
* **Attend community calls** → All meetings are open! Add our [public calendar](https://red.ht/llm-d-public-calendar) (Wednesdays 12:30pm ET) and join the conversation
* **Follow project updates** → Stay current on [Twitter/X](https://twitter.com/_llm_d_), [Bluesky](https://bsky.app/profile/llm-d.ai), and [LinkedIn](https://www.linkedin.com/company/llm-d)
* **Watch demos and recordings** → Subscribe to the [llm-d YouTube channel](https://www.youtube.com/@llm-d-project) for community call recordings and feature walkthroughs
diff --git a/blog/2026-06-09_heterogeneous-inference-3-vendor-sovereign-cluster.md b/blog/2026-06-09_heterogeneous-inference-3-vendor-sovereign-cluster.md
new file mode 100644
index 000000000..5c0c0101b
--- /dev/null
+++ b/blog/2026-06-09_heterogeneous-inference-3-vendor-sovereign-cluster.md
@@ -0,0 +1,135 @@
+---
+title: "Heterogeneous inference serving across three GPU vendors with llm-d"
+description: "Benchmarking llm-d's prefix-cache-aware routing across anonymized GPU pools on the NxtGen sovereign cloud, showing how one routing layer improves throughput and TTFT across single-vendor and heterogeneous fleets."
+slug: heterogeneous-inference-3-vendor-sovereign-cluster
+date: 2026-06-09T09:00
+
+authors:
+ - praveinkannan
+ - praveenjayachandran
+ - jaikhari
+ - varunraste
+ - prasadmukhedkar
+ - vinodpathangay
+ - jayanthreddy
+ - abhisyant
+
+tags: [blog, inference, scheduling, kv-cache, sig-benchmarking]
+---
+# Heterogeneous inference serving across three GPU vendors with llm-d
+
+Most production inference clusters today are single-vendor because that is often the simplest way to configure and operate a cluster.
+
+That is starting to change. Procurement cycles bring new generations alongside older ones, supply planning spans multiple accelerator options, and cost/performance profiles differ by workload. Real production fleets are accumulating heterogeneity whether or not the architecture planned for it.
+
+This is an opportunity to unlock real value: different accelerator classes can be matched to workload requirements, stranded capacity gets reclaimed, and operators gain more flexibility in capacity planning. The case is stronger still for sovereign and on-premise deployments, where data residency, regulatory alignment, and the long-term economics of high-volume inference make local fleet optimization especially important.
+
+Making that work in practice is a non-trivial systems problem. Each accelerator stack brings its own optimized drivers, firmware, container images, runtime settings, and attention kernels. A coherent serving layer needs to preserve those platform-specific optimizations while still giving operators one control plane for routing, observability, and policy.
+
+
+
+## Setup
+
+To evaluate llm-d on a heterogeneous environment, we ran experiments on the **NxtGen sovereign cloud's** mixed GPU environment, with the following accelerator pools within a single OpenShift AI cluster:
+
+| Pool | Hardware | Count |
+| :---- | :---- | :---- |
+| Vendor A | 2 nodes, each with 2 GPUs | 4 |
+| Vendor B | 1 node with 8 GPUs | 8 |
+| Vendor C | 1 node with 8 GPUs | 8 |
+
+We use anonymized labels to keep the focus on the serving-layer behavior: how llm-d routes the same workload across the accelerator pools available in this test environment. The pools differ in generation, memory capacity, runtime characteristics, and expected per-GPU performance, so the results should be read as routing-policy comparisons within each pool and across the combined fleet.
+
+All nodes are connected over a shared **100 G RoCE** network. We pinned each vLLM replica to a single accelerator card (TP = 1) to maximize the number of independent serving instances and exercise the routing layer.
+
+Models served:
+
+* `ibm-granite/granite-4.1-8b` — 8 B parameter, decoder-only dense transformer model
+* `sarvamai/sarvam-30b` — 30 B MoE, Indic-multilingual model
+
+The workload is the prefill-heavy `shared_prefix_synthetic` from [inference-perf](https://github.com/kubernetes-sigs/inference-perf): a long shared system prompt + short question + decode-tolerant output (~7.2K input tokens + 1K output tokens). This matches production RAG, chat, and citizen-services traffic profiles where prefix-cache routing is most beneficial.
+
+## What this benchmark shows
+
+This benchmark evaluates llm-d as a routing and control-plane layer over a mixed accelerator fleet. It does not compare accelerator vendors directly. Instead, it asks whether a cache-aware, saturation-aware router can make single-vendor and heterogeneous pools behave like one inference service, using the same vLLM pods for both the llm-d run and the Kubernetes round-robin baseline within each pool.
+
+The results are most relevant to operators who already have mixed capacity: sovereign cloud teams, enterprise AI platform teams, on-prem clusters, and organizations with staggered hardware refresh cycles. For these teams, the question is not a standalone accelerator ranking; it is how to route production traffic across the fleet they actually operate.
+
+## Prefix-aware caching
+
+We deployed llm-d v0.0.7 with prefix-cache-aware routing in two flavours, picked per-model rather than per-pool: **`granite-4.1-8b` runs against the [precise prefix-cache scorer](https://github.com/llm-d/llm-d/tree/main/guides/precise-prefix-cache-routing)** (tokenizer-backed, exact prefix matching), and **`sarvam-30b` runs against the approximate prefix-cache scorer** (xxhash over raw prompt bytes, no tokenizer required). The precise scorer needs a tokenizer, but sarvam's custom HF code requires `trust_remote_code=True` — a flag the v0.8.0 llm-d-router images does not pass through the UDS tokenizer sidecar. The hash-based approximate scorer bridges that gap.
+
+Each vendor's pods are deployed as a separate Helm release in the same namespace; only the `nodeSelector` and a small set of vendor-specific tuning flags (e.g. Vendor C's `--block-size 128`, `--max-num-seqs 256`, `VLLM_BUILD` pin) vary between releases. All pods carry the same selector labels and register with a single InferencePool maintained by llm-d's router. For the baseline, we use a ClusterIP service over the same set of pods to drive Kubernetes round-robin scheduling. Within each pool, the llm-d and baseline runs use the same pods, vLLM image, and serving flags; only the routing layer differs.
+
+Across every pool we tested — single-vendor (A-only, B-only, C-only) and heterogeneous (A+B, A+B+C) — **llm-d's prefix-cache-aware routing improved throughput and time-to-first-token (TTFT) compared with the k8s round-robin baseline**. The improvement grows with pool size and heterogeneity.
+
+| Pool | Pods | Model | Throughput improvement (llm-d vs k8s) | TTFT reduction |
+| :---- | :---- | :---- | :---- | :---- |
+| Vendor A only | 4 GPUs | granite-4.1-8b | +25–36% | 16× |
+| Vendor A only | 4 GPUs | sarvam-30b | 2× | 22× |
+| Vendor B only | 8 GPUs | granite-4.1-8b | +79% | 21× |
+| Vendor B only | 8 GPUs | sarvam-30b | +83% @ 200 qps (28.6 K vs 15.6 K out tok/s) | 5× |
+| Vendor C only | 8 GPUs | granite-4.1-8b | +34% | 18× |
+| Vendor A + B | 12 GPUs | granite-4.1-8b | +85% (19.4 K vs 10–11 K) | 3.4–5.6× |
+| Vendor A + B | 12 GPUs | sarvam-30b | ~3× @ 200 qps | 2.85–4.54× |
+| **Vendor A + B + C** | **20 GPUs** | **granite-4.1-8b** | **+91% @ 85 qps** | **5.4×** |
+
+**Why heterogeneous pools benefit from llm-d:** k8s round-robin spreads requests evenly regardless of current pod capacity, so lower-capacity or saturated pods can accumulate queue depth and reduce aggregate throughput. llm-d's prefix-cache-aware EPP accounts for saturation and concentrates cache hits on warm pods, so heterogeneous capacity can be used more effectively.
+
+:::note Workload caveat
+
+`shared_prefix_synthetic` is a favourable regime for prefix-cache routing: all requests share the same long system prompt, so cache hit rate on llm-d approaches 100% once a prefix is warm on a pod. Results are strongest for workloads with high prefix reuse; gains can vary with prefix diversity.
+
+:::
+
+### Single-vendor pools — granite-4.1-8b
+
+We start with the per-vendor baselines so the heterogeneous results below have a reference point. All runs use ~7.2K ISL + 1K OSL.
+
+**4× Vendor A GPUs.** llm-d improves TTFT by up to 16× compared to k8s, and output throughput by 25–36%.
+
+
+
+**8× Vendor B GPUs.** llm-d delivers up to 21× better TTFT and +79% throughput vs k8s round-robin on this Vendor B-only granite deployment.
+
+
+
+**8× Vendor C GPUs.** At saturation (rate 25), llm-d delivers +34% throughput and ~18× better TTFT compared with the k8s round-robin baseline.
+
+
+
+### Single-vendor pools — sarvam-30b (multilingual MoE)
+
+**4× Vendor A GPUs.** llm-d delivers 2× the throughput and 22× better TTFT. The k8s round-robin baseline reaches saturation between rate 15-25, while llm-d continues to scale across that range.
+
+
+
+**8× Vendor B GPUs.** k8s throughput plateaus at ~17 K out tok/s (peak at rate 175) and declines to 15.6 K at rate 200, while llm-d keeps scaling to **28.6 K out tok/s at rate 200 — +83% over k8s at the same rate** (or +65% peak-vs-peak). TTFT-wise llm-d is up to 5× faster at lower rates.
+
+
+
+We did not include sarvam-30b results on Vendor C because the model integration and the tested runtime image depended on different vLLM API versions: sarvam's `hotpatch_vllm.py` pins `vllm==0.15.0`, while the tested Vendor C image was based on vLLM 0.16. We plan to revisit with the llm-d community once the version mismatch is resolved.
+
+### Heterogeneous pool results
+
+**Vendor A + B (12 pods, granite-4.1-8b).** While k8s throughput plateaus at 10–11 K tok/s, llm-d goes up to 19.4 K — 85% higher throughput. TTFT-wise llm-d is 3.4–5.6× faster at higher rates.
+
+
+
+**Vendor A + B (12 pods, sarvam-30b).** llm-d brings down TTFT by 2.85–4.54× and increases throughput by close to 3× at rate 200. The mixed pool shows the largest gain for this model because round-robin is least aligned with heterogeneous capacity, while llm-d's prefix-aware routing adapts to the observed serving state.
+
+
+
+**Vendor A + B + C (20 pods, granite-4.1-8b).** The 20-pod 3-vendor (A + B + C) pool delivers **14.2 K out tok/s peak with llm-d vs 9.6 K with k8s round-robin**. k8s saturates at rate 25 and *declines* to 7.5 K at rate 85 (queue depth dominates) — llm-d delivers **+91% throughput at the same load**. TTFT at rate 85: llm-d 6.8 s, k8s 36.4 s (**5.4× better**).
+
+
+
+The rate ladder stopped at 85 QPS because the single-replica EPP became CPU-bound, not because the pool saturated. EPP work scales with `pod_count × QPS`, so the 20-pod 3-vendor (A + B + C) pool hits the CPU ceiling well before a smaller single-vendor pool at the same QPS. Per-pod throughput here sums to ~25 K, so the true pool ceiling is likely higher; EPP horizontal scaling (replicas: 1 → 2) or a higher CPU limit would unblock it further.
+
+## Takeaway
+
+Heterogeneous serving is useful when the routing layer understands more than endpoint count. In this workload, llm-d improves throughput and TTFT by routing with prefix-cache locality and saturation signals, while preserving the platform-specific settings each accelerator pool needs. That is the practical value for mixed fleets: operators can expose diverse capacity through one inference pool and let policy, cache state, and load shape placement decisions.
+
+## What's next
+
+**Cross-accelerator P/D disaggregation.** We plan to take heterogeneous inference to the next level by enabling prefill and decode to run on mixed accelerator types within the same cluster — for example, routing compute-heavy prefill to one vendor's nodes and memory-bandwidth-intensive decode to another's (or vice versa), based on where each phase runs most efficiently. This requires the KV cache transfer library to work across different GPU vendors on each end, an active area of development in the llm-d community.
diff --git a/blog/authors.yml b/blog/authors.yml
index 6f53f6e87..824b67043 100644
--- a/blog/authors.yml
+++ b/blog/authors.yml
@@ -198,6 +198,72 @@ abdullahgharaibeh:
url: https://github.com/ahg-g
image_url: https://avatars.githubusercontent.com/u/40361897?v=4
+praveinkannan:
+ name: Pravein Govindan Kannan
+ title: Staff Research Scientist, IBM
+ email: pravein.govindan.kannan@ibm.com
+ image_url: https://avatars.githubusercontent.com/u/9940568?v=4
+ socials:
+ linkedin: praveingk
+ github: https://github.com/praveingk
+ twitter: praveingk
+
+praveenjayachandran:
+ name: Praveen Jayachandran
+ title: Senior Technical Staff Member, IBM
+ email: praveen.j@in.ibm.com
+ image_url: /img/blogs/praveenjayachandran.webp
+ socials:
+ linkedin: praveen-jayachandran-97831113a
+
+jaikhari:
+ name: Jaikrishnan Hari
+ title: Research Partnerships & BD Executive, IBM
+ email: jaikhari@in.ibm.com
+ image_url: /img/blogs/jaikhari.webp
+ socials:
+ linkedin: jaikrishnan-hari-a137972
+
+varunraste:
+ name: Varun Raste
+ title: Solution Architect, IBM
+ email: varun.raste@ibm.com
+ image_url: /img/blogs/varunraste.webp
+ socials:
+ linkedin: varun-raste-0783b3184
+
+prasadmukhedkar:
+ name: Prasad Mukhedkar
+ title: Associate Principal AI Architect, Red Hat
+ email: pmukhedk@redhat.com
+ image_url: /img/blogs/prasadmukhedkar.webp
+ socials:
+ linkedin: prasadmukhedkar1
+
+vinodpathangay:
+ name: Vinod Pathangay
+ title: Chief Architect, Field CTO Organization, Red Hat
+ email: vpathang@redhat.com
+ image_url: /img/blogs/vinodpathangay.webp
+ socials:
+ linkedin: vinod-pathangay
+
+jayanthreddy:
+ name: Jayanth Babu Reddy
+ title: Principal Architect, NxtGen Cloud Technologies
+ email: jayanth.reddy@nxtgen.ai
+ image_url: /img/blogs/jayanthreddy.webp
+ socials:
+ linkedin: jayanth-babu-reddy-498bb0207
+
+abhisyant:
+ name: Abhisyant Anasapurapu
+ title: VP, NxtGen Cloud Technologies
+ email: abhisyant@nxtgen.ai
+ image_url: /img/blogs/abhisyant.webp
+ socials:
+ linkedin: abhisyant
+
llm-d-maintainers:
name: llm-d maintainers
url: https://github.com/llm-d/llm-d/blob/main/MAINTAINERS.md
diff --git a/community/index.md b/community/index.md
index 737287e13..9d40068e5 100644
--- a/community/index.md
+++ b/community/index.md
@@ -15,7 +15,7 @@ This page is your gateway to everything you need to know about participating in
**New to llm-d?** Here's how to get started:
-1. **Join our Slack** 💬 → Get your invite and visit [llm-d.slack.com](https://llm-d.slack.com)
+1. **Join our Slack** 💬 → Get your invite and visit [llm-d.slack.com](https://llm-d.slack.com)
2. **Explore our code** 📂 → [GitHub Organization](https://github.com/llm-d)
3. **Join a meeting** 📅 → [Add calendar](https://red.ht/llm-d-public-calendar)
4. **Pick your area** 🎯 → [Browse SIGs](#special-interest-groups-sigs) below
diff --git a/docusaurus.config.js b/docusaurus.config.js
index dc8a00760..efe5fbb52 100644
--- a/docusaurus.config.js
+++ b/docusaurus.config.js
@@ -213,7 +213,7 @@ const config = {
type: 'html',
position: 'right',
className: 'navbar-slack-item',
- value: 'Join Slack',
+ value: 'Join Slack',
},
],
},
@@ -296,7 +296,7 @@ const config = {
@@ -317,4 +317,3 @@ const config = {
export default config;
-
diff --git a/preview/docusaurus.config.ts b/preview/docusaurus.config.ts
index 83edfd02d..9be88b7a3 100644
--- a/preview/docusaurus.config.ts
+++ b/preview/docusaurus.config.ts
@@ -139,10 +139,10 @@ const config: Config = {
return `https://github.com/llm-d/llm-d/blob/main/${wellLitPath}`;
}
- // Gateway pages come from guides/prereq/gateways/ in the upstream repo
+ // Gateway pages come from docs/resources/gateway/ in the upstream repo
if (cleanPath.startsWith('resources/gateway/')) {
const gatewayFile = sourcePath.replace(/^resources\/gateway\//, '');
- return `https://github.com/llm-d/llm-d/blob/main/guides/prereq/gateways/${gatewayFile}`;
+ return `https://github.com/llm-d/llm-d/blob/main/docs/resources/gateway/${gatewayFile}`;
}
// Infra-provider pages come from docs/infra-providers/ (not docs/resources/infra-providers/)
diff --git a/preview/scripts/sync-docs.sh b/preview/scripts/sync-docs.sh
index 2b657bc0b..b1e51cf7e 100755
--- a/preview/scripts/sync-docs.sh
+++ b/preview/scripts/sync-docs.sh
@@ -224,11 +224,11 @@ else
cp_doc "$WIP/guides/monitoring/tracing.md" "$DOCS_DIR/resources/observability/tracing.md"
fi
-# PR llm-d/llm-d#1259 moved gateway docs to guides/prereq/gateways/
-cp_doc "$SRC/guides/prereq/gateways/README.md" "$DOCS_DIR/resources/gateway/index.md"
-cp_doc "$SRC/guides/prereq/gateways/istio.md" "$DOCS_DIR/resources/gateway/istio.md"
-cp_doc "$SRC/guides/prereq/gateways/gke.md" "$DOCS_DIR/resources/gateway/gke.md"
-cp_doc "$SRC/guides/prereq/gateways/agentgateway.md" "$DOCS_DIR/resources/gateway/agentgateway.md"
+# Gateway docs live under docs/resources/gateway/ in upstream llm-d.
+cp_doc "$WIP/resources/gateway/README.md" "$DOCS_DIR/resources/gateway/index.md"
+cp_doc "$WIP/resources/gateway/istio.md" "$DOCS_DIR/resources/gateway/istio.md"
+cp_doc "$WIP/resources/gateway/gke.md" "$DOCS_DIR/resources/gateway/gke.md"
+cp_doc "$WIP/resources/gateway/agentgateway.md" "$DOCS_DIR/resources/gateway/agentgateway.md"
cp_doc "$WIP/resources/rdma/README.md" "$DOCS_DIR/resources/rdma/rdma-configuration.md"
@@ -331,6 +331,7 @@ find "$DOCS_DIR" -name "*.md" -print0 | while IFS= read -r -d '' file; do
-e 's|advanced/autoscaling/README\.md|advanced/autoscaling/index.md|g' \
-e 's|advanced/disaggregation/README\.md|advanced/disaggregation/index.md|g' \
-e 's|resources/gateways/README\.md|../resources/gateway/index.md|g' \
+ -e 's|resources/gateway/README\.md|resources/gateway/index.md|g' \
-e 's|guides/README\.md|guides/index.md|g' \
-e 's|architecture/introduction\.md|architecture/index.md|g' \
-e 's|architecture/README\.md|architecture/index.md|g' \
@@ -439,9 +440,9 @@ done
echo " Fixing prereq and helper file references..."
find "$DOCS_DIR/guides" -name "*.md" -print0 | while IFS= read -r -d '' file; do
sed_inplace \
- -e 's|\](../prereq/gateways)|\](https://github.com/llm-d/llm-d/tree/main/guides/prereq/gateways)|g' \
- -e 's|\](../../prereq/gateways)|\](https://github.com/llm-d/llm-d/tree/main/guides/prereq/gateways)|g' \
- -e 's|\](/docs/prereq/gateways)|\](https://github.com/llm-d/llm-d/tree/main/guides/prereq/gateways)|g' \
+ -e 's|\](../prereq/gateways)|\](https://github.com/llm-d/llm-d/tree/main/docs/resources/gateway)|g' \
+ -e 's|\](../../prereq/gateways)|\](https://github.com/llm-d/llm-d/tree/main/docs/resources/gateway)|g' \
+ -e 's|\](/docs/prereq/gateways)|\](https://github.com/llm-d/llm-d/tree/main/docs/resources/gateway)|g' \
-e 's|\](/docs/guides/prereq/gateway-provider)|\](https://github.com/llm-d/llm-d/tree/main/guides/prereq/gateway-provider)|g' \
-e 's|\](../../prereq/gateway-provider/README\.md#supported-providers)|\](https://github.com/llm-d/llm-d/tree/main/guides/prereq/gateway-provider#supported-providers)|g' \
-e 's|\](../../prereq/gateway-provider/common-configurations)|\](https://github.com/llm-d/llm-d/tree/main/guides/prereq/gateway-provider#common-configurations)|g' \
@@ -509,8 +510,8 @@ find "$DOCS_DIR/guides" -name "*.md" -print0 | while IFS= read -r -d '' file; do
-e 's|\](./router/epp/config\.yaml)|\](https://github.com/llm-d/llm-d/blob/main/guides/no-kubernetes-deployment/router/epp/config.yaml)|g' \
-e 's|\](./router/epp/endpoints\.yaml)|\](https://github.com/llm-d/llm-d/blob/main/guides/no-kubernetes-deployment/router/epp/endpoints.yaml)|g' \
-e 's|\](./router/envoy/envoy\.yaml)|\](https://github.com/llm-d/llm-d/blob/main/guides/no-kubernetes-deployment/router/envoy/envoy.yaml)|g' \
- -e 's|\](../../04_customizing_a_guide\.md)|\](https://github.com/llm-d/llm-d/tree/main/guides/prereq/gateways)|g' \
- -e 's|\](/docs/04_customizing_a_guide\.md)|\](https://github.com/llm-d/llm-d/tree/main/guides/prereq/gateways)|g' \
+ -e 's|\](../../04_customizing_a_guide\.md)|\](https://github.com/llm-d/llm-d/tree/main/docs/resources/gateway)|g' \
+ -e 's|\](/docs/04_customizing_a_guide\.md)|\](https://github.com/llm-d/llm-d/tree/main/docs/resources/gateway)|g' \
-e 's|\](../../02_verifying_a_guide\.md)|\](https://github.com/llm-d/llm-d/tree/main/guides/optimized-baseline)|g' \
-e 's|\](/docs/02_verifying_a_guide\.md)|\](https://github.com/llm-d/llm-d/tree/main/guides/optimized-baseline)|g' \
-e 's|\](../../02_verifying_a_guide\.md#following-logs-for-requests)|\](https://github.com/llm-d/llm-d/tree/main/guides/optimized-baseline)|g' \
@@ -540,7 +541,7 @@ find "$DOCS_DIR/guides" -name "*.md" -print0 | while IFS= read -r -d '' file; do
done
# === Fix gateway index.md links ===
-# gateway/index.md comes from guides/prereq/gateways/README.md — fix relative paths
+# gateway/index.md comes from docs/resources/gateway/README.md — fix relative paths
if [[ -f "$DOCS_DIR/resources/gateway/index.md" ]]; then
sed_inplace \
-e 's|\](../../guides/README\.md)|\](/guides)|g' \
diff --git a/preview/scripts/transformations.sh b/preview/scripts/transformations.sh
index e7432b0f2..310a4b33b 100755
--- a/preview/scripts/transformations.sh
+++ b/preview/scripts/transformations.sh
@@ -123,10 +123,10 @@ apply_transformations() {
# Fix deployment guide links to GitHub URLs
# These guides live in llm-d/guides/ and should link to GitHub
sed_inplace \
- -e 's|\](.*\/guides/prereq/gateways/README\.md)|\](https://github.com/llm-d/llm-d/tree/main/guides/prereq/gateways/README.md)|g' \
- -e 's|\](.*\/guides/prereq/gateways/istio\.md)|\](https://github.com/llm-d/llm-d/tree/main/guides/prereq/gateways/istio.md)|g' \
- -e 's|\](.*\/guides/prereq/gateways/gke\.md)|\](https://github.com/llm-d/llm-d/tree/main/guides/prereq/gateways/gke.md)|g' \
- -e 's|\](.*\/guides/prereq/gateways/agentgateway\.md)|\](https://github.com/llm-d/llm-d/tree/main/guides/prereq/gateways/agentgateway.md)|g' \
+ -e 's|\](.*\/guides/prereq/gateways/README\.md)|\](https://github.com/llm-d/llm-d/tree/main/docs/resources/gateway/README.md)|g' \
+ -e 's|\](.*\/guides/prereq/gateways/istio\.md)|\](https://github.com/llm-d/llm-d/tree/main/docs/resources/gateway/istio.md)|g' \
+ -e 's|\](.*\/guides/prereq/gateways/gke\.md)|\](https://github.com/llm-d/llm-d/tree/main/docs/resources/gateway/gke.md)|g' \
+ -e 's|\](.*\/guides/prereq/gateways/agentgateway\.md)|\](https://github.com/llm-d/llm-d/tree/main/docs/resources/gateway/agentgateway.md)|g' \
"$file"
# Fix unclosed HTML tags for MDX (must be self-closing)
diff --git a/src/pages/kubecon-eu-26.js b/src/pages/kubecon-eu-26.js
index b195e33fd..8408eb62d 100644
--- a/src/pages/kubecon-eu-26.js
+++ b/src/pages/kubecon-eu-26.js
@@ -219,7 +219,7 @@ export default function KubeConEU26() {
>
Star us on GitHub
-
+
Join Slack
diff --git a/src/pages/videos.js b/src/pages/videos.js
index c4b6e0a5a..80f0a766b 100644
--- a/src/pages/videos.js
+++ b/src/pages/videos.js
@@ -88,7 +88,7 @@ export default function Videos() {
Read the Docs
-
+
Join Slack
@@ -98,4 +98,3 @@ export default function Videos() {
);
}
-
diff --git a/static/img/blogs/abhisyant.webp b/static/img/blogs/abhisyant.webp
new file mode 100644
index 000000000..8347dc564
Binary files /dev/null and b/static/img/blogs/abhisyant.webp differ
diff --git a/static/img/blogs/heterogeneous-3vendor/vendor-a-granite.png b/static/img/blogs/heterogeneous-3vendor/vendor-a-granite.png
new file mode 100644
index 000000000..9942bf1a1
Binary files /dev/null and b/static/img/blogs/heterogeneous-3vendor/vendor-a-granite.png differ
diff --git a/static/img/blogs/heterogeneous-3vendor/vendor-a-sarvam.png b/static/img/blogs/heterogeneous-3vendor/vendor-a-sarvam.png
new file mode 100644
index 000000000..c9566a25c
Binary files /dev/null and b/static/img/blogs/heterogeneous-3vendor/vendor-a-sarvam.png differ
diff --git a/static/img/blogs/heterogeneous-3vendor/vendor-ab-granite.png b/static/img/blogs/heterogeneous-3vendor/vendor-ab-granite.png
new file mode 100644
index 000000000..f6e93efa5
Binary files /dev/null and b/static/img/blogs/heterogeneous-3vendor/vendor-ab-granite.png differ
diff --git a/static/img/blogs/heterogeneous-3vendor/vendor-ab-sarvam.png b/static/img/blogs/heterogeneous-3vendor/vendor-ab-sarvam.png
new file mode 100644
index 000000000..265bcbf4f
Binary files /dev/null and b/static/img/blogs/heterogeneous-3vendor/vendor-ab-sarvam.png differ
diff --git a/static/img/blogs/heterogeneous-3vendor/vendor-abc-granite.png b/static/img/blogs/heterogeneous-3vendor/vendor-abc-granite.png
new file mode 100644
index 000000000..d783b7676
Binary files /dev/null and b/static/img/blogs/heterogeneous-3vendor/vendor-abc-granite.png differ
diff --git a/static/img/blogs/heterogeneous-3vendor/vendor-b-granite.png b/static/img/blogs/heterogeneous-3vendor/vendor-b-granite.png
new file mode 100644
index 000000000..534ca285e
Binary files /dev/null and b/static/img/blogs/heterogeneous-3vendor/vendor-b-granite.png differ
diff --git a/static/img/blogs/heterogeneous-3vendor/vendor-b-sarvam.png b/static/img/blogs/heterogeneous-3vendor/vendor-b-sarvam.png
new file mode 100644
index 000000000..da62296d6
Binary files /dev/null and b/static/img/blogs/heterogeneous-3vendor/vendor-b-sarvam.png differ
diff --git a/static/img/blogs/heterogeneous-3vendor/vendor-c-granite.png b/static/img/blogs/heterogeneous-3vendor/vendor-c-granite.png
new file mode 100644
index 000000000..2427776af
Binary files /dev/null and b/static/img/blogs/heterogeneous-3vendor/vendor-c-granite.png differ
diff --git a/static/img/blogs/jaikhari.webp b/static/img/blogs/jaikhari.webp
new file mode 100644
index 000000000..86760b89c
Binary files /dev/null and b/static/img/blogs/jaikhari.webp differ
diff --git a/static/img/blogs/jayanthreddy.webp b/static/img/blogs/jayanthreddy.webp
new file mode 100644
index 000000000..185e62136
Binary files /dev/null and b/static/img/blogs/jayanthreddy.webp differ
diff --git a/static/img/blogs/prasadmukhedkar.webp b/static/img/blogs/prasadmukhedkar.webp
new file mode 100644
index 000000000..b384bcaf0
Binary files /dev/null and b/static/img/blogs/prasadmukhedkar.webp differ
diff --git a/static/img/blogs/praveenjayachandran.webp b/static/img/blogs/praveenjayachandran.webp
new file mode 100644
index 000000000..f3a9591a7
Binary files /dev/null and b/static/img/blogs/praveenjayachandran.webp differ
diff --git a/static/img/blogs/varunraste.webp b/static/img/blogs/varunraste.webp
new file mode 100644
index 000000000..e9824b8ca
Binary files /dev/null and b/static/img/blogs/varunraste.webp differ
diff --git a/static/img/blogs/vinodpathangay.webp b/static/img/blogs/vinodpathangay.webp
new file mode 100644
index 000000000..94264d29c
Binary files /dev/null and b/static/img/blogs/vinodpathangay.webp differ