企业官网建设流程全解析

这段时间在梳理大模型商业化落地时，看到智谱 2026 年上半年营收 9.54 亿元、同比增长 399.7%，归母亏损收窄至 20.71 亿元这组数据，感触挺深。大多数读者看到的是商业新闻，但对我们做大模型工程的人来说，这几个数字背后其实是模型调用量、Token 单价、GPU 利用率、推理成本和 FinOps 机制相互博弈的结果。

这篇文章不聊股价，也不做财务预测，而是把这组财报数据当成一个输入条件，拆解大模型公司从“营收高增长”到“亏损收窄”背后的技术账本。我会带大家完成三件事：

1. 把财务指标翻译成技术团队能执行的工程指标；
2. 用 Python 搭建一个营收、Token 调用量、GPU 利用率之间的敏感性分析模型；
3. 梳理大模型推理成本治理的常见手段和排查路径。

这套分析思路不局限于某一家公司，任何做大模型 API 服务、私有化部署或者模型应用开发的团队，都可以拿来复用。

1. 当财报成为技术团队的“体检报告”

1.1 数据背后的三个关键词：增长、价格与成本

“营收 9.54 亿元，同比增长 399.7%”，这句话翻译成技术语言就是：过去一年里，智谱对外提供的大模型服务在需求量上出现了接近 5 倍的增长。这里的需求量可以是 API 调用量、Token 消耗量、订阅用户数，也可以是私有化项目的数量。

“归母亏损收窄至 20.71 亿元”，关键在“收窄”两个字。它说明虽然公司整体还没有盈利，但亏损的绝对额已经比上一周期下降了。对于仍然处于高强度研发投入期的大模型公司来说，这通常意味着三个层面的改善：

• 单位收入对应的成本在下降，也就是“卖得越多、单位越赚钱”；
• 规模效应开始显现，算力、人力、销售费用被更大规模的收入摊薄；
• 经营效率提升，包括推理成本优化、交付流程标准化、资源利用率提高。

如果把财报当作一个系统的最终输出结果，那么模型效果、工程质量、成本控制、产品体验这些输入指标，最终都会在“营收”和“利润”这两个字段上暴露出来。

1.2 技术人为什么要关注财务指标

很多技术团队会认为财务数据是 CEO 和 CFO 才需要关心的事情。但在大模型公司，这个认知需要修正：推理成本直接决定了产品能不能定价、能定多少价、毛利是正是负。

举个例子，如果日均 Token 调用量增长了三倍，但 GPU 集群没有提前扩容，也没有做连续批处理优化，那么新增的流量反而会把服务打挂；如果为了追求模型效果，每次都使用超大杯模型处理简单分类任务，那么单位 Token 成本会高到产品根本无法盈利。

财务指标是技术工作的滞后指标。今天优化的推理引擎、缓存命中率、模型量化策略，会在下一个财报周期体现为毛利率的改善。反过来，从财报数据也能反推出技术团队必须完成哪些改进。

1.3 这篇文章能给你什么

我不会只停留在概念层面。接下来会提供：

• 一套可复制的财务指标到技术指标的拆解方法；
• 四个 Python 分析脚本，覆盖营收反推、Token 经济模型、价格敏感性和 GPU 利用率成本分析；
• 一份大模型推理成本优化清单；
• 一张常见财务异常与工程排查对照表。

建议你打开 Jupyter Notebook，一边读一边把代码跑起来，把里面的模拟参数替换成你自己业务的真实数据。

2. 把财务指标翻译成技术指标

2.1 从“营收”到“日均 Token 消耗量”

要理解大模型公司的营收，核心是理解它靠什么赚钱。常见收入来源包括：

如果一家公司的收入主要来自 API，那么营收可以近似拆成：

营收 = 各模型 Token 消耗量 × Token 平均单价

“营收同比增长 399.7%”意味着两种可能：

• 单价没有变，纯粹是 Token 消耗量涨了近 4 倍；
• 单价下降，但 Token 消耗量涨得更多，最终营收仍然高增长。

第二种情况在大模型行业更常见，因为 Token 价格战一直在持续。相当于“以价换量”，靠技术降本守住毛利空间。

2.2 从“亏损收窄”到“单位经济模型”

亏损收窄并不直接等于“收入变多了”，也可能是“成本结构变轻了”。技术团队需要关注的是单位经济模型：

单位 Token 毛利 = Token 单价 - 单位 Token 算力成本 - 单位 Token 其他摊销

如果 Token 单价在下降，但单位 Token 毛利没有继续恶化，说明算力成本下降的幅度至少跟上了价格下降的幅度。这是非常关键的工程信号。

要做到这一点，团队通常会在以下几个方向发力：

• 提高单卡吞吐量，让同样一张 GPU 卡承载更多请求；
• 通过量化、蒸馏降低模型参数量和推理开销；
• 使用 Prefix Cache 等缓存机制，减少重复计算；
• 削峰填谷，提高 GPU 集群整体利用率。

2.3 财务指标与技术指标映射表

为了让分析更落地，我把“财务指标”和“技术指标”做了一张对应表。你可以直接把它作为团队月度复盘时的参考框架：

不要直接把财务目标分发给研发同学，而是要把财务目标拆成“指标、责任人、动作”。比如“将日均 Token 成本降低 20%”，会比“提高毛利率 5 个百分点”更容易执行。

3. 大模型商业化的成本结构

3.1 单位 Token 成本的基本公式

大模型服务的成本通常由四部分组成：

总成本 = 算力成本 + 存储成本 + 网络成本 + 人力与平台摊销成本

算力成本是大头，尤其在使用高密度 GPU 集群时。单位 Token 成本则可以写成：

单位 Token 成本 = 总成本 / 有效 Token 输出量

这个公式看起来很简单，但要注意“有效”两个字。如果集群里有一半 GPU 在空转，或者请求排队但算力没有被打满，那么总成本没有减少，有效 Token 输出却在下降，单位成本自然升高。

影响 GPU 利用率的因素包括：

• 请求到达分布是否均匀；
• Batch 是否足够大；
• 推理引擎是否能动态调整 Batch Size；
• 显存是否成为瓶颈；
• 是否存在大量长上下文请求，导致 KV Cache 占用过大。

3.2 Prefill 与 Decode 的资源差异

在自回归大模型推理过程中，请求处理分为两个阶段：

• Prefill（预填充）：处理用户输入的提示词，并行计算量高，对算力需求大；
• Decode（解码）：逐 Token 生成输出，每一步依赖前一步结果，访存需求高，对显存带宽敏感。

如果让同一个 GPU 同时处理 Prefill 和 Decode，就会出现资源争抢。Prefill 密集的请求会拖慢 Decode 的响应速度，Decode 又会让 Prefill 阶段无法充分利用算力。

一种常见优化是“Prefill / Decode 分离部署”，将两个阶段拆到不同实例上，让算力型 GPU 专门处理 Prefill，让访存型 GPU 专门处理 Decode。这样做能明显提升整体吞吐，但也会增加系统复杂度，需要单独的调度器和队列。

3.3 KV Cache 是隐形成本大户

KV Cache 是自回归模型中存储历史 Key-Value 信息的显存区，随文本长度增长。这部分显存不直接产生“收益”，却是推理过程中必须付出的代价。

长上下文请求会让 KV Cache 占用剧增，导致单卡能并行处理的请求数变少。为了缓解这个问题，工程上通常采用：

• PagedAttention 机制，把 KV Cache 切成小块按需分配，减少显存碎片；
• Prefix Cache，当多个请求共享相同前缀时，直接复用前面已经计算好的 KV Cache；
• 上下文压缩 / 摘要缓存，把长历史压缩成更小的表示。

这些方案的核心都是“减少重复计算 + 提高显存利用率”。

3.4 模型侧的降本手段

除了推理引擎优化，模型本身也有很大的降本空间：

• 量化：把 FP16 权重压缩到 INT8 或 INT4，显存占用减少，推理速度提升；
• 知识蒸馏：用一个更大的教师模型训练更小的学生模型，降低部署成本；
• MoE 稀疏激活：虽然模型总参数很大，但每次推理只激活部分专家，计算量远小于相同参数的 Dense 模型；
• 模型裁剪：去掉不重要的层或头，缩小模型体积。

但要注意，降本不能牺牲用户体验。如果量化后模型效果显著下降，导致用户流失和调用量降低，最终总营收不升反降。“每单位成本下降”必须放在“模型质量不降级”的前提下来讨论。

4. 实战：用 Python 搭一个成本与营收分析模型

这一节我们直接上手写代码。所有脚本都按独立文件组织，大家可以根据自己的业务数据修改参数。

4.1 根据营收推算去年同期规模

假设我们拿到的数据是智谱 2026 年上半年营收 9.54 亿元，同比增长 399.7%，那么 2025 年同期营收可以算出来。

创建文件financial_summary.py：

# financial_summary.py # 根据已知财务数据推算去年同期营收 # 使用方法：python financial_summary.py rev_2026 = 9.54 # 单位：亿元 yoy_growth = 399.7 # 单位：% # 同比增长 399.7% 表示 rev_2026 = rev_2025 * (1 + 399.7 / 100) rev_2025 = rev_2026 / (1 + yoy_growth / 100.0) print(f"2026H1 营收: {rev_2026} 亿元") print(f"同比增长: {yoy_growth}%") print(f"推算 2025H1 营收: {rev_2025:.3f} 亿元") print(f"增长倍数: {rev_2026 / rev_2025:.2f} 倍")

运行结果：

2026H1 营收: 9.54 亿元 同比增长: 399.7% 推算 2025H1 营收: 1.909 亿元 增长倍数: 5.00 倍

这里要注意，同比增长 399.7% 并不是“增长了 4 倍”，而是“增长到原来的 5 倍”，也就是1 + 399.7 / 100 = 4.997。

4.2 从营收反推 Token 消耗量

如果智谱的营收主要来自 API 调用，我们可以用平均 Token 单价来反推全年的等效 Token 消耗量。由于我不知道智谱真实的 Token 价格和业务结构，这里的price_per_1k只是一个模拟参数，实际使用时要替换成你们业务的平均单价。

创建文件token_economics.py：

# token_economics.py # 从年度营收反推等效 Token 消耗量 # 注意：price_per_1k 为模拟示例值，请替换为真实业务数据 annual_revenue = 9.54 * 10**8 # 9.54 亿元，换算成元 price_per_1k = 0.02 # 每 1000 tokens 的综合收入，单位：元 # 例如 0.02 元/千tokens # 计算全年等效 Token 消耗量 total_tokens = annual_revenue / (price_per_1k / 1000) daily_tokens = total_tokens / 365 print(f"全年等效 Token 消耗量: {total_tokens:.2e} tokens") print(f"日均等效 Token 消耗量: {daily_tokens:.2e} tokens/天")

运行结果：

全年等效 Token 消耗量: 4.77e+14 tokens 日均等效 Token 消耗量: 1.31e+12 tokens/天

这个数字本身没有实际含义，因为真实的price_per_1k会随模型、渠道、客户类型变化很大。但这个方法可以用在任何定价场景里：只要把price_per_1k换成业务均价，就能快速得到量级认知。

4.3 Token 价格与调用量的敏感性矩阵

大模型行业经常出现“Token 降价 50%”的新闻。问题是：降价之后，营收能不能保持？答案是看调用量的增长能否覆盖价格下降。

创建文件sensitivity_analysis.py：

# sensitivity_analysis.py # 分析不同日均调用量、不同Token单价下的年营收 # 需要安装 pandas 和 matplotlib：pip install pandas matplotlib import numpy as np import pandas as pd import matplotlib.pyplot as plt # 设置中文字体，避免图表中文乱码 plt.rcParams['font.sans-serif'] = ['SimHei', 'Microsoft YaHei', 'Arial Unicode MS'] plt.rcParams['axes.unicode_minus'] = False # 模拟参数：日均调用量（亿 tokens / 天） daily_tokens = np.array([100, 200, 300, 400, 500]) # 模拟参数：每 1000 tokens 平均价格（元） price_per_1k = np.array([0.005, 0.01, 0.02, 0.04]) # 计算年营收（亿元） # 年营收 = 日均Tokens * 365 * (单价 / 1000) / 1e8 revenue_matrix = ( daily_tokens[:, None] * 365 * (price_per_1k[None, :] / 1000) / 1e8 ) df = pd.DataFrame( revenue_matrix, index=[f"{x}亿tokens/天" for x in daily_tokens], columns=[f"{p}元/千tokens" for p in price_per_1k], ) print("年营收矩阵（单位：亿元）") print(df)

运行结果会打印一个矩阵：

年营收矩阵（单位：亿元） 0.005元/千tokens 0.01元/千tokens 0.02元/千tokens 0.04元/千tokens 100亿tokens/天 1.825 3.650 7.300 14.600 200亿tokens/天 3.650 7.300 14.600 29.200 300亿tokens/天 5.475 10.950 21.900 43.800 400亿tokens/天 7.300 14.600 29.200 58.400 500亿tokens/天 9.125 18.250 36.500 73.000

这个矩阵的用途是：当营收目标（9.54 亿元）确定后，你可以反查“在某个单价下，需要做到多少日均调用量”。例如，如果综合单价只有 0.005 元/千 Tokens，要完成 9.54 亿元营收，日均调用量需要远超 500 亿 Tokens。这有助于我们判断“降价换量”的策略是否现实。

4.4 GPU 利用率对单位成本的影响

GPU 利用率是影响单位成本最直接的工程变量。下面模拟一个简化模型：集群总成本固定，有效 Token 产出与利用率成正比，观察单位成本曲线。

创建文件gpu_utilization_model.py：

# gpu_utilization_model.py # GPU 利用率对单位 Token 成本的影响 # 简化模型，演示优化方向 import numpy as np import matplotlib.pyplot as plt plt.rcParams['font.sans-serif'] = ['SimHei', 'Microsoft YaHei', 'Arial Unicode MS'] plt.rcParams['axes.unicode_minus'] = False # GPU 利用率范围：20% 到 90% utilization = np.linspace(0.2, 0.9, 50) # 假设集群日总成本固定为 100 万元 total_cost_per_day = 100.0 # 有效产出：利用率越高，单位时间产出的 token 越多 effective_output = utilization * 1000 # 单位：百万 tokens/天 # 单位成本：万元 / 百万 tokens unit_cost = total_cost_per_day / effective_output plt.plot(utilization, unit_cost, linewidth=2) plt.xlabel("GPU 平均利用率") plt.ylabel("单位 Token 成本（万元/百万 Tokens）") plt.title("GPU 利用率对单位成本的简化影响") plt.grid(True) plt.show()

运行后可以看到一条明显的下降曲线。利用率从 20% 提升到 40%，单位成本可能下降一半；但从 70% 提升到 90%，收益就逐渐趋于平缓。这说明成本治理的关键是把利用率从“很低”拉到“及格线”，而不是盲目追求 100% 利用率。

利用率也并非越高越好。如果为了追求利用率而无限增加队列长度，会导致响应时延变长，用户体验下降，最终影响营收。合理的做法是设置目标利用率区间，比如 60% 到 80%，超过阈值就扩容。

4.5 把模型应用到团队决策

上面几个脚本单独看都比较简单，但组合起来就是一个“财务-工程”联动分析模型：

1. 用 4.1 的脚本确认去年同期的营收基数和增长目标；
2. 用 4.2 的脚本把营收翻译成日均 Token 量，判断团队现有容量是否支持；
3. 用 4.3 的矩阵模拟调价后需要达到的调用量，辅助销售和运营定目标；
4. 用 4.4 的曲线分析当前 GPU 利用率是否有提升空间，判断降本重点。

建议在项目仓库中新建一个analysis/目录，把这些脚本放进去，并把真实参数抽到配置文件中，避免硬编码。

5. 从成本结构出发的优化手段

5.1 推理引擎层优化

当前大模型推理常用框架包括 vLLM、SGLang、TGI 等，它们解决的核心问题之一就是“如何把 GPU 用满”。以 vLLM 为例，PagedAttention 机制可以把 KV Cache 分割成固定大小的块，按需分配，减少了显存碎片和浪费。

连续批处理（Continuous Batching）也是一项关键能力。传统批处理要等一个批次的所有请求都结束，才处理下一个批次；连续批处理则允许随时插入新请求、及时让已完成请求退出，把等待时间变成有效计算时间。

除了框架选型，还要关注推理引擎参数：

不对参数做绝对推荐，因为它们高度依赖模型大小、请求长度分布和 GPU 型号，需要压测后确定。

5.2 请求调度与流量治理

真实的 API 流量是波动的。白天和晚上、工作日和节假日，调用量差距可能很大。容量规划必须考虑这种波动。

工程上可以采用：

• 请求优先级队列，付费高的客户请求优先处理；
• 多租户限流，避免单一用户打爆公共集群；
• 闲时任务错峰执行，把离线推理任务调度到低峰期；
• 请求合并，把相同 prefix 的请求聚到一起，提升缓存命中率。

这些手段的核心目的不是“压榨 GPU”，而是“让每一块 GPU 尽可能做有价值的计算”。

5.3 资源调度与弹性伸缩

在 Kubernetes 环境下运行大模型推理时，弹性伸缩策略会直接影响成本：

HPA / 自定义指标伸缩 → 按请求数或 GPU 利用率动态调整副本数

但模型加载、权重分发需要时间，弹性扩容不可能做到秒级。常用的做法是：

• 保留一个 Baseline 集群，应对日常流量；
• 使用 Serverless 或按量付费实例处理突发流量；
• 提前为大型促销活动或大客户上线做容量预留。

需要特别注意冷启动问题。如果扩容速度跟不上流量增长速度，用户请求会排队甚至超时，反而伤害营收。

5.4 FinOps 与成本归因

大模型公司的成本分散在多个项目、多个模型、多条业务线之间。如果没有清晰的成本归因，就会出现“人人都觉得成本高，但没人能说清钱花在了哪里”。

FinOps 实践的第一步是打标签。例如在 API 请求中强制携带request_id、business_line、model_name、user_id等字段，日志系统把每次请求的成本计算出来，按业务维度聚合。

推荐建立成本日报，观察以下指标：

• 各模型 Token 占比；
• 各业务线日成本趋势；
• 均价与单位成本差；
• 闲置 GPU 数量；
• 缓存命中率。

只有先“看得见”，才能“管得住”。

6. 常见问题与排查思路

6.1 成本居高不下，但调用量没有明显增长

可能性：集群存在大量空转 Pod，或者模型版本过旧导致推理效率低。

排查顺序：

1. 检查 GPU 利用率，如果长时间低于 30%，说明资源配置过剩；
2. 检查是否有未删除的测试服务；
3. 检查模型是否启用了 PagedAttention 和 Prefix Cache；
4. 对比不同模型版本的 Token 成本和响应速度。

6.2 GPU 利用率高，但响应时延也在飙升

可能性：队列堆积导致“看起来忙”，实际已过载。

排查方式：

• 观察队列深度和 P99 时延；
• 观察是否频繁触发 OOM 或显存交换；
• 如果利用率高但有效吞吐不涨，说明瓶颈在显存带宽或调度器。

解决思路是增加副本数，或启用 Prefill/Decode 分离部署，而不是继续压高 Batch Size。

6.3 Token 降价后，毛利反而恶化

可能性：调用量增长没有跑赢价格下降幅度，或者单位成本没有同步下降。

用文章里的敏感性矩阵即可判断：如果价格下降 50%，调用量至少要增长 100%，才能保持营收不变。如果调用量只涨了 30%，则需要通过成本优化把单位成本下降 40% 以上，才能保住毛利。

6.4 容量规划跟不上营收增长

可能性：没有建立财务目标和技术指标之间的联动机制。

建议：

• 每月更新一次 Token 消耗量和营收目标；
• 提前一个季度做容量预测；
• 在预测模型中引入“新模型上线”“大客户签约”等事件变量。

6.5 成本归因到团队时扯皮

可能性：成本台账缺少统一的标签规范。

解决方式是先制定资源标签规范，再通过财务系统强制校验，未打标签的请求不予以统计。宁可暂时“算不准”，也不能一直不“分账”。

7. 最佳实践与工程建议

7.1 建立 Token 级成本可观测性

如果公司正在做模型 API 服务，最好从第一天就把“单次请求成本”作为日志标准字段。每次请求记录request_id、model、input_tokens、output_tokens、cache_hit、price、cost等字段。这样未来做成本归因、价格调整、异常预警都有据可查。

7.2 让模型版本成为成本维度

每次升级模型，都不能只看效果指标，还要看单位 Token 成本。建议建立“模型版本成本评审表”，字段包括模型名、参数量、量化类型、单卡吞吐、单位成本、效果分、上线状态。

灰度发布时，同时观察新旧版本的成本差异。如果新模型效果提升有限，但成本高出 50%，就要谨慎上线。

7.3 每周做一次成本复盘

不需要很重，建议每周花 30 分钟看三个核心指标：

1. 日均 Token 量变化；
2. GPU 平均利用率；
3. 单位 Token 成本变化趋势。

如果单位 Token 成本连续两周上行，尽快定位是新模型问题、流量结构变化，还是资源配置问题。

7.4 警惕“为了降本而降本”

压缩模型、降低精度、删减缓存这些手段都有副作用。如果一个降本动作导致 P99 时延翻倍，或者模型准确率明显下降，那它带来的营收损失可能远超节省的成本。

每一项降本措施都应当设置一个“回滚条件”。比如“模型量化后准确率下降超过 1 个百分点，立即切回原版本”。

7.5 安全与合规底线

在做成本优化和资源变更时，必须遵循合法合规原则：

• 对生产环境的变更先在测试环境验证；
• 涉及清理资源、下线服务时，做好备份和审批；
• 保持最小权限原则，避免无关人员接触生产集群；
• 涉及客户数据时，确保脱敏和加密，不进行未授权访问。

成本治理永远是以安全为前提的，不能为了省钱而在安全边界上打折。

8. 总结：这组数据给技术团队的三点启示

第一，营收增长是需求真实性的证明。智谱 2026 年上半年营收达到 9.54 亿元，说明大模型服务已经不只是实验品，而是有企业愿意持续付费的生产工具。对技术团队来说，这意味着要把“稳定性”和“容量规划”提升到更高优先级。

第二，亏损收窄背后是单位经济模型的改善。没有技术侧的推理成本治理，Token 价格战会直接把毛利击穿。量化、缓存、连续批处理、利用率优化这些细节，最终会体现在财报的亏损数字上。

第三，财务和技术之间需要一座桥梁。这座桥梁就是指标拆解和成本模型。你可以从今天开始，先把本文的 Python 脚本跑起来，再逐步替换成真实数据，搭建你所在团队的 Token 经济分析大盘。

如果你正在做模型推理平台，建议下一件事是拉出最近 7 天的 GPU 利用率曲线和 Token 消耗曲线，看看它们是否匹配。很多时候，成本问题的答案就藏在这两条曲线的落差里。