大模型推理优化：Proxima KV Cache压缩策略解析与vLLM实践

在实际的大模型推理服务中，GPU显存是决定并发能力和吞吐量的核心瓶颈。尤其是在使用vLLM这类高性能推理框架时，KV Cache（键值缓存）会随着请求的上下文长度和批处理大小线性增长，迅速耗尽宝贵的显存资源，导致服务无法处理更多并发请求。许多团队在遇到性能瓶颈时，第一反应往往是申请更昂贵的硬件，但这不仅成本高昂，而且周期长。

Proxima 提出了一种创新的KV Cache管理策略，其核心思想是：通过智能地压缩和重组KV Cache，在几乎不影响模型输出质量的前提下，显著降低显存占用，从而在不增加任何硬件成本的情况下，提升服务的请求处理能力。根据其展示的数据，在vLLM框架上实现了高达4倍的请求服务能力提升。这对于需要高并发、低成本部署大模型的服务提供商来说，具有直接的工程价值。

本文将深入解析Proxima的工作原理，并提供一个从概念理解到动手验证的完整指南。你将了解到KV Cache为何成为瓶颈，Proxima的STAR-KV等关键技术如何工作，以及如何在自己的vLLM服务环境中尝试类似的优化思路。本文适合正在使用或计划使用vLLM部署大语言模型（LLM）的工程师、架构师以及对大模型推理优化感兴趣的研究者。

1. 理解推理瓶颈：为什么KV Cache是显存杀手

要理解Proxima的价值，必须先弄清楚现代大语言模型推理过程中的核心资源消耗点。这不仅仅是算力（FLOPs）的问题，更是显存带宽和容量的问题。

1.1 自回归解码与KV Cache

大语言模型通常以自回归（Autoregressive）的方式生成文本。给定一个输入序列（Prompt），模型会逐个预测下一个token（词元）。在预测第t个token时，模型需要基于之前所有0到t-1个token的隐藏状态进行计算。

为了提高效率，避免为每个新生成的token重新计算所有历史token的Key和Value向量，推理框架引入了KV Cache机制。简单来说：

• Key（K）和Value（V）： 是Transformer注意力机制中用于计算注意力权重的两个矩阵。
• Cache（缓存）： 在生成第一个token后，将当前所有输入token对应的K和V向量保存在显存中。
• 复用： 在生成后续token时，只需要计算新token的K和V，并将其追加到缓存中，然后基于整个缓存计算注意力。这避免了大量的重复计算。

1.2 KV Cache的显存占用分析

KV Cache的显存占用是惊人的，我们可以用一个公式来估算：

显存占用（字节） ≈ 2 * batch_size * seq_len * num_layers * num_heads * head_dim * dtype_size

• 2: 代表K和V两个缓存。
• batch_size: 批处理大小（同时处理的请求数）。
• seq_len: 序列长度（输入+已生成的长度）。
• num_layers: 模型的层数（例如LLaMA-7B有32层）。
• num_heads: 注意力头数。
• head_dim: 每个注意力头的维度。
• dtype_size: 数据类型大小（如float16为2字节，bfloat16为2字节）。

以一个常见的场景为例：使用LLaMA-7B模型（num_layers=32,num_heads=32,head_dim=128），以float16精度运行，批处理大小为4，序列长度为2048。

单请求KV Cache ≈ 2 * 1 * 2048 * 32 * 32 * 128 * 2 ≈ 2.15 GB 批处理（4请求）KV Cache ≈ 2.15 GB * 4 ≈ 8.6 GB

这仅仅是KV Cache的占用！模型参数本身（7B FP16约14GB）和激活值还需要额外的显存。对于一块24GB显存的GPU（如RTX 4090），KV Cache很容易成为限制批处理大小（batch_size）和最大序列长度（max_seq_len）的主要因素。更小的批处理意味着更低的GPU利用率和吞吐量。

1.3 vLLM的PagedAttention与现存问题

vLLM框架通过其创新的PagedAttention技术，极大地优化了KV Cache的显存管理。它借鉴操作系统内存分页的思想，将不同请求的KV Cache划分为块（block），允许非连续存储，从而减少因碎片化导致的内存浪费。

然而，PagedAttention主要解决的是显存碎片问题，并没有减少KV Cache的总体积。只要请求的上下文长、并发高，KV Cache的绝对大小依然会线性增长，最终触及显存上限。Proxima正是在这个基础上，试图对KV Cache本身进行“瘦身”。

2. Proxima的核心思路：对KV Cache进行无损/微损压缩

Proxima的优化目标很明确：在保证生成质量基本不变的前提下，减少每个请求KV Cache的实际存储量。其技术路径并非单一方法，而是一套组合策略。根据公开资料，其核心可能涉及以下方向：

2.1 注意力稀疏化与近似计算

并非所有历史token对当前生成token都同等重要。研究表明，注意力权重通常集中在少数几个token上。Proxima可能采用了某种动态评估机制，在每一层、每一步生成时，只保留重要性最高的Top-K个token的KV向量，而将其他token的缓存丢弃或进行低精度合并。

• 技术实现猜想： 在每次注意力计算后，分析注意力分布，为每个Key向量维护一个“重要性分数”。当缓存块需要被换出或压缩时，优先丢弃低分向量。
• 潜在影响： 这是一种有损压缩，需要精细的阈值控制，以避免影响模型输出的连贯性和事实准确性。

2.2 KV Cache量化与共享

另一种思路是降低KV Cache的数值精度或发现其冗余。

• 量化（Quantization）： 将KV Cache从FP16/BF16转换为INT8甚至INT4。这可以直接将显存占用减半或更多。但需要解决量化带来的误差累积问题，可能需要对不同层的K和V采用不同的量化策略。
• 跨层/跨头共享： 分析不同层、不同注意力头之间的KV向量是否存在相似性。对于高度相似的向量，可以只存储一份，并在计算时复用。这需要对模型结构有深入理解。

2.3 STAR-KV：结构化与重组缓存

“STAR-KV”是Proxima提及的一个关键概念。它很可能代表一种结构化、分层的KV Cache组织方式。

传统的KV Cache是一个“平坦”的列表，存储着所有历史token的向量。STAR-KV可能将其重组为树状或图状结构：

• 聚类（Clustering）： 将语义或位置相近的token的KV向量聚类成一个“超级向量”（Super Token）。
• 层级化（Hierarchy）： 构建多级缓存，高频访问或近期生成的token保留在高精度、快速访问的层级；历史、低频的token被压缩或转移到低精度层级。
• 这种结构化的好处： 在进行注意力计算时，可以先与高层级的“超级向量”计算，快速筛选出相关区间，再深入细节，这既能减少计算量，也能降低需要驻留显存的精细向量数量。

2.4 与vLLM的协同：块级别的压缩策略

Proxima需要深度集成到vLLM的PagedAttention系统中。它的操作单元很可能就是vLLM管理的“内存块（block）”。

1. 监控： Proxima监控每个缓存块的使用频率和重要性。
2. 决策： 当显存压力增大时，选择重要性较低的块进行压缩（应用上述稀疏化、量化或重组方法）。
3. 解压： 当后续计算需要访问被压缩的块时，进行快速解压或近似计算。

这种按需压缩/解压的策略，旨在实现显存占用与计算开销之间的平衡。

3. 环境准备：搭建vLLM测试平台

在深入代码之前，我们需要一个可以复现和观察KV Cache行为的环境。这里我们以部署一个LLaMA-7B模型为例。

3.1 硬件与基础软件要求

• GPU： 至少8GB显存（用于测试），推荐24GB以上（如RTX 4090, A10）以进行并发测试。确保已安装正确版本的NVIDIA驱动。
• CUDA Toolkit： 版本需与PyTorch和vLLM要求匹配（如12.1）。
• Python： 3.8 或 3.9。

3.2 创建Python虚拟环境并安装依赖

避免系统环境冲突，使用conda或venv创建独立环境。

# 使用 conda conda create -n vllm-proxima python=3.9 -y conda activate vllm-proxima # 或使用 venv python -m venv venv source venv/bin/activate # Linux/Mac # venv\Scripts\activate # Windows

安装PyTorch（请根据你的CUDA版本访问 PyTorch官网 获取最新安装命令）。

# 例如，对于 CUDA 12.1 pip install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/cu121

安装vLLM及其基础依赖。

pip install vllm # vllm会安装transformers, huggingface-hub等依赖

3.3 验证安装与基础功能

编写一个简单的脚本，测试vLLm能否正常加载模型并进行推理。

# test_vllm_basic.py from vllm import LLM, SamplingParams # 定义模型。首次运行会自动从Hugging Face下载，请确保网络通畅。 # 可以使用较小的模型如 `meta-llama/Llama-2-7b-chat-hf`（需授权） # 此处以 `facebook/opt-125m` 为例，因为它小，下载快，仅用于验证。 model_id = "facebook/opt-125m" print(f"Loading model {model_id}...") llm = LLM(model=model_id, max_model_len=512) # 限制最大长度以节省显存 # 定义采样参数 sampling_params = SamplingParams(temperature=0.8, top_p=0.95, max_tokens=50) # 准备提示词 prompts = [ "The future of artificial intelligence is", "Explain the concept of machine learning in one sentence:", ] print("Generating responses...") outputs = llm.generate(prompts, sampling_params) # 打印结果 for output in outputs: prompt = output.prompt generated_text = output.outputs[0].text print(f"Prompt: {prompt!r}\nGenerated: {generated_text!r}\n")

运行脚本：

python test_vllm_basic.py

如果看到模型加载并成功生成文本，说明vLLM环境基本就绪。

4. 模拟与观测：在没有Proxima的情况下评估KV Cache瓶颈

由于Proxima的具体实现代码尚未完全开源，我们可以先构建一个测试场景，来直观感受KV Cache如何随着并发和序列长度增长，并学会使用工具来观测它。

4.1 编写一个负载测试脚本

这个脚本将模拟多个并发请求，并打印显存使用情况。

# benchmark_kv_cache.py import time from vllm import LLM, SamplingParams import torch def run_benchmark(model_name, batch_sizes, sequence_lengths): """ 运行基准测试，观察不同批处理和序列长度下的显存占用。 """ for seq_len in sequence_lengths: print(f"\n{'='*60}") print(f"测试序列长度 (max_model_len): {seq_len}") print('='*60) # 重新加载模型以重置缓存，确保测试独立 llm = LLM(model=model_name, max_model_len=seq_len, gpu_memory_utilization=0.9, # 允许使用90%的GPU显存 enforce_eager=True # 在某些情况下更稳定 ) for batch_size in batch_sizes: print(f"\n--- 批处理大小: {batch_size} ---") # 准备一批相同的提示词，内容不重要，长度固定。 # 使用空格生成指定长度的提示词（近似）。 dummy_prompt = "Hello " * (seq_len // 10) # 粗略控制长度 prompts = [dummy_prompt for _ in range(batch_size)] sampling_params = SamplingParams(temperature=0.7, top_p=0.9, max_tokens=50) # 固定生成50个token # 清除CUDA缓存，获得更准确的基准 torch.cuda.empty_cache() torch.cuda.reset_peak_memory_stats() start_mem = torch.cuda.memory_allocated() / 1024**3 # GB start_time = time.time() outputs = llm.generate(prompts, sampling_params) elapsed = time.time() - start_time end_mem = torch.cuda.memory_allocated() / 1024**3 peak_mem = torch.cuda.max_memory_allocated() / 1024**3 # 计算吞吐量：总生成token数 / 时间 total_tokens = sum(len(out.outputs[0].token_ids) for out in outputs) throughput = total_tokens / elapsed if elapsed > 0 else 0 print(f" 生成耗时: {elapsed:.2f}s") print(f" 生成总Token数: {total_tokens}") print(f" 吞吐量: {throughput:.1f} tokens/s") print(f" 显存占用（峰值）: {peak_mem:.2f} GB") print(f" 显存占用（当前）: {end_mem:.2f} GB") # 删除模型以释放显存，进行下一轮测试 del llm torch.cuda.empty_cache() if __name__ == "__main__": # 使用一个小模型进行快速测试 MODEL = "facebook/opt-125m" BATCH_SIZES = [1, 2, 4, 8] SEQ_LENS = [256, 512, 1024] run_benchmark(MODEL, BATCH_SIZES, SEQ_LENS)

4.2 使用NVIDIA-SMI和vLLM内置工具观测

运行测试脚本的同时，在另一个终端窗口使用nvidia-smi命令动态观察显存变化。

# 每隔1秒刷新一次 watch -n 1 nvidia-smi

你将会看到，随着batch_size或seq_len增加，GPU Memory Usage会显著上升。这就是KV Cache在“作祟”。

vLLM也提供了更细致的统计信息，可以通过初始化参数开启：

llm = LLM(model=model_name, max_model_len=1024, disable_log_stats=False) # 开启日志统计

在生成请求后，vLLM会在日志中输出缓存块的使用情况等信息。

4.3 分析测试结果

运行完基准测试后，你会得到一组数据。可以手动记录或简单绘图来分析趋势。预期结论是：

• 在固定seq_len下，batch_size翻倍，显存占用近似线性增加。
• 在固定batch_size下，seq_len翻倍，显存占用也近似线性增加。
• 吞吐量可能不会随batch_size线性增长，因为受到GPU计算能力和显存带宽的限制，最终会达到瓶颈。

这个瓶颈点，就是Proxima这类优化技术试图突破的地方。

5. 探索性实现：模拟Proxima的KV Cache压缩思路

虽然无法完全复现Proxima，但我们可以实现一个简化版的“KV Cache重要性评估与裁剪”模拟器，来理解其核心思想。注意：以下代码仅为教学演示，会严重影响模型输出质量，不可用于生产环境。

5.1 拦截并分析注意力权重

我们需要修改vLLM的注意力计算过程。由于直接修改vLLM源码较复杂，我们通过一个“猴子补丁”（monkey-patch）的方式来模拟。这里假设我们使用Hugging Face Transformers库的原始模型进行原理演示。

# simulate_proxima.py import torch import torch.nn as nn from transformers import AutoModelForCausalLM, AutoTokenizer import numpy as np class SimulatedProximaWrapper: """ 一个模拟Proxima思想的包装器，用于演示KV Cache裁剪。 它会记录注意力权重，并基于权重和低重要性头部的KV Cache。 """ def __init__(self, model, keep_ratio=0.5): self.model = model self.keep_ratio = keep_ratio # 保留比例，例如0.5表示保留50%最重要的KV self.attention_weights = [] # 用于记录各层注意力权重 self._install_hooks() def _install_hooks(self): """安装前向钩子以捕获注意力权重""" for layer_idx, layer in enumerate(self.model.model.layers): # 假设是LLaMA结构，注意力模块在 layer.self_attn attn_module = layer.self_attn def hook_fn(module, input, output, idx=layer_idx): # output 通常是 (attn_output, attn_weights, ...) if isinstance(output, tuple) and len(output) >= 2: attn_weights = output[1] # 注意力权重 [batch, heads, q_len, k_len] # 存储下来，用于后续分析 self.attention_weights.append((idx, attn_weights.detach().cpu())) return output attn_module.register_forward_hook(hook_fn) def compress_kv_cache(self, layer_idx, key_cache, value_cache, attn_weights): """ 模拟压缩：根据注意力权重，保留最重要的部分KV Cache。 key_cache: [batch, heads, seq_len, head_dim] value_cache: [batch, heads, seq_len, head_dim] attn_weights: [batch, heads, q_len, seq_len] 这里我们取最后一个查询位置（q_len-1）的权重 """ batch, heads, seq_len, head_dim = key_cache.shape # 取最后一个生成步骤的注意力权重（对历史所有key的注意力） # attn_weights shape: [batch, heads, q_len, seq_len] last_step_weights = attn_weights[:, :, -1, :] # [batch, heads, seq_len] compressed_keys = [] compressed_values = [] for b in range(batch): for h in range(heads): weights = last_step_weights[b, h] # [seq_len] # 1. 根据注意力权重排序，决定重要性 _, indices = torch.sort(weights, descending=True) keep_num = int(seq_len * self.keep_ratio) important_indices = indices[:keep_num] # 2. 裁剪KV Cache comp_key = key_cache[b, h, important_indices, :] # [keep_num, head_dim] comp_value = value_cache[b, h, important_indices, :] # 3. 为了简单，我们直接存储裁剪后的。实际Proxima可能进行重组或编码。 compressed_keys.append(comp_key) compressed_values.append(comp_value) # 这是一个极度简化的演示，实际需要处理形状重组和后续计算。 # 此处我们仅打印信息，不实际修改模型缓存。 print(f"[模拟压缩] 层 {layer_idx}: 序列长度 {seq_len} -> 保留 {keep_num} 个最重要的token。") # 注意：这里没有实际修改模型的缓存，因为直接操作内部缓存非常复杂且危险。 return None, None def generate_with_simulation(self, input_ids, max_new_tokens=20): """一个模拟的生成过程，用于演示思路""" self.attention_weights.clear() device = self.model.device generated = input_ids with torch.no_grad(): for step in range(max_new_tokens): # 前向传播，钩子会捕获注意力权重 outputs = self.model(generated) next_token_logits = outputs.logits[:, -1, :] next_token = torch.argmax(next_token_logits, dim=-1, keepdim=True) generated = torch.cat([generated, next_token], dim=-1) # 模拟：在每一步后，根据最新捕获的权重“压缩”上一层的缓存（伪代码） if step > 0 and len(self.attention_weights) > 0: # 这里只是演示逻辑，不真正操作模型内部状态 for layer_idx, attn_weight in self.attention_weights[-len(self.model.model.layers):]: # 在实际Proxima中，这里会调用 compress_kv_cache # 并更新模型内部对应的 past_key_values pass return generated # 演示代码 if __name__ == "__main__": print("加载一个小模型进行模拟演示...") tokenizer = AutoTokenizer.from_pretrained("facebook/opt-125m") model = AutoModelForCausalLM.from_pretrained("facebook/opt-125m") # 如果使用LLaMA等模型，需要正确的tokenizer和加载方式 # 设置padding token（如果tokenizer没有） if tokenizer.pad_token is None: tokenizer.pad_token = tokenizer.eos_token model.eval() simulator = SimulatedProximaWrapper(model, keep_ratio=0.7) prompt = "Artificial intelligence is" inputs = tokenizer(prompt, return_tensors="pt") input_ids = inputs["input_ids"] print(f"输入: {prompt}") print("开始模拟生成（带压缩逻辑打印）...") output_ids = simulator.generate_with_simulation(input_ids, max_new_tokens=10) output_text = tokenizer.decode(output_ids[0], skip_special_tokens=True) print(f"输出: {output_text}") print("\n注意：上述‘压缩’仅为打印信息，未实际修改模型。真实实现需深度集成到推理框架的缓存管理中。")

5.2 关键逻辑解释

1. 重要性评估： 我们使用当前生成步骤（最后一个查询位置）的注意力权重作为评估标准。权重越高，认为该历史token对当前生成越重要。
2. 裁剪策略： 我们根据keep_ratio（如0.7）保留权重最高的那部分token的KV向量，丢弃权重低的。
3. 集成挑战： 上述模拟代码没有真正修改模型的KV Cache，因为vLLM或Transformers的内部缓存管理非常复杂。真实的Proxima需要作为vLLM的一个内核（kernel）或内存管理插件来实现，直接操作CacheEngine和BlockManager。

这个模拟演示了动态稀疏化的思想。Proxima的STAR-KV可能采用了更复杂、更稳定的重要性评估和聚类重组方法。

6. 集成与验证：思考真实场景下的实现路径

要将Proxima的思想应用于真实vLLM服务，你需要沿着以下路径进行工程化探索。

6.1 理解vLLM架构与扩展点

vLLM的核心组件包括：

• LLMEngine： 协调请求调度和批处理。
• Worker： 执行模型前向计算。
• CacheEngine和BlockAllocator： 管理GPU显存中的KV Cache块。
• Attention算子： 执行带有PagedAttention的注意力计算。

集成点可能在：

1. CacheEngine层： 实现一个自定义的BlockAllocator，在分配、释放、换出块时执行压缩/解压逻辑。
2. Attention内核层： 修改注意力计算内核，使其能处理经过压缩或重组的KV Cache数据结构。
3. 作为独立中间件： 在vLLM之上包装一层，在请求级别干预KV Cache的存储和读取，但这可能带来额外延迟。

6.2 设计压缩策略配置

一个生产级的系统需要可配置的策略，例如：

# proxima_config.yaml compression: enabled: true strategy: "hybrid" # hybrid, sparse, quantize, star # 稀疏化策略 sparsification: keep_ratio: 0.6 importance_metric: "attention" # attention, frequency, gradient # 量化策略 quantization: enabled: true k_bits: 8 v_bits: 8 per_channel: true # STAR-KV 策略 star_kv: cluster_size: 16 hierarchy_levels: 2 # 触发条件 trigger: memory_pressure_threshold: 0.8 # GPU内存使用率超过80%时触发压缩 min_seq_len_to_compress: 128

6.3 验证压缩效果与质量损失

任何压缩都会带来潜在的质量损失，必须严格评估。

1. 建立评估基准：

   • 任务数据集： 使用MMLU、HellaSwag、TruthfulQA等标准评测集。
   • 质量指标： 准确率（Accuracy）、困惑度（Perplexity）。
   • 性能指标： 吞吐量（tokens/s）、延迟（ms/token）、最大支持并发数。

2. A/B测试：

   • 对照组A： 原始vLLM。
   • 实验组B： 集成了Proxima策略的vLLM。
   • 在相同的硬件、模型、请求负载下，对比两组的质量和性能指标。

3. 质量损失监控：

   • 对于生成任务，可以采用语义相似度（如BERTScore）来比较压缩前后生成文本的差异。
   • 设定一个可接受的质量损失阈值（例如，准确率下降不超过1%）。

7. 常见问题与排查指南

在实现或应用此类优化技术时，你会遇到一系列典型问题。

7.1 性能与质量权衡问题

7.2 集成与调试问题

7.3 生产环境考量

1. 预热与冷启动： 压缩策略可能在服务刚启动、请求模式不稳定时做出次优决策。考虑设置一个“学习期”或使用固定的启动策略。
2. 监控与告警： 必须监控压缩率、质量指标（如通过抽样请求计算困惑度）和性能指标。设置告警，当质量损失超过阈值时自动回退到无压缩模式。
3. 动态适配： 不同的模型、不同的请求类型（如创意写作 vs. 代码生成）可能需要不同的压缩策略。可以探索简单的在线学习机制来动态调整参数。

8. 最佳实践与扩展方向

基于对Proxima思路的分析，以下是在实际项目中应用KV Cache优化的建议。

8.1 实施路径建议

1. 从分析和观测开始： 不要盲目优化。先用第4节的基准测试脚本，量化你当前服务的KV Cache显存占用与吞吐量瓶颈。明确优化目标（是提升并发数？还是支持更长上下文？）。
2. 从模拟到原型： 先像第5节一样，在离线环境中用PyTorch脚本模拟压缩算法对输出质量的影响。验证核心算法的有效性。
3. 从小模块集成： 不要试图一次性替换vLLM整个缓存系统。尝试先实现一个最简单的“按固定间隔丢弃后半部分缓存”的策略，并集成到vLLM中，确保流程能跑通。
4. 分层优化： 结合多种轻量级技术，效果可能优于单一的激进策略。例如：
   • 层间差异化： 对模型底层（靠近输入的层）的KV Cache采用高保留率或无损策略，对顶层采用更激进的压缩。
   • 请求差异化： 对高优先级、付费用户的请求使用低压缩率，对低优先级请求使用高压缩率。
   • 时间衰减： 为KV Cache中的向量引入“年龄”因子，越旧的token重要性评分衰减越多。

8.2 扩展方向

1. 与现有优化技术结合：

   • 量化（Quantization）： 将Proxima的稀疏化与KV Cache INT8量化结合。先裁剪，再对保留部分量化，实现双重压缩。
   • 连续批处理（Continuous Batching）： vLLM已支持。确保你的压缩策略能正确应对动态变化的批处理队列。
   • 张量并行（Tensor Parallelism）： 在多GPU场景下，KV Cache分布在不同的卡上。压缩策略需要考虑跨卡通信和负载均衡。

2. 更智能的重要性评估：

   • 当前的注意力权重是即时且局部的。可以探索基于强化学习的评估器，以更长远的生成质量作为奖励信号，学习如何分配KV Cache预算。
   • 利用模型本身的特性，例如，某些特定类型的token（如标点、常见虚词）的KV向量是否天然可以更激进地压缩？

3. 硬件协同设计：

   • 如果拥有定制硬件或FPGA，可以设计专用的硬件单元，用于高效执行KV Cache的稀疏查找、聚类和近似计算，将软件算法的优势固化为硬件性能。

Proxima所展示的“4倍提升”是一个强有力的概念验证，它指明了LLM推理优化中一片尚未充分开发的蓝海：显存内容的有效性管理。随着模型规模和上下文窗口的不断增长，这类技术的重要性只会与日俱增。作为工程师，理解其原理并能在自己的技术栈中进行探索和实验，是将研究转化为实际生产力的关键一步。