作者：熊猫不是猫 QAQ

家里想唱歌，最省事的办法当然是买一套成品点歌机，机器往电视旁边一放，插上线就能用，曲库和界面也都有人管。问题是这东西平时大概率在吃灰，买回来占一个位置不说，后面想加歌、换硬盘、整理曲库，很多时候还得顺着厂商的规则来，碰上会员、广告或者系统停更，心里多少有点膈应。

而熊猫作为 NAS 玩家，自然想法不一样了，既然家里已经有一台长期在线的服务器，电影、照片、音乐都放在里面，为什么不能顺手把 KTV 也塞进去？这次方案采用的是绿联 DXP6800 Pro，在 UGOS Pro 里用 Docker 部署 nasktv 项目，音源文件放在 NAS 硬盘中；雷鸟电视负责大屏播放；家里的手机连上 Wi-Fi 后能直接点歌，整套系统只在局域网里跑，不用每个人装 App，也不用把自己的曲库交给第三方平台。

主机核心

绿联 DXP6800 Pro 是这套方案的中枢，项目本身是需要用到一些硬件性能的，英特尔酷睿 i5-1235U 的处理器有 10 核 12 线程，项目需要用到的一些本地模型这点负载对它来说基本等于热身，且因为性能有亢余，当家里有人唱歌时，NAS 仍然可以继续下载、备份照片、跑影音服务，几个任务堆在一起也不至于互相抢得太难看。

DXP6800 Pro 给了双 10GbE 网口、两个 M.2 NVMe 插槽、双雷电 4、PCIe 扩展和最高 8K 60Hz 的 HDMI 输出。家庭 KTV 本身吃不了万兆，它真正方便的是，曲库初次入库时经常要搬几百 GB 甚至几 TB 文件，万兆局域网能明显缩短等待，加上熊猫自媒体的副业，家里还有剪辑电脑、工作站等多台终端，带宽不用全挤在一条线上。

背面接口

很多人看到六盘位，第一反应是 " 家用有必要吗 "。实话说，轻度用户确实没必要，但如果你是屯屯鼠，那还是有必要。影视和音频这类文件有个特点，单个文件看着不大，攒起来却很快，尤其是保留高码率 MV、演唱会版本和不同伴奏，一首歌几百 MB 很正常，再叠加电影、电视剧、全家照片和电脑备份，四盘位很容易从 " 够用 " 变成 " 又要换盘 "。

六盘位

六个 SATA 盘位的价值不是让你第一天就插满，而是留出后悔的空间。前期可以先上两块或三块盘，按自己的数据安全需求组阵列，怎么选要看数据价值，如果数据比较重要，那么千万别为了多一点可用容量把冗余全丢了。

硬盘选择

这次也是刚好准备给它加硬盘，顺便清一下灰，之前一直是插了 4 张盘，但随着东西越来越多也是感觉不够用了。

东芝 N300 硬盘

这次盘位里可以搭配东芝 N300 NAS 机械硬盘，CMR 传统磁记录，转速为 7200RPM，带旋转振动传感器，作为 NAS 专用盘，完全是按照 NAS 的 7 × 24 小时环境设计，对家庭曲库这种 " 大文件顺序读取为主，偶尔集中写入 " 的场景，CMR 比一些采用 SMR 的普通桌面盘更省心，阵列重建和持续写入时也更符合预期。

特写图

定位对路，容量选择多，持续读写也够用，这次熊猫准备了两张 8T。当然了，7200 转机械盘不可能完全没声音，夜深以后磁头寻道和盘体振动还是能听见，如果对噪声特别敏感，干脆把机器放到书房或弱电柜，硬盘是拿来干活的，不是靠 " 静音 " 两个字哄自己睡觉。

电视联动

电视在这套方案里不负责存歌，也不负责跑服务，充当的是大屏点歌台，NAS-KTV 把前端单独做成了 Web 容器，默认从 NAS 的端口访问，因此电视与服务器不需要是同一台设备，电视只要能通过浏览器访问局域网地址，就可以打开系统页面。

雷鸟电视

熊猫这里用的是雷鸟，当然，电视不一定非要是雷鸟，不过因为雷鸟和绿联本身就是有合作的，雷鸟的 TV 系统自带就有绿联云的小卡片，也算是一个加分项。

如果电视自带浏览器打不开全屏，或者播放某些 MP4 只有声音没有画面，可以换 BrowseHere 或其他 Chromium 内核电视浏览器，也可以接一个兼容性更好的盒子，实在不想折腾，拿笔记本接 HDMI 当播放端也行。

整个项目想要完整的体验，你就需要准备这些东西：装好 UGOS Pro 与 Docker 的绿联 NAS、能正常访问局域网的电视、本地歌曲文件，以及一套独立的麦克风。

容器部署

打开绿联的的 Docker 应用，切到项目选项选择创建项目，把下面 Compose 内容贴进去：

services: backend: image: ghcr.linkos/panda-995/nas-ktv-backend:${NASKTV_IMAGE_TAG:-latest} pull_policy: always ports: - "3000:3000" - "45678:45678/udp" volumes: - ./data/db:/app/data/db - ./data/songs:/app/data/songs - ./data/separation:/app/data/separation - ./data/uploads:/app/data/uploads environment: NODE_ENV: production PORT: "3000" JWT_SECRET: ${JWT_SECRET:-your-jwt-secret-change-me} DB_PATH: /app/data/db/nasktv.db SCAN_PATH: /app/data/songs SEPARATOR_SERVICE_URL: SEPARATION_OUTPUT_DIR: /app/data/separation SEPARATION_CONCURRENCY: ${SEPARATION_CONCURRENCY:-2} SEPARATION_AUTO_ENABLE: ${SEPARATION_AUTO_ENABLE:-true} HF_ENDPOINT: ${HF_ENDPOINT:- AI_ENABLED: ${AI_ENABLED:-false} AI_BASE_URL: ${AI_BASE_URL:- AI_API_KEY: ${AI_API_KEY:-} AI_MODEL: ${AI_MODEL:-gpt-4o-mini} AI_PARSE_CONCURRENCY: ${AI_PARSE_CONCURRENCY:-2} AI_AUTO_PARSE_AFTER_SCAN: ${AI_AUTO_PARSE_AFTER_SCAN:-true} depends_on: separator: condition: service_started restart: unless-stopped healthcheck: test: - CMD-SHELL - >- node -e "require ( 'http' ) .get ( ' r => process.exit ( r.statusCode === 200 ? 0 : 1 ) ) .on ( 'error', ( ) => process.exit ( 1 ) ) " interval: 30s timeout: 10s retries: 3 start_period: 10s separator: image: ghcr.linkos/panda-995/nas-ktv-separator:${NASKTV_IMAGE_TAG:-latest} user: "0:0" pull_policy: always volumes: - ./data/songs:/app/data/songs:ro - ./data/separation:/app/data/separation - ./data/separator-cache:/app/cache environment: TORCH_HOME: /app/cache DEMUCS_CACHE: /app/cache HF_ENDPOINT: ${HF_ENDPOINT:- SEPARATION_CONCURRENCY: ${SEPARATION_CONCURRENCY:-2} PYTORCH_INDEX_URL: ${PYTORCH_INDEX_URL:- restart: unless-stopped web: image: ghcr.linkos/panda-995/nas-ktv-web:${NASKTV_IMAGE_TAG:-latest} pull_policy: always ports: - "18080:80" depends_on: backend: condition: service_healthy restart: unless-stopped

关于文件夹映射，其中 data/songs 为歌曲存放目录，你可以部署之后再放文件，也可以提前放，同时熊猫在镜像中已经添加了加速源，所以不需要再担心速度问题。

歌曲命名依然建议做干净，例如 " 歌手 - 歌名 "，项目虽然预留了 AI 解析能力，但默认毕竟要外接 API，不开 AI 不能指望系统替你猜完所有乱七八糟的文件名，即便以后开启 AI，整齐的源文件也更方便迁移和备份。

这份配置最少要改一项 JWT_SECRET，这里需要填写一个 32 位的长随机字符串，可以直接让豆包之类的帮你生成，AI 曲名解析默认关闭，需要时再把 AI_ENABLED 设为 true，补上 AI_BASE_URL、AI_API_KEY 与 AI_MODEL 就行。

项目拉取

保存并启动项目，Docker 会拉取 Backend、Separator 和 Web 三个镜像，三个容器显示正常启动后，再用 class="img_desc">

登录界面

仪表盘会显示当前的曲库数量、歌手数、播放次数以及活跃房间，下面还有完整的 AI 解析和人声分离队列以及歌曲解析，相当于 KTV 的中控后台界面。

仪表盘

歌曲管理、去重和歌手管理这些就不用看了，很正常播放器的管理没有区别。

歌曲上传或者放到曲库之后首先看 AI 解析，配置好 AI 之后 AI 会根据提示词根据歌曲的内容进行解析歌曲名和歌手，还会进行流派分类等操作，最终这个解析并不会写入曲库中，而是作为 json 存在项目本地。

AI 解析

除了解析，人生分离就是最重要的了。一般来说个人找到的音源是默认没有人声伴奏分离的，所以这时候就要借助大模型来将人生和伴奏进行分离，首先在 GPU 管理这里我们能看到硬件信息和 PyTorch 状态，如果你有外接显卡，那么这里就能检测到你的外接显卡并用 GPU 版本模型来加速人声分离，如果没有那么就会采用 CPU 版本。

模型管理

点击人声分离，这时候项目会调用你绿联 NAS 的本地 CPU 能力进行模型处理，再将分离的人声伴奏进行转码，熊猫的绿联 DXP 6800Pro 一首歌按照标准模型处理大概用时 50 秒左右。

人声分离

分离之后可以点击后面的试听，这时候就能看到歌曲分成了原唱音频、伴奏音频、人声音频，且分离效果非常不错，如果想要更精细，可以选择更好的模型进行分离，不过耗时会更久一点。

分离结果

分离配置在系统设置界面可以找到，同时需要注意右下角这个 H5 手机点歌，需要改成你的 NASIP 地址和端口然后加上 /h5/ 的后缀，后面会用到。

连接配置

在电视上安装 NASKTV 应用，下载地址在 github 搜索项目 Panda-995/NAS-KTV，按页面提供二维码扫码，这里手机一定要是同一局域网，这时候手机就会弹出项目的后端配置界面，输入我们的后端地址，也就是 class="img_desc">

点歌界面

这里熊猫的歌曲文件没有内嵌歌词，如果你有 lrc 歌词文件，也可以在后端的歌曲管理中去上传，这样桌面就能显示歌词了。

歌词上传

手机扫码之后的点歌界面长这样，除了支持点歌，也能作为遥控器使用，支持单独调节伴奏、人声音量，同时还提供了各种环绕声效果，也支持升调降调操作，基本是满足 K 歌的需求了。

手机端界面

这套方案落地后，最省心的是曲库确实在自己手里，当然，它没有商业 KTV 那种现成的海量在线曲库，第一次整理会花时间，人声分离更不是点一下马上完成，说白了，这是一套 " 愿意前期折腾，换后期自由 " 的方案。

写在最后

这套方案不一定适合所有人，它需要整理曲库，也需要花一点时间处理 Docker 路径、应用兼容，但折腾完之后，家里的照片、电影、音乐、KTV 都能围着同一台 NAS 运转，这种 " 东西是自己的，规则也由自己定 " 的感觉，确实挺舒服。

以上便是本次分享的全部内容了。如果你觉得还算有趣或对你有所帮助，不妨点赞收藏，最后也希望能得到你的关注，咱们下期见！

关注熊猫

本文来自什么值得买网站（www.smzdm.com）。