这一页把前面五层的产品叙事放下，看代码和部署里实际是什么样： 后端负责什么、开源边界在哪、怎么装、推理该放哪一边。
直觉上"画框在前端，那前端就够了"。这个直觉在一种情况下确实成立， 而"标注平台"的定义恰好排除了那种情况。
如果只是一个人标 100 帧，打开浏览器、载入本地文件、画框、导出下载， 纯前端工具确实存在，而且够用。所以问题不是技术上行不行，是规模假设是什么。
前端 = 一次会话中的交互
谁在用、在哪台设备、这次打开要做什么
易失的、多副本的、不可信的
后端 = 跨越所有会话、所有人、所有时间的【唯一真相】
数据是什么、谁在标、标到哪了、标签从哪来
持久的、单副本的、权威的前端天然是多副本的。你开两个浏览器标签就是两份内存状态，互相不知道对方存在。 两个副本要一致，就必须有一个权威节点做仲裁。这是架构上的不可能，不是能力问题。
| 需求 | 只有前端 | 为什么必须后端 |
|---|---|---|
| 刷新页面后标注还在 | ❌ | 需要持久化存储 |
| 20 个人标不同帧 | ❌ | 需要共享状态 |
| 防止两个人标同一帧 | ❌ | 需要中心化仲裁 |
| 进度看板 | ❌ | 需要全局聚合视图 |
| 审核流，标完再审再打回 | ❌ | 需要状态机 |
| 上传 20 TB 数据集 | ❌ | 浏览器存不下也拉不动 |
| 跑 AI 预标注 | ❌ | 需要 GPU 服务器 |
| 统一类别定义 | ❌ | 需要权威 schema |
| 记录标签来源 | ❌ | 需要数据库 |
| 权限与审计 | ❌ | 需要身份系统和日志 |
第三行最容易被忽略，但它是硬需求。一百个标注员并发工作时， "这一帧有人正在标，别人不能碰"只能靠一个中心节点保证，前端之间无法互相协调。
MySQL 元数据、标注对象、用户、任务、模型运行记录
MinIO 原始文件（点云、图片），对象存储
Redis 缓存
Flyway 启动时自动做数据库 schema 迁移一个 PCD 可能有几十 MB，一个数据集可能几 TB。原始文件绝不能进浏览器， 必须由后端管理分发：签名 URL、按需分块、断点续传。
真正值钱的是业务数据模型：标注对象有哪些字段、什么约束； 角色与组织结构；任务与领取；以及最关键的来源追踪。
sourceId = -1 这条标注是人标的，也就是 Ground Truth
sourceId = 模型ID 这条标注是某个模型版本的预标注每条标注都记录它从哪来。有了这个字段，人在环、模型评估、导出纯净训练集才都做得出来。 没有后端，这套来源追踪无处安放。
再往外是三类重计算，交给独立的 Python 微服务：PCD 解析与渲染预处理、 全数据集的相似度图、点云和图像的预标注（需要 GPU）。为什么要拆出去， 理由很直接：几十 MB 的 PCD 用 JS 解又慢又占内存，而降维和推理都要 GPU。
Xtreme1 是真开源，全栈。许可证 Apache-2.0，由 LF AI & Data Foundation 孵化， 是第一个进入该基金会的开源标注项目。主仓库包含 Java 后端和 TypeScript 前端。
前端不是一个应用，是四个子应用：主应用、点云工具、图像工具、文本工具。 其中点云工具是工业级的浏览器 3D 标注器，想学"3D 标注交互怎么做"，读这个目录比读任何文档都有用。
| 许可证 | 哪些仓库 |
|---|---|
| Apache-2.0 | 主仓库、SDK、文档站、资源库 |
| MIT | 相似度图服务 |
| GPL-3.0 | 图像预标注服务，传染性许可证 |
| 无许可证 | PCD 渲染工具、点云预标注服务。法律上等于保留所有权利 |
自己内部部署基本没问题，因为 GPL 的义务主要在分发时触发，不是使用时。
但要打包进对外销售的产品，这两个无许可证的仓库加一个 GPL-3.0 是必须过法务的点。 更麻烦的是 PCD 渲染工具是默认启动的必需服务，绕不开。
活跃，2026 年 9 月还有推送
主仓库 · SDK · 文档站 · PCD 工具 · 点云预标注
停滞，2024 年 8 月起没动
图像预标注 · 相似度图服务星标分布更能说明问题：组织总计约 1414，主仓库独占 1384。 98% 的关注度集中在主仓库，所有微服务加起来不到 20。
一、它活着，不是弃坑项目，最近提交很密集，修的都是真问题。
二、但近期提交以修 bug 和工程清理为主，不是功能扩张期。 别指望它快速长出具身原生能力。
三、真正跑起来的人很少。关注者只有三十几个，发布包下载量四十几次， 大量星标只是收藏式关注。
四、最该知道的一点：它由商业公司主导，开源版是商业版的引流入口。 所以开源版的功能策略一定够用但不富。
| 项 | 值 |
|---|---|
| 文件名 | xtreme1-v0.9.3.zip |
| 大小 | 10,210 字节 |
十 KB 装不下任何源码。这个包里只有 compose 文件和 deploy 目录， 所以官方的"下载解压然后 compose up"路径，全部软件都来自镜像仓库。
nginx / mysql / redis / minio 第三方官方镜像
backend basicai/xtreme1-backend:v0.9.3 源码构建被注释掉
frontend basicai/xtreme1-frontend:v0.9.3 同上
pcd-tools 以及另外三个微服务 连 build 行都没有关键差别：只有后端和前端留了源码构建的入口，四个 Python 微服务根本没有 build 路径。 也就是说，改点云解析或预标注没有官方路径，得自己克隆、编译、重新打标签， 并且接受无许可证的状态。
每次启动都会去镜像仓库重新拉，于是：
一、离线起不来。 二、本地自己编译的同名镜像会被覆盖，想用自己编的必须把策略改成 missing。
三、tag 是可变的。同一个 tag 理论上能被上游重新推送成不同内容。 生产部署应该固定 digest，而不是 tag。
一、必须用 v0.9.3 或更新，老版本有 SSRF 漏洞。 修复说明里写得很清楚：白名单为空时放行一切，设置时只做子串匹配， 于是任何登录用户都能让后端去请求云元数据服务、数据库、对象存储的管理端口。
二、密码硬编码，端口全部对外。 compose 文件里 MySQL 密码、用户密码、对象存储密码都是明文， 端口映射的写法默认绑定到 0.0.0.0。 自己机器上玩没关系，部署到服务器第一件事是改密码加防火墙，或者改成只绑本地回环。
这是个真问题，答案是分两类：交互式推理放客户端，批量推理放服务端。 两类都放错的情况也常见，所以先澄清两个事实。
| API | 2026 年状态 |
|---|---|
| WebGPU | ✅ 2026 年 1 月达成基线，三大浏览器全线稳定 |
| WebNN | ❌ 仅 Chrome 的实验性 Origin Trial，Safari 和 Firefox 完全没实现 |
业界对 WebNN 的判断是：2026 年还不能生产用，作为默认路径最乐观也是 2027 年。
但你要的能力用 WebGPU 今天就能拿到。2026 年的生产栈是 WebGPU 加 ONNX Runtime Web， 已经有生产案例：设计工具、三维渲染库、浏览器里跑大模型的项目都在跑。
如果打包成桌面客户端
= Chromium + Node.js，有完整原生模块能力
→ 可以直接打包 ONNX Runtime 的 CUDA 后端、LibTorch、TensorRT
→ 性能远超 WebGPU，而且能吃到全套 CUDA 生态
→ 这时候根本不需要 WebNN
如果只用浏览器，不装客户端
→ 没有原生模块
→ WebGPU 加 ONNX Runtime Web 是唯一路径，WebNN 得等 2027| 交互式推理 | 批量推理 | |
|---|---|---|
| 触发方式 | 标注员正在看这一帧，点一下 | 提交"跑完这十万帧"的任务 |
| 数据在哪 | ✅ 已经在客户端 | ❌ 在服务端对象存储 |
| 延迟要求 | 100 ms 以内，否则交互卡顿 | 无所谓 |
| 一致性要求 | 低，人马上会检查修正 | 极高，直接进训练集 |
| 该放哪 | 客户端 | 服务端 |
点一下自动抠出物体
服务端：网络往返加排队加推理，三百到八百毫秒，手感崩了
客户端：直接推理，三十到八十毫秒，顺手
而且数据本来就在客户端，人正在看这一帧，不用传任何东西一、数据不在客户端。批量跑十万帧预标注，客户端要先把十万帧下载下来， 而标注员只会标其中几百帧。这等于为了跑模型把整个数据集推到所有人机器上。 分布式计算的铁律是算力向数据移动，反过来不划算。
二、一致性没有保证。二十台客户端，GPU 型号不同、驱动版本不同、 量化精度不同、浮点累加顺序不同，产出二十个略有差异的标签分布混进同一个训练集。 这是静默的数据质量问题。
三、来源追踪会被摧毁。来源标记的整个价值是"这批标签来自模型 X 的版本 Y"。 二十台客户端各跑各的，这句话就不成立了。
四、闲置算力这个假设不成立。标注员在工作时 GPU 正在渲染点云， 不是闲置，强行跑推理会卡界面降低产能；标注员不在线时机器已经关机。 "闲置"和"在线"这两个条件几乎不同时成立。
五、运维成本。服务端更新模型是更新一个容器，所有人立刻用上； 客户端要推送到 N 台机器，还要处理版本漂移、离线机器、回滚和排障。
后端的价值不是"存数据"，是"唯一真相"和"中心化仲裁"。只要用户超过一个，它就省不掉。
开源的边界要看两处：许可证是不是统一、活跃度是不是集中在主仓库。 这两处都容易在评估时只看主页。
推理的判据只有一条：数据在哪，就算在哪。 交互式的数据已经在客户端，批量的数据在服务端，所以答案天然分开。