From c9990eb6576fe863b254c20984e84f0b512fb1da Mon Sep 17 00:00:00 2001 From: gthulhu-work Date: Sun, 6 Sep 2026 21:37:29 +0800 Subject: [PATCH 1/3] docs: sharpen homepage value proposition --- docs/index.md | 192 +++++++++++++++++++++++++------------------------- 1 file changed, 96 insertions(+), 96 deletions(-) diff --git a/docs/index.md b/docs/index.md index 3c2f131..67eedd5 100644 --- a/docs/index.md +++ b/docs/index.md @@ -1,142 +1,142 @@ +# Gthulhu + +
+ +## Keep critical workloads fast when CPUs get busy + +Gthulhu is a cloud-native runtime scheduling platform built with eBPF and Linux `sched_ext`. It protects latency- and throughput-sensitive Linux tasks inside Kubernetes workloads when CPU contention would otherwise slow them down. + +
+Get Started +View on GitHub +
+ +
+ +
+ +
+free5GC / 5G user plane + +### 97.66% lower average latency + +**88.98 ms → 2.079 ms** average UE ping latency under CPU stress. + +Maximum latency also fell from **130.95 ms → 8.45 ms**. + +[Read the published free5GC case study →](https://free5gc.org/blog/20251126/20251126/) +
+ +
+vLLM / GPU inference + +### ~3.2× decode throughput + +**~6.7 t/s → ~21.3 t/s** on `tg128` under CPU pressure with Gthulhu + tiered scheduling policy. + +*Reproducible community benchmark currently under upstream vLLM blog review.* + +[Review the benchmark and methodology →](https://github.com/vllm-project/vllm-project.github.io/pull/300) +
+ +
+ +
cncf landscape ebpf landscape +LFX Health Score +
-[![LFX Health Score](https://insights.linuxfoundation.org/api/badge/health-score?project=gthulhu)](https://insights.linuxfoundation.org/project/gthulhu) +## The problem Gthulhu solves -# Gthulhu +Kubernetes can place a workload on the right node and allocate the right resources. That still does not guarantee the workload's critical Linux threads will get CPU time when they need it. -## Protect critical workloads from CPU contention +Under contention, GPU feeder threads, `EngineCore`, packet-processing workers, IRQ-related work, or other latency-sensitive tasks can be delayed by background CPU load. The result is simple: **allocated resources, but missed SLOs**. -Gthulhu uses eBPF and Linux `sched_ext` to make workload scheduling observable and controllable across Kubernetes nodes. +Gthulhu closes that execution gap. -**Measured results under CPU contention:** +
-| Workload | Baseline | With Gthulhu | Result | -|---|---:|---:|---:| -| free5GC / GTP data path — average UE ping latency | **88.98 ms** | **2.079 ms** | **97.66% lower** | -| free5GC / GTP data path — maximum UE ping latency | **130.95 ms** | **8.45 ms** | **93.55% lower** | -| vLLM Qwen2.5-0.5B decode (`tg128`) under CPU pressure | **~6.7 t/s** | **~21.3 t/s** with tiered policy | **~3.2× throughput** | +**1. Observe** +Use eBPF to see which tasks are waiting, running, migrating, and competing for CPU. -The free5GC numbers are published in the free5GC community blog. The vLLM result comes from a reproducible community benchmark currently proposed to the vLLM project blog; treat it as an experiment under upstream review rather than a project-wide guarantee. +**2. Target** +Resolve Kubernetes workload intent down to the Linux process or thread that actually matters. -[Read the free5GC case study](https://free5gc.org/blog/20251126/20251126/){: .md-button .md-button--primary } -[vLLM benchmark PR](https://github.com/vllm-project/vllm-project.github.io/pull/300){: .md-button } -[Get Started](k8s.md){: .md-button } +**3. Control** +Use `sched_ext` to apply bounded runtime scheduling policy and protect critical execution paths. -> **DRA chooses what and where; Gthulhu controls how it actually runs.** +
-## Why this matters +> **DRA chooses what and where. Gthulhu controls how it actually runs.** -A workload can already own a GPU, NIC, CPU set, or Kubernetes placement and still miss its latency or throughput target because its host-side Linux tasks are delayed by CPU contention. +## Built for workload-aware runtime scheduling -Gthulhu focuses on that execution gap: +
-```text -Kubernetes admission / placement / allocation - │ - ▼ - Gthulhu runtime plane - │ - Pod / cgroup / TGID / TID resolution - │ - ▼ - sched_ext + eBPF - │ - ▼ - latency / throughput / jitter / SLO -``` +- :material-eye-outline:{ .lg .middle } **Scheduling observability** -## Proven use cases + --- -### 5G user-plane latency + Pod-level scheduling metrics with eBPF, plus Prometheus and Grafana integration. -The free5GC community published a GTP-driven scheduling experiment that combines `gtp5g-tracer`, a userspace operator, and Gthulhu. Under the same CPU stress, average UE ping latency dropped from **88.98 ms to 2.079 ms**, while maximum latency dropped from **130.95 ms to 8.45 ms**. +- :material-tune-variant:{ .lg .middle } **Fine-grained control** -[Read: Implementing GTP-driven Automatic Scheduling Optimization with eBPF-based Scheduler](https://free5gc.org/blog/20251126/20251126/) + --- -A separate earlier free5GC case study also documents using Gthulhu to reduce RTT by combining application/domain knowledge with custom `sched_ext` policy. + Apply scheduling intent to specific workloads, processes, or non-leader worker threads with TID-aware matching. -[Read: Improving Network Performance with Custom eBPF-based Schedulers](https://free5gc.org/blog/20250726/index.en/) +- :material-server-network:{ .lg .middle } **Cloud-native operation** -### vLLM inference under CPU pressure + --- -A reproducible DGX Spark / GB10 experiment uses MicroK8s, vLLM, `stress-ng`, and Gthulhu to isolate the effect of CPU scheduling on GPU inference. In the submitted benchmark, decode throughput under CPU pressure is around **6–7 t/s** with the default scheduler and reaches roughly **21 t/s** on `tg128` with Gthulhu plus tiered policies targeting GPU-related work and vLLM's `EngineCore` thread. + Manager + per-node Decision Makers distribute scheduling intent across Kubernetes nodes. -This result is linked here as an **upstream-reviewing community benchmark**, not as a generalized performance guarantee. +- :material-chart-line:{ .lg .middle } **SLO-oriented automation** -[Review the benchmark and methodology in vLLM blog PR #300](https://github.com/vllm-project/vllm-project.github.io/pull/300) + --- -## What Gthulhu provides today + Feed scheduler signals into Prometheus, Grafana, and KEDA to support runtime-aware operations and scaling. -- **Pod-level scheduling observability** with eBPF. -- **Prometheus / Grafana / KEDA integration** for scheduler-aware operations and scaling. -- **Distributed scheduling intent** through a Manager and per-node Decision Makers. -- **Custom CPU scheduling** on Linux 6.12+ with `sched_ext`. -- **TID-aware node-policy matching** so non-leader worker threads can be targeted directly. -- **Explicit priority semantics** across user-space and kernel scheduler modes. +
-[How It Works](how-it-works.md){: .md-button } -[Claim2Core Roadmap](claim2core.md){: .md-button } +[See how Gthulhu works](how-it-works.md){: .md-button } -## Claim2Core: from allocation to delivered performance +## Where Gthulhu is going: Claim2Core -The next architecture step is to connect actual Kubernetes allocation to runtime task scheduling: +Today, Gthulhu can observe and control Linux task scheduling at runtime. The next step is to connect that control directly to Kubernetes' **actual resource allocation**. ```text Kueue / Workload API - │ admission / quota - ▼ + ↓ kube-scheduler / DRA - │ Node + device + topology allocation - ▼ + ↓ ResourceClaim + topology Gthulhu Runtime Plane - │ ResourceClaim → Pod/cgroup → TGID/TID - ▼ + ↓ Pod / cgroup / TGID / TID sched_ext + eBPF - │ runtime policy + verification - ▼ + ↓ Delivered workload SLO ``` -The critical correctness rule is: +The principle is simple: -- `ResourceSlice` is **inventory**. -- `ResourceClaim.status.allocation` is the workload's **actual allocation**. +- `ResourceSlice` tells us what resources exist. +- `ResourceClaim.status.allocation` tells us what the workload actually received. +- Gthulhu turns that allocation into a verifiable runtime execution policy **without crossing the CPU/resource boundaries Kubernetes already established**. -Gthulhu should not reimplement kube-scheduler, DRA, or Kueue. It should consume their decisions and control Linux CPU execution **inside** the resource envelope established by Kubernetes/cgroups. +[Explore the Claim2Core roadmap](claim2core.md){: .md-button } +[Follow roadmap issue #141](https://github.com/Gthulhu/Gthulhu/issues/141){: .md-button } -Read [Claim2Core](claim2core.md) for the implementation phases and safety boundaries. +## Start with a real workload -## Architecture at a glance +
-```text -User / Web UI / CRD - │ - ▼ -Manager API ───────▶ MongoDB / Kubernetes API - │ - ▼ -Decision Maker DaemonSet - │ - ├── eBPF scheduling metrics collector ──▶ Prometheus / Grafana / KEDA - │ - └── task resolution / scheduling intent - │ - ▼ - Gthulhu daemon - │ - ▼ - sched_ext / BPF - │ - ▼ - Linux scheduler -``` +### See what CPU scheduling is doing to your workload + +Deploy Gthulhu on Kubernetes, inspect scheduler behavior, then apply policy only where the data shows it matters. -## Get involved +[Deploy Gthulhu](k8s.md){: .md-button .md-button--primary } +[Read the free5GC case study](https://free5gc.org/blog/20251126/20251126/){: .md-button } +[Contribute](contributing.md){: .md-button } -- [Deploy Gthulhu with Kubernetes](k8s.md) -- [Understand the architecture and scheduler semantics](how-it-works.md) -- [Read the Claim2Core roadmap](claim2core.md) -- [Contribute](contributing.md) -- [GitHub repository](https://github.com/Gthulhu/Gthulhu) -- [Roadmap issue #141](https://github.com/Gthulhu/Gthulhu/issues/141) +
From a5132e0eb254c78b425c669cdde35a1586cb11af Mon Sep 17 00:00:00 2001 From: gthulhu-work Date: Sun, 6 Sep 2026 21:37:55 +0800 Subject: [PATCH 2/3] docs: sharpen Chinese homepage value proposition --- docs/index.zh.md | 192 +++++++++++++++++++++++------------------------ 1 file changed, 96 insertions(+), 96 deletions(-) diff --git a/docs/index.zh.md b/docs/index.zh.md index 3562a05..3d7c0f0 100644 --- a/docs/index.zh.md +++ b/docs/index.zh.md @@ -1,142 +1,142 @@ +# Gthulhu + +
+ +## CPU 忙起來時，讓關鍵工作負載仍然跑得快 + +Gthulhu 是一個以 eBPF 與 Linux `sched_ext` 建構的 cloud-native runtime scheduling 平台。當 CPU contention 開始拖慢 Kubernetes workload 時，Gthulhu 會保護真正影響 latency 與 throughput 的 Linux tasks。 + +
+開始使用 +GitHub +
+ +
+ +
+ +
+free5GC / 5G User Plane + +### 平均 latency 降低 97.66% + +CPU stress 下，UE 平均 ping latency **88.98 ms → 2.079 ms**。 + +最大 latency 也從 **130.95 ms → 8.45 ms**。 + +[閱讀 free5GC 已發表 Case Study →](https://free5gc.org/blog/20251126/20251126/) +
+ +
+vLLM / GPU Inference + +### Decode throughput 約提升 3.2× + +CPU pressure 下，`tg128` 從 **~6.7 t/s → ~21.3 t/s**，使用 Gthulhu + tiered scheduling policy。 + +*此為可重現的 community benchmark，目前仍在 vLLM upstream blog review 中。* + +[查看 benchmark 與實驗方法 →](https://github.com/vllm-project/vllm-project.github.io/pull/300) +
+ +
+ +
cncf landscape ebpf landscape +LFX Health Score +
-[![LFX Health Score](https://insights.linuxfoundation.org/api/badge/health-score?project=gthulhu)](https://insights.linuxfoundation.org/project/gthulhu) +## Gthulhu 解決什麼問題？ -# Gthulhu +Kubernetes 可以把 workload 放到正確的 Node，也可以分配正確的資源；但這不代表 workload 裡真正重要的 Linux threads，在需要 CPU 時一定拿得到 CPU。 -## 在 CPU contention 下保護關鍵工作負載 +當系統出現 contention，GPU feeder、`EngineCore`、packet-processing workers、IRQ-related work 或其他 latency-sensitive tasks，都可能被背景 CPU workload 延遲。最後形成一個很直接的問題：**資源已經分配了，SLO 還是沒達成。** -Gthulhu 使用 eBPF 與 Linux `sched_ext`，讓 Kubernetes 節點上的 workload scheduling 可以被觀測、控制與驗證。 +Gthulhu 專注處理這個 execution gap。 -**CPU contention 下的實測結果：** +
-| Workload | Baseline | 使用 Gthulhu | 結果 | -|---|---:|---:|---:| -| free5GC / GTP data path — UE 平均 ping latency | **88.98 ms** | **2.079 ms** | **降低 97.66%** | -| free5GC / GTP data path — UE 最大 ping latency | **130.95 ms** | **8.45 ms** | **降低 93.55%** | -| vLLM Qwen2.5-0.5B decode (`tg128`) under CPU pressure | **~6.7 t/s** | **~21.3 t/s**（tiered policy） | **約 3.2× throughput** | +**1. Observe — 看見問題** +用 eBPF 看清楚哪些 tasks 在等待、執行、migration，以及誰正在競爭 CPU。 -free5GC 數據已發表於 free5GC 社群部落格。vLLM 數據來自可重現的 community benchmark，目前正在 vLLM 官方 blog PR 審核中，因此應視為 upstream-reviewing experiment，而不是適用所有環境的效能保證。 +**2. Target — 找到真正重要的 task** +把 Kubernetes workload intent 解析到實際影響服務的 Linux process / thread。 -[閱讀 free5GC Case Study](https://free5gc.org/blog/20251126/20251126/){: .md-button .md-button--primary } -[vLLM Benchmark PR](https://github.com/vllm-project/vllm-project.github.io/pull/300){: .md-button } -[開始使用](k8s.md){: .md-button } +**3. Control — 精準控制** +利用 `sched_ext` 套用有邊界的 runtime scheduling policy，保護關鍵 execution path。 -> **DRA chooses what and where; Gthulhu controls how it actually runs.** +
-## 為什麼這件事重要 +> **DRA chooses what and where. Gthulhu controls how it actually runs.** -Workload 即使已經取得 GPU、NIC、CPU set 或 Kubernetes placement，也可能因 host-side Linux tasks 在 CPU contention 下被延遲，而無法達成 latency / throughput SLO。 +## 為 workload-aware runtime scheduling 而設計 -Gthulhu 專注於這個 execution gap： +
-```text -Kubernetes admission / placement / allocation - │ - ▼ - Gthulhu runtime plane - │ - Pod / cgroup / TGID / TID resolution - │ - ▼ - sched_ext + eBPF - │ - ▼ - latency / throughput / jitter / SLO -``` +- :material-eye-outline:{ .lg .middle } **Scheduling Observability** -## 已驗證的使用案例 + --- -### 5G User Plane latency + 使用 eBPF 提供 Pod-level scheduling metrics，並整合 Prometheus 與 Grafana。 -free5GC 社群已發表 GTP-driven scheduling 實驗，將 `gtp5g-tracer`、userspace operator 與 Gthulhu 串起來。在相同 CPU stress 下，UE 平均 ping latency 從 **88.98 ms 降到 2.079 ms**，最大 latency 從 **130.95 ms 降到 8.45 ms**。 +- :material-tune-variant:{ .lg .middle } **Fine-grained Control** -[閱讀：Implementing GTP-driven Automatic Scheduling Optimization with eBPF-based Scheduler](https://free5gc.org/blog/20251126/20251126/) + --- -另一篇較早的 free5GC case study 也展示如何利用 network-domain knowledge 搭配 Gthulhu 的 `sched_ext` policy 降低 RTT。 + 對特定 workload、process，甚至非 leader worker thread 套用 scheduling intent；支援 TID-aware matching。 -[閱讀：利用 Custom eBPF-based Schedulers 改善網路效能](https://free5gc.org/blog/20250726/) +- :material-server-network:{ .lg .middle } **Cloud-native Operation** -### vLLM 在 CPU pressure 下的 inference + --- -另一個可重現實驗使用 DGX Spark / GB10、MicroK8s、vLLM、`stress-ng` 與 Gthulhu，刻意隔離 CPU scheduling 對 GPU inference 的影響。在目前提交給 vLLM blog 的 benchmark 中，default scheduler 在 CPU pressure 下 decode throughput 約為 **6–7 t/s**；使用 Gthulhu 並對 GPU-related work 與 vLLM `EngineCore` 套用 tiered policy 後，`tg128` 約可達 **21 t/s**。 + 透過 Manager 與每節點 Decision Maker，把 scheduling intent 分散到 Kubernetes nodes。 -這裡將它標示為 **upstream 審核中的 community benchmark**，而不是廣泛化的 performance guarantee。 +- :material-chart-line:{ .lg .middle } **SLO-oriented Automation** -[查看 vLLM blog PR #300 的 benchmark 與方法](https://github.com/vllm-project/vllm-project.github.io/pull/300) + --- -## Gthulhu 目前已具備的能力 + 將 scheduler signals 接到 Prometheus、Grafana 與 KEDA，支援 runtime-aware operations 與 scaling。 -- **Pod 層級 scheduling observability**：使用 eBPF 收集 scheduler signals。 -- **Prometheus / Grafana / KEDA 整合**：支援 scheduler-aware operations 與 scaling。 -- **分散式 scheduling intent**：Manager 搭配每節點 Decision Maker。 -- **自訂 CPU scheduling**：Linux 6.12+ 可使用 `sched_ext`。 -- **TID-aware node policy matching**：可以直接命中非 leader worker thread。 -- **明確的 priority semantics**：user-space 與 kernel mode 都有清楚的 boosting 行為。 +
-[了解運作原理](how-it-works.md){: .md-button } -[Claim2Core Roadmap](claim2core.md){: .md-button } +[了解 Gthulhu 如何運作](how-it-works.md){: .md-button } -## Claim2Core：從 allocation 到 delivered performance +## 下一步：Claim2Core -下一個架構階段，是把 Kubernetes 的實際 allocation 接到 runtime task scheduling： +目前 Gthulhu 已能在 runtime 觀測與控制 Linux task scheduling。下一步，是把這個能力直接接到 Kubernetes **實際分配的資源**。 ```text Kueue / Workload API - │ admission / quota - ▼ + ↓ kube-scheduler / DRA - │ Node + device + topology allocation - ▼ + ↓ ResourceClaim + topology Gthulhu Runtime Plane - │ ResourceClaim → Pod/cgroup → TGID/TID - ▼ + ↓ Pod / cgroup / TGID / TID sched_ext + eBPF - │ runtime policy + verification - ▼ + ↓ Delivered workload SLO ``` -最重要的 correctness 原則是： +核心原則很簡單： -- `ResourceSlice` 是 **inventory**。 -- `ResourceClaim.status.allocation` 才是 workload 的 **actual allocation**。 +- `ResourceSlice` 告訴我們有哪些資源。 +- `ResourceClaim.status.allocation` 告訴我們 workload 實際拿到了什麼。 +- Gthulhu 把 allocation 轉成可驗證的 runtime execution policy，並且**不突破 Kubernetes 已建立的 CPU / resource boundary**。 -Gthulhu 不重新實作 kube-scheduler、DRA 或 Kueue，而是在 Kubernetes/cgroup 建立的 resource envelope 內，控制 workload 真正取得 CPU service 的方式。 +[查看 Claim2Core Roadmap](claim2core.md){: .md-button } +[追蹤 Roadmap Issue #141](https://github.com/Gthulhu/Gthulhu/issues/141){: .md-button } -完整 implementation phases 與安全邊界請看 [Claim2Core](claim2core.md)。 +## 從真實 workload 開始 -## 架構一覽 +
-```text -User / Web UI / CRD - │ - ▼ -Manager API ───────▶ MongoDB / Kubernetes API - │ - ▼ -Decision Maker DaemonSet - │ - ├── eBPF scheduling metrics collector ──▶ Prometheus / Grafana / KEDA - │ - └── task resolution / scheduling intent - │ - ▼ - Gthulhu daemon - │ - ▼ - sched_ext / BPF - │ - ▼ - Linux scheduler -``` +### 先看 CPU scheduling 到底怎麼影響你的服務 + +在 Kubernetes 部署 Gthulhu、觀察 scheduler behavior，再只對數據證明有影響的 execution path 套用 policy。 -## 參與 Gthulhu +[部署 Gthulhu](k8s.md){: .md-button .md-button--primary } +[閱讀 free5GC Case Study](https://free5gc.org/blog/20251126/20251126/){: .md-button } +[參與貢獻](contributing.md){: .md-button } -- [在 Kubernetes 部署 Gthulhu](k8s.md) -- [理解系統架構與 scheduler semantics](how-it-works.md) -- [閱讀 Claim2Core roadmap](claim2core.md) -- [參與貢獻](contributing.md) -- [GitHub repository](https://github.com/Gthulhu/Gthulhu) -- [Roadmap issue #141](https://github.com/Gthulhu/Gthulhu/issues/141) +
From b8176a8ee83877ee98b4111d020d903afd9a9dde Mon Sep 17 00:00:00 2001 From: gthulhu-work Date: Sun, 6 Sep 2026 21:38:25 +0800 Subject: [PATCH 3/3] style: add focused homepage marketing layout --- docs/stylesheets/extra.css | 180 +++++++++++++++++++++++++++---------- 1 file changed, 134 insertions(+), 46 deletions(-) diff --git a/docs/stylesheets/extra.css b/docs/stylesheets/extra.css index 1305686..668e16b 100644 --- a/docs/stylesheets/extra.css +++ b/docs/stylesheets/extra.css @@ -5,12 +5,11 @@ :root { --md-typeset-a-color: #2563EB !important; --md-primary-fg-color: #3B82F6; - --md-primary-fg-color--light: #60A5FA; /* 偏亮的主色，用於 hover 等狀態 */ - --md-primary-fg-color--dark: #2563EB; /* 偏暗的主色，用於陰影或深色邊界 */ - --md-accent-fg-color: #3B82F6; /* 強調色一併設為相同色調（可依需求調整） */ + --md-primary-fg-color--light: #60A5FA; + --md-primary-fg-color--dark: #2563EB; + --md-accent-fg-color: #3B82F6; } -/* 深色模式也同步主題色，避免切換配色時恢復預設藍色 */ [data-md-color-scheme="slate"] { --md-typeset-a-color: #60A5FA !important; --md-primary-fg-color: #3B82F6; @@ -19,7 +18,6 @@ --md-accent-fg-color: #60A5FA; } -/* 全站基礎字體設定 */ body, .md-typeset { font-family: 'Inter', -apple-system, BlinkMacSystemFont, 'Segoe UI', Roboto, sans-serif !important; @@ -27,14 +25,12 @@ body, line-height: 1.7 !important; } -/* 內文段落 */ .md-typeset p { font-family: 'Inter', sans-serif !important; font-size: 0.95rem !important; line-height: 1.7 !important; } -/* 標題字體 - 使用 Orbitron 保持科技感 */ .md-typeset h1 { font-family: 'Orbitron', sans-serif !important; font-weight: 700 !important; @@ -56,7 +52,6 @@ body, letter-spacing: 0.3px !important; } -/* 程式碼區塊使用等寬字體 */ .md-typeset code, .md-typeset pre, .md-typeset kbd, @@ -64,79 +59,55 @@ body, font-family: 'JetBrains Mono', 'Consolas', monospace !important; } -/* 行內程式碼 */ .md-typeset code { font-size: 0.85em !important; padding: 0.1em 0.4em !important; } -/* 列表文字 */ .md-typeset ul, .md-typeset ol, -.md-typeset li { +.md-typeset li, +.md-typeset blockquote, +.md-typeset table, +.md-typeset .admonition { font-family: 'Inter', sans-serif !important; } -/* 引用區塊 */ .md-typeset blockquote { - font-family: 'Inter', sans-serif !important; font-style: italic !important; } -/* 表格 */ .md-typeset table { - font-family: 'Inter', sans-serif !important; font-size: 0.9rem !important; } -/* Admonition (提示框) */ .md-typeset .admonition-title, .md-typeset summary { font-family: 'Orbitron', sans-serif !important; font-weight: 600 !important; } -.md-typeset .admonition { - font-family: 'Inter', sans-serif !important; -} - -/* 調整 logo 大小 */ .md-header__button.md-logo img, -.md-header__button.md-logo svg { - height: 3rem !important; - width: auto !important; -} - +.md-header__button.md-logo svg, .md-logo img, .md-logo svg { height: 3rem !important; width: auto !important; } -/* 導航列背景色 */ -.md-header { - background-color: #1E293B !important; -} - -.md-tabs { - background-color: #1E293B !important; -} - -.md-nav__source { +.md-header, +.md-tabs, +.md-nav__source, +.md-nav--primary .md-nav__title { background-color: #1E293B !important; } -.md-nav__item .md-nav__link--active, .md-nav__item .md-nav__link--active code, -.md-nav__item--active>.md-nav__link { +.md-nav__item .md-nav__link--active, +.md-nav__item .md-nav__link--active code, +.md-nav__item--active > .md-nav__link { color: #3B82F6 !important; } -/* 主要導覽（側邊/抽屜）背景，確保與主題色一致 */ -.md-nav--primary .md-nav__title { - background-color: #1E293B !important; -} - -/* 導航列字體 - 使用 Orbitron 科技感字體 */ .md-header__title, .md-header__topic { font-family: 'Orbitron', 'JetBrains Mono', monospace !important; @@ -150,14 +121,131 @@ body, letter-spacing: 0.3px !important; } -/* 導航選單項目 */ .md-nav__link { font-family: 'Inter', sans-serif !important; font-weight: 500 !important; } -/* 側邊欄標題 */ .md-nav__title { font-family: 'Orbitron', sans-serif !important; font-weight: 600 !important; } + +/* Homepage marketing layout */ +.gth-hero { + margin: 0.5rem 0 1.5rem; + padding: 2.2rem 2.4rem; + border: 1px solid rgba(59, 130, 246, 0.22); + border-radius: 1rem; + background: linear-gradient(135deg, rgba(59, 130, 246, 0.12), rgba(15, 23, 42, 0.02)); +} + +.gth-hero h2 { + margin-top: 0; + margin-bottom: 0.7rem; + font-size: clamp(1.75rem, 4vw, 2.65rem); + line-height: 1.18; + max-width: 18ch; +} + +.gth-hero p { + max-width: 760px; + font-size: 1.05rem !important; +} + +.gth-hero-actions { + display: flex; + flex-wrap: wrap; + gap: 0.65rem; + margin-top: 1.15rem; +} + +.gth-proof-grid { + display: grid; + grid-template-columns: repeat(2, minmax(0, 1fr)); + gap: 1rem; + margin: 1.5rem 0 1rem; +} + +.gth-proof-card { + padding: 1.35rem 1.45rem; + border: 1px solid rgba(148, 163, 184, 0.28); + border-radius: 0.9rem; + background: var(--md-default-bg-color); + box-shadow: 0 8px 28px rgba(15, 23, 42, 0.05); +} + +.gth-proof-card h3 { + margin-top: 0.35rem; + margin-bottom: 0.55rem; + font-size: 1.25rem; + line-height: 1.3; +} + +.gth-proof-eyebrow { + display: inline-block; + font-size: 0.72rem; + font-weight: 700; + letter-spacing: 0.08em; + text-transform: uppercase; + color: var(--md-primary-fg-color); +} + +.gth-trust-row { + display: flex; + align-items: center; + flex-wrap: wrap; + gap: 0.55rem; + margin: 1.2rem 0 2.4rem; + opacity: 0.92; +} + +.gth-trust-row img { + max-height: 28px; +} + +.gth-flow { + display: grid; + grid-template-columns: repeat(3, minmax(0, 1fr)); + gap: 1rem; + margin: 1.3rem 0 1.6rem; +} + +.gth-flow > p { + margin: 0 !important; + padding: 1rem 1.1rem; + border-left: 3px solid var(--md-primary-fg-color); + background: rgba(59, 130, 246, 0.06); +} + +.gth-cta { + margin: 1.2rem 0 2rem; + padding: 1.5rem 1.7rem; + border-radius: 0.9rem; + background: rgba(59, 130, 246, 0.08); +} + +.gth-cta h3 { + margin-top: 0; +} + +[data-md-color-scheme="slate"] .gth-hero, +[data-md-color-scheme="slate"] .gth-flow > p, +[data-md-color-scheme="slate"] .gth-cta { + background-color: rgba(59, 130, 246, 0.08); +} + +@media screen and (max-width: 760px) { + .gth-hero { + padding: 1.45rem 1.25rem; + } + + .gth-proof-grid, + .gth-flow { + grid-template-columns: 1fr; + } + + .gth-trust-row { + margin-bottom: 1.8rem; + } +}