企业官网建设流程全解析

• 人工智能
• 大模型
• 微调
• LoRA
• 模型优化
• 模型量化
• 强化学习

Unsloth Docker Studio 与 JupyterLab 镜像在构建产物中散布了完整的 Unsloth 归属声明（attribution），而保留这些声明不是可选的"品牌美化"，而是 AGPLv3 许可协议下的硬性合规条件。本文以 docker/jupyter/BRANDING.md 为骨架，结合 docker/jupyter/unsloth_branding.py、docker/Dockerfile.studio、docker/studio_launch.sh 与 docker/NOTICE 等源码，完整梳理"哪些内容必须保留、分散在哪些文件、通过什么机制在构建期与运行期强制校验"，帮助镜像维护者、二次分发者与安全审计者理解这套"防白标（white-label）"守卫的工程实现与许可边界。读完本文，你将能解释 PHRASE 字面量为何必须字节级一致、--verify 校验器检查哪些资产，以及镜像无法启动时那段错误横幅的来龙去脉。

一、为什么署名是许可条件而不是构建检查

Unsloth Docker Studio 镜像同时承载两份开源许可：Unsloth Studio 以 GNU Affero General Public License v3.0（AGPLv3）授权（见 studio/LICENSE.AGPL-3.0），Unsloth Core 以 Apache License 2.0 授权（见根目录 LICENSE）。docker/NOTICE 依据 AGPLv3 第 7(b) 条，将以下内容指定为镜像的Appropriate Legal Notice（适当法律声明）：

• 归属声明 "Built by the Unsloth team"；
• 版权行 "Copyright 2026-Present the Unsloth team"；
• 许可声明 "Licensed under Apache 2.0 and the GNU AGPLv3"；
• 显示于 JupyterLab 顶栏与加载 splash 的 Unsloth logo 与 "Unsloth Dark" 主题；
• Help > About 对话框及其中的 Source、Website、License、AGPLv3、Apache 链接。

NOTICE 明确写道：如果你向用户传达、修改或通过网络提供该镜像（或其衍生作品），就必须原样保留并向用户展示这些声明。删除或篡改它们——无论是改动构建流程、品牌源码还是完整性守卫本身——都不能免除这项许可义务。同时 NOTICE 也划清了边界：本声明仅规范 AGPLv3 下的版权归属，不授予任何商标许可，"Unsloth" 及 Unsloth logo 仍是 Unsloth 团队的商标。

二、必须保留的署名清单

BRANDING.md 把"必须保留"的内容归纳为五条：

这些字符串的唯一事实来源（canonical source）有两处：Python 侧的 docker/jupyter/unsloth_branding.py 与 TypeScript 镜像侧 docker/jupyter/unsloth_labext/src/branding.ts。其中最关键的一条规则是：PHRASE字面量在两个文件之间必须字节级一致（byte-identical），因为守卫会在构建好的 labextension bundle 中直接 grep 这个完整字符串。

unsloth_branding.py第 19–41 行集中定义了全部规范字符串：

PRODUCT = "Unsloth Docker Studio" SHORT_LABEL = "Built by the Unsloth team" SPLASH_LABEL = "Loading Unsloth Docker" COPYRIGHT = "Copyright 2026-Present the Unsloth team" AGPL_NOTICE = "Licensed under Apache 2.0 and the GNU AGPLv3" WEBSITE_URL = "https://unsloth.ai" DOCS_URL = "https://unsloth.ai/docs" SOURCE_URL = "https://github.com/unslothai/unsloth" LICENSE_URL = "https://github.com/unslothai/unsloth#license" AGPL_URL = "https://www.gnu.org/licenses/agpl-3.0.html" APACHE_URL = "https://www.apache.org/licenses/LICENSE-2.0" # ONE literal, byte-identical to PHRASE in unsloth_labext/src/branding.ts PHRASE = ( "Unsloth Docker Studio and JupyterLab image. Built by the Unsloth team. " "Licensed under Apache 2.0 and the GNU AGPLv3. " "Source: https://github.com/unslothai/unsloth Website: https://unsloth.ai" ) THEME_NAME = "Unsloth Dark" LABEXT_NAME = "unsloth-jupyterlab" ABOUT_PLUGIN_ID = "unsloth-jupyterlab:about" SPLASH_PLUGIN_ID = "unsloth-jupyterlab:splash" LOGO_DATA_URI_PREFIX = "data:image/png;base64,iVBOR"

对应的 docker/jupyter/unsloth_labext/src/branding.ts 声明了完全相同的常量，并且注释明确强调：PHRASE必须以单个字面量书写、不能拼接，这样 webpack 在生产构建中会把它作为连续字符串保留下来，守卫才能在压缩产物里完整地匹配到它。

三、署名资产分布在哪些文件

BRANDING.md 给出了一张"资产清单"表，说明每份品牌内容各自承载在哪：

以下逐一说明各文件的实际实现，均可在仓库中直接查看：

• docker/jupyter/login.html：基于 Jinja2 模板{% extends "page.html" %}重写 jupyter_server 默认登录页，隐藏原生顶部 header，渲染与 "Unsloth Dark"（Monokai）主题一致的深色居中卡片；每次访问还会从sloth/01.png … 20.png中随机选一张 sloth 贴纸（由构建阶段install_sloth_stickers.py从 Studio 前端资源复制），贴纸缺失时通过onerror回退到 Unsloth logo。卡片下方即归属页脚：Built by the Unsloth team.+ Apache 2.0/AGPLv3 License Link + 版权行 + 源码/官网链接。
• docker/jupyter/unsloth_labext/src/about.ts：注册unsloth:about命令，在 Help 菜单（mainMenu.helpMenu.addGroup）与命令面板中加入 "About Unsloth Docker Studio" 入口；弹窗正文仅使用 branding.ts 中的受信任常量拼接，并把PHRASE写入data-unsloth-attribution数据属性，保证它被原样打进 bundle 供守卫检索，同时避免 innerHTML 注入面。
• docker/jupyter/unsloth_labext/src/splash.ts：实现ISplashScreen提供者，替换 JupyterLab 原生 splash（原生 splash 在构建时被禁用并加锁，使该插件成为唯一的 splash 提供者），展示旋转的 Unsloth logo 与 "Loading Unsloth Docker" 标语，并遵循prefers-reduced-motion无障碍约定。
• docker/jupyter/unsloth_labext/src/logo.ts：把 Unsloth logo 以 base64 data URI 内嵌进 TS 源码，使插件运行时不再依赖额外静态资源文件——这也是unsloth_branding.py中LOGO_DATA_URI_PREFIX = "data:image/png;base64,iVBOR"前缀校验的由来。
• docker/jupyter/overrides.json：镜像默认烘焙的 JupyterLab 设置覆盖，包含theme: "Unsloth Dark"、adaptive-theme、笔记本"Restart & Run All"按钮、关闭新闻推送等。

此外，docker/jupyter/jupyter_server_config.d/unsloth_branding_guard.json 负责把unsloth_branding注册为启用的 jupyter_server 扩展：

{ "ServerApp": { "jpserver_extensions": { "unsloth_branding": true } } }

unsloth_branding.py第 213–232 行正是通过_jupyter_server_extension_points()暴露扩展点、由_load_jupyter_server_extension(serverapp)在加载时执行校验。

四、三重强制机制：构建期、容器启动期、JupyterLab 加载期

BRANDING.md 明确指出守卫（guard）在三处独立执行，形成三层防线（可对照 docker/Dockerfile.studio 与 docker/studio_launch.sh 验证）：

1. 构建期（Build time）：python -m unsloth_branding --verify在镜像构建阶段执行，任何署名资产缺失或被篡改都会让构建直接失败。在 docker/Dockerfile.studio 中，守卫模块、AGPLv3 许可证文本及其启用配置被复制进基础 venv，随后立即执行&& /opt/unsloth-venv/bin/python -m unsloth_branding --verify（该文件第 239–249 行），校验失败即中断构建。
2. 整镜像启动期（Whole image）：docker/studio_launch.sh 在启动 supervisord 之前再次运行同一校验，失败则拒绝启动容器。脚本第 143 行即为if ! /opt/unsloth-venv/bin/python -m unsloth_branding --verify; then ...。
3. JupyterLab 加载期：unsloth_branding同时作为 jupyter_server 扩展，在服务加载时重新校验，若容器启动后署名被剥离，则拒绝对外提供 JupyterLab——_load_jupyter_server_extension会打印 banner 到 stderr、调用serverapp.log.critical并最终serverapp.exit(1)。

三层机制在语义上有明确分工：studio_launch.sh 负责"容器启动前拦截"，jupyter_server 扩展则"兜底"那些绕过启动脚本直接运行 JupyterLab 的场景，源码注释对此写得很直白（studio_launch.sh refuses the container first; this backstops a direct run）。

五、守卫到底校验什么：verify_branding 的检查清单

unsloth_branding.py的核心函数verify_branding()（第 108–186 行）在解析出的资产路径上逐项检查，任何一项不满足都会收集进problems列表并最终导致非零退出。检查项如下：

其中 bundle 扫描的逻辑（_bundle_text，第 94–105 行）值得注意：它把 labextension 静态目录下所有.jschunk 拼接成一个大字符串再逐个匹配标记，因为生产构建只压缩标识符、不重写字符串字面量，归属声明会原样存在于某一个 chunk 中。而page_config.json的检查针对一种特殊绕过方式：disabledExtensions不会从磁盘删除 bundle，但会在加载时把扩展剥离——因此守卫专门扫描所有可能的 page_config 位置（含 jupyter_core 配置路径），只要出现unsloth-jupyterlab或unsloth-jupyterlab:*前缀的禁用项就报错。

路径解析由resolve_paths()（第 44–76 行）完成，默认基于sys.prefix/share/jupyter、jupyter_server包目录与jupyter_config_path()推导所有受检资产的实际安装位置，同时允许测试显式传入根路径（测试即依赖此能力，见下文）。

失败时banner()（第 189–210 行）会输出一段 72 字符宽的醒目横幅，逐条列出所有缺失项，并以SHORT_LABEL + COPYRIGHT、Website、Source、License 收尾。CLI 入口main()（第 235–250 行）支持--verify（校验失败退出码 1）以及--venv-share、--jupyter-server-dir两个用于定位资产目录的参数；校验通过时打印Unsloth branding integrity check passed (Unsloth Docker Studio, AGPLv3).。

六、工程设计与许可哲学：绊线（tripwire）而非锁

BRANDING.md 用一段话概括了整个守卫的设计哲学：

The guard is a tripwire, not a lock. Anyone who forks the source controls the build and can edit any of these files. It exists to make accidental removal fail loudly and to make deliberate removal unambiguous.

也就是说：任何 fork 者本就掌控构建流程，可以随意修改这些文件，守卫不可能也不打算阻止蓄意移除。它的真实价值有两层：

1. 让无意的删除大声失败：浅层的 find-and-replace、漏拷贝、打包裁剪等误操作会在构建或启动阶段立刻暴露；
2. 让蓄意的删除无可辩驳：署名受 AGPLv3 的 Appropriate Legal Notice 保护（见 docker/NOTICE），在传达或网络提供服务前移除即构成许可违约，守卫的存在使"是否故意移除"不再有模糊空间。

围绕这一目标，源码还做了几处刻意设计：

• 署名散布在多份独立文件中：unsloth_branding.py的模块 docstring 明确写道，归属声明"spread over several independent files on purpose, so a shallow find-and-replace cannot white-label the image"——一个全局替换不可能同时命中所有分散点。
• 全文本、可读为主：除 logo 的 base64 blob 外，所有受检内容都是明文可读文本，便于人审与自动化校验。
• PHRASE 双端字节一致：Python 与 TS 两侧必须保持同一个完整句子，构建守卫会在 bundle 中检索它；about.ts又通过data-unsloth-attribution属性把它原样烙进 bundle，形成双重保障。
• 构建期资产迁移与锁定的配合：docker/Dockerfile.studio 在构建时替换 favicon/logo/login.html、复制 sloth 贴纸，并执行jupyter labextension disable/lock关闭原生 logo 与 splash 扩展、锁定unsloth-jupyterlab，确保镜像里唯一的 logo/splash 提供者就是品牌化实现。

七、镜像构建、运行与校验失败的运维视角

从使用侧看，这套机制与日常构建/运行命令直接相关。docker/Dockerfile.studio 文件头给出了标准用法：

# 构建（本地，基于已发布 base 或由 docker/Dockerfile 构建） docker buildx build --build-arg BASE_IMAGE=unsloth/unsloth:core \ -f docker/Dockerfile.studio -t unsloth/unsloth:studio docker/ # 运行 docker run --rm --gpus all -p 8000:8000 -p 8888:8888 \ -v $HOME/.cache/huggingface:/workspace/.cache/huggingface \ -v unsloth-studio:/opt/unsloth-studio unsloth/unsloth:studio

镜像默认暴露 8000（Studio）、8888（JupyterLab）、22（sshd）三个端口；JupyterLab 密码由JUPYTER_PASSWORD环境变量指定，未设置则打印随机密码。

如果镜像构建或启动时品牌资产出了问题，你会在两个地方看到那条横幅式错误：

• 构建阶段：--verify失败导致整个docker build中断，日志末尾是ERROR: Unsloth Docker Studio attribution / license integrity check failed.及逐条问题列表；
• 容器启动阶段：unsloth-studio-launch拒绝拉起 supervisord，--verify的非零退出码阻断容器启动（对应 docker/studio_launch.sh 第 143 行）。

排查时可借助 CLI 的两个定位参数手动复现：python -m unsloth_branding --verify --venv-share <路径> --jupyter-server-dir <路径>，以便在不完整环境中精确指出缺失的资产路径。

八、测试与持续验证

仓库用自动化测试固化了这一机制的行为，最直接的是 tests/python/test_docker_studio_rocm_jupyter.py：

• 它通过importlib.util.spec_from_file_location直接加载仓库中的unsloth_branding.py（BRANDING = DOCKER / "jupyter" / "unsloth_branding.py"），调用resolve_paths(...)并断言 labextension 恰好落在守卫所检查的位置（test_the_labextension_lands_where_the_branding_guard_looks）；
• 断言构建流程中确实包含-m unsloth_branding --verify字样（test_the_branding_chain...）；
• 还比较 ROCm 与 CUDA 两种 Studio 镜像的品牌链完全一致（test_the_branding_chain_matches_the_cuda_studio_image），确保双后端镜像携带同一套署名与校验逻辑。

这说明品牌守卫不是一次性脚本，而是随 CI 持续验证的、跨镜像变体一致的契约。

总结

Unsloth Docker Studio 的品牌与许可署名保护，本质上是把 AGPLv3 的 Appropriate Legal Notice 义务工程化为可自动验证的资产清单：规范字符串以 Python/TypeScript 双源维护，PHRASE字面量字节级同步；署名分散在登录页、labextension（About/splash/logo）与主题配置等多个独立文件中；unsloth_branding.py作为构建期 CLI 校验器、容器启动前门卫与 jupyter_server 运行时扩展三合一守卫，在构建、容器启动、JupyterLab 加载三个时机反复确认署名未被剥离。它刻意以"绊线"而非"锁"自居——不阻止 fork 者修改，只让意外删除大声失败、蓄意删除无可抵赖。理解这套机制，既有助于镜像维护者合规地二次分发，也为安全审计者提供了一条"品牌/许可完整性是否被篡改"的快速验证路径。

• 人工智能
• 大模型
• 微调
• LoRA
• 模型优化
• 模型量化
• 强化学习