大模型服务首版的必要边界

大模型服务首版的必要边界

第一版的边界应从一个具体业务任务和可观测指标出发；下面的组件只是可选组合，不是所有团队都必须采用的标准答案。

在研发团队首次启动大模型（LLM）应用后端底座项目时，非常容易走入“过度设计（Over-Engineering）”的误区。

有些团队项目还没上线，就急着搭建极其复杂的分布式向量数据库集群（Vector DB Cluster）、规划几十种 Agent 自动路由算法、引入重型微服务框架和复杂的异构流式图计算引擎。然而，历经三个月研发上线后，却发现系统每日调用量不过数千次，而复杂的分布式架构不仅导致部署运维痛苦不堪，还让排查长尾延迟问题变得极其困难。

第一版大模型应用后端底座，核心目标只有两个：极高的确定性 与 极致的轻量低延迟。

在第一版架构中，我们不需要包揽全宇宙的功能，而是要以最简约的代码结构，解决好大模型交互中最基础也最关键的核心链路：流式推送（SSE）、并发削峰与 Token 计费、以及轻量级上下文检索。

把第一版的边界收拢得越清晰，架构后期的可扩展性反而越好。

流式 SSE 传输与客户端连接管理的简化实现

大模型响应与传统 RESTful API 的最大区别在于 流式传输（Streaming）。为了让前端用户获得打字机式的即时反馈，后端必须采用 Server-Sent Events（SSE）或者 WebSocket 协议。

在第一版实施中，优先推荐使用 SSE 而非 WebSocket。

因为 SSE 是基于标准 HTTP 协议单向文本流，天生兼容 HTTP/2、网关层负载均衡和浏览器端原生 EventSource API。它的复杂度远低于需要维持双向心跳与重连协议的 WebSocket。

然而，在处理 SSE 长连接时，最忌讳的是在后端为每一个长连接开一个永久阻塞线程。在 Java Spring 体系中，应该使用 SseEmitter 结合 Reactive 异步模型；在 Go 语言中，则可以通过 http.Flusher 实现高效的非阻塞推流。

基于 Go 语言实现的 MVP 级别 SSE 流式推送与连接优雅切断示例代码：

package main

import (
"context"
"fmt"
"io"
"net/http"
"time"
)

// StreamHandler 处理大模型 SSE 流式输出与客户端主动断开
func StreamHandler(w http.ResponseWriter, r *http.Request) {
// 1. 设置 SSE 响应 Header
w.Header().Set("Content-Type", "text/event-stream")
w.Header().Set("Cache-Control", "no-cache")
w.Header().Set("Connection", "keep-alive")
w.Header().Set("Access-Control-Allow-Origin", "*")

flusher, ok := w.(http.Flusher)
if !ok {
http.Error(w, "Streaming unsupported!", http.StatusInternalServerError)
return
}

ctx := r.Context()

// 2. 模拟从大模型推理 API 读取流式 Chunk
chunkChan := mockLLMStreamInference(ctx)

for {
select {
case <-ctx.Done():
// 客户端断开连接（如关掉网页），立刻取消上游 LLM 请求，防止浪费 Token
fmt.Println("客户端主动断开 SSE 连接，释放上游算力资源")
return
case chunk, ok := <-chunkChan:
if !ok {
// 流式推送结束标记
fmt.Fprintf(w, "event: close\\ndata: [DONE]\\n\\n")
flusher.Flush()
return
}

// 3. 向客户端推送单个 SSE 数据块
fmt.Fprintf(w, "data: %s\\n\\n", chunk)
flusher.Flush() // 强制刷新缓冲区，确保实时性
}
}
}

// 模拟流式推理管道
func mockLLMStreamInference(ctx context.Context) <-chan string {
out := make(chan string)
go func() {
defer close(out)
tokens := []string{"架构", "设计的", "本质", "在于", "在正确", "的时间", "做关键", "的取舍。"}
for _, t := range tokens {
select {
case <-ctx.Done():
return
case <-time.After(150 * time.Millisecond):
out <- t
}
}
}()
return out
}

请求队列、Token 计费与并发限制的最小闭环

第一版底座千万不要直接把前端请求无脑透传给上游大模型。大模型 API 通常有严格的 RPM（Request Per Minute） 和 TPM（Token Per Minute） 限制。

如果第一版不做并发队列控制，一旦突发流量打进来，上游 API 会立刻返回 429 Too Many Requests，前端用户会大面积报错。

第一版必须包含的“最小闭环”防线：

关键取舍：什么时候该上向量数据库，什么时候内存检索就够了

在搭建 RAG（检索增强生成）知识库能力时，很多团队第一天就去部署 Milvus、Qdrant 等重型向量数据库。

其实在第一版（MVP 阶段），如果你的知识库文档数量在万级以下（例如几十本 PDF 规则说明书，或者几千条常见问题 FAQ），引入专门的向量数据库是典型的过度设计。

让我们来看一下关键工程取舍：

在第一版中，直接利用已有的 Redis 7.0+ 向量检索功能（Redis Search Module），或者在 JVM / Go 进程内存中加载 HNSW 索引，不仅能将研发周期缩短一半以上，还能获得极其强悍的毫秒级检索性能。

把第一版的架构做薄，把基础的 SSE 推送控制好，把并发上限卡死，把知识库检索控制在轻量内存级。待业务真实流量增长起来之后，再将各个组件平滑替换为微服务与分布式组件，这才是现代化后端架构演进的正确节奏。