本周 Reddit LocalLLaMA 板块一个不起眼的帖子，让我们注意到一个正在改变 AI 落地成本的趋势：一位开发者想让 27B 大模型的任务分一半给 0.8B 小模型——具体来说，是让小模型负责压缩对话历史、腾出 context 窗口（模型一次能读进去的文字量），再把摘要喂给大模型推理。
这是什么
所谓 session compression（会话压缩），就是把多轮对话的历史记录压成简短摘要，腾出 context 窗口给新内容。传统做法是直接用同一个大模型顺手压缩，但 27B 这种规模每跑一次都要烧 GPU 时间。
这个帖子的核心思路是「按工种配模型」：脏活累活（压缩、分类、提取）交给 0.8B 小模型，单次推理成本能压到大模型的百分之一；正经推理才轮到 70B（700 亿参数规模）大模型出手。千问 0.8B 这种尺寸的小模型，本就是为边缘设备设计的，跑这类结构化任务反而比大模型更稳定。
这不是学术突破，而是一种工程优化思路——就像公司不会让总监去贴发票。
行业怎么看
支持者认为这才是 AI 落地的正确姿势。Anthropic、阿里、字节内部早就在按任务分层调度模型，几家做 Agent（能自主执行多步任务的 AI）的公司甚至专门训练小模型做中间环节。一句话：与其把所有鸡蛋放进一个超大模型，不如把对的活交给对的尺寸。
反对意见同样值得听。0.8B 模型压缩对话很可能丢失关键细节——比如用户三句话前说过的「别给我推股票」，可能被压成「用户偏好保守」，大模型端是补不回来的。多走一道工序还引入额外延迟，对实时对话是硬伤。更现实的顾虑是供应商锁定（vendor lock-in）：如果一家公司所有模型都来自千问，未来想换 DeepSeek 或 Llama，迁移成本会很高。
我们倾向后者。短期看分层调度确实省钱，长期看模型能力还在快速爬升，单一大模型可能又会吃掉小模型的活——RAG（让模型查外部知识库）和 fine-tuning（微调）这两个技术就经历过类似的循环。
对普通人的影响
对企业 IT：采购 AI 不再是「买一个最强大模型」那么简单，未来账单上会出现「压缩模型 + 推理模型 + 审核模型」几条线，按 token（模型处理的文字单位）分别计费。
对个人职场：用 AI 工具时如果发现它「忘了你说过什么」，很可能不是模型变笨，而是中间的压缩环节丢了细节——遇到重要对话可以主动把关键信息再贴一遍。
对消费市场：AI 产品定价会进一步分化。简单问答走小模型、单价压到几分钱，复杂推理依然按大模型收钱。普通用户会越来越难判断「我这次对话到底花了多少钱」。