AI开源概览及工具使用-开发者社区

一、前言

随着ChatGPT热度的攀升，越来越多的公司也相继推出了自己的AI大模型，如文心一言、通义千问等。各大应用也开始内置AI玩法，如抖音的AI特效；但如今，大模型开放权重解决的是谁能拿到模型，没解决「谁能跑得起模型」。26年8月1日，来自中国上海交大的2为华人科学家联合Berkeley、MIT 等机构的联合团队，发布一个开源端侧大模型部署技术，名为 FreeToken 的全新开源边缘端推理系统，它能让笔记本 RTX 4060 跑 Qwen 3.6-35B，桌面 RTX 5090 跑得起 DeepSeek-V4-Flash 284B，测试笔记本 RTX 4060 跑 Qwen3.6-35B 的 decode速度已达39.3 token/s ；

关联资源：代码 GitHub、相关论文、项目Demo、产品文档、Grok Ai、grokstream、添加链接描述、FreeToken

二、开源版「ChatGPT Plus」

来自香港大学、XLang实验室、Sea AI实验室和Salesforce的研究者联合打造了一款用于真实世界生产力工具的开源智能体框架——OpenAgents，并开源了全栈代码（完整前后端）；OpenAgents还提供线上的网页 demo (以及配套的开源代码)，非程序员背景的普通用户也可轻松与智能体进行交互；OpenAgents 支持真实世界环境和可控环境，支持超过 200 + 的日常工具调用，支持网页自动浏览。OpenAgents 的动机是作为一个开源平台，旨在成为一个真实而全面的人类可交互的智能体评估平台：根据真实需求，真实用户与智能体互动以完成其任务，并记录整个用户 - 智能体互动过程和用户反馈以供进一步评估。为使用和部署智能体提供，目前包括三个关键智能体：

用于 Python 和 SQL 的数据智能体；
200 多个工具使用的插件智能体；
自动网络浏览的 Web 智能体。

OpenAgents 用基于「大语言模型」（LLMs）的技术和全栈工程代码尝试近似复刻了 ChatGPT Plus 的功能。智能体可执行 Python/SQL 代码，熟练调用工具，也能上网找地图发帖子，OpenAgents完全开源了代码，包含从科研到逻辑代码到前端代码的一切。代码完善、易于拓展，本地直接可以一键部署，配套提供了含有丰富的使用案例的文档，帮助研究者和开发者在模型上搭建自己的智能体和应用。一路从代码实现到后端前端全部开源，让其变成了人人都能用的落地级别应用，基于代码开源，开发者和研究者可以定制适配业务需要，修改若干行代码适配自己想要的模型，改进、创造自己想要的功能，甚至创造新的 Agent。下面是OpenAgents 总览图，面向用户的网页界面，面向开发者的本地部署。

1）数据分析对比

OpenAgents 和 ChatGPT 都能不错地完成用户对股价和交易的分析要求。不过 OpenAgents 可以自动搜索 Kaggle 数据集并下载，ChatGPT 需要用户从本地上传。

2）插件和画图

两者都能成功调用了 Wolfram 插件画出多种八面体的图片。

3）网页调用

模拟测试用户想要查询 10 月 20 日从中国香港到纽约的机票，OpenAgents 识别用户意图后直接跳转到 Skycanner，像 “真人” 一样一边思考一边在网站中填入信息，最后回到聊天页面总结信息；而 ChatGPT 出于安全考虑保证可控性，和调用插件类似，在云端做网页浏览，将最后搜寻到的信息返回。

三、马斯克的Grok

Grok-1（Open Release of Grok-1[1]）是一款由 xAI 开发的大型语言模型，拥有 3140 亿个参数，属于混合专家模型（MoE：Mixture-of-Experts model），包含8个专家，总参数量为314B（3140亿），处理Token时，其中的两个专家会被激活，激活参数量为86B。该模型的基础模型权重（一堆训练/投喂的数据，也称模型参数）和网络架构现已在 GitHub:xai-org/grok-1上公开发布，并未经过针对任何特定任务的微调，即它是是2023年10月预训练阶段的原始模型，避免引入任何自定义内核。开源协议遵循 Apache 2.0 许可证，商用友好。引起参数庞大，部署时注意需要一台拥有充足 GPU 内存的机器。Grok-1没有采用常见的Python、PyTorch或Tensorflow，而是选用了Rust编程语言以及深度学习框架新秀JAX，在底层技术上，Grok-1选择使用了基于JAX（一个由Google开发的用于高性能机器学习研究的库）和Rust（一种注重安全性和并发的系统编程语言）的自定义训练堆栈。xAI称：计划未来将Grok打造成多模态的大模型。

关联资源：grok-博客、问题讨论、JAX、JAX GitHub、精度说明

Grok-1 相关特性：

3140 亿参数（314B parameters）
8 个专家的混合体（Mixture of 8 Experts）
每个 token 使用 2 个专家（2 experts used per token）
64 层（64 layers）
查询的 48 个注意力头（48 attention heads for queries）
键/值的 8 个注意力头（8 attention heads for keys/values）
嵌入大小：6144（embeddings size: 6,144）
旋转嵌入（rotary embeddings, RoPE）
SentencePiece 分词器；131,072 个令牌（SentencePiece tokenizer; 131,072 tokens）
支持激活分片和 8 位量化（Supports activation sharding and 8-bit quantization）
最大序列长度（上下文）：8192 个 token（Max seq length (context): 8,192 tokens）

Grok-1存储库提供了使用 JAX 框架(是一个专为加速器优化的数组计算和程序转换设计的 Python 库，主要目标是高性能数值计算和大规模机器学习。)加载和运行 Grok-1 模型的示例代码。相对比Grok采用的框架和技术，大多数知名的大模型比如OpenAI的GPT系列或Google的大模型通常是基于TensorFlow或PyTorch这样的主流深度学习框架开发的，且有丰富的API和社区支持，能让模型开发和训练变得更高效。而Grok-1将JAX和Rust的结合，优势在于能够在模型性能、效率和可伸缩性方面有所优化。但这也意味着，xAI可能需要投入更多的资源来维护和支持这种非主流的技术栈。

要运行这些示例，用户需要先下载模型的检查点文件，将其放置在指定的目录中（将下载的 ckpt-0 目录放置在 checkpoint 目录中），然后执行以下命令来安装依赖并运行示例（基础模型大约有七百多个文件，近 300G，注意存储）：

gitclone https://github.com/xai-org/grok-1.gitcdgrok-1# installpipinstall-rrequirements.txt python run.py

根据网络相关经验显示， Grok 的最低配置要求（仅作为参考）：

#3[3]：8bit量化的话，可能需要8块H100；在 FP16 精度下，Grok-1 模型大约需要 630GB 至 700GB 的显存。即便配置了 8 个 NVIDIA H100 GPU，能否成功运行该模型仍不确定。在进行某些优化（如通过 GGUF[4] 工具）之前，这个模型可能无法在 CPU 上运行。

#24[5]：你需要拥有 TPU 或 NVIDIA/AMD 品牌的 GPU，且系统中必须装有 8 个此类设备。当前不支持 Apple silicon 设备（如 M1、M2、M3 等）。尽管 Jax 提供了一个 Metal 插件，让你可以在苹果芯片上运行 Jax（Accelerated JAX training on Mac[6]），但在使用 dm_haiku[7] 依赖时仍会遇到问题。即便克服了这些技术障碍，苹果芯片设备可能也没有足够的内存来运行如此庞大的 Grok-1 模型。

#25[8]：需要 8 个 GPU，每个 GPU 拥有 80GB 的显存，典型的选择是 A100 型号。即使是使用 4 个 NVIDIA 4090 显卡，也只能在 4 位量化的情况下勉强容纳模型的权重，而无法实际运行模型。此外，所需的硬件成本极高，单个 A100 的价格约为 12,000 美元，而一台配备 4 个 A100 GPU 的 NVIDIA DGX Station 的起价在 120,000 美元左右。因此，尽管技术上可行，但这样的配置对于大多数人来说是不切实际的。

下图是一组网络测试数据，从整体测试效果来看，这次开源的Grok-1可以说“比上不足，比下有余”——在各个测试集中呈现的效果要比GPT-3.5、70b的LLAMA2和Inflection-1要好，但距离Claude2和GPT-4仍然差了一大截。因Grok-1是xAI从零开始训练，在2023年10月就已经结束了预训练，且没有针对任何特定应用（如对话）进行微调，所以目前无法直接体验到对话的应用。

四、Sora

五、Meta：Llama 2

Meta联手微软开源了Llama 2，是一系列预训练和微调的大型语言模型（LLMs），一共有7B、13B、70B三个版本，Llama 2 的社区MIT许可证相当宽松，且可商用。相比于 Llama 1 ，Llama 2 的训练数据多了 40%，上下文长度也翻倍，并采用了分组查询注意力机制。具体来说，Llama 2预训练模型是在2 万亿的 token上训练的，精调 Chat 模型是在100 万人类标记数据上训练的。相关评测显示，70B模型与GPT-3.5-0301大致持平。

相关资源：-Llama-2-7b代码、Llama2-Chinese、llama-recipes、llama2官网

六、谷歌Gemini：Gemma

它采用Gemini同款技术架构，主打开源和轻量级，免费可用、模型权重开源、允许商用，同时笔记本可跑。
共有2B和7B两个版本，7B版本使用多头注意力机制，2B版本使用多查询注意力机制，Gemma 2B/7B分别使用了2T和6T token进行训练，主要来自网络文档、数学和代码，不过这些数据不是多模态的。据相关测试数据表明：性能全面超越开源标杆Llama 2；目前模型也同步上线Hugging Chat，可在线体验试玩。

关联资源：gemma、博客、博客2、Gemma代码

七、法国Mistral AI

八、FreeToken 开源边缘端推理系统

FreeToken系统专门针对MoE（混合专家）大模型在消费级硬件上的本地部署进行了全栈协同设计，打破了大规模前沿模型必须依赖数据中心集群的硬件门槛。它能把 GPU 显存、CPU、系统内存、PCIe 总线当作一个统一的弹性推理平台来调度，让消费级单卡（如 RTX 5090、8GB 游戏本）本地跑满血 MoE 大模型。FreeToken 现在已经提供了 Windows / Linux 桌面 App（带 GUI），CLI 一行uv pip install "freetoken [accel]" 即可载入，开源社区采用Apache 2.0；官方实测：8GB 显存笔记本 + 35B MoE 模型 → 39.3 tokens/s（约每秒 20 汉字，实时对话级）。单卡 RTX 5090 → 跑满血 DeepSeek-V4-Flash（290B+ 总参）达到交互级速度，实现"Token 自由"。

它强调如下特性：

“显存容量"不再是本地跑 MoE 的唯一约束传统观点认为"模型太大 = 显存放不下 = 不能本地跑”。FreeToken 主张：MoE 模型每 token 只激活一小部分专家（如 671B 模型仅激活 ~37B），瓶颈不是显存容量，而是**"取专家"的搬运带宽**。把搬运链路管好，消费级硬件也能跑。
边缘/桌面是 MoE 推理的合理主场：强调Edge-Native：隐私（数据不出本机）、无 API 费用、离线可用，适合个人电脑、工作站，而非只面向数据中心集群。
带宽自适应的执行，而不是固定策略的卸载，传统 offload 方案（llama.cpp 等）是"放不下就整体卸载到内存"，受 PCIe 带宽瓶颈拖累，速度只有每秒几 token。FreeToken 主张：按实测带宽动态决定每个专家在哪算、怎么搬，让搬运与计算重叠，达到交互级速度。
不做近似，不改模型，不损失精度，关键卖点：专家拆分到 CPU/GPU并行计算后按路由权重精确合并，结果与全 GPU 推理一致（非量化近似、非投机采样）。

FreeToken 的三件套全部围绕"专家搬运链路"：

带宽自适应执行（Bandwidth-Adaptive Execution）——核心创新实时测量PCIe 带宽与 CPU 内存带宽（提供 ft bench bw 基准工具，结果写入 profile 供引擎自动使用）。对于缓存未命中的专家，按实测带宽把专家参数切成两份：一份搬进 GPU 计算；一份留在 CPU/DRAM 侧就地用 CPU 核计算；两边并行执行，按路由权重精确合并结果——不是近似推理，数学等价。效果：避免所有数据都挤在 PCIe 这条窄路上，消除拷贝停顿。
语义感知的专家缓存（Semantic-Aware Expert Caching）
利用 MoE 的访问规律：相邻 token倾向于访问相似专家（语义局部性）。
做全局 LRU 专家缓存：高频专家常驻 GPU，低频专家放 DRAM，命中即免搬运。
论文实测：RTX 5090 上 GPU 专家缓存仅能容纳完整专家池约 11%，配合该策略仍能维持高命中率。
对比数据：专家未命中率从 llama.cpp 的 62% 降到 16%（命中率 38% → 84%）。
全层双缓冲 Prefill（Double-Buffered Prefill）
Prompt 预处理阶段计算量小、搬运量大。通过双缓冲让"数据搬运"与"GPU 计算"完全重叠，长 Prompt（4k–16k）不再被逐层拉取卡死。
4. 弹性显存热扩缩容：运行中动态在专家缓存与 KV 缓存之间重分配显存（ft ctl cache --moe N --kv N），无需重启、无需重载权重——不同会话可在线调整内存分配。
面向 Agent 的状态复用：针对编码 Agent 等场景复用已计算状态，避免重复 prefill（专为 Codex/Claude Code 这类工具调用负载优化）。

FreeToken 在处理长 Prompt（如 4-16k 上下文）时，相比传统 Offloading 方案因逐层从系统内存拉取 Expert 导致严重 I/O 阻塞，FreeToken 将首 Token延迟（TTFT）降低了 42-58%。

对如 Claude Code、OpenClaw 等循环交互、逐步追加上下文的场景，在多次工具调用与思维链（CoT）迭代中，由于 FreeToken 引入的 Token 边界轻量级检查点与状态复用，后续多轮交互的 TTFT 减少了 65-80%。

CPU-GPU协同方面，根据他们在不同 PCIe 规格（PCIe 3.0 x8、PCIe 4.0 x16、PCIe 5.0 x16）及不同 CPU（如 Intel i7、AMD Ryzen 9、Threadripper）下进行了测试，当系统后台有其他高 I/O 任务抢占总线时，算法可以自动提升 CPU 端分流计算比例；当总线空闲时则提升 GPU 载入比例。

压测下，FreeToken 可以在 0 停机开销下无缝收缩 GPU 驻留的 LRU Cache 大小，将更多未命中 Expert 转交 CPU 计算，保证推理服务平滑降级而不中断。

对比维度	llama.cpp / 传统 CPU-GPU	Offload vLLM / 标准 GPU 推理	FreeToken
模型放置	放不下就整体卸载到内存	必须整体进显存	高频专家 GPU + 低频专家 DRAM，按需调度
搬运策略	固定策略，逐层拉取	无（假设全显存）	带宽自适应，按实测带宽拆分专家并行执行
专家未命中率	~62%	—（显存足够）	~16%
精度	可能用 GGUF 量化损失精度	高	无损（精确合并，可配合量化）
长 Prompt 性能	受 PCIe 瓶颈，逐层搬运卡顿	好	双缓冲 prefill 重叠搬运与计算
最低硬件	慢到不可用（几 token/s）	显存必须 ≥ 模型	8GB 显存游戏本跑 35B MoE @ 39.3 tok/s；单卡 5090 跑满血 DeepSeek-V4-Flash
运行时调整	需重启	需重启	热调整专家/KV 缓存分配

持的模型与硬件：

模型：DeepSeek-V4-Flash、Qwen3.6-35B-A3B、GLM-5.2 等前沿开放权重 MoE 模型。
量化：MXFP4、NVFP4、FP8、BF16。
GPU：NVIDIA RTX 30/40/50 系列消费级显卡（笔记本/台式机/工作站）。
系统内存：MoE offload 依赖大容量 DRAM（跑 35B 级建议 ≥16GB，跑 DeepSeek-V4-Flash 建议 ≥64GB，视模型而定）。

FreeToken 的突破点在于用"带宽"视角重构 MoE 边缘推理：语义感知缓存把高频专家留在 GPU，带宽自适应执行让低频专家在 CPU/DRAM 就地并行计算并精确合并，配合双缓冲 prefill 和弹性显存管理，使消费级单卡获得数据中心级模型的本地推理能力。相比 llama.cpp 的固定卸载和 vLLM 的"全显存"前提，它在小显存 + 大模型场景下有数量级优势，且无损、不近似。

# 1. 安装（需 Python + uv）uv pipinstall"freetoken[accel]"# 或源码安装gitclone https://github.com/FlashML-org/FreeToken.gitcdFreeToken uv venvsource.venv/bin/activate# Windows: .venv\Scripts\activateuv pipinstall-e".[accel]"#启动服务，启动 API 服务器（模型可传本地路径或 HuggingFace ID）ft serve--model~/models/Qwen3.6-35B-A3B ft serve--modelQwen3.6-35B-A3B# 或直接传 HF 仓库名， 就绪标志：API server is ready to serve on 127.0.0.1:1919，任何支持 OpenAI / Anthropic 协议的客户端，把 base URL 指向 http://127.0.0.1:1919 即可接入#优化后ft serve--model~/models/Qwen3.6-35B-A3B\--port8080\# 端口--gpu1\# 指定 GPU（nvidia-smi 索引或 UUID）--max-running-requests8\# 最大并发--moe-backend hybrid\# fused / offload / cpu / hybrid（搬运策略）--moe-cache-size 200k\# 专家 GPU 缓存大小--moe-cpu-layers3,7,11\# 指定某些 MoE 层在 CPU 解码--memory-ratio0.9\# 可用显存比例--cache-type radix# 前缀复用（KV 缓存）#验证和调用# 查看模型列表curlhttp://127.0.0.1:1919/v1/models#首次使用建议流程：ft bench bw 校准本机带宽（hybrid 模式自动生效）； ft checkpoint 预转模型格式（加速加载）； ft serve 启动 → ft shell 聊天验证 → ft launch claude 接入编码 Agent。# 聊天补全（OpenAI 兼容）curlhttp://127.0.0.1:1919/v1/chat/completions\-H'Content-Type: application/json'\-d'{"model":"Qwen3.6-35B-A3B","messages":[{"role":"user","content":"What is a Mixture-of-Experts model?"}],"max_tokens":256,"stream":true}'#常用命令ft serve--model<模型>启动 API 服务（默认端口1919） ft shell[--model...]终端聊天（可附加到已有服务） ft launch claude/codex/dsh/opencode 一键配置并启动编码 Agent（自动清理云 API key，防止回退到付费端点） ft ctl health / stats / generate / cache 查询与在线管理服务器（ft ctl cache--moe200k 热调整缓存） ft checkpoint--model<HF>--out<目录>把 HF safetensors 转成 FTW 快速加载格式 ft bench bw 校准 PCIe/CPU 带宽（--moe-backend auto 会自动读取）

九、国内的开源项目

关联资源：讯飞AI应用、Open-Sora社区

1）中科院文献chatGPT

目前，「中科院学术专业版 ChatGPT」已经发布至 3.6* 版本，该版本充分满足本科生、硕士、博士和科研工作者的写作需求，提升学术效率。其中内置的工具，包括但不限于以下这些：

学术论文一键润色、语法错误查找；
中英文快速互译；
一键代码解释；
快捷键自定义；
高阶实验模块化设计；
项目源代码自我剖析；
智能读取论文并生成摘要。

cd/d h:gitclone--depth=1https://github.com/binary-husky/gpt_academic.gitcdgpt_academic H:\china_gpt\gpt_academic>dir /D 驱动器 H 中的卷是 科技与共享中心 卷的序列号是 043B-D05A H:\china_gpt\gpt_academic 的目录[.].gitignore core_functional.py Dockerfile multi_language.py[shared_utils]version[..]check_proxy.py crazy_functional.py[docs]README.md[tests].gitattributes colorful.py[crazy_functions]LICENSE[request_llms][themes][.github]config.py docker-compose.yml main.py requirements.txt toolbox.py16个文件242,496字节9个目录479,930,814,464 可用字节#安装依赖python3-mpipinstall-rrequirements.txt Collectinggradio==3.32.10(from-rrequirements.txt(line1))Downloading https://public.agent-matrix.com/publish/gradio-3.32.10-py3-none-any.whl(11.5MB)----------------------------------------11.5/11.5 MB10.7MB/s eta0:00:00 Collectingfastapi==0.110(from-rrequirements.txt(line2))Obtaining dependency informationforfastapi==0.110from https://files.pythonhosted.org/packages/f0/f7/ea860cb8aa18e326f411e32ab537424690a53db20de6bad73d70da611fae/fastapi-0.110.0-py3-none-any.whl.metadata Downloading fastapi-0.110.0-py3-none-any.whl.metadata(25kB)Collecting gradio-client==0.8(from-rrequirements.txt(line3))Obtaining dependency informationforgradio-client==0.8from https://files.pythonhosted.org/packages/c4/e7/5da3a4b6108f5e2e43d034d7923c3562f93beba8f3d13a0ec7c201a6f33c/gradio_client-0.8.0-py3-none-any.whl.metadata Downloading gradio_client-0.8.0-py3-none-any.whl.metadata(7.1kB)Collectingpypdf2==2.12.1(from-rrequirements.txt(line4))Obtaining dependency informationforpypdf2==2.12.1 from https://files.pythonhosted.org/packages/2e/40/4f997b7cf72d89bb5aafd57b01dfa0be4e9560c8e5b993fde3986b3904f9/pypdf2-2.12.1-py3-none-any.whl.metadata Downloading pypdf2-2.12.1-py3-none-any.whl.metadata(6.6kB)……#配置#打开项目目录下的config.py文件API_KEY="此处填API密钥"# 可同时填写多个API-KEY，用英文逗号分割USE_PROXY=False#如果用openai，这里需修改为trueifUSE_PROXY: proxies={# [协议]:// [地址] :[端口]"http":"socks5h://localhost:11284",# 魔法软件/代理工具使用的协议，或使用：https://xinghuo.xfyun.cn/sparkapi、https://maas.aminer.cn/overview"https":"socks5h://localhost:11284",# 魔法软件/代理工具使用的端口}API_URL_REDIRECT={"https://api.openai.com/v1/chat/completions":"https://api.onechat.fun/v1/chat/completions"}#验证python check_proxy.py#def check_proxy(proxies):importrequests try: response=requests.get("https://ipapi.co/json/",proxies=proxies,timeout=4,verify=False)data=response.json()country=data['country_name']# city = data['city']result=f"代理所在地：{country}"print(result)returnresult except: result="代理所在地查询超时，代理可能无效"print(result)returnresultif__name__=='__main__':from configimportproxies check_proxy(proxies)#运行程序，core_functional.py有功能提示词python main.py

说明：部署过程中问题参看1；

十、其他说明

10.1、MoE专家稀疏模型

MoE（混合专家模型Mixture of Experts）之所以是“稀疏激活”架构，核心在于它‌把“总参数量”和“单次计算量”解耦了‌，将 Transformer 模型中计算开销最大的**前馈网络（FFN）**层，替换为一组并行的“专家”网络和一个“门控网络”（路由器）。MoE架构中：模型可以拥有海量参数，但处理每个输入时，只通过一个门控网络（路由）动态挑选出少数几个“专家”子网络来干活，其余专家全部闲置。‌‌MoE的专家它们的专业化是在训练过程中自发涌现的、面向数据统计模式的专家。

这种设计让模型在同等推理成本下拥有更大容量。比如资料里提到的视觉编码器，总参数 35 亿但只激活 11 亿，延迟仅为同级别全激活模型的 76%，性能还相当甚至更好。另一个例子是 Kimi K3 的 Stable LatentMoE 框架，896 个专家每次只激活 16 个，激活比例约 1.8%。‌‌

总参数决定了模型的“知识储备”和容量上限，而单次计算量只跟“被激活的参数”挂钩，跟总参数无关。
路由机制是稀疏的关键‌：门控网络会为每个输入输出一个覆盖所有专家的概率分布，然后按Top-k策略只挑概率最高的 k 个专家参与计算（常见的是 top-1 或 top-2），其他专家完全不参与。这个“按需挑选”的动作，就是“稀疏激活”中“稀疏”二字的由来。‌‌

⚠️ 需要留意的代价：稀疏激活不是没有成本：

‌工程开销‌：如果实现得很朴素（比如逐专家循环计算），GPU 利用率会非常低，实际跑起来可能比密集模型还慢。内核优化（如专家并行、负载均衡）是让 MoE 理论优势落地的必要条件，不是锦上添花。
‌内存和通信‌：虽然计算量小了，但所有专家参数仍需加载到显存，推理时内存需求高；分布式训练时专家间的通信开销也更大。
‌调参更难‌：路由设计和专家负载平衡引入了密集模型没有的超参数，学习率这类关键超参的搜索空间会指数膨胀。‌‌

MoE架构的主要优势是利用稀疏激活的性质，将大模型拆解成若干功能模块，每次计算仅激活其中一小部分，而保持其余模块不被使用，从而大大降低了模型的计算与学习成本，能够在同等计算量的情况下产生性能优势。注意的是，这种利用稀疏激活性质的架构，都认为大模型需要在预训练阶段就额外引入模块化结构约束。对此，清华大学受启发于人脑高效的稀疏模块化架构，在论文《Configurable Foundation Models: Building LLMs from a Modular Perspective》中提出了一种类脑高效稀疏模块化架构：Configurable Foundation Model（CFM可配置的基础模型），将MoE架构进行了革新。

这里回顾下标准的 Transformer 模型，它是“稠密”的，这意味着，对于输入序列中的每一个词元（Token），在前向传播的过程中，它都必须经过模型所有的参数。这导致了一个致命的问题：模型的参数量与每个词元的计算成本（FLOPs）是严格耦合的。MeEt实现了模型总参数量与单次计算量的Decouple（解耦）；而CFM架构进一步将大模型的模块拆分为：预训练阶段产生的涌现模块（Emergent Brick）与后训练阶段产生的定制模块（Customized Brick），然后通过模块的检索、组合、更新与增长可以高效地实现复杂功能配置与组合。这样，训练大模型无需在预训练阶段就像MoE架构一样引入模块化结构约束，而是可以在预训练阶段产生涌现模块之后，所有Transformer-based 大模型的预训练和后训练等工作都可以通过模块化的视角进行解构，像搭积木一样来构建大模型！CFM 架构具有高效性、可复用性、可溯源性、可扩展性，更适合分布式计算，让大模型在端侧部署提供实现可能。

涌现模块：随机初始化的模型参数，在预训练过程中，模型神经元将会自发地产生功能分化的现象，进而组成了大模型的功能分区。在推理阶段，只有与当前输入内容相关的功能分区会被激活，并作用于模型的输出结果。与人脑类似，大模型神经元在预训练后产生了功能分化，各自仅负责部分功能：比如知识神经元，用于存储世界三元组知识；技能神经元，用于辅助模型完成特定任务，例如情感分类；语言神经元，用于识别特定的语法特征或处理特定语言。
稀疏激活：最早利用稀疏激活性质的模型架构为稀疏混合专家模型MoE；它通过预定义的模块化结构，强制每个词仅能使用部分专家进行计算，另稠密训练的模型中，神经元同样存在稀疏激活现象，因一般再对词元处理时，大量神经元激活值的绝对值很低。稀疏激活的性质使得我们可以训练高效的参数选择器，在推理时动态选择参数进行计算，以降低计算开销。

定制模块：预训练之后，我们往往需要对模型进行后训练，从而将模型与人类需求对齐，并增强包括领域能力和任务能力在内的模型能力。最广为人知的是通过少参数微调形成的任务模块，保持模型主体参数不变，仅微调少量的任务相关参数。另许多研究发现，小规模的外部插件，不仅可以赋予大模型任务特定的能力，还可以为它们补充更多额外的知识和功能，例如用于世界知识注入的知识插件、用于多模态组合的模态插件、用于长文本处理的记忆插件，以及用于推理加速的压缩插件等。后训练的本质是定制模块的训练，这些模块可以充分补充和激发大模型的知识和能力。