Python Streamer-Sales 基于大模型的AI卖货主播生成工具

直播电商的脚本撰写，大概是每个运营团队都绕不开的体力活。一件新品上架，要写卖点、要憋单、要互动话术，还得根据不同的商品类目调整语气风格。更麻烦的是，当商品库有几百个 SKU 时，人工写脚本的速度根本追不上上播的节奏。Streamer-Sales 这个项目试图解决的就是这个问题：给定商品信息，让大模型自动生成一套有“带货感”的解说词，并且把语音合成、数字人视频、实时信息查询这些环节串成一条可运行的流水线。

项目基本信息

信息项详情
项目名称Streamer-Sales
GitHub地址https://github.com/PeterH0323/Streamer-Sales
项目描述Streamer-Sales 销冠 —— 卖货主播 LLM 大模型，一个能够根据给定的商品特点从激发用户购买意愿角度出发进行商品解说的卖货主播大模型。内含详细的数据生成流程，另外还集成了 LMDeploy 加速推理、RAG检索增强生成、TTS文字转语音、数字人生成、Agent 使用网络查询实时信息、ASR 语音转文字、Vue 生态搭建前端、FastAPI 搭建后端、Docker-compose 打包部署
作者PeterH0323
开源协议GNU Affero General Public License v3.0
开源状态公开状态
LanguagesPython / Vue / TypeScript / Dockerfile
支持平台Linux / Windows / macOS / Web
最后更新2026-10-24

一、项目介绍

Streamer-Sales 的核心是一个在 InternLM2 基础上微调而来的 7B 对话模型，项目内部给它起了个名字叫“乐乐喵”。和直接拿通用大模型写带货文案不同，这个模型在训练阶段就灌入了特定的人设和任务范式：主播会称呼观众为“家人们”，语气偏向可爱活泼，并且在组织语言时会刻意放大商品的亮点价值来激发购买欲。

但仅仅有一个会写文案的模型，并不足以构成一个“可用”的卖货系统。作者把整条链路做成了模块化的组合：模型生成文案之后，TTS 模块把文字变成带感情的语音，数字人模块再根据语音生成对应的口播视频。如果观众提问涉及快递时效或天气信息，Agent 模块会调用外部 API 实时查询并融入回答。RAG 模块则让主播在解说时参考商品说明书，这意味着上架新品不需要重新微调模型，只要更新知识库就能让话术贴合实际参数。

从 v0.9.0 开始，项目还加入了基于 Vue 和 FastAPI 的后台管理系统，包含商品管理、直播间配置、数字人管理等页面，接口采用 RESTful 规范并带有 JWT 鉴权。这使得它不再只是一个演示 demo，而具备了小团队内部试用的基本形态。

二、核心优势

数据生成流程完全透明。很多微调项目的 README 只告诉你“我训了一个模型”，但对数据从哪来、 prompt 怎么设计、格式如何清洗闭口不谈。Streamer-Sales 把数据集生成的脚本和配置文件都摊开在 dataset/ 目录下，conversation_cfg.yaml 里定义了主播性格、商品品类、用户可能提问的问题模板，你可以照着这套流程替换成自己的品类重新生成数据。

RAG 带来的“免微调上新品”能力是实用层面最大的亮点。传统做法是每上一个新品就得准备数据、重新训练或至少做一次增量微调。RAG 方案下，你只需要把商品说明书喂给系统，主播回答时就会自动检索相关段落作为参考。对于商品迭代快的团队，这个设计省掉的算力成本和时间成本相当可观。

推理加速做了两档适配。项目接入了 LMDeploy，开启 KV cache 和 Turbomind 之后推理效率相比原生 HF 推理有明显提升。更关键的是它提供了 4bit 量化模型，6.5G 左右的显存占用让 24G 显卡（如 RTX 4090）也能跑起来，大大降低了本地体验的门槛。

部署形态灵活。早期版本是前后端融合的 Streamlit 单页，后来逐步演进到前后端分离，并支持 Docker-Compose 编排。你可以选择一键拉起整套服务，也可以按需关掉数字人、ASR 等吃显存的模块，只跑文案生成和 TTS 这条最小链路。

三、适用场景

电商运营团队的脚本预生产。如果你的团队每天需要产出几十条商品口播稿，人工从零写起效率很低。可以用这个系统批量生成初稿，运营人员再基于初稿做修改和调整，把精力从“憋词”转移到“调优”上。

AI 应用开发者的学习样本。这个项目在架构上覆盖了 LLM 微调、RAG 检索、TTS、数字人驱动、Agent 工具调用、前后端分离、容器化部署等多个环节，而且每个环节的代码都是开源的、可读的。想了解一个完整 AI 应用从模型到产品的链路长什么样，这是一个不错的参照物。

直播场景的自动化尝试。虽然目前距离真正的实时互动直播还有距离，但对于录播式的商品讲解视频、无人值守的循环直播、或者夜间时段的补充内容，用数字人加生成话术的方式可以做到低成本覆盖。

注意：如果你期望的是开箱即用的 SaaS 产品，点开就能上播卖货，那 Streamer-Sales 会让你失望。它本质上是一个需要自己部署、自己配环境、自己调参的技术项目，显存要求、模型下载、依赖冲突这些门槛一个都不会少。

四、安装教程

环境准备

先确认你的机器满足最低要求。显卡方面，如果使用 4bit 量化模型，24G 显存（如 RTX 3090 / 4090）即可运行；如果使用原版 7B 模型，建议 40G 显存以上。系统建议 Ubuntu 20.04 及以上，Python 版本 3.10 左右。

需要提前装好 Git 和 Conda。如果打算用 Docker 部署，Docker 版本建议 24 以上。

获取代码与创建环境

git clone https://github.com/PeterH0323/Streamer-Sales.git
cd Streamer-Sales

conda env create -f environment.yml
conda activate streamer-sales

pip install -r requirements.txt

environment.yml 里已经锁定了大部分核心依赖的版本，这比纯靠 pip install -r requirements.txt 要稳妥一些，能避开不少版本冲突的坑。

模型权重预下载（强烈建议）

项目启动时会通过 ModelScope 自动拉取权重，但国内网络环境下这一步经常超时或者卡住。weights/ 目录下有一个 README，列出了 LLM、TTS、数字人、ASR、RAG 各模块需要的模型文件和存放路径。建议先按照清单手动下载好再启动，首次运行的等待时间会短很多。

配置修改

主要配置文件在 server/web_configs.py。几个需要关注的参数：

  • POSTGRES_PASSWORD：如果使用数据库功能，需要和你本地 PostgreSQL 的密码一致
  • 功能开关：ENABLE_RAG、ENABLE_TTS、ENABLE_DIGITAL_HUMAN、ENABLE_ASR，显存紧张时可以先关掉数字人和 ASR
  • Agent 密钥：快递查询和天气查询的 API Key 通过环境变量注入，没有的话先跳过，不影响文案生成核心功能

启动方式选择

Docker-Compose（快速体验后端）：

docker-compose up -d

适合只想看看文案生成和 TTS 效果的情况，省去逐个配环境的麻烦。

宿主机分服务启动（完整体验）：

按照项目文档的说明，LLM 服务、TTS 服务、数字人服务、ASR 服务、RAG 服务、后端 API、前端各开一个终端依次启动。这种方式能用到完整的后台管理界面，也方便单独调试某个模块。如果显存不够跑全部服务，可以先只启动 LLM 和 TTS，把数字人和 ASR 留到后面再加。

五、使用示例

场景：为一把人体工学椅生成带货文案

假设你上架了一款人体工学椅，卖点是“腰托可调”“网布透气”“扶手四向调节”。在后台的商品管理页面填入这些信息，或者直接调用模型接口，让主播生成一段解说。

用 Python 直接调用模型的一个简化示例如下（实际接口以项目最新文档为准）：

from lmdeploy import pipeline, TurbomindEngineConfig

# 使用 4bit 模型以适配 24G 显存
backend_config = TurbomindEngineConfig(model_format='awq', tp=1)
pipe = pipeline('HinGwenWoong/streamer-sales-lelemiao-7b-4bit', backend_config=backend_config)

prompt = """你是一个卖货主播，请根据以下商品信息生成一段口播文案：
商品：人体工学办公椅
卖点：腰托可调、高弹网布透气、扶手四向调节、适合久坐人群
要求：语气活泼，称呼观众为家人们，突出对腰部健康的改善。"""

response = pipe(prompt)
print(response.text)

模型会输出类似“家人们看过来，这把椅子真的拯救了我的老腰……”的文案。你可以直接把这段文字拿去用，也可以把生成的文本传给 TTS 模块进一步合成语音。

添加新商品并更新 RAG 知识库

如果不想每次都在 prompt 里粘贴卖点，更工程化的做法是通过 RAG 流程：

  1. 把商品说明书（文本或从图片 OCR 提取的文本）放入指定目录
  2. 运行 RAG 初始化脚本，脚本会自动切分文本并写入向量数据库
  3. 之后在对话中提及该商品，主播的回答会自动检索说明书中的相关内容

这样上架一个新品的时间成本从“准备数据 + 微调或调 prompt”压缩到了“上传文档 + 跑一次索引”。

显存不够时的取舍

如果你的显卡只有 24G，建议的启动组合是：LLM（4bit 版）+ TTS + RAG，关掉数字人和 ASR。这套组合的显存占用大约在 15G 左右，足够完成“输入商品信息 → 生成文案 → 合成语音”的闭环。数字人生成单独占用 5G 左右显存，可以在需要产出视频时再临时开启。

六、常见问题

启动时模型下载卡住或报 ConnectionError

这是最常见的问题，根源是 ModelScope 或 HuggingFace 的网络连通性。解决方案是提前手动下载权重：打开 weights/README.md，里面列出了每个模块需要的模型仓库地址和本地存放路径，用 git lfs 或者 ModelScope 的 SDK 下载后按对应目录放好。项目启动时会检测本地文件，存在就不再重复下载。

24G 显卡跑原版模型爆显存

默认配置使用的是非量化的 7B 模型，需要约 16G 显存仅给 LLM，加上 TTS 和 RAG 之后 24G 会很紧张。切换到 4bit 模型，LLM 部分降到 6.5G 左右，留出足够空间给其他模块。具体启动命令在项目部署文档中有说明，注意修改模型路径或名称。

前端页面能打开但接口报 500

先检查后端服务的日志。常见原因包括：数据库没有初始化（PostgreSQL 需要先建库）、某个依赖服务的端口没启动（比如 TTS 服务没有运行但前端触发了语音生成请求）、或者环境变量中缺少必要的密钥。从 v0.9.0 起接口加了 JWT 鉴权，如果是自己改过前端代码，确认 token 的携带方式是否正确。

生成的文案“AI 味”太重，不够自然

微调模型的表现很大程度上取决于训练数据的质量。项目默认的数据集是用商用大模型生成的，如果你有自己的历史直播脚本，可以替换 conversation_cfg.yaml 中的产品信息和话术模板，重新跑一遍数据生成和训练流程。不过对于大多数试用场景，更实用的做法是在 prompt 里加入具体的风格示例，让模型模仿而不是自由发挥。

数字人生成的视频口型对不上

数字人模块依赖 ComfyUI 的 workflow，项目开源了对应的流程文件。口型同步问题通常出在音频和驱动视频的时长匹配上。如果 TTS 生成的语音比模板视频长，就需要做截断或加速处理。检查 weights/ 中数字人相关模型的版本是否与代码匹配，版本错位也会导致生成异常。

七、总结

Streamer-Sales 是一个野心不小的项目。它把“让大模型卖货”这件事拆解成了文案生成、语音合成、数字人驱动、实时信息检索等多个可独立工作的模块，再用前后端和容器化把整条链路串起来。从技术学习的角度，它的代码结构和数据生成流程有不错的参考价值；从实际使用的角度，RAG 免微调上新品和 4bit 量化适配 24G 显卡是两个实打实的实用设计。

但也要清醒地看到，它目前更适合作为“原型验证”和“二次开发的基础”来使用。部署门槛、显存要求、以及各模块之间的联调复杂度，决定了它离开箱即用的商业产品还有距离。如果你有一个小团队、有一张 24G 以上的显卡、愿意花一个周末折腾环境，它能让你直观感受到一个多模块 AI 应用从代码到运行的全貌。如果你只是想要一个写带货文案的工具，直接调商用大模型的 API 可能是更省事的选择。