ARTICLE DETAIL

资讯详情

深耕网站建设与运营推广的一线实战洞察。

首页/资讯中心/资讯详情

大模型应用后端底座设计与高并发支撑：并发时先看资源边界

发布时间：2026/8/10 0:31:18 拓冰企业网站定制
大模型应用后端底座设计与高并发支撑：并发时先看资源边界

大模型应用后端底座设计与高并发支撑：并发时先看资源边界

当大模型（LLM）应用的用户规模从几十个内部测试人员暴增到上万并发请求时，后端架构师面临的挑战与传统 Web 系统完全不同。

传统 Web 微服务处理一个 HTTP 请求耗时通常在 20ms 以内，而大模型推理一个请求可能持续数秒甚至数十秒，同时占用沉重的 GPU 显存（KV Cache）。

并发流量一旦涌入，如果不加控制地把请求全量塞给推理引擎（如 vLLM 或 TGI），系统不会只是缓慢排队，而是会直接触发 GPU 显存 OOM 崩溃，或者导致首字延迟（TTFT，Time To First Token）暴涨到几十秒，让绝大多数用户因超时而放弃连接。

并发上来之后，后端底座的第一条防线，应是基于 KV Cache 物理容量估算与 TTFT 要求的自适应背压控制。

为什么大模型后端的并发瓶颈在 KV Cache

在传统 API 后端中，内存瓶颈通常在 JVM 堆内存或 Go 堆内存。但在 LLM 推理 Server 中，真正的命门在于GPU KV Cache 显存容量。

每一次 Context 交互，模型在 Transformer 注意力层都需要为历史 Token 维护 Key-Value Cache。

一个 70B 参数的模型，在 FP16 精度下，单用户 4096 长度的 Context 就要占用近 2GB 的 KV Cache 显存。

flowchart TD UserReqs[突发 500 个并发 LLM 请求] -->|1. 涌入 LLM Gateway| Gateway[LLM Backend Gateway] Gateway -->|2. 检查当前 GPU KV Cache 占用| Evaluator{KV Cache 占用率 > 85%?} Evaluator -- 是: 触发背压守住线 -->|3. 启动优先级拒绝| PriorityQueue[Priority Load Shedding] PriorityQueue -->|VIP 用户请求| ExecQueue[压入 待推理队列] PriorityQueue -->|普通 / 匿名请求| FastReject[直接返回 429 System Busy] Evaluator -- 否 -->|4. 放行给推理引擎| vLLMEngine[vLLM Inference Engine] vLLMEngine -->|5. PagedAttention 动态分配| GPUCache[GPU 物理显存 KV Cache] ExecQueue --> vLLMEngine

即使采用了 PagedAttention（如 vLLM 架构），显存能够实现细粒度的物理页复用，显存总容量依然决定了系统能够同时进行 Prefill（首字填充）和 Decode（Token 生成）的物理并发上限。

一旦并发数超过了这个物理极限，vLLM 引擎不得不将部分请求的 KV Cache 抢占并 Swap 到 CPU 内存，这会导致推理延迟暴增 10 倍以上，系统迅速陷入瘫痪。

基于物理显存与 TTFT 的容量估算公式

在大模型后端底座设计中，不能盲目相信“高并发支持 10,000 QPS”的宣传。应根据 GPU 显存大小精确计算当前集群的最大并发推理 Slot 数量：

$$\text{MaxConcurrentSlots} = \frac{\text{TotalVRAM} - \text{ModelWeightsVRAM} - \text{ActivationVRAM}}{\text{AvgContextLen} \times \text{KVCacheSizePerToken}}$$

假设使用一张 80GB 显存的 A100 GPU 运行 32B 模型：

  1. 模型权重占用约 64GB 显存。
  2. 激活值与系统保留占用 6GB 显存。
  3. 剩余可用于 KV Cache 的显存为80GB - 64GB - 6GB = 10GB。
  4. 若平均上下文长度为 4096 Token，每个 Token 消耗 KV Cache 约 1MB 显存，则单请求消耗4GB显存。

结论：单张 A100 在此配置下，并发支持的上下文 Slot 极限只有 2 到 3 个。超过 3 个并发，应依赖 Tensor Parallelism（多卡并行）或者前端 Gateway 的严格队列拦截。

第二个关键指标是首字延迟（TTFT）。大模型推理分为 Prefill 阶段（计算 Prompt）和 Decode 阶段（逐字生成）。Prefill 是 Compute-bound（计算密集型），如果多个大 Prompt 同时进入 Prefill，GPU 会发生严重的算力抢占，导致首字迟迟无法吐出。

应设定硬性 SLA 目标：如P99 TTFT ≤ 1500ms。一旦当前队列估算的 Prefill 时间超过 1.5 秒，后续请求应在 Gateway 处强行截断。

多级背压控制器实现代码

为了守护 GPU 不被 OOM 冲垮，同时保证 VIP 业务不中断，后端底座应在 LLM 引擎上游构建多级信号量限流与自适应背压控制器：

package gateway import ( "context" "errors" "net/http" "sync/atomic" "time" ) var ( ErrQueueFull = errors.New("llm backend inference queue full, load shed active") ) type PriorityLevel int const ( PriorityNormal PriorityLevel = iota PriorityVIP ) type LLMBackpressureController struct { maxActiveSlots int64 activeSlots int64 maxQueueLen int64 currentQueue int64 } func NewLLMBackpressureController(maxSlots, maxQueue int64) *LLMBackpressureController { return &LLMBackpressureController{ maxActiveSlots: maxSlots, maxQueueLen: maxQueue, } } func (c *LLMBackpressureController) AcquireSlot(ctx context.Context, priority PriorityLevel) (func(), error) { // 1. 判断当前活跃推理解析 Slot 是否足够 if atomic.LoadInt64(&c.activeSlots) < c.maxActiveSlots { atomic.AddInt64(&c.activeSlots, 1) return func() { atomic.AddInt64(&c.activeSlots, -1) }, nil } // 2. Slot 满，进入背压排队逻辑 // 如果是普通请求且队列已经超过 8无，直接快速拒绝（Fast-Fail） queueLen := atomic.LoadInt64(&c.currentQueue) if priority == PriorityNormal && queueLen > int64(float64(c.maxQueueLen)*0.8) { return nil, ErrQueueFull } if queueLen >= c.maxQueueLen { return nil, ErrQueueFull } atomic.AddInt64(&c.currentQueue, 1) defer atomic.AddInt64(&c.currentQueue, -1) // 3. 在 Queue 中等待超时或可用 Slot ticker := time.NewTicker(20 * time.Millisecond) defer ticker.Stop() for { select { case <-ctx.Done(): return nil, ctx.Err() case <-ticker.C: if atomic.LoadInt64(&c.activeSlots) < c.maxActiveSlots { atomic.AddInt64(&c.activeSlots, 1) return func() { atomic.AddInt64(&c.activeSlots, -1) }, nil } } } } func (c *LLMBackpressureController) HTTPMiddleware(next http.Handler) http.Handler { return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) { priority := PriorityNormal if r.Header.Get("X-User-Tier") == "VIP" { priority = PriorityVIP } // 最长等待 3 秒首字排队超时 ctx, cancel := context.WithTimeout(r.Context(), 3*time.Second) defer cancel() release, err := c.AcquireSlot(ctx, priority) if err != nil { w.Header().Set("Retry-After", "2") w.WriteHeader(http.StatusTooManyRequests) _, _ = w.Write([]byte(`{"error": "LLM Capacity Exceeded", "code": 429}`)) return } defer release() next.ServeHTTP(w, r.WithContext(ctx)) }) }

流式断连与 Prefill 算力回收机制

除了防范入站流量过载，大模型后端底座还应处理**客户端中途取消连接（Client Disconnect）**的算力浪费问题。

在 SSE 模式下，用户看到吐出前 5 个字不符合预期，经常会直接关闭网页或点击“停止生成”。

如果 Gateway 没有将 TCP 显式断开事件透传给底层推理 Engine，vLLM Engine 还会继续傻傻地把剩下的 2000 个 Token 吐完，白白浪费巨量的 GPU 显存与计算时间。

后端底座应建立Client Cancel Context Propagation机制：

当 Gateway 检测到r.Context().Done()触发（Client 断开）时，立即通过 gRPC / HTTP 向 vLLM 的/cancel接口发送request_id强行终止该 Request 的 Decode 循环，瞬间释放其占用的 KV Cache 页。

生产落地的底线要求

在大模型应用后端底座上线前，架构团队应守住三条底线：

  1. 尽量禁止无限制的 HTTP 长连接排队：Gateway 层面的 Queue 长度应是有界上限，超过界限立刻返回429降级提示。
  2. 区分 Prefill 节点与 Decode 节点（PD 分离架构）：高并发场景下，将 Prefill（计算 Prompt）与 Decode（生成 Token）部署在不同的 GPU 节点上，避免大 Prompt 输入卡死小生成的 Token 吐出。
  3. 熔断抢占 Swap 机制：一旦发现 GPU 显存 Swap 到 CPU 内存的频率大于 0，说明系统已经严重超载，背压控制器应立刻提高 Load Shedding 抛弃比例。

守住了 KV Cache 显存与首字延迟这条线，大模型后端底座才能在应对突发流量洪峰时做到较稳定。

网站建设 企业官网 运营推广
返回列表