前言随着 LLM 从实验 Demo 走向商业化落地越来越多开发者开始搭建面向生产的大模型业务系统。很多 AI 工程师擅长 Prompt 调试、RAG、Agent 开发但缺乏后端架构思维系统简单堆砌接口、数据表杂乱无章、大量重复推理请求压垮模型服务、业务迭代后代码严重耦合上线后出现查询缓慢、并发雪崩、难以扩展等各类问题。一份真实企业 AI 后端岗位要求明确提出熟练掌握 RESTful API 设计、数据库建模、缓存、消息队列、异步任务、系统拆分具备良好接口设计与系统拆分能力。本文结合企业级 LLM 智能体业务平台实战经验围绕数据库建模、多级缓存架构、领域驱动系统拆分三大核心板块展开完整讲解大模型业务场景下的后端工程落地方法论配套 Python (FastAPI) 完整示例代码覆盖对话管理、知识库管理、任务调度、用量统计等典型 LLM 业务场景帮助 AI 工程师补齐后端架构短板搭建可长期迭代、支撑高并发的大模型业务系统。一、大模型业务系统业务特征与架构痛点在开展设计之前首先要认清 LLM 业务和传统 Web 业务的差异化特点请求耗时极不均衡普通接口毫秒级大模型流式推理往往数秒几十秒同步接口极易超时资源成本高昂LLM 推理消耗大量 GPU 算力相同 Query 重复推理会造成巨额资源浪费数据种类复杂用户对话消息、知识库文档、Agent 任务记录、模型调用账单、权限配置多类数据并存任务形态多样化即时对话、文档异步解析、长周期 Agent 任务、定时数据统计混合存在流量波动明显营销活动、业务高峰会带来流量尖峰若无缓存、队列削峰极易造成服务崩溃。常见反面案例所有数据挤在一张对话表不分库分表、缺少合理索引历史对话查询越跑越慢用户相同问题每次都重复调用 LLM 推理没有缓存策略全部逻辑写在单一 FastAPI 服务知识库、对话、计费、Agent 任务耦合在一起改动一处影响全系统同步执行文档向量化、长文本总结高并发场景接口大面积超时。针对以上痛点下文从数据库建模→缓存分层设计→业务系统拆分逐层落地。二、大模型业务系统数据库建模实战2.1 建模设计原则LLM 场景专属冷热数据分离近期活跃对话、历史归档对话拆分为不同数据表大字段独立存储对话完整 content、知识库原文等超大文本禁止和基础字段混表区分事务型数据与日志统计数据业务核心数据使用 MySQL海量审计日志、原始推理记录存入时序库 / 对象存储预留扩展字段适配不同模型、不同 Agent 新增参数避免频繁 DDL 改表适度冗余减少多表 Join大模型业务后台查询频繁优先降低关联查询复杂度。2.2 领域数据表结构设计MySQL我们以「企业 LLM 对话 知识库 Agent 平台」为例梳理核心实体租户、用户、对话会话、对话消息、知识库文档、模型调用账单。sql– 1.租户表多租户平台基础CREATE TABLEllm_tenant(idbigint PRIMARY KEY AUTO_INCREMENT COMMENT ‘租户ID’,tenant_namevarchar(100) NOT NULL COMMENT ‘租户名称’,contact_emailvarchar(100) COMMENT ‘联系人邮箱’,statustinyint NOT NULL DEFAULT 1 COMMENT ‘状态0禁用 1正常’,daily_token_quotabigint DEFAULT 0 COMMENT ‘每日token配额’,created_atdatetime DEFAULT CURRENT_TIMESTAMP,updated_atdatetime DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,KEY idx_status (status)) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT‘租户信息表’;– 2.会话主表一次对话一个sessionCREATE TABLEllm_chat_session(idbigint PRIMARY KEY AUTO_INCREMENT,session_idvarchar(64) NOT NULL COMMENT ‘会话唯一标识’,tenant_idbigint NOT NULL COMMENT ‘所属租户’,user_idvarchar(64) NOT NULL COMMENT ‘用户ID’,agent_idvarchar(64) COMMENT ‘绑定智能体ID’,titlevarchar(255) COMMENT ‘对话标题’,statustinyint DEFAULT 1 COMMENT ‘会话状态’,created_atdatetime DEFAULT CURRENT_TIMESTAMP,updated_atdatetime DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,UNIQUE KEY uk_session_id (session_id),KEY idx_tenant_user (tenant_id, user_id)) COMMENT‘对话会话表’;– 3.对话消息表【核心】存储每一轮问答CREATE TABLEllm_chat_message(idbigint PRIMARY KEY AUTO_INCREMENT,session_idvarchar(64) NOT NULL COMMENT ‘关联会话ID’,rolevarchar(20) NOT NULL COMMENT ‘user/assistant/system’,message_shortvarchar(512) COMMENT ‘消息简短预览’,message_content_idbigint COMMENT ‘大文本内容外键关联消息内容附表’,model_namevarchar(64) COMMENT ‘本次调用模型’,input_tokensint DEFAULT 0 COMMENT ‘输入token’,output_tokensint DEFAULT 0 COMMENT ‘输出token’,cost_msint DEFAULT 0 COMMENT ‘推理耗时ms’,created_atdatetime DEFAULT CURRENT_TIMESTAMP,KEY idx_session (session_id)) COMMENT‘对话消息表’;– 4.消息内容附表【冷热拆分大文本独立存储】CREATE TABLEllm_message_content(idbigint PRIMARY KEY AUTO_INCREMENT,full_contentLONGTEXT NOT NULL COMMENT ‘完整对话内容’,created_atdatetime DEFAULT CURRENT_TIMESTAMP) COMMENT‘对话大文本附表’;– 5.知识库文档主表CREATE TABLEllm_knowledge_doc(idbigint PRIMARY KEY AUTO_INCREMENT,doc_idvarchar(64) NOT NULL,tenant_idbigint NOT NULL,kb_idvarchar(64) NOT NULL COMMENT ‘所属知识库ID’,doc_namevarchar(255) NOT NULL COMMENT ‘文档名称’,source_typevarchar(32) COMMENT ‘pdf/md/txt’,statustinyint DEFAULT 0 COMMENT ‘0待解析 1解析完成 2失败’,created_atdatetime DEFAULT CURRENT_TIMESTAMP,UNIQUE KEY uk_doc_id(doc_id),KEY idx_kb_status(kb_id, status)) COMMENT‘知识库文档’;– 6.模型调用账单统计表CREATE TABLEllm_usage_bill(idbigint PRIMARY KEY AUTO_INCREMENT,tenant_idbigint NOT NULL,session_idvarchar(64),model_namevarchar(64) NOT NULL,total_input_tokensbigint DEFAULT 0,total_output_tokensbigint DEFAULT 0,stat_datedate NOT NULL COMMENT ‘统计日期’,created_atdatetime DEFAULT CURRENT_TIMESTAMP,UNIQUE KEY uk_tenant_date(tenant_id, stat_date, model_name),KEY idx_stat_date(stat_date)) COMMENT‘用量日统计表’;2.3 建模重点总结大文本拆分将超长对话文本单独存入llm_message_content日常列表查询只读取预览短文本避免大量 IO** 避免 SELECT ***生产严禁查询 LONGTEXT 字段做列表分页统计数据做预聚合每日用量写入 bill 统计表不要实时聚合原始消息表做账单查询超过 6 个月的历史对话定时归档至归档表保障活跃数据表体量可控。三、多级缓存架构设计LLM 系统降本核心大模型最大成本在于 GPU 推理算力缓存不仅仅是加速接口更是降低算力开销、节约成本最重要的手段。我们设计三级缓存体系本地内存缓存 → Redis 分布式缓存 → 模型结果缓存。3.1 缓存适用场景✅ 适合缓存无上下文独立问答、高频重复通用问题知识库检索结果短时间知识库未更新检索结果不变租户配置、智能体提示词模板、静态参数每日 Token 用量统计数据。❌ 不建议缓存多轮上下文依赖对话需要实时查询数据库 / 外部 API 的动态数据时效性要求极高、频繁变更的业务数据。3.2 FastAPI Redis 缓存完整代码实现python运行import hashlibimport jsonimport redisfrom fastapi import FastAPIfrom functools import lru_cachefrom pydantic import BaseModelfrom typing import Optionalapp FastAPI(title“LLM系统缓存示例”)连接Redisredis_client redis.Redis(host“127.0.0.1”, port6379, db0, decode_responsesTrue)请求结构体class ChatRequest(BaseModel):session_id: strquery: strmodel_name: strtemperature: float 0.7use_cache: bool True--------------------------工具函数--------------------------def generate_cache_key(query: str, model: str, temperature: float) - str:“”“生成唯一缓存key不同参数区分缓存结果”“”raw_str f{query}|{model}|{temperature:.2f}md5_key hashlib.md5(raw_str.encode(“utf-8”)).hexdigest()return fllm:cache:reply:{md5_key}lru_cache(maxsize2000)def get_local_static_config(tenant_id: str):“”“一级缓存本地内存缓存存放极少变更的租户配置、Prompt模板”“”# 模拟数据库查询print(“【未命中本地缓存查询数据库】”)return {“prompt_template”: “你是企业智能客服基于知识库回答用户问题”,“max_context_len”: 8192}async def llm_infer(query: str, model_name: str, temp: float):“”“模拟真实大模型推理生产对接vLLM/OpenAI接口”“”print(f执行真实LLM推理 query{query}“)return f”【模型回复】针对问题{query} 的标准回答内容--------------------------对话接口--------------------------app.post(“/api/chat/completion”)async def chat_endpoint(req: ChatRequest):# 多轮对话不启用结果缓存单轮独立问答开启缓存if req.use_cache and len(req.session_id) 12:cache_key generate_cache_key(req.query, req.model_name, req.temperature)cache_data redis_client.get(cache_key)if cache_data:print(“命中Redis模型结果缓存”)return {“reply”: json.loads(cache_data), “cache_hit”: True}# 缓存未命中调用大模型推理 llm_result await llm_infer(req.query, req.model_name, req.temperature) # 写入缓存过期时间30分钟知识库更新时主动清理对应缓存 if req.use_cache: redis_client.setex( cache_key, 1800, json.dumps(llm_result, ensure_asciiFalse) ) return {reply: llm_result, cache_hit: False}获取租户配置接口使用本地内存缓存app.get(“/api/tenant/config”)async def get_tenant_config(tenant_id: str):config get_local_static_config(tenant_id)return configifname “main”:import uvicornuvicorn.run(app, host“0.0.0.0”, port8000)3.3 缓存避坑策略缓存一致性知识库文档新增 / 修改 / 删除时主动清理检索结果缓存与问答缓存避免旧知识持续输出缓存雪崩缓存过期时间增加随机偏移量防止大量 key 同一时刻失效缓存穿透高频不存在的 query 设置空值短期缓存冷热分离动态推理结果缓存短 TTL基础配置类缓存长期有效变更主动删除。四、领域驱动大模型业务系统如何合理拆分很多初期项目全部代码写在单一服务随着迭代膨胀上万行代码每次上线风险巨大。我们按照领域边界拆分服务结合异步消息队列消解 LLM 长耗时任务。4.1 推荐拆分方案适合中大型 LLM 平台Gateway 网关服务负责鉴权、路由、限流、日志审计、请求转发对应多租户平台接入层对话业务服务chat-service Python/FastAPI用户对话管理、会话 CRUD、多轮上下文组装、调用推理集群知识库服务knowledge-service文档上传、文本切割、向量化入库、向量库管理、RAG 检索Agent 调度服务agent-service任务规划、工具调用、长周期任务管理、智能体工作流执行用量 计费服务bill-service Java/SpringBootToken 用量统计、租户配额校验、账单生成、定时结算异步任务 Worker 集群文档异步解析、批量向量化、模型评测任务、定时报表基于 RabbitMQ/RocketMQ 解耦。4.2 同步改造异步案例消息队列实战示例原始问题用户上传 PDF 文档同步执行文档解析、文本分割、向量化入库。文档越大耗时越长极易接口超时。优化方案接口仅接收文件投递消息队列由消费 Worker 异步处理。python运行消息生产者知识库上传接口import pikaconnection pika.BlockingConnection(pika.ConnectionParameters(‘127.0.0.1’))channel connection.channel()channel.queue_declare(queue“doc_parse_queue”, durableTrue)app.post(“/api/knowledge/upload_doc”)async def upload_document(kb_id: str, doc_name: str):“”“文档上传接口只投递消息不阻塞”“”# 1.数据库创建文档记录状态待解析doc_info {“kb_id”: kb_id,“doc_name”: doc_name,“doc_id”: “doc_xxxx123”}# db.insert(llm_knowledge_doc, data…)# 2.投递异步任务channel.basic_publish(exchange“”,routing_key“doc_parse_queue”,bodyjson.dumps(doc_info),propertiespika.BasicProperties(delivery_mode2))return {“code”:0, “msg”:“文档已接收后台开始解析”}消费者 Worker 独立进程执行耗时任务不占用 Web 服务线程池实现服务解耦。4.3 系统拆分核心原则以业务领域划分不要按技术层拆分长耗时任务一律异步化避免拖垮 Web 接口服务之间通过 HTTP / 消息队列通信禁止直接跨服务访问数据库小团队初期不必过度微服务可以先模块分层预留拆分边界避免过度微服务带来运维负担。五、全链路落地问题复盘5.1 数据库踩坑总结不分冷热表对话表持续膨胀 → 解决方案冷热拆分 定时归档查询不分页前端一次性拉取全部历史对话 → 强制分页、限制单次最大条数缺少索引列表查询全表扫描 → 所有查询条件建立合适联合索引。5.2 缓存踩坑总结不分场景无脑缓存多轮对话造成上下文错乱 → 多轮对话关闭结果缓存缓存永久有效知识库更新后问答依然使用旧内容 → 设计主动失效机制。5.3 系统拆分踩坑总结初期追求微服务拆分大量小服务运维复杂度暴增同步接口执行向量化、文档解析高峰期大量请求超时服务之间直接访问 MySQL丧失数据权限管控后续无法拆分。六、总结对于 AI 大模型工程师来说仅仅掌握大模型调用、RAG、Agent 远远不足以独立负责商业化项目。数据库建模决定系统数据底座能否长期稳定扩展多级缓存直接控制 GPU 算力成本合理系统拆分决定项目迭代维护成本。一套成熟 LLM 业务后端应当做到数据分层存储、冷热分离算力资源通过缓存节约长短任务分离同步异步合理搭配按照业务领域清晰划分模块与服务。当你能够完整从数据表设计、缓存策略、服务拆分独立完成整套 LLM 平台后端设计时就完成了从「只会调用 API 的 AI 应用开发者」到「具备架构能力的 AI 后端工程师」的跨越。后续进阶方向可以继续研究分布式定时任务、链路追踪、服务监控告警、多租户数据隔离、灰度发布等云原生能力持续完善大模型平台工程体系。