企业官网建设流程全解析

上周在同事的工位上看到一个挺反常识的演示：一台没有独立显卡的小盒子，接着一个麦克风和一个普通摄像头，对着它说话它能应答，拿张图给它看它能描述内容，全程离线、断网。跑在里面的模型参数量是0.1B 量级——也就是一亿参数这个档位。而业界主流的多模态旗舰动辄上千亿参数，中间差着三到四个数量级，所以圈子里才有了"比千亿级多模态旗舰小一千倍，却能听说看"的这个说法。这个"0.1B 全模态模型"到底是怎么做到的，是营销口径上的花活，还是工程上真的有一套可行路径，这正是我准备在这篇里彻底掰开讲清楚的东西。这篇适合三类人看：想在自己设备上跑多模态的算法工程师、被"小模型能不能顶用"这个问题困扰的产品同学，以及想搞明白多模态模型内部到底在干什么的技术爱好者。我不打算讲空话，会把参数量口径、token 压缩、训练配比、显存账、延迟预算连着一套可复现的管线一起摊开，最后把我们实际踩过的坑列成一张排查表。

1. 先把"小一千倍"这句话拆开看

1.1 参数量口径：千倍差距是怎么算出来的

一亿参数对一千亿参数，正好是千分之一，所以"小千倍"这个说法在数学上站得住。但我必须先泼一盆冷水：这个对比里的两个数字，往往不是同一种口径统计出来的。千亿级闭源多模态产品的参数规模是"整体系统"的规模，包含了语言主干、视觉编码器、音频前端、语音合成模块；而 0.1B 这个数字，通常只统计了参与梯度更新的那个语言主干加上连接器，视觉编码器和声码器这些"外挂件"要么另算，要么干脆不在宣传口径里。

这个差别有多大？我举个例子。一个 100M 的模型，如果配一个 20M 的视觉编码器、一个 15M 的音频前端、再加一个 30M 的轻量声码器，实际部署包体是 165M 参数，还是同一个数量级，但和"0.1B"这个漂亮数字之间已经有 65% 的落差。所以看到任何"超小参数"的宣传，第一件事应该是问：这个数是不是把 tokenizer、编码器、解码器都排除在外了？这不是苛责，这是从业者必须建立的审数直觉。

真正值得关注的，不是那个具体数字，而是在同样的参数量预算下，为什么以前做不出来，现在能做了。这才是工程秘密的所在。

1.2 "全模态"里的"全"，门槛到底卡在哪

模态这个词被用滥了。严格来说，输入侧支持文本、图像、音频、视频，输出侧支持文本和语音，这才勉强够得上"全"。而每加一个模态，成本不是线性的，是叠乘的：编码器要单独训，隐空间要和文本对齐，数据配比要重新调，推理时序列长度会暴涨，显存占用跟着涨。

最容易低估的是序列长度这一项。一张 448x448 的图，如果按 14x14 的 patch 切，就是 1024 个视觉 token；一秒钟 16kHz 的音频，如果按 10ms 帧移做特征，就是 100 帧，就算每帧压成 1 个 token，那也是每秒 100 个。一段 30 秒的语音加上一张图，token 总数轻松破三千，而一个小模型的有效上下文窗口本来就只有两千到四千。多模态在小模型上最尖锐的矛盾，从来不是"参数不够学"，而是"序列装不下"。

所以那些真正把 0.1B 跑通的方案，核心功夫几乎都花在同一件事上：把每个模态的 token 数量压到极致。这一点后面会单独展开。

1.3 小模型不等于大模型的压缩包

我见过不少团队的思路是：拿个大模型，蒸馏、剪枝、量化，压到 0.1B。这条路我试过，结论很直接——能力会断崖式掉，尤其是跨模态的那部分。原因是多模态能力属于"涌现型"能力，它依赖主干在足够多数据上形成的语义空间，而这个空间本身是有容量下限的。你把主干压到一亿参数，它连单模态的语言流畅度都得精打细算，哪还有余量去装视觉和听觉的映射关系。

反过来，"从零设计一个 0.1B 的全模态架构"这条路反而更现实。因为你可以从一开始就按"小"来规划：主干宽度定小一点、层数定浅一点、模态编码器选最轻的、token 压缩率定得激进一点，所有取舍围绕"一亿参数怎么花"来做，而不是事后砍。这就像盖房子，一亿预算的方案和一千亿预算的方案砍到一亿，结构合理性完全是两回事。

2. 0.1B 全模态的四个核心工程取舍

2.1 模态编码器"够用就好"，绝不追求大

视觉编码器是多模态系统里最容易被堆料的地方。业界的习惯做法是挂一个 ViT-L，三亿参数起步，光编码器就比整个 0.1B 预算大三倍。小模型方案必须反着来：编码器的作用是把像素变成"能被语言主干理解的语义片段"，不是做精细的视觉理解。

实操里我推荐两条路。第一条是极轻量 ViT，宽度 192、深度 6、patch 16、8 个注意力头，参数量大概 5M 到 8M，输入 224x224 就够。第二条更省，用卷积主干做特征提取再过一个两层 Transformer，参数量能压到 3M 以内，代价是细粒度识别稍弱。

关键判断标准只有一个：这个编码器输出给主干的特征，主干能不能用起来。判断方法是冻结主干，只训连接器，看图文检索的召回能不能在几千步内爬到可用水平。如果爬不动，说明编码器给的特征太抽象或者太稠密，换掉比加大更有效。

注意：编码器不是越小越好。宽度低于 128 的 ViT 在中文场景里的文字识别基本失效，如果你的应用涉及读图里的字，这一块不能省，宁可把主干的层数砍两层。

2.2 token 压缩：第一刀必须砍在序列长度上

这一节是我认为整篇文章最值钱的部分。0.1B 能跑全模态，七成功劳在 token 压缩。

视觉侧常用三种压缩手法，我按性价比排序。第一种是patch 合并（pixel shuffle 式），把相邻 2x2 的 patch 特征在通道维拼接再降维，token 数直接除以 4，代价很小、实现极简，10 行代码搞定。第二种是重采样器（resampler），用一组可学习的查询向量去交叉注意力抽取信息，把任意数量的视觉 token 压到固定 64 个或 32 个，好处是序列长度恒定、显存可预测，坏处是细节丢失明显，OCR 类任务会崩。第三种是动态分辨率 + 分块，只在需要细节时才增加 token。

音频侧的压缩更暴力也更有效。原始波形 16kHz 直接进 Transformer 是不现实的，标准流程是先算 80 维 mel 特征，帧移 10ms，得到 100 帧每秒。然后接两到三层步长为 2 的一维卷积，把帧率降到 12.5Hz 到 25Hz。一段 10 秒的语音，从 1000 帧压到 125 到 250 个 token，这才是能塞进小模型上下文的量级。

我把这几组数字整理成表，方便你直接对照：

提示：压缩比不是越大越好。我实测过把图像压到 16 个 token，模型能说出"这是一张餐桌照片"，但完全说不对桌上有什么。压缩比应该由你的下游任务决定，别一上来就照着论文里的极限值抄。

2.3 共享隐空间：一个主干吃三种输入，别搞多塔

多模态架构有两条经典路线：多塔各自编码后再融合，或者所有模态映射进同一个隐空间交给一个主干。小模型只能选后者，没有第二个选项。

原因很实际。多塔方案的融合层通常很大，而且每个模态都要维护自己的位置编码、自己的层归一化统计量，参数开销成倍增长。共享隐空间方案里，视觉 token 和音频 token 经过投影层之后，和文本 token 长得一模一样，主干完全不需要知道自己吃的是什么。这让主干可以复用同一套注意力参数，参数量省下来的同时，跨模态迁移也更顺。

具体到实现，投影层就是个小 MLP：两层线性，中间加 GELU 和 LayerNorm，隐层维度取主干的 2 到 4 倍，输出维度必须严格等于主干的 d_model。整个投影层参数量在 1M 到 3M 之间，极其便宜。

这里有个容易翻车的细节：位置编码怎么处理。文本用 RoPE，图像是二维的，音频是一维连续的。我的做法是统一用一维 RoPE，图像按行优先展平后顺序编号，音频按时间顺序编号，中间插一个特殊的分隔符 token 让模型自己学边界。这样不用引入额外的位置编码类型，参数零增加，实测效果不差。

2.4 分阶段训练：三个阶段，三种学习率

架构定了之后，训练策略决定了模型能不能真的学会。直接端到端训是最省事也最容易失败的做法，小模型尤其经不起这么折腾。我采用的是标准三阶段：

阶段一，连接器预热。冻结编码器和主干，只训投影层。学习率给到 1e-3，batch 尽量大，跑三到五千步。这一阶段的目标很单纯：让投影层的输出分布和文本 embedding 的分布对齐。判断收敛的信号是图文匹配的对比损失开始下降。

阶段二，联合预训练。解冻主干，编码器保持冻结或者给极小的学习率。主干学习率 2e-4，投影层 5e-4，cosine 衰减，warmup 占总步数 3%。这一阶段占了总训练算力的大部分，数据量要足够大。

阶段三，混合模态指令微调。全部参数解冻，学习率降到 5e-5，数据换成高质量的多模态对话对。这一阶段步数不多，主要目的是让模型学会"说话的方式"，而不是学新知识。

三个阶段的学习率差了一个数量级以上，这个梯度是必要的。阶段一学太快会把主干带偏，阶段三学太猛会把预训练的东西冲掉，我见过学习率没调好导致模型只会复读的案例，回头查就是阶段二学习率给到了 1e-3。

3. 参数与显存：把账算在纸面上

3.1 一亿参数怎么分配

不同方案的分法差异很大，但有一个大原则：主干拿七成，编码器拿两成，连接件拿一成。下面这套分法是我实测下来比较平衡的：

加起来 100M。可以看到主干只有 512 维、16 层，这在纯文本模型里属于偏小的规格，但在多模态场景里完全够用，因为多模态任务对"知识储备"的要求其实低于对"跨模态对齐"的要求。

我特别想强调一点：预训练阶段的声码器不参与训练，只在推理时挂上去。这意味着训练时你根本不需要为语音输出付出参数和算力成本，语音输出走的是"离散音频 token + 独立声码器"的路线。这也是 0.1B 这个数字能成立的重要原因之一。

3.2 训练和推理的资源估算

显存这块的账很多文章不讲，我直接给公式。

训练时每参数的开销：fp32 主权重 4 字节，Adam 一阶二阶动量各 4 字节，梯度 4 字节，合计 16 字节。一亿参数就是 1.6GB，这部分是硬开销，省不掉。激活值部分按 batch × 序列长度 × d_model × 层数估算，再乘以每层的中间张量倍数（经验值 8 到 12）。

我按 batch 8、序列 1024 算一遍：8 × 1024 × 512 × 16 = 6.7e7 个元素，乘以中间倍数 10 得到 6.7e8，fp16 存储就是 1.34GB，再算上注意力矩阵（序列长度平方乘 batch 乘头数），大概 0.3GB。总量 1.6 + 1.34 + 0.3 ≈ 3.3GB，实际训练时因为碎片和临时缓冲，峰值大概在 5GB 左右。一张 16GB 的消费级卡能舒服地跑，8GB 卡靠梯度累积也能跑，这就是小模型的好处。

推理侧的账更简单。fp16 权重 200MB，int8 量化后 100MB，int4 量化后 50MB。加上视觉编码器、声码器和运行时开销，实际部署包体 150MB 到 300MB 之间。KV cache 按每 token 2 × 层数 × d_model × 2 字节算，2 × 16 × 512 × 2 = 32KB 每 token，2000 token 的上下文就是 64MB。这个数字很关键，它意味着一台 4GB 内存的设备可以同时跑好几路推理。

3.3 延迟预算：能不能算"实时"

"能听说看"这个说法里隐含了一个性能承诺：交互得是实时的。我按流水线拆一下毫秒数：

算一下首字延迟：音频特征 8ms 加视觉 35ms 加 prefill 120ms，大约 160ms，加上调度开销算 250ms。这个数字在语音交互里是可接受的，人能明显感觉到"想了一下"，但不影响对话流畅度。语音输出的吞吐是 12.5 token 每秒（每个 token 对应 80ms 音频），生成速度基本能跟上播放速度，不会卡顿。

如果要更激进，有两条路：把主干的 attention 换成 GQA，KV cache 直接砍掉一半；或者把声码器改成更小的分块流式版本，延迟能压到 20ms 级。

4. 动手搭一套最小可跑的管线

4.1 目录结构与依赖准备

我不打算讲太细的安装步骤，这一块大家各有各的习惯。目录结构建议这样组织，把模态相关的代码彻底隔离，后面换编码器的时候改动面最小：

tiny-omni/ ├── configs/ │ ├── stage1_align.yaml │ ├── stage2_pretrain.yaml │ └── stage3_sft.yaml ├── models/ │ ├── backbone.py # 语言主干 │ ├── vision_tower.py # 视觉编码器 │ ├── audio_tower.py # 音频前端 │ └── projector.py # 投影层 ├── data/ │ ├── processors/ # 各模态预处理 │ └── collators.py # 多模态 batch 组装 └── train.py

环境上，torch 2.x 加 transformers 主干加载、torchaudio 做音频特征、pillow 或 opencv 处理图像，基本就够了。不建议引入太重的多模态训练框架，因为 0.1B 的规模用不上分布式和流水线并行，自己写个训练循环反而更透明、更好调。

4.2 视觉分支与压缩投影的关键实现

视觉这块的核心是压缩投影，我把关键逻辑写出来。注意pixel_shuffle那一步是省 token 的关键，把 2x2 邻域的特征在通道维拼起来再降维，token 数直接除以 4：

import torch import torch.nn as nn class VisionProjector(nn.Module): def __init__(self, vis_dim=384, hidden=1024, d_model=512, merge=2): super().__init__() self.merge = merge merged = vis_dim * (merge ** 2) self.proj = nn.Sequential( nn.Linear(merged, hidden), nn.GELU(), nn.LayerNorm(hidden), nn.Linear(hidden, d_model), ) self.norm = nn.LayerNorm(d_model) def forward(self, feats): # feats: (B, H*W, C) b, n, c = feats.shape h = w = int(n ** 0.5) x = feats.view(b, h, w, c).permute(0, 3, 1, 2) # B,C,H,W x = nn.functional.pixel_shuffle(x, self.merge) # B,C*4,H/2,W/2 x = x.flatten(2).transpose(1, 2) # B,N/4,C*4 return self.norm(self.proj(x))

这段代码有个细节值得说：LayerNorm 放在线性层之间而不是最后。我对比过两种放法，放在中间的版本在冻结主干训练时收敛快大概 30%，原因是它的输出分布更接近预训练好的文本 embedding 分布，而这一侧主干本来就统计好了均值方差，分布不匹配的话主干的 attention 会打得非常散。这是个很难从论文里看出来的经验点。

4.3 音频前端与降帧策略

音频前端分两段，第一段是特征提取，第二段是降帧。降帧用卷积做，比用平均池化效果好很多，因为卷积能学到哪些帧信息密度高，可以自适应地保留：

class AudioTower(nn.Module): def __init__(self, n_mels=80, d_model=512, stride=8): super().__init__() self.conv = nn.Sequential( nn.Conv1d(n_mels, 256, 3, stride=2, padding=1), nn.GELU(), nn.Conv1d(256, 384, 3, stride=2, padding=1), nn.GELU(), nn.Conv1d(384, d_model, 3, stride=stride // 4, padding=1), nn.GELU(), ) layer = nn.TransformerEncoderLayer(d_model, 8, 2048, batch_first=True, norm_first=True) self.enc = nn.TransformerEncoder(layer, num_layers=4) def forward(self, mel): # mel: (B, T, 80) x = self.conv(mel.transpose(1, 2)).transpose(1, 2) return self.enc(x)

三次卷积下来，100Hz 的帧率变成 12.5Hz，压了 8 倍。这里stride的分配我用的是 2、2、2，实际还可以改成 2、2、1 加上尾部池化，差别不大。千万别一步到位用 stride 8，那样每个卷积核要跨 8 帧，时间分辨率损失太严重，语音里的辅音信息会糊掉，实测字错误率会上升 5 到 8 个百分点。

后面接的 4 层 Transformer 是可选的。如果你的音频任务只是"听懂说什么"，两层就够；如果要做情感识别之类的细粒度任务，加到 6 层收益明显。

4.4 训练循环与损失权重

损失这块我用的是组合损失：主线交叉熵，加一个跨模态对比损失做辅助对齐，音频侧再加一个小的 CTC 辅助。权重分配很关键：

对比损失的权重不能给大。我一开始给到 0.5，结果模型学会了"图文匹配得很好，但回答问题时总是跑偏"，因为对比任务把隐空间拉得太紧，主干的生成能力被压住了。降到 0.1 之后恢复正常。这类辅助损失在小模型上尤其要克制的根本原因是：辅助任务会占用主干本来就不宽裕的参数容量。

训练循环本身没什么花活，但有两个点必须做对。一是梯度裁剪，阈值设 1.0，小模型对梯度尖峰特别敏感，不裁剪的话跑几千步就会遇到一次 loss 暴涨。二是多模态 batch 的采样策略，别按样本数对齐，要按 token 数对齐。文本样本短、音频样本长，按样本数凑 batch 会导致不同 batch 之间的实际计算量差三倍，学习率曲线会有明显抖动。

4.5 推理封装与量化落地

推理这块，我把量化前后的体积和精度实测数据放出来，这个对不同硬件的选型帮助比较直接：

推荐默认走 int4 分组量化，组大小 128。这个配置下精度损失只有 2% 到 3%，但体积减到四分之一。有个坑：视觉投影层和音频投影层不要量化，它们的参数量小但数值范围窄，量化后对齐能力下降明显，实测图文匹配召回能掉 6 个点。只量化主干，投影层保持 fp16，这个混合策略我是吃过亏才定下来的。

流式推理的封装上，把 prefill 和 decode 分开做，prefill 一次处理完所有输入模态的 token，decode 阶段用 KV cache 逐 token 出。语音输出这块按块合成，每 4 到 8 个音频 token 送一次声码器，能保证边生成边播放。

5. 踩过的坑和一份排查手册

5.1 六个高频问题及定位思路

小模型的多模态训练失败起来很有迷惑性，表面症状和真实原因经常对不上。我把实际遇到的六个问题整理成速查表：

这里我想单独展开"语音识别完全无效"这一条，因为它最容易被误判。很多人第一反应是音频编码器太小，拼命加大参数量，其实问题往往出在时间分辨率上。语音里区分辅音靠的是几十毫秒级的短时特征，帧率一旦降到 12.5Hz 以下，也就是每帧 80ms，辅音信息就被平均掉了。判断方法很简单：打印降帧后每帧对应的原始时间跨度，超过 60ms 就该警惕。

5.2 一些不太好写进文档的经验

有几个经验，在正式文档里基本看不到，但在实操中能省几天时间。

第一，先把单模态跑通再上多模态。我见过太多团队一上来就三模态一起训，loss 曲线看着正常，实际每个模态都没学好。正确的顺序是先确认纯文本能力可用，再接视觉、只训投影层、验证图文检索召回，最后才加音频。每加一个模态，都要能回答"这个模态单独的效果是什么水平"。

第二，数据配比按 token 算不按样本算。文本、图文、音频三条数据流，按样本数 1:1:1 混合是最常见也最糟糕的做法，因为一条音频样本可能顶十条文本样本的 token 数。我用的比例是按 token 计文本占 60%、图文 30%、音频 10%，这样训出来的模型文本能力不掉，多模态能力也稳。音频占比不宜超过 15%，过了的话文本生成质量会明显下滑。

第三，验证集要分模态建。只建一个综合验证集，你根本看不出是哪一块坏了。我建了四个：纯文本困惑度、图文检索召回、语音字错率、多模态对话人工打分。哪块掉了，回头翻训练日志就能定位到对应的数据配比或者学习率。

第四，别急着上长上下文。小模型的注意力参数本来就少，序列拉长之后注意力权重会被稀释，短序列上的表现反而下降。我一般先用 1024 的序列训完阶段二，阶段三再扩到 2048，配合位置编码缩放。一上来就 4096 训练，前期收敛会明显变慢。

第五，参数量不是唯一指标，训练 token 数才是。一个 100M 的模型在 200 亿 token 上训过，效果远超 300M 但在 50 亿 token 上训过的。小模型的性能天花板很大程度由数据量决定，而不是参数。搞不定效果的时候，先问数据够不够，而不是先问要不要加参数。

最后分享一个小技巧：调试多模态模型时，把每个模态的输入 token 和对应的注意力图打印出来看看，比盯 loss 曲线有效得多。我遇到过视觉 token 全被 attention 忽略的情况，loss 看着在降，其实模型只用了文本上下文在硬猜——这种问题不把注意力图摊开看，永远发现不了。