大模型商业化讨论里收入增长率通常是最容易抓眼球的一个数字。MiniMax 上半年营收增长 283% 的消息很容易让人先记住扩张速度但同一句话中的后半段——毛利率仍落后同行其实更值得技术团队关注。毛利率不是财务课上的抽象概念它直接反映算力成本、推理成本、数据成本、研发投入和产品定价共同构成的结构关系。技术团队如果只关注模型效果和并发上限忽略毛利率背后的单位经济模型后期往往会陷入“调用量越大亏损越多”的被动局面。这篇文章以 MiniMax 这个案例为切入点从技术视角拆解大模型公司的成本结构说明为什么高增长不一定带来高毛利以及技术侧可以从哪些环节改善毛利率。1. 先拆清楚毛利率到底被哪些成本吃掉1.1 毛利率是商业模式健康度指标不是技术优越性指标毛利率的计算公式很简单毛利率 (营业收入 - 营业成本) / 营业收入 * 100%难点在于营业成本的口径。在大模型公司里营业成本通常包括 GPU 或 CPU 算力租赁、自建数据中心的硬件折旧、带宽、电力、推理服务器、模型调用网关以及直接参与模型服务交付的工程人力。这里的成本并不等于“研发费用”研发费用更多发生在利润表更靠后的位置但两者会互相影响。技术人容易把毛利率理解成“技术强不强”的结果但这种理解并不准确。毛利率更接近“交付一份服务时收入能覆盖多少直接成本”的商业度量。一个 API 产品的毛利率是 80% 还是 40%反映的不是模型效果差距而是收入、定价、成本结构、资源利用效率共同作用的结果。同样一个 7B 模型用低效的推理框架部署毛利率可能只有 30%换一个经过优化的推理引擎并配置好缓存毛利率可能提升到 60% 以上。1.2 MiniMax 这类大模型公司收入从哪来成本从哪走大模型公司的收入来源通常分为几类面向开发者的 API 调用收入、面向 C 端或 B 端用户的订阅收入、私有化部署收入、企业解决方案收入以及部分广告或流量变现收入。不同收入类型的成本结构差异很大。API 调用收入最直接按 token 计费也最容易和算力成本挂钩。订阅收入通常给定用户一个额度包超额后限制或付费用户的实际使用强度决定成本。私有化和企业项目收入虽然单笔金额高但交付周期长需要大量售前支持、定制开发和运维人力。收入结构越复杂毛利率分析就越不能只停留在总量层面。成本侧的核心是算力。训练阶段需要大规模 GPU 集群成本是脉冲式的模型发布后会明显回落推理阶段则是持续的每一笔 API 请求、每一个对话都会产生电力、带宽、显存占用和 GPU 推理时延。除此之外还有数据清洗、标注、合规审核、模型评测、实验管理平台、日志存储和监控系统等基础设施成本。这些成本往往不直接进入单次调用账单但会在月底汇总财报时体现出来。1.3 一张成本表训练、推理、数据、人力的角色成本类型发生阶段对毛利率的影响方式典型特点训练成本模型预训练、微调、对齐、实验复现训练集群购买或租赁费用在当期或折旧期摊销脉冲式成本高周期不规律推理成本每笔 API 请求、每次对话、每份生成结果直接进入营业成本随 token 量线性增长持续发生与业务量强相关数据成本数据采购、清洗、标注、合成、合规审查部分计入研发费用部分影响交付成本前期集中后续仍需持续维护人力成本算法、工程、SRE、数据标注、运维直接参与服务的工程人力计入营业成本其余计入费用刚性支出难随业务快速伸缩基础设施成本网关、存储、日志、监控、带宽支撑层成本容易被低估用量增长后占比可能快速上升这张表说明一个关键问题传统软件产品一旦完成开发复制和分发的边际成本接近零所以毛利率可以做到 70% 甚至 90%。但大模型公司的推理成本是随着用户使用量同步增长的模型每生成一个 token都会消耗计算资源。只要定价不能显著高于单位成本毛利率就一定会被压在相对低的水平。2. 为什么营收增速可以到 283%毛利率却落后同行2.1 推理成本随用量线性放大边际成本没有降到接近零传统 SaaS 模式的经典优势是“一份代码无限复制”。即使不断加新用户服务器成本也只是缓慢增长主要瓶颈在运维和数据库连接数。大模型产品完全不同用户每发一次请求模型就要在 GPU 上执行一次前向推理生成几十个或几百个 token。这个过程消耗的算力和请求数量基本是线性关系。从毛利拆解看单次请求的毛利可以表示为单次请求毛利 单次请求收入 - 单次请求推理成本 - 单次请求分摊成本如果单次请求收入是 0.01 元推理成本是 0.008 元分摊成本是 0.003 元那么每一笔请求都在亏损。收入翻倍意味着亏损金额也翻倍。MiniMax 这类公司营收增长 283%如果收入增长主要来自 token 用量扩张而单位成本和定价没有显著改进毛利率就会被持续稀释。这也是大模型公司和云计算公司的重要差异。云计算同样有基础设施成本但虚拟机的复用、网络带宽的利用率、存储的分层都早有多年的成本优化手段。生成式模型推理的 GPU 利用率却往往偏低尤其在首 token 时延要求较高的交互场景中批处理规模上不去GPU 空转明显。2.2 低价竞争和免费额度把单位收入压到成本线附近大模型 API 市场长期存在价格竞争。为了争夺开发者很多平台会提供免费额度、低价 promotion 模型、限时折扣或者在 C 端产品里赠送大量免费对话次数。从用户增长角度看这些动作有效但从毛利率角度看单位收入被压低了。免费额度的成本会真实发生。每个免费用户使用一次模型平台就要支付相应的推理成本。如果免费用户占比很高且他们的请求内容没有价值密度那么即便总营收高速增长营业收入的增量也会被成本增量抵消。毛利率落后同行很可能不是因为模型能力弱而是因为大量收入沉淀在低毛利甚至零毛利的流量型业务里。这里需要区分“营收增长”和“毛利增长”。营收增长 283% 可以来自用户数增加、调用量增加和价格提升的叠加毛利率则必须同时观察收入质量。如果一个公司的免费调用占比从 40% 上升到 60%即便付费收入也在增长最终毛利率也可能下降。2.3 模型迭代带来的重复训练成本会穿透到当期利润大模型公司通常保持着较高的模型迭代频率。每次发布新模型都需要大规模预训练、SFT、RLHF 或对齐调整。训练过程不是一次成功而是大量实验并行推进失败实验同样消耗 GPU。这些成本不以 token 形式出现在 API 账单里但最终会进入利润表。训练成本的会计处理方式直接影响毛利率。有些公司把训练的 GPU 租赁费用直接计入营业成本毛利率自然低有些公司把大模型训练算作研发投入并进行资本化摊销毛利率表现会好看一些。但这只是会计口径差异不代表真实经济效益更好。技术团队看毛利率时要先弄清楚对方使用的是哪一种口径否则容易得出错误结论。2.4 毛利率对比必须先对齐统计口径不同公司披露收入时也有差异。有的公司把云资源转售、客服人力、安全审核都算进营业成本有的公司则只算模型推理服务器成本。有的公司把模型训练费用归入研发费用有的则归入营业成本。下面这张表可以说明口径差异会导致怎样的阅读误差统计口径公司 A公司 B结果比较训练算力成本计入营业成本计入研发费用公司 B 毛利率虚高推理服务器折旧按 3 年折旧按 5 年折旧公司 A 当期成本更高免费用户推理成本计入营业成本作为销售费用公司 B 毛利率虚高带宽和电力计入营业成本计入管理费用公司 B 毛利率虚高所以看到“MiniMax 营收增长 283%毛利率仍落后同行”时不能直接将其解读为经营能力差。更合理的做法是拆开收入结构、成本口径和业务阶段。一个处于高速扩张期的公司很可能为了市场份额牺牲短期毛利另一个已经进入稳定成熟期的公司则可能通过提价和控制用量把毛利率做高。两者不具备简单的可比性。3. 技术侧的主战场让单位推理成本降下来3.1 先量化从调用日志统计 token 用量和成本优化毛利率的第一步不是直接改模型而是先搞清楚单位推理成本。很多公司只有月底财务给一个总账单技术团队不知道每个模型、每个客户、每个 API Key 消耗了多少 token更不知道哪个业务线在亏钱。建立成本观测体系的入口是模型调用日志。常见做法是在 API Gateway 层记录每个请求的 model、prompt_tokens、completion_tokens、user_id、api_key、request_time 等字段。下面是一个用 Python 从 MongoDB 聚合日志的示例用于按模型统计 token 用量from pymongo import MongoClient import datetime client MongoClient(mongodb://localhost:27017) db client[llm_gateway] calls db[call_logs] start datetime.datetime(2025, 7, 1) end datetime.datetime(2025, 7, 31) pipeline [ {$match: {request_time: {$gte: start, $lt: end}}}, {$group: { _id: $model_name, total_prompt_tokens: {$sum: $usage.prompt_tokens}, total_completion_tokens: {$sum: $usage.completion_tokens}, total_calls: {$sum: 1} }}, {$sort: {total_prompt_tokens: -1}} ] for row in calls.aggregate(pipeline): print(row)这段代码的前提是日志中已经记录了 model 和 usage 字段。如果还没有打点需要先在前端 Gateway 或 SDK 里补上。只有把 token 用量统计出来才能计算每个模型的实际生产成本。3.2 缓存与复用避免同一个问题计算两次推理成本最高的场景往往不是复杂问题而是大量相似请求。比如客服问答、文档摘要、代码补全用户多次提交同一类问题模型重复生成相似内容。针对这类场景可以引入语义缓存或前缀缓存。语义缓存的基本思路是计算输入文本的向量用近似度判断是否命中缓存。命中后直接返回之前的结果不再调用模型。下面是一段用于说明思路的 Python 伪代码import hashlib import numpy as np def get_cache_key(query, model, temperature, system_prompt): content f{system_prompt}|{query}|{model}|{temperature} return hashlib.sha256(content.encode()).hexdigest() cache {} def chat_with_cache(query, modeltiny-llm, temperature0.7): key get_cache_key(query, model, temperature, default-system) if key in cache: # 命中缓存不产生新的 token 成本 return cache[key], cache_hit response llm_chat(query, modelmodel, temperaturetemperature) cache[key] response return response, cache_miss在这个例子里缓存命中请求不再消耗 token直接消除了对应的推理成本。实际生产环境通常会使用 Redis 或专门的 embedding 检索系统并设置过期时间避免缓存无限膨胀。缓存命中率越高单位收入对应的推理成本越低毛利率越容易改善。3.3 推理引擎调优量化、批处理、投机采样和 KV Cache除缓存外推理引擎本身也有大量优化空间。常见手段包括模型量化把权重从 FP16 压缩到 INT8 或 INT4降低显存占用和计算量。动态批处理把同一时刻到达的多个请求组合成 batch提高 GPU 利用率。投机采样用小模型生成候选 token再由大模型验证减少逐步生成的时间。KV Cache 优化复用前缀相同请求的键值缓存减少重复计算。如果使用 vLLM 或类 TS 推理框架启动参数可以直接影响推理成本。下面是一个示例命令用于说明参数含义vllm serve Meta-Llama-3-8B-Instruct \ --tensor-parallel-size 2 \ --max-num-seqs 256 \ --kv-cache-dtype fp8 \ --gpu-memory-utilization 0.9参数解释参数作用注意事项tensor-parallel-size将模型切分到多张 GPU 上显存不足时提高但会带来通信开销max-num-seqs同时处理的序列数调大可提高吞吐但会增大延迟kv-cache-dtypeKV Cache 的数据类型fp8 可减少显存但要验证精度影响gpu-memory-utilization给推理引擎预留显存比例过高会导致模型加载失败或 OOM这些参数的收益会随硬件、模型和请求分布变化。不要照搬参数要先用压测工具跑出延迟、吞吐和 GPU 利用率再决定是否调整。3.4 架构选型混合模型路由降低平均成本不同请求的难度差异很大。简单问题不需要每次都调用大模型。一个常见策略是混合模型路由先由路由层判断请求的难度或领域选择不同规模的模型。def route_request(query): if len(query) 30 and intent_is_simple(query): return small-fast-model if requires_code_execution(query): return code-specialized-model return large-general-model这样可以实现一个朴素的效果大部分简单请求走小模型只有复杂请求才调用大模型。平均成本下降但用户体验没有明显下降。生产环境的路由往往更复杂会结合语义向量、分类器、业务规则甚至 A/B 测试。成本观察是这套系统的核心依据如果小模型经常被分配复杂任务会导致质量下降如果大模型承担了过多简单任务又会导致成本浪费。模型策略优势风险落地难度只用大模型效果稳定实现简单成本高毛利差低只用小模型成本低速度快复杂任务质量不足低路由混合模型成本和效果折中路由错误会带来体验抖动中多阶段级联先小模型后大模型补充延迟可能增加高4. 毛利率异常时从技术到财务的排查链路4.1 现象与排查优先级当公司毛利率低于预期或持续恶化时技术团队经常接到一个模糊问题“为什么我们的毛利越来越差”不能直接凭感觉回答。需要按数据链路排查顺序是收入确认 - 用量统计 - 单位成本 - 资源利用率 - 财务口径。按这个顺序可以避免一个常见错误一开始就怀疑模型太贵或 GPU 不够。实际收益下降往往是因为免费额度占比太高、缓存没生效、日志缺 token 统计或者财务把一次性采购费用全部计入了当期营业成本。4.2 第一层收入账单是否漏记、错记、免费额度占比过高先看收入端。毛利率的分母是营业收入如果收入漏记毛利率必然失真。比如前端页面只展示了付费调用量但后台实际还有很多 API Key 通过测试接口大量调用却没有被计费。排查方式是按模型、客户、渠道拆收入。下面是一段 SQL 示例用于统计不同模型和客户等级的 token 消耗以及免费 token 的占比SELECT model_name, customer_tier, SUM(prompt_tokens completion_tokens) AS total_tokens, SUM(CASE WHEN is_free_quota 1 THEN (prompt_tokens completion_tokens) ELSE 0 END) AS free_tokens, SUM(CASE WHEN is_free_quota 1 THEN (prompt_tokens completion_tokens) ELSE 0 END) * 1.0 / NULLIF(SUM(prompt_tokens completion_tokens), 0) AS free_ratio FROM billing_records WHERE billing_month 2025-07 GROUP BY model_name, customer_tier ORDER BY total_tokens DESC;free_ratio 过高说明大量 token 没有产生收入。此时需要判断这些免费用户是否能转化为付费用户如果不能就应该限制免费额度的使用范围或者选择成本更低的小模型承接。4.3 第二层单位推理成本是否异常排除收入问题后进入成本端。重点观察缓存命中率、平均单请求 token 数、GPU 利用率、每秒输出 token 数。在 vLLM 环境下可以通过 metrics 接口观察关键指标curl -s localhost:8000/metrics | grep -E avg_prompt_throughput|avg_generation_throughput|cache_hit如果缓存命中率为 0但业务中大量请求前缀相同说明缓存配置没有生效。如果 GPU 利用率很低但 max-num-seqs 很小说明批处理没有发挥作用。如果单次请求平均输出 token 数异常高说明 prompt 设计可能导致模型输出冗长建议从提示词层面限制 max_tokens。4.4 第三层资源池与调度是否造成闲置浪费大模型推理集群如果固定常驻很容易出现波峰和波谷。白天业务高峰 GPU 不够晚间闲时大量 GPU 空转。毛利率是月度结果空转成本同样计入营业成本。排查时先看集群资源时间线不同业务线使用的 GPU 是否独立维护导致资源无法复用。实验训练任务是否抢占推理资源导致推理 service 频繁扩容。是否配置了自动缩容或弹性策略。如果问题出在资源利用率解决方案通常是推理服务统一接入 Kubernetes按业务优先级调度训练任务使用独立队列或错峰执行闲时任务用 Spot 实例。4.5 毛利率排查清单检查层检查项正常信号异常信号收入层免费 token 占比小于 20%超过一半收入层按客户和渠道的收入统计可以下钻到 API Key只能看总量成本层缓存命中率高相似请求场景命中率大于 50%长期为 0成本层平均单请求 token 用量与业务场景匹配明显高于预期资源层GPU 利用率推理服务利用率大于 60%长期低于 30%财务层一次性采购摊销方式按资产折旧或合同期分摊一次性计入当期成本5. 改善毛利率的实践路径从技术动作到商业结果5.1 产品层提高付费浓度和单位 token 价值技术优化解决的是“省成本”但毛利率改善还有另一条腿就是“提收入”。同一个模型生成的 token在金融报告场景和在聊天机器人场景里的商业价值完全不同。技术团队可以参与的工作是帮助产品侧识别高价值用户和高价值场景设计更合理的计费套餐。例如面向高价值场景提供更强的模型和更长上下文收取更高费用面向普通用户提供低成本的短上下文模型。单位 token 收入提升了即使成本不变毛利率也会上升。这里的核心工具还是调用日志必须知道哪些用户产生了高毛利哪些用户在持续消耗免费额度。5.2 工程层把成本观测接入告警和变更流程成本问题不能等月底财务来看。推荐做法是把模型调用成本作为业务指标接入监控系统。下面是一段 Prometheus 告警规则示例用于在单次调用成本超过阈值时提醒groups: - name: llm-cost-alerts rules: - alert: ModelCostPerCallTooHigh expr: rate(model_call_cost_total[10m]) / rate(model_call_count_total[10m]) 0.02 for: 15m labels: severity: warning annotations: summary: 单次调用成本超过 0.02 元 description: 最近 10 分钟单次调用成本已达到 {{ $value }} 元请检查模型选择、缓存命中率和批处理配置。除了告警还应该把成本估算加入模型发布流程。每次新模型上线都要评估这个模型相比线上模型推理成本上升还是下降延迟能否接受效果提升是否值得成本增加如果效果提升只带来 1% 的准确率提升但成本翻倍就需要谨慎决策。5.3 财务与技术协同建立单位经济模型毛利率是财务结果但可以拆成技术变量。一个简单的单位经济模型可以表达为单次调用毛利 单次调用收入 - 单次调用成本 单次调用成本 单次 prompt token 成本 单次 completion token 成本下面用一张模拟表说明不同场景下的毛利率差异。数据仅用于说明思路不代表任何公司实际数据。场景单次收入(元)单次成本(元)毛利率关键假设纯大模型无缓存0.0100.00820%请求复杂度高无缓存命中大模型缓存0.0100.00460%缓存命中率 50%平均成本下降小模型承接简单请求0.0080.00275%60% 请求走小模型提高高价值场景定价0.0150.00566%高价场景占比提高这张表说明毛利率改善往往不是单一技术优化带来的而是产品定价、模型路由、缓存策略和资源利用率共同作用的结果。技术团队不能只盯着“模型强不强”还要能够把优化动作翻译成成本数据。5.4 长期能力模型变小、硬件变快、成本曲线下移长期看大模型单位成本有下降空间但下降并不是自动发生的。它依赖三个方向的持续投入模型训练更高效例如通过数据筛选、更小的模型架构保留同等效果。推理硬件迭代新的 GPU、专用加速卡和更优的互联拓扑。工程系统成熟包括调度、缓存、量化和资源池化。这些方向都需要投入研发资源本质上等于用当期成本换未来成本。毛利率落后的公司在周期早期未必是输家但必须证明自己能在成本曲线上跑出清晰的下行动线。否则当收入增长速度放缓低毛利就会立刻变成低净利甚至直接进入现金流风险区。6. 把毛利率当成技术架构的一组核心指标来对待6.1 技术人需要建立的三个习惯第一每次模型版本上线同时评估成本增量。不能只看效果指标还要把 token 成本、延迟、吞吐一起加入评审清单。第二让成本报表可以下钻到模型、用户、API Key。毛利问题必须能定位到具体业务线否则财务告诉你“毛利低了”你无法判断是哪个环节出了问题。第三把优化动作记录为可复用的成本基线。缓存命中率提升了多少量化后精度损失了多少路由策略减少了多少 token这些记录都可以作为后续迭代的参照。6.2 下一步可以继续研究的三个方向端侧模型和私有化部署对毛利率的影响推理发生在用户设备或客户内网平台承担的成本下降但产品定价模型也会变化。大模型训练成本与推理成本的投资节奏如何让训练投入不过度挤占当期毛利又不损害模型迭代速度。混合推理调度系统的完整实现从成本预测、路由决策到自动扩缩容的一体化方案。回到 MiniMax 的案例营收增长 283% 是一个值得关注的市场信号但在毛利率没有明显改善之前收入增长本身并不能证明商业模式已经跑通。对于技术团队来说更实际的做法是把自己的业务拆成同样清晰的成本结构收入是不是真的跟着高价值场景在增长推理成本有没有随调用量线性膨胀缓存命中率、批处理配置和模型路由是否已经被当成核心运维指标。这些问题看清楚了毛利率才不会只是个落后的财务数字。