一、前言随着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 出于安全考虑保证可控性和调用插件类似在云端做网页浏览将最后搜寻到的信息返回。三、马斯克的GrokGrok-1Open Release of Grok-1[1]是一款由 xAI 开发的大型语言模型拥有 3140 亿个参数属于混合专家模型MoEMixture-of-Experts model包含8个专家总参数量为314B3140亿处理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 parameters8 个专家的混合体Mixture of 8 Experts每个 token 使用 2 个专家2 experts used per token64 层64 layers查询的 48 个注意力头48 attention heads for queries键/值的 8 个注意力头8 attention heads for keys/values嵌入大小6144embeddings size: 6,144旋转嵌入rotary embeddings, RoPESentencePiece 分词器131,072 个令牌SentencePiece tokenizer; 131,072 tokens支持激活分片和 8 位量化Supports activation sharding and 8-bit quantization最大序列长度上下文8192 个 tokenMax seq length (context): 8,192 tokensGrok-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 插件让你可以在苹果芯片上运行 JaxAccelerated 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五、MetaLlama 2Meta联手微软开源了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官网六、谷歌GeminiGemma它采用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带 GUICLI 一行uv pip install freetoken [accel] 即可载入开源社区采用Apache 2.0官方实测8GB 显存笔记本 35B MoE 模型 → 39.3 tokens/s约每秒 20 汉字实时对话级。单卡 RTX 5090 → 跑满血 DeepSeek-V4-Flash290B 总参达到交互级速度实现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%。全层双缓冲 PrefillDouble-Buffered PrefillPrompt 预处理阶段计算量小、搬运量大。通过双缓冲让数据搬运与GPU 计算完全重叠长 Prompt4k–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-GPUOffload 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。GPUNVIDIA RTX 30/40/50 系列消费级显卡笔记本/台式机/工作站。系统内存MoE offload 依赖大容量 DRAM跑 35B 级建议 ≥16GB跑 DeepSeek-V4-Flash 建议 ≥64GB视模型而定。FreeToken 的突破点在于用带宽视角重构 MoE 边缘推理语义感知缓存把高频专家留在 GPU带宽自适应执行让低频专家在 CPU/DRAM 就地并行计算并精确合并配合双缓冲 prefill 和弹性显存管理使消费级单卡获得数据中心级模型的本地推理能力。相比 llama.cpp 的固定卸载和 vLLM 的全显存前提它在小显存 大模型场景下有数量级优势且无损、不近似。# 1. 安装需 Python uvuv pipinstallfreetoken[accel]# 或源码安装gitclone https://github.com/FlashML-org/FreeToken.gitcdFreeToken uv venvsource.venv/bin/activate# Windows: .venv\Scripts\activateuv pipinstall-e.[accel]#启动服务启动 API 服务器模型可传本地路径或 HuggingFace IDft 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\# 指定 GPUnvidia-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\-HContent-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--modelHF--out目录把 HF safetensors 转成 FTW 快速加载格式 ft bench bw 校准 PCIe/CPU 带宽--moe-backend auto 会自动读取九、国内的开源项目关联资源讯飞AI应用、Open-Sora社区1中科院文献chatGPT目前「中科院学术专业版 ChatGPT」 已经发布至 3.6* 版本该版本充分满足本科生、硕士、博士和科研工作者的写作需求提升学术效率。其中内置的工具包括但不限于以下这些学术论文一键润色、语法错误查找中英文快速互译一键代码解释快捷键自定义高阶实验模块化设计项目源代码自我剖析智能读取论文并生成摘要。cd/d h:gitclone--depth1https://github.com/binary-husky/gpt_academic.gitcdgpt_academic H:\china_gpt\gpt_academicdir /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 Collectinggradio3.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 Collectingfastapi0.110(from-rrequirements.txt(line2))Obtaining dependency informationforfastapi0.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-client0.8(from-rrequirements.txt(line3))Obtaining dependency informationforgradio-client0.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)Collectingpypdf22.12.1(from-rrequirements.txt(line4))Obtaining dependency informationforpypdf22.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_PROXYFalse#如果用openai这里需修改为trueifUSE_PROXY: proxies{# [协议]:// [地址] :[端口]http:socks5h://localhost:11284,# 魔法软件/代理工具使用的协议或使用https://xinghuo.xfyun.cn/sparkapi、https://maas.aminer.cn/overviewhttps: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: responserequests.get(https://ipapi.co/json/,proxiesproxies,timeout4,verifyFalse)dataresponse.json()countrydata[country_name]# city data[city]resultf代理所在地{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 ModelCFM可配置的基础模型将MoE架构进行了革新。这里回顾下标准的 Transformer 模型它是“稠密”的这意味着对于输入序列中的每一个词元Token在前向传播的过程中它都必须经过模型所有的参数。这导致了一个致命的问题模型的参数量与每个词元的计算成本FLOPs是严格耦合的。MeEt实现了模型总参数量与单次计算量的Decouple解耦而CFM架构进一步将大模型的模块拆分为预训练阶段产生的涌现模块Emergent Brick与后训练阶段产生的定制模块Customized Brick然后通过模块的检索、组合、更新与增长可以高效地实现复杂功能配置与组合。这样训练大模型无需在预训练阶段就像MoE架构一样引入模块化结构约束而是可以在预训练阶段产生涌现模块之后所有Transformer-based 大模型的预训练和后训练等工作都可以通过模块化的视角进行解构像搭积木一样来构建大模型CFM 架构具有高效性、可复用性、可溯源性、可扩展性更适合分布式计算让大模型在端侧部署提供实现可能。涌现模块随机初始化的模型参数在预训练过程中模型神经元将会自发地产生功能分化的现象进而组成了大模型的功能分区。在推理阶段只有与当前输入内容相关的功能分区会被激活并作用于模型的输出结果。与人脑类似大模型神经元在预训练后产生了功能分化各自仅负责部分功能比如知识神经元用于存储世界三元组知识技能神经元用于辅助模型完成特定任务例如情感分类语言神经元用于识别特定的语法特征或处理特定语言。稀疏激活最早利用稀疏激活性质的模型架构为稀疏混合专家模型MoE它通过预定义的模块化结构强制每个词仅能使用部分专家进行计算另稠密训练的模型中神经元同样存在稀疏激活现象因一般再对词元处理时大量神经元激活值的绝对值很低。稀疏激活的性质使得我们可以训练高效的参数选择器在推理时动态选择参数进行计算以降低计算开销。定制模块预训练之后我们往往需要对模型进行后训练从而将模型与人类需求对齐并增强包括领域能力和任务能力在内的模型能力。最广为人知的是通过少参数微调形成的任务模块保持模型主体参数不变仅微调少量的任务相关参数。另许多研究发现小规模的外部插件不仅可以赋予大模型任务特定的能力还可以为它们补充更多额外的知识和功能例如用于世界知识注入的知识插件、用于多模态组合的模态插件、用于长文本处理的记忆插件以及用于推理加速的压缩插件等。后训练的本质是定制模块的训练这些模块可以充分补充和激发大模型的知识和能力。 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 出于安全考虑保证可控性和调用插件类似在云端做网页浏览将最后搜寻到的信息返回。三、马斯克的GrokGrok-1Open Release of Grok-1[1]是一款由 xAI 开发的大型语言模型拥有 3140 亿个参数属于混合专家模型MoEMixture-of-Experts model包含8个专家总参数量为314B3140亿处理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 parameters8 个专家的混合体Mixture of 8 Experts每个 token 使用 2 个专家2 experts used per token64 层64 layers查询的 48 个注意力头48 attention heads for queries键/值的 8 个注意力头8 attention heads for keys/values嵌入大小6144embeddings size: 6,144旋转嵌入rotary embeddings, RoPESentencePiece 分词器131,072 个令牌SentencePiece tokenizer; 131,072 tokens支持激活分片和 8 位量化Supports activation sharding and 8-bit quantization最大序列长度上下文8192 个 tokenMax seq length (context): 8,192 tokensGrok-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 插件让你可以在苹果芯片上运行 JaxAccelerated 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五、MetaLlama 2Meta联手微软开源了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官网六、谷歌GeminiGemma它采用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带 GUICLI 一行uv pip install freetoken [accel] 即可载入开源社区采用Apache 2.0官方实测8GB 显存笔记本 35B MoE 模型 → 39.3 tokens/s约每秒 20 汉字实时对话级。单卡 RTX 5090 → 跑满血 DeepSeek-V4-Flash290B 总参达到交互级速度实现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%。全层双缓冲 PrefillDouble-Buffered PrefillPrompt 预处理阶段计算量小、搬运量大。通过双缓冲让数据搬运与GPU 计算完全重叠长 Prompt4k–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-GPUOffload 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。GPUNVIDIA RTX 30/40/50 系列消费级显卡笔记本/台式机/工作站。系统内存MoE offload 依赖大容量 DRAM跑 35B 级建议 ≥16GB跑 DeepSeek-V4-Flash 建议 ≥64GB视模型而定。FreeToken 的突破点在于用带宽视角重构 MoE 边缘推理语义感知缓存把高频专家留在 GPU带宽自适应执行让低频专家在 CPU/DRAM 就地并行计算并精确合并配合双缓冲 prefill 和弹性显存管理使消费级单卡获得数据中心级模型的本地推理能力。相比 llama.cpp 的固定卸载和 vLLM 的全显存前提它在小显存 大模型场景下有数量级优势且无损、不近似。# 1. 安装需 Python uvuv pipinstallfreetoken[accel]# 或源码安装gitclone https://github.com/FlashML-org/FreeToken.gitcdFreeToken uv venvsource.venv/bin/activate# Windows: .venv\Scripts\activateuv pipinstall-e.[accel]#启动服务启动 API 服务器模型可传本地路径或 HuggingFace IDft 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\# 指定 GPUnvidia-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\-HContent-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--modelHF--out目录把 HF safetensors 转成 FTW 快速加载格式 ft bench bw 校准 PCIe/CPU 带宽--moe-backend auto 会自动读取九、国内的开源项目关联资源讯飞AI应用、Open-Sora社区1中科院文献chatGPT目前「中科院学术专业版 ChatGPT」 已经发布至 3.6* 版本该版本充分满足本科生、硕士、博士和科研工作者的写作需求提升学术效率。其中内置的工具包括但不限于以下这些学术论文一键润色、语法错误查找中英文快速互译一键代码解释快捷键自定义高阶实验模块化设计项目源代码自我剖析智能读取论文并生成摘要。cd/d h:gitclone--depth1https://github.com/binary-husky/gpt_academic.gitcdgpt_academic H:\china_gpt\gpt_academicdir /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 Collectinggradio3.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 Collectingfastapi0.110(from-rrequirements.txt(line2))Obtaining dependency informationforfastapi0.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-client0.8(from-rrequirements.txt(line3))Obtaining dependency informationforgradio-client0.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)Collectingpypdf22.12.1(from-rrequirements.txt(line4))Obtaining dependency informationforpypdf22.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_PROXYFalse#如果用openai这里需修改为trueifUSE_PROXY: proxies{# [协议]:// [地址] :[端口]http:socks5h://localhost:11284,# 魔法软件/代理工具使用的协议或使用https://xinghuo.xfyun.cn/sparkapi、https://maas.aminer.cn/overviewhttps: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: responserequests.get(https://ipapi.co/json/,proxiesproxies,timeout4,verifyFalse)dataresponse.json()countrydata[country_name]# city data[city]resultf代理所在地{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 ModelCFM可配置的基础模型将MoE架构进行了革新。这里回顾下标准的 Transformer 模型它是“稠密”的这意味着对于输入序列中的每一个词元Token在前向传播的过程中它都必须经过模型所有的参数。这导致了一个致命的问题模型的参数量与每个词元的计算成本FLOPs是严格耦合的。MeEt实现了模型总参数量与单次计算量的Decouple解耦而CFM架构进一步将大模型的模块拆分为预训练阶段产生的涌现模块Emergent Brick与后训练阶段产生的定制模块Customized Brick然后通过模块的检索、组合、更新与增长可以高效地实现复杂功能配置与组合。这样训练大模型无需在预训练阶段就像MoE架构一样引入模块化结构约束而是可以在预训练阶段产生涌现模块之后所有Transformer-based 大模型的预训练和后训练等工作都可以通过模块化的视角进行解构像搭积木一样来构建大模型CFM 架构具有高效性、可复用性、可溯源性、可扩展性更适合分布式计算让大模型在端侧部署提供实现可能。涌现模块随机初始化的模型参数在预训练过程中模型神经元将会自发地产生功能分化的现象进而组成了大模型的功能分区。在推理阶段只有与当前输入内容相关的功能分区会被激活并作用于模型的输出结果。与人脑类似大模型神经元在预训练后产生了功能分化各自仅负责部分功能比如知识神经元用于存储世界三元组知识技能神经元用于辅助模型完成特定任务例如情感分类语言神经元用于识别特定的语法特征或处理特定语言。稀疏激活最早利用稀疏激活性质的模型架构为稀疏混合专家模型MoE它通过预定义的模块化结构强制每个词仅能使用部分专家进行计算另稠密训练的模型中神经元同样存在稀疏激活现象因一般再对词元处理时大量神经元激活值的绝对值很低。稀疏激活的性质使得我们可以训练高效的参数选择器在推理时动态选择参数进行计算以降低计算开销。定制模块预训练之后我们往往需要对模型进行后训练从而将模型与人类需求对齐并增强包括领域能力和任务能力在内的模型能力。最广为人知的是通过少参数微调形成的任务模块保持模型主体参数不变仅微调少量的任务相关参数。另许多研究发现小规模的外部插件不仅可以赋予大模型任务特定的能力还可以为它们补充更多额外的知识和功能例如用于世界知识注入的知识插件、用于多模态组合的模态插件、用于长文本处理的记忆插件以及用于推理加速的压缩插件等。后训练的本质是定制模块的训练这些模块可以充分补充和激发大模型的知识和能力。