企业官网建设流程全解析

开头先给一个判断：AI 这轮热潮里，钱并不是均匀“撒”给所有人的，而是沿着一条非常清晰的技术链路逐层汇聚。你问“AI 的钱，被谁赚走了”，其实是在问两件事：一是产业链上每一层到底从谁手里收到钱，二是这些收进来的钱最后能不能变成利润。前者看市场结构，后者看工程成本控制能力。对开发者来说，这个问题不是看热闹，而是决定了你应该在哪个技术栈上投入时间，给客户做方案时应该把预算放在哪里，以及做 AI 应用时为什么明明有流量却仍然亏损。

下面不从宏观叙事讲，而是从工程视角把这笔账拆开：算力、云、模型、推理、中间件、应用、交付，每一层分别靠什么赚钱，每一层的成本和坑在哪里，以及你作为开发者该怎么选择和排查。

1. 拆开 AI 产业链：钱沿着六层技术栈流动

1.1 六层模型先对齐，后面所有成本判断才有坐标系

要回答“钱被谁赚走了”，先得给产业链画一个完整分层。当前 AI 项目从底层到上层大致可以分为六层：

1. 算力硬件层：GPU、加速卡、服务器、液冷、机柜、数据中心。这一层生产 AI 最底层的算力资源。
2. 云计算平台层：在硬件之上提供虚拟机、容器、对象存储、网络、日志、监控、镜像仓库等基础设施服务。
3. 模型研发层：包括数据采集清洗、预训练、指令微调、人类反馈对齐、评测，以及开源模型的发布和迭代。
4. 模型服务与推理层：包括模型 API、私有化部署、推理服务网关、模型路由、多副本扩缩容，以及推理性能优化。
5. 中间件与工具层：向量数据库、RAG 框架、Agent 编排框架、提示词管理、可观测平台、成本治理平台。
6. 应用与交付层：面向 C 端用户的产品、面向 B 端的私有化项目、系统集成、咨询实施、定制开发。

这一层级的核心关系是：上层向下层购买服务，下层从上层获得收入。应用层向模型 API 付费，模型层向云计算平台付费，云计算平台向硬件厂商和机房付费。所以“谁赚走钱”本质上是一个成本逐级传导的过程：最顶层的应用一旦卖不动，最底层的硬件也会感受到压力，只是传导有滞后。

1.2 每一层的钱都来自“上一层预算”，不是凭空产生

把产业链看作资金流动，需要记住一条规律：每一层的收入，其实是上一层成本预算的一部分。C 端用户订阅费进入应用公司账上，应用公司拿出一部分作为模型 API 费；模型公司拿到 API 费后，又要把大部分花在云计算和训练算力上；云厂商收到钱后，还要支付硬件采购、机房租金和电力成本。

所以讨论谁赚钱，不能只看“收入最高的层”，还要看“利润率最高”和“现金流最稳”的层。很多企业收入高，但采购成本、研发成本、渠道成本同样高，最后账上不一定留下利润。而有些层看起来只是提供标准化资源，却能以更高的毛利、更稳定的订阅模式把钱留在手里。这一点对个人开发者和技术团队都有直接意义：选择在哪个层做事情，决定了你的成本结构，也决定了抗风险能力。

2. 算力与云：最确定的“收钱口”

2.1 GPU 成本以两种形态出现：买机器和使用云服务

AI 项目对算力的消耗是硬性的。训练一个大模型需要成千上万卡时，推理一个高并发应用需要持续占用的 GPU 实例。所以算力层是整条产业链中最先感受到钱的地方。

对开发者来说，算力成本有两种形态：

• 自购硬件：一次性采购 GPU 服务器，自己解决机房、电力、散热、运维、故障更换。优点是单位算力长期成本更低，缺点是前期资金压力大，扩缩容不灵活，设备折旧快。
• 使用云计算：按时或按量租用 GPU 实例，按秒计费，用完释放。优点是弹性和运维成本低，缺点是长时间稳定运行时，总费用可能超过自购。

在真实项目里，建议这样判断：短期实验、弹性波动大、团队运维能力弱，优先云；长期 7×24 小时满载运行、业务规模稳定、现金流能覆盖采购，再评估自购。不要只听“自购一定省钱”的说法，设备闲置率超过一定比例后，自购反而是最贵的方案。

2.2 云账单可以从四个维度拆开看

走进云厂商控制台，AI 项目的账单经常让人困惑。看起来没开多少台机器，为什么月末费用很高？这是因为云账单通常由四个部分组成：

排查云费用时，先不要看总账单，按“计算、存储、网络、服务”四个维度去看环比和按资源维度聚合。一个常见做法是给每个项目打资源标签，比如project=rag-service、env=prod，这样月末发现成本异常时，可以直接在账单里过滤出某个项目，而不是手动回忆哪些机器是哪个团队的。

2.3 云厂商收的“管理费”本质是封装成本

很多开发者问，为什么自己买 GPU 插在机房，比云上租同款便宜不少，还有那么多人选择云？原因在于云厂商赚的不是单纯“机器差价”，而是封装成本：电力和网络可靠性、故障处理速度、镜像和容器生态、按需扩容能力、安全合规基线。这些能力在小团队里很难自建，所以购买云服务本质上是在买“工程效率”和“稳定性”。

对个人开发者来说，不要为用不到的能力付费。比如单机实验环境，不需要开高可用多可用区架构；给客户做演示，不需要每台机器都绑弹性公网 IP。云资源的浪费几乎都存在同一类问题：按生产环境的规格申请，然后只用来跑一个周末实验。

3. 模型层：API、开源和自训练的账本

3.1 API 按 Token 计费，真正消耗钱的是上下文长度

模型 API 的计费模式大家都很熟悉：输入多少 token、输出多少 token，按单价结算。实际项目里，很多人忽略了两个隐性因素：长上下文的重复计费和输出长度的不确定性。

同样一个问题，如果 prompt 写了 5000 字，其中 4000 字是和本次查询无关的历史背景，那这 4000 字每次调用都会被计价；如果系统设计不好，每次请求都把整个对话历史完整发给模型，成本会随轮数线性增长。更隐蔽的是，模型可能会先输出思考过程再输出答案，如果“思考过程”也被计费，单次调用的实际支出可能比预期高好几倍。

写代码时可以做一个简单的成本预估函数，把调用次数、输入 token、输出 token 和单价统一起来：

def estimate_token_cost(calls, input_tokens, output_tokens, input_price, output_price): input_cost = calls * input_tokens * input_price / 1_000_000 output_cost = calls * output_tokens * output_price / 1_000_000 return input_cost + output_cost # 示例：假设每天 10 万次调用，平均每次输入 2000 token，输出 500 token per_day = estimate_token_cost(100000, 2000, 500, input_price=1, output_price=3) print(f"每天预估成本: {per_day:.2f} 元") print(f"每月预估成本: {per_day * 30:.2f} 元")

这个脚本不依赖任何具体模型，把“价格”当参数传入即可。实际落地时，你要把调用日志里的 token 字段采集起来，按天聚合，才能做真实成本预测。价格以模型服务方实时报价为准。

3.2 开源模型把“按调用付费”变成“按运维付费”

使用开源模型的账本和调用 API 不同。表面上模型权重是免费的，但成本转移到了几个地方：

• GPU 资源：开源模型推理需要自己部署，机器费用不会消失。
• 运维人员：模型版本的更新、推理服务的故障恢复、多副本扩缩容，都依赖人力。
• 优化成本：想让开源模型跑得快、并发高，需要做量化、批处理、内核优化，这些都需要有对应技术能力的工程师。
• 版本迭代：开源模型也在更新，每次重大版本升级都可能触发一轮回归测试和配置调整。

所以开源模型适合的团队是：有 GPU 运维能力，有明确的数据隐私要求，或者业务调用量足够大到 API 费用远超部署运维成本。如果只是做原型验证，不要一开始就自建推理服务，先用 API 把业务跑通，再评估迁移。

3.3 自训练的预算为什么难控

训练一个自己的模型，成本不只是 GPU 时长。数据标注、清洗、过滤、存储、实验追踪、失败重试都会产生费用。一次大规模训练失败，可能意味着已经投入的几周算力全部浪费。所以成熟团队会把训练成本控制前置：明确数据质量基线、做小规模实验确认收敛曲线、设定训练自动停止条件，而不是盲目把数据直接灌进大模型。

这给普通开发者的建议是：绝大多数业务场景不需要从零训练基础模型。需要做的是在开源模型基础上做指令微调或 RAG 增强。这部分成本通常远低于预训练成本，效果却更能贴近业务。

4. 都容易忽略的推理侧成本

4.1 推理成本为什么会逐渐吃掉应用利润

模型 API 看起来单次调用费用不高，但应用上线后，推理成本会从几个方向叠加：

• 用户量增长：每个活跃用户每天可能产生几十次调用。
• 上下文膨胀：多轮对话不裁剪历史，单次调用 token 不断变大。
• 失败重试：超时和报错后自动重试，重试同样产生费用。
• 无效调用：恶意刷接口、爬虫批量抓取、未鉴权的异常流量，都会变成账单。

许多 AI 应用的收入公式是“订阅收入 - 推理成本 - 服务器成本 - 人力成本”。如果推理成本占收入的比例超过 40%，这个产品就非常脆弱，因为流量越大亏损越多。所以推理成本不是后台优化问题，而是产品商业模式成立与否的关键。

4.2 五个可以落地的成本优化动作

在工程层面，建议按以下顺序优化：

1. 减少输入 token：用提示词压缩、减少无关历史、用摘要替换完整对话记录，是最直接的手段。
2. 使用上下文缓存：相同前缀或相同文档片段重复传递给模型时，很多模型服务支持缓存计费或更低的缓存命中价格，要开启并设计好前缀结构。
3. 模型分级路由：简单问题用轻量模型，复杂问题用能力更强模型。不要让每个请求都走最大模型。
4. 批量和异步化：非实时场景（摘要生成、批量分类、离线清洗）用批量处理，而不是逐个同步请求。
5. 限流和配额：给每个用户、每个接口设置明确配额，避免无界消耗。

一个通用的请求网关配置可以这样设计：

route: - pattern: /api/summary model: lightweight-model rate_limit: 100/minute context_cache: true - pattern: /api/agent model: strong-model rate_limit: 10/minute context_cache: true

配置只展示思路。实际项目要按模型服务商的接口协议和平台约定调整。

4.3 把成本观测做成系统能力，而不是月末看账单

优化成本的前提是能看见成本。不要只在收到月度账单时才发现费用异常。应该把 token 消耗作为业务指标接入日志系统，按用户、接口、模型、时间段做聚合。

下面是按天聚合调用数的示例，SQL 结构可以根据你的日志表调整：

SELECT DATE(created_at) AS day, model_name, COUNT(*) AS call_count, SUM(input_tokens) AS total_input_tokens, SUM(output_tokens) AS total_output_tokens FROM model_call_logs GROUP BY DATE(created_at), model_name ORDER BY day DESC LIMIT 30;

有了这张聚合表，就能回答三个关键问题：调用量是否在上涨、token 消耗是否在上涨、哪种模型在烧钱。成本治理的前提不是“省”，而是“归属清楚”。

5. 中间件与工具：许多人眼中的“卖铲人”

5.1 中间件靠什么赚钱

AI 产业链里，经常说做中间件和工具是在“卖铲子”。这不完全准确，因为中间件的商业模式也分几种：

• 开源免费 + 云托管收费：框架本身开源，托管服务按调用量或节点数收费。
• 开源免费 + 企业版收费：基础版免费，企业版提供权限、审计、高可用等能力。
• 全托管 SaaS：按数据量、存储量、API 调用次数收费。
• 私有化授权：大型企业一次买断许可，按环境数计费。

这些模式有一个共同特点：收费对象不是终端用户，而是开发者或开发团队。这意味着中间件产品不需要承担获客和教育市场的成本，只需要让开发者集成后能节省更多时间或成本，商业模式就容易立足。

5.2 自建与托管的成本分水岭

以向量数据库为例。一个内部 RAG 项目，如果数据量只有几万条，自建一个本地向量索引完全够用；但当数据量达到千万级、需要多租户隔离、需要稳定运维和监控告警时，自建成本就明显上升。

建议采用“先自建、规模扩大再迁移”的策略。原型阶段不要被中间件绑架，但在生产环境前，要把可迁移性考虑进接口设计，避免和某个中间件深度耦合，导致后续切换成本高。

5.3 什么才是真正稳定的“铲子”

做工具能持续获得收入的本质，不在于名字叫“AI 中间件”，而在于它是否解决了频繁发生、支付意愿明确的问题。被真正愿意埋单的领域，通常有三个特征：成本可度量、替换成本高、省下的人力或算力费用可量化。

例如成本治理工具，如果它能让一个项目每月云账单下降 20%，企业很容易算出收益；而一个概念上很先进但无法量化收益的 Agent 编排工具，就很难稳定收费。所以不要只问“做工具能不能赚钱”，要问“这个工具帮谁省了什么、省了多少”。

6. 应用层：能赚钱，但容易亏在工程细节

6.1 应用的单位经济模型先算清楚

应用层是离用户最近的一层，看起来最有机会建立直接收入，但也最容易出现“流量越大亏损越大”。要判断一个 AI 应用有没有盈利能力，建议先做单位经济模型：

单用户月毛利 = 单用户月收入 - 单用户月推理成本 - 单用户月服务器成本 - 单用户月客服成本

如果这个公式是负数，那么市场营销投入越多，亏损越严重。这时候不能认为是“增长还不够”，而要先降低模型调用成本，或者提升单用户付费。很多 AI 产品把精力花在增长上，却忽视了所有增长都在放大结构性亏损。

建议把单用户每日平均调用次数、平均输入 token、平均输出 token 纳入产品指标看板。一旦发现某类用户的 token 消耗显著高于付费用户均值，就需要限制或引导。

6.2 交付类项目赚的钱被什么吃掉

B 端交付是很多团队的实际收入来源，但交付项目的利润容易被这些环节吃掉：

• 定制化需求没边界：客户不断加需求，需求变更没有对应报价机制。
• 数据质量参差不齐：客户数据清洗成本远超预期，模型效果达不到演示水平。
• 多模型适配成本：客户要求适配不同模型，每个模型都要重新做评测和调优。
• 验收标准模糊：项目交付后，客户以效果不稳定为由延迟验收。

要把项目利润守住，核心是在合同中写清数据责任边界、需求变更流程、效果验收指标，并且在工程上把“定制部分”和“通用部分”分离。通用部分做成可复用的模块，定制部分按人天报价。这样即使单个项目毛利低，沉淀下来的模块也能降低下一个项目成本。

6.3 中小团队适合在哪一层切蛋糕

中小团队做应用，最大的优势是贴近场景、响应快。但不要试图同时覆盖工具、模型、中间件和应用。一个常见的稳健策略是：选一个现金流最好的环节，先建立收入，再决定是否往上下游延伸。

如果你擅长做行业 Know-how，可以做垂直应用，比如某个行业的知识库问答、审批辅助、报表生成；如果你擅长做工程基建，可以做内部效率工具、模型网关、数据管道；如果你擅长做模型调优，可以接一些微调和私有化咨询的业务。关键是每一单都要能覆盖算力成本、人力成本和获客成本，再谈规模。

7. 排查实战：AI 产品成本异常要从哪里开始查

7.1 Token 费用上涨的排查顺序

项目上线一段时间后，模型调用费用可能出现明显上涨。建议按这个顺序排查：

这里最容易被忽略的是“上下文膨胀”。对话类产品如果不设置最大轮数，或不在用户长时间不发言后重置上下文，很容易因为累计 token 过多而产生高额费用。建议在代码层面对每次请求的上下文做预算限制。

7.2 云账单上涨要从资源维度拆

云账单异常时，不要直接怀疑云厂商计价错了。先看资源维度的用量趋势：

# 查看当前所有实例及运行时长 # 具体命令以你使用的云平台控制台或命令行工具为准 # 下面只是检查思路，实际项目要结合云平台 API 和资源标签

检查项目标签、实例规格、创建时间，看是否有“实验集群一直没关”“开发环境按生产规格启动”“凌晨低峰没有定时关机”等常见浪费。云费用通常不是某一个资源贵，而是大量低利用率的资源叠加出来的。

建议每个项目至少做到三条：

• 给所有云资源打标签，账单可以按标签聚合。
• 给非生产环境的实例设置定时开关机。
• 每月导出账单明细，按资源和项目两个维度对比增幅。

7.3 用代码搭一套基础成本观测

不依赖第三方平台，利用现有日志也能搭一套轻量成本观测。关键是把 token 数据写到结构化日志里，然后聚合。

# 示例：记录一次模型调用的 token 计量信息 log_payload = { "timestamp": "2025-01-15T12:00:00+08:00", "user_id": "user_001", "service": "document-summary", "model": "model-name", "input_tokens": 3800, "output_tokens": 720, "cache_hit": True, "request_id": "req_12345", }

有了这样的记录，按天聚合后就能得到完整的消耗曲线。成本治理并不复杂，难的是持续记录并保持字段规范。

8. 落到实践：选择、检查、优化清单

8.1 启动 AI 项目之前先回答三个问题

每个 AI 项目在写第一行代码前，建议按成本视角确认：

1. 谁付费：这个项目的收入来自个人订阅、企业合同还是内部预算？收入来源决定了你能够承受多少推理成本。
2. 成本在哪里：模型 API、云资源、人力投入，哪一项占比最重？先控制最大项，而不是先省小钱。
3. 优化余地有多大：如果模型成本上涨，能否通过模型分级、上下文缓存、批量处理等方式找回空间？

这个问题清单虽然在立项阶段做，成本最省。等项目上线后再重构成本结构，往往要付出更大的工程代价。

8.2 从实验走向生产时要做的成本方案切换

实验阶段可以不做成本控制，怎么快怎么来。但一旦进入生产环境，至少要做这些切换：

• 模型请求全部经过网关，不直接调用底层 API。
• 所有模型调用统一记录 token 和调用结果。
• 每个用户或每个租户有配额限制。
• 生产环境和测试环境用不同模型实例或不同计费账号。
• 设置成本告警，超过阈值自动通知负责人。

这些措施不复杂，但能把失控的苗头扼杀在初期。很多人只在收到大额账单后才想到要治理，那时候已经很被动。

8.3 每年重新评估一次技术栈和成本结构

AI 技术栈变化很快，模型价格、开源模型能力、云产品形态都在持续更新。建议团队每年至少做一次成本结构复盘：当前模型是否还是最优选择、推理是否迁移到更便宜的实例、使用频率低的功能是否可以下架、缓存策略是否需要调整。

这听起来像经营建议，但它本质上是工程工作。成本是系统设计的一部分，不是财务部门的事。一个应用能在 AI 时代持续运转，依赖的是模型选型合理、请求链路可控、成本指标可见、异常消耗可追溯，这套能力比押中某个热门概念更持久。

回到最开始的问题：AI 的钱到底被谁赚走了。从工程视角看，短期确定性最强的是提供算力、云资源和基础模型服务的上游层；长期来看，真正能留下利润的是愿意把成本管清楚、把每一个调用都量化、把每一笔支出都归属到具体业务目标的团队。对于开发者和中小团队，最该做的不是追逐“最赚钱的一层”这个标签，而是确认自己的技术栈处于哪一层，把这一层的成本模型和优化空间吃透，再决定是否向上下游延伸。所有商业讨论背后，最终都要落到一张能对上的账单上。