一家从成立之初就把“深度学习”写进基因的公司，能够在 2026 年上半年首次实现盈利，这件事放在整个 AI 行业里，都是一个非常值得拆解的信号。大家通常看到的是“盈利”这个财务结果，但作为长期关注大模型工程落地的开发者，我更关心的是另一个问题：一家高研发投入的 AI 公司，到底做对了哪些技术决策，才能把算法研究、模型训练、推理服务、行业定制这些环节，从持续烧钱的状态，转变成真正可规模化的收入？
这篇文章想从这个事件切入，整理一份偏工程视角的复盘笔记。文章会围绕 AI 公司的成本结构、推理服务优化、模型部署和工程化管理展开，所有代码和配置均基于常见开源方案，可直接复用。如果你正在做大模型应用、后端服务，或者需要为团队的 GPU 成本做技术治理，这篇文章会比较适合你。文中所有示例只用于技术演示，不涉及商汤内部系统细节；关于财务数据的解读，也请以官方披露信息为准。
1. 为什么“AI 公司盈利”值得技术人关注
1.1 盈利的本质是技术定价得到了市场确认
很多技术同学对“盈利”这个词的第一反应是：这是财务的事情，和我们写代码、调模型的关系不大。但 AI 行业的情况不太一样。AI 公司的主要资产不是厂房和设备，而是算法、模型、数据以及把这些能力工程化的团队。一家 AI 公司如果说自己实现了盈利，本质上是在说：它的技术能力在市场上获得了持续付费的认可，并且这些收入已经可以覆盖研发成本、人力成本和算力成本。
以商汤为例，这家公司从计算机视觉起家，业务覆盖智慧城市、智慧商业、智能汽车等多个方向，后来又逐步布局生成式 AI 与大模型能力。早期的 AI 公司普遍面临一个问题：算法很强，但每接一个新客户，都要投入大量工程师去定制模型、清洗数据、适配场景。这类项目的毛利率往往不高，因为人力和算力都烧在了“一次性交付”上。如果 2026 年上半年真的能实现首次盈利，说明它的收入结构已经从“项目定制”逐步转向“标准化产品 + 平台服务”。只有标准化的技术产品，才能在边际成本递减的情况下持续产生利润。
1.2 从“烧钱换技术”到“效率换利润”
很多 AI 公司前期不盈利，不是因为技术不行，而是因为技术投入的回收周期太长。训练一个大模型需要消耗大量算力，推理服务每响应一次请求也在消耗算力，数据标注、算法研发、工程开发的人力成本更是一笔不小的开销。如果收入增长跟不上成本增长，公司就会长期处于亏损状态。
实现盈利，往往不是一个孤立的结果，它同时意味着三个环节发生了变化：
- 收入端：客户愿意为 AI 能力付费，且并非一次性项目，而是持续调用、持续订阅。
- 成本端：模型训练不再重复“造轮子”，推理服务的单位成本明显下降。
- 管理端：研发资源和算力资源的利用率得到提升，不再有大量空闲 GPU 或者重复开发。
所以，当我们复盘“AI 公司实现盈利”这个主题时，真正值得关注的是它背后的工程效率提升。无论公司规模大小，只要你的团队在提供模型服务，就会面临同样的问题：如何用更少的算力支撑更多的请求？如何降低单次推理的成本？如何把算法能力沉淀成可以复用的平台功能？这些问题的答案，才是技术人可以从行业案例中真正拿走的经验。
1.3 技术人得到的三个启示
结合商汤这类综合 AI 公司的成长路径，我认为技术人至少可以得到三点启示。
第一，技术能力必须和商业化产品绑定。算法再强，如果不能被 API、应用或解决方案封装起来，就很难产生持续收入。第二，成本优化要从第一天开始考虑。很多开发者在做模型服务时，优先关注效果和延迟，却忽略了 GPU 利用率和单位请求成本，等项目大了才发现推理成本高得惊人。第三，平台化是 AI 工程化的必经之路。把通用的模型能力沉淀成平台服务，把重复劳动变成标准化接入，是降低交付成本最有效的方式。
2. 盈利背后离不开的三条技术主线
2.1 训练成本：从重复建设走向集约化
训练成本是 AI 公司早期最大的开销之一。尤其是大模型出现之后，一次预训练往往要消耗成千上万张 GPU 卡时。对于任何一家公司来说，这笔支出都不可能无限持续。所以，当公司走向盈利时，大概率会做以下几个技术调整。
第一，减少重复预训练。大部分业务场景并不需要从头训练一个大模型，而是在已有基座模型上进行微调。基座模型处理通用语言理解，微调处理特定业务风格和领域知识，这样训练成本会下降一个数量级。第二，采用更高效的训练方式。比如 LoRA、QLoRA 等参数高效微调方法，只需要训练少量参数，就能让模型适配新任务，显存占用也远低于全参数微调。第三，建立模型仓库和版本管理，避免团队之间重复训练相似模型。
在实际项目中，我建议团队在启动任何“训练任务”之前，先问自己几个问题：这个任务真的需要重新训练吗？能不能用开源模型？能不能用微调解决？如果必须训练，数据量是否已经足够？这些判断看似简单，却能直接影响研发预算。
2.2 推理成本：利润表上的“隐形黑洞”
相比于训练成本的一次性投入，推理成本才是 AI 公司走向盈利时必须重视的“长期支出”。原因很简单：训练只发生在模型研发阶段，而推理服务是 7×24 小时都在运行的。每来一个用户请求，就需要 GPU 做一次前向计算。请求量越大，算力消耗越多，电费和服务器成本也随之增长。
很多开发者对大模型推理成本没有直观感受。一个 70 亿参数的模型，在 FP16 精度下权重占用内存大约 14GB；如果不做量化，一张 24GB 显存的显卡可能只能勉强跑一个模型；如果并发请求多了，还需要更大的显存来存放 KV Cache。换句话说，推理服务不是“部署完就结束”，而是要持续优化性能的长期工程。
从技术上看，降低推理成本的常用手段包括：模型量化、批处理、KV Cache 优化、动态早停、模型蒸馏、用小模型替代大模型等。这些手段可以组合使用，效果往往能在不显著降低效果的前提下，把吞吐量提升数倍。这也是为什么很多 AI 公司实现盈利后，外界看到的不仅仅是产品能力增强，还有毛利率的改善。
2.3 平台化与产品化：一次开发，多处复用
提到 AI 公司盈利，离不开“平台化”这个词。平台化解决的核心问题是：当算法团队投入大量资源训练好一个模型后，如何让这个模型在不同业务线、不同客户那里快速复用。
举个例子，一家公司可能同时需要人脸识别、OCR、文本审核、大模型对话等多个能力。如果每个能力都独立开发、独立交付，那每个项目都要投入新的工程资源。但如果把这些能力封装成标准 API 或平台服务，新客户接入时只需要申请密钥、调用接口，公司的边际交付成本就会大幅下降。
商汤过去在智慧城市、智慧商业等领域积累了大量视觉能力，后来又向生成式 AI 方向扩展，本质上就是在走“能力平台化”的路线。当底层能力可以复用时，每次新客户接入带来的收入，不需要再匹配同等规模的研发成本，利润空间就会自然扩大。
3. 用数据说话：AI 项目的成本模型拆解
聊完了概念，我们进入更具体的内容。这一节会给出一个简单但实用的成本估算模型。你可以把它用在自己的项目中，帮助团队量化训练和推理成本。注意，这个模型只用于辅助判断，实际账单请以云厂商和硬件供应商提供的价格为准。
3.1 训练成本估算脚本
先看训练成本。训练成本通常由三个变量决定：GPU 数量、训练天数和单卡每小时价格。我们可以把估算逻辑写成 Python 脚本。
# 文件路径：cost_estimate/training_cost.py def estimate_training_cost(gpu_count: int, training_days: int, price_per_gpu_hour: float) -> float: """ 估算一次模型训练的总成本。 :param gpu_count: 使用的 GPU 数量 :param training_days: 训练持续天数 :param price_per_gpu_hour: 单张 GPU 每小时价格，单位：元 :return: 训练总成本，单位：元 """ hours_per_day = 24 total_gpu_hours = gpu_count * training_days * hours_per_day total_cost = total_gpu_hours * price_per_gpu_hour return total_cost if __name__ == "__main__": # 示例：32 张 GPU，训练 15 天，单卡每小时 20 元 cost = estimate_training_cost(gpu_count=32, training_days=15, price_per_gpu_hour=20) print(f"预估训练成本：{cost:,.2f} 元")运行这个脚本，会输出：
预估训练成本：230,400.00 元这个数字说明，一次中等规模的训练任务就可能花费二十多万元。如果团队频繁重复训练类似模型，这部分开销会非常可观。所以，训练之前做成本预估，是很有必要的。
3.2 推理成本估算脚本
推理成本更适合按 Token 计算。对大模型服务来说，用户每次请求都在消耗模型的 Token 额度，所以我们可以根据日均 Token 量和单位 Token 价格来估算成本。
# 文件路径：cost_estimate/inference_cost.py def estimate_inference_cost(daily_tokens: int, price_per_million_tokens: float) -> float: """ 估算日均推理成本。 :param daily_tokens: 每天处理的 Token 总量 :param price_per_million_tokens: 每百万 Token 的成本，单位：元 :return: 每日推理成本，单位：元 """ daily_cost = daily_tokens / 1_000_000 * price_per_million_tokens return daily_cost if __name__ == "__main__": # 示例：每天处理 5000 万 Token，每百万 Token 成本 30 元 cost = estimate_inference_cost(daily_tokens=50_000_000, price_per_million_tokens=30) print(f"预估日推理成本：{cost:,.2f} 元")运行结果：
预估日推理成本：1,500.00 元一个月下来，单是推理成本就可能达到 4.5 万元。这还只是一个模型的估算，如果线上有多个模型、多个业务线共用，推理成本累加起来会非常惊人。
3.3 成本结构对比
我们用一张表来看不同环节的典型成本分布：
| 成本环节 | 触发时机 | 特点 | 典型优化手段 |
|---|---|---|---|
| 模型预训练 | 新模型研发阶段 | 一次性投入大，周期长 | 使用开源基座模型，减少重复预训练 |
| 模型微调 | 业务适配阶段 | 相比预训练成本低很多 | 使用 LoRA、QLoRA 等高效微调方法 |
| 推理服务 | 上线后持续运行 | 长期、持续，随调用量增长 | 量化、批处理、动态扩缩容 |
| 数据标注 | 模型迭代阶段 | 人力密集，容易失控 | 自动化标注、小样本学习 |
| 工程开发 | 全流程 | 人力成本最高 | 平台化、复用组件、低代码化 |
这张表的目的是帮团队建立“成本地图”。很多团队在做大模型应用时，只盯着模型训练成本，却忽略了推理服务和数据处理的成本，最后项目上线才发现运营成本远超预期。
4. 实战：低成本推理服务搭建与调优
这一节我们动手做一件事：用开源工具搭建一个大模型推理服务，并针对吞吐量和显存利用率进行调优。这套方案并不绑定任何商业平台，适合绝大多数具备 GPU 资源的研发团队参考。
4.1 服务架构与部署
先明确服务架构。这里采用一个常见的大模型服务链路：
用户请求 ↓ API 网关 / 业务后端 ↓ 推理服务（vLLM） ↓ GPU 显存 / 模型权重其中，推理服务负责加载模型、处理请求并生成回复。为了提升吞吐量，我们可以使用 vLLM 这类专门针对大模型推理做过优化的框架。它支持 PagedAttention、Continuous Batching 等特性，在同等硬件条件下，吞吐量通常比简单的 Transformers 直接推理高出数倍。
假设我们已经准备好一台带 GPU 的服务器，并安装了 Docker 和 NVIDIA 容器运行时。可以用下面的命令启动一个 OpenAI 兼容的推理服务：
docker run --runtime nvidia --gpus all \ -v ~/.cache/huggingface:/root/.cache/huggingface \ -p 8000:8000 \ vllm/vllm-openai:latest \ --model Qwen/Qwen2.5-7B-Instruct \ --served-model-name qwen2.5-7b \ --gpu-memory-utilization 0.85 \ --max-model-len 8192 \ --trust-remote-code注意，这里的镜像标签latest会随着时间变化，建议根据 vLLM 官方文档选择与你的 CUDA 驱动适配的稳定版本。另外，模型名称Qwen/Qwen2.5-7B-Instruct是开源社区中可获取的模型，实际使用时请按你团队选择的模型替换。
4.2 配置项解读
上面的启动命令里有几个关键参数，分别解释一下。
--model指定要加载的模型路径或 Hugging Face 模型名称。--served-model-name是给客户端调用的模型名，可以自定义。--gpu-memory-utilization表示模型最多可使用多少比例的 GPU 显存。设置为 0.85 意味着预留 15% 的显存给 CUDA 上下文和可能的波动，避免显存溢出。--max-model-len限制了模型最大上下文长度。这里设置为 8192，意味着模型可以处理最长 8192 个 Token 的输入和输出。--trust-remote-code允许加载部分模型仓库自带的代码，但要确保模型来源可信。
这里需要特别提醒的是：如果你的 GPU 显存较小，建议把max-model-len调低，或者选择更小的量化模型，否则容易在服务调用时遇到显存不足的问题。
4.3 压测与验证
服务启动后，我们可以写一个简单的 Python 脚本，模拟并发请求，观察服务的吞吐量和错误率。为了安全，压测请在测试环境进行，避免影响线上服务。
# 文件路径：benchmark/concurrent_test.py import time from concurrent.futures import ThreadPoolExecutor import requests URL = "http://localhost:8000/v1/chat/completions" PAYLOAD = { "model": "qwen2.5-7b", "messages": [{"role": "user", "content": "用一句话解释什么是大模型推理优化。"}], "max_tokens": 128, "temperature": 0.7, } def send_request(_): start = time.time() resp = requests.post(URL, json=PAYLOAD, timeout=60) cost_time = time.time() - start return resp.status_code, cost_time if __name__ == "__main__": concurrency = 16 with ThreadPoolExecutor(max_workers=concurrency) as executor: results = list(executor.map(send_request, range(concurrency))) ok_count = 0 total_time = 0.0 for status, cost in results: if status == 200: ok_count += 1 total_time += cost print(f"成功请求数：{ok_count}/{len(results)}") if ok_count: print(f"平均响应耗时：{total_time / ok_count:.2f} 秒")运行后，你可以观察到一个基本的性能基线。如果发现大量请求超时或返回错误，就需要回头检查显存、模型长度和并发参数。
4.4 优化前后对比
通过调整 batch 策略、启用 PagedAttention、选择量化版本模型，推理服务的吞吐量往往会有明显变化。下面是一张示意性的对照表，真实数据会因 GPU、模型和请求结构不同而有差异。
| 优化手段 | 预期效果 | 备注 |
|---|---|---|
| 连续批处理 | 提升 GPU 利用率，提高整体吞吐量 | vLLM 默认支持 |
| KV Cache 优化 | 减少显存浪费，支持更大并发 | PagedAttention 核心能力 |
| 模型量化 | 降低显存占用，加快计算速度 | 可能带来轻微效果损失 |
| 限制最大生成长度 | 避免单个请求长时间占用 GPU | 可按业务场景调整 |
这组优化的核心思路是：不要浪费 GPU。很多时候，推理服务吞吐量上不去，不是因为 GPU 算力不够，而是因为服务在空等请求、显存被无效占用、单个请求串行执行。把这些工程细节优化好，同样的硬件就能支撑更多的业务量。
5. 常见问题与排查思路
在部署和调优推理服务的过程中，团队通常会遇到一些很典型的坑。这里整理了一张排查表，方便你在遇到问题时快速定位。
| 问题现象 | 常见原因 | 解决思路 |
|---|---|---|
| 服务启动时报显存不足 | 模型过大或 max-model-len 设置过长 | 降低 gpu-memory-utilization 或换用量化模型 |
| 并发一高就大量超时 | 批量策略不合理，请求排队严重 | 检查连续批处理配置，调整队列限制 |
| 单次请求延迟高 | 输入长度或输出长度过长 | 限制 max_tokens，对长文本做切片处理 |
| GPU 利用率很低 | 请求分布不均或推理框架未启用优化 | 使用 vLLM、TensorRT-LLM 等框架 |
| 多模型切换频繁 | 缺乏模型缓存和多副本管理 | 用多个部署实例隔离模型，减少热切换 |
| 输出内容质量下降 | 量化过度或模型版本不一致 | 对比量化前后效果，评估是否可接受 |
如果你遇到“启动失败”的问题，还有一个很实用的排查步骤：先把模型参数和请求参数调到最保守状态，比如只允许一个并发请求、上下文长度设置为 1024，看服务能否正常运行。如果这样能跑起来，再逐步增大参数，定位是用哪个配置导致崩溃。这种二分法排查效率很高。
对于线上服务，我建议在代码层面加上完善的日志和监控。至少要在日志中记录请求耗时、Token 数、错误状态，方便后续做成本核算和故障分析。生产环境中的任何变更，包括模型版本升级、推理框架升级，都建议先在测试环境验证，再灰度发布。
6. 最佳实践与工程建议
6.1 建立成本台账
如果团队长期使用 GPU 资源，强烈建议建立一份成本台账，记录每一次训练任务和推理服务的资源消耗、价格和用途。有了台账，才能回答“钱花在哪了”和“哪一部分开销可以省”这两个问题。
台账并不需要很复杂，甚至可以是一份简单的表格，包含日期、项目、资源类型、GPU 卡时、预估费用、负责人等字段。每周统计一次，就能看到成本变化的趋势。很多成本问题，不是突然爆发的，而是随着业务增长、模块增多慢慢累积起来的，只有持续监控才能及时控制。
6.2 弹性扩缩容与实例管理
大模型服务的调用量通常有明显的高峰和低谷。如果团队始终按峰值流量购买 GPU 资源，必然会造成大量浪费。更好的做法是通过 Kubernetes 等容器编排平台，搭配 HPA 实现弹性伸缩。
下面是一个简单的 Kubernetes HPA 示例，基于 CPU 使用率实现自动扩缩容：
# 文件路径：k8s/inference-hpa.yaml apiVersion: autoscaling/v2 kind: HorizontalPodAutoscaler metadata: name: llm-inference-hpa spec: scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: llm-inference minReplicas: 2 maxReplicas: 10 metrics: - type: Resource resource: name: cpu target: type: Utilization averageUtilization: 70实际生产环境中，如果指标是 GPU 利用率，可以搭配 Prometheus Adapter 自定义指标。这里先不展开，思路是明确的：资源分配要动态化，不要静态预留。这里的 yaml 只是示例，应用时需要根据你的集群环境调整 API 版本和指标定义。
6.3 模型选型与数据安全
模型选型对成本和效果的影响是决定性的。很多场景其实不需要 70B 的大模型，一个 7B 甚至更小的模型配合 RAG 或知识库，就能达到不错的业务效果。小模型推理成本低、响应快，也更容易部署和运维。建议团队在需求评审阶段就明确效果基准，用最小可用模型跑通流程，再根据瓶颈决定是否升级模型。
数据安全同样需要从第一天就考虑。如果业务涉及敏感数据，尽量使用私有化部署或本地化模型，避免把数据发送到第三方平台。调用外部 API 时，要去标识化和脱敏。涉及数据库或线上系统的任何变更，都必须遵循最小权限原则，并在测试环境验证。
6.4 可维护性建设
最后，建议把推理服务当成正式产品来建设，而不是一个临时的“模型 Demo”。这意味着要规范 API 接口，文档要完整，模型版本要统一管理，日志要结构化，错误码要明确。只有服务具备可维护性，团队才能持续叠加新能力，而不是每次都在救火。
7. 总结与学习路线
回到最开始的问题：AI 公司从持续投入到实现盈利，靠的不是单一的爆款算法，而是一整套工程化能力。训练端减少重复建设，推理端降低单位请求成本，产品端实现平台复用，三件事环环相扣。对于普通开发者和研发团队来说，商汤实现盈利这件事带来的最大价值，是帮我们画出了一张“AI 工程效率”的路线图。
如果这篇文章能带给你行动上的启发，我建议从三件事开始做起：第一，用文中第三个章节的成本脚本，给自己团队的项目算一笔账，搞清算力成本花在哪。第二，在测试环境部署一次 vLLM 推理服务，用压测脚本观察吞吐量变化。第三，复盘自己团队当前的项目交付方式，整理出哪些能力可以平台化复用，哪些流程可以标准化。
大模型技术的迭代速度很快，但成本控制、系统稳定性、数据安全这些工程问题，是任何时代都不会过时的基本功。希望这篇复盘笔记能帮你少走一些弯路，也让你的团队在追求效果的同时，更早地建立起成本意识和工程规范。
