![image.png](/static/img/498183653de6f0b2db1fb4da88fc0bf3.image.png)




PageIndex 的核心目标是解决一个问题：
> 如何让 LLM 高质量理解长文档，并实现精准搜索。

传统 RAG 的问题：

- 文档 chunk 切得很碎
- 结构信息丢失
- 搜索结果上下文不完整
- LLM 容易 hallucination

PageIndex 的思路是：
> 先理解文档结构 → 再建立树状索引 → 再做向量搜索

而不是直接 chunk。

整个系统可以拆成两个阶段：

**离线阶段（Indexing）**

`文档解析 → 结构提取 → 索引构建 → 向量存储`

**在线阶段（Query）**

`用户问题 → 向量搜索 → 结构补全 → LLM回答`

## 一、文档解析流程（Document Parsing）

文档解析的目标是：

> 把 PDF / Word / Markdown 转换成可理解的结构化数据

典型输入：
- PDF
- Word
- Markdown
- HTML

解析流程如下。

### 1 文档加载

首先系统加载原始文档。

核心任务：
- 读取文档
- 转换为文本
- 保留基础结构

可能用到的工具：
- pdf parser
- docx parser
- html parser

输出类似：
```json
{
  "pages": [
    {
      "text": "...",
      "layout": "..."
    }
  ]
}
```
此时仍然是原始文本。

### 2 文档结构解析

接下来需要识别文档结构。

系统会识别：
- 标题（H1 / H2 / H3）
- 段落
- 列表
- 表格
- 代码块

**例如：**

原文：
```markdown
1. Introduction
This paper introduces...
2. Method
```

会被解析成：
```json
[
  { "type": "heading", "level": 1, "text": "Introduction" },
  { "type": "paragraph", "text": "This paper introduces..." },
  { "type": "heading", "level": 1, "text": "Method" }
]
```
这一步的意义是：
> 恢复文档逻辑结构。

### 3 LLM 推理生成初始目录

如果文档结构不明显（很多 PDF 都这样），系统会调用 LLM。

让 LLM：

> 根据文本推断文档目录结构

例如：

输入：
```txt
大量文本
```
输出：
```txt
1 Introduction
2 Background
3 Method
4 Experiment
```
这一步得到：

> Document Outline

也就是 **初始目录线索**。

### 4 构建文档树（Document Tree）

有了标题信息之后，就可以生成 文档树结构。

例如：
```txt
Document
 ├── Introduction
 │     ├── paragraph
 │     └── paragraph
 │
 ├── Method
 │     ├── subsection
 │     └── subsection
 │
 └── Experiment
```
内部结构通常是：
```
Node {
    title
    level
    content
    children
}
```

这样每一段文本都有：
- 父节点
- 子节点
- 层级关系

这就是 PageIndex 的核心结构。

### 5 文档 Chunk 切分

接下来系统会生成检索单元。

但和传统 RAG 不同：

> 不是固定长度切分

而是：

> 按结构切分

例如：
```
Section
Subsection
Paragraph
```
形成 chunk：
```
chunk_1 = "Introduction section"
chunk_2 = "Method subsection"
chunk_3 = "Experiment subsection"
```
同时保留：
```
parent
section path
```
例如：
```
path = Introduction > Background
```
这对于搜索非常重要。

### 6 Embedding 向量化

然后系统会对每个 chunk 生成向量存入向量库

### 7 构建索引

最终索引包含：
- text
- embedding
- tree path
- node id
- parent id

例如：
```json
{
  "text": "...",
  "vector": [...],
  "path": "Method > Architecture",
  "node_id": 123
}
```
到这里 **离线阶段完成**。


## 二、搜索流程（Query Pipeline）

当用户提问时，系统开始在线搜索流程。

### 1 Query 解析

用户输入：
```
How does the method work?
```
系统会：
- 清洗 query
- 生成 embedding

得到：
```
query vector
```

### 2 向量搜索

在向量数据库中查找 TopK 相似 chunk

返回：
```
Method section
Architecture subsection
Algorithm description
```
这是 第一层召回。

### 3 结构补全

如果只返回 chunk，LLM 很可能缺上下文。

所以 PageIndex 会：
- 补充父节点
- 补充兄弟节点
- 补充上下文

例如：

原始 chunk：
```
Algorithm Step 2
```
系统会扩展为：
```
Method
 └ Algorithm
      ├ Step1
      ├ Step2
      └ Step3
```
这样上下文完整。

### 4 上下文重排序

如果 chunk 很多，需要排序。

排序依据：
- embedding 相似度
- 文档结构距离
- LLM rerank

最终选择：`Top N context`

### 5 构造 LLM Prompt

系统构造 Prompt：
```
Context:
[document chunks]

Question:
user query
```
例如：
```
Answer based on the following document.
```

### 6 LLM 生成答案

最后调用 LLM 输出：

final answer

同时可能附带：
- 引用来源
- section path

例如：
```
Source: Method > Architecture
```

## 三、核心算法
### 1. 文档树生成算法
核心思想：
> 把文档转换成类似 HTML DOM 的树结构

结构示意：
```txt
Document
 ├── Section
 │     ├── Subsection
 │     │       ├── Paragraph
 │     │       └── Paragraph
 │     └── Subsection
 └── Section
```
每个节点都保存：
```txt
Node
 ├ id
 ├ title
 ├ content
 ├ level
 ├ parent
 └ children
```
构建流程通常是 三阶段。

#### 1 结构元素检测

首先解析文本块类型：
- heading
- paragraph
- list
- table
- code

例如：
```txt
1 Introduction
This paper proposes...
```
解析结果：
```txt
Heading(level=1)
Paragraph
```
在 PDF 场景下，通常还会利用：
- 字体大小
- 字体粗细
- 行距
- 版面布局

来识别标题。

例如：
```
FontSize > 18 → H1
FontSize > 14 → H2
```
这样可以初步恢复文档结构。

#### 2 层级推断

如果文档本身没有明确层级（很多 PDF 都是这样），就需要推断。

典型方法：

**方法1：规则推断**

例如：
```txt
1
1.1
1.1.1
```
直接转换成：
```
level1
level2
level3
```
**方法2：LLM 推断**

当结构不清晰时，让 LLM 推理：

输入：
```
大量文本片段
```
输出：
```
Possible outline:
1 Introduction
2 Background
3 Method
```
但注意：

> 不会把整个文档给 LLM。

而是：

> 抽样片段 + 标题候选

这样 token 很小。

#### 3 树结构构建

当拿到标题层级之后，构建树结构。

伪代码：
```
stack = []

for element in elements:
    if element is heading:
        while stack.top.level >= element.level:
            stack.pop()

        stack.top.children.append(element)
        stack.push(element)

    else:
        stack.top.children.append(element)
```
最终得到：
```
Document Tree
```
优势：
- 结构清晰
- 支持父子检索
- 支持上下文扩展


### 搜索时的结构扩展策略

普通 RAG 的最大问题：

> chunk 太碎

例如：
```txt
Algorithm Step 2
```
LLM 根本不知道：
```
Step1
Step3
```
PageIndex 的解决办法是：

> 结构扩展（Structure Expansion）

流程如下。

**1 初始向量召回**

首先正常向量搜索：
```
query embedding
↓
vector search
↓
topK chunks
```
例如：
```
Chunk A
Chunk B
Chunk C
```
但这些 chunk 只是局部。

**2 向上扩展（Parent Expansion）**

系统会找：

> 父节点

例如：

原始结果：
```
Algorithm Step 2
```
扩展后：
```
Method
 └ Algorithm
      └ Step 2
```
这样 LLM 就知道：

> 这是 Method 章节里的算法

**3 向下扩展（Child Expansion）**

如果 chunk 是一个标题节点：
```
Algorithm
```
系统会补充：
```
Algorithm
 ├ Step1
 ├ Step2
 └ Step3
```
这样内容更完整。

**4 兄弟节点扩展（Sibling Expansion）**

有时需要增加相邻信息：
```
Step1
Step2
Step3
```
而不是只给：
```
Step2
```
这样能明显提高回答质量。

**5 Token Budget 控制**

扩展不是无限的。

系统会控制：

> max_tokens

例如：

> 4000 tokens context

策略：
- 优先保留最相关 chunk
- 逐层扩展
- 直到 token 满

类似：
```
relevance-first expansion
```

### LLM 生成目录为什么不会超上下文

很多人看到 PageIndex 的一个步骤：

> LLM 推理生成文档目录

会有疑问：

> 文档几百页，LLM 怎么可能读完？

实际上它用了 分层策略。

**1 文档分段**

首先文档会被切成块：

> chunk size ≈ 500 tokens

例如：
```
chunk1
chunk2
chunk3
...
```
每个 chunk 单独分析。

**2 局部目录生成**

LLM 对每一小段生成：

> local outline

例如：
```
chunk1 → Introduction
chunk2 → Method
chunk3 → Experiment
```

**3 Outline 合并**

系统再把这些 outline 合并：

> merge outlines

类似：

> map-reduce

过程：
```
local outline
     ↓
merge
     ↓
global outline
```

**4 层级压缩**

如果目录太长，还会压缩：

例如：

原始：
```
1 Introduction
1.1 Motivation
1.2 Background
2 Method
2.1 Architecture
2.2 Training
```
压缩为：
```
Introduction
Method
Experiment
```
这样 token 极小

PageIndex架构分析

![](https://blog.42tr.cn/static/img/091832ca46397412018e0f979e75b806.image.png)



## 环境准备
需要 jeprof 工具解析 heap 文件 `apt install libjemalloc-dev graphviz`

## 代码
cargo.toml
```toml
[package]
name = "test260202"
version = "0.1.0"
edition = "2024"

[dependencies]
tikv-jemallocator = { version = "0.6", features = ["profiling"] }
tikv-jemalloc-ctl = { version = "0.6", features = ["profiling", "use_std"] }
```

main.rs
```rust
#[global_allocator]
static GLOBAL: tikv_jemallocator::Jemalloc = tikv_jemallocator::Jemalloc;

#[unsafe(export_name = "_rjem_malloc_conf")]
// lg_prof_sample:0 表示每次分配都采样(最详细,但性能开销大)
// lg_prof_sample:10 表示每 1KB 采样一次(推荐)
// lg_prof_sample:19 表示每 512KB 采样一次(默认值)
pub static MALLOC_CONF: &[u8] = b"prof:true,prof_active:true,lg_prof_sample:10\0";

use std::{
    ffi::CString,
    fs,
    process::Command,
    time::{Duration, SystemTime, UNIX_EPOCH},
};

use tikv_jemalloc_ctl::raw;
fn main() {
    let mut keep = Vec::new();
    for _ in 0..1024 {
        keep.push(vec![0u8; 4096]);
    }
    std::thread::sleep(Duration::from_millis(200));

    let path = heap_profile_pdf_impl();
    println!("Heap profile PDF saved to {}", path.display());
    std::mem::forget(keep);
}

fn heap_profile_pdf_impl() -> std::path::PathBuf {
    let pid = std::process::id();
    let ts = SystemTime::now()
        .duration_since(UNIX_EPOCH)
        .expect("SystemTime error")
        .as_secs();

    // 生成 heap dump 文件
    let heap_filename = format!("heap.{}.{}.heap", pid, ts);
    let mut heap_path = std::env::temp_dir();
    heap_path.push(&heap_filename);
    let heap_path_str = heap_path.to_string_lossy().into_owned();
    let c_path =
        CString::new(heap_path_str.clone()).expect("Failed to create C string for heap path");

    // 导出 heap dump
    println!("Generating heap dump: {}", heap_path_str);
    let ptr = c_path.as_ptr();
    unsafe {
        raw::write(b"prof.dump\0", ptr).expect("jemalloc heap dump failed");
    }

    // 生成 PDF 文件
    let pdf_filename = format!("heap.{}.{}.pdf", pid, ts);
    let mut pdf_path = std::env::current_dir().expect("Failed to get current dir");
    pdf_path.push(&pdf_filename);
    let pdf_path_str = pdf_path.to_string_lossy().into_owned();

    // 获取当前二进制文件路径
    let binary_path = std::env::current_exe().expect("Failed to get binary path");
    let binary_path_str = binary_path.to_string_lossy();

    println!(
        "Running jeprof: binary={}, heap={}, output={}",
        binary_path_str, heap_path_str, pdf_path_str
    );

    // 执行 jeprof 命令
    let output = Command::new("jeprof")
        .arg("--pdf")
        .arg(binary_path_str.as_ref())
        .arg(&heap_path_str)
        .output()
        .expect("Failed to execute jeprof (make sure jeprof is installed)");

    if !output.status.success() {
        let stderr = String::from_utf8_lossy(&output.stderr);
        let _ = fs::remove_file(&heap_path);
        panic!("jeprof execution failed: {}", stderr);
    }

    // 读取生成的 PDF
    let pdf_bytes = output.stdout;
    if pdf_bytes.is_empty() {
        let _ = fs::remove_file(&heap_path);
        panic!("jeprof generated empty PDF");
    }

    fs::write(&pdf_path, &pdf_bytes).expect("Failed to write PDF");

    // 清理临时文件
    let _ = fs::remove_file(&heap_path);

    println!(
        "Successfully generated heap profile PDF: {} bytes",
        pdf_bytes.len()
    );

    pdf_path
}
```

## 使用
`cargo run` 在当前目录生成文件 `heap.3742391.1770170243.pdf`，可以加到 debug 中实时生成 heap 文件，pdf 文件可后续有问题时再解析，也可以使用其他方式处理 heap 文件。

rust内存分析

估算一台机器~



## 估算方式

- **CPU**：核心数 × 主频 × 每核心每周期 FP32 FLOPs ≈ FP32 GFLOPS
- **GPU**：CUDA cores × 主频 × 2

### 树莓派

```shell
# lscpu
Architecture:             aarch64
  CPU op-mode(s):         32-bit, 64-bit
  Byte Order:             Little Endian
CPU(s):                   4
  On-line CPU(s) list:    0-3
Vendor ID:                ARM
  Model name:             Cortex-A72
    Model:                3
    Thread(s) per core:   1
    Core(s) per cluster:  4
    Socket(s):            -
    Cluster(s):           1
    Stepping:             r0p3
    CPU max MHz:          1800.0000
    CPU min MHz:          600.0000
    BogoMIPS:             108.00
    Flags:                fp asimd evtstrm crc32 cpuid
Caches (sum of all):
  L1d:                    128 KiB (4 instances)
  L1i:                    192 KiB (4 instances)
  L2:                     1 MiB (1 instance)
Vulnerabilities:
  Gather data sampling:   Not affected
  Itlb multihit:          Not affected
  L1tf:                   Not affected
  Mds:                    Not affected
  Meltdown:               Not affected
  Mmio stale data:        Not affected
  Reg file data sampling: Not affected
  Retbleed:               Not affected
  Spec rstack overflow:   Not affected
  Spec store bypass:      Vulnerable
  Spectre v1:             Mitigation; __user pointer sanitization
  Spectre v2:             Vulnerable
  Srbds:                  Not affected
  Tsx async abort:        Not affected
```

注：
- 支持 NEON SIMD，128-bit
- FP32 SIMD vector 长度 4 → 每周期 4 FLOPs
- Cortex-A72 可以做 FMA（乘加） → 每周期 8 FLOPs

理论峰值算力 = 4 × 1.8 GHz × 8 = **57.6 GFLOPS**（FP32）


ARM + 内存带宽限制较明显，经验值：

实际可用 FP32：30% ~ 60% ≈ **17 ~ 35 GFLOPS**

### mac mini m1
#### CPU
FP32 GFLOPS = (P核 × P频率 + E核 × E频率) × 8
```shell
sysctl -n hw.perflevel0.physicalcpu   # 性能核（P-core）
sysctl -n hw.perflevel1.physicalcpu   # 能效核（E-core）
```
看芯片型号
```shell
sysctl -n machdep.cpu.brand_string
```
|芯片|P 核频率|E 核频率|
|-|-|-|
|M1|~3.2 GHz|~2.0 GHz|
|M2|~3.5 GHz|~2.4 GHz|
|M3|~4.0 GHz|~2.8 GHz|

```shell
$ sysctl -n hw.perflevel0.physicalcpu
6

$ sysctl -n hw.perflevel1.physicalcpu
2

$ sysctl -n machdep.cpu.brand_string
Apple M1 Pro

```

算力 ≈ ( 6 x 3.2 + 2 x 2.0 ) x 8 = **185.6 GFLOPS**

Apple Silicon 内存带宽强，但调度保守：

实际可用 FP32 ≈ 60% ~ 80%

≈ **110 ~ 150 GFLOPS**

#### GPU
```shell
$ system_profiler SPDisplaysDataType

Graphics/Displays:

    Apple M1 Pro:

      Chipset Model: Apple M1 Pro
      Type: GPU
      Bus: Built-In
      Total Number of Cores: 14
      Vendor: Apple (0x106b)
      Metal Support: Metal 4
      Displays:
        Color LCD:
          Display Type: Built-in Liquid Retina XDR Display
          Resolution: 3024 x 1964 Retina
          Main Display: Yes
          Mirror: Off
          Online: Yes
          Automatically Adjust Brightness: Yes
          Connection Type: Internal
```
**官方参考 FP32 理论峰值**
|芯片 / 核心数|FP32 TFLOPS|
|-|-|
|M1 Pro 14 核|~2.3 TFLOPS|
|M1 Pro 16 核|~2.6 TFLOPS|

### Linux 服务器
```shell
$ lscpu
Architecture:             x86_64
  CPU op-mode(s):         32-bit, 64-bit
  Address sizes:          46 bits physical, 57 bits virtual
  Byte Order:             Little Endian
CPU(s):                   128
  On-line CPU(s) list:    0-127
Vendor ID:                GenuineIntel
  Model name:             INTEL(R) XEON(R) GOLD 6530
    CPU family:           6
    Model:                207
    Thread(s) per core:   2
    Core(s) per socket:   32
    Socket(s):            2
    Stepping:             2
    CPU max MHz:          4000.0000
    CPU min MHz:          800.0000
    BogoMIPS:             4200.00
    Flags:                fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc a
                          rt arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf tsc_known_freq pni pclmulqdq dtes64 ds_cpl vmx smx est tm2 ssse3 sdbg fma cx16 xtpr p
                          dcm pcid dca sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch cpuid_fault epb cat_l3 cat_l2 cdp_l3 intel_pp
                          in cdp_l2 ssbd mba ibrs ibpb stibp ibrs_enhanced tpr_shadow flexpriority ept vpid ept_ad fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid cqm rdt_a avx512f avx
                          512dq rdseed adx smap avx512ifma clflushopt clwb intel_pt avx512cd sha_ni avx512bw avx512vl xsaveopt xsavec xgetbv1 xsaves cqm_llc cqm_occup_llc cqm_mbm_total cqm_
                          mbm_local split_lock_detect user_shstk avx_vnni avx512_bf16 wbnoinvd dtherm ida arat pln pts vnmi avx512vbmi umip pku ospke waitpkg avx512_vbmi2 gfni vaes vpclmulq
                          dq avx512_vnni avx512_bitalg tme avx512_vpopcntdq la57 rdpid bus_lock_detect cldemote movdiri movdir64b enqcmd fsrm md_clear serialize tsxldtrk pconfig arch_lbr ib
                          t amx_bf16 avx512_fp16 amx_tile amx_int8 flush_l1d arch_capabilities
Virtualization features:
  Virtualization:         VT-x
Caches (sum of all):
  L1d:                    3 MiB (64 instances)
  L1i:                    2 MiB (64 instances)
  L2:                     128 MiB (64 instances)
  L3:                     320 MiB (2 instances)
NUMA:
  NUMA node(s):           2
  NUMA node0 CPU(s):      0-31,64-95
  NUMA node1 CPU(s):      32-63,96-127
Vulnerabilities:
  Gather data sampling:   Not affected
  Itlb multihit:          Not affected
  L1tf:                   Not affected
  Mds:                    Not affected
  Meltdown:               Not affected
  Mmio stale data:        Not affected
  Reg file data sampling: Not affected
  Retbleed:               Not affected
  Spec rstack overflow:   Not affected
  Spec store bypass:      Mitigation; Speculative Store Bypass disabled via prctl
  Spectre v1:             Mitigation; usercopy/swapgs barriers and __user pointer sanitization
  Spectre v2:             Mitigation; Enhanced / Automatic IBRS; IBPB conditional; RSB filling; PBRSB-eIBRS SW sequence; BHI BHI_DIS_S
  Srbds:                  Not affected
  Tsx async abort:        Not affected
```
注：
- Xeon Gold 6530 支持 AVX512
- 每个 AVX512 vector 寄存器 512 bit → 16 FP32 per vector
- CPU 支持 FMA（乘加） → 每周期每核心可以执行 32 FLOPs

2 × Intel Xeon Gold 6530，一共 128 逻辑核心（64 物理核心 × 2 超线程）

理论峰值算力 = 64 × 4 GHz × 32 = **8.2 TFLOPS**（FP32）

实际可用通常 70–80% ≈ **5.74 ~ 6.56 TFLOPS**

```shell
$ nvidia-smi
Wed Jan  7 17:51:05 2026
+-----------------------------------------------------------------------------------------+
| NVIDIA-SMI 570.169                Driver Version: 570.169        CUDA Version: 12.8     |
|-----------------------------------------+------------------------+----------------------+
| GPU  Name                 Persistence-M | Bus-Id          Disp.A | Volatile Uncorr. ECC |
| Fan  Temp   Perf          Pwr:Usage/Cap |           Memory-Usage | GPU-Util  Compute M. |
|                                         |                        |               MIG M. |
|=========================================+========================+======================|
|   0  NVIDIA GeForce RTX 4090        Off |   00000000:4B:00.0 Off |                  Off |
| 30%   29C    P8              8W /  450W |    7449MiB /  24564MiB |      0%      Default |
|                                         |                        |                  N/A |
+-----------------------------------------+------------------------+----------------------+
|   1  NVIDIA GeForce RTX 4090        Off |   00000000:4C:00.0 Off |                  Off |
| 30%   31C    P8              8W /  450W |   21079MiB /  24564MiB |      0%      Default |
|                                         |                        |                  N/A |
+-----------------------------------------+------------------------+----------------------+
|   2  NVIDIA GeForce RTX 4090        Off |   00000000:4E:00.0 Off |                  Off |
| 30%   29C    P8             10W /  450W |    3457MiB /  24564MiB |      0%      Default |
|                                         |                        |                  N/A |
+-----------------------------------------+------------------------+----------------------+
|   3  NVIDIA GeForce RTX 4090        Off |   00000000:4F:00.0 Off |                  Off |
| 30%   31C    P8              7W /  450W |    2007MiB /  24564MiB |      0%      Default |
|                                         |                        |                  N/A |
+-----------------------------------------+------------------------+----------------------+
|   4  NVIDIA GeForce RTX 4090        Off |   00000000:CB:00.0 Off |                  Off |
| 30%   33C    P8              7W /  450W |   20443MiB /  24564MiB |      0%      Default |
|                                         |                        |                  N/A |
+-----------------------------------------+------------------------+----------------------+
|   5  NVIDIA GeForce RTX 4090        Off |   00000000:CC:00.0 Off |                  Off |
| 30%   34C    P8              5W /  450W |   20359MiB /  24564MiB |      0%      Default |
|                                         |                        |                  N/A |
+-----------------------------------------+------------------------+----------------------+
|   6  NVIDIA GeForce RTX 4090        Off |   00000000:CE:00.0 Off |                  Off |
| 30%   31C    P8              7W /  450W |   20359MiB /  24564MiB |      0%      Default |
|                                         |                        |                  N/A |
+-----------------------------------------+------------------------+----------------------+
|   7  NVIDIA GeForce RTX 4090        Off |   00000000:CF:00.0 Off |                  Off |
| 30%   32C    P8              5W /  450W |   22098MiB /  24564MiB |      0%      Default |
|                                         |                        |                  N/A |
+-----------------------------------------+------------------------+----------------------+
```
| GPU      | CUDA 核心 | 基本时钟     | FP32 计算能力          |
| -------- | ------- | -------- | ------------------ |
| RTX 4090 | 16,384  | 2.23 GHz | ~82.6 TFLOPS（FP32） |

82.6 TFLOPS × 8 ≈ **660 TFLOPS**（理论峰值）

实际可用（70–80%）≈ **450–500 TFLOPS**


### 对比
|项目|树莓派 4|M1 Pro|服务器|
|-|-|-|-|
|理论 FP32|~58 GFLOPS|~186 GFLOPS|8.2 TFLOPS|
|实际 FP32|~20–30|~110–150| 5.12 ~ 6.56|
|倍数|1×|~5–6×|~170-328x|

|项目|树莓派 4|M1 Pro|服务器|
|-|-|-|-|
|GPU FP32|~10 GFLOPS|~2.6 TFLOPS|~660 TFLOPS|
|AI / 专用计算单元|❌|Neural Engine ≈ 11 TOPS|Tensor Core（4090）≈ 1300+ TOPS INT8|

M1 Pro ≈ 树莓派 100×

8×4090 服务器 ≈ M1 Pro 60×

服务器 ≈ 树莓派 8000×

算力

最小化部署 git server ~





# 创建用户
`adduser git`

# 切换到 git 用户
`su - git`

# 创建裸仓库
没有工作目录，专用于服务器存储，不能直接编辑文件

```shell
mkdir -p /home/git/myproject.git
cd /home/git/myproject.git
git init --bare
```

# 创建钩子脚本
```shell
vim /home/git/myproject.git/hooks/post-receive
# 赋予执行权限
chmod +x /home/git/myproject.git/hooks/post-receive
```
钩子脚本内容
```shell
#!/bin/bash
# 执行你的自定义脚本
/path/to/your/script.sh
# 可选：输出日志到文件（调试用）
# echo "$(date): Push received" >> /tmp/git-hook.log
```

# 使用
```shell
git remote set-url origin ssh://git@42tr.cn:8899/home/git/x.git
```
本地使用
```shell
git clone ssh://git@127.0.0.1/home/git/x.git
```
钩子脚本权限问题 `sudo visudo` 增加一行
```
git ALL=(root) NOPASSWD: /path/to/your/script.sh
```
然后钩子脚本中改用 `sudo /path/to/your/script.sh` 执行

轻量化部署 git server

测试 cpu 和写入性能~



`Cargo.toml`
```toml
[package]
name = "test01"
version = "0.1.0"
edition = "2024"

[dependencies]
rand = "0.9.2"
rand_xoshiro = "0.7.0"
rayon = "1.11.0"
```

`main.rs`
```rust
use rand_xoshiro::Xoshiro256PlusPlus;
use rand::{RngCore, SeedableRng};
use std::fs::File;
use std::io::{BufWriter, Write};
use std::time::Instant;
use rayon::prelude::*;   // ← 需要这个

const CHARSET: &[u8; 64] = b"ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/";
const LINE_LEN: usize = 100;
const BATCH: usize = 100000;
const TOTAL_LINE: usize = 10_000_000;
const THREAD_NUM: usize = 8;

fn main() {
    rayon::ThreadPoolBuilder::new()
        .num_threads(THREAD_NUM)
        .build_global()
        .unwrap();

    let start = Instant::now();

    (0..THREAD_NUM).into_par_iter().for_each(|chunk| {
        let mut rng = Xoshiro256PlusPlus::seed_from_u64(123456 + chunk as u64);

        let filename = format!("log{}.txt", chunk);
        let file = File::create(filename).unwrap();
        let mut writer = BufWriter::new(file);

        let mut buf = vec![0u8; BATCH * LINE_LEN];

        for _ in 0..(TOTAL_LINE / THREAD_NUM / BATCH) {
            rng.fill_bytes(&mut buf);

            for b in &mut buf {
                *b = CHARSET[(*b & 63) as usize];
            }

            writer.write_all(&buf).unwrap();
        }

        writer.flush().unwrap();
    });

    println!("Time: {:?}", start.elapsed());
}
```

在 m1 macbook pro 8c 上
```plaintext
Time: 1.50388325s
```