DeepSeek之高并发架构筹划

一、配景

        前面根据学习DeepSeek与运维干系的团结之后，我们发现针对GPU、Ollama大概大模子本身必要做到许多监控项举行管理，才气包管大模子的高可用运行。随之而来的思索就是，应用层怎么在面对高并发、高流量环境下，包管整个应用的高可用性、可扩展性呢?
        接下来和各人分享一下这个过程中，传统的Web架构与融合了大模子的应用的Web架构有什么区别的地方， 而且怎样来实现这个高可用、高性能的架构。
二、传统Web架构与大模子思索

1、传统Web架构

        传统Web架构我们知道，如果利用了负载平衡器在前面举行负载，那么起首要思量的题目是session会话的题目。 
1、session共享(nfs、redis)等

        要么我们的后端接纳session共享机制， 可以通过nfs挂载到同一个盘，后端都能读取session信息，大概把全部的session存储到同一个地方，如redis等介质。
        为的就是实现session读写都在同一个地方，就不会造成session紊乱大概丢失的情况。 
2、后端服务改造为"无状态服务"，利用jwt

        尚有一种方式就是，改造我们的服务，从有状态改为无状态。 每次通报jwt的令牌，令牌内里有登录会话的信息，比方user_id、个人简朴信息等等，每次调用接口都是验证token是否合法，从中获取当前登任命户的信息举行处置处罚。
        这种无状态的机制，方便了我们举行负载平衡，而且也不必要像第一种方法一样，专门找一个介质要么nfs，要么redis要么数据库等等，将全部后端产生的session信息存储到同一个地方。进步了服务的可用性，也低沉了引入第三方服务的本钱.
2、大模子是无状态服务

        起首，大模子的对话是属于有状态照旧无状态呢?  基于前面的传统Web架构，我们起首得明白这个题目。  如许后续的架构才气筹划出来。
        干系资料如下:
        大语言模子，如 Transformer 架构的模子，在练习时，是基于大量文本数据举行学习，以推测下一个单词或标记。在每次处置处罚输入文本时，模子根据输入的序列数据举行盘算，其本身并不自然 “记着” 之前处置处罚过的输入内容，从这个意义上说，它是无状态的。比方，在练习完成后，单独输入一段文本，模子只是对这段文本举行处置处罚，天生相应的输出，不涉及对之前其他输入的影象。
        总结来说，大模子本身根本是无状态的，不外可以通过特定的输入构造方式等，让它在对话等应用场景中出现出有状态的效果。
         大模子没有所谓传统Web的session大概cookie机制，每次你的对话对于它都是"新的"，是无状态的服务。 都是基于你给的上下文，然后给你一个复兴，就这么简朴的逻辑。
         大模子之以是明白你的对话上下文， 是由于每次你问他一个新的题目标时间，都必要将之前的答复汗青记载通报给它， 它在基于这个汗青问答上下文，去给你的最新的题目，做一个答复。
 3、问答上下文 Token

        在大语言模子的语境中，“上下文 Token” 包罗两个关键概念，即 “上下文” 和 “Token”：

• Token：Token 是对文本举行处置处罚时分别的根本单位。由于大语言模子无法直接处置处罚文本数据，必要将文本转化为模子可以大概明白的数字情势，这一过程就涉及到对文本举行分词，分别成一个个 Token。比方，对于英文文本，Token 大概是一个单词、一个词缀以致是一个字母；对于中文文本，Token 可以是一个字、一个词等。好比句子 “我喜欢苹果”，大概被切分成 “我”“喜欢”“苹果” 三个 Token。模子在处置处罚输入和天生输出时，都是基于这些 Token 举行盘算和利用的。
  
• 上下文 Token：“上下文” 指的是与当前处置处罚的文本干系的前后文信息。“上下文 Token” 就是构成这些上下文信息的全部 Token 聚集。在对话或处置处罚连续文本时，模子为了精确明白当前输入的寄义并天生符合的复兴或输出，必要思量之前出现的文本内容（汗青对话、前文等），这些文本内容被转化为 Token 后，就构成了上下文 Token。比方在多轮对话中，前面几轮的对话内容所对应的 Token，与当前输入的 Token 一起，构成了模子处置处罚当前输入时的上下文 Token。模子会基于这些上下文 Token 来捕获文本之间的语义关联和逻辑关系，从而更好地完成任务，好比答复题目、天生连贯的文本等。
  

        简朴来说，上下文 Token 就是模子在处置处罚当前文本时所依靠的、由前后文及当前文本转化而来的根本单位聚集。
        上面第二点提到的每次必要通报，对话汗青记载就是上下文token。 而且每个模子针对上下文的token长度， 也就是这个大模子"影象本事"的一个体现。  能记载的上下文token越多，那么它的"影象越长"，能根据你整个提问记载举行更好地答复。
        上下文 Token 数目限定会影响模子对长文本的明白和处置处罚本事，更多的上下文 Token 意味着模子能思量更多前文信息，在处置处罚长篇文档、多轮复杂对话时更具上风。随着技能的发展，各模子也在不绝探索怎样突破现有限定，进步上下文处置处罚本事。  差别的模子，支持的上下文token长度不一样。
三、大模子Web架构思索

1、思绪

        通过我们的学习，原来大模子的会话的input输入、output输出是这么个玩意啊。 就是每次你的提问，以及模子的复兴都要记载下来，作为下一次你举行新题目提问的参数，这个参数叫对话上下文context。每次都是云云，而且呢token长度是有限定的，理论上你问到token超出上下文，应该是有题目标。
        比方为了包管token不超出模子的明白范围，可以针对将之前时间比力旧的删除，尚有一种就是滑动窗口的方式，每次都从前以后滑，包管了token的长度不超出范围，而且只管通报最新的上下文信息。
        既然大模子的对话是无状态的，那么团结传统Web架构，我们做一些应用层的改造即可了，照旧负载平衡、集群那套东西，往上应用即可。架构筹划如下.
2、架构图

        我们在Ollama集群前面，可以设置Nginx做反向署理。由于Ollama摆设的DeepSeek大模子是无状态的，无论流量到了哪个Ollama根据上下文token推断，举行答复，进步了并发本事。
        我们的应用层可以接纳Python、Golang、Java等编程语言举行实现，重点照旧看Ollama提供了哪些编程语言的SDK, 理论上来讲，只要Ollama提供官方支持的对应语言的SDK,那么都能很好支持我们去做应用后端。
        每次应用后端必要将对话记载存入Redis，每次得到效果也要存入Redis， 整个就是一个context上下文的内容，只要还在这个对话，就必要通报整个上下文token给Ollama集群，才气获取到更优质的答复。实现大模子"有状态"的答复效果。
3、Ollama SDK后端干系代码demo

针对context上下文存储代码demo:   可以团结redis，存储到redis

2. import ollama
4. # 初始化上下文管理器
5. class ConversationContext:
6.     def __init__(self, max_context_length=10):
7.         self.context = []  # 保存对话历史
8.         self.max_context_length = max_context_length  # 最大上下文长度
10.     def add_message(self, role, content):
11.         """添加消息到上下文"""
12.         self.context.append({"role": role, "content": content})
13.         # 如果上下文过长，移除最早的消息
14.         if len(self.context) > self.max_context_length:
15.             self.context.pop(0)
17.     def get_context(self):
18.         """获取当前上下文"""
19.         return self.context
21.     def clear_context(self):
22.         """清空上下文"""
23.         self.context = []
25. # 初始化对话上下文
26. conversation = ConversationContext(max_context_length=10)

复制代码

每次对话通报context上下文给到Ollama， Ollama负责通报给大模子:

2. def chat_with_model(user_input):
3.     # 将用户输入添加到上下文
4.     conversation.add_message("user", user_input)
6.     # 获取当前上下文, 上下文数组
7.     messages = conversation.get_context()
9.     # 调用 Ollama 模型
10.     response = ollama.chat(
11.         model="your-model-name",  # 替换为你的模型名称
12.         messages=messages    #传递上下文数组，  最后的一个元素应该是你的最新问题
13.     )
15.     # 获取模型回复
16.     model_reply = response["message"]["content"]
18.     # 将模型回复添加到上下文
19.     conversation.add_message("assistant", model_reply)
21.     return model_reply

复制代码

四、总结

        市面上看到的这些大模子，无外乎就是利用了Python的许多呆板学习框架做出来的东西。以是团结到我们的Web开辟，只要明白怎么摆设模子、调用模子、进步模子并发、高流量就行，本质上也那么复杂。
        重点的复杂和有核心技能难度的是模子怎么练习的、复杂的算法、算法优化等等才是大模子的核心，Web只是大模子向外袒露的intput、output方式罢了，本质和console控制台没多大区别。而且大模子最大的一个特点就是，整个问答实在是无状态的，这一点很紧张。