在4GB笔记本GPU（RTX 3050 Ti）上的本地智能体工作空间：tok/s 以及小型模型在调用工具、构建制品和RAG时遇到的困难

聊天内交互式/可预览的制品 声明：我在Bike4Mind（基于BUSL-1.1的可获取源码的AI工作空间，可通过Docker自行托管）工作。运行它无需购买任何东西。我主要在自己的普通笔记本上使用本地Qwen。4GB显卡运行本地聊天模型并不新鲜，但我真正想探索的是，一个完整的智能体工作空间（能够调用工具、对你自己的文档进行RAG、生成制品、处理视觉等）在4GB显存下能做什么，以及当模型需要执行比聊天更复杂的任务时，小型模型会在哪里跟不上。仓库见第一条评论。 我的机器：i7-12700H, 32GB RAM, RTX 3050 Ti笔记本（4GB VRAM, 60W）, Ubuntu 24.04。使用栈内捆绑的Ollama运行本地Qwen，无需云端密钥。 速度数据，在触及4GB限制的情况下（Ollama /api/generate, Q4_K_M除Q8_0 0.8b外, num_ctx=4096, 预热, 取3次中位数, 一次只加载一个模型）： - qwen3.5:0.8b - 122 tok/s, 约1.4GB, 全部在GPU上 - qwen3.5:2b-q4_K_M - 96 tok/s, 约2.4GB, 全部在GPU上 - qwen3.5:4b - 25 tok/s, 约3.4GB, 约三分之一溢出到CPU - qwen3.5:9b - 8.6 tok/s, 大部分在CPU上, 需要约8GB 对我而言，2B是目前的最佳选择：它适配4GB并剩余约1.3GB空间，速度超过我之前使用的qwen2.5-coder:3b（72 tok/s），同时更新且多模态。超过它就会触及显存墙——4B的权重约3.4GB，即使num_ctx=2048也无法完全容纳，因此约三分之一落在CPU上。普通的qwen3.5:2b是Q8_0版本（约2.7GB），在4GB下会溢出，但qwen3.5:2b-q4_K_M可以容纳。这样剩余约1.3GB，所以旁边放不下第二个模型。 模型选择器显示各种自托管模型（如果你配置了云提供商密钥，他们的所有模型也会显示出来） 显而易见的功能——聊天、原生工具调用、视觉——在2B上都能正常工作；qwen3.5是多模态的且原生支持工具调用，这很好。我最兴奋的顶层功能是对自己文档的RAG，全程无需密钥：丢入一个文件，工作进程进行分块并使用本地Ollama嵌入器嵌入，查询返回带引用的答案，整个流程中没有任何云端嵌入API。在4GB下，嵌入器和聊天模型需要交换位置。qwen3-embedding:0.6b占用约1.2GB，2B模型占用约2.4GB，它们无法同时驻留，因此Ollama会卸载一个以便加载另一个。生成时仍可获得完整的96 tok/s，因为2B模型在VRAM中时嵌入器不在——你付出的代价是模型加载，而不是更慢的token速度。数据摄取在后台工作进程中运行，因此一个文档文件夹只需加载一次嵌入器，然后处理大量分块，不占用聊天路径。查询时嵌入一个短字符串，然后2B模型重新加载回答它。所以每次RAG交互需要重新加载一次，而不是每个token或每个分块。如果你不想付出这个代价，nomic-embed-text大约0.25GB（768维，据称检索能力较弱），因此不需要把2B模型换出，或者将嵌入放在CPU上，把GPU留给生成。无论哪种方式，在加载整个知识库/数据湖之前，选择一个嵌入器并固定使用（或者意识到所有向量需要重新嵌入），因为向量不会跨模型转移。 除了RAG中的聊天-嵌入器交换问题，小型模型在其他方面也让我失望： - 制品。通用qwen3.5模型在这些大小下会写出不完整的HTML——未闭合的标签、脚本泄漏到页面上。对于实际的交互式制品，我必须切换到编码调优的qwen2.5-coder，它能写出完整可工作的页面。所以这是按任务分配模型：qwen3.5用于聊天/视觉/工具，编码模型用于代码，在笔记本内切换。我猜这在4GB下基本就是常态！ - 工具选择。启用很多工具后，小型模型会误路由——在启用所有工具的情况下，我的7b模型曾经把“创建一个HTML制品...”发送给图像生成器，结果生成了一张用户界面图像，哈哈。所以另一个显然的结论是，本地小型模型必须启用更少的工具。这让我想要一个智能的中间层，能自动为你启用当前上下文中最可能相关的少数（可配置N个？）工具。 - 图像生成是本地化的（自托管SD.Next），但每张图片需要1-3分钟，且会溢出到CPU，还会与聊天模型争夺VRAM。所以仍然是启动后等待的情况，这里没有真正好的解决方法，只能下载更多的VRAM 🙃 那么，相比于单独使用Ollama加聊天UI，这值得吗？只有在顶层的智能体层对你有价值时才值得——例如工具处理、制品、本地RAG，以及针对你自己的服务器的CLI。如果你只想要快速的本地聊天，我建议保持现状；使用llama.cpp等开销更小的方案。 关于许可证：简要说明——基于BUSL-1.1提供源码，并非完全开源（目前）。你可以自行托管、投入生产、分叉、构建并销售产品；只是不能直接将其作为竞争的托管服务转售。每个版本在两年后转为Apache-2.0（这个计时器是为了防止AWS像对MongoDB那样立即对我们下手）。仓库和自托管详情见第一条评论。 对我来说，这个设置中真正的摩擦是需要两个模型——qwen3.5用于聊天、视觉和工具，以及一个编码模型处理任何与代码相关的事务，因为通用模型在这些大小下会写出有问题的HTML/制品——这并非新问题。为此，我仍在努力优化这一设置，所以想请教各位更资深的本地构建专家（人类）： - 你们是否找到过一个能工作在4GB显存上的通用模型，可以写出完整有效的制品，而无需专门的编码模型辅助？或者有更好的配置方法？请告诉我！ - 我很好奇其他人的聊天+代码+图像+嵌入等一次性设置，所以如果你们找到了良好的模型组合（像是俄罗斯方块拼图），或者看到了哪些权衡并接受了自托管所有这些功能，请分享。