LLM 无状态架构实践：从原理到代码落地

在大语言模型（LLM）的应用开发中，无状态（Stateless） 是保障高并发、高可用的核心设计原则。本文将从无状态的核心概念出发，结合实际代码案例，详解如何在 LLM 接口调用中落地无状态架构，同时解决对话历史管理的核心问题。

一、LLM 无状态的核心原理

1. 什么是无状态？

HTTP 协议本身是无状态的 ------ 每个请求都是独立的，服务器不会存储客户端的状态信息，这意味着：

客户端的每次请求必须包含完整的上下文，服务器无需依赖「之前的请求」就能处理当前请求；
服务器可以水平扩展，任意一台服务器处理请求的结果完全一致；
对比「有状态」架构：如果服务器需要存储用户对话历史，高并发下会导致内存溢出、扩容困难，最终压垮 LLM 服务。

2. LLM 无状态的核心要求

LLM 接口基于 HTTP 实现无状态调用的核心逻辑是：让客户端而非服务器维护对话上下文。因为 LLM 本身不会「记住」任何对话，想要让模型理解上下文，必须在每次请求时手动带上全部对话历史。

二、无状态架构下的 LLM 调用实践

1. 基础实现：手动维护对话历史

下面的代码基于 DeepSeek API 演示无状态调用的核心逻辑 ------ 通过客户端维护chatHistory数组，每次请求都携带完整的对话上下文：

javascript

运行

javascript 复制代码

import OpenAI from 'openai';
import { config } from 'dotenv';
config();

// 初始化OpenAI兼容客户端（对接DeepSeek）
const client = new OpenAI({
  apiKey: process.env.DEEPSEEK_API_KEY,
  baseURL: process.env.DEEPSEEK_API_BASE_URL,
});

/**
 * 核心：客户端维护对话历史（无状态架构的关键）
 * 所有上下文由客户端管理，服务器无需存储
 */
let chatHistory = [
  { role: 'system', content: '你是一个严谨的助手，仅根据提供的对话历史回答问题' }
];

/**
 * 封装无状态LLM调用函数
 * @param {string} userInput 用户输入
 * @returns {Promise<string>} 模型回复
 */
async function callLLMWithHistory(userInput) {
  // 1. 将当前用户输入加入对话历史
  chatHistory.push({ role: 'user', content: userInput });

  try {
    // 2. 发起无状态请求：携带完整对话历史
    const response = await client.chat.completions.create({
      model: 'deepseek-v4-flash',
      messages: chatHistory, // 核心：每次请求传递完整上下文
      temperature: 0.1 // 保证回答稳定性
    });

    const assistantReply = response.choices[0].message.content;
    // 3. 将模型回复加入对话历史（供下一次请求使用）
    chatHistory.push({ role: 'assistant', content: assistantReply });

    return assistantReply;
  } catch (err) {
    console.error('LLM调用失败：', err);
    throw err;
  }
}

/**
 * 测试无状态对话流程
 */
async function testStatelessLLM() {
  console.log('=== 第一次请求：传递基础信息 ===');
  const firstReply = await callLLMWithHistory('请记住我叫字节邓');
  console.log('模型回复：', firstReply);

  console.log('\n=== 第二次请求：依赖上下文提问 ===');
  const secondReply = await callLLMWithHistory('请问我的名字是什么？');
  console.log('模型回复：', secondReply);

  console.log('\n=== 客户端维护的完整对话历史 ===');
  console.log(chatHistory);
}

// 执行测试
testStatelessLLM();

2. 代码核心说明

无状态核心 ：每次调用client.chat.completions.create时，messages参数传入完整的chatHistory，服务器无需存储任何状态；
上下文维护 ：用户输入和模型回复都被追加到chatHistory，确保下一次请求能复用上下文；
高可用保障 ：即使切换 LLM 服务器节点，只要传入相同的chatHistory，就能得到相同的结果，满足水平扩展要求。

三、对话历史管理的核心问题与优化

基础实现虽然能满足无状态要求，但随着对话次数增加，会出现新问题：

chatHistory体积越来越大，Token 开销指数级增长；
无用的历史信息会降低模型响应速度，甚至触发上下文长度限制。

优化方案：LRU 策略裁剪对话历史

LRU（最近最少使用）策略可以保留最近的核心对话，删除久远的无关内容，平衡上下文完整性和 Token 开销：

javascript

运行

javascript 复制代码

import OpenAI from 'openai';
import { config } from 'dotenv';
config();

const client = new OpenAI({
  apiKey: process.env.DEEPSEEK_API_KEY,
  baseURL: process.env.DEEPSEEK_API_BASE_URL,
});

// 对话历史配置：保留最近10轮有效对话（可根据Token限额调整）
const CHAT_HISTORY_CAPACITY = 10;
let chatHistory = [
  { role: 'system', content: '你是一个严谨的助手，仅根据提供的对话历史回答问题' }
];

/**
 * LRU策略裁剪对话历史
 * 保留system指令 + 最近的对话，删除超出容量的历史
 */
function trimChatHistory() {
  // system指令始终保留，其余对话按容量裁剪
  const systemMessage = chatHistory.filter(item => item.role === 'system');
  const contextMessages = chatHistory.filter(item => item.role !== 'system');
  
  // 只保留最近的CHAT_HISTORY_CAPACITY条上下文
  const trimmedContext = contextMessages.slice(-CHAT_HISTORY_CAPACITY);
  
  chatHistory = [...systemMessage, ...trimmedContext];
}

/**
 * 优化版无状态LLM调用（带LRU裁剪）
 */
async function callLLMWithLRU(userInput) {
  chatHistory.push({ role: 'user', content: userInput });
  
  // 裁剪历史，控制Token开销
  trimChatHistory();

  try {
    const response = await client.chat.completions.create({
      model: 'deepseek-v4-flash',
      messages: chatHistory,
      temperature: 0.1
    });

    const assistantReply = response.choices[0].message.content;
    chatHistory.push({ role: 'assistant', content: assistantReply });
    
    // 再次裁剪（防止回复后超出容量）
    trimChatHistory();

    return assistantReply;
  } catch (err) {
    console.error('LLM调用失败：', err);
    throw err;
  }
}

/**
 * 测试LRU裁剪效果
 */
async function testLLMWithLRU() {
  // 模拟多轮对话
  const questions = [
    '请记住我叫字节邓',
    '我是做什么的？（提示：前端开发）',
    '我的名字和职业分别是什么？',
    '前端开发需要掌握哪些核心技术？',
    '我名字里的最后一个字是什么？'
  ];

  for (const [index, question] of questions.entries()) {
    console.log(`\n=== 第${index+1}次请求 ===`);
    const reply = await callLLMWithLRU(question);
    console.log('用户：', question);
    console.log('模型：', reply);
  }

  console.log('\n=== 裁剪后的对话历史 ===');
  console.log(chatHistory);
}

testLLMWithLRU();

四、无状态架构的进阶方向

Context Engineering（上下文工程） ：通过 RAG（检索增强生成）补充外部知识库，替代冗长的对话历史，既保留上下文又降低 Token 开销；
Loop Engineering（循环工程） ：通过自动化循环校验、补全上下文，让模型在无状态下完成复杂任务；
Prompt Engineering（提示词工程） ：优化提示词结构，让模型用更少的 Token 理解核心上下文，提升无状态调用的效率。

五、总结

LLM 无状态架构的核心是「客户端维护上下文，服务器无状态处理」：

基础层：每次请求携带完整对话历史，保障服务器水平扩展能力；
优化层：通过 LRU 等策略裁剪历史，平衡 Token 开销和上下文完整性；
进阶层：结合上下文工程、提示词工程，提升无状态调用的效率和效果。

这种架构既符合 HTTP 无状态的本质，又能适配 LLM 高并发、高可用的业务需求，是大规模 LLM 应用的核心设计原则。