企业官网建设流程全解析

1. 这不是又一篇“PyTorch入门教程”，而是一份十年炼出来的框架认知地图

我第一次在实验室服务器上跑通torch.cuda.is_available()时，显示器右下角的时间是凌晨2:17，终端里跳出来的True两个字母，比当年收到第一封实习offer还让我手抖。那会儿用的是0.4版，Variable和Tensor还在打架，nn.Module的forward方法里连@torch.no_grad()都还没影儿。今天回看，PyTorch早已不是那个“研究用玩具”——它成了工业界模型迭代的流水线、学术界新想法落地的试验台、甚至高中生参加AI竞赛的默认起点。但问题来了：为什么是PyTorch？为什么不是别的？为什么它能在TensorFlow如日中天时硬生生撕开一条路？这背后没有玄学，只有三件事做对了：把Python的直觉感刻进DNA、让调试像写脚本一样自然、把社区协作变成基础设施。你不需要记住所有API，但得明白torch.nn.Sequential和torch.nn.Module之间那层薄薄的抽象到底挡住了什么；你不必背熟DataLoader所有参数，但得清楚num_workers=4在Linux和Windows上为何表现截然不同；你更该知道，当torch.compile()在2.0版本横空出世时，它编译的不只是计算图，更是整个深度学习开发范式的惯性。这篇文章不教你怎么写一个ResNet，而是带你站在Meta AI工程师、一线算法研究员、MLOps工程师三个视角，重新拆解PyTorch的骨架——从张量内存布局如何影响GPU显存碎片，到autograd引擎里那个被反复调用却从不露面的AccumulateGrad节点，再到torch.distributed里DDP和FSDP在大模型训练中如何用通信掩盖计算。如果你正卡在模型训不动、显存总爆、多卡同步慢、部署掉精度这些具体问题里，这篇就是为你写的。它不承诺“三天速成”，但保证你读完后，再看到报错信息里的RuntimeError: expected scalar type Float but found Double，第一反应不再是百度，而是立刻打开.cuda()调用链查类型传播路径。

2. 核心设计哲学与底层机制解构

2.1 “Pythonic”的真实含义：不是语法糖，而是执行模型的重构

很多人说PyTorch“Pythonic”，就以为是API长得像Python。错了。真正的Pythonic，在于它把执行模型（execution model）彻底交还给Python解释器。我们对比一个最基础的操作：

# TensorFlow 1.x 静态图时代（已淘汰，但对比价值巨大） import tensorflow as tf x = tf.placeholder(tf.float32, [None, 784]) W = tf.Variable(tf.random_normal([784, 10])) y = tf.matmul(x, W) # 此时y只是一个计算图节点，没任何数值！必须sess.run(y)才触发执行

# PyTorch 的“即时执行”（Eager Execution） import torch x = torch.randn(32, 784) # 立即分配内存，生成实际数值 W = torch.randn(784, 10, requires_grad=True) # 立即创建，且标记可求导 y = torch.mm(x, W) # 立即计算，返回真实tensor，可直接print(y[0])

关键差异在哪？在TensorFlow 1.x里，y是一个符号化的操作描述（Symbolic Operation），它的生命周期由Session管理；而在PyTorch里，y是一个活的对象（Live Object），它拥有自己的内存地址、数据指针、梯度缓冲区，并且其生命周期完全遵循Python的引用计数规则。这意味着什么？意味着你可以用if语句动态控制网络结构：

class DynamicNet(torch.nn.Module): def __init__(self): super().__init__() self.linear1 = torch.nn.Linear(100, 50) self.linear2 = torch.nn.Linear(50, 10) def forward(self, x): # 这里可以是任意Python逻辑！ if x.mean() > 0.5: x = torch.relu(self.linear1(x)) return self.linear2(x) else: # 跳过中间层，直连 return self.linear2(x) # 注意：这里x维度必须匹配！

这种能力在RNN变体、条件生成、神经架构搜索（NAS）中是刚需。而TensorFlow 2.x虽也支持Eager模式，但其底层仍保留着向静态图转换的路径（@tf.function），这种“双模并存”带来了额外的抽象泄漏——比如你在@tf.function里用print()，它可能只在图构建时执行一次，而非每次调用都打印。PyTorch则干净利落：没有图构建阶段，只有代码执行阶段。它的“动态计算图”本质，是autograd引擎在每次forward执行时，实时记录所有涉及requires_grad=True张量的操作，形成一个有向无环图（DAG）。这个图不是预先定义的，而是forward函数执行的副产品。所以当你print(model)看到的Sequential或ModuleList，只是组织代码的容器；真正驱动训练的，是那个在backward()时被遍历的、内存中的操作记录链。

提示：理解这一点，你就明白为什么PyTorch的调试如此直观——print(x.shape)、breakpoint()、pdb.set_trace()全部原生支持。因为x就是个普通Python对象，不是图节点ID。

2.2 张量（Tensor）：不只是多维数组，而是内存、计算、自动微分的三位一体

初学者常把torch.Tensor当成NumPyndarray的GPU版。这是危险的简化。一个PyTorch张量，至少承载三层契约：

1. 内存契约（Memory Contract）：它精确控制数据在CPU RAM或GPU VRAM中的位置、布局（contiguous vs non-contiguous）、数据类型（dtype）和内存池归属。
2. 计算契约（Computation Contract）：它声明自己参与的运算类型（如torch.float32张量不能直接与torch.int64张量相加，除非显式转换），并决定运算在哪个设备上发生。
3. 微分契约（Differentiation Contract）：通过requires_grad属性，它声明自己是否需要被追踪以计算梯度，从而决定autograd引擎是否为其创建梯度缓存（grad属性）和计算历史（grad_fn）。

这三个契约紧密耦合，破坏任一者都会导致灾难性错误。例如：

# 场景：你在做图像预处理，想把uint8转float32 img_uint8 = torch.randint(0, 256, (3, 224, 224), dtype=torch.uint8) # 错误做法：除法隐式转换（会丢失精度且创建新tensor） img_float_wrong = img_uint8 / 255.0 # dtype=float64! 因为255.0是double # 正确做法：显式转换，保持精度和控制权 img_float_correct = img_uint8.to(torch.float32) / 255.0 # 更佳做法：利用torchvision.transforms，它内部做了最优实现 from torchvision import transforms normalize = transforms.Normalize(mean=[0.485, 0.456, 0.406], std=[0.229, 0.224, 0.225])

再看内存布局的关键性。contiguous()不是可有可无的优化项，而是很多CUDA算子的硬性要求：

x = torch.randn(2, 3, 4, 5) y = x.transpose(1, 3) # 形状变为(2,5,4,3)，但内存不连续！ print(y.is_contiguous()) # False # 下面这行会报错：RuntimeError: Input is not contiguous # z = torch.nn.functional.conv2d(y, weight) z = y.contiguous() # 强制复制内存，使其连续

为什么？因为CUDA卷积核期望输入张量在内存中是按行主序（row-major）连续排列的。非连续张量（non-contiguous tensor）虽然逻辑形状正确，但其内存地址是跳跃的，无法被单个CUDA kernel高效访问。contiguous()会分配一块新内存，将数据按正确顺序拷贝过去。代价是显存占用翻倍（临时+新内存），所以生产环境要尽量避免频繁调用。解决方案是：在数据加载阶段就用pin_memory=True（锁页内存加速CPU->GPU传输），并在模型输入前用view()或reshape()替代transpose()+contiguous()组合，因为view()在满足内存连续前提下是零拷贝操作。

注意：view()和reshape()的区别在于，view()要求原始tensor必须连续，否则报错；reshape()更智能，它会在必要时自动调用contiguous()。但在性能敏感场景，明确控制连续性更可靠。

2.3 Autograd引擎：那个看不见的“梯度会计”

autograd是PyTorch的隐形心脏。它不暴露复杂API，却决定了你能否成功训练模型。其核心是一个反向传播调度器（Backward Scheduler），工作流程如下：

1. 前向记录（Forward Recording）：每当一个requires_grad=True的tensor参与运算（如+,*,mm,relu），autograd就在内存中创建一个Function对象（如AddBackward0,MulBackward0,MmBackward），并将输入tensor的grad_fn指向它。
2. 计算图构建（Graph Construction）：这些Function对象通过next_functions属性链接，形成一个从输出到输入的DAG。loss.backward()时，引擎从loss.grad_fn开始，按拓扑逆序遍历此图。
3. 梯度计算（Gradient Computation）：对每个Function，调用其backward()方法，根据前向输入和当前梯度，计算出传给上游的梯度。例如，MulBackward0的backward()会执行grad_output * other_input。
4. 梯度累加（Gradient Accumulation）：计算出的梯度不是直接赋值给input.grad，而是调用AccumulateGrad节点，将其累加到input.grad上。这就是为什么多次loss.backward()后，param.grad是梯度之和，而非覆盖——你需要手动optimizer.zero_grad()来清零。

这个机制带来两个关键实操后果：

• 梯度不会自动清零：这是新手最大坑点。如果你在一个循环里忘记zero_grad()，梯度会不断累加，导致权重更新爆炸。
• backward()只能调用一次：因为计算图在backward()后就被释放（节省内存）。若需二次反向（如GAN的判别器更新两次），必须设retain_graph=True，但这会显著增加内存占用。

# 典型训练循环（务必牢记！） for epoch in range(num_epochs): for data, target in dataloader: optimizer.zero_grad() # 关键！清零上一轮梯度 output = model(data) loss = criterion(output, target) loss.backward() # 计算梯度，图被释放 optimizer.step() # 更新权重

更深层的技巧：torch.no_grad()和torch.inference_mode()。前者是经典方案，禁用autograd记录，所有tensor的requires_grad=False；后者是2.0+新增，更激进——它不仅禁用记录，还禁用梯度缓存分配和某些运行时检查，速度更快，内存更省，专为纯推理设计。但注意：inference_mode下，requires_grad属性不可修改，且某些依赖梯度的API（如torch.autograd.grad）不可用。

3. 工程化核心组件与最佳实践

3.1 数据加载：DataLoader不是管道，而是性能瓶颈的放大器

DataLoader常被当作黑盒使用，但它其实是整个训练Pipeline中最易被低估的性能杠杆。它的设计目标是用CPU预处理和数据搬运，掩盖GPU计算时间。但若配置不当，它反而会成为拖慢训练的“减速带”。关键参数解析：

一个经过压测的高性能DataLoader配置示例：

from torch.utils.data import DataLoader from torch.utils.data.distributed import DistributedSampler # 假设你有自定义Dataset train_dataset = MyImageDataset(root_dir="data/train") # 多卡训练时，用DistributedSampler确保每卡数据不重叠 sampler = DistributedSampler(train_dataset) if args.distributed else None train_loader = DataLoader( train_dataset, batch_size=args.batch_size, shuffle=(sampler is None), # 分布式训练时，shuffle由sampler控制 num_workers=8, pin_memory=True, persistent_workers=True, prefetch_factor=3, sampler=sampler, drop_last=True, # 防止最后一批size不足，导致BN层报错 )

实操心得：我曾遇到一个项目，训练速度卡在1.2 it/s。排查发现num_workers=0，所有数据加载都在主线程，GPU 90%时间在等CPU。改成num_workers=8后，速度飙升至8.7 it/s。但紧接着又出现OOM（Out of Memory），原因是prefetch_factor=4导致8个worker各预取3个batch，瞬间吃光CPU内存。最终平衡点是num_workers=6, prefetch_factor=2。

3.2 模型构建：从nn.Module到torch.compile的演进路径

PyTorch的模型构建哲学是“组合优于继承”。nn.Module是基石，但它本身不做任何计算，只提供注册、状态管理和前向钩子（hook）框架。真正的计算发生在forward()方法里。因此，模块化设计的核心是清晰的职责分离：

• nn.Module: 定义参数（self.weight,self.bias）和子模块（self.conv1,self.bn1）。
• forward(): 定义数据流，应尽可能简洁，只包含张量运算。
• __init__()和forward()之间，不应有状态计算（如self.register_buffer('running_mean', ...)应在__init__中完成）。

一个易被忽视的陷阱是参数初始化。PyTorch不会自动为你初始化Linear或Conv2d的权重，它依赖reset_parameters()方法，该方法在nn.Module.__init__()中被调用。但如果你重写了__init__()却忘了调用super().__init__()，初始化就会失效！

class BadModule(nn.Module): def __init__(self, in_features, out_features): # 错误！漏掉了super().__init__() self.linear = nn.Linear(in_features, out_features) # self.linear.weight 和 bias 将是未初始化的垃圾值！ class GoodModule(nn.Module): def __init__(self, in_features, out_features): super().__init__() # 正确！触发Linear的reset_parameters() self.linear = nn.Linear(in_features, out_features)

进入2024年，torch.compile()已成为性能调优的新标配。它不是简单的JIT编译，而是对计算图进行多层次优化：前端（Frontend）将Python代码转为TorchDynamo IR；中端（Middle-end）应用算子融合（Op Fusion）、内存规划（Memory Planning）；后端（Backend）生成高效CUDA或CPU代码。效果惊人：ResNet50训练速度提升30%，显存占用降低15%。

# 启用compile（PyTorch 2.0+） model = MyModel() # 编译整个模型 compiled_model = torch.compile(model, mode="default") # 或 "reduce-overhead", "max-autotune" # 编译后，首次forward会有编译开销，后续极快 output = compiled_model(input_tensor)

但compile()不是银弹。它对动态控制流（如for i in range(n):中的n是tensor）支持有限，此时会fallback到eager模式。最佳实践是：先用mode="reduce-overhead"快速验证，再用mode="max-autotune"在稳定环境中做终极优化。后者会尝试多种内核实现并benchmark，耗时较长，但收益最大。

3.3 分布式训练：DDP与FSDP的选型逻辑

单卡训不动大模型？torch.distributed是你的答案。但DDP（DistributedDataParallel）和FSDP（Fully Sharded Data Parallel）绝非简单二选一，而是对应不同规模和硬件的精密工具。

• DDP适用场景：模型参数量<1B，GPU数量≤8，显存充足（如A100 80G）。它采用数据并行：每个GPU持有一份完整模型副本，计算各自batch的梯度，然后用all-reduce同步梯度。优点是简单、稳定、通信开销相对固定（梯度大小=模型参数量）。

• FSDP适用场景：模型参数量≥1B，GPU数量≥4，显存紧张（如V100 32G）。它采用模型分片+数据并行：将模型参数、梯度、优化器状态（如Adam的momentum,variance）分片到所有GPU上。每个GPU只存储一部分，前向/反向时按需all-gather。通信量大幅减少（与分片数成反比），但增加了all-gather和reduce-scatter的复杂性。

选型决策树：

1. 你的模型model.numel()是多少？<1e9 →DDP；≥1e9 →FSDP。
2. 你有多少块GPU？≤4且显存≥40G → 可试DDP；≥8或显存<32G →FSDP。
3. 你是否需要ZeRO-3级别的极致显存优化？→FSDPwithsharding_strategy=ShardingStrategy.FULL_SHARD。

一个FSDP最小可行配置：

from torch.distributed.fsdp import FullyShardedDataParallel as FSDP from torch.distributed.fsdp.wrap import size_based_auto_wrap_policy # 初始化分布式环境（略） # 定义分片策略：按参数量自动分片 auto_wrap_policy = size_based_auto_wrap_policy # 创建FSDP包装器 model = FSDP( model, auto_wrap_policy=auto_wrap_policy, sharding_strategy=ShardingStrategy.FULL_SHARD, device_id=torch.cuda.current_device(), sync_module_states=True, # 确保各GPU初始参数一致 )

注意：FSDP的sync_module_states=True至关重要。它确保在FSDP初始化时，所有GPU从rank 0同步参数，避免各卡初始权重不同导致训练发散。

4. 生态系统与工程集成实战

4.1torchvision：不只是预训练模型，而是CV Pipeline的标准化接口

torchvision常被当作“放ResNet的地方”，但它真正的价值在于统一了计算机视觉任务的数据、模型、评估的接口规范。其三大支柱：

• datasets: 提供CIFAR10,ImageNet,COCO等标准数据集的Dataset实现，关键是它们都遵循__getitem__返回(image, target)元组的约定，且image是PIL.Image或Tensor，target是int或dict。这让你可以无缝切换数据源。
• models: 不仅提供resnet50(pretrained=True)，更关键的是weights参数。pretrained=True已被弃用，新范式是：

  from torchvision.models import resnet50, ResNet50_Weights weights = ResNet50_Weights.IMAGENET1K_V1 # 明确指定权重版本 model = resnet50(weights=weights) # 自动加载权重并冻结BN层

  这种设计消除了“预训练权重是否包含在模型中”的歧义，且weights对象包含了预处理信息（transforms()方法），可直接用于DataLoader。
• transforms:Compose是函数式编程的典范。每个transform都是一个可调用对象，接受PIL.Image或Tensor，返回同类型对象。这使得pipeline可组合、可测试、可复现。

一个生产级图像预处理Pipeline：

from torchvision import transforms # 训练时增强（强随机性） train_transform = transforms.Compose([ transforms.Resize((256, 256)), transforms.RandomResizedCrop(224, scale=(0.8, 1.0)), # 随机裁剪缩放 transforms.RandomHorizontalFlip(p=0.5), transforms.ColorJitter(brightness=0.2, contrast=0.2, saturation=0.2, hue=0.1), transforms.ToTensor(), # PIL -> Tensor, [0,1] transforms.Normalize(mean=[0.485, 0.456, 0.406], std=[0.229, 0.224, 0.225]), # ImageNet均值方差 ]) # 验证时（确定性） val_transform = transforms.Compose([ transforms.Resize((256, 256)), transforms.CenterCrop(224), transforms.ToTensor(), transforms.Normalize(mean=[0.485, 0.456, 0.406], std=[0.229, 0.224, 0.225]), ])

4.2Hugging Face Transformers：PyTorch与NLP的终极粘合剂

transformers库的成功，本质上是PyTorch“Pythonic”哲学在NLP领域的胜利。它没有发明新框架，而是将PyTorch的灵活性与NLP任务的复杂性完美对齐。其核心设计是PreTrainedModel基类，它封装了：

• forward()：统一的输入签名（input_ids,attention_mask,labels等），无论BERT、GPT还是T5。
• from_pretrained()：从Hugging Face Hub下载权重和配置，一行代码加载SOTA模型。
• save_pretrained()：保存模型和tokenizer，保证可复现性。

最关键的创新是TrainerAPI。它不是一个黑盒训练器，而是一个高度可定制的训练循环模板。你可以轻松注入自定义逻辑：

from transformers import Trainer, TrainingArguments # 自定义回调：在每个epoch结束时保存最佳模型 class BestModelSaver(TrainerCallback): def on_epoch_end(self, args, state, control, **kwargs): if state.best_metric and state.best_metric > self.best_score: self.best_score = state.best_metric kwargs["model"].save_pretrained("best_model") training_args = TrainingArguments( output_dir="./results", per_device_train_batch_size=16, num_train_epochs=3, save_steps=500, logging_steps=100, evaluation_strategy="epoch", load_best_model_at_end=True, ) trainer = Trainer( model=model, args=training_args, train_dataset=train_dataset, eval_dataset=eval_dataset, callbacks=[BestModelSaver()], # 注入自定义逻辑 ) trainer.train()

这体现了PyTorch生态的精髓：底层框架（PyTorch）提供坚实基础，上层库（Transformers）提供领域最佳实践，而用户始终握有最终控制权。

4.3 模型部署：从torch.jit.trace到Triton Inference Server

训练完模型，下一步是服务化。PyTorch提供了多条路径，选择取决于延迟、吞吐、硬件和团队技能：

• torch.jit.trace/script: 最轻量级。trace适用于控制流固定的模型（如CNN），script支持Python控制流（如RNN）。生成.pt文件，可用C++ API加载，延迟最低（<1ms），但缺乏跨平台优化。
• ONNX: 开放标准，支持TensorRT、OpenVINO、Core ML等后端。torch.onnx.export()导出，再用对应工具优化。适合需要跨硬件（Jetson, iOS）或已有ONNX生态的团队。
• Triton Inference Server: NVIDIA官方推荐，支持多框架（PyTorch, TensorFlow, ONNX）、动态批处理、模型集成（ensemble）。它将模型视为微服务，通过HTTP/gRPC暴露API。优势是运维友好、弹性伸缩、GPU资源隔离。

一个Triton部署的典型流程：

1. 将PyTorch模型导出为torchscript或ONNX。
2. 按Triton要求组织模型仓库（config.pbtxt定义输入输出、动态批处理策略）。
3. 启动Triton Server：tritonserver --model-repository=/path/to/models。
4. 客户端用tritonclient发送请求。

import tritonclient.http as httpclient client = httpclient.InferenceServerClient(url="localhost:8000") inputs = httpclient.InferInput("INPUT__0", [1, 3, 224, 224], "FP32") inputs.set_data_from_numpy(image_np, binary_data=True) outputs = httpclient.InferRequestedOutput("OUTPUT__0") response = client.infer("resnet50", [inputs], outputs=[outputs]) preds = response.as_numpy("OUTPUT__0")

实操心得：在一次电商搜索排序项目中，我们用torch.jit.trace部署BERT特征提取，P99延迟12ms；换成Triton + TensorRT优化后，P99降至3.8ms，且支持自动批处理，QPS提升4倍。代价是部署复杂度上升，需要专职MLOps支持。

5. 对比分析与选型决策指南

5.1 PyTorch vs TensorFlow：不是框架之争，而是范式之辨

将PyTorch和TensorFlow简单对比为“谁更好”，如同问“锤子和螺丝刀哪个更优秀”。它们服务于不同范式，选择应基于团队基因、项目阶段和长期维护成本。

我的建议是：新项目、研究导向、算法团队主导 → PyTorch；遗留系统集成、强运维要求、已有TF基建 → TensorFlow。二者并非水火不容，tf.keras可加载PyTorch模型（通过ONNX），torch也可调用TF SavedModel（通过tensorflow-io），混合使用是常态。

5.2 版本演进路线图：哪些特性值得升级，哪些可以观望

PyTorch版本迭代极快，盲目升级可能引入breaking change。以下是近3年关键版本的务实评估：

• PyTorch 1.12 (2022)：torch.compile()初亮相（beta）。当时不稳定，编译失败率高，仅建议尝鲜。不推荐生产升级。
• PyTorch 2.0 (2023)：torch.compile()正式发布，torch.export()（用于安全导出模型）引入。强烈推荐升级，compile()带来的性能收益远超兼容性成本。
• PyTorch 2.1 (2023)：torch.compile()支持inductor后端（默认），FSDP稳定性大幅提升，torch.distributed.checkpoint（DCP）成为推荐的分布式检查点方案。推荐升级，尤其对大模型训练团队。
• PyTorch 2.2 (2024)：torch.compile()支持aot_inductor（Ahead-of-Time编译），torch._dynamo.config提供更多细粒度控制。可选升级，适合追求极致性能的团队。
• PyTorch 2.3+ (2024)：重点在torch.compile()的max-autotune优化、FSDP的state_dict加载速度提升。等待稳定版发布后再评估。

升级checklist：

1. 运行torch.__version__确认当前版本。
2. 查阅 PyTorch Release Notes ，重点关注Breaking Changes和Deprecations。
3. 在CI中添加torch.compile()测试用例，验证核心模型是否能成功编译。
4. 监控升级后GPU显存占用和训练速度变化，用torch.cuda.memory_summary()和time.time()量化。

我踩过的坑：一次将1.13升级到2.0后，torch.compile()在某个自定义LayerNorm上编译失败。排查发现是LayerNorm的eps参数被当作常量处理，而我们的实现中eps是torch.tensor。解决方案是将eps改为Python float，或用torch.compile()的dynamic_shapes=True参数。这提醒我们：升级不是一键操作，而是需要深入理解新特性的边界。

6. 常见问题与硬核排查技巧实录

6.1 显存爆炸（OOM）：不是显存不够，而是没管好“内存账”

OOM是PyTorch最常见也最令人抓狂的问题。根本原因往往不是模型太大，而是内存管理失控。排查必须系统化：

Step 1: 定位“谁在吃显存”

# 在训练循环中插入 print(torch.cuda.memory_summary()) # 详细显存报告 # 关键指标： # - Allocated: 当前被tensor占用的显存（你的模型、数据、中间变量） # - Reserved: CUDA内存池已向GPU申请但未分配给tensor的显存（碎片来源） # - Peak: 训练至今的最大Allocated值（优化目标）

Step 2: 常见罪魁祸首与解法

Step 3: 终极武器——torch.profiler

with torch.profiler.profile( activities=[torch.profiler.ProfilerActivity.CPU, torch.profiler.ProfilerActivity.CUDA], record_shapes=True, profile_memory=True, with_stack=True, # 记录调用栈，定位到具体代码行 ) as prof: for data, target in dataloader: output = model(data) loss = criterion(output, target) loss.backward() optimizer.step() break # 只prof一个batch，避免日志爆炸 print(prof.key_averages(group_by_stack_n=5).table(sort