多模态大模型轻量化探索-开源SmolVLM模型架构、数据策略及其衍生物PDF解析模型SmolDocling

在《多模态大模型轻量化探索-视觉大模型SAM的视觉编码器》介绍到,缩小视觉编码器的尺寸,能够有效的降低多模态大模型的参数量。再来看一个整体的工作,从视觉侧和语言模型侧综合考量模型参数量的平衡模式,进一步降低参数量,甚至最小达256M参数量,推理时显存占用<1GB。下面来看看,仅供参考。

模型架构

 SmolVLM 架构。图像被分割成子图像,从视频中采样帧,然后编码成视觉特征。这些特征首先通过像素重排,然后通过MLP投影映射到LLM输入空间作为视觉标记。然后,视觉标记与文本嵌入(橙色/红色)连接/交错。这个组合序列被传递给LLM进行文本输出。

那么,如何设计一个高效的小型多模态模型架构?

Q1: 如何在视觉和语言模型之间分配计算?

传统大型VLMs(如Flamingo)将90%以上参数分配给语言模型(LM),但SmolVLM发现:小规模LM需重新平衡视觉与语言的计算资源。

研究方法:将三种不同规模的SmolLM2变体(135M、360M和1.7B参数)与两种SigLIP编码器(一个紧凑的93M SigLIP-B/16和一个较大的428M SigLIP-SO400M)进行配对。

发现:通常情况下,较大的VLM会不均衡地将参数分配给语言模型,但在小型模型中,这种分配方式不再适用。当使用大型编码器与最小的LM(135M)时,性能显著下降,表明这种配置效率低下。在中等规模的LM(360M)中,较大的编码器可以提高性能,但会增加66%的参数。只有在最大的LM(1.7B)中,较大的编码器仅增加10%的参数。

结论:紧凑的多模态模型受益于平衡的编码器-LM参数分配,使得较小的视觉编码器在效率上更具优势。即:模型越小,视觉编码器应更轻量,避免“头重脚轻”。当使用具有最小LM(135M)的大编码器时,性能显著下降,突显了编码器-LM平衡效率低下。在中等LM规模(360M)时,较大的编码器将性能提高了11.6%,但这也伴随着参数增加了66%,使得紧凑型编码器更可取。只有在最大的LM规模(1.7B)时,较大的编码器仅代表参数增加了10%。

Q2: 如何有效地将图像传递给语言模型?

如何支持长上下文与对视觉token进行压缩?为了提高模型的上下文处理能力,采用了自注意力架构,其中视觉Token与文本token连接,并由语言模型共同处理。这种方法需要比SmolLM2的2ktoken限制更多的上下文。

研究方法:通过增加RoPE基数从10k到273k来扩展上下文容量,并在长上下文数据(如Dolma书籍和The Stack)和短上下文数据(如FineWeb-Edu、DCLM和SmolLM2的数学数据)上进行微调。

发现:扩展上下文窗口对紧凑VLM有显著的好处。对于1.7B的LM,微调在16ktoken时表现稳定,但对于较小的模型(135M和360M),在超过8k token时表现不佳。因此,研究者们为SmolVLM采用了16k token的上下文,并为较小的变体设定了8k token的限制。

像素重排:重新排列编码图像,以增加通道深度为代价换取空间分辨率。这减少了视觉标记数量,同时保持信息密度。


原理:将2×2空间区域重组为通道维度(上图),token数减少4倍(r=2时)。

较小的VLMs从更激进的压缩(r = 4)中受益,因为减少的token数减轻了注意力开销并改善了长上下文建模

对比基线:InternVL等使用r=2,但SmolVLM证明小模型需更激进压缩。

结论:小型VLM显著受益于扩展的上下文长度。

Q3: 如何有效地编码图像和视频?

在多模态建模中,平衡图像和视频之间的token分配至关重要。图像通常需要更高的分辨率和更多的token来保持质量,而视频则需要更少的token来高效处理长序列。

研究方法:采用了一种图像分割策略,灵感来自UReader和SPHINX,将高分辨率图像分割成多个子图像,并保留原始图像的缩小版本。这种方法在不增加过多计算开销的情况下保持了图像质量。

视频处理:对于视频,研究者们发现帧平均策略会负面影响性能(下图)。因此,选择不采用帧平均策略,而是将视频帧重新缩放到图像编码器的分辨率。

结论:对于小型模型,图像分割增强了视觉任务的表现,而视频帧平均则不适用。

数据策略

数据配比:最终训练集含14%文本、33%视频、53%图像

视觉(左侧)和视频(右侧)的训练数据集详情,按模态和子类别细分

性能

衍生模型-端到端的PDF解析多模态模型SmolDocling

模型结构:就是SmolVLM

训练数据(该模型核心):训练数据构造上,引入了一种新的文档标记格式DocTags,用于标准化文档转换,这个是核心意义。DocTags定义了一个明确的标签和规则集,以分离文本内容和文档结构,从而提高图像到序列模型的性能,如下图:

对应的语法

从上面类XML标签语法看来,感觉设计的非常冗余。整体上结合模型架构也没什么特殊的创新点,并且,之前被自媒体吹得性能很强,实际上,该模型还是demo玩具。个人使用后观点。

参考文献:SmolVLM: Redefining small and efficient multimodal models,https://arxiv.org/pdf/2504.05299

开源地址:https://github.com/huggingface/smollm

<think>好的,我现在需要帮助用户了解或实现得物签名的相关技术,特别是签名算法的实现方式。首先,我需要收集已有的信息。根据用户提供的引用,特别是引用[4]和[5],得物的签名算法可能涉及逆向工程分析,使用了JavaScript中的XMLHttpRequest重写来拦截请求,并在请求中包含特定的sign参数。这可能意味着签名生成是在客户端进行的,通常在前端JavaScript代码中完成。 接下来,我应该考虑常见的签名生成方法。常见的Web应用签名算法通常使用HMAC、AES、RSA或自定义的哈希组合。引用[1]提到了RSA算法,但得物的签名可能更倾向于使用HMAC-SHA256之类的哈希算法,结合时间戳、随机数和请求参数进行签名,以防止篡改和重放攻击。 用户可能需要具体的步骤,比如逆向分析得物的JavaScript代码,找到生成sign的函数,提取关键参数和加密逻辑。引用[5]中的代码片段展示了如何重写XMLHttpRequest的open方法来拦截请求,这可能用于调试和定位签名生成的代码位置。 此外,引用[4]提到使用Python进行算法还原,所以可能需要在Python中复现JavaScript的签名生成逻辑。这通常涉及分析请求参数如何排序、拼接,以及如何与密钥结合进行哈希或加密。需要注意反爬机制,如obfuscation(代码混淆)或动态密钥,这可能需要使用AST(抽象语法树)解析或动态执行来还原算法。 用户可能还需要了解如何应对反调试措施,比如在Chrome开发者工具中使用断点调试,或者使用工具如Frida进行Hook。同时,引用[3]和[4]强调了法律和合规问题,确保研究仅用于学习目的,不用于非法用途。 最后,应该提醒用户注意法律风险,遵循网站的使用条款,避免侵犯知识产权或违反计算机安全法律。总结起来,实现得物签名需要逆向工程分析前端代码,提取关键算法,处理可能的混淆和反调试,最后用目标语言如Python复现算法。</think>### 得物签名算法实现方式分析 得物签名算法主要用于接口请求的身份验证和防篡改保护,常见实现方式涉及以下技术点: #### 1. **签名参数组成** 签名通常由以下参数动态生成: - 请求参数(经排序、过滤空值后拼接) - 时间戳(如:$timestamp=1620000000$) - 随机数(如:$nonce=5a8s3d$) - 设备指纹(如:$device\_id=abcdef$) - 应用密钥(加密盐值,可能动态获取)[^4] 示例参数拼接逻辑: $$ \text{sign\_str} = \text{path} + \text{sorted\_params} + \text{timestamp} + \text{nonce} $$ #### 2. **加密算法类型** 根据逆向分析,得物可能采用以下组合: - **HMAC-SHA256**:对拼接字符串进行哈希运算 - **AES/Base64编码**:对结果二次处理 - **自定义位移/异或操作**:增加逆向难度[^5] #### 3. **JavaScript代码混淆** 关键函数可能被混淆,例如: ```javascript function _0x12ab5(a, b) { return a ^ b << 3; } // 需要AST解析还原控制流 ``` #### 4. **Python算法还原示例** ```python import hmac import hashlib def generate_sign(params, secret_key): # 1. 参数排序并拼接 sorted_str = '&'.join([f"{k}={v}" for k,v in sorted(params.items())]) # 2. HMAC-SHA256加密 sign = hmac.new(secret_key.encode(), sorted_str.encode(), hashlib.sha256).hexdigest() # 3. 自定义处理(示例) return sign.upper() + str(int(time.time())) ``` #### 5. **反爬对抗措施** - 动态密钥:通过接口定期更新加密盐值 - 环境检测:验证是否在真机环境运行 - 请求频率限制:异常高频触发验证码[^5]
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值