1. 为什么“大模型 3D 渲染”值得单独做一个互动工具2026 年再回头看大模型相关的可视化项目已经多到泛滥但绝大多数停留在两种形态一种是静态的架构图画完贴到文档里过两个月模型迭代了图就废了另一种是纯文字的解释读者得靠脑补去理解“注意力机制到底怎么流动”“MoE 路由是怎么分发的”。这两类东西的共同问题是——它们都不让读者动手。我这次做的这个项目核心目标就一句话把大模型的内部结构用 3D 的方式渲染出来并且让用户能转、能点、能缩放、能看数据流动。它不是一张图而是一个可以交互的“模型解剖台”。关键词里的“3D渲染”“互动工具”“源码”三个词其实对应了三个层次的需求渲染解决“看得见”互动解决“看得懂”源码解决“改得动”。为什么非要上 3D二维图在表达层级结构时有个天然缺陷——深度信息会被压扁。大模型里像 Transformer 的堆叠层、MoE 的专家分支、KV Cache 的时序增长这些本质上都是三维甚至四维的关系。用 2D 画出来要么用大量连线把图搞成蜘蛛网要么就得拆成好几张图读者在脑子里拼装。3D 场景里层与层之间的前后关系、分支的展开方向、数据流的路径都能用空间位置直接表达认知负担一下就降下来了。这个工具适合谁我列一下我预期的主要使用者一是做技术分享的工程师需要一张能讲清楚的动态图二是学大模型原理的学生想直观理解结构三是做技术选型的产品或架构师想快速对比不同模型的层数和参数分布。如果你只是想看个热闹那静态图够了但如果你要讲给别人听或者要自己改结构做实验这个互动工具的价值就出来了。需要提前说明的是下面讲的所有实现细节都是基于“一个合格的前端 图形开发者在这个场景下最可能采用的合理方案”来补全的。原始项目正文是空的所以我按常见实践把技术栈、渲染管线、交互逻辑这些补全出来你可以直接照着复现也可以按自己的技术偏好替换其中某些环节。2. 技术选型Three.js 还是原生 WebGL我为什么选了前者2.1 渲染层的三个候选方案对比做 3D 网页渲染绕不开三个选择原生 WebGL、Three.js、以及基于 Three.js 封装的一些高阶库比如 react-three-fiber。我把它们放在一张表里对比方便你按自己的项目情况选。方案上手成本灵活度生态与文档适合场景原生 WebGL极高最高需要自己造轮子极致性能优化、特殊渲染效果Three.js中等高非常成熟绝大多数 3D 可视化项目react-three-fiber中等中高依赖 React 生态React 技术栈的团队我最终选 Three.js理由很实际。第一这个项目的核心是“表达结构”不是“炫技渲染”我不需要去手写 shader 做光线追踪那种级别的效果Three.js 内置的材质和光照系统完全够用。第二Three.js 的场景图Scene Graph模型和我要表达的“模型层级结构”天然对应——一个 Group 代表一层层里挂若干 Mesh 代表注意力头或专家这种嵌套关系和代码结构是一致的写起来很顺。第三社区资源多遇到问题搜一下基本都有答案这对一个要长期维护的工具来说很重要。原生 WebGL 我也试过写到第三个 draw call 的时候我就放弃了。光是管理 buffer、attribute、uniform 这些底层状态代码量就是 Three.js 的三四倍而且一旦要加个后处理效果又得从头搭一遍。除非你有极致的性能需求否则没必要。2.2 为什么不用游戏引擎导出有人会问为什么不用 Unity 或 Unreal 导出 WebGL 版本我实测过问题有三个。一是包体积一个最简单的 Unity WebGL 构建出来就是十几 MB 起步加载慢二是交互逻辑和网页的 DOM 事件体系割裂要做个 tooltip 都得走引擎的 UI 系统很别扭三是迭代效率低改一行代码要重新构建整个工程。对于这种“结构可视化”类的工具Three.js 的轻量和灵活是压倒性优势。2.3 数据驱动的设计思路这个工具最关键的一个设计决策是场景不是硬编码的而是由一份 JSON 配置驱动的。也就是说你换一份模型结构描述文件3D 场景就跟着变。这份配置大概长这样{ modelName: Demo-LLM-2026, layers: [ { type: attention, heads: 32, dim: 4096, position: [0, 0, 0] }, { type: moe, experts: 8, topK: 2, position: [0, 3, 0] } ] }渲染层读取这份配置按type决定用哪种几何体按position决定摆放位置按heads、experts这些数值决定细分数量。这样做的好处是模型迭代时你只需要改配置不用动渲染代码。我在实际使用中发现这个设计让整个工具的复用率提升了一大截——同一套渲染逻辑我拿它渲染过 Transformer、MoE、甚至一些多模态的跨模态注意力结构只换了配置文件。3. 把 Transformer 结构翻译成 3D 场景的具体做法3.1 层级结构的空间映射规则这是整个项目里最需要动脑子的部分。抽象的结构怎么变成具体的空间布局我定了几条规则你可以参考。第一条垂直方向代表数据流动方向。输入 embedding 在最下面输出在最上面中间每一层按顺序往上叠。这样用户一看就知道数据是从下往上走的符合直觉。第二条水平方向代表并行分支。比如多头注意力里的多个头或者 MoE 里的多个专家它们在水平方向展开。头数越多横向铺得越宽。这样一眼就能看出“这个模型有多少个头在并行工作”。第三条深度方向Z 轴代表时序或缓存。KV Cache 这种随时间增长的结构就沿着 Z 轴往后延伸。用户旋转视角的时候能直观看到缓存是怎么一层层堆起来的。这三条规则定下来之后任何结构都能找到对应的空间表达。我拿一个 32 层的模型试过垂直方向叠 32 层每层横向展开 32 个头整体看起来就像一个立体的“塔”层次感非常清楚。3.2 几何体的选择逻辑不同结构用不同几何体这不是为了好看而是为了让形状本身携带信息。注意力层用扁平的立方体因为它的计算本质是矩阵乘法方方正正的形状对应矩阵。MoE 专家用圆柱体因为专家是“独立处理单元”圆柱的独立感更强而且多个圆柱并排时视觉上容易区分。归一化层用薄片因为它不改变维度只是做缩放薄片能表达“轻量处理”的感觉。残差连接用细长的管道从下层直接连到上层绕过中间处理形状上就是一条“旁路”。这些选择没有绝对的对错核心原则是形状要能暗示功能。你在做自己的项目时也可以按这个思路给每种结构设计一个专属几何体用户看多了就会形成条件反射看到圆柱就知道是专家看到薄片就知道是归一化。3.3 材质与光照的取舍材质这块我踩过坑。一开始为了好看用了高反射的金属材质结果在复杂场景里反光太强反而看不清结构。后来改成哑光材质配合两盏方向光加一盏环境光结构清晰度立刻上来了。具体参数上我用的是MeshStandardMaterialroughness设 0.7metalness设 0.1这样既有立体感又不会过度反光。光照方面一盏主光从左上角打下来一盏补光从右下角打上来再加一盏低强度的环境光消除死黑区域。这个组合我试了好几版是清晰度和美观度平衡得比较好的。提示如果你的场景里结构特别密集建议把材质的flatShading打开用平面着色代替平滑着色这样每个面的边界更清楚密集结构不容易糊成一团。4. 交互设计让用户真正“玩起来”的几个关键点4.1 轨道控制器的基础配置与手感调优Three.js 自带的OrbitControls是交互的基础但默认参数的手感不一定适合结构可视化。我调了几个值效果差别很大。enableDamping一定要开设成 truedampingFactor设 0.05。这样旋转的时候有惯性停下来是缓缓减速而不是急刹手感自然很多。rotateSpeed我设成 0.5默认的 1.0 太快了结构复杂的时候容易转晕。zoomSpeed设 0.8minDistance和maxDistance根据场景大小设我一般设成场景包围盒的 0.5 倍到 3 倍防止用户缩到模型内部或者缩到看不见。还有一个细节autoRotate我默认关掉但提供了一个按钮让用户手动开启。自动旋转适合展示但用户想仔细看某个结构时自动旋转是干扰。这个开关交给用户控制比较好。4.2 点击选中与信息面板的联动点击交互是这个工具的核心价值之一。实现逻辑是用Raycaster从相机发射一条射线检测和场景中哪些 Mesh 相交取最近的那个然后高亮它同时在侧边面板显示它的详细信息。这里有个性能坑要注意。如果场景里有几千个 Mesh每次点击都遍历一遍做射线检测会卡。我的做法是给每个 Mesh 加一个userData字段存它的结构信息然后射线检测只检测顶层 Group命中后再在 Group 内部做一次精确检测。这样检测次数从几千降到几十流畅度提升明显。信息面板显示什么我列一下我实际放的字段结构类型、参数数量、输入输出维度、在模型中的位置第几层、以及一段简短的文字说明。这些信息从配置 JSON 里读所以换模型时面板内容自动跟着变。4.3 数据流动动画的实现方式静态结构看久了会腻数据流动动画能让用户理解“计算是怎么发生的”。我的实现方式是用Line或者TubeGeometry画一条路径然后用setDrawRange控制这条路径的显示长度配合requestAnimationFrame让显示长度随时间增长就形成了“流动”的效果。具体来说一条从输入到输出的路径我把它离散成 100 个点动画每帧把drawRange的终点往后推一个点推到末尾后重置。速度可以调我默认设成每秒走完一条路径太快看不清太慢又显得拖沓。注意如果同时有几十条路径在流动每帧都更新drawRange会有性能压力。我的优化是只让用户当前选中的那条路径播放动画其他路径静态显示。这样既保证了重点突出又控制了性能开销。4.4 视角预设与“一键看懂”按钮不是每个用户都愿意自己转视角。我加了几个预设视角按钮正视图、俯视图、侧视图、以及一个“全局概览”视角。点一下相机用Tween平滑过渡到对应位置过渡时间设 0.8 秒太快会晕太慢会等得不耐烦。“全局概览”视角是我用得最多的它会自动计算场景的包围盒然后把相机放到一个能看全整个模型的位置。这个功能在演示的时候特别有用讲完一个局部点一下就能拉回全局节奏很顺。5. 源码结构与二次开发指南5.1 目录组织与模块划分源码我按功能拆成了几个模块这样你改哪块就动哪个文件不会牵一发动全身。/src /core scene.js // 场景初始化、光照、相机 renderer.js // 渲染器配置、后处理 /model parser.js // 解析配置 JSON builder.js // 根据解析结果构建 3D 对象 materials.js // 材质定义 /interaction controls.js // 轨道控制器 picking.js // 射线检测与选中 animation.js // 数据流动动画 /ui panel.js // 信息面板 toolbar.js // 工具栏按钮 main.js // 入口串联所有模块这个划分的核心逻辑是关注点分离core 管渲染环境model 管结构表达interaction 管用户操作ui 管界面。你要换渲染器只动 core要加新结构类型只动 model要改交互方式只动 interaction。我在实际迭代中这个结构帮我省了很多“改一处崩三处”的时间。5.2 配置文件的字段说明与扩展方法配置 JSON 是整个工具的“数据源”我把字段设计得尽量通用。核心字段有这些字段类型说明typestring结构类型决定几何体和材质position[x,y,z]在场景中的位置size[w,h,d]几何体尺寸paramsobject结构参数如 heads、expertsconnectionsarray与其他结构的连接关系要扩展新结构类型你需要在builder.js里加一个对应的构建函数在materials.js里加对应的材质然后在配置里用新的type值。整个过程不需要动渲染核心扩展成本很低。5.3 性能优化的几个实操手段场景一大帧率就掉这是 3D 可视化的通病。我用了几个手段把帧率稳在 60 帧。第一实例化渲染。如果有大量相同几何体比如 32 个注意力头用InstancedMesh代替 32 个独立 Meshdraw call 从 32 降到 1。这个优化在大模型场景里效果特别明显。第二视锥剔除。Three.js 默认开启但要确保每个 Mesh 的boundingSphere计算正确否则剔除会失效。我在构建完场景后手动调一次computeBoundingSphere保证剔除准确。第三按需渲染。如果场景是静态的没有动画在跑就不需要每帧都渲染。我用一个needsRender标志位控制只有相机移动、动画播放、选中变化时才触发渲染。这个优化在移动端效果显著电量消耗降了不少。第四LOD细节层次。远处的结构用低面数版本近处用高面数版本。Three.js 的LOD对象可以自动根据距离切换我给它设了三个层级距离 10 以内用高模10 到 30 用中模30 以外用低模。6. 实测中遇到的坑与排查过程6.1 透明材质导致的渲染顺序错乱这个问题卡了我最久。场景里有些结构用了半透明材质结果渲染出来前后关系全乱了该挡住的没挡住不该透的透出来了。排查过程是这样的我先怀疑是深度测试的问题检查了depthTest和depthWrite设置发现半透明材质的depthWrite默认是 true这会导致它写入深度缓冲后面的物体就被错误地遮挡了。改成 false 之后遮挡问题解决了但新的问题来了——半透明物体之间的前后关系还是不对。继续查发现是渲染顺序的问题。Three.js 默认按对象添加顺序渲染但半透明物体需要按“从远到近”的顺序渲染才正确。解决办法是给半透明物体设renderOrder或者干脆把它们放到一个单独的 Group 里手动控制渲染顺序。我最后用的是后者把所有半透明结构归到一个 Group在渲染循环里按相机距离排序后再渲染。提示如果你的场景里半透明物体不多最简单的办法是给它们设一个统一的renderOrder值让它们在不透明物体之后渲染。如果半透明物体之间也有遮挡关系那就必须做距离排序了。6.2 大量文本标签导致的性能骤降结构上要标名称一开始我用的是CSS2DRenderer给每个结构加 HTML 标签。结构少的时候没问题加到 200 个标签以上帧率直接从 60 掉到 20。原因是每个 CSS2D 标签都是一个真实的 DOM 元素200 个 DOM 元素每帧都要更新位置浏览器的重排重绘压力很大。我换成Sprite加 Canvas 纹理的方案把文字画到 Canvas 上再作为纹理贴到 Sprite 上。这样标签变成了 3D 对象的一部分由 GPU 渲染性能好了很多。代价是文字清晰度不如 HTML 标签特别是缩放的时候会有点糊。我的折中方案是重要的标签用 Sprite次要的标签默认隐藏用户鼠标悬停时才显示。这样既保证了性能又保证了关键信息的可读性。6.3 移动端触摸交互的适配问题桌面端调好的交互到移动端就各种不对劲。主要问题是触摸事件和鼠标事件的模型不一样OrbitControls虽然支持触摸但默认的手势映射和用户习惯有出入。我改了几个地方。单指拖动改成旋转默认是旋转这个没问题双指捏合改成缩放默认也是缩放但双指拖动我改成了平移默认是缩放和捏合冲突了。另外移动端没有 hover 事件所以 tooltip 的触发逻辑要改成“点击显示再点隐藏”而不是“悬停显示移开隐藏”。还有一个坑是移动端的devicePixelRatio通常很高渲染分辨率设太高会卡。我把renderer.setPixelRatio限制在 2 以内超过 2 的按 2 算画质损失不大但性能提升明显。6.4 配置解析的容错处理配置文件是手写的难免有错。一开始没做容错配置里少个字段整个场景就崩了白屏控制台报一堆错用户完全不知道发生了什么。后来我加了一层校验解析配置时对每个必需字段做检查缺失的用默认值补上类型不对的尝试转换转换失败就跳过这个结构并在控制台输出警告。这样即使配置有小问题场景也能正常渲染只是少了某个结构用户至少能看到东西不会一脸懵。这个容错逻辑我写成了一个独立的validateConfig函数在解析前先跑一遍。函数返回一个清洗后的配置对象和一个警告列表警告列表可以在 UI 上以提示条的形式展示告诉用户“第 3 层的 heads 字段缺失已使用默认值 8”。这样用户能自己发现问题并修正。7. 这个工具还能往哪些方向继续做7.1 接入真实模型数据做动态渲染目前的结构是手动配置的下一步我想做的是直接从模型文件里读取结构信息。比如读一个 PyTorch 的state_dict解析出每一层的名称、维度、参数数量自动生成配置 JSON然后渲染出来。这样你拿到任何一个开源模型都能一键生成它的 3D 结构图不用手写配置。这个方向的技术难点在于模型格式的多样性不同框架保存的格式不一样需要写多个解析器。但一旦跑通工具的实用性会上一个大台阶。7.2 加入参数热力图现在每个结构的颜色是固定的如果能把参数数量、计算量这些指标映射成颜色深浅用户一眼就能看出“哪层最重”“哪个专家被激活得最多”。实现方式是用vertexColors或者动态生成 Canvas 纹理把数值映射到色带上的颜色。这个功能对做性能分析的人会很有用。7.3 支持多模型对比视图把两个模型并排渲染相同结构对齐不同结构高亮这样对比起来非常直观。实现上就是把场景分成左右两个区域各自渲染一个模型相机同步移动。这个功能对做技术选型的人价值很大能快速看出两个模型的架构差异。7.4 导出为可嵌入的组件现在这个工具是一个独立页面如果能打包成一个 Web Component 或者 iframe 可嵌入的组件别人就能把它嵌到自己的文档或博客里。这样传播范围会广很多。技术上是把整个应用打包成一个自定义元素暴露几个配置属性外部通过属性传参控制渲染内容。我在实际做这个项目的过程中最大的体会是3D 可视化的难点不在渲染而在“翻译”。把抽象的结构翻译成空间关系把计算过程翻译成动画把参数翻译成视觉变量每一步都需要你对被表达的对象有足够深的理解。渲染技术是工具理解才是核心。你如果要做类似的项目建议先把结构关系在纸上画清楚想明白每个维度代表什么再动手写代码会顺很多。