算力成本估算：基于Token吞吐量的资源需求模型

在上一篇中，我们聊了模型选型的艺术。今天，我们要变得更现实一点，聊聊钱。

当你向CTO或财务总监申请购买昇腾910B服务器时，光说“DeepSeek效果好”是拿不到预算的。你需要回答一个灵魂拷问：为了支撑我们现在的业务量，到底需要多少算力？是买1台还是10台？

这笔账如果算不清楚，后果只有两种：要么资源闲置被老板骂浪费，要么上线即崩被用户骂垃圾。这一篇，我们将建立一个数学模型，教你从业务指标倒推硬件需求，精确到每一分钱。

1. 核心指标：吞吐量与首字延迟

在计算算力之前，我们必须先统一两个核心概念，它们是衡量推理性能的黄金标准。

首先是吞吐量，即System Throughput，单位是Tokens/s。它代表了你的系统每秒钟能吐出多少个字。这直接决定了你能服务多少并发用户。比如，如果你的业务峰值有100个人同时在用，每个人每秒阅读10个字，那你的系统吞吐量至少要达到1000 Tokens/s。

其次是首字延迟，即Time To First Token (TTFT)，单位是毫秒（ms）。它代表了用户从点击“发送”到看到第一个字蹦出来的时间。这是用户体验的生命线。一般来说，TTFT低于200ms是极致体验，低于500ms是优秀，超过1秒用户就开始焦虑了。

这两个指标往往是矛盾的。为了提高吞吐量，我们通常会加大Batch Size，让一次推理处理更多请求，但这会导致每个请求的排队时间变长，从而增加延迟。算力规划的核心，就是在延迟可接受的前提下，最大化吞吐量。

2. 算力需求公式：从Token到TFLOPS

我们如何把业务上的Token需求转化为硬件上的TFLOPS（每秒万亿次浮点运算）需求呢？这里有一个经典的估算公式。

对于一个参数量为P（单位：十亿/Billion）的模型，生成一个Token所需的浮点运算次数（FLOPs）大约是2P。这只是权重计算的部分，实际上考虑到通信开销和注意力机制，通常取2.2P到2.5P更为保险。

假设我们使用DeepSeek-67B模型，P=67。那么生成1个Token大约需要2 * 67 * 10^9 = 134 GFLOPs。

现在，假设你的业务目标是每秒生成100个Token。那么理论算力需求就是100 * 134 GFLOPs = 13.4 TFLOPS。

但这只是理论值。实际上，由于显存带宽限制、算子效率低等原因，硬件的利用率（MFU, Model FLOPs Utilization）通常只有30%到50%。昇腾的FP16峰值算力大约在300 TFLOPS左右（具体数值视版本而定）。如果我们按40%的利用率计算，单卡的有效算力大约是120 TFLOPS。

这意味着，单张910B理论上每秒能生成120 TFLOPS / 134 GFLOPs ≈ 895个Token。

看起来很高？别急，这只是“生成阶段”的算力。别忘了还有“预填充阶段”（Prefill），也就是处理用户输入的Prompt。Prompt越长，计算量越大。如果你的场景是长文档分析，输入有10k tokens，那光是处理输入就需要巨大的瞬间算力。

3. 显存带宽：隐形的瓶颈

在实际测试中，你往往会发现，明明算力利用率才20%，但生成速度就是上不去。这时候，瓶颈通常在显存带宽。

大模型推理是一个典型的Memory-Bound（显存受限）任务。每生成一个Token，我们都需要把几十GB的模型权重从显存搬运到计算单元一次。

假设模型权重是130GB（DeepSeek-67B FP16），显存带宽是HBM的理论带宽（假设为1.6 TB/s）。那么理论上每秒最多能搬运1600 / 130 ≈ 12次。也就是说，如果Batch Size为1，你的极限速度只有12 Tokens/s。

这太慢了！为了解决这个问题，我们必须提高Batch Size，让一次搬运计算多个Token。这就解释了为什么高并发下吞吐量会暴涨。

在昇腾上，优化带宽利用率的关键在于KV Cache的管理。如果KV Cache占满了显存，你就无法增大Batch Size，带宽优势就发挥不出来。所以，使用PagedAttention等技术来节省显存，本质上是在用显存换带宽，进而换吞吐量。

4. 实战推演：我们需要多少卡？

让我们来做一个真实的场景推演。

假设我们要为公司内部搭建一个DeepSeek-Coder-7B的代码补全服务。

并发目标：50个工程师同时使用。
平均速度：每人每秒生成20个Token（代码补全通常是一大段一大段出的）。
总吞吐需求：1000 Tokens/s。
模型：DeepSeek-7B (FP16)，权重约14GB。

第一步：算力估算
生成1个Token需要2 * 7 = 14 GFLOPs。
总需求：1000 * 14 GFLOPs = 14 TFLOPS。
单张910B有效算力（按保守30%算）约90 TFLOPS。
算力上，一张卡绰绰有余。

第二步：显存容量估算
权重：14GB。
KV Cache：假设最大上下文长度4096，Batch Size 50。
KV Cache大小 ≈2 * 2 * n_layers * n_heads * head_dim * seq_len * batch_size * 2 bytes。
粗略估算，7B模型的KV Cache在4k长度、Batch 50下，大约需要20GB左右。
总显存需求：14GB + 20GB = 34GB。

结论：
一张32GB显存的910B卡装不下！KV Cache会溢出（OOM）。
你有两个选择：

量化：使用INT8量化，权重降到7GB，总需求27GB，一张32GB卡勉强能塞下，但很极限。
加卡：使用一张64GB版本的910B，或者两张32GB卡做TP并行。

考虑到代码补全对延迟极度敏感，TP并行会引入通信开销，增加延迟。因此，最佳方案是一张64GB显存的910B，或者对模型进行INT8量化后跑在32GB卡上。

5. 成本计算器代码

为了让你在做预算时更有底气，我写了一个简单的Python类，用于计算资源需求。

classResourceEstimator:def__init__(self,model_size_b,hidden_size,layers,heads):self.P=model_size_b*10**9self.h=hidden_size self.l=layers self.nh=headsdefestimate_vram(self,precision_bytes,batch_size,seq_len):"""估算显存占用 (GB)"""# 权重占用weight_vram=self.P*precision_bytes/1024**3# KV Cache占用 (简化版公式)# KV = 2 * n_layers * n_heads * head_dim * seq_len * batch_size * precisionhead_dim=self.h/self.nh kv_cache=2*self.l*self.nh*head_dim*seq_len*batch_size*precision_bytes/1024**3# 激活值及其他缓冲区预留 (经验值: 20%)total=(weight_vram+kv_cache)*1.2returntotal,weight_vram,kv_cachedefestimate_flops(self,target_tokens_per_sec):"""估算所需算力 (TFLOPS)"""# 2 * P * tokens/sreturn2*self.P*target_tokens_per_sec/10**12# 以DeepSeek-7B为例estimator=ResourceEstimator(model_size_b=7,hidden_size=4096,layers=30,heads=32)# 场景：FP16 (2 bytes), Batch 50, Seq 4096total_vram,w_vram,kv_vram=estimator.estimate_vram(precision_bytes=2,batch_size=50,seq_len=4096)flops_needed=estimator.estimate_flops(target_tokens_per_sec=1000)print(f"DeepSeek-7B 资源需求估算:")print(f"权重显存:{w_vram:.2f}GB")print(f"KV Cache:{kv_vram:.2f}GB")print(f"推荐总显存:{total_vram:.2f}GB")print(f"理论算力需求:{flops_needed:.2f}TFLOPS")