在Qwen3-1.7B模型上，用1.7倍压缩率应用SemanticFold后，压缩分支的负对数似然（NLL）比原生分支低了0.135——这是arXiv那篇序列压缩论文里最反常识的结果，一般压缩模型都是牺牲性能换体积，这次反而能把某一项指标拉得比原生更好。
这不是普通压缩，是“语义折叠”
SemanticFold不是简单删文本或剪层，核心是“折叠”前缀的隐藏状态——在模型自己学到的边界上合并冗余部分，而非粗暴丢弃。论文用了固定目标协议：冻结前缀，压缩前后跑一模一样的续接token，排除了“换目标选不同token”的干扰，确保结果是压缩本身带来的变化。
论文测了五个主流模型：Qwen3的1.7B、8B，SmolLM2的1.7B，Pythia的1.4B和6.9B，覆盖开源大模型多个系列，不算小众测试。
不同能力，压缩阈值真的不通用
论文考察了五大核心能力：语言建模的NLL、有限标签推理的准确率、线性探针的特征可访问性、开放生成表现、系统级内存和延迟。结论是：这些能力对压缩的响应完全独立，没有统一压缩阈值能同时兼顾。
举几个具体数：Qwen3-1.7B在1.7倍压缩率下，NLL降了0.135；SmolLM2在1.2倍压缩率下，NLL反而比原生高0.013；Pythia的两个模型，NLL几乎没变化。线性探针的准确率和AUC变化都不到0.03的绝对值，置信区间跨过零，说明这个变化统计不显著，等于没动。
还有个细节：论文把NLL变化拆成“单纯缩短序列”和“压缩带来的残差变换”，发现Qwen的NLL变好主要来自后者——单纯缩短序列结果反而变差，加上边界学习到的残差调整，才拉低了NLL。
给大模型压缩踩了“一刀切”的坑
现在行业做模型压缩，不管蒸馏、量化还是剪枝，大多是一套方案套所有场景，比如“所有模型压到1/3体积，延迟降一半”。但这篇论文说的是：语言建模、可解码性、推理能力，这三大核心，对压缩的要求完全分开。
比如做代码推理任务，得单独找对应推理准确率的压缩阈值，不能和聊天生成用同一个；Pythia的模型对压缩鲁棒性强，压了也不怎么掉NLL，Qwen的模型就很吃压缩策略，乱压反而会让NLL变差。
那问题来了——现在很多To B的大模型服务，都是一套压缩方案打天下，以后是不是得给每个场景做定制化的压缩包？比如推理任务和生成任务，压缩逻辑完全分开？
素材来源：arXiv (LLM/多模态新论文) · AI情报、大模型、科研前沿
查看报道原文
发表第一条评论吧