Kiln 提供 Lite、Core 和 Full 三个版本。三者使用相同的配置模型和原生媒体模块，区别在于管理功能、是否内置 FFmpeg，以及资源预算。
三个变体
| 维度 | Lite | Core | Full |
|---|---|---|---|
| 默认 packager | native |
native |
auto |
| 原生 HLS / DASH | 是 | 是 | 是 |
| FFmpeg | 不包含 | 不包含 | 内置 9.0 |
| 登录、M3U、播放 | 是 | 是 | 是 |
| SQLite 数据库 | 否 | 是 | 是 |
| 管理控制台与管理 API | 否 | 是 | 是 |
| EPG | 否 | 是 | 是 |
| OTLP 与 pprof | 否 | 是 | 是 |
| 基础镜像 | scratch |
Alpine | Alpine 加 FFmpeg |
| 定位 | 固定配置的低资源播放节点 | 完整的纯原生部署 | 完整的兼容部署 |
kiln:latest 是同版本 kiln:full 的别名，不是第四种运行时实现。
镜像提供的默认 packager 通过 KILN_DEFAULT_PACKAGER_ENGINE 注入，只在配置里没有写 [packager].engine 时生效。同一份配置不会因为换了镜像标签而悄悄改变行为，详见 媒体引擎。
构建与分发方式
Core 与 Full 使用完全相同的标准构建入口和编译参数，产出的应用二进制大小一致，差别只有镜像里是否存在 ffmpeg 以及注入的环境变量。Lite 是唯一一个在编译期就不同的变体：
# Core 与 Full 共用的标准构建
CGO_ENABLED=0 go build -trimpath -o kiln ./apps/server
# Lite 通过构建标签换掉整个入口与控制面
CGO_ENABLED=0 go build -tags=lite -trimpath -o kiln ./apps/serverlite 标签让编译器选中另一份 main，SQLite、管理控制台、EPG、遥测导出这些控制面依赖根本不会进入依赖闭包，因此 Lite 不是“把功能关掉”，而是没有编译进去。
三个镜像对应 Dockerfile 里的三个 target：
docker build --target lite -f deploy/docker/Dockerfile -t kiln:lite .
docker build --target core -f deploy/docker/Dockerfile -t kiln:core .
docker build --target full -f deploy/docker/Dockerfile -t kiln:full .Core 的多架构构建覆盖 linux/amd64、linux/arm64、linux/arm/v7 与 linux/arm/v6。二进制分发方面，安装脚本的 --lite 只提供 Linux 构建，其它平台安装的都是完整版，参见 安装脚本。
Lite 的边界
Lite 的公开接口只有 /healthz、/readyz、/v1/auth/login、/v1/playlist.m3u 和 /v1/play/*。它不创建 SQLite，data_dir 里只有自动生成的登录密钥和临时媒体文件，因此可以配合只读根文件系统运行。
配置里出现下面任何一项时，Lite 会在启动时直接拒绝，而不是静默忽略：
- 全局或任一频道的 packager 引擎不是
native - 存在已启用的 EPG 源
- 配置了 OTLP 导出端点
- 启用了 pprof
Lite 的固定资源预算
Core 与 Full 按容器实际内存挑选内部档位，Lite 则不管宿主机多大，都固定使用同一组预算，以保证跨机器的低内存特征一致：
| 生效值 | Lite | 对比：受限档位的 Core / Full |
|---|---|---|
| Go 软内存目标 | 24 MiB | 48 MiB |
| 原生 inflight 上限 | 24 MiB | 32 MiB |
| 单段上限 | 20 MiB | 20 MiB |
| 启动 / 预取流水线 | 1 / 1 | 1 / 1 |
| GOGC | 50 | 75 |
| 主动回收媒体页缓存 | 是 | 是 |
这组数字在 resource_mode 为 auto 和 constrained 时都成立，只有 performance 会让 Lite 完全退出自适应、改用配置里写的值。预算是 Go 堆与媒体工作集的软目标，不是容器总 RSS 的保证。
性能对比
下面的数字来自仓库内的受控实测，测试日期 2026-07-23，架构 linux/arm64，三个变体在相同宿主机、相同容器限制（1 CPU、128 MiB）、相同配置和相同媒体 fixture 下各跑 5 轮、共 100 次完整链路。
体积（MB 为十进制字节）：
| 变体 | Docker 本地镜像 | Kiln 二进制 | 额外 FFmpeg |
|---|---|---|---|
| Lite | 3.84 MB | 9.31 MB | 无 |
| Core | 13.27 MB | 22.22 MB | 无 |
| Full | 66.41 MB | 22.22 MB | 109.57 MB |
内存与链路稳定性：
| 变体 | 负载后 RSS 中位数（范围） | 成功链路 | OOM |
|---|---|---|---|
| Lite | 13.01 MiB（11.48 到 13.33） | 100 / 100 | 0 |
| Core | 25.17 MiB（25.11 到 25.27） | 100 / 100 | 0 |
| Full | 25.21 MiB（21.03 到 25.35） | 100 / 100 | 0 |
结论性的几条：
- Lite 的镜像比 Core 小 71.1%，比 Full 小 94.2%；二进制比 Core 与 Full 小 58.1%。
- Lite 的负载后 RSS 中位数比 Core 低 48.3%、比 Full 低 48.4%。这个下降来自运行时结构和预算共同变化，不只是二进制变小。
- Core 与未启动 ffmpeg 子进程的 Full 在原生路径上没有可解释的内存差异，两者相差约 0.14%。把 ffmpeg 放进镜像主要增加分发与磁盘成本。
- 官方验收里，Lite 在 1 CPU、64 MiB 的容器中完成 10 次链路，负载后 RSS 为 12.80 MiB，无 OOM。
测试环境与方法
宿主机为 Apple M1 Max（10 核、64 GiB），容器运行在 OrbStack 的 linux/arm64 环境，每个 Kiln 容器限制 1 CPU、128 MiB，swap 与内存相同，根文件系统只读，移除全部 Linux capabilities 并启用 no-new-privileges。三个变体按交叉顺序执行，以减弱固定顺序带来的缓存偏差。
工作负载使用仓库内的确定性媒体 fixture 而不是外部源站：320×180、25 fps、4 秒、约 120 kbit/s 的 H.264 测试图，配 32 kbit/s 双声道 AAC 测试音。每次迭代完整抓取加密 DASH 转 HLS 的 master、media、init 与分片，以及 HLS 代理的 playlist、init 与分片。Full 默认走 auto，但该 fixture 可由原生引擎完整处理，日志确认为原生路径且进程表中没有 ffmpeg 子进程，因此这组数字隔离的是变体本身的开销。
内存以每轮第 20 次迭代后 PID 1 的 VmRSS 快照为准。cgroup 的 memory.peak 同时记账匿名内存和文件页缓存，跨轮波动明显更大，只用于确认容器边界与 OOM 安全性，不用于变体之间的排名。每个指标报告 5 轮的中位数与范围；样本量小，只作描述性比较。
复现
先从目标修订构建并检查镜像，检查会验证变体标签、默认 packager、非 root 用户、ffmpeg 边界以及 Lite 的依赖闭包和体积上限：
make docker-images docker-verify-images单轮比较使用 deploy/docker/native-media-runtime-smoke.sh，通过环境变量固定容器限制、迭代次数和预期资源档位：
KILN_SMOKE_CHECK_RESOURCES=1 \
KILN_SMOKE_CPUS=1 \
KILN_SMOKE_MEMORY=128m \
KILN_SMOKE_ITERATIONS=20 \
KILN_SMOKE_VARIANT=lite \
KILN_SMOKE_EXPECTED_PROFILE=lite \
sh deploy/docker/native-media-runtime-smoke.sh kiln:lite-localCore 与 Full 把 KILN_SMOKE_VARIANT 和 KILN_SMOKE_EXPECTED_PROFILE 换成 core / full 与 compact。正式复测至少重复 5 轮并轮换执行顺序，跨提交比较时还要保持 Docker 版本、宿主负载、容器限制、fixture 和迭代数不变。真实频道的验收另有 scripts/live-performance.sh，用于测量冷启动、首个 manifest、吞吐实时比、RSS 与 CPU。
怎么选
选 Lite
节点只需要登录、M3U 和播放，频道完全由原生引擎处理，配置用文件管理不需要运行时数据库和管理台，并且资源预算、镜像拉取速度或攻击面是首要考虑。
选 Core
需要完整的管理控制台、数据库、EPG 和观测能力，并且已经确认所有 DASH 频道都能被原生引擎处理。相比 Full 显著减少镜像体积，但在同样的原生路径上不要指望进程内存明显更低。
选 Full
输入兼容性优先，需要保留 ffmpeg 回退。原生可处理时它的内存表现与 Core 接近；真正发生回退时，容器限制要按“Kiln 进程加 ffmpeg 子进程加页缓存”来设。
不确定时从 Full 起步，把频道跑通、确认日志里都是原生路径之后再换 Core；需要边缘播放节点时再单独部署 Lite。三者共用同一份配置模型，迁移只需要换镜像，参见 Docker 部署。
Windows
Windows 发行版不含 ffmpeg，也没有 Lite 构建。[packager].engine 为 auto 时会自动走原生引擎，确实需要兼容回退时自行安装 ffmpeg 并加入 PATH。其它方面 Windows 版与完整版一致，包含管理控制台、数据库、EPG 与观测能力，安装与服务注册见 二进制安装。