方向一：Dify 模式（Dify化）
一种是支持发布成 App 的功能，比如通过一定的系统提示词、工具集选择、模型参数设置（如温度等），可以将这样的东西打包发布成一个像 App 一样的网页，或者是一个 js 入口。用户可以通过这个网页直接使用 Chats 的预定功能和 AI 大模型聊天、完成指定任务。打包成的 js 甚至可以嵌入用户（通常是企业用户）的网页中，这样一来用户就可以直接在自己的网站上使用定制化的 AI 助手了。这个方向很有商业潜力，很多客户都在问。

方向二：Code Interpreter 模式（ADA）
另外一个方向就是实现内置的基于 Docker 的沙箱功能。因为我经常看到 ChatGPT 网站（或者像 Manus 一样）中可以执行一段 Python 脚本——或者经过一系列多步骤的过程，然后生成一张图片或者一个图表、Excel、PPT。这个功能之前 ChatGPT 叫作 Code Interpreter（代码执行器），后来为了显得更专业，改名叫“高级数据分析”（Advanced Data Analysis，ADA）。

这个功能的核心在于： 它可以让 AI 模型直接操作文件、生成各种格式的输出，而不需要用户手动去处理数据和文件。

我发现，目前市面上除了 OpenAI 提供了完整体验外，像 Gemini、Grok、Qwen（基于OpenWebUI）等都没有提供类似的功能支持。

我的选择
从 Chats 的商业化角度来说，Dify 方向肯定更有“钱”景。但我个人对 ADA 方向更感兴趣一些，因为我觉得这个功能更“硬核”，也更能体现 AI 模型的能力和潜力。

所以我最终选择了 ADA 方向作为 1.10 版本发布的核心功能。经过几周的努力，1.10 版本终于完成了内置 Docker Code Interpreter 的功能！现在用户可以在 Chats 中直接请 AI 创建一个 Docker 会话，上传文件，让 AI 模型执行代码、分析数据、生成 PPT 等，非常方便实用。

强大的 Docker 沙箱：不只是 Python

为了实现这个功能，我不仅仅是加了几个 API 那么简单。

这个功能的 PoC 其实早在去年 11 月我就完成了，之后我陆续打磨，直到 2026 年元旦的时候我和 AI 做了多轮的设计，最终定稿并创建了 7 个内置工具：

• create_docker_session：创建环境
• run_command：执行命令
• read_file /  write_file /  patch_file：文件操作
• download_chat_files：文件流转
• destroy_session ：资源回收

我还内置了一套  Artifact（工件）文件夹跟踪机制。简单来说，如果大模型操作命令行工具或者其它什么脚本将文件放到了指定的 artifact 文件夹，Chats 系统就会自动帮用户保存下来，用户在聊天界面可以直接点击下载。

专属镜像：sdcb/code-interpreter

为了让体验达到，我不想让大家每次都去拉取巨大的通用镜像，也不想让大家费劲去配置环境。因此，我专门构建了一个 docke 镜像： sdcb/code-interpreter。

和 OpenAI 的 ADA 功能类似，这个镜像里预装了常用的工具链和依赖库：

• 语言环境：Python, .NET (Dotnet), Node.js, GCC
• 数据处理：SQLite3, Pandas, Numpy
• 文档办公：LibreOffice, Pandoc
• 多媒体：FFmpeg, ImageMagick
• Web自动化：Playwright Chromium

大模型在使用这个镜像时，会自动加载  /app/skills.md 这个文件，里面列出了镜像中预装的工具和库：

This environment is pre-configured with the following tools and libraries:* utilities: git, LibreOffice, Pandoc, Poppler (`pdftotext`, `pdfinfo`), sqlite3, file, FFmpeg {ffmpegVersion}, git, imagemagick, playwright[chromium]* dotnet {dotnetVersion}, commands: `dotnet build`, `dotnet run single-file.cs`, `dotnet add package`, pre-cached NuGet packages in `/opt/nuget-local`* python {pythonVersion}, commands: `python3 - <<'PY' ...ftzhibo.cn`,livesoccerontv.cn `pip install --break-system-packages package-name`, IMPORTANT: Many packages are pre-installed, Always check with `pip list` BEFORE ftzhibo.com installing to avoid unnecessary waits.* C/C++ Toolchain (gcc {gccVersion}), tools: `gcc`, `g++`, `make`, `cmake`* node.js {nodeVersion}, commands: `node`, `npm`, IMPORTANT: Many packages are pre-installed globally. Always check with `npm -g ls` BEFORE installing.

大模型可以直接调用这些工具，非常方便。

值得一提的是，作为一名 .NET 爱好者，这个镜像我是基于 .NET 做的（Base Image），因此碰巧你像我一样使用 .NET/C# 来验证一些东西的话，让大模型直接使用这个镜像就行了！

不过值得注意的是 _flash_3_hub 只支持非hopper架构，因此可以直接就使用 set_attention_backend("flash")。2、 直接使用 torch.compile进行加速，不过值得注意的是 在开始使用过程中会比较慢，因为在执行时，它会将模型编译为优化的内核，所以相对会比较慢，但是如果对编译后模型进行批量测试在时间上就会有所提升比如说在代码 df_acceralate.ipynb中测试结果使用compile在z-image上生成5张图片耗时：86.49s（ 平均生图时间4s）不使用compile：29.92（ 平均生图时间5s）；3、使用 torch.channels_last去优化数据结构（ torch文档）：最主要的一点是通过channel_last让 GPU 在计算卷积 / attention 时，内存访问更连续，比如说一般数据的输入是NCHW那么在内存访问中格式是： N0C0H0W0, N0C0H0W1, ..., N0C0H1W0, ...这个里面通道C变化最慢，使用channel_list数据格式变为NHWC在内存中访问顺序是： N0H0W0C0, N0H0W0C1, N0H0W0C2, ...值得注意的是两部分数据在shape上是一致的只是strid不一致。使用方式也比较简单：

# 修改模型model = model.to(memory_format=torch.channels_last)# 修改输入input = input.to(memory_format=torch.channels_last)output = model(input)...pipeline.unet.to(memory_format=torch.channels_last)

1、xFormers加速

在SD模型中对于xformers基本使用方式如下所示：

import torchfrom diffusers import StableDiffusionXLPipelinepipeline = StableDiffusionXLPipeline.from_pretrained("stabilityai/stable-diffusion-xl-base-1.0",torch_dtype=torch.float16,).to("cuda")# 使用xformer加速pipeline.enable_xformers_memory_efficient_attention()# 关闭xformer加速pipeline.disable_xformers_memory_efficient_attention()

xformers作用在于 加速attention计算并降低显存，除此之外还提供了多种注意力实现方式，如casual attention等。根据 官方文档中的描述，对于对于 xformers.ops.memory_efficient_attention在使用上参数主要是：1、输入数据也就是QKV的格式上必须满足为： [B, M, H, K]分别表示的是其中B 为batch size, N为序列长度, num_heads为多头注意力头的个数, dim_head则为每个头对应的embeding size；2、attn_bias实际上充当为在使用mask attention时的mask；3、p也就是dropout对应值；4、op为Tuple，用于指定优化self-attention计算所采用的算子。基本使用方式如下：

import xformers.ops as xopsy = xops.memory_efficient_attention(q, k, v)y = xops.memory_efficient_attention(q, k, v, p=0.2) # 使用dropouty = xops.memory_efficient_attention(q, k, v,attn_bias=xops.LowerTriangularMask())# 使用casual 注意力

值得着重了解的就是其中 attn_bias参数，简单直观的理解：用于控制注意力可见性和结构的统一接口， 既可以表示 mask，也可以表示稀疏/局部/因果等高级注意力模式，并且以高性能方式融入 attention 内核。比如说：
1、 xops.LowerTriangularMask()：常规的causal注意力也就是下三角mask
2、 xops.LocalAttentionFromBottomRightMask：局部注意力，每个token只能看最近的window_size个token

2、设备分配
这部分主要是将生成模型中不同模型结构如VAE、CLIP去分配到其它显卡上：

import torchfrom diffusers import AutoModel, StableDiffusionXLPipelinepipeline = StableDiffusionXLPipeline.from_pretrained("stabilityai/stable-diffusion-xl-base-1.0",torch_dtype=torch.float16,device_map="balanced" # 使用balance就可以实现不同设备分配)print(pipeline.hf_device_map){'unet': 1, 'vae': 1, 'safety_checker': 0, 'text_encoder': 0}

亦或者直接自己定分配：

import torchfrom diffusers import AutoModeldevice_map = {'pos_embed': 0, 'time_text_embed': 0, 'context_embedder': 0, 'x_embedder': 0, 'transformer_blocks': 0, 'single_transformer_blocks.0': 0, 'single_transformer_blocks.1': 0, 'single_transformer_blocks.2': 0, 'single_transformer_blocks.3': 0, 'single_transformer_blocks.4': 0, 'single_transformer_blocks.5': 0, 'single_transformer_blocks.6': 0, 'single_transformer_blocks.7': 0, 'single_transformer_blocks.8': 0, 'single_transformer_blocks.9': 0, 'single_transformer_blocks.10': 1, 'single_transformer_blocks.11': 1, 'single_transformer_blocks.12': 1, 'single_transformer_blocks.13': 1, 'single_transformer_blocks.14': 1, 'single_transformer_blocks.15': 1, 'single_transformer_blocks.16': 1, 'single_transformer_blocks.17': 1, 'single_transformer_blocks.18': 1, 'single_transformer_blocks.19': 1, 'single_transformer_blocks.20': 1, 'single_transformer_blocks.21': 'cpu', 'single_transformer_blocks.22': 'cpu', 'single_transformer_blocks.23': 'cpu', 'single_transformer_blocks.24': 'cpu', 'single_transformer_blocks.25': 'cpu', 'single_transformer_blocks.26': 'cpu', 'single_transformer_blocks.27': 'cpu', 'single_transformer_blocks.28': 'cpu', 'single_transformer_blocks.29': 'cpu', 'single_transformer_blocks.30': 'cpu', 'single_transformer_blocks.31': 'cpu', 'single_transformer_blocks.32': 'cpu', 'single_transformer_blocks.33': 'cpu', 'single_transformer_blocks.34': 'cpu', 'single_transformer_blocks.35': 'cpu', 'single_transformer_blocks.36': 'cpu', 'single_transformer_blocks.37': 'cpu', 'norm_out': 'cpu', 'proj_out': 'cpu'}transformer = AutoModel.from_pretrained("black-forest-labs/FLUX.1-dev",subfolder="transformer",device_map=device_map,torch_dtype=torch.bfloat16)

cache策略概述

cache指的是： 缓存通过存储和重用不同层（例如注意力层和前馈层）的中间输出来加速推理，而不是在每个推理步骤执行整个计算。它以更多内存为代价显着提高了生成速度，并且不需要额外的训练。主要详细介绍两种：1、DeepCache；2、FORA。对于更加多的cache策略可以看 知乎， 推荐直接使用 CacheDit来进行加速。

场景演示：它能做什么？

光说不练假把式，我们来看看它在实际场景中的威力。

场景一：分析 Excel 并生成图表

以前我们让 AI 分析 Excel，通常是将数据格式发给AI，然后让它帮忙写代码，用户再自己运行代码生成图表。现在可以直接让 AI 在沙箱中操作 Excel 文件，生成图表。

其它重磅更新

除了代码执行器，1.10 还有很多硬核更新：

1. 交错思考改进

在 1.9 版本中，我引入了交错思考（Interleaved Thinking）的概念，允许大模型在回答问题时分多步思考和行动。但只支持 Minimax-M2、Anthropic Claude等模型支持交错思考。

在 1.10 版本中，我扩展了对更多模型的支持，包括 OpenAI Responses API、DeepSeek V3.2模型。

比如你看下面的使用量统计（来自 Chats 的截图）：

• ❓代表模型提供商使用了基于 Anthropic Messages API 的实现，按协议推断应该支持，但由于未做过端到端测试，因此不确定是否能实现完整的交错思考能力——我相当肯定不能简单地说“支持”，因为有些模型在实现上可能会有差异化。
• 还有一些模型提供商基于 OpenAI Responses API 实现的，比如文心千帆，理论上只要支持 Responses API 也能实现交错思考，但我还没有做过测试，因此暂时不列入表格。

2. 用户体验大升级

• 工具调用展示：为了配合 Code Interpreter，我重写了工具调用的 UI（ ToolCallBlock）。现在可以看到实时的控制台输出流（Log Stream），体验就像自己在看终端一样爽。

幕后花絮

那个让人头秃的 EF Core Bug

开发后期有一个很烦人的 EF Core 问题，表现是会话追踪的数据有时候会莫名其妙地状态不对。当时我把日志丢给 AI 大模型，让它帮我分析了好久都没解决，给出的建议都在“隔靴搔痒”。

后来没办法，我只能拿出传统的“调试器”，一步一步地断点调试，才发现是 EF Core 在处理并发更新时的状态跟踪（Change Tracking）导致了数据污染。果然，关键时刻还是得靠人类工程师的直觉和经验啊！😅

为什么迟到了？

1.10 其实早在  2026-01-14 就发布了，为什么今天是 26 号我才发文章宣传？

一方面是我自己在进行高强度的“测试”（Dogfooding），确保在这个 Docker 沙箱里跑 rm -rf / 不会把我的宿主机炸了（开玩笑的，有安全限制）。

另一方面，我补了大量的文档。新功能的配置参数比较多，为了让大家能顺利部署，我花了几天时间重新梳理了  README 和  Release Note，大家部署前一定要去看看。

结语

Chats 1.10 是一个里程碑，它让 Chats 从一个单纯的“聊天窗口”进化成了一个“生产力工场”。我非常期待看到大家用这个功能玩出什么花样！

在上一篇 收藏！LLM-RL训练框架：3大流派+6大框架，一文搞定中，我们重点讨论了LLM训练技术的开源框架，并未涉及LLM训练的其他环节。在人工智能领域从模型中心化向数据中心化范式转移的背景下，LLM的成功不仅依赖于模型参数规模的爆炸式增长，更取决于全链路工程化的精细程度。

这一链路涵盖了从海量异构数据的精炼、超大规模分布式环境下的模型训练、特定任务驱动的指令微调，到最终模型输出与人类价值观对齐的RLHF阶段。如近的开源生态系统已涌现出一批高性能、模块化且落地性强的代码框架，这些工具极大地降低了开发者训练、微调和部署私有化大模型的门槛。本篇将对这一全链路中的核心开源框架进行深度的技术解构，分析其底层机制、性能指标及行业应用场景。

1 分布式数据清洗与编排引擎

数据质量是LLM性能的生命线。当前工业界的共识是，高质量的合成数据和经过严苛清洗的NLP语料对提升模型逻辑推理能力至关重要。当数据规模达到PB级时，单机处理变得不可行。异构脏数据的处理流程需要复杂的任务编排和大规模分布式计算的支持。

核心特点

• 一站式与系统化：涵盖了数据分析、清洗、过滤、转换、去重及合成的完整链路。它不仅是一个工具包，更是一个完整的系统，提供了100多个核心算子。

• 多模态支持：除了基础的文本数据，Data-Juicer 2.0及后续版本深度支持图像、视频、音频等多种模态，能够处理复杂的交织多模态数据。

• 高效扩展：基于Ray和CUDA优化，支持单机到数千核集群的弹性扩展，性能经工业级验证。

• 数据-模型共开发（Sandbox）：提供沙盒机制，允许开发者在小规模数据上快速迭代实验，通过反馈循环和可视化工具快速验证数据改进对模型效果的影响。

适用场景

• 预训练/微调加速：对海量网页数据去噪，或筛选高质量、高多样性的指令微调数据。

• 多模态生成训练：为类似Sora的视频生成或多模态大模型准备精细化标注与清洗后的语料。

• 自动化数据工程：利用AI算子自动生成、重写数据，或探索最优数据混合比例。

优缺点

优点：① 工业级成熟度：源自阿里巴巴通义实验室，经过大规模生产环境验证，算子丰富且性能优异；② 生态集成度高：与ModelScope（魔搭社区）、LLaMA-Factory、Ray等主流大模型生态深度打通，方便开发者集成到现有流水线；③ 灵活易用：对于新手，可以直接使用官方提供的最佳实践配置；对于高级用户，可以通过 Python 灵活自定义算子。

缺点：① 学习成本：算子库庞大，需一定时间摸索最佳参数组合；② 资源需求：部分高级算子（如模型打分）依赖计算资源，处理海量数据时成本较高。

适用场景

• LLM  预训练清洗：处理Common Crawl等原始网页快照，提取纯净文本并剔除低质量内容。。

• 超大规模去重：在海量数据中精准剔除重复或高度相似的文档。

• 分布式数据工程：利用Slurm或Ray等集群环境快速处理万亿规模的数据集。

优缺点

优点：① 极的扩展性：不是为了处理小样本设计的，而是为了处理万亿级Token设计的，在Slurm或Ray分布式环境下表现极佳；②简洁的API：Pythonic风格，模块化程度高，易于自定义扩展；③ 与生态深度集成：与Hugging Face Hub和fsspec深度整合，支持直接读写S3、Hugging Face数据仓库。

缺点：①主要侧重文本：理论上虽然可以处理其他数据，但目前其生态和预置算子主要集中在文本领域。在多模态（图像、视频）算子的丰富度上，目前弱于Data-Juicer；② 文档相对精简：相比一些商业化或历史悠久的框架，其详细文档和教程仍在完善中，更多依赖示例代码（Examples）。

2 分布式预训练与模型训练底层架构

当数据准备就绪后，如何将其高效地输入到分布式计算集群中进行训练成为核心挑战。因单个GPU的显存（如H100的80GB）远不足以容纳100+B参数的模型、及其优化器状态和梯度，分布式并行策略成为了现代训练框架的基石。

关键技术深度解析

DeepSpeed的核心架构由ZeRO优化器及其衍生的异构存储技术构成。

• ZeRO 优化器（ZeRO-1/2/3）：ZeRO技术的精髓在于消除模型状态的冗余存储。在传统数据并行中，每个GPU都保存完整的模型状态，而ZeRO则将这些状态进行分片（Sharding）。ZeRO-1仅对优化器状态进行分片；ZeRO-2进一步对梯度进行分片；ZeRO-3则实现了对参数、梯度和优化器状态的全量分片存储。这种策略使得显存消耗随设备数的增加而线性下降。

• ZeRO-Offload与ZeRO-Infinity：针对显存严重短缺的场景，DeepSpeed提出了异构内存利用方案。ZeRO-Offload利用CPU内存存储并处理优化器状态更新，而ZeRO-Infinity则将这一思路推向，通过高效的Infinity Offload引擎同时利用GPU显存、CPU内存和NVMe SSD，支持在单个GPU上训练高达130亿参数的模型，或在集群上支持万亿参数规模。

• DeepSpeed-Ulysses序列****并行：相比Megatron的序列并行，Ulysses采用了一种更通用的All-to-All通信机制。它在注意力计算前后重新分配数据，使得每个GPU能够完整地看到全局上下文，但仅负责计算部分注意力头，这在长序列训练中展现出了极佳的带宽效率。

• 混合3D 并行集成：DeepSpeed通过与Megatron-LM的深度融合，将ZeRO技术与张量并行、流水线并行相结合，形成了一套完整的万亿级模型训练方案。其提供的TiledLinear模块进一步通过内存平铺技术减少了算子的峰值内存需求。

适合场景

DeepSpeed是资源异构或受限环境下的不二之选。无论是需要在中小规模集群上微调百亿参数模型，还是在跨节点的非高速互联环境下进行预训练，其强大的显存管理能力都能确保持续运行。此外，由于其与 Hugging Face等开源生态结合紧密，它是研究人员和企业进行快速实验和模型私有化部署的首选框架。

优缺点

优点：① 显存效率极高：ZeRO-3与Infinity技术极大地打破了内存墙，支持单机训练超大规模模型；② 易用性与兼容性：通过简单的JSON配置文件即可启用复杂功能，无需大规模重构PyTorch代码；③ 生态开放：支持包括AMD、Intel 在内的多种硬件平台，广泛集成于第三方库。

缺点：① 通信开销风险：在开启深度Offload模式下，由于受限于PCIe带宽，计算效率可能大幅下降；② 复杂系统集成：在将ZeRO与3D并行结合使用时，参数配置与负载均衡的调优极其繁琐。