AGI 这个词在近两年的讨论热度很高但关注点正在从“模型会不会拥有意识”转移到更具体的问题上多模态 AGI 需要多少算力、多少数据以及什么级别的推理基础设施。商业内容通常把这些投入概括为“硅谷又为资本开支找了一个新理由”而从工程师的视角看这个“理由”并不抽象它对应的是多模态模型的显存占用、端到端延迟、模型参数规模、数据管道和推理服务的成本结构。本文会从多模态模型的算力需求和技术栈入手说明为什么近期的投入重心转向了多模态方向并在有限预算条件下给出一个可以实际运行的多模态推理与微调方案再补充成本评估、监控指标和问题排查方法帮助读者在学习和生产场景中都形成一套可复用的判断框架。1. AGI 与“新理由”多模态模型为什么把算力开支推向新高度1.1 从文本聊天到多模态算力需求发生了什么变化文本模型处理的是离散 token。一句话被切分成若干 token 后模型的核心计算量主要由序列长度、模型维度和层数决定。换句话说只要上下文窗口不变文本任务的算力需求相对容易预估。多模态模型的输入空间远不止文本。图像要被切分成固定大小的 patch再经过视觉编码器转换成视觉 token视频则是一连串帧每一帧都要做类似的编码。音频、文档、图表也都要经过各自的编码器进入语言模型主干。这带来两个直接后果单次输入产生的 token 数量显著增加。一张高分辨率图片可能产生数百到上千个视觉 token远高于一段简短文本的 token 数。注意力计算量和 KV cache 占用随 token 数量上升。Transformer 的注意力复杂度是序列长度的二次方因此图像 token 越多预填充阶段的计算量增长越明显。更关键的是多模态并不只是输入侧的变化。文生图、文生视频、语音合成、视频理解这些任务都要求模型在输出侧生成高维信号。输出空间比文本复杂得多计算量也成倍增加。这就是为什么多模态方向会成为新一轮资本开支的重要去向它让模型能处理更接近真实世界的信息形态但同时也把计算资源需求拉到了新的量级。1.2 AGI 没有标准定义但多模态是绕不开的方向AGI即通用人工智能指能够像人类一样在广泛任务中表现出通用问题解决能力的智能体。业界对 AGI 的定义仍有分歧但多模态能力被普遍视为 AGI 的基础能力之一。原因很简单人类的感知和表达方式是多模态的我们通过图像、声音、语言、动作来理解世界并做出反馈。如果模型只能处理文本就无法覆盖真实世界的交互需求。从技术演进路径看多模态模型通常是在大语言模型的基础上扩展视觉、音频等编码能力再通过投影层把不同模态的信息对齐到统一的语义空间。这个设计思路相对清晰但实现起来要处理数据配比、对齐质量、评测方式等复杂问题。更重要的是每一种新模态的加入都会带来新的数据清洗、标注和评测成本这些成本最终同样会转化为资本开支的一部分。因此与其把“为资本开支找新理由”理解成商业话术不如把它看作技术瓶颈的真实表达多模态 AGI 需要更大的模型、更复杂的训练流程、更高质量的数据以及更高吞吐的推理服务而这些都需要系统性投入。1.3 资本开支转化成了什么样的技术基础设施算力投入最终会落到几类具体基础设施上这也是工程师能在日常工作中直接感受到的部分。第一类是训练集群。训练一个多模态模型需要多机多卡并行显卡之间的通信速度直接决定训练效率。高速互联、分布式训练框架、模型并行策略、梯度同步机制这些都属于训练基础设施。第二类是推理基础设施。模型训练完成之后真正面向用户的是推理环节。推理服务需要处理高并发请求要在显存、延迟、吞吐之间做平衡。量化、批处理、KV cache、连续批处理、前缀缓存都是推理侧的关键技术。第三类是数据基础设施。多模态数据的来源更分散格式更复杂清洗难度更高。图片的清晰度、视频的时长、文本与图像的匹配程度都会影响模型效果。数据管道是否自动化决定了一个团队能否快速迭代模型。对中小团队而言虽然不必自建超大规模训练集群但理解这些基础设施组件仍然重要。因为无论使用云资源还是开源框架最终都要面对相同的资源约束和性能瓶颈。理解资本开支背后的技术构成才能知道钱到底花在哪里也知道自己在有限预算下应该先补哪块能力。2. 多模态大模型的技术栈数据、模型和训练推理链路2.1 多模态模型的常见组成以视觉语言模型为例一个典型的多模态模型至少包含四个部分视觉编码器把图像切分为 patch 并编码成视觉特征。输入投影层把视觉特征映射到语言模型的语义空间。语言模型主干负责融合文本 token 和视觉 token并生成输出。输出投影层根据任务类型把隐状态映射为文本、图像或其他信号。视觉编码器对输入图像的尺寸、通道数都有要求。模型通常不会直接把原始图片交给语言模型而是先做 resize、归一化、patch embedding 等操作再生成固定的视觉 token 序列。不同模型对图像分辨率的处理策略不同有些模型会先把图像切成多个子图再把子图 token 拼接进序列这会进一步放大 token 数量。2.2 训练流程预训练、SFT 与对齐多模态模型的训练流程大体分为三个阶段。预训练阶段使用海量图文对、视频文本对等数据目标是让模型学会把不同模态的信息对齐。这个阶段计算量最大需要大量 GPU 和多机多卡并行中小团队一般不会从零开始训练这类模型而是基于开源权重继续做微调。指令微调阶段使用人工标注或模型生成的指令数据教会模型理解用户意图并按要求输出。这个阶段的数据质量比数据量更重要。微调时通常只训练新增的投影层和部分模型层保存显存和计算资源。对齐阶段使用人类反馈或 AI 反馈来调整模型输出偏好常见方法包括 RLHF 和 DPO。多模态对齐比文本对齐更复杂因为人类判断模型输出是否合理时不仅要看文本语义还要看图像细节、指令符合度和事实准确性。这个阶段的评测和反馈收集成本很高。2.3 推理链路为什么多模态推理更耗资源多模态推理可以拆成两个阶段预填充阶段和解码阶段。预填充阶段将输入图像和文本一次性处理生成 KV cache。对于一张图片视觉编码器先把图像转为若干视觉 token这些 token 再进入语言模型与文本 token 一起计算注意力。因为图像 token 数量多预填充阶段的计算量会比纯文本输入大很多。解码阶段逐 token 生成输出。这个阶段的计算瓶颈主要是显存带宽和 KV cache 开销。解码长度越长KV cache 越大显存占用越高。如果输入包含视频视频帧数还会线性放大 KV cache 占用量导致显存迅速逼近上限。理解了这条链路就能理解很多多模态项目的性能问题为什么一张大图比一段长文本还慢为什么显存经常不够用为什么需要量化。推理优化本质上都是在和这些问题打交道。3. 有限预算下落地多模态 AGI从模型选择到最小实现3.1 先想清楚目标场景在选模型之前先明确是学习验证、业务原型还是生产服务。三种场景的方案差异很大。场景推荐路径资源特点学习验证本地单卡 开源小模型只需要一块消费级显卡或适量云 GPU业务原型开源模型 API 混合调用需要验证效果也要关注响应速度生产服务推理服务框架 弹性伸缩需要高并发、监控、告警和回滚能力学习环境追求快速跑通不需要追求最大模型。生产环境则要系统考虑稳定性、成本和可观测性。预算有限时先用开源模型做离线评估确认效果后再决定是继续微调还是接入闭源 API能避免一开始就投入过重。3.2 模型选型与版本确认目前开源社区已经有较多视觉语言模型可选例如 Qwen2-VL、InternVL、LLaVA 等。选型时要关注以下维度显存占用是否支持量化加载官方文档给出的最低配置是多少。语言能力和中文支持中文场景要重点看中文指令跟随能力。输入类型是否支持图像、视频、多图输入。上下文长度长文档或多图场景需要更长上下文。社区活跃度版本更新频率、issue 回复速度、示例代码是否完整。许可协议是否允许商业使用是否对模型权重有额外限制。实际部署前还要确认一组版本关系Python 版本、PyTorch 版本、transformers 版本、CUDA 驱动版本。不同模型对 transformers 的小版本有要求装得太新或太旧都可能报错。建议先按模型仓库的 README 安装依赖再用一个最小样例完整跑通再进入后续开发。注意任何模型仓库里的依赖版本都可能随着迭代变化落地前要以当前发布版本为准不要照抄旧教程里的固定版本号。3.3 准备运行环境下面以 Linux 环境为例准备一个 Python 3.10 的虚拟环境并安装推理所需的基础库。conda create -n mmllm python3.10 -y conda activate mmllm pip install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/cu121 pip install transformers accelerate bitsandbytes peft pillow安装完先确认 GPU 是否可见再确认 PyTorch 是否正确编译了 CUDA 支持。nvidia-smi python -c import torch; print(torch.cuda.is_available()); print(torch.cuda.get_device_name(0))如果torch.cuda.is_available()返回False通常是因为 PyTorch 版本和 CUDA 驱动不匹配需要检查nvidia-smi显示的驱动版本并安装对应 CUDA 版本的 PyTorch。3.4 最小多模态推理示例以视觉语言模型为例加载一个本地目录里的模型权重给定一张图片和一段提示词生成模型回复。from transformers import AutoProcessor, AutoModelForVision2Seq from PIL import Image model_path /data/models/你的多模态模型目录 processor AutoProcessor.from_pretrained(model_path, trust_remote_codeTrue) model AutoModelForVision2Seq.from_pretrained( model_path, trust_remote_codeTrue, torch_dtypeauto, device_mapauto, ) image Image.open(sample.png) messages [ { role: user, content: [ {type: image, image: image}, {type: text, text: 请描述这张图片的内容。}, ], } ] text processor.apply_chat_template(messages, tokenizeFalse, add_generation_promptTrue) inputs processor(text[text], images[image], return_tensorspt) inputs {k: v.to(model.device) for k, v in inputs.items()} outputs model.generate(**inputs, max_new_tokens256) answer processor.batch_decode(outputs, skip_special_tokensTrue) print(answer)这段代码里最关键的是processor而不是tokenizer。多模态模型的 processor 会把图片转换为pixel_values把文本转换为input_ids再统一成模型需要的输入格式。如果只使用文本 tokenizer模型会缺少视觉输入报错非常常见。torch_dtypeauto会优先使用模型支持的浮点精度比如 bf16。device_mapauto会自动把模型分配到可用的 GPU 或 CPU 上。需要注意的是不同模型的 messages 结构可能不同具体字段名要以该模型的 processor 文档为准。3.5 用 LoRA/QLoRA 做低成本微调在有限预算下LoRA 是微调大模型的常用方案。LoRA 的原理是冻结原始模型权重只训练插入在特定模块中的低秩矩阵训练参数量大幅减少。QLoRA 进一步把原始模型权重量化为 4bit在低显存显卡上也能微调较大模型。from peft import LoraConfig, get_peft_model from transformers import AutoModelForVision2Seq model AutoModelForVision2Seq.from_pretrained( /data/models/你的多模态模型目录, torch_dtypeauto, device_mapauto, ) lora_config LoraConfig( r8, lora_alpha16, target_modules[q_proj, k_proj, v_proj, o_proj], lora_dropout0.05, biasnone, task_typeCAUSAL_LM, ) peft_model get_peft_model(model, lora_config) peft_model.print_trainable_parameters()这段配置中r表示低秩矩阵的秩通常取 4 到 32 之间。r越大表达能力越强但训练参数量和显存占用也越高。lora_alpha是缩放系数一般设为r的两倍。target_modules表示要对哪些模块插入 LoRA 层。不同模型内部的模块名可能不同需要在模型配置文件或源码中确认。lora_dropout用于防止过拟合建议调小0.05 是常见取值。微调数据通常整理成 JSON 格式一条数据包含图像路径、用户指令和期望输出。训练时不要把所有视觉编码器都解冻否则显存会迅速膨胀也会破坏预训练阶段学到的视觉特征。3.6 把推理封装成服务实验脚本验证通过后可以先用一个简单的 FastAPI 服务把推理能力暴露出来方便后续做接口联调。import os import time from fastapi import FastAPI, HTTPException from pydantic import BaseModel from transformers import AutoProcessor, AutoModelForVision2Seq from PIL import Image class ChatRequest(BaseModel): image_path: str prompt: str 请描述这张图片 app FastAPI() model_path /data/models/你的多模态模型目录 processor AutoProcessor.from_pretrained(model_path, trust_remote_codeTrue) model AutoModelForVision2Seq.from_pretrained( model_path, trust_remote_codeTrue, torch_dtypeauto, device_mapauto, ) app.post(/vision/chat) def vision_chat(req: ChatRequest): if not os.path.exists(req.image_path): raise HTTPException(status_code404, detailimage not found) image Image.open(req.image_path) messages [ { role: user, content: [ {type: image, image: image}, {type: text, text: req.prompt}, ], } ] text processor.apply_chat_template(messages, tokenizeFalse, add_generation_promptTrue) inputs processor(text[text], images[image], return_tensorspt) inputs {k: v.to(model.device) for k, v in inputs.items()} start time.time() outputs model.generate(**inputs, max_new_tokens256) answer processor.batch_decode(outputs, skip_special_tokensTrue)[0] return {answer: answer, latency: time.time() - start}这个示例只适合原型验证。生产环境还需要补充请求鉴权、限流、超时控制、错误码约定、日志采集和模型预热。直接把模型加载逻辑放在模块顶层也会在多人并发时出现显存竞争问题需要结合推理框架或锁机制进一步设计。4. 从实验到生产成本、性能与可观测性4.1 先算显存再算预算部署多模态模型前先要大致估算显存需求。模型权重的显存占用按参数量计算FP16 精度下大约每个参数 2 字节INT8 约 1 字节INT4 约 0.5 字节。例如一个 7B 模型FP16 权重大约占用 14GB4bit 量化后约 3.5GB。但这只是模型权重本身实际运行还需要额外考虑激活值、KV cache、图像 patch 和推理框架的开销。设计规格时不能只按权重显存来规划。模型规模FP16 权重理论占用4bit 量化权重理论占用实际部署建议7B约 14GB约 3.5GB上下文较长时建议使用量化或选择显存更大的显卡13B约 26GB约 6.5GB单卡 32GB 以下建议量化72B约 144GB约 36GB需要多卡或量化加多卡方案云资源计费通常有按 GPU 小时、按 Token、按请求三种模式。具体单价变化很快但成本结构是相对固定的推理任务主要成本是 GPU 占用时长微调任务主要成本是训练时长和存储。上线前先估算一个请求的平均输入 token 数和输出 token 数再结合吞吐数据反推 GPU 数量这样比凭感觉采购更可靠。4.2 推理性能优化手段多模态推理的性能优化通常围绕显存和延迟展开。量化的收益最直接。把模型从 FP16 降到 INT8 或 INT4可以显著降低显存占用和带宽需求。但量化也会带来一定效果损失业务上要考虑容错程度并做离线效果对比。FlashAttention 可以降低注意力层的显存占用并加速计算很多模型在推理框架中默认开启。批处理能提升 GPU 利用率但 batch size 增大后首个 token 的响应时间可能变长需要按业务要求寻找平衡点。KV cache 是解码阶段的关键优化点。输入图像分辨率越高、上下文越长KV cache 越大。部署时可以根据业务限制图片最大分辨率避免用户传入超高分辨率图片导致显存被瞬间占满。视频场景则要限制帧数采样间隔。对多模态模型而言图像预处理的优化也很重要。图像尺寸、编码器是否启用、子图数量都会影响单次请求的计算量。建议在请求入口处做统一的图像压缩和尺寸限制而不是把所有开销都留给模型层。4.3 监控没有指标就谈不上优化排查性能和成本问题之前先建立监控。最基本的指标可以从nvidia-smi获得。nvidia-smi --query-gpuutilization.gpu,memory.used,temperature.gpu,power.draw --formatcsv生产环境通常结合 Prometheus 和 Grafana 做指标采集和可视化。重点关注以下指标指标含义观察重点GPU 利用率SM 计算单元利用率持续接近 0 说明可能卡在数据加载或 CPU 侧显存占用当前显存使用量接近上限时容易触发 OOM首 token 延迟从请求进入到返回第一个 token 的时间反映预填充阶段和网络开销吞吐每秒处理的请求数或 token 数决定服务容量和成本解码速度每个 token 的平均生成时间反映带宽和 KV cache 效率在代码中加入简单的计时逻辑是定位问题最快的方式。分别统计图像预处理时间、模型生成时间、响应序列化时间哪一段异常就优先排查哪一段。4.4 生产环境还要补齐哪些能力学习环境里只要能跑通脚本就可以生产环境则需要额外补齐一整套工程能力。维度学习环境生产环境模型加载启动时加载一次预热、版本管理、灰度发布配置写死在代码中外置配置中心、环境变量、密钥管理请求控制无鉴权、限流、超时、并发控制日志print 调试结构化日志、request id 串联监控手动查看指标采集、告警规则、可视化面板回滚无模型版本回退、接口兼容策略数据安全忽略图片、文本脱敏访问审计多模态场景的数据更复杂图片和视频可能包含敏感信息。生产环境必须考虑数据脱敏和访问权限不能把用户上传的图片直接存入公共存储桶也不能在日志中打印完整的图片路径和提示词。注意实验时可以用任意本地图片生产环境务必先明确数据合规要求再设计上传、存储和推理流程。5. 常见问题排查多模态项目跑不起来的典型原因5.1 显存不足CUDA OOM现象是运行推理或微调代码时抛出类似CUDA out of memory的异常。常见原因包括上下文过长、图像分辨率过高、模型未量化、batch size 过大、多进程同时加载模型。处理时先用nvidia-smi查看显存占用情况确认是模型权重占用过多还是运行时 KV cache 增长导致。如果权重占用过大改为量化加载如果 KV cache 增长过快缩短上下文窗口或限制图片分辨率如果服务中同时运行多个进程统一收敛为单一常驻进程。5.2 加载模型时报错现象是from_pretrained阶段报 KeyError、AttributeError 或类型错误。常见原因是 transformers 版本过旧不认识新模型的网络结构或者本地缓存里的权重文件不完整或者下载过程被中断。先检查模型仓库指定的 transformers 版本再确认本地权重目录是否完整。重点对比config.json中的model_type与当前加载代码使用的类是否匹配。不要只看代码是否报错要看日志里实际加载的是哪个模型结构。5.3 输入预处理失败现象是调用 processor 之后inputs里缺失pixel_values或者batch_decode输出与预期不一致。常见原因是 messages 结构不符合当前模型要求或者图片无法被 PIL 正常打开或者图片是 RGBA 模式模型只接受 RGB。检查图片路径、图片模式、messages 中 content 的字段名。多模态模型的 processor 对消息格式约束较多最稳妥的方式是打开模型仓库的示例代码逐字段对齐。5.4 推理速度过慢现象是单张图片要几秒才能返回。先确认模型是否真的运行在 GPU 上可以打印model.device。如果输出cpu说明device_map没有生效模型运行在 CPU 上速度当然很慢。接着看是否开启了量化是否使用了 batching。如果是长视频或多图输入还要评估输入 token 总量是否过大。服务化场景里网络传输和图片上传也可能是瓶颈单独压测模型接口时要排除这部分干扰。5.5 排查清单将常见问题整理成一张可复用的检查表遇到问题按顺序排查。问题现象常见原因检查方式处理建议CUDA OOM上下文太长、图片过大、未量化nvidia-smi 查看显存降图片分辨率、缩短上下文、量化、减小 batch加载报错transformers 版本不匹配对比模型仓库 requirements安装指定版本重新加载缺少 pixel_valuesprocessor 未使用或 messages 结构错误打印 inputs 的 key按模型示例调整预处理输出为空生成参数不正确或模板错误去掉 chat template 直接推理检查 prompt 模板和生成终止条件推理很慢模型在 CPU 上或未优化打印 model.device配置 device_map开启量化和 FlashAttention这个表格不是最终答案但它能帮助团队在接手一个新的多模态项目时把排查范围迅速缩小到数据、模型、环境三个方向。6. 工程视角下的“资本开支”怎么判断资源投入方向6.1 资本开支背后是资源稀缺性大模型领域的资本开支之所以被反复讨论本质上是因为算力、数据和电力都是稀缺资源。一家公司愿意持续投入大模型意味着它判断这些资源投入能换来模型能力的提升而模型能力的提升可以最终转化为产品竞争力。工程团队不需要复制这种大规模投入模式但需要理解其中的资源配置逻辑。比如训练一个新模型和租用 API 哪个性价比更高多模态能力究竟是自研、微调还是直接接入现成接口这些问题没有固定答案取决于团队的预算、数据规模、业务场景和迭代速度。做判断前先列出最需要的能力清单再给每项能力估算成本。不要因为某个模型很热门就盲目自研也不要因为采购 API 方便就放弃沉淀自己的数据和评测能力。6.2 按目标分层投入第一层是个人学习和能力验证。这个阶段使用开源模型、单卡、小规模数据就足够目标是把多模态流程跑通理解数据格式和推理链路。第二层是团队技术预研和业务原型。这个阶段可以选择云 GPU 按需租用也可以混合使用开源模型和闭源 API。重点是建立评测集和基准数据明确“效果不好”具体指哪些维度。第三层是生产服务。这个阶段才适合投入推理框架、监控告警、模型版本管理和自动化评测。不要在生产环境直接复用学习脚本也不要让模型服务在没有日志和告警的情况下长期运行。6.3 算力之外工程化能力才是长期竞争力多模态 AGI 的竞争并不只是堆显卡数量的竞争。两组团队使用相同的开源模型最终拉开差距的往往是谁的数据清洗更规范、谁的评测集更能反映真实业务、谁的监控和回滚机制更完善以及谁能更快把模型迭代到线上。这也是理解“资本开支”话题对工程师最有价值的部分。大模型方向的资本开支确实庞大但落到日常工作中工程师能真正发挥作用的地方在于提高资源利用率、降低无效推理开销、建立可靠的数据管道和量化模型效果。把每一分算力用在明确的目标上比单纯讨论投入规模更有意义。