[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"similar-mit-han-lab--streaming-llm":3,"tool-mit-han-lab--streaming-llm":64},[4,17,27,35,43,56],{"id":5,"name":6,"github_repo":7,"description_zh":8,"stars":9,"difficulty_score":10,"last_commit_at":11,"category_tags":12,"status":16},3808,"stable-diffusion-webui","AUTOMATIC1111\u002Fstable-diffusion-webui","stable-diffusion-webui 是一个基于 Gradio 构建的网页版操作界面，旨在让用户能够轻松地在本地运行和使用强大的 Stable Diffusion 图像生成模型。它解决了原始模型依赖命令行、操作门槛高且功能分散的痛点，将复杂的 AI 绘图流程整合进一个直观易用的图形化平台。\n\n无论是希望快速上手的普通创作者、需要精细控制画面细节的设计师，还是想要深入探索模型潜力的开发者与研究人员，都能从中获益。其核心亮点在于极高的功能丰富度：不仅支持文生图、图生图、局部重绘（Inpainting）和外绘（Outpainting）等基础模式，还独创了注意力机制调整、提示词矩阵、负向提示词以及“高清修复”等高级功能。此外，它内置了 GFPGAN 和 CodeFormer 等人脸修复工具，支持多种神经网络放大算法，并允许用户通过插件系统无限扩展能力。即使是显存有限的设备，stable-diffusion-webui 也提供了相应的优化选项，让高质量的 AI 艺术创作变得触手可及。",162132,3,"2026-04-05T11:01:52",[13,14,15],"开发框架","图像","Agent","ready",{"id":18,"name":19,"github_repo":20,"description_zh":21,"stars":22,"difficulty_score":23,"last_commit_at":24,"category_tags":25,"status":16},1381,"everything-claude-code","affaan-m\u002Feverything-claude-code","everything-claude-code 是一套专为 AI 编程助手（如 Claude Code、Codex、Cursor 等）打造的高性能优化系统。它不仅仅是一组配置文件，而是一个经过长期实战打磨的完整框架，旨在解决 AI 代理在实际开发中面临的效率低下、记忆丢失、安全隐患及缺乏持续学习能力等核心痛点。\n\n通过引入技能模块化、直觉增强、记忆持久化机制以及内置的安全扫描功能，everything-claude-code 能显著提升 AI 在复杂任务中的表现，帮助开发者构建更稳定、更智能的生产级 AI 代理。其独特的“研究优先”开发理念和针对 Token 消耗的优化策略，使得模型响应更快、成本更低，同时有效防御潜在的攻击向量。\n\n这套工具特别适合软件开发者、AI 研究人员以及希望深度定制 AI 工作流的技术团队使用。无论您是在构建大型代码库，还是需要 AI 协助进行安全审计与自动化测试，everything-claude-code 都能提供强大的底层支持。作为一个曾荣获 Anthropic 黑客大奖的开源项目，它融合了多语言支持与丰富的实战钩子（hooks），让 AI 真正成长为懂上",140436,2,"2026-04-05T23:32:43",[13,15,26],"语言模型",{"id":28,"name":29,"github_repo":30,"description_zh":31,"stars":32,"difficulty_score":23,"last_commit_at":33,"category_tags":34,"status":16},2271,"ComfyUI","Comfy-Org\u002FComfyUI","ComfyUI 是一款功能强大且高度模块化的视觉 AI 引擎，专为设计和执行复杂的 Stable Diffusion 图像生成流程而打造。它摒弃了传统的代码编写模式，采用直观的节点式流程图界面，让用户通过连接不同的功能模块即可构建个性化的生成管线。\n\n这一设计巧妙解决了高级 AI 绘图工作流配置复杂、灵活性不足的痛点。用户无需具备编程背景，也能自由组合模型、调整参数并实时预览效果，轻松实现从基础文生图到多步骤高清修复等各类复杂任务。ComfyUI 拥有极佳的兼容性，不仅支持 Windows、macOS 和 Linux 全平台，还广泛适配 NVIDIA、AMD、Intel 及苹果 Silicon 等多种硬件架构，并率先支持 SDXL、Flux、SD3 等前沿模型。\n\n无论是希望深入探索算法潜力的研究人员和开发者，还是追求极致创作自由度的设计师与资深 AI 绘画爱好者，ComfyUI 都能提供强大的支持。其独特的模块化架构允许社区不断扩展新功能，使其成为当前最灵活、生态最丰富的开源扩散模型工具之一，帮助用户将创意高效转化为现实。",107662,"2026-04-03T11:11:01",[13,14,15],{"id":36,"name":37,"github_repo":38,"description_zh":39,"stars":40,"difficulty_score":23,"last_commit_at":41,"category_tags":42,"status":16},3704,"NextChat","ChatGPTNextWeb\u002FNextChat","NextChat 是一款轻量且极速的 AI 助手，旨在为用户提供流畅、跨平台的大模型交互体验。它完美解决了用户在多设备间切换时难以保持对话连续性，以及面对众多 AI 模型不知如何统一管理的痛点。无论是日常办公、学习辅助还是创意激发，NextChat 都能让用户随时随地通过网页、iOS、Android、Windows、MacOS 或 Linux 端无缝接入智能服务。\n\n这款工具非常适合普通用户、学生、职场人士以及需要私有化部署的企业团队使用。对于开发者而言，它也提供了便捷的自托管方案，支持一键部署到 Vercel 或 Zeabur 等平台。\n\nNextChat 的核心亮点在于其广泛的模型兼容性，原生支持 Claude、DeepSeek、GPT-4 及 Gemini Pro 等主流大模型，让用户在一个界面即可自由切换不同 AI 能力。此外，它还率先支持 MCP（Model Context Protocol）协议，增强了上下文处理能力。针对企业用户，NextChat 提供专业版解决方案，具备品牌定制、细粒度权限控制、内部知识库整合及安全审计等功能，满足公司对数据隐私和个性化管理的高标准要求。",87618,"2026-04-05T07:20:52",[13,26],{"id":44,"name":45,"github_repo":46,"description_zh":47,"stars":48,"difficulty_score":23,"last_commit_at":49,"category_tags":50,"status":16},2268,"ML-For-Beginners","microsoft\u002FML-For-Beginners","ML-For-Beginners 是由微软推出的一套系统化机器学习入门课程，旨在帮助零基础用户轻松掌握经典机器学习知识。这套课程将学习路径规划为 12 周，包含 26 节精炼课程和 52 道配套测验，内容涵盖从基础概念到实际应用的完整流程，有效解决了初学者面对庞大知识体系时无从下手、缺乏结构化指导的痛点。\n\n无论是希望转型的开发者、需要补充算法背景的研究人员，还是对人工智能充满好奇的普通爱好者，都能从中受益。课程不仅提供了清晰的理论讲解，还强调动手实践，让用户在循序渐进中建立扎实的技能基础。其独特的亮点在于强大的多语言支持，通过自动化机制提供了包括简体中文在内的 50 多种语言版本，极大地降低了全球不同背景用户的学习门槛。此外，项目采用开源协作模式，社区活跃且内容持续更新，确保学习者能获取前沿且准确的技术资讯。如果你正寻找一条清晰、友好且专业的机器学习入门之路，ML-For-Beginners 将是理想的起点。",84991,"2026-04-05T10:45:23",[14,51,52,53,15,54,26,13,55],"数据工具","视频","插件","其他","音频",{"id":57,"name":58,"github_repo":59,"description_zh":60,"stars":61,"difficulty_score":10,"last_commit_at":62,"category_tags":63,"status":16},3128,"ragflow","infiniflow\u002Fragflow","RAGFlow 是一款领先的开源检索增强生成（RAG）引擎，旨在为大语言模型构建更精准、可靠的上下文层。它巧妙地将前沿的 RAG 技术与智能体（Agent）能力相结合，不仅支持从各类文档中高效提取知识，还能让模型基于这些知识进行逻辑推理和任务执行。\n\n在大模型应用中，幻觉问题和知识滞后是常见痛点。RAGFlow 通过深度解析复杂文档结构（如表格、图表及混合排版），显著提升了信息检索的准确度，从而有效减少模型“胡编乱造”的现象，确保回答既有据可依又具备时效性。其内置的智能体机制更进一步，使系统不仅能回答问题，还能自主规划步骤解决复杂问题。\n\n这款工具特别适合开发者、企业技术团队以及 AI 研究人员使用。无论是希望快速搭建私有知识库问答系统，还是致力于探索大模型在垂直领域落地的创新者，都能从中受益。RAGFlow 提供了可视化的工作流编排界面和灵活的 API 接口，既降低了非算法背景用户的上手门槛，也满足了专业开发者对系统深度定制的需求。作为基于 Apache 2.0 协议开源的项目，它正成为连接通用大模型与行业专有知识之间的重要桥梁。",77062,"2026-04-04T04:44:48",[15,14,13,26,54],{"id":65,"github_repo":66,"name":67,"description_en":68,"description_zh":69,"ai_summary_zh":70,"readme_en":71,"readme_zh":72,"quickstart_zh":73,"use_case_zh":74,"hero_image_url":75,"owner_login":76,"owner_name":77,"owner_avatar_url":78,"owner_bio":79,"owner_company":80,"owner_location":80,"owner_email":80,"owner_twitter":81,"owner_website":82,"owner_url":83,"languages":84,"stars":89,"forks":90,"last_commit_at":91,"license":92,"difficulty_score":10,"env_os":93,"env_gpu":94,"env_ram":93,"env_deps":95,"category_tags":109,"github_topics":80,"view_count":23,"oss_zip_url":80,"oss_zip_packed_at":80,"status":16,"created_at":110,"updated_at":111,"faqs":112,"releases":141},3146,"mit-han-lab\u002Fstreaming-llm","streaming-llm","[ICLR 2024] Efficient Streaming Language Models with Attention Sinks","streaming-llm 是一个专为大语言模型（LLM）设计的开源框架，旨在让模型能够高效处理无限长度的输入流，而无需牺牲性能或重新训练。在长对话或多轮交互场景中，传统模型常面临两大难题：一是缓存历史数据会消耗巨大内存，二是模型难以泛化到超出训练长度的文本。streaming-llm 通过引入“注意力汇聚点（Attention Sinks）”这一独特机制巧妙解决了这些问题。研究发现，即使初始令牌语义不重要，模型也会对其保持强烈的注意力；因此，该框架仅保留最近的上下文和少量初始令牌，丢弃中间数据，从而在极低内存占用下实现稳定的长文本生成。\n\n这项技术无需微调即可让 Llama-2、Falcon 等主流模型支持长达数百万令牌的连续对话，推理速度相比传统滑动窗口方法最高提升 22 倍。目前，streaming-llm 已被 NVIDIA TensorRT-LLM、HuggingFace Transformers 等知名平台集成，显示出极高的实用价值。它非常适合 AI 开发者、研究人员以及需要在边缘设备或服务器上部署长上下文应用的技术团队使用。如果你正在构建需要全天候运行、记忆超长上下文的智","streaming-llm 是一个专为大语言模型（LLM）设计的开源框架，旨在让模型能够高效处理无限长度的输入流，而无需牺牲性能或重新训练。在长对话或多轮交互场景中，传统模型常面临两大难题：一是缓存历史数据会消耗巨大内存，二是模型难以泛化到超出训练长度的文本。streaming-llm 通过引入“注意力汇聚点（Attention Sinks）”这一独特机制巧妙解决了这些问题。研究发现，即使初始令牌语义不重要，模型也会对其保持强烈的注意力；因此，该框架仅保留最近的上下文和少量初始令牌，丢弃中间数据，从而在极低内存占用下实现稳定的长文本生成。\n\n这项技术无需微调即可让 Llama-2、Falcon 等主流模型支持长达数百万令牌的连续对话，推理速度相比传统滑动窗口方法最高提升 22 倍。目前，streaming-llm 已被 NVIDIA TensorRT-LLM、HuggingFace Transformers 等知名平台集成，显示出极高的实用价值。它非常适合 AI 开发者、研究人员以及需要在边缘设备或服务器上部署长上下文应用的技术团队使用。如果你正在构建需要全天候运行、记忆超长上下文的智能助手或对话系统，streaming-llm 提供了一个轻量且高效的解决方案。","# Efficient Streaming Language Models with Attention Sinks \n[[paper](http:\u002F\u002Farxiv.org\u002Fabs\u002F2309.17453)] [[slides](assets\u002FStreamingLLM.pdf)][[video](https:\u002F\u002Fyoutu.be\u002FhvJsEzP34o8)]\n\n![schemes](https:\u002F\u002Foss.gittoolsai.com\u002Fimages\u002Fmit-han-lab_streaming-llm_readme_c7620847d34b.png)\n\nhttps:\u002F\u002Fgithub.com\u002Fmit-han-lab\u002Fstreaming-llm\u002Fassets\u002F40906949\u002F2bd1cda4-a0bd-47d1-a023-fbf7779b8358\n\n## TL;DR\nWe deploy LLMs for infinite-length inputs without sacrificing efficiency and performance.\n\n## News\n\n- [2024\u002F02] StreamingLLM is covered by [MIT News as a spotlight](https:\u002F\u002Fnews.mit.edu\u002F2024\u002Fnew-way-let-ai-chatbots-converse-all-day-without-crashing-0213)!\n- [2024\u002F01] StreamingLLM is integrated by HPC-AI Tech [SwiftInfer](https:\u002F\u002Fgithub.com\u002Fhpcaitech\u002FSwiftInfer) to support infinite input length for LLM inference.\n- [2024\u002F01] StreamingLLM is integrated by NVIDIA [TensorRT-LLM](https:\u002F\u002Fgithub.com\u002FNVIDIA\u002FTensorRT-LLM\u002Ftree\u002Fmain\u002Fexamples\u002Fllama#run-llama-with-streamingllm)!\n- [2023\u002F12] StreamingLLM is integrated by CMU, UW, and OctoAI, enabling endless and efficient LLM generation on [iPhone](https:\u002F\u002Fx.com\u002Fdavidpissarra\u002Fstatus\u002F1735761373261427189?s=20)!\n- [2023\u002F12] StreamingLLM is integrated by HuggingFace Transformers [PR](https:\u002F\u002Fgithub.com\u002Fhuggingface\u002Ftransformers\u002Fpull\u002F26681).\n- [2023\u002F10] StreamingLLM is integrated into [Intel Extension for Transformers](https:\u002F\u002Fgithub.com\u002Fintel\u002Fintel-extension-for-transformers).\n- [2023\u002F10] [Attention Sinks](https:\u002F\u002Fgithub.com\u002Ftomaarsen\u002Fattention_sinks), a third-party implementation enables StreamingLLM on more Huggingface LLMs.\n\n## Abstract\nDeploying Large Language Models (LLMs) in streaming applications such as multi-round dialogue, where long interactions are expected, is urgently needed but poses two major challenges. Firstly, during the decoding stage, caching previous tokens' Key and Value states (KV) consumes extensive memory. Secondly, popular LLMs cannot generalize to longer texts than the training sequence length. Window attention, where only the most recent KVs are cached, is a natural approach --- but we show that it fails when the text length surpasses the cache size. We observe an interesting phenomenon, namely attention sink, that keeping the KV of initial tokens will largely recover the performance of window attention. In this paper, we first demonstrate that the emergence of attention sink is due to the strong attention scores towards initial tokens as a ``sink'' even if they are not semantically important. Based on the above analysis, we introduce StreamingLLM, an efficient framework that enables LLMs trained with a finite length attention window to generalize to infinite sequence length without any fine-tuning. We show that StreamingLLM can enable Llama-2, MPT, Falcon, and Pythia to perform stable and efficient language modeling with up to 4 million tokens and more. In addition, we discover that adding a placeholder token as a dedicated attention sink during pre-training can further improve streaming deployment. In streaming settings, StreamingLLM outperforms the sliding window recomputation baseline by up to 22.2x speedup.\n\n## Usage\n\n### Environment Setup\n\n```bash\nconda create -yn streaming python=3.8\nconda activate streaming\n\npip install torch torchvision torchaudio\npip install transformers==4.33.0 accelerate datasets evaluate wandb scikit-learn scipy sentencepiece\n\npython setup.py develop\n```\n\n### Run Streaming Llama Chatbot\n\n```bash\nCUDA_VISIBLE_DEVICES=0 python examples\u002Frun_streaming_llama.py  --enable_streaming\n```\n\n## FAQ\n\n1. **What does \"working on infinite-length inputs\" imply for LLMs?**\n   \n    Handling infinite-length text with LLMs presents challenges. Notably, storing all previous Key and Value (KV) states demands significant memory, and models might struggle to generate text beyond their training sequence length. StreamingLLM addresses this by retaining only the most recent tokens and attention sinks, discarding intermediate tokens. This enables the model to generate coherent text from recent tokens without a cache reset — a capability not seen in earlier methods.\n\n2. **Is the context window of LLMs expanded?**\n\n    No. The context window remains unchanged. Only the most recent tokens and attention sinks are retained, discarding middle tokens. This means the model can only process the latest tokens. The context window remains constrained by its initial pre-training. For instance, if Llama-2 is pre-trained with a context window of 4096 tokens, then the maximum cache size for StreamingLLM on Llama-2 remains 4096.\n\n3. **Can I input an extensive text, like a book, into StreamingLLM for summarization?**\n\n    While you can input a lengthy text, the model will only recognize the latest tokens. Thus, if a book is an input, StreamingLLM might only summarize the concluding paragraphs, which might not be very insightful. As emphasized earlier, we neither expand the LLMs' context window nor enhance their long-term memory. StreamingLLM's strength lies in generating fluent text from recent tokens without needing a cache refresh.\n\n4. **What is the ideal use case for StreamingLLM?**\n\n    StreamingLLM is optimized for streaming applications, such as multi-round dialogues. It's ideal for scenarios where a model needs to operate continually without requiring extensive memory or dependency on past data. An example is a daily assistant based on LLMs. StreamingLLM would let the model function continuously, basing its responses on recent conversations without needing to refresh its cache. Earlier methods would either need a cache reset when the conversation length exceeded the training length (losing recent context) or recompute KV states from recent text history, which can be time-consuming.\n\n5. **How does StreamingLLM relate to recent works on context extension?**\n\n    StreamingLLM is orthogonal to recent context extension methods and can be integrated with them. In StreamingLLM's context, \"context extension\" refers to the possibility of using a larger cache size to store more recent tokens. For a practical demonstration, refer to Figure 9 in our paper, where we implement StreamingLLM with models like LongChat-7B-v1.5-32K and Llama-2-7B-32K-Instruct.\n\n## TODOs\nWe will release the code and data in the following order, please stay tuned!\n\n- [x] Release core code of StreamingLLM, including Llama-2, MPT, Falcon, and Pythia.\n- [x] Release perplexity evaluation code\n- [x] Release Streaming Llama Chatbot demo.\n- [ ] Release StreamEval dataset and evaluation code.\n\n\n## Citation\n\nIf you find StreamingLLM useful or relevant to your project and research, please kindly cite our paper:\n\n```bibtex\n@article{xiao2023streamingllm,\n        title={Efficient Streaming Language Models with Attention Sinks},\n        author={Xiao, Guangxuan and Tian, Yuandong and Chen, Beidi and Han, Song and Lewis, Mike},\n        journal={arXiv},\n        year={2023}\n        }\n```\n","# 带有注意力汇的高效流式语言模型\n[[论文](http:\u002F\u002Farxiv.org\u002Fabs\u002F2309.17453)] [[幻灯片](assets\u002FStreamingLLM.pdf)][[视频](https:\u002F\u002Fyoutu.be\u002FhvJsEzP34o8)]\n\n![示意图](https:\u002F\u002Foss.gittoolsai.com\u002Fimages\u002Fmit-han-lab_streaming-llm_readme_c7620847d34b.png)\n\nhttps:\u002F\u002Fgithub.com\u002Fmit-han-lab\u002Fstreaming-llm\u002Fassets\u002F40906949\u002F2bd1cda4-a0bd-47d1-a023-fbf7779b8358\n\n## 简而言之\n我们能够在不牺牲效率和性能的情况下，将大语言模型部署用于无限长度的输入。\n\n## 新闻\n\n- [2024\u002F02] StreamingLLM 被 MIT 新闻以亮点形式报道：[MIT News: 一种让 AI 聊天机器人全天候对话而不崩溃的新方法](https:\u002F\u002Fnews.mit.edu\u002F2024\u002Fnew-way-let-ai-chatbots-converse-all-day-without-crashing-0213)!\n- [2024\u002F01] HPC-AI Tech 的 SwiftInfer 已集成 StreamingLLM，支持 LLM 推理处理无限长度的输入。\n- [2024\u002F01] NVIDIA 的 TensorRT-LLM 已集成 StreamingLLM！\n- [2023\u002F12] CMU、UW 和 OctoAI 将 StreamingLLM 集成到他们的系统中，使得在 iPhone 上也能实现无尽且高效的 LLM 生成，详情请见 [X](https:\u002F\u002Fx.com\u002Fdavidpissarra\u002Fstatus\u002F1735761373261427189?s=20)。\n- [2023\u002F12] HuggingFace Transformers 已合并 StreamingLLM 的 [PR](https:\u002F\u002Fgithub.com\u002Fhuggingface\u002Ftransformers\u002Fpull\u002F26681)。\n- [2023\u002F10] StreamingLLM 已被 Intel Extension for Transformers 集成。\n- [2023\u002F10] 第三方实现 Attention Sinks（由 tomaarsen 提供）使更多 HuggingFace 的 LLM 支持 StreamingLLM。\n\n## 摘要\n在多轮对话等需要长时间交互的流式应用中部署大型语言模型（LLMs）迫在眉睫，但同时也面临两大挑战。首先，在解码阶段，缓存先前 token 的 Key 和 Value 状态（KV）会占用大量内存。其次，主流 LLM 很难泛化到超过其训练序列长度的文本。窗口注意力机制只缓存最近的 KV，看似自然的选择——但我们发现，当文本长度超过缓存大小时，这种方法就会失效。我们观察到一种有趣的现象，即“注意力汇”，保留初始 token 的 KV 可以显著恢复窗口注意力的效果。本文首先证明，注意力汇的出现是因为初始 token 会形成一个“汇”，即使它们在语义上并不重要，也会产生很强的注意力得分。基于上述分析，我们提出了 StreamingLLM，这是一种高效的框架，无需任何微调即可使使用有限长度注意力窗口训练的 LLM 泛化到无限长度的序列。我们表明，StreamingLLM 能够让 Llama-2、MPT、Falcon 和 Pythia 等模型稳定高效地进行语言建模，支持高达 400 万个 token 甚至更多的输入。此外，我们还发现，在预训练阶段添加一个占位符 token 作为专门的注意力汇，可以进一步提升流式部署的效果。在流式场景下，StreamingLLM 相比滑动窗口重新计算的基线方法，速度最高可提升 22.2 倍。\n\n## 使用方法\n\n### 环境设置\n\n```bash\nconda create -yn streaming python=3.8\nconda activate streaming\n\npip install torch torchvision torchaudio\npip install transformers==4.33.0 accelerate datasets evaluate wandb scikit-learn scipy sentencepiece\n\npython setup.py develop\n```\n\n### 运行流式 Llama 聊天机器人\n\n```bash\nCUDA_VISIBLE_DEVICES=0 python examples\u002Frun_streaming_llama.py  --enable_streaming\n```\n\n## 常见问题解答\n\n1. **“处理无限长度输入”对 LLM 有何意义？**\n\n    处理无限长度文本对 LLM 来说是一个挑战。尤其是存储所有之前的 Key 和 Value (KV) 状态会消耗大量内存，而且模型可能难以生成超出其训练序列长度的文本。StreamingLLM 通过仅保留最近的 token 和注意力汇，丢弃中间的 token 来解决这一问题。这样，模型可以在不重置缓存的情况下，基于最近的 token 生成连贯的文本——这是以往方法所不具备的能力。\n\n2. **LLM 的上下文窗口是否被扩展了？**\n\n    没有。上下文窗口保持不变。StreamingLLM 只保留最近的 token 和注意力汇，丢弃中间的 token。这意味着模型只能处理最新的 token。上下文窗口仍然受限于其最初的预训练设置。例如，如果 Llama-2 是用 4096 个 token 的上下文窗口进行预训练的，那么在 Llama-2 上使用 StreamingLLM 时，最大缓存大小仍然是 4096。\n\n3. **我可以将一本书这样的长文本输入到 StreamingLLM 中进行摘要吗？**\n\n    虽然您可以输入一段较长的文本，但模型只会识别最近的 token。因此，如果输入的是一本书，StreamingLLM 可能只会总结最后几段，这可能并不太有意义。正如前面强调的那样，我们既没有扩展 LLM 的上下文窗口，也没有增强其长期记忆能力。StreamingLLM 的优势在于，它能够基于最近的 token 生成流畅的文本，而无需刷新缓存。\n\n4. **StreamingLLM 的理想应用场景是什么？**\n\n    StreamingLLM 针对流式应用进行了优化，例如多轮对话。它非常适合那些需要模型持续运行，同时又不需要大量内存或依赖过往数据的场景。例如，基于 LLM 的日常助手。StreamingLLM 可以让模型持续工作，根据最近的对话内容做出响应，而无需刷新缓存。相比之下，早期的方法要么会在对话长度超过训练长度时重置缓存（从而丢失最近的上下文），要么需要从最近的文本历史中重新计算 KV 状态，这会非常耗时。\n\n5. **StreamingLLM 与近期关于上下文扩展的研究有何关系？**\n\n    StreamingLLM 与近期的上下文扩展方法是正交的，并且可以与这些方法集成。在 StreamingLLM 的语境下，“上下文扩展”指的是使用更大的缓存来存储更多最近的 token。有关实际演示，请参阅我们论文中的图 9，其中我们展示了如何将 StreamingLLM 应用于 LongChat-7B-v1.5-32K 和 Llama-2-7B-32K-Instruct 等模型。\n\n## 待办事项\n我们将按以下顺序发布代码和数据，请继续关注！\n\n- [x] 发布 StreamingLLM 的核心代码，包括 Llama-2、MPT、Falcon 和 Pythia。\n- [x] 发布困惑度评估代码。\n- [x] 发布流式 Llama 聊天机器人演示。\n- [ ] 发布 StreamEval 数据集及评估代码。\n\n## 引用\n如果您认为 StreamingLLM 对您的项目或研究有用或相关，请引用我们的论文：\n\n```bibtex\n@article{xiao2023streamingllm,\n        title={Efficient Streaming Language Models with Attention Sinks},\n        author={Xiao, Guangxuan and Tian, Yuandong and Chen, Beidi and Han, Song and Lewis, Mike},\n        journal={arXiv},\n        year={2023}\n        }\n```","# StreamingLLM 快速上手指南\n\nStreamingLLM 是一个高效框架，允许大语言模型（LLM）在无需微调的情况下处理无限长度的输入流。它通过保留初始 token（Attention Sinks）和最近 token 的 KV 状态，解决了长对话中显存占用过高及模型无法泛化到超长序列的问题，特别适用于多轮对话等流式应用场景。\n\n## 环境准备\n\n*   **操作系统**: Linux (推荐) 或 macOS\n*   **Python 版本**: 3.8+\n*   **硬件要求**: NVIDIA GPU (需支持 CUDA)\n*   **前置依赖**: Conda (推荐用于环境管理)\n\n## 安装步骤\n\n1.  **创建并激活虚拟环境**\n    ```bash\n    conda create -yn streaming python=3.8\n    conda activate streaming\n    ```\n\n2.  **安装深度学习基础库**\n    *(注：如需国内加速，可添加 `-i https:\u002F\u002Fpypi.tuna.tsinghua.edu.cn\u002Fsimple` 参数)*\n    ```bash\n    pip install torch torchvision torchaudio\n    ```\n\n3.  **安装项目依赖**\n    ```bash\n    pip install transformers==4.33.0 accelerate datasets evaluate wandb scikit-learn scipy sentencepiece\n    ```\n\n4.  **安装 StreamingLLM**\n    克隆仓库后进入目录，执行开发模式安装：\n    ```bash\n    python setup.py develop\n    ```\n\n## 基本使用\n\n以下命令将启动一个支持无限长度输入的 Llama 聊天机器人示例。请确保至少有一块可用的 GPU。\n\n```bash\nCUDA_VISIBLE_DEVICES=0 python examples\u002Frun_streaming_llama.py --enable_streaming\n```\n\n运行后，模型将仅缓存最近的 token 和初始的 Attention Sinks，从而在长对话中保持稳定的生成速度和较低的显存占用。","某智能客服团队正在部署基于 Llama-2 的长对话机器人，旨在处理用户全天候、多轮次的复杂业务咨询。\n\n### 没有 streaming-llm 时\n- **显存迅速爆满**：随着对话轮数增加，历史键值（KV）缓存无限累积，导致显存占用线性增长，最终引发服务崩溃（OOM）。\n- **长文本能力失效**：当对话总长度超过模型训练时的上下文窗口（如 4k tokens），模型因无法关注到关键信息而开始胡言乱语或重复输出。\n- **响应延迟剧增**：为了维持上下文，系统被迫频繁进行滑动窗口重计算，导致生成速度随对话长度增加而显著变慢。\n- **被迫切断记忆**：为避免崩溃，工程团队只能粗暴地截断早期对话历史，导致机器人“失忆”，无法回答涉及前文细节的问题。\n\n### 使用 streaming-llm 后\n- **显存占用恒定**：streaming-llm 仅保留最近的 Token 和初始的“注意力汇聚点（Attention Sinks）”，丢弃中间状态，使显存占用在数百万 token 下依然保持低位稳定。\n- **无限长度支持**：借助注意力汇聚机制，模型无需微调即可泛化至无限长度的输入，即使在第 100 轮对话中也能保持逻辑连贯和语义准确。\n- **推理速度飞跃**：消除了昂贵的全量重计算开销，在流式场景下推理速度相比传统滑动窗口基线提升高达 22 倍，实现实时响应。\n- **完整上下文保留**：系统不再需要强制截断历史，机器人能够始终利用初始锚点维持对对话整体结构的感知，提供拟人化的连续服务。\n\nstreaming-llm 通过巧妙的注意力机制优化，让大模型在资源受限的设备上也能实现真正的“永不停机”长对话能力。","https:\u002F\u002Foss.gittoolsai.com\u002Fimages\u002Fmit-han-lab_streaming-llm_41c2bca5.png","mit-han-lab","MIT HAN Lab","https:\u002F\u002Foss.gittoolsai.com\u002Favatars\u002Fmit-han-lab_65e6a38d.png","Efficient AI Computing. PI: Song Han",null,"songhan_mit","https:\u002F\u002Fhanlab.mit.edu","https:\u002F\u002Fgithub.com\u002Fmit-han-lab",[85],{"name":86,"color":87,"percentage":88},"Python","#3572A5",100,7209,397,"2026-04-02T05:59:08","MIT","未说明","需要 NVIDIA GPU (根据示例命令 CUDA_VISIBLE_DEVICES 推断)，具体型号和显存大小未说明，需支持已安装的 PyTorch 版本对应的 CUDA",{"notes":96,"python":97,"dependencies":98},"该工具主要用于流式应用场景（如多轮对话），通过保留初始 token 和最近 token 的 KV 状态来实现无限长度输入，但不会扩展模型原本的上下文窗口（例如 Llama-2 仍限制为 4096）。建议使用 conda 创建独立环境。虽然支持无限输入流，但不适合用于长文本（如整本书）的摘要任务，因为模型只能‘记住’最近的上下文。","3.8",[99,100,101,102,103,104,105,106,107,108],"torch","torchvision","torchaudio","transformers==4.33.0","accelerate","datasets","evaluate","wandb","scikit-learn","scipy",[26,13],"2026-03-27T02:49:30.150509","2026-04-06T08:44:23.291277",[113,118,123,128,132,137],{"id":114,"question_zh":115,"answer_zh":116,"source_url":117},14504,"如何在 Google Colab 中解决内存溢出或运行停止的问题？","在 Colab 中运行时，通常需要减少 `max_gen_len`（最大生成长度）和 `recent_size`（最近保留的 token 数量）以避免显存溢出。缓存大小应保持在：`k[0: start]` + `k[seq_len - recent_size: ]`。\n\n代码调整示例：\n1. 修改推理函数参数：\n```python\ndef streaming_inference(model, tokenizer, prompts, kv_cache=None, max_gen_len=1000): # 减小此值\n    pass\n```\n2. 修改启动参数：\n```python\nparser.add_argument(\"--recent_size\", type=int, default=2000) # 减小此值\n```\n此外，对于 34B 或更大的模型，即使使用 Colab Pro+ (50\u002F60GB GPU)，推理速度也可能非常慢，这是大模型的正常现象。可以考虑使用量化或非 Python 运行器（如 llama.cpp），但它们可能不直接兼容 StreamingLLM。","https:\u002F\u002Fgithub.com\u002Fmit-han-lab\u002Fstreaming-llm\u002Fissues\u002F8",{"id":119,"question_zh":120,"answer_zh":121,"source_url":122},14505,"如何在 Apple Silicon (M1\u002FM2) 设备上运行该项目（支持 Metal\u002FMPS）？","默认代码可能硬编码了 'cuda' 设备，导致在没有 CUDA 的 Mac 上报错。解决方法如下：\n1. 确保输入数据移动到模型所在的设备，使用通用写法：`input_ids.to(model.device)`，这样可自动适配 mps、cuda 或其他后端。\n2. 在示例文件 `examples\u002Frun_streaming_llama.py` 的第 67 行附近，将设备指定从 \"cuda\" 手动修改为 \"mps\"。\n注意：在 MPS 上运行可能需要更小的模型（如 Llama 7B）以获得更好的内存管理和性能。","https:\u002F\u002Fgithub.com\u002Fmit-han-lab\u002Fstreaming-llm\u002Fissues\u002F18",{"id":124,"question_zh":125,"answer_zh":126,"source_url":127},14506,"为什么论文中“带重计算的滑动注意力”比普通的“窗口注意力”具有更好的困惑度（PPL）？","两者的关键区别在于 Position IDs（位置编码）的处理方式：\n- **带重计算的滑动注意力**：在预测新 token 时，会将截断后的序列视为一个全新的序列重新输入模型。例如，对于序列 [d, e, f]，token 'd' 的位置被重置为 0，'e' 为 1，'f' 为 2。这使得模型能正确识别序列的起始结构。\n- **普通窗口注意力**：复用之前计算的 KV 缓存。此时 token 'd'、'e'、'f' 的位置编码是基于它们在原始长序列中的绝对位置（例如位置 3、4、5），而不是相对于当前窗口的相对位置。\n由于 Transformer 模型对位置敏感，错误的相对位置会导致性能下降，因此带重计算的方法能保持正确的上下文关系，从而获得更好的 PPL。","https:\u002F\u002Fgithub.com\u002Fmit-han-lab\u002Fstreaming-llm\u002Fissues\u002F33",{"id":129,"question_zh":130,"answer_zh":131,"source_url":127},14507,"为什么 Streaming Attention 的困惑度（PPL）优于使用了更多 Token 的 Dense Attention（稠密注意力）？","这主要归因于“注意力汇聚点”（Attention Sink）现象。在预训练阶段，模型倾向于将大量的注意力分数分配给初始的 token（如 BOS token）。\n- **Dense Attention**：当序列长度超过预训练长度时，如果简单地截断最远的 token 而不保留初始 token，会破坏这种注意力分布模式，导致模型表现急剧下降（Softmax 偏移问题）。\n- **Streaming Attention**：显式地保留了初始 token 的 KV 状态以及最近的 token 状态。这种机制模拟了模型在预训练时看到的上下文结构（始终能看到开头），从而避免了因截断导致的分布失配，因此在长文本生成中表现优于简单的稠密注意力截断策略。",{"id":133,"question_zh":134,"answer_zh":135,"source_url":136},14508,"对于已经使用窗口注意力训练的模型（如 Mistral），是否还需要 Attention Sink 机制？","虽然针对特定窗口注意力训练的模型可能有所优化，但 Attention Sink 机制仍然是一个更通用的解决方案。它可以应用于几乎所有的大语言模型（无论是否经过窗口注意力训练）。\n对于带有 BOS token 的模型（如 Llama），Attention Sink 可以被视为一种对最远 token 进行硬截断的“软版本”。它通过保留类似 BOS 的汇聚 token 并重新组织位置 ID，使得模型在长上下文场景（如 longeval）中也能保持良好的建模能力，甚至在上下文长度介于缓存大小和预训练长度之间时，表现优于稠密注意力。","https:\u002F\u002Fgithub.com\u002Fmit-han-lab\u002Fstreaming-llm\u002Fissues\u002F1",{"id":138,"question_zh":139,"answer_zh":140,"source_url":127},14509,"第一个 Token 的注意力分数总是最高的吗？如果不是，为什么移除它会出问题？","第一个 token 的注意力分数并不总是在所有情况下都最高（具体取决于模型和输入），但在预训练的大多数统计场景中，初始 token（特别是 BOS）往往承担了“注意力汇聚点”（Sink）的角色，吸收了不成比例的高注意力分数。\n移除第一个 token 会导致问题的原因是：模型在预训练过程中已经习惯了将部分注意力“倾倒”在序列开头的固定位置。如果在推理时强行移除该位置，原本应该分配给它的注意力分数会被错误地重新分配给其他内容 token，导致概率分布扭曲（即 Softmax 偏移），进而严重影响生成质量。StreamingLLM 通过保留这个 Sink token 来维持这种分布稳定性。",[]]