一家从成立之初就把“深度学习”写进基因的公司能够在 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_count32, training_days15, price_per_gpu_hour20) 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_tokens50_000_000, price_per_million_tokens30) 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, jsonPAYLOAD, timeout60) cost_time time.time() - start return resp.status_code, cost_time if __name__ __main__: concurrency 16 with ThreadPoolExecutor(max_workersconcurrency) 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 推理服务用压测脚本观察吞吐量变化。第三复盘自己团队当前的项目交付方式整理出哪些能力可以平台化复用哪些流程可以标准化。大模型技术的迭代速度很快但成本控制、系统稳定性、数据安全这些工程问题是任何时代都不会过时的基本功。希望这篇复盘笔记能帮你少走一些弯路也让你的团队在追求效果的同时更早地建立起成本意识和工程规范。