LLM网关项目复盘：多模型统一接入层的架构设计与工程挑战

LLM网关项目复盘多模型统一接入层的架构设计与工程挑战一、多模型的巴别塔问题一个AI应用同时使用了5个LLM ProviderOpenAI、Anthropic、DeepSeek、通义千问、Moonshot。每个Provider有自己的SDK、请求格式、响应格式、错误码——代码中散落着5套if-else逻辑。更麻烦的是需要做A/B对比同一问题发给两个模型、故障切换OpenAI挂了自动切Anthropic、成本控制优先用便宜模型复杂问题才用贵的。这些都指向同一个需求多模型的统一接入层——不关心用什么模型只关心得到了什么回答。二、统一抽象层的设计核心接口Provider抽象type LLMProvider interface { Name() string Chat(ctx context.Context, req ChatRequest) (*ChatResponse, error) StreamChat(ctx context.Context, req ChatRequest) (-chan StreamEvent, error) ListModels(ctx context.Context) ([]Model, error) } // 统一的请求/响应——屏蔽Provider差异 type ChatRequest struct { Model string Messages []Message Temperature float64 MaxTokens int Stream bool } type ChatResponse struct { ID string Model string Content string FinishReason string Usage Usage Latency time.Duration } // OpenAI Adapter type OpenAIProvider struct { client *openai.Client config ProviderConfig } func (p *OpenAIProvider) Chat(ctx context.Context, req ChatRequest) (*ChatResponse, error) { // 内部格式转换统一格式 → OpenAI格式 resp, err : p.client.CreateChatCompletion(ctx, openai.ChatCompletionRequest{ Model: req.Model, Messages: toOpenAIMessages(req.Messages), Temperature: req.Temperature, MaxTokens: req.MaxTokens, }) if err ! nil { return nil, p.mapError(err) // 错误码标准化 } // 响应标准化OpenAI格式 → 统一格式 return toChatResponse(resp), nil } // Anthropic Adapter type AnthropicProvider struct { client *anthropic.Client } func (p *AnthropicProvider) Chat(ctx context.Context, req ChatRequest) (*ChatResponse, error) { // Claude格式转换 msg, err : p.client.Messages.Create(ctx, anthropic.MessageNewParams{ Model: req.Model, Messages: toAnthropicMessages(req.Messages), MaxTokens: int64(req.MaxTokens), Temperature: anthropic.Float(req.Temperature), }) // ... }三、智能路由策略基于内容的路由type Router struct { rules []RouteRule defaultProvider string } type RouteRule struct { Matcher func(req ChatRequest) bool Provider string } func (r *Router) Route(req ChatRequest) string { // 代码相关 → DeepSeek代码能力好且便宜 // 长文本 → Claude200K上下文 // 默认 → GPT-4o for _, rule : range r.rules { if rule.Matcher(req) { return rule.Provider } } return r.defaultProvider } // 路由规则配置 var defaultRules []RouteRule{ { Matcher: func(req ChatRequest) bool { return containsKeyword(req.Messages, 代码, bug, function) }, Provider: deepseek, }, { Matcher: func(req ChatRequest) bool { return estimateTokenCount(req.Messages) 100000 }, Provider: claude, // 大上下文场景 }, }基于优先级的故障切换func (g *Gateway) Chat(ctx context.Context, req ChatRequest) (*ChatResponse, error) { primary : g.router.Route(req) fallbacks : g.getFallbackChain(primary) // [primary, fallback1, fallback2] var lastErr error for _, providerName : range fallbacks { provider : g.providers[providerName] if !g.circuitBreaker.IsOpen(providerName) { resp, err : provider.Chat(ctx, req) if err nil { return resp, nil } lastErr err g.circuitBreaker.RecordFailure(providerName) } } return nil, fmt.Errorf(所有Provider都不可用: %w, lastErr) }四、成本控制与可观测性成本追踪每个请求记录实际消耗的Token和费用func (g *Gateway) Chat(ctx context.Context, req ChatRequest) (*ChatResponse, error) { start : time.Now() resp, err : g.routeAndExecute(ctx, req) // 记费用——不管成功失败 cost : g.calculateCost(resp) g.metrics.RecordRequest(MetricRecord{ Provider: resp.Provider, Model: req.Model, Tokens: resp.Usage.TotalTokens, Cost: cost, Latency: time.Since(start), Error: err, }) return resp, err } func (g *Gateway) calculateCost(resp *ChatResponse) float64 { // 各模型定价 pricing : map[string]float64{ gpt-4o: 0.005 / 1000, // $0.005/1K tokens gpt-4o-mini: 0.00015 / 1000, claude-3-opus: 0.015 / 1000, deepseek-chat: 0.00014 / 1000, } rate, ok : pricing[resp.Model] if !ok { return 0 } return float64(resp.Usage.TotalTokens) * rate }月费用报表基于记录的数据自动生成各Provider的费用分布。DeepSeek处理了65%的请求但仅占总费用的12%GPT-4o仅15%的请求却占总费用的72%。五、总结LLM网关的核心价值统一接入层屏蔽了5个Provider的SDK差异——调用方不感知底层用哪个模型智能路由节省了约40%的LLM费用——简单问题用便宜模型复杂问题才用贵的故障切换让整体可用性从单Provider的99.5%提升到99.9%成本追踪让每个请求花了多少钱从黑盒变成白盒Provider接口抽象让新增模型接入成本从改全局代码降到实现一个适配器当前网关日均处理约2万次LLM调用月费用约$1800。智能路由策略将DeepSeek/GPT-4o-mini等低成本模型的使用率从初始的40%提升到65%月节省约$700。最大的架构取舍流式响应streaming要求Provider适配器支持SSE推送复杂度是指令式非流式的3倍。如果不需要流式输出如后台批量处理适配器实现可以大幅简化。网关的流式和非流式两套路径独立维护是当前架构的主要技术债。