企业官网建设流程全解析

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）。我把它们放在一张表里对比，方便你按自己的项目情况选。

我最终选 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 材质与光照的取舍

材质这块我踩过坑。一开始为了好看，用了高反射的金属材质，结果在复杂场景里反光太强，反而看不清结构。后来改成哑光材质，配合两盏方向光加一盏环境光，结构清晰度立刻上来了。

具体参数上，我用的是MeshStandardMaterial，roughness设 0.7，metalness设 0.1，这样既有立体感又不会过度反光。光照方面，一盏主光从左上角打下来，一盏补光从右下角打上来，再加一盏低强度的环境光消除死黑区域。这个组合我试了好几版，是清晰度和美观度平衡得比较好的。

提示：如果你的场景里结构特别密集，建议把材质的flatShading打开，用平面着色代替平滑着色，这样每个面的边界更清楚，密集结构不容易糊成一团。

4. 交互设计：让用户真正“玩起来”的几个关键点

4.1 轨道控制器的基础配置与手感调优

Three.js 自带的OrbitControls是交互的基础，但默认参数的手感不一定适合结构可视化。我调了几个值，效果差别很大。

enableDamping一定要开，设成 true，dampingFactor设 0.05。这样旋转的时候有惯性，停下来是缓缓减速，而不是急刹，手感自然很多。rotateSpeed我设成 0.5，默认的 1.0 太快了，结构复杂的时候容易转晕。zoomSpeed设 0.8，minDistance和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 是整个工具的“数据源”，我把字段设计得尽量通用。核心字段有这些：

要扩展新结构类型，你需要在builder.js里加一个对应的构建函数，在materials.js里加对应的材质，然后在配置里用新的type值。整个过程不需要动渲染核心，扩展成本很低。

5.3 性能优化的几个实操手段

场景一大，帧率就掉，这是 3D 可视化的通病。我用了几个手段把帧率稳在 60 帧。

第一，实例化渲染。如果有大量相同几何体（比如 32 个注意力头），用InstancedMesh代替 32 个独立 Mesh，draw 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 可视化的难点不在渲染，而在“翻译”。把抽象的结构翻译成空间关系，把计算过程翻译成动画，把参数翻译成视觉变量，每一步都需要你对被表达的对象有足够深的理解。渲染技术是工具，理解才是核心。你如果要做类似的项目，建议先把结构关系在纸上画清楚，想明白每个维度代表什么，再动手写代码，会顺很多。