中鼎 Token 工厂业务 投资人交流纪要

2026-09-07 16:46:055

目录


一、会议核心信息


二、公司转型背景与能力基础


三、Token 工厂定位与商业模式


四、T客户合作背景与合作机制


五、推理效率技术与集群运行逻辑


六、测试验证、设备到货与投产节奏


七、数据中心与服务器安排


八、团队、组织与业务归属


九、资本投入、融资安排与财务口径


十、价格判断与中长期业务方向


十一、会议中尚未明确的关键事项


十二、原文口径冲突与转写待确认


十三、详细问答纪要





一、会议核心信息




一句话概括


会议将该业务定位为“Token 工厂”:核心不是单纯出租 GPU 算力,而是在相同硬件和模型条件下,通过推理调优、集群调度与显存管理提高
Token 产出,并围绕实际产出与客户开展动态结算。







1.1 关键事项速览



事项





会议内容








转型起点





会议称董事长在 2022 年已开始推动 IT 能力建设并招募核心负责人;随后由 ERP、制造业信息化逐步走向 AI。







当前业务定位





不把项目定义为纯算力租赁,而是以“同卡多产 Token”为核心的端到端闭环。







核心客户





现阶段主要客户为 T客户;T客户自身算力供给不足,需要外部合作方同步建设。







T客户需求口径





会议对T客户推理需求给出快速增长的口头预期,具体数字未获正式文件确认。







合作结算





按实际产出、模型和服务要求动态定价;会议讨论过利润保底与超额分成,但具体公式未披露。







合同约束





可约定最低供给量和 SLA;若公司未达到最低供给要求,公司承担违约责任。客户最低采购责任在会议中没有得到同等清晰的确认。







技术路径





围绕 Prefill 计算单元与 Decode 的 HBM 带宽,重点讨论连续批处理、缓存复用、KV Cache 分页、权重量化,以及 PD 分离和集群“超卖”。







验证状态





会议称已完成小规模测试;大规模部署仍需在四季度设备到位后验证,且明确表示“小规模跑通不等于大规模一定跑通”。







项目节奏





设备分批到货,四季度启动千卡级组网和调优,目标在春节前完成首轮闭环,再向后复制。







团队情况





团队目前 30 多人,以 GPU 加速、模型调优为主,运维人数较少。







数据中心





短期租赁合适机房先运行;中期自建,会议称自建周期通常为
1 年至 1 年半。







资本投入





会议多次以 200 亿元总投入讨论项目规模;常规融资结构口径为
20% 自有资金、80% 融资,资金成本约 2.6%—2.8%。







财务粗测





按 2027 年全年跑满的口头假设,会议给出 100 亿元营收、60 亿元净利润,并称成本约 40 亿元、折旧约 30 亿元。







中长期方向





在基础
Token 之上叠加制造业采购、财务、销售、制造、质量管理等场景,形成智能体和解决方案。







1.2 会议反复强调的三项成立条件

1. 能投入并能拿到卡。 会议认为,只有具备真实资金投入和服务器采购能力,项目才能启动。


2. 有高质量客户共同推进。 会议将T客户的需求、模型协同和业务配合视为重要条件。


3. 同样硬件能够产出更多 Token。 会议认为这是最关键的差异,直接影响收入和利润。


1.3 本次会议最核心的待验证点

会议将四季度至春节前视为从“团队与方案”走向“真实集群结果”的关键阶段。届时需要验证的不是单台服务器能否运行,而是千卡级集群能否稳定组网、完成模型部署和调优,并在实际负载下兑现小规模测试所体现的吞吐提升。


合同层面,会议对公司最低供给量、SLA 和违约责任的描述较清楚;但T客户是否承担刚性的最低采购量或最低付款责任,会议没有给出同样明确的回答。第一场交流还直接指出,若客户的采购意向仅停留在口头层面,则没有约束力。


二、公司转型背景与能力基础
2.1 转型并非在本轮 AI 热度出现后才开始

会议称,董事长在 2022 年已经希望加强公司的 IT 能力,并招募核心负责人加入。当时的直接目标是把 IT 做好,并非一开始就以当前的 Token 工厂为明确目标。核心负责人此前长期从事 ERP 和制造业信息化,对制造业流程较为熟悉。


公司的路径被描述为从 IT、ERP 和制造业数字化逐步走向 AI。会议认为,2024 年以前 AI 业务的实际落地仍有限,2025 年初以后行业变化加快,公司也在团队、技术、市场和内部平台建设方面持续准备,最终决定正式进入。


2.2 核心负责人的经历与业务衔接

会议介绍,核心负责人曾任 SAP 中国研发中心负责人,具有实用软件开发和企业级
IT 背景。其自身也强调长期从事 ERP,对制造业采购、财务、销售、制造和质量管理等流程熟悉。


会议将这一经历与两类能力联系在一起:一是搭建 GPU 加速和模型调优团队;二是在未来把基础 Token 进一步封装为制造业智能体和解决方案。


2.3 公司所称的前期准备

团队准备: 组建 30 多人的团队,核心岗位集中在 GPU 加速、模型调优和平台建设。


技术准备: 开展小规模测试,验证连续批处理、缓存、显存管理和量化压缩等方向。


客户协同: 围绕T客户模型、产能和交付要求讨论合作方式。


平台准备: 会议提到在正式下场前进行了内部平台建设,但没有进一步拆分平台模块和完成度。




会议未进一步展开


前期投入金额、团队具体履历、已完成测试的模型与硬件配置、平台模块清单及测试报告均未在两次交流中披露。







三、Token 工厂定位与商业模式
3.1 与纯算力生意的区别

会议明确表达,单纯做算力生意的毛利会越来越低。项目希望解决的问题是:在服务器、GPU 和大模型都相同的情况下,不同团队可以通过调度和优化产出不同数量的 Token,进而形成不同的收入水平。


因此,项目被描述为从硬件采购、集群组网、模型部署、GPU/HBM
利用率优化到持续运维的端到端闭环,而不是只提供一批服务器或一套软件优化方案。


3.2 收入与利润的形成方式

计量基础: 会议称商业模式与实际产出相关,Token 产出越高,收入空间越大。


价格基础: 不同模型的 Token 售价和采购价不同,价格需要谈判,并会动态调整。


服务约束: 结算还会受到模型、实际供给量和 SLA 等要求影响。


分成机制: 会议讨论过基础利润保障和超过基准后的分成;第一场交流以“保
20% 利润”举例,但没有说明该比例是否为最终合同条款。


效率价值: 公司认为,超过基础产出的部分主要由优化能力创造,因此客户愿意对超额部分进行分成。


3.3 产能是否具有客户可迁移性

投资人询问,若服务器和模型经过T客户侧调优,是否还能服务其他客户。会议回答,约
80%—90% 可以直接使用,并称平台会支持市场上的主流开源大模型,客户可按需求选择。


会议同时承认,现阶段客户主要就是T客户。公司认为当前T客户需求足够,因此没有急于拓展其他客户;若未来需要分散客户,可以再发展其他客户。两次会议未披露已签约的第二客户。


3.4 不同模型的经济差异

会议称,不同模型的基础价格不同,能力较强、终端售价较高的模型,其 Token 采购和销售价格也可能更高。公司表示,不同模型的利润率比例未必差异很大,但价格基数高的模型可能贡献更多绝对利润。具体模型、价格和毛利率未披露。


四、T客户合作背景与合作机制
4.1 T客户为何需要外部合作方

会议将T客户的需求分为 MaaS(Model as a Service)等方向,并给出T客户推理需求快速增长的口头预测。会议称,T客户现有自持算力的供给能力仍无法覆盖中长期需求。


因此,公司判断T客户不能只靠自己采购和建设,需要与外部合作方同步推进。对于未来由T客户自持与外部合作各承担多少比例,会议明确表示不了解T客户内部战略,无法给出比例。


4.2 T客户需求的会议口径



时点





会议口径





补充说明








6 月





万亿级
Token/日





会议称为当时的推理供给/需求量级。







年底






6 月数倍增长





现场对增长幅度做过口头澄清。







2028 年





中长期持续高增长





会议称为中长期增长预期。









口径属性


上述内容均为会议中的口头表述。两次交流未展示T客户内部文件、正式预测表或采购承诺。







4.3 合作关系的描述

会议称,T客户希望合作方不仅提供硬件产能,还要共同把业务跑通;双方在模型适配、供给和交付上存在业务协同。公司将自身模式描述为“端到端闭环”。


会议同时提到,T客户内部团队、其他第三方优化团队和其他算力合作模式也存在。会议没有给出排他性条款,也没有确认公司是T客户唯一合作方。


4.4 定价、数量与 SLA

会议将合作模式描述为动态模式,难以做成价格完全锁死的封闭合同。不同模型、版本和市场价格变化会影响采购价,因此价格需要根据实际情况持续谈判。


数量可以签约。会议举例,如果公司拥有 128 台机器,但因设备或运营问题未达到客户要求的最低 Token 供给量,则会影响T客户对下游客户的交付计划,公司需要承担违约责任。


换言之,会议对“公司必须提供多少量、达不到如何处理”的描述较明确;对“T客户必须采购多少量、采购不足如何赔偿”没有给出同样明确的合同安排。


4.5 采购意向与保底问题

管理层多次表达,T客户当前担心的是公司供给不足。但投资人追问后,第一场交流明确指出,如果采购意向只是口头承诺,本身没有约束力。


会议还讨论了“保险价格”“利润保底”和超额分成,并以“保 20% 利润”作举例性说明。但最终价格、利润口径、保底触发条件、超额分成比例及T客户的最低付款责任均未披露。


五、推理效率技术与集群运行逻辑
5.1 两类主要资源瓶颈

会议把推理过程拆为 Prefill 和 Decode 两个阶段。Prefill 被描述为输入阶段,主要消耗 GPU 计算单元;Decode 被描述为输出阶段,主要受 HBM 显存带宽制约。项目的目标是同时提高 GPU 计算利用率和 HBM
带宽利用率,从而提高 TPM(Tokens per Minute)。





技术/机制





作用位置





会议中的解释








连续批处理/动态调度





Prefill





同一批请求长短不一,短请求完成后立即补入新请求,减少计算资源空置。会议用“拼车”类比。







缓存复用/缓存命中





Prefill





大量用户基于相同知识库提问时,共同内容只处理一次,减少重复读取和计算。







KV Cache 分页





Decode/HBM





将显存分页做得更细,减少显存碎片,提高显存利用率和并发度。







权重量化压缩





Decode/HBM





按应用场景选择
FP16、FP8、FP4 等精度,在保持回答质量的前提下降低权重占用,为输出留出更多显存。







PD 分离





Prefill 与 Decode





将两类负载分开处理,以分别匹配计算单元和 HBM 带宽。会议提到该方向,但未展开具体部署方式。







集群“超卖”





集群调度





利用不同用户不会在每个毫秒都满载的特点,在毫秒级切换资源,使实际可服务量高于静态分配量。







5.2 连续批处理:减少批次内空置

会议举例,同一批次内有的请求需要 20 秒,有的请求只需要 5 秒。传统批处理需要等整批完成后才释放资源,导致已完成请求所占用的位置空置;动态调度可以在短请求结束后立即补入新的短请求,使计算资源持续被使用。


会议称,普通状态下 GPU 利用率通常只有
35%—40%,若连续批处理等优化做得较好,吞吐可接近翻倍。该数字未说明硬件型号、模型、输入输出长度和延迟约束。


5.3 缓存复用:减少相同内容的重复计算

会议以企业知识库为例:一万名员工可能围绕同一套出差、请假和人力制度提出不同问题。若共同背景内容每次都重新读取和处理,会产生大量重复计算;缓存命中可以复用已经处理过的共同内容。


会议称,做得好时缓存命中率可达到 75% 以上,但同一句中又出现“30%”的口头片段,具体含义不清,需以正式测试口径确认。


5.4 KV Cache 分页:提高显存利用率

会议把 KV Cache 类比为显存中的缓存空间。持续满负荷运行会形成显存碎片,分页管理把空间切得更细,并配合先进先出等调度方式,把零散空间重新利用起来,从而提高并发度。


5.5 权重量化压缩:在质量与显存占用之间做选择

会议称,模型权重可以采用不同精度保存和加载。问答等场景未必需要 FP32 或 FP64,可以按场景使用
FP16、FP8 或 FP4;例如从 FP8 降至 FP4,会议称权重占用可降低一半,从而为 Decode 留出更多显存。


会议同时强调,应在保持回答质量的前提下调整精度;科研、3D
设计等场景可能需要更高精度。具体精度策略、质量损失和模型适配结果未披露。


5.6 集群“超卖”与规模效应

会议用云资源举例:十名用户各需要 100G,静态分配下 1000G 只能服务十人;由于用户不会在每个毫秒都满载,通过毫秒级调度,可以让同一资源在不明显影响用户感知的情况下服务更多用户。会议以“1000G 卖出 3000G 效果”作示意。


会议认为,单台与 32 台组网的表现差异较大,集群规模越大,调度和“超卖”效应越明显。但也明确表示,小规模跑通不代表大规模必然跑通。


5.7 会议中出现的性能数字



指标





会议数字





说明








GPU 常规利用率





35%—40%





技术拆解部分的明确表述。







优化后利用率






80%





后续问答中的口头表述。







另一处常规利用率





3%





与前文
35%—40% 明显冲突,疑似转写问题。







连续批处理提升





吞吐接近翻倍





未披露测试条件。







不同团队同机差异





3—8





第一场会议的口头表述,句子存在转写杂音。







缓存命中率





75%
以上





同一句另出现“30%”,含义未明确。







集群资源示例





1000G
形成 3000G 服务效果





用于解释“超卖”,不是正式测试结果。







六、测试验证、设备到货与投产节奏
6.1 当前验证状态

会议称团队已经做过小规模测试,相关方案并非完全停留在纸面。但目前尚未在大规模集群上完成正式验证。管理层认为,小规模跑通后向大规模迁移相对容易,但同时明确承认“并不是小规模跑通,大规模就一定能跑通”。


6.2 组网规模与启动条件

会议中出现了 32 台倍数、320 台、千卡级和千台以上等不同说法。较明确的共同点是:单台或十几台不能体现完整效果,需要达到可组网的规模后才能开展集群调优。


公司称第一批资源达到千卡级别,设备将分批到货。团队会根据到货情况启动工作,而不是等全部设备到齐后一次性开始。


6.3 四季度至春节前的关键安排



阶段





会议安排








四季度





第一批服务器/卡到位并完成基础组网,达到可开展模型部署和集群调优的规模。







到货后





核心团队开始跑模型、做调优,并处理分批到货、不同机器和组网节奏问题。







至少约 1 个月





会议称需要留出时间进行调教、数据优化和闭环验证。







春节前





目标是把首轮闭环完整跑一遍,证明团队能力可以从方案转为实际结果。







闭环跑通后





按照“第二次、第三次、第四次复制”的思路扩大规模。







6.4 会议对首轮闭环的重视程度

与会者多次强调,决定业务能做多久的不是 PPT,而是核心团队能否在真实硬件上把闭环跑通。四季度设备到货后,首轮集群结果将决定后续复制是否具备基础。


七、数据中心与服务器安排
7.1 数据中心:短期租赁,中期自建

会议提出“两手抓”:短期寻找合适机房租赁,先让设备运行;中期与地方政府推进自建数据中心。会议称,从选址到建成通常需要 1 年至 1 年半,因此无法等待自建完成后再启动业务。


7.2 选址与延迟

投资人提出,推理业务是否需要靠近华东、华南用户。会议回答,T客户在全国有多个可用区,并通过自有骨干网连接,因此数据中心不一定必须位于终端用户所在城市,只要靠近T客户可用区即可。


会议提到四川成都及雅安、内蒙古乌兰察布、宁夏中卫、湖北宜昌等候选区域,并称雅安至成都附近的测试延迟约为
1—2 毫秒。公司倾向选择成都附近,但两次交流没有给出最终选址。


7.3 服务器采购与价格讨论

会议以高端服务器为例讨论采购价格,现场出现“一千多万”“约八百”以及现货“1400—1500”等多个口头数字。与会者同时指出,小批量现货价格不代表大规模采购价格。


由于单位、具体配置、是否含税以及“一台”对应的服务器形态均未在转写中明确,这组数字只能保留为会议讨论,不能据此形成统一采购单价。


7.4 200 亿元与集群规模

会议称,200 亿元投入并不只对应一个简单的“一万卡集群”,且“万卡集群”不一定是严格的一万张卡整数。具体卡数、服务器数、网络和机房投入拆分均未披露。


八、团队、组织与业务归属
8.1 团队规模与分工



项目





会议内容








团队人数





30
多人







核心工作





GPU 加速、模型调优、集群和平台相关工作。







运维





会议称人数不多。







客户协同





设有与T客户对接和沟通的角色。







办公点





安徽总部及上海浦东/金桥等多个 base。







后续招聘





随着规模扩大,会议预计还会继续补充人员。







8.2 会议所称的团队壁垒

会议认为,成熟的 GPU 加速和大模型调优人才并非仅靠资金就能立即获得,核心负责人的行业经历和人才关系有助于组建团队。公司同时认为,单纯提供优化软件、但没有自有硬件和客户闭环的第三方,与公司模式不同。


不过,两次交流未给出核心成员名单、履历、薪酬激励、股权安排或人员稳定性数据。


8.3 上市公司与集团的业务归属

会议中有人强调,若项目是上市公司的业务,就不应把核心资产和利益放在集团层面,并表示“上市公司归上市公司,集团归集团”。但会议没有进一步披露服务器、合同、团队、知识产权、融资和利润分别由哪个主体承接。


九、资本投入、融资安排与财务口径
9.1 总投入与资金结构

会议多次围绕 200 亿元总投入讨论项目规模。设备和项目将分批推进,不是一次性在同一时点支付全部资金。


常规资金结构被描述为“1 比 4”,即约 20% 自有资金、80% 融资;融资资金成本约 2.6%—2.8%。会议还提到可以使用原有授信额度、自有资金调动和融资租赁。


与会者强调,“授信”并不等于同额现金贷款,其中也可能包括承兑汇票、理财等安排。两次交流没有披露具体银行、授信批复、融资租赁合同或分期提款计划。


9.2 2027 年全年跑满的口头粗测



项目





会议数字





说明








资本投入





200
亿元





按项目总规模讨论。







测算时点





2027
年全年跑满





会议称若 200
亿元投入全年运行,才对应这一规模。







营收






100 亿元





会议称为“大数粗拍”。







净利润






60 亿元





会议口头表述,未给详细利润表。







营收与净利润差额






40 亿元





会议称主要包括折旧、房租、电费、机房及其他辅助成本。







折旧






30 亿元





会议同时称设备按
5 年折旧、残值 30%。







9.3 会议未给出的财务细项

会议没有提供按模型、服务器、Token 数量和单价拆分的收入表,也没有给出电费、机房费、带宽、运维、人力、税费、利息、折旧起算时点及设备残值实现方式的逐项明细。


因此,100 亿元营收和 60 亿元净利润在本纪要中仅保留为会议的口头粗测,不进行额外复算或外推。


9.4 现金周转的会议判断

会议认为项目分批投入、回款周期相对较快,资金可以循环使用,因此现金不是最难的问题。这一判断未附现金流计划或回款周期数据。


十、价格判断与中长期业务方向
10.1 Token 价格的短中长期判断

第一场交流承认 Token 价格总体存在下降趋势,且玩家增多、效率提升和竞争都会影响价格,但无法量化每月降幅。


第二场交流中,管理层进一步表示,虽然中长期可能成为红海,但其判断未来 2—3 年需求增长快于供给增长,基础 Token 价格不会明显下降;4—5 年以后竞争压力可能加大。


两次表述可以合并理解为:会议承认长期价格压力,但管理层对未来 2—3 年供需较为乐观。该判断未给供需模型。


10.2 Token 价格下降与硬件成本之间的讨论

投资人提出,历史 Token 单价下降较快,但 GPU 和服务器价格并未同步下降,若效率提升存在物理极限,未来是否会出现盈利压力。管理层回应,过去一段时间推理调优效率提升较快;若价格降到生产者无法盈利,供需会通过减少供给或价格回升重新平衡。


会议承认优化有物理上限,利用率不可能超过 100%,但没有回答当前距离理论上限还有多少。


10.3 从基础 Token 走向业务解决方案

公司表示,不希望长期只卖没有业务附加值的基础
Token,而是计划把制造业采购、财务、销售、制造、质量管理等场景做成智能体。最终客户购买的是解决方案,Token
只是底层消耗。


会议称这条路径更长、准备时间更多,核心门槛在于行业知识。最后还以机器人等应用作方向性举例,但没有披露具体产品、客户和时间表。


十一、会议中尚未明确的关键事项



事项





两次会议未明确的内容








T客户采购义务





客户采购意向是否写入合同;是否有最低采购量、最低付款额及客户违约责任。







保底与分成





“20% 利润”是否为正式条款;利润计算口径、成本基准、超额分成比例及结算周期。







Token 定价





不同模型的采购价、调价频率、与刊例价的关系、折扣方式及价格下限。







SLA





最低供给量、可用率、延迟、质量、故障处理和违约金的具体标准。







技术结果





小规模测试的硬件、模型、并发、输入输出长度、延迟约束和稳定运行时长。







规模化结果





千卡级集群的实际吞吐、利用率、稳定性和复制速度。







设备





最终采购型号、单台配置、数量、单价、到货批次和供应商。







数据中心





最终选址、租赁机房、建设主体、电力与网络安排。







资本安排





200 亿元分期计划、具体融资机构、已获批额度、提款条件和担保。







财务口径





100 亿元营收、60 亿元净利润的单位经济、成本和税费明细。







客户集中





第二客户是否存在、何时拓展、产能转移需要多少重新适配。







业务归属





服务器、合同、团队、知识产权、融资和利润在上市公司与集团之间的具体边界。







长期产品





制造业智能体、机器人或其他解决方案的产品形态、客户与时间表。







十二、原文口径冲突与转写待确认



项目





整理处理








GPU 常规利用率





技术拆解处为 35%—40%;后续问答有一次转写为
3%,明显不一致。







吞吐提升幅度





一处为连续批处理后接近翻倍;另一处出现 3—8 倍,测试边界不同或存在转写问题。







缓存命中率





同一段同时出现“75%
以上”和“30%”,后者所指不明。







设备单价





出现“八百”“一千二”“1400—1500”“一千多万”等口头数字,单位和配置不完整。







设备规模





出现 32 台倍数、320 台、千卡级、千台以上、万卡集群等说法,需区分服务器、GPU 卡和集群名称。







需求增长





原文另有关于增长倍数的口头片段,所指时点和指标不清,未纳入核心内容。







投入节奏





原文有“再加 45 亿,差不多就是 50 个亿,就 200 亿”等片段,缺少上下文,未据此拆分年度资本开支。







技术成熟时点





会议交替使用“去年底到今年初”“今年上半年后”“2026 年是元年”等说法,统一保留为管理层认为 2026 年技术进入较成熟阶段。









处理原则


对上述口径不做会议之外的修正;能够由现场后续问答澄清的,按澄清后的表述整理;无法澄清的,保留“待确认”。







十三、详细问答纪要


阅读说明


以下按议题重组两次交流的主要问答,删去重复口头语,但不添加会议之外的结论。







Q1. 公司为什么从原有业务转向 AI 和 Token 工厂?


会议称,董事长在 2022 年已经希望加强 IT 能力,并招募核心负责人。当时并未预判 AI 会成为当前风口,最初是希望把 IT 做好。


核心负责人长期从事 ERP 和制造业信息化,公司随后从 IT 一步步走向 AI。2025 年初以后行业变化加快,公司在团队、技术、市场和内部平台方面持续准备,最终决定正式进入。


Q2. 公司凭什么做这一转型?
[部分明确]


会议主要给出三方面:核心负责人曾任 SAP 中国研发中心负责人,熟悉企业软件和制造业流程;公司已组建 GPU 加速与模型调优团队;公司与T客户建立了客户协同。


会议还将资金和服务器获取能力视为必要条件。具体团队履历和测试报告未披露。


Q3. 为什么选择与T客户合作?


会议称T客户 MaaS 和推理需求增长较快,自持算力难以覆盖未来需求,需要外部合作方同步建设。T客户也希望合作方不仅提供服务器,还要共同把模型、产能和交付闭环跑通。


Q4. 会议如何描述T客户的 Token 需求?
[会议口径]


会议以口头方式描述了需求快速增长的趋势:年内需求较年中显著提升,中长期预计维持高增长。具体数字为口头表述,未获正式文件确认。


Q5. T客户自持与外部合作各占多少比例?
[未明确]


会议明确表示不了解T客户内部战略,无法给出比例;只强调T客户自持供给肯定不够,必须引入外部供给。


Q6. 公司是否是T客户唯一或排他的合作方?
[未确认]


会议没有确认排他性。


会议同时承认T客户内部团队、其他算力合作方和第三方优化团队也存在。


Q7. Token 工厂与普通算力租赁有什么区别?


会议认为,普通算力租赁主要卖硬件资源,毛利会逐渐下降;Token 工厂的核心是让相同服务器和相同模型产出更多 Token,并按实际产出形成收入。


公司希望覆盖硬件、组网、模型、调优和运维的端到端闭环。


Q8. 为什么同一台服务器的收入会不同?


会议称,不同团队对 GPU 计算资源、HBM 带宽、缓存、调度和模型精度的优化能力不同,因此同样硬件和模型可以产生不同吞吐。产出更多 Token,收入也会相应更高。


Q9. 与T客户的结算依据是什么?
[部分明确]


会议称商业模式与实际产出相关,并根据不同模型、实际供给和 SLA 动态结算。价格不是固定不变的封闭合同,需要持续谈判和调整。


Q10. Token 采购价格与T客户刊例价是什么关系?
[未明确]


会议区分了T客户对终端客户的刊例价与T客户向公司采购 Token 的价格。采购价需要单独谈判,可能参考不同模型价格并考虑折扣和价差。具体公式未给出。


Q11. 合作是否有利润保底和超额分成?
[待确认]


会议讨论过“保险价格”、利润保底和超过基准后的分成,并以“只保 20% 利润”作举例。


会议没有说明 20% 是否为正式合同数字,也没有说明利润口径、成本基准和分成比例。


Q12. T客户是否承诺最低采购量?
[未明确]


管理层多次描述当前需求旺盛,但第一场交流在投资人追问后明确承认,若只是口头表述,则没有约束力。


交流称数量可以签,但后续举例主要说明公司必须满足最低供给量,未清楚说明T客户采购不足时承担何种责任。


Q13. 公司在合同中承担什么义务?


会议称最低供给量和 SLA 可以约定。如果公司拥有 128 台机器,但因故障或调度问题没有达到客户要求的最小量,会打破T客户的交付计划,公司需承担违约责任。


Q14. 公司目前是否只服务T客户?


会议称现阶段主要就是T客户一家,管理层认为T客户需求已经足够。是否拓展其他客户取决于后续经营安排。两次交流未披露第二个已签约客户。


Q15. 为T客户调优后的产能能否转给其他客户?
[部分明确]


会议回答,约 80%—90% 可以直接使用,因为平台会支持国内外主流开源大模型。公司表示,如果T客户需求变化,可以服务其他客户。具体重新适配时间和成本未披露。


Q16. 不同模型对收入和利润有什么影响?
[未量化]


会议称不同模型的 Token 价格不同。能力较强、终端售价较高的模型,价格基数更高,公司可能获得更多绝对利润。具体模型组合和毛利率未给出。


Q17. 公司团队与纯软件优化团队有什么不同?


会议认为,部分第三方只在租来的卡上提供优化方案,没有自有硬件和客户闭环;公司则计划亲自采购设备并负责从硬件到模型、调优和交付的完整闭环。


Q18. 团队目前有多少人,主要做什么?


会议称团队有 30 多人,核心工作是 GPU 加速和模型调优,运维人员不多,并有客户对接岗位。随着规模扩大,后续还会招聘。


Q19. 团队分布在哪里?
[部分明确]


会议称公司有多个 base,包括安徽总部和上海浦东/金桥。具体各地人数和职责未披露。


Q20. 公司认为推理优化技术何时开始成熟?
[会议观点]


会议称 2025 年相关技术仍不成熟,2025 年底至 2026 年上半年开始加速发展,并把 2026 年称为“智算元年”。这是管理层的行业判断。


Q21. 公司是否已经完成技术测试?
[部分明确]


会议称已做过小规模测试,并非完全基于纸面。测试硬件、模型、并发、延迟和结果明细未披露。


Q22. 小规模跑通是否意味着大规模也能跑通?


会议回答,小规模跑通后大规模相对容易,但明确表示并不是小规模跑通就一定能在大规模跑通。四季度千卡级部署仍需实际验证。


Q23. 为什么集群规模会影响效率?


会议称单台与 32 台组网存在明显差异。集群越大,可利用不同用户负载不同步的特点,在毫秒级调度资源,从而产生“超卖”或集群效应。


Q24. 什么是会议所说的“超卖”?


会议用云资源举例:用户不会在每个毫秒都跑满,平台可以在毫秒级把暂时空闲资源分给其他用户,在不明显增加感知延迟的情况下服务更多需求。


“1000G 卖出 3000G 效果”是解释性示例,不是正式披露的业务数据。


Q25.
Prefill 和 Decode 分别受什么限制?


会议称 Prefill 是输入阶段,主要消耗 GPU 计算单元;Decode
是输出阶段,主要受 HBM 显存带宽限制。提高这两类资源的利用率可以提升 TPM。


Q26. 连续批处理如何提升吞吐?


同一批请求长短不同。短请求先结束后,平台立即补入新请求,避免等待最长请求结束后才整体释放资源。会议称该方法可提高 GPU 计算效率。


Q27. 缓存命中如何节省计算?
[数字待确认]


对于使用相同企业知识库的多个问题,共同背景内容不必每次重新读取和处理,可以复用已有结果。会议称做得好时缓存命中率可达 75% 以上。


Q28. KV Cache 分页解决什么问题?


会议称 HBM 长时间运行会产生显存碎片。把 KV Cache 分页做得更细,并配合调度策略,可以利用零散空间、提高并发度。


Q29. 权重量化压缩如何提升产出?


模型在实际推理中可按场景选择 FP16、FP8 或 FP4 等精度。会议称,在不影响回答质量的前提下降低精度,可减少权重占用,为 Decode 留出更多 HBM 空间。


Q30. 会议给出的 GPU 利用率是多少?
[口径冲突]


技术拆解部分称普通状态下为 35%—40%,优化较好时可接近翻倍;后续问答又出现普通状态 3%、优化后 80% 的说法。3% 与前文冲突,需要确认。


Q31. 会议给出的吞吐提升是多少?
[待确认]


一处称连续批处理做得好可以让吞吐接近翻倍;第一场交流另有不同团队同机吞吐相差 3—8 倍的口头表述。两者测试范围和条件未说明。


Q32. 推理优化是否存在理论上限?
[未量化]


会议确认存在物理上限,利用率不能超过 100%。当被问及当前距离上限还有多少时,管理层没有给出具体倍数。


Q33. 服务器何时到货?
[时间待确认]


会议称设备分批到货,第一批在四季度到位。部分原文提到九月、四季度等说法,最终整理以四季度启动为较一致口径。


Q34. 需要多大规模才能开始调优?
[口径待确认]


会议称只有十几台不够,32 台的倍数可以开展组网;同时出现 320 台、千卡级和千台以上等说法。具体最小规模需确认服务器与 GPU 卡口径。


Q35. 春节前要完成什么?


目标是让首批硬件完成组网,跑模型、做调优和数据优化,把完整闭环至少跑一遍。会议认为闭环跑通后,才能进行第二次、第三次和第四次复制。


Q36. 高端服务器的采购价格是多少?
[未明确]


现场出现“约八百”“一千二”“1400—1500”“一千多万”等多个口头数字,并强调现货小批量价格不代表大规模采购价。单位和配置不完整,因此无法形成统一单价。


Q37. 200 亿元大约对应多少卡?
[未明确]


会议称 200 亿元不止一个简单的“万卡集群”,且万卡集群不一定严格等于一万张卡。具体卡数、服务器数和其他投入没有拆分。


Q38. 服务器由谁采购?
[未明确]


会议表述为核心团队和公司利用自身资源解决采购。具体供应商和采购路径未披露。


Q39. 数据中心是租还是自建?


短期租赁合适机房,先让业务运行;中期推进自建。会议称自建周期一般为 1 年至 1 年半,因此不能等自建完成后再启动。


Q40. 为什么数据中心可以放在西部?
[会议观点]


会议称T客户在全国有多个可用区,并通过自有骨干网连接。只要数据中心靠近可用区,终端客户不一定能感知明显延迟。


Q41. 公司倾向在哪里建数据中心?
[未最终确定]


会议称倾向成都附近,并提到雅安、乌兰察布、中卫、宜昌等地点。雅安附近测试延迟被描述为 1—2 毫秒。最终地点未确认。


Q42. 团队和业务应放在上市公司还是集团?
[未明确]


会议有人明确表示,如果项目作为上市公司业务推进,就不应把核心内容放在集团;但服务器、合同、团队、知识产权和利润的具体归属没有展开。


Q43. 200 亿元资金如何安排?
[部分明确]


会议称常规结构约为 20% 自有资金、80% 融资,资金成本 2.6%—2.8%;还可使用原有授信、自有资金和融资租赁,并分批投入。具体金融机构和额度未披露。


Q44. 会议给出的收入和利润预期是多少?
[口头粗测]


按 200 亿元投入、2027 年全年跑满的口头假设,会议粗拍约 100 亿元营收、60 亿元净利润,营收与净利润之间约 40 亿元成本,其中折旧约 30 亿元。


Q45. 折旧如何假设?
[会议口径]


会议称按 5 年折旧、残值 30% 的行业口径计算,并口头给出折旧约 30 亿元。未披露不同设备的折旧分类和起算时点。


Q46. 公司认为这个项目成功的三要素是什么?


第一,真金白银投入并能拿到卡;第二,有高质量客户共同推进;第三,也是最重要的一点,同样硬件能够比别人产出更多 Token。


Q47. 公司如何判断未来
Token 价格?
[管理层判断]


会议承认长期价格存在下降和竞争加剧趋势,但管理层判断未来 2—3 年需求增速高于供给,基础 Token 价格不会明显下降;4—5 年以后可能进入红海。


Q48. 如果 Token 价格持续下降,业务如何维持盈利?
[管理层判断]


管理层认为,一方面推理调优提高了输出效率;另一方面若价格降到生产者亏损,供给会退出,市场会通过供需重新平衡。会议没有给定量模型。


Q49. 公司中长期准备做什么?


公司计划从基础 Token 向带业务附加值的 Token 发展,把制造业采购、财务、销售、制造和质量管理等流程做成智能体和解决方案。


会议称这一方向需要更长时间和更深行业知识,最后还以机器人等应用作方向性举例。


Q50. 会议如何看待基础
Token 与解决方案的关系?
[会议观点]


会议用“Token 像电”作比喻:长期不只卖底层消耗,而是卖解决问题的应用和方案。公司认为行业知识是T客户、阿里等平台型公司不容易单独完成的部分。


Q51. 价格战与折旧是否可能造成“亏利润、不亏现金流”的竞争?
[未完整回答]


投资人在最后提出这一极端情景。管理层没有正面给出财务边界,只强调需要形成自身能力,并最终转向解决方案,而不是停留在普通 Token 供给。


纪要收束

两次交流围绕同一条主线展开:公司试图以资金、客户和技术三项能力切入 Token 工厂,并在四季度至春节前通过真实集群验证“同卡多产 Token”的核心假设。会议对项目愿景、T客户需求、技术路径和资本规模有较多口头说明,但合同采购责任、规模化测试、设备价格、资金落地、财务拆分和业务归属仍需后续正式信息补充。

作者声明: 本文转载自第三方,旨在提供资讯参考,并非证券推荐或投资建议。作者对内容的真实性、准确性不承担保证责任。本文不构成任何投资建议或证券推荐。截至发文日,作者与文中提及的标的不存在持仓关系。

合规声明:本站发布的所有文章及观点均系个人研究共享,投资心得交流,不代表本站立场,且不构成任何形式的投资建议。投资者据此操作,风险自担,请务必保持独立审慎的决策态度。