企业官网建设流程全解析

这两年身边聊 AI，绕不开的话题永远是算力。前几年大家见面问的是“搞到卡了吗”“训练那个多大的模型”，那种感觉像在聊军备竞赛——谁囤的显卡多，谁就有话语权。但最近半年我的感受发生了明显变化：当模型能力逐渐追平，开源权重不断下放，真正决定一个 AI 产品能不能活下来的，早就不再是“你有没有卡”，而是“你手里的算力到底被榨出了多少价值”。这也就是我理解的“AI 下半场”：训练大战退潮，应用和创新成为主战场，算力从一种稀缺的收藏品，变成了需要精打细算的生产资料。

这篇文章我想把自己这段时间在算力规划、部署、调优上的真实经历梳理一遍。如果你正在做 AI 应用开发、准备自己部署开源大模型，或者已经在管理几台到几十台不等的 GPU 服务器，那这篇内容应该能帮上忙。我不会只讲理论，也不会给你一张脱离实际的天价选型清单，而是从“算力需求怎么量化”“显卡参数怎么判断”“多台机器怎么统一管”“不同应用场景的算力消耗有什么不同”这几个方向展开，尽量少说废话。

1. 训练军备赛退场，推理才是下半场的“电费账单”

1.1 从“买卡”到“经营卡”：算力叙事正在转弯

我把 AI 前几年称为“上半场”，因为那个阶段的逻辑很清晰：模型参数越大，效果越好；谁先训出更大的模型，谁就能定义行业标准。那时候团队的核心资产确实就是那几张卡，模型训练动不动就是几千张 GPU 同时跑上几个月，算力规模和融资数字是直接挂钩的。但走到今天，很多基础模型的训练已经收敛到少数几个大玩家手里，对绝大多数团队来说，拿着开源模型做微调、做部署、做场景适配，才是更常态的路径。

这种转变带来一个巨大的变化：训练成本是一次性的，但推理成本是持续性的。训练就像拍一部电影，预算再高，拍完就结束；推理则像电影上线后的电费和服务器租金，只要用户在访问、产品在运行，这个成本就一直在烧。过去大家舍得为训练花钱，是因为训练完能出一个“作品”；但推理成本是天天流淌的现金流，躲不开也藏不住。

我自己就有亲身经历。有一段时间团队做内部 AI 工具，微调完一个 7B 模型，大家都很兴奋，觉得总算跑通了。结果上线做了个小范围测试，一百多个人用，每天产生的推理请求量看着不高，但一周下来电费、GPU 租用费、运维时间加在一起，负责人直接被吓到了。那一刻我才真正意识到：上半场比的是谁能把模型造出来，下半场比的是谁能用更低的成本把模型“天天开着”。

1.2 训练和推理的算力消耗逻辑完全不同

很多人对算力的理解还停留在“参数量越大越费电”，这个说法对训练大体成立，但推理不完全是这样。训练时，模型权重是在每个 batch 上都反复更新，数值计算量巨大，而且训练要经历成千上万步迭代，一次训练任务烧掉的浮点运算量往往是推理的几十万倍。推理则不同，权重已经固定，每来一个请求，模型只做一次前向计算，按顺序把 token 一个个生成出来。

但推理真正的特点在于“细碎且重复”。每一个用户请求都是一次独立的前向计算，请求量一旦涨上来，叠加效应非常惊人。尤其到了 Agent、AI 编程这类场景，一个任务内部会反复调用模型，单次任务的总 token 消耗量可能被放大十倍甚至几十倍。这意味着，哪怕你的模型本身不算大，只要调用频率上去了、上下文变长了，推理成本依然可以迅速失控。

注意：训练阶段投入是一次性的资本开支，而推理则是“每一笔订单都要扣手续费”。如果产品长期不能形成正向收益，你的算力投入就会变成一个永远填不满的洞。

2. 用 Token 而不是用“卡”来估算算力需求

2.1 先搞明白 Token、参数和算力之间的关系

聊算力需求，很多人一上来就问“我需要几张 4090”或者“租多少台 A100”。但这个问题本身没问到点子上，因为同样的显卡，在不同场景下能提供的有效服务能力天差地别。关键在于，你每天要处理多少 token，以及要求的响应速度和并发量是多少。

先明确三个基础概念：

• 参数（Parameter）：模型的权重规模，比如 7B 就是 70 亿参数。参数越多，模型通常越聪明，但每次推理需要计算的量也越大。
• Token：模型处理文本的最小单位，一个汉字可能对应一到多个 token。模型每生成一个字，就是生成一个 token。
• 算力需求：一次推理需要完成的浮点运算量，大致可以按经验公式估算：

推理总计算量 ≈ 2 × 模型参数量 × 生成的 Token 数

这个公式是业内有名的近似估算方式，计算结果虽然不是精确的数字，但用来做容量规划已经足够。通俗理解就是：你让一个 7B 模型生成 300 个 token，大约等效于做了“70 亿 × 300 × 2”次基本运算，也就是大约 4200 亿次浮点运算。如果换成 70B 模型，同样生成 300 token，需求直接放大十倍。

知道了这个逻辑，你就会明白：决定算力需求的核心变量不是“卡的数量”，而是“每天要生成多少 token”。这就像货运公司不会说“我有三辆车”，而会说“我每天能跑多少吨公里”；显卡只是你的车，“吨公里”才是你的业务量。

2.2 一套可以直接套用的算力估算流程

我给自己团队做算力规划时，习惯按下面几步来测算，完全不需要复杂的预测模型，只需要产品侧给几个运营数字就行：

1. 预估每日请求量：这个从产品规划里就能拿到，比如“上线前三个月预计日活 3000 人，人均每天调用 20 次”，那日请求量就是 6 万次。
2. 确认单次请求的输入和输出 token：看产品交互设计。比如知识库问答，输入可能是用户问题加检索回来的相关文档，平均在 1200~2000 token 之间；输出大约在 300~500 token 之间。
3. 计算每日总 token 消耗：日请求量 × (输入 token + 输出 token)，注意输入 token 也不能忽略，因为前向计算同样要处理输入内容。
4. 估算需要的总算力：用上面的经验公式，把每日总 token 中“输出部分”代入计算。输入部分虽然也占显存和计算，但大部分场景里，生成部分的复杂度更高，先用这个粗粒度口径做规划是合理的。
5. 除以单卡能提供的有效算力：注意，这里一定要用“有效算力”，不是显卡理论 TOPS。受限于显存带宽、批处理大小和软件调度，实际能利用的往往只有峰值的 30%~50%。

我举个例子。假设你做一个企业知识库问答系统，用 7B 开源模型：

• 日均请求量：5 万次
• 平均输入：1500 token，平均输出：300 token
• 日均总 token：5 万 × 1800 = 9000 万 token
• 估算总算力：约 2 × 70 亿 × 5 万 × 300 = 2.1 万亿次浮点运算规模

然后你需要看一台中高端推理卡一天能“消化”多少 token。以一台搭载主流高端加速卡的单机为例，如果做足工程优化，一天大概能吞吐几千万 token。按这个口径，5 万日请求量，理论上 1~2 张卡的核心算力就够了。但现实必须叠加并发因素：如果峰值时段有大量请求同时到达，而单机显存装不下那么多并发序列，你就会需要更多卡来做水平扩展。

2.3 并发、延迟和成本：三个硬约束的取舍

上面只算了“总量”，但真实线上系统还受两个约束：延迟和并发。同一个 7B 模型，一次请求进来，模型要先读入你的输入，再逐字生成输出，这个过程受显存带宽和批次大小影响很大。如果把 4 个请求拼在一起作为一个 batch 处理，显卡利用率会高很多，但第一个 token 的响应时间也会变长。你要在“单请求速度”和“整卡吞吐量”之间做取舍。

实际落地时，我通常这样判断：

• 如果产品对延迟要求高，比如在线聊天机器人，那就不要过度放大批处理大小，宁可让一部分显卡闲置，也要保证响应速度。
• 如果任务是异步的，比如夜间批量内容总结、离线数据处理，那就把 batch 拉满，尽可能压榨硬件的吞吐极限。
• 如果并发峰值明显，那么就要留出 30% 以上的算力冗余，否则高峰期一起涌入，队列会越积越长，体验立刻崩塌。

经验：不要按“日均请求量”直接部署，一定要按“峰值并发”来算卡数。日均数据可以骗人，但峰值的排队时间不会。

3. 显卡算力 TOPS 排行只决定上限，不决定实际体验

3.1 TOPS 是“峰值速度”，不是“服务速度”

现在网上有各种“显卡 AI 算力 TOPS 排行”，很多人照着榜单买卡，买完发现推理速度并没有想象中快。原因很简单：TOPS 衡量的是 GPU 在最优条件下每秒能做多少次整数运算，但实际 AI 推理是一个被内存带宽、显存容量、数据搬运和软件调度层层限制的过程。就好比你有一辆极速 350 公里的跑车，但每天上班路线全是拥堵路段，实际通勤速度可能还不如一辆小电驴。

推理过程的瓶颈分布，大致可以分三块：

所以你会发现，一些游戏显卡虽然在 TOPS 榜单上名次靠前，但用来跑大模型推理，吞吐量反而不一定打得过专业计算卡。核心原因就是显存带宽和专业卡差距过大，导致模型权重在显存里“搬运”得慢。

3.2 显存容量决定了你能“装下”多大的上下文

另一个榜单上看不见的关键指标是显存容量。推理时，除了模型权重，还需要存储每个请求的中间状态，尤其是注意力机制的 KV 缓存，这部分显存消耗随着上下文长度和并发请求数线性增长。如果你只有 24GB 显存，部署 13B 模型后，权重就占掉一多半，能同时处理的并发请求数量会很有限。一旦超出显存，就只能靠 CPU 内存兜底，性能断崖式下跌，这在线上是不可接受的。

我实际遇到过这种情况：用消费级显卡部署一个 34B 模型，量化之后权重刚好塞进显存，但每次推理一多，很快就触顶。后来换了一张显存更大但 TOPS 数字更低的卡，并发能力和总吞吐反而翻倍了。看性能，要看的不是“峰值算力”，而是“峰值算力能在多大规模的任务下持续释放”。

3.3 选卡的正确判断顺序

如果你想自己部署模型，又不想被各式榜单带偏，我建议按下面的顺序评估：

1. 先测真实吞吐：拿你要部署的模型，用真实的输入输出长度，测一下它每秒能生成多少 token。这比任何参数都可靠。
2. 看显存容量：确保模型权重加最大上下文下的 KV 缓存能轻松塞进显存，并且至少留出 20% 余量。
3. 看显存带宽：在模型大小相同时，显存带宽决定了生成速度的天花板。
4. 看多卡互联：如果你要考虑拆分模型或多卡并行，卡间互联带宽很关键，否则跨卡通信会吃掉大量性能。
5. 最后才看 TOPS：TOPS 更反映训练方面或者矩阵计算的峰值能力，对推理来说，它不是核心决策指标。

建议：做容量评估前，先在目标显卡上跑一次 200 token 输出的基准测试，记录生成速度和显存占用，数据有了，方案自然就清楚了。

4. 从单机调试到服务器集群统一管理

4.1 为什么多台机器不能继续“各管各的”

当手里机器少的时候，SSH 登录上去敲命令也没问题。但一旦上了多台服务器，再靠一个个登录去人肉管理，问题很快就来：这台机器的 GPU 利用率只剩 5%，那台机器的任务排队排了几小时，还有一台驱动版本和别人的不一样，部署个环境都要折腾半天。整个集群的资源利用率可能连 30% 都不到，但单看每台机器好像又都很忙。

统一管理的本质，是把多台独立的 GPU 服务器变成“一个算力池”。用户或任务管理器来提交需求时不关心具体跑在哪台机器上，由调度系统根据当前的负载、显存、卡数来自动分配。这样不仅省去大量重复运维工作，更重要的是能把碎片化的资源聚在一起，提高整体利用率。

4.2 最小可用的算力池管理方案

基于我这边的实际经验，如果你要从零搭一套小规模集群管理，不需要一上来就上很复杂的云原生平台，可以分三步走：

第一步：标准化环境。把每台机器的操作系统、驱动版本、容器运行时尽量统一。强烈建议用容器封装训练和推理环境，这样换机器跑不会出现“我本地明明好的，到服务器就起不来”的问题。镜像仓库留在内网，方便复用。

第二步：部署一个任务调度器。常见的有 Slurm 和 Kubernetes 两个技术方向。Slurm 在传统 HPC 领域用得多，对 PyTorch 分布式训练很友好；Kubernetes 跟云原生生态结合更紧密，做在线推理服务比较顺手。小团队如果以离线训练和批量任务为主，用 Slurm 起步会更简单；如果主打在线 API 服务，Kubernetes 是长期趋势。记住，调度器的核心作用有两个：让任务找到合适的卡，让卡不闲着。

第三步：统一监控和报警。多台机器时，光是“哪台卡挂了”“哪张卡温度过高”这种问题，靠人工盯着就够呛。最简单的办法是统一收集每台机器的 GPU 利用率、显存占用、温度、功耗，并通过关键指标设置告警。刚开始不需要很复杂的可观测系统，一个基本的监控面板加一个通知机器人就够了。

下面这几个命令和思路，是我日常管理 GPU 服务器时用得最频繁的：

# 查看单台或本地机器的 GPU 实时状态 nvidia-smi # 监控多卡利用率、显存、温度，1秒刷新一次 nvidia-smi dmon -s pucvmet -d 1 # 定期采集多台机器的指标，统一上报监控系统 nvidia-smi --query-gpu=index,uuid,utilization.gpu,memory.used,temperature.gpu \ --format=csv -l 60 >> /var/log/gpu_metrics.csv

这些命令的作用不是给你炫技，而是让你在“出了问题再登录”和“随时知道集群状态”之间划一条明确的线。只有先掌握集群的健康状态，调度器才有意义，否则你都不知道资源瓶颈卡在哪。

4.3 我踩过的三个集群管理坑

讲三个真实发生在我这边的例子，给还没入坑的人提前打个预防针。

第一个坑是节点状态不一致。某次周末跑批量推理任务，一调度就报错，排查半天，发现其中一台机器驱动被静默更新过，导致卡在容器里不可见。从那之后，我强制所有机器统一维护窗口，驱动和系统补丁只能通过统一流程下发，禁止人肉登录升级。

第二个坑是任务排队机制缺失。早期没有配置资源配额，一个人提交了 8 卡训练任务，把所有机器占满了，其他人的推理任务全部排队等待。后来给不同项目组设置了队列优先级和最大卡数限制，才解决这种“饿死”现象。

第三个坑是空转浪费。监控数据上线后我发现，很多任务实际只用了单张卡，却申请了多台机器；还有不少测试环境跑完忘了释放，GPU 空转好几天。现在我的做法是，所有任务必须设置最大运行时间和自动释放策略，没用完就销毁。一通调整下来，整个集群的有效吞吐量提升非常明显。

经验：集群管理的目标不是“装上某个调度器”，而是把任务的申请、执行、释放变成一条有约束、有监控、有回收的流水线。管理工具只是手段，治理规则才是核心。

5. Agent、AI 编程、AI 视频：不同应用场景的算力消耗逻辑完全不同

5.1 AI Agent：一次任务拆成 N 次调用，Token 消耗成倍放大

AI Agent 是这两年特别火的方向，几乎每个做 AI 应用的人都在琢磨它。但 Agent 场景的算力消耗模式和传统问答完全不同：传统问答是“问一次答一次”，Agent 是“一次任务，内部要思考、拆解、调用工具、查看结果、再思考”，等于把原来的一次推理放大了很多倍。

举个例子：让 Agent 完成“帮我把本周的销售数据汇总成周报”这个任务，它可能要经历：读取数据工具调用、生成中间分析、生成结构化报告，前后触发模型推理十几次，总 token 消耗可能是直接问答的 5 到 10 倍。如果中间需要处理的上下文又长，比如读了几十个文档片段，那显存和计算的压力立刻翻倍。

因此，做 Agent 产品时，我强烈建议：

• 设置最大迭代次数，避免 Agent 陷入死循环导致成本失控。
• 对结果做缓存：相同的子任务结果直接复用，不重复调用模型。
• 能用规则、代码处理的环节，就不要交给模型。让模型只做它擅长的事，其他流程用工程手段解决。

5.2 AI 编程：长上下文和大输出让显存压力拉满

AI 编程工具是另一个典型场景。跟普通聊天不同，代码场景的输入往往特别长——一个文件可能几百行，一个项目上下文可能上万行。长输入带来的直接问题是：模型每次都要对整段输入进行 prefill 计算，并且在生成阶段，KV 缓存的体量会随着上下文长度快速增长，显存占用非常大。

实际使用中你会发现，同一个模型，在短输入场景下并发能力很强，但到了代码场景，输入一长，单请求能占用的显存就剧烈上升，能同时跑的并发请求瞬间缩小。优化手段主要有两条路：第一，通过检索和代码结构解析，只把真正相关的代码片段喂给模型，而不是把整个代码库硬塞进去；第二，利用上下文缓存，让相同的项目前缀在多次请求之间共享计算，能省下大量的重复 prefill 开销。

5.3 AI 视频：把文本推理问题变成了“渲染”问题

AI 视频和文本模型的算力消耗差距不是一倍两倍，而是数量级的差距。文本模型一次生成几百个 token，撑死也就上千 token；视频生成要做多次扩散采样，每次采样都要处理一整个隐空间张量，计算量随分辨率和帧数极速膨胀。可以说，AI 视频的算力消耗更像传统 CG 渲染，而不是文本推理。

同样是给用户提供服务，处理文本任务的服务器可以实时响应，视频生成则很难做到秒级返回，一般要走异步队列：用户提交请求，后台排队，生成完再通知。部署的时候得做好队列和任务优先级管理，尽量错峰填谷，避免所有请求挤在同一时间点抢占资源。不同应用场景的算力消耗模式比较，可以简单参考下表：

6. 真正拉开差距的是“软算力”：缓存、量化、路由和工程取舍

6.1 提示词缓存和 KV Cache：入场即回本的关键优化

很多团队在部署推理服务时，第一反应是“换更贵的显卡”，却忽略了软件层面最大的一个省钱点——提示词缓存。在真实产品里，很多请求都共享同一个系统提示词和很长的公共前缀，比如客服产品有固定的角色设定、律所产品有固定的条款说明。如果每次都让模型从头重新处理这些内容，等于每一笔请求都在重复做无用功。

提示词缓存会把这些公共前缀的计算结果暂存下来，新请求来了之后直接复用，只需要计算新增的那一小段内容。这个优化对长上下文场景特别明显，有时候能把单请求的输入计算成本砍掉一半甚至更多。类似的思路还有 KV Cache 的显存管理，通过更聪明的调度方式让显存里能同时塞下更多请求，提升整体并发吞吐。

6.2 量化不是无脑压缩，要按场景分层选择

模型量化是把大模型的权重从较高精度压缩到较低精度，比如从 FP16 压缩到 INT8 甚至更低，换来显存占用下降、推理速度提升。这项技术确实是现阶段性价比最高的“软算力”来源，但一定要明确一件事：量化不是无脑压缩，是有损的，能不能接受要看具体任务。

我自己的习惯是分级处理：如果模型只做简单分类和摘要，用 INT8 甚至 4bit 量化没太大问题；如果是写代码、做数学推理这类对输出确定性要求高的任务，量化后效果波动会很敏感，至少要用 W8A8 这样相对稳妥的量化方式，并在上线前做一轮效果对比测试。记住，不要迷信“量化后效果不变”的宣传，以你自己的测试集数据为准。

6.3 流量路由：让“大模型”干大事，“小模型”干小事

最后再讲一个我在线上系统里特别看重的优化层——流量路由。任何一个有一定规模请求量的 AI 系统，都不需要让所有请求都跑到最大最聪明的模型上。简单问题用 7B 模型就能答得很好，复杂问题才需要 70B 级别模型；把这两类请求全部混在一起跑大模型，等于每天都在铺张浪费。

可以设计一个路由策略：先让容易、重复的问题走小模型或者直接命中缓存；判断可能有难度、需要复杂推理的请求才升级到大模型。这个策略看起来简单，但在实际业务里省下的成本相当可观。GPU 资源又贵又紧张，让“好钢用在刀刃上”不是一句口号，而是 AI 下半场活下来的基本素养。

真正让我觉得算力这事值得认真对待的，不是技术多炫，而是每一项优化都可以直接折算成成本。过去一年，我逐渐养成一个习惯：每一次性能优化之后，先记下原来的生成速度、显存占用、并发能力，改完再看收益曲线。算力资源不会自己变得便宜，但更聪明的使用方式可以让同样一张卡发挥出几倍的价值。如果你现在正站在“要不要再买几张卡”的岔路口，我的建议是先别急着下单；把你现有的请求日志拉出来，算清楚日均 token、峰值并发、单次请求长度，再结合缓存、量化和路由手段做一轮优化，很可能你会发现，现有的算力还有大半身位没被榨干。