大模型“第二股”新叙事：从技术领先到商业工程化

最近讨论圈里热度很高的一条消息，是月之暗面（Moonshot AI）与 IPO 的传闻。很多开发者第一次听到这个名字，是因为 Kimi 智能助手。又一家大模型公司可能要走向公开市场，这自然让人想起资本市场常说的“大模型第二股”。不过在动辄谈估值和新闻热点之前，我觉得更值得技术从业者关注的，是整个大模型赛道正在切换叙事方式：以前讲模型能力、跑分和融资额，如今必须讲收入、毛利、客户留存和工程化能力。本文不构成任何投资建议，只想从技术研究和应用开发视角，拆解这类公司走向 IPO 时面对的难题，也聊聊作为工程师，我们可以用什么方法去观察、评估和参与这场变化。

1. 从一条 IPO 传闻说起

1.1 为什么“第二股”比“第一股”更难讲

先解释一下背景。月之暗面是大模型创业公司中的高关注度团队，Kimi 是其核心产品，早期给外界留下最深的印象是超长上下文处理能力。最近如果消息属实，它可能成为“大模型第二股”。

所谓“第二股”，通常是指继某个被市场公认的“大模型第一股”之后，第二家以类似概念冲刺资本市场的公司。对普通用户来说，谁第一谁第二也许只是谈资，但从资本市场角度看，“第二股”往往比“第一股”更尴尬。原因在于“第一股”的价值是定义了赛道，市场会愿意给它一点稀缺性溢价；而到了“第二股”出现时，投资人已经见过同类型公司，估值预期会更冷静，疑问也更直接：上一家的收入结构是怎样的？用户增长是否真实？推理成本降下来了吗？如果这些答案都还不清晰，后上市的公司就必须给出比第一股更完整的商业叙事，否则上市后的股价波动压力会很大。

技术圈很容易把这类新闻理解成“资本游戏”，但从工程师视角看，大模型公司的商业叙事最终会一层层传导到技术选型、API 价格、开源策略和开发者工具上。比如一家公司如果要对投资人讲清楚“我的毛利率会改善”，它必然要优化推理引擎、部署方式、上下文缓存策略等底层工程。这些工作，本质上和我们平时做服务端性能优化是同一件事。

1.2 从技术叙事切换到商业叙事

过去几年，大模型公司的标准叙事可以概括为技术叙事：我们训练了多少参数、在多少个评测集上拿了第一、上下文窗口能做到多长、吸引到多少顶尖研究员。这种叙事对技术媒体和开发者社区非常有效，因为它能快速建立“技术领先”的印象。

但 IPO 阶段需要的是商业叙事。商业叙事通常要回答几类问题：收入来自哪些客户群？收入是否有合同和续约作为支撑？单次模型调用背后的成本是多少？随着用户规模增长，边际成本是下降还是上升？为了支持这些回答，公司需要把技术资产转化为可量化、可审计的经营数据。很典型的例子是 Token 消耗量。如果一家公司只能证明自己模型“跑得快”，却无法证明每百万 Token 有合理毛利，那它就很难给出稳定预期。

所以我理解“大模型第二股需要新叙事”这句话的重点，不在 IPO 本身，而在“新叙事”。它意味着大模型公司不能只做实验室里的模型发布者，而需要变成一家具备完整产品、销售、交付、服务能力的技术公司。对开发者来说，这未必是坏事，因为当模型公司开始重视工程化和商业化时，API 的稳定性、文档的完整度、工具链的易用性通常也会跟着改善。

2. 大模型公司的收入与成本模型

2.1 常见的收入模式

要理解大模型公司如何走向 IPO，首先要拆开它的收入模型。不同定位的大模型公司，收入结构差异很大，但大体可以归为四类：面向个人用户的订阅服务、面向开发者的 API 服务、面向政企客户的私有化项目，以及面向具体场景的 Agent 解决方案。

用户更容易感知到的是前两类。C 端订阅的关键不是“有多少注册用户”，而是“有多少用户愿意持续付费”，因为 AI 助手的留存率与使用频次高度相关。API 服务的关键则是“开发者的调用量能否持续增长”，一个只用来做演示的 Key 不会带来商业价值，只有嵌进真实业务系统、每天稳定产生调用的 Key 才对收入有实质贡献。

从大模型公司筹备 IPO 的角度看，最理想的状态是收入呈现多元化且具备可预测性。比如一部分收入来自大客户的年度合同，一部分来自个人用户的月度订阅，一部分来自开发者的按量计费。这样的结构更能支撑可持续增长，也更容易让资本市场理解。

2.2 成本结构与 Token 经济学

大模型公司的成本大头集中在算力、人力、数据获取和获客四个方面。其中算力又分成训练算力和推理算力，普通用户往往高估训练成本的影响，却低估推理成本的长期压力。

为什么这么说？因为训练是一次性投入，模型训练完成后，只要不频繁重新训练，这部分成本会逐步被摊薄。推理则是每一行对话、每一次 API 调用都在发生的成本。对于一个日调用量达到亿级的大模型平台，推理成本会变成一项持续烧钱的费用，直接影响公司毛利率。这也是 OpenAI、Anthropic 以及国内头部大模型厂商都极其重视推理优化的根本原因。

理解 Token 经济学是开发者评估模型成本的第一步。一个用户在对话中发送的文本会被切分成 Token，模型生成的回复也是 Token。总的计费量通常是“输入 Token 数 × 输入单价 + 输出 Token 数 × 输出单价”，因为输出 Token 需要逐字生成，计算成本通常比输入更高。下面是一段简单的成本估算脚本，可以帮助团队在调用模型前先算清每笔对话的边际成本：

# cost_simulator.py def estimate_call_cost( prompt_tokens: int, completion_tokens: int, input_price_per_million: float, output_price_per_million: float, ) -> float: """ 估算一次模型调用的成本。 价格单位：元/百万 Token，这里仅作为演示占位。 """ input_cost = prompt_tokens / 1_000_000 * input_price_per_million output_cost = completion_tokens / 1_000_000 * output_price_per_million return round(input_cost + output_cost, 6) if __name__ == "__main__": # 假设输入 5000 token，输出 1000 token cost = estimate_call_cost( prompt_tokens=5000, completion_tokens=1000, input_price_per_million=12, output_price_per_million=12, ) print(f"单次调用成本约：{cost} 元")

这个脚本只是演示思路，真实价格请以模型开放平台为准。把它扩展到业务层面后，你可以再乘上日活用户数和人均对话轮次，得到一天的推理总成本。很多团队低估了 prompt 长度对成本的影响，因为每次请求都会携带 system prompt、历史对话和工具定义，输入 Token 很容易快速膨胀。优化方向包括裁剪历史消息、短化 system prompt、使用上下文缓存复用等。

2.3 用单位经济模型衡量可持续性

对于准备走向资本市场的公司，单看总收入和总成本还不够，创业公司早期的总亏损通常无法避免，关键是亏损能否收窄。于是“单位经济模型”就成了判断模型公司健康度的重要工具。

我们可以把单位经济模型粗略写成：

单用户月毛利 = 单用户月收入 - 托管与推理成本 - 获客摊销 - 客服与支付费用

单用户月收入又由付费率和客单价决定，推理成本则由人均 Token 消耗量和单位 Token 成本决定。以 C 端智能助手为例，如果平均每个付费用户每天产生 5 万 Token 调用，一个月就是 150 万 Token；在单位 Token 成本不变的前提下，用户倍数增长会带来推理成本的同步增长，如果没有用技术手段把单位 Token 成本压低，公司会陷入“用户越多亏得越多”的状态。

这也解释了大模型公司为什么总在发布会强调“成本降低到原来的几分之一”。不只是为了宣传，更是为了证明公司找到了可持续经营的路径。站在这个角度看，算法工程师、推理优化工程师和平台开发者在 IPO 叙事里的作用非常大：他们不是后台角色，而是直接决定公司商业模式能否成立的执行者。

3. 商业故事背后的技术支柱

3.1 长文本、多模态与场景化能力

Kimi 被外界记住，很大程度上是因为长上下文处理能力。长文本能力解决的是“用户能不能把一个 20 万字的文档一次性丢给模型”的问题。这种能力在许多知识密集型行业都有实用价值，例如合同审核、招股书分析、论文阅读、代码库理解。

但长文本能力本身还不是商业模式。它需要转化为具体场景中的“任务完成能力”。同样的上下文窗口，用户可能只是用来做一次文档总结，也可能用来自动执行一个跨多个文档的审核流程。前者的客单价很低，后者的客单价会明显更高。因此，大模型公司的新叙事不能停留在“我的模型能读多长”，而要展开为“在我的模型帮助下，用户以前需要 2 小时完成的文档工作，现在 2 分钟就能完成并且结果可校验”。

类似的逻辑也适用于多模态能力。多模态让模型能处理图片、音频和视频，但资本市场更关心这些能力能否被嵌入到产品流程中。比如一张票据照片能不能直接转成结构化财务数据，一段客服录音能不能自动生成工单摘要。技术能力只有附着在真实业务问题上，才会形成收费基础。

3.2 推理成本：掐住毛利的技术命门

推理成本归根结底是一个工程问题。模型参数规模越大、上下文越长、并发越高，推理资源消耗就越多。为了降低单位成本，工程团队通常从几个层面入手：使用高吞吐推理框架如 vLLM、SGLang、TensorRT-LLM；对模型做量化压缩；优化 KV Cache 以提升显存利用率；在长上下文场景使用前缀缓存。

对业务开发人员来说，前缀缓存是最容易感知到的优化。很多应用在每次请求时都会携带一大段完全相同的 system prompt 或企业知识库内容，如果推理平台支持 prompt caching，相同前缀的 KV Cache 可以被复用，后续请求的延迟和成本都会下降。反过来，如果团队不关注消息结构，每次都让相同长文本重新参与计算，账单自然只会涨不会降。

在这个意义上，模型公司能够把推理成本做到多低，直接决定了它的 API 定价有没有竞争力。这也是推断一家公司能否走到 IPO 后仍然健康运营的重要观察点：它是否有长期优化基础设施的团队，而不只是有一张参数漂亮的模型卡。

3.3 Agent、开发者生态与可编程性

再往后的叙事增长点大概率是 Agent 和开发者生态。传统 API 的商业模式是“按调用次数收钱”，模型回答得越多，收入越高，但单个请求的付费上限也有限。Agent 化应用则可能会改变这种模式，从“卖 Token”变成“卖任务结果”，用户购买的不是一次文字生成，而是“自动完成一个数据报表”“自动回一封邮件”的能力，付费意愿和客单价都会发生变化。

Agent 化对技术能力的要求包括工具调用（function calling）、结构化输出、代码执行能力和记忆能力。这些能力会导致模型厂商的平台属性增强：模型不只是回答问题，还要通过工具访问外部系统，读数据库、调接口、操作后台。因此，API 的设计是否稳定、文档是否完整、是否支持流式输出、是否提供错误码和监控后台，会变得越来越重要。开发者生态建设也将成为模型公司无形资产的一部分，API 调用规模的持续增长就是最有说服力的平台指标。

4. 从开发者视角看一个“可用的模型平台”

4.1 评估清单：不要只看跑分和发布会

我们平时要接入某个大模型平台的 API，不能只看它发布会的演示效果。演示环境通常经过挑选，无法代表真实业务场景。更靠谱的方法，是以一个业务任务为基准做对比测试，并且关注下面几项清单。

值得注意的是，现在很多大模型厂商提供“OpenAI 兼容接口”，这让业务代码可以先跑在任意兼容服务上，后续再迁移到其他服务或本地部署环境，只要修改 base_url、api_key 和 model 即可。这种良好的兼容性本质上也是在降低开发者的切换成本，大模型厂商互相之间的竞争，对最终用户属于利好。

4.2 最小可运行的接入示例

下面用一个 Python 示例演示如何接入常见的 OpenAI 兼容接口。代码本身不绑定任何特定厂商，你需要根据所选平台填写环境变量，并把请求模型名改为平台实际提供的模型标识。不要将 API Key 硬编码在代码中，这不仅容易泄露，也会给团队留下安全风险。

# client_demo.py # 先安装依赖：pip install openai import os from openai import OpenAI # 从环境变量读取平台地址与密钥 client = OpenAI( api_key=os.getenv("LLM_API_KEY"), base_url=os.getenv("LLM_BASE_URL"), ) response = client.chat.completions.create( model=os.getenv("LLM_MODEL", "your-model-id"), messages=[ { "role": "system", "content": "你是一个合同风险审核助手，请只输出结构化摘要。", }, { "role": "user", "content": "请抽取付款条款、违约责任、争议解决方式。", }, ], temperature=0.2, timeout=30, ) print(response.choices[0].message.content)

运行前要设置环境变量。在 Linux 或 macOS 下可以直接执行：

export LLM_API_KEY="your-api-key" export LLM_BASE_URL="https://your-model-provider.example.com/v1" export LLM_MODEL="your-model-id" python client_demo.py

这个示例看起来很简单，但它体现了一个核心观点：大模型平台的竞争力往往体现在工程细节上。如果一家公司的 API 文档足够清楚、响应结构足够稳定、限流策略足够合理，开发者接入的成本就会显著降低。一个有多家模型供应商可以自由切换的团队，在商务谈判和模型选型上也会有更大底气。

4.3 平台能力中隐藏的商业信号

开发者在调用大模型 API 时，其实可以从接口设计反向推断这家公司的经营思路。比如是否提供 budget 或 max_tokens 控制？是否支持流式输出？是否允许开发者在请求中打开“缓存开关”？是否有用量明细报表？这些功能看似都是“开发体验”，但背后反映的是公司对基建设施的投入程度。

进一步说，成熟的模型平台会认真处理计量计费，因为大模型调用一旦进入生产环境，Token 用量就是直接成本。如果计量不清晰、请求记录缺失，企业用户很难向财务解释账单。反过来，平台若提供清晰的可观测能力，比如每条请求消耗了多少输入 Token 和输出 Token、缓存命中情况如何，会让开发者更信任平台。这种信任正是模型公司能够持续获取增量收入的基础。

5. 私有化部署不等于省钱

5.1 本地快速体验：Ollama

很多团队在关注大模型厂商消息的同时，也会关心能不能用自己的机器跑开源模型。这种思路适合做原型验证、隐私要求高的场景，以及学习大模型工作机制。个人开发者最常用的工具之一是 Ollama，它把模型下载和运行封装成了类似 Docker 的命令行操作。

# 这里以 qwen2:7b 为例，实际模型名请根据环境自行确认 ollama pull qwen2:7b ollama run qwen2:7b

执行后会进入一个交互式对话界面，你已经在本机完成了一次大模型推理。Ollama 的优点是简单易用，适合快速测试；缺点是默认面向单机场景，缺乏生产环境所需的完善监控、高并发队列、弹性伸缩等能力。

5.2 生产环境推理：vLLM

如果需要把开源模型部署为可供团队内部调用的 HTTP 服务，可以考虑 vLLM。vLLM 在推理吞吐和显存利用方面做了大量优化，也经常被团队用作 OpenAI 兼容服务的基础。启动一个 OpenAI 兼容接口的大致思路如下：

# 注意：模型路径需要替换为真实存在的模型目录 vllm serve /data/models/Qwen2.5-7B-Instruct \ --host 0.0.0.0 \ --port 8000

服务启动后，客户端可以通过 http://localhost:8000/v1 访问 OpenAI 兼容接口。不过 vLLM 有比较陡峭的学习曲线，涉及模型格式、量化方式、并发参数、可用显存等配置，团队需要有一定的基础设施能力才能在生产环境把它跑稳定。

5.3 GPU 资源分配与 Docker

实际落地时，GPU 资源通常需要与 Docker 配合使用。通过 GPU 设备参数可以限制容器能看到哪些显卡，再通过共享内存、模型目录等挂载项完成部署。下面仅给出一段说明性命令，具体参数需要根据所用镜像和宿主机环境调整。

docker run --runtime nvidia --gpus '"device=0,1"' \ --shm-size=16g \ -v /data/models:/models \ -p 8000:8000 \ vllm/vllm-openai:latest \ --model /models/Qwen2.5-7B-Instruct

使用 --gpus 参数可以避免容器占满宿主机所有显卡，在多团队共享 GPU 时尤其重要。无论使用哪种部署方式，都建议先在测试环境验证，再逐步引入生产流量。

5.4 私有化的真实成本

许多企业在了解本地部署大模型后会默认“私有化更省钱”，但这个结论并不绝对。私有化确实规避了按 Token 计费的模式，但会带来新的成本：GPU 服务器采购或租用成本、运维人员成本、模型升级成本、GPU 利用率管理成本等。如果企业每天只有少量调用，使用云端 API 往往更划算；只有当数据合规要求、调用量规模、私有网络环境等条件都满足时，本地部署才具有明显优势。

判断一个模型公司是否“靠谱”，也可以从它提供的私有化方案看出端倪。如果它能够交付清晰的部署文档、提供容器化安装包、支持与现有权限系统集成，说明公司在客户成功层面有投入。这也是从技术叙事转向商业叙事的重要证据。

6. 大模型公司评判中的常见误区

资本市场会讲故事，技术圈也容易被概念带着跑。在观察大模型公司时，要留意下面几个典型误区。

第一个误区是把“上下文窗口很长”等同于“模型能力很强”。长上下文只说明模型可以接受更多输入，但用户在长文本中的信息召回能力、推理准确率并不是窗口越长就一定越好。对于具体业务，真正的验证方式是构造贴近线上场景的测试集，看看模型能否在长文档里准确找到被隐藏的关键约束。

第二个误区是把公开评测榜单排名当作商业潜力。榜单体现的是某一时刻的静态能力，商业潜力的核心是持续迭代速度、服务可靠性和用户付费意愿。一个评测集第一的模型，可能因为 API 限流过高、响应不稳定而无法在业务中落地。

第三个误区是默认开源模型“免费”。开源模型通常可以免费下载权重，但部署、运维、GPU 资源、后期调优都是成本。完全忽视运维成本，是很多企业私有化部署踩坑的起点。

第四个误区是认为 Agent 可以完全替代人工。当前 Agent 适合处理边界清晰、流程固定的任务，比如定时抓取数据并生成摘要；但在复杂长尾场景中，仍需要人工审核兜底。如果公司叙事把 Agent 描述成万能工具，反而需要谨慎。

这些误区不仅适用于“如何评价一家大模型公司”，也适用于我们日常做技术选型。少看宣传话术，多用低成本、小范围的对比实验去验证，是工程师避免被概念裹挟的最好方法。

7. 团队落地的最佳实践

7.1 在业务代码中做模型层抽象

团队在接入大模型时，最怕的是业务代码直接绑定某个厂商的私有 SDK。一旦模型涨价、接口变动或出现更好选择，替换成本就会很高。建议在项目早期引入一个轻量模型网关层，封装统一的模型调用接口。

比较稳妥的做法是让所有业务代码依赖 OpenAI 兼容接口格式，然后通过环境变量切换 base_url 和 api_key。对于测试场景，甚至可以切换到一个本地 Mock 服务，让依赖大模型的单测可以在没有网络和 Key 的情况下运行。另一个务实方向是采用模型路由：简单意图走便宜的小模型，复杂思考走更强的模型，从而在成本和效果之间取得平衡。

7.2 把 Token 消耗变成可观测指标

很多团队上线了大模型功能，却对成本没有感知，这是比较危险的事情。建议在模型调用层统一记录每次请求的模型名、输入 Token、输出 Token、缓存命中状态、响应耗时和错误码，并把数据发送到监控平台。只有先有了数据，才能回答“这个功能一个月花了多少钱”“哪个用户最消耗资源”“哪段 prompt 让成本居高不下”等问题。

在此基础上，可以针对不同功能设置预算阈值。当某条业务线的 Token 消耗出现明显波动时，第一时间告警。成本问题如果等账单出来再复盘，往往已经晚了。大模型功能的成本治理应该像日志监控和性能监控一样，成为研发流程的一部分。

7.3 跟踪模型版本与价格变化

大模型行业变化很快，版本迭代周期短，价格也经常调整。团队应建立一个模型版本更新跟踪机制。一种做法是在每次升级模型版本时，先对完整的评测用例集跑一遍，对比输出质量变化；另一种做法是设置灰度切流，让少量真实流量先使用新版本，观察用户反馈和错误率再全量更新。

同时在代码中避免硬编码不必要地依赖旧模型能力。如果模型供应商下线某个历史版本，而业务系统没有任何兼容层，可能会在小概率情况下出现不可用风险。比较好的实践是提前了解平台版本下线时间表，在迁移窗口内完成验证和切换。

8. 小结：比起追叙事，先练基本功

关于“月之暗面 IPO”这类消息，最值得关注的不是公司本身，而是它背后代表的大模型商业化进程。过去我们习惯把大模型看作一项技术，但技术和商业之间还隔着大量工程化细节：推理成本能不能降，API 能不能稳定支撑业务，私有化部署方案能不能交付，开发者生态能不能留存。这些细节决定了叙事最终能不能兑现。

作为一个技术人员，与其在新闻评论区争论“估值合理不合理”，不如用一套自己的方法去验证。比如选定一个真实业务场景，调用不同平台的 API，记录输出效果和 Token 消耗；或者用 Ollama、vLLM 在本机部署一个小模型，模拟从模型下载到接口服务的完整链路，看看哪些环节容易踩坑。这些动手实验积累的判断力，比看任何财经分析都有价值。

如果你也关注大模型应用开发和部署这件事，建议把 Token 成本测算、模型抽象、私有化部署这几个基本功先练扎实。无论哪家公司成为“大模型第二股”，这些能力都会是技术团队长期受益的基础。欢迎在评论区聊聊你正在做的模型接入场景，以及你在本地部署和 API 调用上踩过哪些坑。