LFM2.5-VL-3B 是一个面向边缘设备的视觉语言模型Vision-Language Model, VLM目标是在算力、内存和功耗都受限的边缘硬件上让模型既能看懂图片又能生成自然语言描述或回答问题。与云端大模型不同边缘部署必须在模型规模、推理速度、量化精度和硬件适配之间反复权衡任何一个环节没对齐都会出现显存爆炸、延迟超标或输出质量明显下降的问题。本文站在部署工程师视角以 LFM2.5-VL-3B 这类 3B 规模视觉语言模型为例从理解模型定位、准备运行环境、跑通最小推理、量化压缩、服务化部署到质量验证和故障排查整理出一条可以复现的落地路径。文章中的所有代码和命令都面向实际工程读者可以按顺序执行并对照检查。1. 先把边缘视觉语言模型的部署约束说清楚1.1 视觉语言模型到底在解决什么问题视觉语言模型是一类能同时理解图像和文本的多模态模型。它的输入通常是一张图片加一句自然语言指令输出是一段自然语言文本。例如输入“这张图片里有什么”和一张街景照片模型会给出“图中有一个穿红色外套的人在街道上行走手里拿着手机”这样的回答。从结构上看VLM 通常由三部分组成视觉编码器Vision Encoder负责把图像转换成视觉特征投影层Projector负责把视觉特征映射到文本语义空间文本解码器Text Decoder负责按自回归方式生成回答。相比纯文本大语言模型VLM 多了一个视觉输入通道因此部署时既要考虑文本解码器的计算开销也要考虑视觉编码器带来的额外显存和延迟。LFM2.5-VL-3B 的价值在于它把这三个模块压缩到约 30 亿参数规模使得模型可以在嵌入式 GPU、轻量级推理盒子甚至部分集成算力设备上运行。对于需要本地处理图片、离线回答问题和保护数据隐私的场景这种小型 VLM 比直接调用云端大模型更可控。1.2 边缘设备和云端服务器的本质差异很多人把模型部署理解为“把模型加载起来、调用一下”但边缘部署和云端部署完全是两套思路。云端有充足的电力和散热条件可以用多卡并行、大批量推理来摊薄成本边缘设备通常只有一个受限的加速器内存有限而且不能假设网络稳定。维度云端服务器边缘设备算力GPU 集群多卡并行单卡 GPU、集成显卡或 NPU内存几十到几百 GB8 GB 到 16 GB 常见功耗无严格限制通常限制在 5 W 到 100 W网络高带宽、低抖动弱网甚至完全离线延迟要求秒级可接受百毫秒到秒级按业务定运维方式专业团队值守现场设备远程维护困难这些差异决定了边缘部署的优先级显存占用要控制推理延迟要稳定模型权重要尽可能小同时还要保证输出质量不严重退化。LFM2.5-VL-3B 这类 3B 模型正是为了满足这些约束而设计。1.3 为什么 3B 参数是边缘部署的“甜点区”参数规模直接影响两个指标显存占用和推理速度。以 FP16 精度为例1B 参数模型权重约占 2 GB3B 参数约占 6 GB7B 参数约占 14 GB。如果再加上视觉编码器、中间激活值和 KV Cache7B 模型在普通 16 GB 内存设备上的余量非常小而 1B 模型虽然跑得动但多模态理解和指令跟随能力往往不足。3B 处于一个相对平衡的位置FP16 下总占用约 7 到 8 GB配合量化可以压到 3 GB 以内在 CPU 上可以用 INT4 跑通在 8 GB 显存 GPU 上可以比较从容地做低延迟推理。因此当项目标题强调 Edge 场景时3B 规模是一个很现实的工程选择。注意不要只看“3B”这个数字视觉编码器和图像分辨率会显著改变实际资源占用。同一个 3B 模型输入 448x448 和输入 1024x1024 图片的显存与延迟差异可能达到数倍。2. 从 LFM2.5-VL-3B 的命名看技术定位2.1 版本号、规模和后缀分别说明什么LFM2.5-VL-3B 这个名称可以拆成三层信息。LFM 是模型系列名表示它属于同一技术家族后续版本会在同一套架构和训练范式上迭代。2.5 是版本号说明这是 2.x 系列中的一次迭代通常意味着在数据质量、指令跟随或多模态能力上有改进。VL 表示 Vision-Language即视觉语言模型。3B 表示模型参数量约为 30 亿。理解这些信息对部署很关键版本号决定了你应当使用哪一版权重和配置文件VL 决定了推理时你需要同时准备图像处理器和文本分词器3B 决定了内存估算和量化方案的选择。如果在部署时拿到的模型仓库与这些信息对不上就要先确认是否加载了错误的权重。2.2 “Better and Faster” 在工程上通常指哪些改进项目标题强调 Better 和 Faster。从同类模型的迭代规律看Better 通常体现在三个方面更准确地理解指令、更稳定地描述图像内容、更少出现幻觉对象Faster 则体现在推理延迟更低、显存占用更小或吞吐更高。落到工程层面这些改进往往对应具体技术调整更高效的注意力机制、更紧凑的视觉编码器、优化的投影层设计以及更好的量化友好性。量化友好性对边缘部署尤其重要因为同一模型在 INT4 下的质量损失会直接决定它能否被业务接受。需要说明的是不同版本的模型卡片会给出不同的精确指标。落地前应当以官方模型卡和权重仓库中给出的数据为准不要根据标题中的 Better and Faster 直接推断性能也不要把它理解为在所有任务上都优于更大规模的模型。2.3 适合用它的场景和不适合它的场景任何模型都有适用边界。小型 VLM 的优势是低延迟、低资源、可离线部署短板是复杂推理能力和知识广度有限。适合的场景工业场景中的图片内容辅助描述与简单质检。智能终端上的本地相册问答不上传图片以保护隐私。边缘盒子上的实时画面属性提取比如人物、物体、场景类别。弱网或离线环境下的图文检索辅助。需要快速给出短文本描述的轻量应用。不适合的场景数百页文档的细粒度 OCR 和信息抽取。需要复杂多步推理的数学或逻辑问题。依赖大规模实时知识更新的开放问答。对输出格式要求极度严格、且模型卡未明确保证的任务。部署前先想清楚任务边界能避免在模型能力不够时反复调参却毫无进展。3. 部署前的环境准备3.1 硬件选型算力、内存和带宽的平衡边缘部署的第一步是确定目标硬件这会决定后面的量化方案和性能基线。建议按三个档位评估。配置档位内存要求推理方式适用场景最低配8 GB RAM无独立 GPUCPU 推理INT4 量化功能验证、低并发离线任务标准配16 GB RAM8 GB 显存 GPUGPU 推理INT4/INT8单路低延迟、实时交互高配32 GB RAM16 GB 显存 GPUGPU 推理FP16/INT8多路并发、较高吞吐选硬件时还要关注内存带宽。视觉语言模型的视觉编码器会处理大量图像 token内存带宽低会直接拖慢推理。同样是 CPU 推理双通道内存和单通道内存的延迟差异明显。不要只看 CPU 核数和频率内存通道数和功耗上限同样重要。3.2 Python 环境、CUDA 与推理框架版本推荐先创建一个独立虚拟环境避免和系统 Python 或其它项目相互污染。以下命令基于 Linux 环境Windows 下需要把激活命令改为.venv\Scripts\activate。python -m venv .venv source .venv/bin/activate pip install --upgrade pip pip install torch torchvision --index-url https://download.pytorch.org/whl/cu121 pip install transformers accelerate bitsandbytes pillow requests安装完成后用一组命令检查关键环境是否正常python -c import torch; print(torch.__version__, torch.version.cuda, torch.cuda.is_available()) nvidia-smi free -h检查结果要满足三点PyTorch 版本能识别当前 GPUCUDA 驱动版本不低于 PyTorch 编译要求的版本系统可用内存比估算的模型占用至少多出 20%。如果 GPU 不可用不要直接往下走先把 CPU 推理跑通再处理加速问题。3.3 模型权重和配置的核对清单很多部署失败不是因为代码写错而是加载了不完整的权重目录。下载模型前先核对以下内容config.json 是否存在里面的模型结构和预期规模一致。处理器配置比如 preprocessor_config.json 或 tokenizer 相关文件是否齐全。权重文件格式是 safetensors 还是 pytorch_model.bin。是否有自定义代码文件如果有加载时需要 trust_remote_code。模型卡的许可证和适用版本说明。如果项目材料没有给出明确的权重仓库地址不要猜测一个 Hugging Face 路径。正确做法是从模型官方发布的页面获取地址或者把本地权重目录放到固定路径后读取。这个检查看起来很基础却能省下后面一整轮的排查时间。4. 最小推理闭环先让模型回答一张图片4.1 加载模型和处理器先写一个最小脚本目标是让模型能对单张图片生成一段文本。加载模型时这里使用 Transformers 的 AutoProcessor 和 AutoModelForVision2Seq 风格接口这也是当前多数视觉语言模型采用的标准接口。实际运行时需要把 model_id 替换成真实权重路径或仓库 ID。import torch from transformers import AutoProcessor, AutoModelForVision2Seq model_id your-org/lfm2.5-vl-3b processor AutoProcessor.from_pretrained(model_id, trust_remote_codeTrue) model AutoModelForVision2Seq.from_pretrained( model_id, torch_dtypetorch.bfloat16, device_mapauto, trust_remote_codeTrue, ) model.eval()这里有两个关键点。第一torch_dtype 选择 bfloat16 还是 float16取决于 GPU 是否支持 bf16。老显卡对 bf16 支持不好此时应该改用 float16否则可能出现数值异常。第二trust_remote_codeTrue 仅在模型仓库包含自定义代码时使用。如果模型无需自定义代码建议关闭该选项因为运行远程自定义代码本身存在安全风险。4.2 准备输入图像与提示词视觉语言模型的输入不只是图片还包括一条提示词。同一个模型提示词写得不清楚输出质量会差很多。这里用一条简单但明确的指令作为示例。from PIL import Image image Image.open(demo.jpg).convert(RGB) prompt 请描述这张图片的内容并说明图中最重要的物体。 messages [ { role: user, content: [ {type: image, image: image}, {type: text, text: prompt}, ], }, ] inputs processor.apply_chat_template( messages, add_generation_promptTrue, return_tensorspt, ).to(model.device).convert(RGB)这一步很关键。很多相机图片或截图带有 Alpha 通道或 EXIF 旋转信息如果不统一转换为 RGB模型的视觉输入会出现异常表现为描述内容张冠李戴。apply_chat_template 会按模型定义的对话模板把图像和文本拼成统一的输入张量不需要手工拼接 IMAGE token。4.3 执行推理并解析输出加载完模型、构造好输入后使用 generate 生成文本。with torch.no_grad(): output_ids model.generate( **inputs, max_new_tokens256, do_sampleFalse, num_beams1, pad_token_idprocessor.tokenizer.pad_token_id, ) answer processor.batch_decode( output_ids[:, inputs[input_ids].shape[1]:], skip_special_tokensTrue, )[0] print(answer)output_ids[:, inputs[input_ids].shape[1]:]的作用是只保留新生成的 token去掉输入部分避免把提示词也打印出来。decode 时设置skip_special_tokensTrue可以去掉image、|im_end|这类特殊标记。正常输出示例图片中有一个穿红色外套的人站在街道上手里拿着手机。图中最重要的物体是手机。如果输出为空优先检查 input_ids 的截取位置是否正确以及 max_new_tokens 是否被设成了 0 或过小。跑通这一步就等于验证了权重、处理器、模型接口和硬件环境整条链路是通的。5. 从跑通到跑得快量化与推理引擎优化5.1 量化方式、精度与效果取舍最小推理跑通后下一步是压低资源占用。量化是边缘部署最常用的手段。不要一开始就上 INT4应该先确认当前硬件和目标延迟是否真的需要量化。方案显存估算3B 模型推理速度质量影响推荐场景FP16/BF16约 6 GB基准基准GPU 显存充足、质量优先INT8仅权重约 3.2 GB略快轻微稳定的生产默认选择INT4NF4约 2 GB快视任务下降8 GB 内存边缘设备INT4AWQ/GPTQ约 2 GB快比 NF4 更稳定对质量要求较高的 INT4 场景使用 bitsandbytes 加载 INT4 模型的代码from transformers import AutoModelForVision2Seq, BitsAndBytesConfig quant_config BitsAndBytesConfig( load_in_4bitTrue, bnb_4bit_quant_typenf4, bnb_4bit_compute_dtypetorch.bfloat16, bnb_4bit_use_double_quantTrue, ) model AutoModelForVision2Seq.from_pretrained( model_id, quantization_configquant_config, device_mapauto, trust_remote_codeTrue, )注意bitsandbytes 是加载时量化适合快速验证。如果模型要部署到多种设备建议提前用 AWQ 或 GPTQ 做离线量化生成量化后的权重文件避免每次启动都重复量化。5.2 不同推理引擎的适用场景量化只是降低权重体积推理引擎决定算子在不同硬件上的执行效率。不同引擎适合不同场景引擎优势限制适用场景transformers accelerate接口通用、迭代快算子优化有限原型验证、功能开发ONNX Runtime / OpenVINOCPU 优化好可部署到更多硬件需要导出和转换CPU 边缘设备、VPU/NPUllama.cpp 系列运行时显存占用低CPU 友好对 VLM 架构支持要看版本低内存设备、ARM 设备vLLM高吞吐、支持并发批处理显存需求高、部署重GPU 服务器端多路服务如果项目材料没有明确说明 LFM2.5-VL-3B 的架构是否兼容某个引擎先看该引擎支持的模型架构列表再决定是否转换。不要为了追求速度强行上 vLLM3B 模型单路低延迟场景用原生 Transformers 往往更省事。5.3 性能瓶颈定位视觉编码器、文本解码器和采样优化性能前先搞清楚时间花在哪一步。简单的方法是在 generate 前后打点import time start time.perf_counter() output_ids model.generate(**inputs, max_new_tokens128, do_sampleFalse) elapsed time.perf_counter() - start print(fgenerate 总耗时: {elapsed:.3f}s)典型的性能规律是视觉编码器处理图片的耗时基本固定文本解码器随着输出 token 数线性增长。如果 max_new_tokens 从 64 调到 256 后耗时翻倍说明瓶颈在解码阶段如果输出长度变化不大时耗时依然很高说明视觉编码器或图像预处理占了主要时间。对应优化手段也不同。解码瓶颈可以降低输出长度、改用更快的采样方式或升级推理引擎视觉瓶颈可以降低输入图像分辨率但要注意这通常会降低细粒度描述质量需要结合业务场景权衡。6. 部署到实际边缘设备服务化与资源控制6.1 最小推理服务的实现思路模型验证通过后需要把推理逻辑封装成服务让上层应用通过 HTTP 接口调用。这里使用 FastAPI 提供最简服务。核心原则是模型和处理器在进程启动时加载一次请求处理函数只做输入解析、推理和输出序列化。import io import time import torch from fastapi import FastAPI, UploadFile, File, Form from PIL import Image app FastAPI() # 假设 model 和 processor 已在模块加载时初始化 # model ... # processor ... app.post(/v1/generate) async def generate( file: UploadFile File(...), prompt: str Form(请描述这张图片。), max_new_tokens: int Form(128), ): raw await file.read() image Image.open(io.BytesIO(raw)).convert(RGB) messages [ { role: user, content: [ {type: image, image: image}, {type: text, text: prompt}, ], } ] inputs processor.apply_chat_template( messages, add_generation_promptTrue, return_tensorspt, ).to(model.device) start time.perf_counter() with torch.no_grad(): output_ids model.generate( **inputs, max_new_tokensmax_new_tokens, do_sampleFalse, ) latency time.perf_counter() - start answer processor.batch_decode( output_ids[:, inputs[input_ids].shape[1]:], skip_special_tokensTrue, )[0] return { answer: answer, latency_ms: round(latency * 1000, 2), model: lfm2.5-vl-3b, }启动命令uvicorn main:app --host 0.0.0.0 --port 8000这里要注意不要在请求函数内部加载模型否则每个请求都会重新读取权重延迟会从百毫秒级变成分钟级。模型加载放在模块导入阶段完成并使用全局变量引用。6.2 内存、显存与线程数控制边缘设备上推理进程不能无限制使用资源。CPU 场景先设置线程数import torch torch.set_num_threads(4)也可以在启动服务前设置环境变量export OMP_NUM_THREADS4 export MKL_NUM_THREADS4GPU 场景可以把模型的一部分层放到 CPU避免显存溢出model AutoModelForVision2Seq.from_pretrained( model_id, device_mapauto, max_memory{0: 6GiB, cpu: 12GiB}, )max_memory的作用是告诉加载器GPU 最多用 6 GiBCPU 内存最多用 12 GiB。超出部分会自动分配到对应设备。设置过小会导致部分层落到 CPU推理会变慢设置过大会触发 OOM。推荐先测一次满载显存再留 20% 余量。6.3 延迟、并发与缓冲设计边缘设备通常不需要很高的并发但需要稳定的延迟。设计时注意几点不要把模型放进多线程栈模型推理在 PyTorch 下有 GIL 和 CUDA 上下文限制多线程并发请求可能互相阻塞对单个边缘设备使用单进程同步推理即可由 FastAPI 的事件循环接收请求推理过程在独立的线程池中执行。如果一台设备需要同时服务多路视频流更稳妥的方式是每路视频一个独立推理进程进程内串行处理进程间通过消息队列分发任务。并发上来的第一反应不应该是加线程而是评估单路延迟是否满足要求再决定是否有必要做批处理。注意不要在每个请求里修改模型权重或量化配置。量化、加载、设备映射都应当只在启动阶段完成运行阶段只做 forward 和 generate。7. 验证模型质量与性能7.1 功能正确性验证的维度部署完成不等于功能正确。质量验证至少要覆盖四个维度图像内容描述是否与图片一致简单文字识别是否准确指令是否被正确遵循比如要求只说一句话时不要输出长段内容是否出现图片中不存在的对象幻觉。建议准备一张固定的测试图片集合包含室内、室外、人物、文字、静物等类型并记录每张图片在不同提示词下的输出。这样既能验证代码逻辑也能在后续更换量化方案或升级模型版本时快速回归。python test_inference.py --image images/demo1.jpg --prompt 描述图片7.2 吞吐与延迟基准的测量方法性能测试要有明确指标不能只靠感觉。最基本的三个指标单次请求从收到图片到返回文本的端到端延迟生成阶段每秒产生的 token 数进程稳定运行时占用的显存和内存。基准测试脚本可以这样写import time import statistics from PIL import Image def benchmark(image_path, prompt, model, processor, repeat10): latencies [] for _ in range(repeat): image Image.open(image_path).convert(RGB) messages [ { role: user, content: [ {type: image, image: image}, {type: text, text: prompt}, ], } ] inputs processor.apply_chat_template( messages, add_generation_promptTrue, return_tensorspt, ).to(model.device) start time.perf_counter() with torch.no_grad(): output_ids model.generate( **inputs, max_new_tokens128, do_sampleFalse, ) latencies.append(time.perf_counter() - start) avg_ms statistics.mean(latencies) * 1000 print(f平均延迟: {avg_ms:.1f}ms)测试时注意两点第一遍调用要做 warmup因为模型首次推理会触发 CUDA kernel 初始化和缓存分配统计时去掉第一轮或前两轮结果才有代表性。延迟记录 P50、P95 和 P99不要只报告平均值。7.3 多模态输出的质量抽检方案质量抽检要持续做尤其是换量化方案后。推荐做法是固定 20 到 50 张覆盖不同难度的图片编写统一评估脚本每次部署前跑一遍把输出保存到文本文件人工抽检关键样本。抽检时重点看两类问题一是对象幻觉模型描述了图片里不存在的人或物体二是指令漂移模型没有按要求的格式答复。出现这类问题先不要急着调采样参数而要对比 FP16 基线输出确认问题是量化带来的还是模型本身能力边界。8. 常见问题排查8.1 OOM 或加载失败现象脚本执行到模型加载或推理时报 CUDA out of memory。常见原因包括 FP16 权重加视觉编码器超出了显存、max_memory 配置不合理、输入图像分辨率过高。检查方式nvidia-smi查看 GPU 显存占用。解决思路改用 INT4 加载降低图像输入尺寸把 max_new_tokens 调小使用 max_memory 把部分层放到 CPU。预防措施在模型加载后显式打印当前显存占用记录基线值。如果报错是AttributeError或模块找不到常见原因是 transformers 版本过低或模型使用自定义代码但没有开启 trust_remote_code。先把 transformers 升级到模型卡片要求的版本再检查仓库是否包含自定义 modeling 文件。8.2 输出为空、重复或格式混乱输出为空的常见原因max_new_tokens 过小生成在输出前就被截断input_ids 截取位置错误把提示词部分当成了回答处理器在保存输入时丢失了图像 token。输出重复的常见原因解码采用贪心但在低精度量化下模型输出倾向重复。可以在 generate 中增加参数output_ids model.generate( **inputs, max_new_tokens256, do_sampleTrue, temperature0.7, top_p0.9, repetition_penalty1.1, )输出格式混乱时先用skip_special_tokensFalse打印原始 token 序列看看是否出现了未被裁剪的特殊标记。这能快速判断是模板拼接问题还是 decode 参数问题。8.3 图片理解明显错误现象模型给出的描述与图片内容完全无关。优先检查输入图片是否被统一转换为 RGB是否被过度压缩导致关键细节丢失是否带 EXIF 旋转信息。再检查提示词如果提示词写得模糊比如只写“这是什么”模型可能给出泛泛回答。还有一种情况是处理器在 apply_chat_template 时没有把 image 放进正确位置导致模型实际上没有看到图片只基于文本先验回答。验证方法换一张特征完全不同的图片如果输出几乎不变说明视觉输入链路有问题。8.4 量化后效果退化严重现象FP16 输出正常INT4 输出出现对象错误或描述混乱。处理顺序先确认量化配置比如 NF4 是否搭配了 bf16 计算精度再对比不同量化位宽INT8 和 INT4 在相同测试集上的差异最后考虑使用 AWQ 或 GPTQ 替代加载时量化。问题现象常见原因检查方式处理建议OOM权重精度过高、显存不足nvidia-smi 查看显存改用 INT4调低图像分辨率输出为空截取位置错、max_new_tokens 过小打印 output_ids 形状核对截取索引调大长度重复输出低精度下采样参数不合适对比 FP16 输出增加 repetition_penalty图片理解错误未转 RGB、模板丢 image token换图测试是否输出变化检查预处理链路量化后退化量化位宽或方式不匹配同图对比 FP16/INT8/INT4换 AWQ/GPTQ或退回 INT89. 最佳实践与下一步扩展9.1 边缘部署可复用检查清单部署 LFM2.5-VL-3B 这类模型前按下面这份清单逐项确认可以避免大多数常见问题阶段检查项模型文件权重、config、tokenizer、许可证全部齐全环境torch/CUDA 版本匹配GPU 可用内存充足推理单张图能输出结果与图片内容一致量化INT4 输出与 FP16 在固定测试集上对比过服务启动后先 warmup再对外提供请求日志记录请求来源、图片尺寸、耗时、输出长度监控显存、内存、失败率、延迟 P95 有可视化回滚保留上一个可用权重和代码版本9.2 生产环境需要的额外保障模型能在测试环境跑通和生产环境稳定运行之间还差很多工程保障。生产环境至少要补齐四件事日志结构化每次推理记录输入来源、耗时、输出 token 数和耗时指标请求校验限制图片大小和格式避免超大图片拖垮内存异常处理推理失败时返回可读错误码而不是让进程崩溃模型版本管理同一个服务接口绑定固定模型版本升级时做到可回滚。另外要考虑多模态输入的安全问题。图片内容可能包含恶意提示词试图诱导模型输出不符合业务约束的内容。实际问题需要在应用层做输入过滤和输出审核不要指望模型自己拒绝所有风险请求。9.3 从单机推理走向多设备管理单台边缘设备验证完成后会遇到多设备部署问题。可以先用 Docker 把推理服务、模型权重和依赖版本打包成镜像固定运行环境再逐台部署。模型更新时不要直接覆盖权重先在新设备上跑一遍质量验证脚本确认输出达标后再切换生产流量。如果设备数量多还需要集中监控。每台设备上报延迟、显存、失败率和输出长度统一汇总到监控面板。模型质量评估也应该集中化固定测试集上传到中心定期拉取各设备输出做对比提前发现量化、温度或版本不一致导致的质量漂移。整体来看LFM2.5-VL-3B 这类 3B 规模视觉语言模型的价值不在于追平云端大模型的广度而在于把“看得懂图片、说得出结果”的能力放进有限硬件。部署这类模型的正确顺序是先跑通最小推理闭环再量化压缩再服务化最后用固定测试集持续监控质量。给新手的建议是不要一开始就追求最高并发或最低延迟先把一张图从输入到输出的全链路日志打清楚再逐段优化。每一步都有明确的验证方法这套方法论同样适用于后续其它边缘多模态模型的落地。