GLM-4-9B-Chat-1M步骤详解：Streamlit状态管理+多用户会话隔离实现方式

GLM-4-9B-Chat-1M步骤详解：Streamlit状态管理+多用户会话隔离实现方式

1. 为什么需要会话隔离？——从单用户到多用户的实际挑战

你刚在本地跑起 GLM-4-9B-Chat-1M，输入一段代码问它“为什么报错”，它秒回精准分析；再粘贴一份合同问“关键违约条款在哪”，它条分缕析。一切都很丝滑——直到你把链接发给同事，两人同时打开浏览器，各自提问。

结果发现：你刚问完“这段SQL怎么优化”，同事刷新页面后看到的却是你上一条关于合同的对话记录；更糟的是，当你们几乎同时发送消息，模型返回的内容开始错乱交叉——你的代码分析混进了对方的会议纪要摘要。

这不是模型的问题，而是 Streamlit 默认状态共享惹的祸。

Streamlit 的st.session_state在默认配置下是全局共享的：所有用户访问同一个 URL，共用同一份内存变量。对单人调试很友好，但一旦多人协作、团队试用、甚至只是你开两个浏览器标签页测试不同场景，就会立刻暴露问题——对话历史串了、上下文丢了、模型“记混人”了。

这恰恰违背了 GLM-4-9B-Chat-1M 的核心价值之一：私有化、可信赖、可追溯的本地智能助手。如果连“谁问了什么”都分不清，再强的百万上下文能力也失去意义。

所以，真正的本地化部署，不只是模型跑在自己机器上，更是每个用户拥有独立、隔离、持久的对话空间。本文就带你手把手实现它——不依赖数据库、不改模型结构、纯 Streamlit 原生方案，清晰、轻量、可直接复用。

2. 核心思路：用唯一标识符切分状态空间

解决多用户会话隔离，本质是做两件事：

• 识别用户：区分“张三”和“李四”不是靠登录，而是靠浏览器会话（session）本身；
• 隔离状态：为每个用户分配独立的st.session_state子空间，互不干扰。

Streamlit 官方文档明确指出：st.session_state本身不支持自动用户隔离，但提供了st.connection和st.cache_resource等机制辅助构建。而最直接、最轻量、最符合本项目定位（纯本地、零外部依赖）的方式，是利用st.runtime.scriptrunner.get_script_run_ctx()获取当前会话 ID，再以此为键，动态管理用户专属状态。

这个 ID 是 Streamlit 内部为每次页面加载生成的唯一字符串，只要用户不关闭标签页或强制刷新，ID 就保持稳定；不同用户、不同标签页、不同设备，ID 全然不同——天然适合作为会话隔离的锚点。

我们不存数据库，不建服务端 session，只在内存中维护一个字典：

{ "session_id_abc123": {"messages": [...], "context_length": 850000}, "session_id_def456": {"messages": [...], "context_length": 210000}, ... }

每次用户操作前，先查 ID，再读/写对应子空间。整个过程毫秒级完成，无额外延迟。

3. 实现步骤详解：从零构建隔离式聊天界面

3.1 初始化会话管理器

首先，在应用入口（app.py顶部）定义一个线程安全的全局状态容器。我们用st.cache_resource保证其单例性，并用threading.Lock防止并发写冲突：

import threading import streamlit as st from streamlit.runtime.scriptrunner import get_script_run_ctx # 全局会话存储（线程安全） @st.cache_resource def get_session_store(): return { "store": {}, "lock": threading.Lock() } def get_session_id(): """获取当前浏览器会话唯一ID""" ctx = get_script_run_ctx() if ctx is None: return "default" return ctx.session_id def get_user_state(): """获取当前用户专属状态字典""" store = get_session_store() session_id = get_session_id() with store["lock"]: if session_id not in store["store"]: # 初始化新用户状态 store["store"][session_id] = { "messages": [], "context_used": 0, # 已用上下文长度（tokens） "max_context": 1_000_000 # GLM-4-9B-Chat-1M上限 } return store["store"][session_id]

关键点说明：

• @st.cache_resource确保get_session_store()全局只执行一次，避免重复初始化；
• threading.Lock是必须的——Streamlit 多用户请求可能并发触发状态写入；
• get_session_id()是核心，它不依赖 Cookie 或登录态，纯粹基于 Streamlit 运行时上下文，断网、无网络权限环境完全可用。

3.2 构建隔离式聊天界面

接下来，用get_user_state()替代直接使用st.session_state。完整 UI 逻辑如下：

# --- 页面配置 --- st.set_page_config( page_title="GLM-4-9B-Chat-1M 本地助手", page_icon="", layout="wide" ) # --- 获取当前用户状态 --- user_state = get_user_state() # --- 侧边栏：用户信息与控制 --- with st.sidebar: st.header(" 当前会话") st.caption(f"ID: {get_session_id()[:8]}...") # 显示已用上下文占比（直观体现1M能力） used_pct = min(100, int((user_state["context_used"] / user_state["max_context"]) * 100)) st.progress(used_pct, text=f"上下文占用: {used_pct}% ({user_state['context_used']:,}/{user_state['max_context']:,} tokens)") if st.button("🗑 清空对话", type="secondary"): user_state["messages"] = [] user_state["context_used"] = 0 st.rerun() # --- 主聊天区域 --- st.title(" GLM-4-9B-Chat-1M 本地对话助手") st.caption("支持百万级长文本理解 · 数据全程离线 · 4-bit量化显存友好") # 显示历史消息（自动按角色渲染） for msg in user_state["messages"]: with st.chat_message(msg["role"]): st.write(msg["content"]) # --- 用户输入处理 --- if prompt := st.chat_input("输入问题或粘贴长文本（支持PDF/DOCX/TXT上传）..."): # 1. 添加用户消息 user_state["messages"].append({"role": "user", "content": prompt}) # 2. 模拟调用GLM模型（此处替换为你的真实推理逻辑） # 注意：真实部署需接入transformers + auto-gptq 或 llama.cpp 量化加载 with st.chat_message("assistant"): with st.spinner("🧠 正在深度理解上下文..."): # 【此处为伪代码，实际应调用你的模型推理函数】 # response = model.generate(prompt, history=user_state["messages"]) response = f"已收到您的输入（约{len(prompt)}字）。作为本地百万上下文模型，我将结合您此前的全部对话（共{len(user_state['messages'])-1}轮）进行综合分析。" # 3. 更新上下文用量估算（简化版，实际需tokenizer精确统计） # 假设每字符≈1.2 token，粗略估算 estimated_tokens = int(len(prompt) * 1.2) user_state["context_used"] += estimated_tokens st.write(response) user_state["messages"].append({"role": "assistant", "content": response})

为什么不用st.session_state直接存？
因为st.session_state是全局的，所有用户共享。而user_state是我们通过 session_id 动态索引的独立字典，天然隔离。你清空自己的对话，不会影响任何人。

3.3 支持文件上传的上下文注入

GLM-4-9B-Chat-1M 的真正威力在于处理长文档。我们扩展文件上传功能，并确保上传内容被正确计入上下文：

# 在主聊天区域上方添加文件上传区 uploaded_file = st.file_uploader( " 上传长文档（PDF/TXT/DOCX）", type=["pdf", "txt", "docx"], label_visibility="collapsed" ) if uploaded_file is not None: # 1. 读取文件内容（简化示例，实际需用PyPDF2/docx2python等） file_content = "" if uploaded_file.type == "text/plain": file_content = uploaded_file.getvalue().decode("utf-8")[:50000] # 截断防爆 elif uploaded_file.type == "application/pdf": file_content = "[PDF文件已上传，共" + str(len(uploaded_file.getvalue())) + "字节]" else: file_content = "[DOCX文件已上传]" # 2. 将文件内容作为系统提示注入（模拟“你已阅读该文档”） system_msg = f"【系统提示】用户已上传一份文档，内容摘要如下：\n\n{file_content[:200]}...\n\n请基于此文档内容回答后续问题。" # 3. 添加到消息历史（仅用户可见，不计入模型输入token，避免超限） user_state["messages"].append({ "role": "system", "content": system_msg, "is_file": True }) st.success(f" 文档已加载！可直接提问（如：“总结这份合同的核心条款”）")

注意：真实生产中，PDF/DOCX 解析需用专业库（如pymupdf解析 PDF，python-docx解析 DOCX），并做分块、去噪、编码等预处理。此处仅展示状态管理如何与文件流协同。

4. 关键细节与避坑指南

4.1 上下文长度的精准追踪

GLM-4-9B-Chat-1M 标称 100 万 tokens，但实际使用中极易超限。不能只靠字符数估算，必须对接 tokenizer：

from transformers import AutoTokenizer # 加载GLM-4 tokenizer（需提前下载） tokenizer = AutoTokenizer.from_pretrained("THUDM/glm-4-9b-chat-1m") def count_tokens(text: str) -> int: """精确统计GLM-4 tokenizer下的token数量""" return len(tokenizer.encode(text, add_special_tokens=False)) # 使用示例 prompt_tokens = count_tokens(prompt) history_tokens = sum(count_tokens(m["content"]) for m in user_state["messages"] if m["role"] != "system") total_tokens = prompt_tokens + history_tokens if total_tokens > user_state["max_context"] * 0.95: # 预留5%缓冲 st.warning(f" 上下文接近上限（{total_tokens:,}/{user_state['max_context']:,}）！建议清空部分历史或精简输入。")

4.2 防止状态“漂移”的三个技巧

• 技巧1：禁用st.experimental_rerun()全局重载
  st.rerun()会重置整个脚本，导致get_session_id()重新生成，用户可能“丢失”会话。改用st.experimental_set_query_params()+ URL 参数维持状态，或仅局部重绘（st.empty().write(...)）。

• 技巧2：为系统消息添加标记
  如上文{"is_file": True}，避免误将系统提示计入 token 统计，也方便前端过滤显示。

• 技巧3：设置会话过期清理
  长时间闲置的会话会累积内存。添加后台清理逻辑（非必须，但推荐）：

import time from datetime import datetime # 在 get_session_store 中扩展 @st.cache_resource def get_session_store(): return { "store": {}, "lock": threading.Lock(), "last_access": {} # 记录最后访问时间 } # 在 get_user_state 中更新访问时间 with store["lock"]: store["last_access"][session_id] = time.time() # 清理1小时未访问的会话 now = time.time() to_remove = [sid for sid, ts in store["last_access"].items() if now - ts > 3600] for sid in to_remove: store["store"].pop(sid, None) store["last_access"].pop(sid, None)

4.3 与模型推理层的无缝衔接

你的model.generate()调用必须接收当前会话的完整消息历史，并返回结构化响应。推荐封装为统一接口：

def call_glm_model(messages: list, max_new_tokens: int = 1024) -> str: """ 封装GLM-4-9B-Chat-1M推理调用 messages: [{"role": "user"/"assistant", "content": "..."}, ...] 返回纯文本响应 """ # 1. 构造GLM格式输入（参考官方chat template） input_text = "" for msg in messages: if msg["role"] == "user": input_text += f"<|user|>\n{msg['content']}<|assistant|>\n" elif msg["role"] == "assistant": input_text += f"{msg['content']}" # 2. 调用量化模型（示例：使用auto-gptq） # inputs = tokenizer(input_text, return_tensors="pt").to("cuda") # outputs = model.generate(**inputs, max_new_tokens=max_new_tokens) # return tokenizer.decode(outputs[0], skip_special_tokens=True) return "【模型响应占位符】实际部署时替换为上述逻辑" # 在聊天主循环中调用 response = call_glm_model(user_state["messages"])

5. 效果验证与多用户实测方法

别只信代码，动手验证才是关键。以下是三种低成本验证方式：

5.1 同一设备双标签页测试

1. 打开 Chrome，访问http://localhost:8080→ 标签页 A；
2. Ctrl+T新建标签页 B，同样访问http://localhost:8080；
3. 在 A 中输入：“你好，我是张三” → 发送；
4. 在 B 中输入：“你好，我是李四” → 发送；
5. 分别查看双方侧边栏的session_id—— 必然不同；
6. 查看各自聊天记录 —— 完全独立，无任何交叉。

5.2 不同设备局域网测试

• 你的笔记本运行streamlit run app.py --server.port=8080；
• 手机连接同一 WiFi，浏览器访问http://[笔记本IP]:8080（如http://192.168.1.100:8080）；
• 双方同时提问，观察侧边栏 session_id 和对话历史 —— 100% 隔离。

5.3 压力测试：5用户并发会话

用 Python 脚本模拟 5 个用户快速提问：

import requests import threading import time def simulate_user(user_id): # 模拟浏览器请求（需配合Streamlit的session机制，此处为概念示意） for i in range(3): time.sleep(0.5) # POST 到你的API端点（若你封装了后端）或直接调用本地函数 print(f"[User-{user_id}] 提问第{i+1}轮") # 启动5个线程 threads = [threading.Thread(target=simulate_user, args=(i,)) for i in range(5)] for t in threads: t.start() for t in threads: t.join()

只要你的显存够（GLM-4-9B-Chat-1M 4-bit 约 8GB），5 用户并发提问毫无压力——因为状态管理是纯内存操作，不增加 GPU 负担。

6. 总结：让百万上下文真正属于每个用户

我们没有引入 Redis、不依赖 PostgreSQL、不改造模型架构，仅用 Streamlit 原生机制和几十行 Python，就实现了：

• 真隔离：每个用户拥有独立 session_id、独立消息历史、独立上下文计数；
• 真本地：所有状态驻留内存，无外部服务，断网可用，数据零外泄；
• 真轻量：无额外 Docker 容器、无复杂配置，pip install streamlit transformers即可启动；
• 真实用：支持长文档上传、上下文智能估算、可视化占用进度，直击 GLM-4-9B-Chat-1M 的核心优势。

这不仅是技术实现，更是一种设计哲学：大模型的价值，不在于参数多少，而在于能否稳稳托住每一个具体的人、每一次具体的提问。

当你把链接发给法务同事审合同、发给开发同事查 Bug、发给产品经理梳需求，他们打开的不是一个共享沙盒，而是一个专属的、可信赖的、永远记得“你是谁”的本地智能伙伴——这才是 GLM-4-9B-Chat-1M 应有的样子。

获取更多AI镜像

想探索更多AI镜像和应用场景？访问 CSDN星图镜像广场，提供丰富的预置镜像，覆盖大模型推理、图像生成、视频生成、模型微调等多个领域，支持一键部署。