「100万积分」的80万利润说法:深读 Liblib/LibTV 的「健身房模式」

「100万积分」的80万利润说法:深读 Liblib/LibTV 的「健身房模式」

精读小卡拉米对 Liblib/演语科技商业模式的观察,区分「用不完的积分」与「整合多模型、少折腾」两条收入逻辑,并列出价格、消耗、上游依赖与利润占比仍缺的证据。

导读

当 AI 创作平台把多个模型、订阅和积分装进同一个入口,读者看到的是一个更省事的工具,平台面对的却是一张使用率和成本表。小卡拉米的观察笔记把这张表压缩成一个刺眼的例子:用户买了 100 万积分,实际只用 20 万,剩下 80 万被作者转述为利润。
这篇主文的价值,不在于它已经证明了 Liblib 的利润结构,而在于它把一个经常被「低价」「多模型」「一站式」遮住的问题摆到台面上:平台到底靠什么赚钱?靠用户用不完的额度,还是靠替用户整合模型、少开几个订阅、少切几个界面?两者的风险并不一样。
主文是《你以为 AI 公司靠技术赚钱?这家靠你算不清账》,作者为「小卡拉米的观察笔记」,发表于 2026 年 8 月 7 日 07:40。下面把主文的叙述、LibTV 官方页面公开的信息和编辑判断分开,重点看这门生意的两条收入逻辑能否被证据支持。

原文信息

项目主文给出的信息
主文《你以为 AI 公司靠技术赚钱?这家靠你算不清账》
作者与时间「小卡拉米的观察笔记」;2026 年 8 月 7 日 07:40 1
主体Liblib,也就是演语科技;文中把 LiblibAI、Lovart(星流)和 LibTV 放在同一家公司框架下讨论 1
文章类型商业模式观察,核心材料来自媒体对创始人陈冕采访的转引
作者的限制说明陈冕原话是媒体转引,并非作者本人直接采访;文末还注明 Liblib 是未上市一级市场公司,文章不构成投资建议 1
这几项限定决定了阅读方法:100 万、20 万和 80 万首先是主文转述的创始人说法,不是本文能够独立核验的审计数字;「Liblib 不训练大模型」以及「批发算力、零售体验」也是主文的商业判断,不应改写成公司公开披露的财务结论。

全文速读

主文先把 Liblib 放在模型厂商与普通用户之间。作者的描述是:Liblib 不自己训练大模型,而是从字节的火山引擎这类模型厂商处批量采购 API 调用权限,再把能力打包进 LiblibAI、Lovart 和 LibTV,用「订阅 + 积分」卖给普通用户。文章因此没有把 Liblib 写成一家靠单一模型取胜的公司,而是写成一个把上游算力重新包装成消费级体验的中间层。1
接着,作者用健身房年卡来解释积分生意。健身房并不假设每个会员都会把年卡用到极致,平台也不必假设每个用户都会把套餐额度全部消耗。主文转述陈冕的话:用户买了 100 万积分,实际只用 20 万,剩下 80 万是利润。作者把它概括成「健身房卖的是用不完,不是用得上」。1
但文章没有停在「信息差套利」上。作者随后承认,若用户都学会直接调用模型 API,这种中间商生意确实会变脆弱;可现实是,用户要同时订阅多个模型、切换多个界面,仍然有一笔「少折腾」的整合价值。于是同一个平台可能有两条腿:一条从用户没有算清楚额度中赚钱,另一条从模型整合、入口统一和切换便利中赚钱。
主文把前一条腿称为脆弱的「算不清账」的钱。模型厂商一旦把计费改成透明的按 token 消耗和预充值,用户就更容易知道自己买了什么、用了多少,平台从信息差中获得的空间会缩小。后一条腿则不依赖用户糊涂:即使用户算得清,也可能不想同时开五个订阅、维护五个界面。1
最后,作者把问题留在公司自己也没有公开拆清的地方:两条腿各占多少?陈冕被转述为承认「应用的时代还没有到来」,也就是说,今天的收入中可能混有窗口期红利,还不能全部叫作护城河。主文的结论不是判定 Liblib 的模式好或坏,而是提醒读者先分辨:一笔收入究竟来自真实整合价值,还是来自用户没有把账算明白。

功能细节拆解

1. 用户买到的不是一个模型,而是一层包装

主文的商业链条可以还原成四步:
  1. 上游模型厂商提供 API 或模型能力。
  2. Liblib 将多个能力放进自己的产品入口。
  3. 用户以订阅、积分或套餐的形式购买使用权。
  4. 平台用实际消耗、未消耗额度和整合服务的差异来形成收入空间。
这是主文的叙述框架,不是演语科技公开的财务报表。它解释了为什么作者反复使用「批发算力、零售体验」这句话:上游卖的是调用能力,下游买的是少选模型、少配参数和少切换工具的体验。1
LibTV 官方首页公开的产品语言是「只需一张画布连接你的多种创意想法」,页面同时列出「LibTV Agent」和「TV Show」入口。它能支持主文对「整合入口」的观察,但页面没有因此公开三项关键数据:不同模型的具体采购关系、积分消耗换算和每一类用户的利润率。2

2. 100 万、20 万、80 万:算术很清楚,利润口径还不清楚

按主文转述的例子,用户购买 100 万积分,实际消耗 20 万积分,未消耗 80 万积分。这个比例的算术没有难度,难的是「80 万是利润」到底采用了什么口径。
至少有四种账不能混在一起:
账目需要知道的字段主文是否给出
用户账套餐价格、积分有效期、实际消耗、过期规则、退款规则没有
上游账不同模型的 API 单价、批量折扣、最低承诺、失败调用是否收费没有
平台账获客、客服、存储、审核、研发、支付和风控成本没有
结果账用户拿到可用图片或视频所需的重试次数、人工筛选和后期时间没有
所以,80 万「未使用积分」可以被作者解释成利润来源,却不能直接等同于 80 万现金利润,更不能由此推导出公司的整体毛利率。只要套餐存在赠送积分、模型差异化定价、有效期、退款、重试或人工服务,这个比例就还不足以还原一位用户的真实单位经济模型。

3. 两条腿必须拆开看

主文对中间商两条收入逻辑的示意图
主文配图把中间商收入拆成「算不清账」和「帮你少折腾」两条腿;这是作者的解释图,不是演语科技公开的收入或利润拆分。1
第一条腿依赖信息不对称。用户不知道自己应该买多少,也不容易把积分换算成每张图、每秒视频或每次修改的成本。它的优点是变现直接,缺点是平台越透明,它越难维持;用户越熟练、批量调用越多,平台越可能面对成本失控或滥用风险。主文还特别提到脚本批量调用和「薅羊毛」会让平台从赚钱变成倒贴,这属于作者提出的风险判断,文章没有给出黑产规模或实际损失数据。1
第二条腿依赖整合价值。平台把多个模型放进一个工作流,用户可以在同一项目里试不同能力,减少注册、充值、切换和资产搬运。这条腿即便面对透明计费也可能成立,但它必须拿出相应的产品证据:模型选择是否足够多,切换是否真的省步骤,项目资产能否复用,最后拿到可交付结果是否更快。

4. 「低价」至少有三种含义

主文的标题和论述容易让人把「低价」理解成模型本身便宜。实际上,读者至少要区分三种价格:
  • 入口价格:注册、月卡或套餐看起来要付多少钱。
  • 调用价格:一次生成、一秒视频、一张图或一次修改实际扣多少积分。
  • 交付价格:拿到能发布、能交给客户的结果,平均要重试多少次、筛选多少候选、投入多少人工。
主文只提供了一个未独立核验的积分使用比例,并没有提供第二种和第三种价格。对 AI 视频创作者而言,第三种价格才决定平台是不是生产工具;对平台而言,第一种价格最容易被用来做推广。两者之间如果缺少账单和成功率,读者就只能知道「能买」,还不知道「值得持续买」。

目标用户场景

个人创作者:先算使用率,再看套餐价格

个人用户最容易被「多模型」「一站式」吸引,也最容易成为低使用率套餐的受益者或承担者。偶尔做一张海报、试一个短视频的人,可能在月末留下大量额度;高频创作者则可能迅速把额度用完,甚至因为重试和修改超出套餐。
因此,个人购买前应记录三件事:一个月实际要做多少个任务,每个任务平均重试几次,以及未用额度能否跨期、退款或转移。单看月费不能回答真实成本,单看「100 万积分」也不能回答能做多少条可交付内容。

工作室和代理团队:整合价值必须落到交接成本

对小团队来说,统一入口的价值可能比个人用户更高。一个项目需要多人共同处理脚本、画面、模型选择和素材交接,减少工具切换可能确实能省下沟通时间。
但团队采购要把「少折腾」换成可记录的字段:项目资产能否由成员共享,模型切换是否保留上下文,失败任务能否定位原因,谁能查看消耗,超额后如何计费。官方首页的画布、Agent 和 TV Show 入口说明了产品方向,却没有替团队回答这些交付问题。2

AI 服务商:平台的成本优势不能直接变成你的利润

如果创作者用 LibTV 或其它平台替客户做视频、图片、代运营,平台的积分套餐就会进入自己的报价表。此时最危险的误判是把平台的宣传价格直接当成项目成本:用户要为失败重试、选片、剪辑、声音、沟通和延期承担成本,而这些不一定显示在积分余额里。
主文的「两条腿」对服务商同样适用。你可能因为聚合工具少折腾而赚到服务费,也可能因为没有把每个项目的调用量算清楚,把利润留在平台的未使用额度或重试成本里。服务商必须保留自己的任务级账本,不能只看月度充值记录。

产品和投资观察者:先问两条腿各占多少

主文最适合给这类读者留下的不是「健身房模式很聪明」或「信息差一定不可持续」,而是一个拆分问题:如果把用户全部使用额度的成本、整合服务的价值和未使用额度分别核算,公司还剩多少利润?主文明确说这个比例没有被公司自己拆清楚,因此现在只能把它当成需要追问的商业假设。

竞品坐标

这篇主文没有用同一任务、同一模型、同一时长去横向测试视频画质,因此不能从它得出任何模型排名。更稳妥的比较方法,是按用户购买的东西来定位:
路线用户购买的主要东西优势关键风险与 LibTV 的比较字段
直接购买上游 API模型调用和更透明的用量账单账目可追踪,能按任务控制调用需要自己做工程、界面和模型切换API 单价、失败计费、开发与维护成本
单模型创作工具一个模型或一条成熟的创作流程上手简单,计费和能力边界较容易理解模型选择和迁移空间有限单任务成本、可用结果率、资产迁移
多模型聚合工作台多模型入口、项目管理和工作流整合少开订阅,减少界面切换积分换算复杂,容易把重试和人工成本藏起来模型覆盖、切换步骤、透明度、可交付成本
服务商或代理团队由别人替你完成筛选、制作和交付用户购买结果而不是工具报价和平台成本之间可能没有清楚边界平台成本、人工分钟数、客户交付价
这里的「竞品」不是只指某个视频模型,而是四种不同的付费路径。LibTV 如果要证明自己不只是一个把 API 重新打包的入口,就必须证明聚合和画布能让用户以更低的任务总成本拿到更稳定的结果。官方首页能证明它把画布、Agent 和 TV Show 放在产品入口上,但不能单独证明这一点。2

行业影响

第一,AI 创作平台的价格竞争会从「每次调用多少钱」转向「用户完成一次任务要花多少钱」。用户不只支付模型调用,还支付重试、等待、筛选、资产搬运和后期制作。若平台用统一积分把这些成本包在一起,低入口价会变得好看,真实任务成本却更难比较。
第二,积分制把使用率变成平台的重要经营变量。低使用率能留下未消耗额度,高使用率能带来更多收入,却也可能提高上游采购、风控和支持成本。平台既不希望普通用户大量浪费,也不能让批量滥用把高频调用变成亏损。真正值得追踪的不是某个套餐有多少积分,而是不同用户的消耗分布、重试率和退款率。
第三,聚合价值并不会因为计费透明就自动消失。用户愿意为少注册几个账号、少维护几套资产、少学习几种工作流付钱,这是正常的服务价值;问题在于,平台要把这笔价值和「用户没用完的额度」分开披露。两者混在一起,外部观察者就无法判断增长来自产品效率,还是来自使用率假设。
第四,LibTV 的产品方向已经公开表达为画布、Agent 和节目化创作入口,但商业模式的关键字段仍不在页面上。主文把产品功能和公司收入放在一张图里讨论,这对读者有启发,也容易让「产品有整合能力」滑向「公司已经证明盈利稳定」。2

待验证点

  1. 100 万积分的原始出处:主文说明这是媒体转引陈冕采访的原话,并非作者直接采访。需要找到那篇原始媒体报道,核对完整上下文、时间和「利润」的具体口径。1
  2. 80 万到底是哪一种利润:是未消耗额度对应的毛利空间、预计利润,还是采访中的口语化说法?没有成本、退款和服务费用,不能把它写成公司整体毛利率。
  3. 用户使用率分布:100 万和 20 万是个案、平均值还是某类套餐的代表?需要看到用户分层、过期率、续费率和高频用户占比。
  4. 积分的有效期与退款规则:这决定未使用额度能否在会计和经营上变成平台收入,也决定用户是否真的承担了「用不完」的损失。主文没有给出这些条款。
  5. 上游采购成本:不同模型的 API 价格、批量折扣、最低承诺和失败调用规则,都可能改变「批发算力、零售体验」的利润空间。主文没有提供合同或账单证据。
  6. 整合价值能否复现:需要用同一项目在单模型工具、直接 API 和 LibTV 之间测试,记录注册、切换、重试、资产迁移和人工收尾的时间。
  7. 黑产批量调用的实际影响:主文提出脚本批量调用会让平台从赚钱变成倒贴,但没有给出发生规模、平台损失或风控效果。这个判断应保持为风险假设。
  8. 两条腿的收入占比:主文明确提出了问题,却没有给出答案。只有把信息差收入与整合服务收入分开,才能判断「应用时代尚未到来」究竟是窗口期判断,还是对产品价值的保守描述。
  9. LibTV 在集团商业模式中的独立账目:主文把 LiblibAI、Lovart 和 LibTV 放在一起讨论,但没有拆出 LibTV 的用户数、收入、消耗和毛利。不能用集团叙述替代单产品证据。

原文关键句

「用户买了 100 万积分,实际只用 20 万,剩下 80 万是我们的利润。」
——主文称这是媒体转引陈冕采访中的话;原文同时提醒,作者并未直接采访陈冕。1
「健身房卖的是『用不完』,不是『用得上』。」
——作者对积分制的概括。它指出的是平台的使用率假设,不等于已经披露了平台的真实利润表。1
「应用的时代还没有到来。」
——主文转述陈冕的判断。作者据此把部分收入理解成窗口期红利,而不是已经稳固的护城河;这一步属于作者的解释,应与原话本身分开。1
读完这篇主文,可以留下一个比「健身房模式」更可操作的判断:先把用户未用额度、上游调用成本、平台整合服务和最终交付人工分开记账。Liblib/LibTV 是否靠技术赚钱,现有材料还不能回答;但这篇文章已经把读者该向平台追问的第一张账单列了出来。

이 콘텐츠는 채널이 자동으로 생성했습니다. 한 문장이면 Neodrop이 당신을 위해 계속 만들어 냅니다.

관련 콘텐츠