给 AI 算账：企业大模型从"能用"到"用得起"的降本增效全景指南——模型路由、缓存压缩、推理引擎与治理观测一次讲透

本文由 辛梓煜@词元二号站（www.ciyuanerhao.com）撰写，转载请注明出处。

快速摘要

一句话结论：企业大模型烧钱失控，几乎不是"模型不够强"，而是"账没算清"。真正把成本压下来的，是四件事叠加——用模型路由让每个任务匹配"刚刚好"的模型（能省一半左右），用四层缓存与压缩在同一件事上少花冤枉 Token（综合削减 30%–60%），用推理引擎的深度优化让同一批卡扛起接近翻倍的业务，再用全链路可观测把每一笔 Token 的去向和 ROI 算明白。会用 AI 只是入场券，"算得清、接得快、管得住"才是下半场的胜负手。

我自己把这套东西从原理到落地捋了一遍，越捋越觉得：2026 年最值钱的一门手艺，不是训模型，而是"给 AI 算账"。下面这篇，我会从"账单为什么突然失控"讲起，一路拆到模型路由、缓存压缩、推理引擎、可观测和安全治理，尽量用大白话把每个环节讲透，配上表格、架构图和伪代码，新手也能跟着看明白。

想看完整拆解，往下翻。

一、账单为什么突然失控：从"按次问答"到"按任务干活"

先说一个真事，很有代表性。

2026 年上半年，一家全球级的出行公司，把 AI 编程工具铺给了大约五千名工程师。结果四个月不到，一整年的 AI 预算就见了底。重度使用者一个月的调用花费能到几百甚至上千美元，公司内部还搞了个"使用量排行榜"，谁用得多谁排前面——这一激励，Token 消耗直接坐上了火箭。等账单摆到管理层桌上，公司高管的第一反应是懵的：钱是真烧掉了，可到底换回了多少实打实的价值，谁也说不清。紧接着，好几家科技巨头开始给员工手里的 AI 编程工具"踩刹车"，有的干脆把外部编程工具的授权收回来，换成自家的替代方案。

这事之所以魔幻，是因为它偏偏发生在 Token 单价一路下跌的 2026 年。

1.1 一个反直觉的现象：单价在跌，账单在涨

按常理说，单价降了，总花费应该跟着降才对。可现实反过来了。原因不复杂，我把它写成一个最朴素的成本公式你就懂了：

[

\text{总成本} \approx \sum_{i} N_i \cdot T_i \cdot p_i

]

其中 (N_i) 是第 (i) 类任务的调用次数，(T_i) 是单次任务吞掉的 Token 数，(p_i) 是对应单价。单价 (p_i) 确实在降，可调用次数 (N_i) 和单次 Token 量 (T_i) 涨得更凶——尤其是 (T_i)。中国的日均 Token 调用量，两年时间涨了一千多倍，到 2026 年 3 月已经突破每天百万亿量级。分母在缩，分子在爆炸，总账自然水涨船高。

1.2 Agent 是"吞 Token 的黑洞"

真正的推手，是 Agent（智能体，简单说就是能自己规划、自己调工具、多步骤把一件事从头干到尾的 AI）。

过去你问 AI 一句"这句话什么意思"，它答一句，一轮对话就结束了，几百个 Token 打住。现在一个 Agent 接到"帮我把这个功能实现并跑通测试"，它会读代码、写代码、跑命令、看报错、再改再跑……一个完整任务跑下来，中间来来回回几十轮，吞掉的 Token 是过去简单问答的数倍乃至数十倍。

模型越会干活，账单涨得越快。这是 Agent 时代的基本矛盾。它不是 bug，是能力变强的副作用。

更麻烦的是，Agent 的花费很难提前估。同一个工具、同一个人、同一个工作日，因为任务不同，账单可能差出几十倍——写个自动补全，和让 AI 编排一堆子任务跑通一整个模块，烧的 Token 完全不是一个量级。传统预算是按"每人每月一个固定席位费"来编的，这种可预测的模型，根本兜不住按用量计费带来的剧烈波动。于是就出现了开头那一幕：预算是按老经验拍的，用量却按新曲线涨，四个月烧穿一年额度，一点都不奇怪。

还有个容易被忽略的组织问题。很多公司里，推动大家"多用 AI"的团队，和为这笔账负责的团队，压根不是同一拨人。前者恨不得人人把 AI 用满，后者到年底才发现钱没了。激励和买单一脱节，账自然失控。所以"给 AI 算账"从来不只是个技术问题，它同时是个管理问题——这一点，后面第七节还会专门再讲。

1.3 "全都用最强的"这个坏习惯

这一条，我猜你自己也中招过。

用 AI 写点东西的时候，明明便宜的档位就摆在那儿，可你还是习惯性把档位拉满——万一便宜的那个搞不定呢？一个人这么干，最多浪费点自己这周的额度。可放到企业里，就变成了一句"我的订单到哪了"和一份上百页的合同审查，烧掉一样贵的算力。

问题在于，不同任务对算力的胃口，差着好几个数量级：

把"提取一个字段"这种活儿也丢给顶配模型，本质上就是拿劳斯莱斯去送外卖。资源利用率跌进谷底，账单一路飙升——这不是模型的问题，是调度的问题。

我自己有段时间也犯这毛病。写点小脚本、查个语法，顺手就把最贵的档位拉满，图个心安。后来把调用记录导出来一算才发现，六七成的请求其实用便宜档就绰绰有余，多花的那部分全打了水漂。个人是这样，企业放大几万倍，浪费就成了一个吓人的数字。

所以你看，同样一句"帮个忙"——"把这份文档总结一下"和"把这份三百页的合同逐条审出风险点"——听起来都是让 AI 搭把手，可它俩对算力的胃口，中间隔着好几个数量级。不区分难易、一律顶配伺候，就是最大的浪费源头。 把这个源头堵上，就是后面所有降本手段的起点。

于是，一门去年还没几个人当回事的学问，今年成了显学：给 AI 算账。辛梓煜@词元二号站也是被这股风推着，才认真啃了一遍这套体系。

二、企业侧的三座大山：成本、治理、国产化

先把视角拉高一点。现在模型多到数不清，开源的、闭源的、通用的、行业的，能训的几乎都训出来了。可"模型都有了"之后，更难的问题才刚开始：怎么让它们在企业里跑得又快、又省、又安全？

真实的现场，比想象中乱得多。一家大企业，应用建了七八十上百个，模型接了四五十个，中间靠一根根"硬连线"对上——哪个应用走哪个模型，全凭当初谁接的谁定。跑是能跑，但三件麻烦事会挨个找上门。

2.1 第一座山：成本

就是上一节讲的。任务复杂度天差地别，落地时却习惯性全量呼叫最贵的模型，资源利用率低到离谱，Token 账单压不住。更隐蔽的是，这种浪费平时看不见——每一次调用都不算贵，可它们叠加成一年的总账时，数字会大得让人心惊。企业往往是在收到账单的那一刻，才意识到问题一直都在。

2.2 第二座山：治理

AI 已经开始碰核心业务了。可权限怎么切、操作怎么审计、敏感数据怎么防外泄，这些企业级的防线普遍千疮百孔。一个能直接调用核心数据的 AI，如果没装安全护栏，本身就是一枚定时炸弹。

2.3 第三座山：国产化

在很多以国资背景为主的私有化机房里，国产芯片上的推理效率，直接决定这台"AI 引擎"转不转得起来、转得划不划算。同样一批卡，压榨得好和压榨得差，业务承载量能差出一倍。对必须走自主可控路线的机构来说，这不是"能不能更省"的问题，而是"这套系统跑不跑得动"的问题——推理引擎优化得不够，可能几十上百万的硬件砸下去，业务高峰期照样卡成一团。

这三件事，其实指向同一个结论：

企业 AI 的重心，正在从"模型能力"，转向"AI 基础设施运营"。

换句话说，AI 的上半场拼的是谁的模型更强，下半场拼的是谁管得住。而这场控制力之战的第一块阵地，就是——模型路由。

三、统一网关：横在业务与模型之间的"超级立交"

在讲路由之前，得先立起一个概念：统一网关（也叫 LLM Gateway、AI 网关、统一中间层）。它是后面所有降本手段的载体。

3.1 为什么需要一个中间层

回到那个"七八十个应用、四五十个模型、硬连线对上"的烂摊子。硬连线的坏处是：想换模型得改一堆应用；想统一加个安全策略，得挨个应用去接，总有人"忘了接"；想看清谁花了多少钱，根本查不出来。

解法是在业务和大模型之间，横插一层统一网关。所有模型调用请求，都先流经这一层，由它统一接入、智能调度、优化成本、把守安全、记账观测。

flowchart LR
    A[各业务应用<br/>客服/风控/办公/营销] --> G{统一网关<br/>LLM Gateway}
    G -->|简单任务| M1[轻量小模型]
    G -->|常规任务| M2[标准模型]
    G -->|复杂/Agent| M3[高性能模型]
    G -->|敏感数据| M4[私有化模型]
    G -.记账/审计/观测.-> O[(可观测 & 治理平台)]

有了这层"超级立交"，应用不再直连模型，而是统一对接网关。换模型、加策略、算账、审计，全在一处搞定，改一处、全局生效。

打个更具体的比方。没有网关的时候，系统像一座没有红绿灯的老城区：每条路（应用）自己找路口（模型），高峰期全堵死，出了事也不知道该找谁。加上网关，就像在城市中心架起一座立体交通枢纽——所有车流先上匝道统一分流，该快的快、该慢的慢，还能全程盯着每一辆车往哪去、走了多远。

这里要澄清一个新手常有的担心："多插一层，会不会更慢？"其实网关做的都是极轻量的判断和转发，本身耗时很短，通常在百毫秒级甚至更低；而它省下的重复计算、避免的错档调用，远远抵得过这点开销。多这一层，恰恰是为了后面每一层都能少花钱。

3.2 网关到底管哪几件事

我把网关的职责归成五件，记这五个字就够了——接、调、省、安、明：

• 接：统一接入。屏蔽不同模型厂商的接口差异，业务侧只面对一套标准协议。
• 调：智能调度（路由）。把任务派给"刚刚好"的模型。
• 省：成本优化。缓存、压缩、裁剪，少花冤枉 Token。
• 安：安全护栏。权限、审计、敏感数据防外泄。
• 明：账目透明。每一笔 Token 花在哪、值不值，都要算得清。

3.3 常见网关一览

这块生态已经很成熟，开源和商用都有得选。我整理成一张表，方便你按自家技术栈对号入座（不构成推荐，具体以官方文档为准）：

新手这里容易犯一个理解误区：网关不是又一个模型，它一个字都不"想"，它只负责"把请求送到对的地方，再把账记清楚"。它是交警和记账员，不是运动员。

四、模型路由：让每个任务匹配"刚刚好"的模型

网关立起来了，最核心的一块能力就是路由。它要解决的，正是第一节那个"全都用最强的"坏习惯。

4.1 三种路由策略

路由从简单到复杂，大致三档：

第一档，规则路由。 基于非语义信息分流，最简单。比如按用户等级：普通用户走轻量模型，付费用户走高性能模型。或者按来源应用、按业务线硬性指定。优点是简单可控，缺点是"一刀切"，同一个用户问难题也只能走固定档。

第二档，级联路由。 先用便宜模型试着答，答得好就收工；答不好（比如置信度低、或触发了兜底规则），再升级到贵模型重答一遍。好处是绝大多数简单请求被便宜模型截住了，只有少数硬骨头才惊动顶配。这类思路的代表工作（如学界的 FrugalGPT）证明了它在大流量下的省钱潜力。缺点是：万一便宜模型答错却没被识别出来，会把错误往下传。

第三档，语义路由。 这是现在的主流。网关先"读懂"用户的 Prompt，分析意图和复杂度，再实时决定派谁去。举几个例子你就有画面了：

• "帮我总结这封邮件" → 简单摘要 → 派给轻量模型
• "帮我写一个爬虫脚本并处理异常" → 复杂编码 → 派给高性能模型
• "查一下我这个订单状态" → 工具调用 → 派给微调过的小模型

flowchart TD
    P[用户 Prompt] --> R[路由器<br/>纳米级分类模型]
    R -->|简单| S[轻量模型<br/>便宜快]
    R -->|中等| N[标准模型]
    R -->|复杂| B[高性能模型]
    R -->|含敏感数据| PV[私有化模型<br/>数据不出域]

三种策略并不是"三选一"，成熟系统往往是叠着用的：底层用规则卡住硬约束（比如敏感数据强制私有化），中间用语义判难易，遇到拿不准的再用级联去试。我把三者的取舍列成一张表，方便你选起点：

我的建议很直接：先从规则路由起步，别一上来就追语义路由。 规则版一两天就能跑通，先把最粗的浪费堵住，收集着真实数据，等有底气了再往上进阶。工程上，"能用的简单方案"永远优先于"完美的复杂方案"。

4.2 路由要综合看哪几个因子

真正工业级的路由，不会只看"难不难"，而是一次性权衡多个因子。我把常见的五个列出来：

一个成熟网关的路由决策，会把这五个因子综合打分，而且整个决策要足够快——通常控制在百毫秒级以内，不能因为"选模型"本身反而拖慢了响应。

4.3 动手搭一个"纳米路由器"

原理说再多，不如看段代码。路由器本身可以非常小——用一个极小的分类模型（几百 MB 甚至更小）专门判意图就够了，推理飞快。下面是一段最小化的伪代码，帮你建立直觉：

# 极简语义路由：一个"纳米级"分类器 + 一张模型档位表
# 说明：真实系统会用微调过的小分类模型；这里用规则近似演示思路

MODEL_TABLE = {
    "simple":  {"name": "light-model",   "price": 1.0},   # 便宜档
    "normal":  {"name": "standard-model","price": 4.0},   # 标准档
    "complex": {"name": "pro-model",     "price": 20.0},  # 高性能档
    "private": {"name": "onprem-model",  "price": 6.0},   # 私有化(敏感数据)
}

def classify(prompt: str, meta: dict) -> str:
    # 1) 安全优先：命中敏感等级，直接走私有化，别的都不谈
    if meta.get("sensitive_level", 0) >= 2:
        return "private"
    # 2) 用长度 + 轮次 + 关键词粗判复杂度（真实场景换成小模型打分）
    hard_signals = ["写代码", "推理", "审查", "分析", "多步骤"]
    score = len(prompt) / 200 + meta.get("turns", 1) * 0.3
    score += sum(kw in prompt for kw in hard_signals)
    if score < 1:   return "simple"
    if score < 2.5: return "normal"
    return "complex"

def route(prompt, meta):
    level = classify(prompt, meta)
    chosen = MODEL_TABLE[level]
    # 记账埋点：把 level / 模型 / 预估价都写进观测系统
    log_decision(prompt_id=meta["id"], level=level, model=chosen["name"])
    return chosen

这段代码丑，但把路由的骨架讲清楚了：先卡安全红线，再判复杂度，最后落到模型档位并埋点记账。工业级实现无非是把 classify 换成一个训练过的小模型、把打分逻辑做得更精细、再加上 fallback 和限流。

4.4 路由到底能省多少

这里给个来自公开研究的量级感受（不是某次固定实测，别当死数据）：学界的 RouteLLM 这类工作显示，用一个小模型做路由器，可以在保住接近顶配模型九成以上效果的前提下，把成本砍掉一半上下。落到真实业务里，效果同样明显——比如一个客服平台，日常几万次咨询里，超过一半不过是查订单、问退换货这种不用动脑的问题，把它们分流给轻量模型、敏感的强制走私有化之后，月度 Token 成本能比"全量灌顶配"砍掉一大半，响应速度反而更快了。

4.5 路由器怎么学会"判断难易"

规则路由靠人写规则，语义路由则要一个"会判断"的小模型。它是怎么学会的？靠数据。

企业跑着跑着，会攒下大量真实的调用日志——什么样的问题，最后用了哪个档位的模型，答得好不好。把这些日志清洗一下，标上"这个问题该走哪档"，就成了训练路由器的"黄金数据集"。用它去微调一个很小的分类模型（几百 MB 那种），路由器就慢慢学会了：扫一眼问题，八九不离十判断出该派谁去。

新手别被"训练模型"四个字吓到。路由器要的不是聪明，是快和稳——它只做一道选择题（简单／中等／复杂／敏感），参数越小越好，跑得越快越好。真正的重活，交给后面被选中的大模型就行。你甚至可以先不训练，用规则版跑起来，边跑边收集数据，等日志够了再换成小模型版，平滑升级。

4.6 别忘了兜底：fallback 与限流

路由不是"派出去就完事"，还得考虑那些"万一"：

• fallback（降级／切换）：目标模型突然挂了、超时了、被限流了，网关要能自动切到备用模型，别让整个业务跟着崩。这就是前面五因子里"可用性"那一条的落地。
• 限流与配额：给每个部门、每个应用设上限，防止某个应用写了个死循环，一夜之间把预算刷爆。这也是把"用量"和"预算"绑起来的第一道闸门。
• 重试策略：偶发的网络抖动，自动重试一两次；但一定要设上限，别把一次失败放大成雪崩式的重复调用——那反而更烧钱。

我的经验是：路由的漂亮，一半在"选得准"，另一半在"兜得住"。 选得准是锦上添花，兜得住是保命底线。上线前，这块务必压测到位。

不过，选对模型只是第一步。接下来这四层，是为了在同一件事上少花冤枉 Token。

五、在同一件事上少花冤枉 Token：四层节流

路由解决的是"派谁去"，节流解决的是"派出去之后，怎么让这一趟少烧点油"。我把常用手段归成四层，从上游到下游依次叠加。

先给张全景图，建立整体印象：

flowchart TD
    C0[原始 Token 成本] --> C1[① 提示词缓存<br/>KV Cache 前缀复用]
    C1 --> C2[② 语义缓存<br/>相似问题直接命中]
    C2 --> C3[③ Prompt 压缩<br/>剔除输入赘肉]
    C3 --> C4[④ 上下文裁剪<br/>只留相关片段]
    C4 --> C5[最终成本<br/>综合削减 30%~60%]

5.1 第一层：提示词缓存（KV Cache 前缀复用）

要讲清这个，得先拆开大模型推理的两个阶段（后面第六节还会反复用到，先记住）：

• 预填充（Prefill）：模型先把你输入的整段 Prompt 读一遍，算出注意力里的 K（Key）和 V（Value）状态。这一步是算力密集型。
• 解码（Decode）：在此基础上，一个词一个词往外蹦答案。这一步是显存/带宽密集型。

关键点来了：在很多场景（尤其是 RAG），你的 System Prompt 加上塞进去的文档，可能有上万个 Token，而用户真正的问题只有几十个 Token。如果每次请求都把这上万个 Token 重新 Prefill 一遍，纯属重复劳动。

提示词缓存（也叫 Prompt Caching / Prefix Caching）就是把这段公共前缀算出来的 KV 状态存下来，下次遇到相同前缀直接复用，跳过重复计算。

这里有个新手常踩的坑，我第一次也搞混了：提示词缓存缓存的不是"答案"，而是"输入的中间计算状态"。所以它对"输出"没有直接影响，只是让"读输入"这一步变快、变省。用好它有条黄金法则——静态在前，动态在后：把不变的（System Prompt、固定文档）放前面，把每次都变的（用户问题）放后面，前缀越稳定，命中率越高。

举个反面例子你就懂了：如果你把当前时间、随机 ID 这类每次都变的东西放在 Prompt 最开头，那从第一个字起前缀就对不上，后面再多的固定内容也没法复用，缓存直接作废。反过来，把几千字的固定说明书放前面、用户那一句短短的问题放最后，绝大部分前缀都能命中。同样的内容，摆放顺序不同，省下的钱可能差一大截。 这也是我特别爱讲的一个点——很多降本，不是靠什么高深技术，就靠"把顺序摆对"这种不起眼的细节。

5.2 第二层：语义缓存（相似问题直接命中）

提示词缓存要求前缀完全一样才命中。而语义缓存更进一步：只要新问题和历史问题意思相近，就直接把旧答案掏出来给你，连模型都不用惊动。

它的原理是：把每个问题转成一串向量（embedding），存进向量库；来了新问题也转成向量，去库里找最相似的，相似度超过阈值就算命中。

在内部知识问答这种"高频重复轰炸"的场景里，命中率能稳定在两三成。别小看这两三成——对一家日调用量以亿计的企业，这就是财报上真金白银的差别。

但语义缓存是把双刃剑，这条红线我必须重点标出来：

相似 ≠ 相同。相似度阈值调得太松，会把"看起来像、其实不是同一回事"的问题误判成命中，轻则答非所问，重则泄露隐私——比如两个不同用户的咨询因为语义接近，被返回了同一条含敏感信息的旧答案。

所以工程上通常要加两道保险：一是阈值别贪心（宁可命中率低一点，也别误判），二是对含身份证号、金额、医疗等敏感字段的请求，直接绕过语义缓存，老老实实实时算。缓存这东西，用好了降本增效，用不好就是埋在系统里的定时炸弹。

5.3 第三层：Prompt 压缩

有些 Prompt 天生啰嗦——大段背景、重复说明、可有可无的客套。Prompt 压缩（代表方法如 LLMLingua 一类）做的，就是在不太伤害语义的前提下，把这些"输入赘肉"精准剔掉一部分，让同样一件事用更少的输入 Token 表达出来。

它的思路有点像"给提示词做减肥"：识别出对结果贡献低的词句，删掉或压缩，通常能再省下一到两成输入。这里的门道在"分寸"——压得太狠，把关键信息也删了，模型就答歪了；压得太保守，又省不下几个 Token。实践里通常会按任务类型分别调压缩强度：闲聊、摘要这类容错高的可以压狠点，涉及精确数字、法律条款的就得手下留情。没有一个放之四海皆准的压缩率，一切以你自己的业务实测为准。

5.4 第四层：上下文裁剪

RAG 场景里，检索回来一堆文档片段，很多其实跟当前问题关系不大。上下文裁剪就是在把片段喂给模型之前，先按相关性排个序、砍掉边角料，只留最相关的那几段。这一步有个一举两得的好处：既省 Token，又能让模型少被无关信息干扰，答得反而更准。

这里顺带纠正一个新手的常见误会："塞给模型的资料是不是越多越好？"恰恰相反。上下文太长，不仅费钱、变慢，还容易让模型"抓不住重点"——关键信息淹没在一堆废话里，答案质量反而下降。给模型喂料，讲究的是"精准投喂"，不是"堆量"。 这也是为什么裁剪这一层，常常是省钱之外还能顺手提质的一环。

小结：四层叠加能省多少

重要提醒：上面这些数字是工程经验量级，强依赖于"请求高度重复、长 Prompt 可压缩、弱模型能兜底"等前提，没有可移植的固定值，一定要按自家真实流量实测。别拿别人的百分比当承诺。

5.5 串起来看：一次客服问答是怎么"省"下来的

把前面四层叠一起，跟着一个虚构的例子走一遍，你会更有体感。假设有位用户在某电商 App 里问："我上周买的那个东西，什么时候能到？"

1. 进网关，先判安全：这句话不含敏感信息，放行走正常流程。
2. 语义缓存查一遍：库里有没有意思相近的旧问题？"订单啥时候到"是超高频问法，很可能直接命中，把现成的查询流程或答案模板掏出来——这一步若命中，后面几乎全省了。
3. 没命中，走路由：判断出这是"查订单状态 + 工具调用"，属于简单任务，派给一个微调过的小模型，而不是顶配大模型。
4. 提示词缓存复用：这类客服请求的 System Prompt（角色设定、话术规范、工具说明）是固定的一大段，早就缓存好了 KV，直接复用，不用每次重新 Prefill。
5. Prompt 压缩 + 上下文裁剪：真正要现算的，只有用户这句话和查到的那条订单记录，其余无关信息在喂给模型前就被裁掉了。

一趟走下来，一个"看似要动用大模型"的请求，实际可能连大模型都没惊动（缓存命中），即便惊动了也是最便宜的小模型加最精简的输入。几万次这样的请求叠起来，省下的就是财报上看得见的数字。

反过来，如果用户问的是"帮我把这三个供应商的合同条款逐条对比，标出对我方不利的地方"——那就是另一副面孔了：路由判成复杂任务，直接上高性能模型，该花的钱一分不省。降本的关键从来不是"处处抠"，而是"该省的省到位、该花的花在刀刃上"。 辛梓煜@词元二号站觉得，这句话是整套方法论的灵魂。

六、推理引擎：同样的卡，扛起翻倍的业务

路由和缓存管的是"要不要调、调哪个、调之前先瘦身"。可一旦真要调，请求最终会落到推理引擎上。尤其在国产化私有部署里，推理引擎的强弱，直接宣判了算力利用率和服务成本。这块是硬骨头，但也是省钱潜力最大的地方。

6.1 先搞懂两个阶段：Prefill vs Decode

第五节埋过伏笔，这里正式展开，因为后面所有优化都围着这两阶段转：

这两个阶段"性格"完全相反：一个吃算力，一个吃显存带宽。把它们混在一起跑，就会互相拖累——一个超长输入的 Prefill 任务，可能把好几个等着逐字输出的 Decode