Chunk Size（分块大小）

3 秒看懂

Chunk Size 是将长文本/长序列切割成可管理小块时，每一块的大小（通常以 token 数或字符数计量）。 它不是某个特定硬件规格，而是一个横跨 RAG 检索、LLM 推理调度、数据管线的”旋钮参数”——调大调小直接影响检索精度、显存占用和推理吞吐。

3 分钟产业解释

为什么一个”切割参数”值得产业级关注？

在当前大模型落地的实际工程中，几乎所有系统都需要把超长输入切分成若干”chunk”来处理：

场景	被切分的对象	Chunk Size 指什么	产业痛点
RAG 检索增强生成	文档/网页/PDF	每个文本块的 token 数	切太大→检索不准；切太小→语义断裂，召回碎片化
LLM 推理（Prefill 阶段）	长 prompt	单次送入 attention 的 token 数	太大→单请求霸占 GPU，阻塞其他请求；太小→频繁启动 kernel，overhead 高
分布式训练	微批次数据	单个 micro-batch 的 token 数	影响流水线气泡率、梯度累积步数
向量数据库写入	embedding 批次	单批写入行数	影响写入吞吐和索引构建效率

一句话：Chunk Size 是大模型系统工程中”分而治之”策略的核心旋钮，不同场景下最优值差异巨大，且往往需要与模型上下文窗口、硬件显存、检索算法联合调优。

15 分钟专家深入

一、RAG 场景中的 Chunk Size——最核心战场

RAG（Retrieval-Augmented Generation）是当前企业级 AI 应用的主战场。其基本流程：

原始文档 → 切分(Chunking) → 向量化(Embedding) → 存入向量数据库 → 检索 → 拼入 prompt → LLM 生成

Chunk Size 是这个管线中最上游、影响最深远的超参数。

1.1 典型取值范围

Chunk Size（tokens）	适用场景	优势	劣势
128–256	细粒度 FAQ、代码片段检索	召回精准，噪声少	语境断裂严重，需多 chunk 拼接
256–512	通用知识库问答（工程主流区间）	精度与上下文的平衡点	仍可能丢失跨段落关联
512–1024	长文档摘要、合同分析	保留更多上下文	检索粒度粗，可能召回无关内容
>1024	特定长文任务	极端上下文保留	embedding 模型截断风险；向量空间语义稀释

⚠️ 关键依赖：Chunk Size 的有效上限受 embedding 模型的最大输入长度约束。例如，若 embedding 模型最大输入为 512 tokens，则 chunk 超过此值会被截断，语义信息丢失。常见 embedding 模型如 OpenAI text-embedding-3 系列、BGE 系列的最大输入长度各异，需逐一确认 [厂商文档]。

1.2 切分策略不只是”固定窗口”

策略	描述	优缺点
固定大小（Fixed-size）	每 N 个 token 切一刀	简单，但可能在句子/段落中间截断
递归字符切分（Recursive Character）	先按段落→句子→字符递归切	LangChain 默认策略，语义保持较好
语义切分（Semantic Chunking）	计算相邻句子 embedding 余弦相似度，拐点处切	效果好但计算开销大 [Andrew Ng 讨论]
文档结构切分	按 Markdown 标题 / HTML 标签 / PDF 段落	保留结构语义，依赖文档格式质量
重叠窗口（Overlap）	相邻 chunk 有 10%–20% token 重叠	缓解边界语义丢失，但增加索引存储量

Overlap（重叠量） 通常是 Chunk Size 的 10%–20%，与 Chunk Size 联合调优。

1.3 Chunk Size 与检索质量的关系

直觉上：

Chunk 越小 → 每个向量的语义越聚焦 → 精确匹配（exact match）能力越强 → 但”需要跨 chunk 理解”的问题会失败
Chunk 越大 → 每个向量的语义越稀释 → 可能检索到”包含答案但噪声很大”的块 → LLM 需要更强的”大海捞针”能力

实际最佳实践往往是多粒度索引（multi-granularity indexing）：同时索引 256-token 和 1024-token 的 chunk，检索时融合排序。这在工程上增加了 2–3 倍的向量存储和 embedding 计算成本 [行业工程实践估算]。

二、LLM 推理中的 Chunk Size（Prefill Chunking）

在 LLM serving（vLLM、TensorRT-LLM、SGLang 等）中，“chunk”概念出现在 prefill 阶段的调度策略中：

2.1 Prefill vs Decode 的矛盾

Prefill（处理 prompt）：计算密集型，GPU 算力利用率高
Decode（逐 token 生成）：访存密集型，GPU 算力利用率低

如果一个超长 prompt 的 prefill 一次完成，会长时间独占 GPU，导致同一 GPU 上的其他 decode 请求被阻塞（延迟飙升）。

2.2 Chunked Prefill 策略

核心思想：将长 prompt 的 prefill 分成多个 chunk，每个 chunk 与 decode 请求交替调度。

┌─────────┐ ┌─────────┐ ┌─────────┐
│ Prefill  │ │ Decode   │ │ Prefill  │ │ Decode   │
│ Chunk 1  │ │ (batch)  │ │ Chunk 2  │ │ (batch)  │
└─────────┘ └─────────┘ └─────────┘

Chunk Size 在此的含义：单次 prefill 处理的 token 数。

常见配置：512–2048 tokens/chunk [SGLang/DeepSeek 工程实践]
太小：kernel launch overhead 增大，throughput 下降
太大：其他请求等待时间过长，P99 延迟恶化

这一策略在 DeepSeek 系列模型的 serving 论文以及 SGLang 的实现中有较详细讨论 [厂商技术博客]。

2.3 与 KV Cache 的关系

每处理一个 chunk，就产生对应位置的 KV Cache。Chunk Size 影响：

显存峰值：单 chunk 越大，attention 矩阵的峰值显存越高（尤其在没有 FlashAttention 的情况下）
KV Cache 分配粒度：PagedAttention（vLLM）以 block 为单位分配 KV Cache，block size 与 chunk size 需协调

三、分布式训练中的 Chunk / Micro-batch Size

在 Pipeline Parallelism 中：

全局 batch 被切分成多个 micro-batch
每个 micro-batch 的 token 数可理解为训练场景的”chunk size”
梯度累积步数 = 全局 batch / micro-batch 数

Micro-batch 越小 → 流水线气泡比例越高（计算/通信 ratio 下降）；越大 → 显存占用越高。

典型配置（以 Megatron-LM 为代表框架）：micro-batch size 通常为 1–8 个 sequence，每个 sequence 长度常见 2048–8192 tokens [Megatron-LM 文档/论文]。

技术原理（最深一层）

Chunk Size 如何影响 Attention 计算

Transformer 的 self-attention 计算复杂度为 O(n²·d)，其中 n 为序列长度，d 为 head dimension。

┌──────────────────────────────────────────────────┐
│           Self-Attention 计算流程                   │
│                                                    │
│  Q, K, V = X · Wq, X · Wk, X · Wv                │
│                                                    │
│  Attention(Q,K,V) = softmax(QK^T / √d_k) · V     │
│                                                    │
│  QK^T 矩阵: [n × n]，显存占用 O(n²)               │
│                                                    │
│  当 chunk_size = n:                                │
│    - 若 n 小(如 256): QK^T ≈ 64K 元素，可控        │
│    - 若 n 大(如 8192): QK^T ≈ 64M 元素，显存压力大  │
│                                                    │
│  FlashAttention 的 tiling 策略:                     │
│    将 Q/K/V 按 block(通常 128 tokens)切块计算       │
│    → 与上层"chunk size"形成两级分块层次             │
└──────────────────────────────────────────────────┘

关键洞察：FlashAttention 内部也有”chunk”（tiled block），其 block size（通常 64–128 tokens）与上层 chunk size 是不同层次的分块：

上层 chunk size：调度/系统层面的序列切分
FlashAttention block size：硬件/算子层面的计算切分

两者独立调优，但共同决定端到端的显存与延迟特征。

Embedding 模型的 Chunk 处理

当 chunk 送入 embedding 模型时：

Chunk (e.g., 512 tokens)
    ↓
Tokenizer → Token IDs [512]
    ↓
Transformer Encoder (or similar)
    ↓
Pooling (CLS / Mean / Last Token)
    ↓
Embedding Vector (e.g., 1536-dim for OpenAI text-embedding-3-small)

若 chunk 长度 > embedding 模型 max_position_embeddings，超出部分被截断，语义丢失。这是 chunk size 的硬上限约束。

技术演进史

时期	Chunk Size 主要语境	典型值	驱动因素
2020–2021	几乎不讨论；NLP 处理以 512 token 上限为主	512（模型硬限制）	BERT max_length = 512；GPT-3 context = 2048
2022	RAG 概念兴起，LangChain 推广固定切分	1000–2000 字符（约 300–600 tokens）	ChatGPT 催化 RAG 工程化
2023	RAG 工程化爆发，chunk 调优成为显学	256–512 tokens 成为主流	社区实验发现小 chunk 召回更准；embedding 模型进步
2023 Q4–2024	Chunked Prefill 在 serving 层面兴起	Prefill chunk: 512–2048 tokens	长 context（128K+）模型普及；SGLang/vLLM 优化
2024–2025	多粒度索引、Late Chunking、Contextual Retrieval	混合粒度	Anthropic 提出 Contextual Retrieval；Jina AI 提出 Late Chunking（先编码再切分）

重要趋势：

Late Chunking（2024，Jina AI 提出）：先将完整文档送入长上下文 embedding 模型得到 token-level 表示，再在表示空间上切分池化。这从根本上改变了”先切再编码”的传统范式，使得 chunk 边界的语义断裂问题大幅缓解。
Anthropic Contextual Retrieval（2024）：在每个 chunk 前拼接一段由 LLM 生成的上下文摘要，再做 embedding。本质上是用计算换 chunk 边界信息损失，可在不改变 chunk size 的前提下提升检索质量。

技术路线对比

Chunk Size 选取策略对比

维度	固定小 Chunk (≤256)	固定中 Chunk (256–512)	固定大 Chunk (512–1024)	多粒度索引	Late Chunking
检索精度	★★★★★	★★★★	★★★	★★★★★	★★★★★
上下文完整性	★★	★★★	★★★★	★★★★	★★★★★
索引存储	小	中	大	大（2–3×）	中
Embedding 计算	低	中	高	高（2–3×）	极高（长上下文模型）
工程复杂度	低	低	低	中	高
适用场景	FAQ、代码	通用 RAG	长文摘要	生产级 RAG	高质量 RAG（预算充足）

Prefill Chunk Size 对比（推理 serving）

Prefill Chunk Size	GPU 利用率	其他请求延迟影响	适用场景
小（≤512 tokens）	较低（kernel overhead）	低（友好）	低延迟交互场景
中（512–2048）	较高	中	通用 serving 主流
大（>2048）	高	高（阻塞他人）	离线批处理、吞吐优先

上下游

上游依赖

上游环节	与 Chunk Size 的关系
Tokenizer	Chunk Size 的计量单位是 token，tokenizer 的分词粒度直接决定实际文本长度对应关系
Embedding 模型	最大输入长度是 chunk size 的硬上限
LLM Context Window	检索到的 chunks 总量不能超过 LLM 的可用 context（需预留生成空间）
向量数据库	单条向量的 payload 大小、索引类型（HNSW/IVF）影响 chunk 元数据存储
GPU 显存	Prefill chunk size 受 KV Cache 显存预算约束

下游影响

下游环节	影响
检索质量（Recall@K, MRR）	直接决定
LLM 生成质量	间接决定（通过检索结果质量）
Serving 延迟（TTFT, TPS）	Prefill chunk size 直接影响
基础设施成本	索引存储、embedding 计算、GPU 占用均受影响

关键指标

指标	含义	典型范围	与 Chunk Size 的关系
Recall@K	Top-K 检索结果中包含正确答案的比例	0.7–0.95（优质 RAG）	核心优化目标，chunk size 直接影响
MRR（Mean Reciprocal Rank）	正确答案在检索结果中的排名倒数均值	0.5–0.9	chunk size 影响排序质量
TTFT（Time to First Token）	用户发出请求到首个生成 token 的延迟	0.5–5s	Prefill chunk size 影响
KV Cache 显存占用	单请求占用的 KV Cache 大小	与 sequence length × layer × hidden dim 成正比	Chunk 过大→单次 prefill 显存峰值高
Embedding 吞吐	每秒可处理的 token 数	取决于模型和硬件	Chunk 越大→单次推理吞吐越高（到某阈值前）
索引膨胀比	有 overlap 的 chunk 总 token 数 / 原始文档 token 数	1.1–1.3（典型 overlap 10%–20%）	Overlap 直接增加

供需与市场数据

RAG 市场规模

RAG 已成为企业 AI 落地的主流架构。相关市场数据：

全球向量数据库市场：预计 2025 年达到数十亿美元规模 [行业报告估算，具体数字因来源差异较大]
企业 AI 应用中采用 RAG 架构的比例：估计 60%–80% 的企业 LLM 应用使用某种形式的检索增强 [Gartner/行业调研估算]
Chunk 优化工具/平台：LangChain、LlamaIndex 等框架内置 chunk 策略调参能力；新兴工具如 Unstructured.io 专注文档智能切分

Chunk Size 调优的隐性成本

成本项	描述	量级估算
工程人力	调参、AB 测试、评估	每个项目 2–4 周 [行业经验估算]
Embedding 计算	多粒度索引需多次 embedding	2–3× 单粒度成本 [估算]
向量存储	更多 chunk → 更多向量	与 chunk 数线性相关
检索延迟	更多候选向量 → 检索稍慢	通常可忽略（向量 DB 优化后）

代表公司与资本映射

公司/项目	与 Chunk Size 的关联	备注
LangChain	提供 RecursiveCharacterTextSplitter 等多种 chunking 策略	RAG 工程的事实标准框架
LlamaIndex	提供 SentenceWindowNodeParser、SemanticSplitterNodeParser 等高级 chunking	专注 RAG 的数据框架
Jina AI	提出 Late Chunking；发布长上下文 embedding 模型	重新定义 chunking 范式
Anthropic	提出 Contextual Retrieval	用 LLM 增强 chunk 语义
Unstructured.io	专注文档解析与智能切分	非结构化数据处理基础设施
Weaviate / Pinecone / Milvus	向量数据库，chunk 存储与检索	受益于 RAG 普及
vLLM / SGLang	实现 Chunked Prefill 推理调度	推理 serving 层面的 chunk 优化
NVIDIA (TensorRT-LLM)	推理引擎中实现 chunked context / inflight batching	硬件+软件栈整合

投资逻辑

核心观点

Chunk Size 本身不是一个可投资的”概念”，但它所处的位置揭示了几个投资主题：

RAG 工程化工具链：Chunking 是 RAG 管线中最”脏”的环节（需要大量人工调优），这意味着自动化 chunking 优化工具存在产品化空间。关注 LangChain/LlamaIndex 的商业化进展，以及新兴的 RAG-as-a-Service 平台。
Embedding 模型进化：Late Chunking 等技术降低对 chunk 策略的敏感度，长上下文 embedding 模型成为关键。关注 Jina、Cohere 等 embedding 专业厂商。
推理 serving 效率：Chunked Prefill 提升长 prompt 场景的 serving 效率，直接关系到推理服务的经济性。关注 vLLM、SGLang 生态及其商业化实体。
向量数据库：多粒度索引策略增加向量存储需求，利好向量数据库厂商（Weaviate、Pinecone、Milvus/Zilliz 等）。
隐性壁垒：企业积累的 chunk 策略调优经验（针对其特定文档类型）构成数据飞轮壁垒——好的 chunk 策略 → 更好的检索 → 更好的 LLM 输出 → 更多用户反馈 → 更好的调优。这种飞轮在垂直领域（法律、医疗、金融）尤其显著。

风险点

长上下文模型可能削弱 RAG 需求：如果模型 context window 足够大（如 >1M tokens）且推理成本足够低，“全部塞进 prompt”可能成为简单替代方案。但短期内（2025），长上下文的推理成本仍然过高，RAG 仍是主流。
Chunk Size 调优的”炼金术”属性：目前缺乏系统性理论，大量依赖经验调参，可能被更好的自动化方法取代。

常见误读纠偏

❌ 误读 1：“Chunk Size 越小检索越准，所以应该尽量切小”

纠偏：Chunk Size 过小会导致语义断裂。例如，一个完整的因果推理（“因为A，所以B”）被切到两个 chunk 中，检索到任何一个 chunk 都无法完整回答问题。最优 chunk size 是语义完整性与检索粒度的平衡点，不存在”越小越好”的简单规律。实际工程中，256–512 tokens 是经过大量实验验证的”甜区”，但需要结合具体文档类型和任务验证。

❌ 误读 2：“Chunk Size 是 RAG 专属概念”

纠偏：Chunk Size/Chunking 在 AI 系统中至少出现在三个层面——RAG 文档切分、LLM 推理 Prefill 调度（Chunked Prefill）、分布式训练的 micro-batch 切分。三者的”chunk”含义和优化目标完全不同。混淆三者会导致在讨论中产生歧义。

❌ 误读 3：“选好 Chunk Size 就能解决 RAG 检索质量问题”

纠偏：Chunk Size 只是 RAG 质量的影响因素之一。其他关键因素包括：

Embedding 模型质量（通常比 chunk size 影响更大）
检索算法（BM25 vs 语义检索 vs 混合检索）
Reranking 策略（二阶段检索的 reranker 质量）
Query 改写与扩展
文档预处理质量（OCR、表格解析等）

在很多实际案例中，切换 embedding 模型或加入 reranker 带来的提升远大于调 chunk size。

❌ 误读 4：“所有文档应该用统一的 Chunk Size”

纠偏：不同类型文档的最优 chunk size 不同。FAQ 适合短 chunk，技术手册适合按章节切分，法律合同适合按条款切分。生产级 RAG 系统通常需要按文档类型/来源分别配置 chunk 策略。

学习路径

入门（2–4 小时）

LangChain 文档 — Text Splitters 章节：了解固定切分、递归切分的基本 API
LlamaIndex 文档 — Node Parser 章节：了解语义切分、窗口切分等高级策略
动手实验：用同一份 PDF，分别以 256/512/1024 tokens 切分，对比检索结果质量

进阶（1–2 天）

Anthropic “Contextual Retrieval” 博文（2024）：理解 chunk 边界信息损失的系统性解决方案
Jina AI “Late Chunking” 博文（2024）：理解从”先切再编码”到”先编码再切”的范式转换
vLLM/SGLang 文档 — Chunked Prefill 章节：理解推理 serving 层面的 chunk 概念
“RAG 应用实战”类教程：在真实数据集上做 chunk size 的 grid search 实验

专家（持续）

阅读原始论文：
- FlashAttention 系列（理解 tiling block 与上层 chunk 的层次关系）
- LongRoPE / YaRN 等位置编码论文（理解 context window 如何影响 chunk 策略选择）
关注 SGLang / vLLM 的 GitHub issues 和 PR：工程前沿的 chunk 调度优化讨论
Benchmark 自建：在自己的业务数据上建立 chunk 策略的自动化评估 pipeline

一句话总结

Chunk Size 是大模型系统中”分而治之”策略的核心旋钮——在 RAG 中它决定检索粒度，在推理中它决定调度效率，在训练中它决定资源利用——没有万能值，只有与文档类型、模型能力、硬件约束联合优化后的”局部最优解”。

延伸阅读与来源

资源	类型	链接/出处
LangChain Text Splitters	框架文档	[LangChain 官方文档]
LlamaIndex Node Parsers	框架文档	[LlamaIndex 官方文档]
“Contextual Retrieval”	博文	[Anthropic 官方博客, 2024]
“Late Chunking”	博文/论文	[Jina AI, 2024]
SGLang Chunked Prefill	技术文档	[SGLang GitHub/docs]
vLLM PagedAttention & Chunked Prefill	技术文档	[vLLM GitHub/docs]
FlashAttention-2	论文	Dao et al., 2023
Megatron-LM	论文/代码	Shoeybi et al., NVIDIA
”Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks”	原始 RAG 论文	Lewis et al., 2020

⚠️ 数据说明：本文中的定量数据，若标注 [估算] 则为基于行业经验的合理推断；若标注 [厂商文档] 则建议读者查阅对应厂商最新文档获取精确数字。本文档撰写时网络检索未成功返回结果（HTTP 403），部分数据依据领域通识，建议交叉验证。