过去一年多多模态大模型虽然能“看懂图”但在复杂场景下“想不明白”的问题越来越突出。比如让模型分析一张园区监控画面它能说出“有几个人、几辆车”却很难推理出“人群聚集是否来自异常事件、该不该触发告警”。另一个矛盾是通用推理模型很强但不懂图像和传感器数据多模态模型懂数据推理链路却相对薄弱。特斯联的解法是把 DeepSeek-R1 的推理能力接入到自研渝州大模型的多模态链路中通过模型蒸馏和推理调度把“看得见”和“想得深”结合起来。本文从一个可落地的工程视角拆解这条技术路径的原理、架构、代码示例和踩坑经验。1. 背景多模态大模型的“感知强、推理弱”困局1.1 多模态大模型的现状多模态大模型指的是能同时处理文本、图像、音频、视频等多种输入的大语言模型。常见的实现思路是用视觉编码器把图片转成视觉 token再与文本 token 一起送入大语言模型做统一建模。这类模型在“感知类”任务上已经非常成熟例如图片描述给出图片生成自然语言描述。视觉问答问“图里有几只猫”模型能准确回答。目标识别检测图片里的物体类别和位置。文档理解对截图、PDF、表格进行信息抽取。但在“推理类”任务上多模态模型普遍偏弱。例如给一张设备告警截图判断故障的根因链条。给一段园区人流热力图推理可能的安全风险。给几张前后对比图判断施工进度是否与计划一致。根据多模态数据综合判断给出可执行的决策建议。这些任务不仅要求“看到什么”还要求“根据看到的内容按照一定的逻辑规则推出结论”。这正是特斯联在产业 AI 落地中频繁遇到的真实需求。1.2 特斯联为什么要接入 DeepSeek-R1特斯联自研了渝州大模型这是一个面向城市级、产业级场景的多模态大模型落地场景包括智慧园区、公共安全、能源管理和办公自动化。在这些场景中模型不只是用来聊天而是要参与实际的业务决策。接入 DeepSeek-R1 的核心动机可以概括为两点。第一DeepSeek-R1 有很强的长思维链推理能力。它在数学、逻辑、代码等需要多步推理的任务上表现突出能够“一步一步想清楚再回答”。这种推理能力正是多模态模型欠缺的。第二特斯联的落地场景对推理要求越来越高。早期只需要“识别出画面里是什么”现在需要“根据画面信息和历史数据推理出应该做什么”。前者靠感知模型后者靠推理模型。所以特斯联的思路不是推翻自研模型而是把 DeepSeek-R1 作为“推理大脑”与渝州大模型的“视觉感知能力”结合形成一条完整的“感知 → 理解 → 推理 → 决策”链路。2. 核心概念DeepSeek-R1 与多模态推理链路2.1 DeepSeek-R1 是什么DeepSeek-R1 是深度求索推出的推理模型系列特点是采用了强化学习训练能够生成较长的思维链Chain of Thought在回答复杂问题前先进行内部推理。从工程使用角度看DeepSeek-R1 与传统对话模型有几个明显区别擅长多步推理适合数学题、逻辑题、代码生成、复杂规划。输出可能包含推理过程回答中会包含“思路拆解”部分需要做解析和后处理。对 Prompt 格式敏感通常需要明确的指令告诉模型“请一步步推理”。推理成本高于普通对话模型因为生成 token 数更多响应时间更长。在特斯联的架构中DeepSeek-R1 不会直接替代渝州大模型而是作为推理增强组件负责对多模态解析结果做深度分析。2.2 多模态推理链路的整体思想“接入 DeepSeek-R1 提升推理能力”并不是简单地在应用层同时调用两个模型而是把推理能力嵌入到多模态处理链路中。一条典型的多模态推理链路是这样的多模态输入图片、视频帧、文本、传感器数据进入渝州大模型。渝州大模型完成感知理解输出结构化的“场景描述”或“识别结果”。DeepSeek-R1 拿到这些结构化中间结果结合业务规则做深度推理。推理结果返回给业务系统触发告警、生成报告或辅助决策。这种架构下多模态大模型负责“感知”DeepSeek-R1 负责“思考”各司其职。2.3 为什么不用单一模型完成全部任务有人会问为什么不直接训练一个有多模态能力又有强大推理能力的模型答案是成本和周期不允许。训练一个同时具备顶尖感知和顶尖推理能力的多模态大模型需要大规模多模态数据、海量算力和长期调优。对于产业落地项目来说更务实的做法是“组合现有能力”。通过模型蒸馏、接口调度、结果融合等方式把多个模型的优势结合起来。特斯联的做法就是典型的工程化路线保留自研渝州大模型的感知能力和行业知识同时把 DeepSeek-R1 的推理能力通过蒸馏和调度的方式注入到业务链路中。3. 整体架构设计如何接入 DeepSeek-R13.1 架构分层从工程实现上可以将整个系统分为四层。层级职责关键技术接入层接收图片、视频、文本等输入HTTP、流式传输、消息队列感知层多模态理解生成结构化中间结果渝州大模型、视觉编码器推理层基于中间结果做逻辑推理DeepSeek-R1、思维链 Prompt应用层输出决策建议、告警、报告规则引擎、业务系统感知层和推理层是本文讨论的核心。3.2 两条接入路径在实际项目中接入 DeepSeek-R1 有两种常见方式。第一种是接口调用方式。DeepSeek-R1 以 API 服务形式提供业务系统将多模态模型输出的结构化结果发送给 R1R1 返回推理结果。优点是接入快、模型迭代不依赖本地资源缺点是依赖外部服务需要考虑网络延迟和数据安全。第二种是模型蒸馏方式。把 DeepSeek-R1 生成的“高质量推理样本”作为训练数据蒸馏到渝州大模型中让渝州大模型自身具备更强的推理能力。优点是推理过程可控、延迟低、支持私有化部署缺点是需要数据构建和训练调优的周期。特斯联采用的是两者结合的路线短期通过接口调用快速验证效果中期通过蒸馏把 R1 的推理能力沉淀到自研模型中。3.3 数据流向示例下面用一张简化的数据流说明整个链路输入图片 → 渝州大模型感知 → 结构化描述JSON → DeepSeek-R1推理 → 决策结果JSON → 业务系统例如输入一张“园区入口人员聚集”的图片渝州大模型输出{objects: [person, person, person], count: 12, scene: entrance, time: 2025-01-15 09:30}DeepSeek-R1 结合历史数据和规则推理{risk_level: high, reason: 同一入口15分钟内人数增长超过阈值且处于非高峰时段建议触发现场巡检, action: notify_security}这就是“感知 推理”的典型价值底层模型负责把图像变成结构化事实推理模型负责把事实变成业务判断。4. 环境准备与依赖说明开始写代码前先说明运行环境。以下版本仅供参考请根据实际项目情况调整。4.1 基础环境操作系统LinuxUbuntu 20.04 或 CentOS 7生产环境建议使用 Docker 部署。Python 版本Python 3.9 或 3.10。主要依赖库openai、requests、pydantic、Pillow。模型服务DeepSeek-R1 APIOpenAI 兼容接口渝州大模型本地服务或 API。4.2 安装依赖pip install openai requests pydantic pillow python-dotenv4.3 项目结构建议按下面的结构组织代码multimodal-reasoning/ ├── config/ │ └── settings.py # 环境变量和配置 ├── core/ │ ├── perception.py # 渝州大模型感知调用 │ ├── reasoning.py # DeepSeek-R1 推理调用 │ └── pipeline.py # 完整链路调度 ├── schemas/ │ └── models.py # 数据结构定义 ├── scripts/ │ ├── distill_data.py # 蒸馏数据构建 │ └── evaluate.py # 效果评估 └── main.py # 示例入口5. 核心代码示例搭建多模态推理链路下面给出一个简化但完整的示例演示如何将渝州大模型的感知结果发送给 DeepSeek-R1 进行推理。5.1 配置管理# 文件路径config/settings.py import os from dotenv import load_dotenv load_dotenv() # DeepSeek-R1 API 配置 DEEPSEEK_API_KEY os.getenv(DEEPSEEK_API_KEY) DEEPSEEK_BASE_URL os.getenv(DEEPSEEK_BASE_URL, https://api.deepseek.com) DEEPSEEK_MODEL os.getenv(DEEPSEEK_MODEL, deepseek-reasoner) # 渝州大模型 API 配置 YZ_API_KEY os.getenv(YZ_API_KEY) YZ_BASE_URL os.getenv(YZ_BASE_URL, http://localhost:8000) YZ_MODEL os.getenv(YZ_MODEL, yuzhou-vl)5.2 数据结构定义# 文件路径schemas/models.py from pydantic import BaseModel from typing import List, Optional class PerceptionResult(BaseModel): 渝州大模型输出的感知结果 scene: str objects: List[str] count: int confidence: float raw_text: str class ReasoningResult(BaseModel): DeepSeek-R1 输出的推理结果 risk_level: str reason: str action: str confidence: float raw_output: strPydantic 的好处是可以在运行时校验数据结构。当模型输出缺少字段或类型不对时能第一时间发现避免脏数据进入业务系统。5.3 调用渝州大模型做感知# 文件路径core/perception.py import base64 import requests from schemas.models import PerceptionResult def image_to_base64(image_path: str) - str: with open(image_path, rb) as f: return base64.b64encode(f.read()).decode(utf-8) def perceive(image_path: str, prompt: str 请描述图片中的场景、物体和数量并输出JSON。) - PerceptionResult: 调用渝州大模型将图片转为结构化感知结果。 注意这里使用的是示例函数实际请按照渝州大模型服务文档调整。 payload { model: yuzhou-vl, messages: [ { role: user, content: [ {type: text, text: prompt}, {type: image_url, image_url: {url: fdata:image/jpeg;base64,{image_to_base64(image_path)}}} ] } ] } resp requests.post(http://localhost:8000/v1/chat/completions, jsonpayload) resp.raise_for_status() content resp.json()[choices][0][message][content] # 这里简化为直接解析 JSON实际工程中建议做容错处理 import json data json.loads(content) return PerceptionResult(**data)这段代码的核心是让渝州大模型输出结构化的 JSON而不是自由文本。在 Prompt 中要明确指定输出格式例如“输出 JSON包含 scene、objects、count、confidence 字段”。否则后续解析会非常痛苦。5.4 调用 DeepSeek-R1 做推理# 文件路径core/reasoning.py from openai import OpenAI from schemas.models import PerceptionResult, ReasoningResult from config.settings import DEEPSEEK_API_KEY, DEEPSEEK_BASE_URL, DEEPSEEK_MODEL client OpenAI(api_keyDEEPSEEK_API_KEY, base_urlDEEPSEEK_BASE_URL) REASONING_PROMPT 你是一个园区安全管理专家。我会给你一段从监控画面中提取的结构化信息你需要根据这些信息判断安全风险。 请按以下要求输出 1. 先逐步推理说明你关注了哪些关键指标。 2. 最后输出 JSON包含 risk_level、reason、action、confidence 四个字段。 3. risk_level 只能取 low、medium、high 三个值。 结构化信息 {perception_text} def reason(perception: PerceptionResult, business_rules: str ) - ReasoningResult: perception_text perception.model_dump_json() prompt REASONING_PROMPT.format(perception_textperception_text) if business_rules: prompt f\n\n附加业务规则\n{business_rules} resp client.chat.completions.create( modelDEEPSEEK_MODEL, messages[{role: user, content: prompt}], temperature0.1, max_tokens2000, ) raw_output resp.choices[0].message.content # 从输出中提取 JSON import json, re json_match re.search(r\{.*\}, raw_output, re.DOTALL) if not json_match: raise ValueError(f无法从模型输出中解析 JSON原始输出{raw_output}) data json.loads(json_match.group()) return ReasoningResult(**data, raw_outputraw_output)这里有几个关键设计点temperature0.1推理类任务需要稳定输出温度越低越好避免模型“自由发挥”。先让模型“逐步推理”再输出 JSON这是思维链的经典用法能够明显提升推理准确率。正则提取 JSON因为 DeepSeek-R1 可能会在 JSON 前后输出解释文字直接json.loads会失败。5.5 完整链路调度# 文件路径core/pipeline.py from core.perception import perceive from core.reasoning import reason from schemas.models import ReasoningResult def multimodal_reasoning(image_path: str, business_rules: str ) - ReasoningResult: # 第一步感知 perception perceive(image_path) print([感知结果], perception.model_dump()) # 第二步推理 result reason(perception, business_rules) print([推理结果], result.model_dump()) return result5.6 主入口示例# 文件路径main.py from core.pipeline import multimodal_reasoning if __name__ __main__: result multimodal_reasoning( image_pathtest_images/entrance_crowd.jpg, business_rules如果同一地点连续15分钟人数超过10人且当前不是上下班高峰则风险等级至少为medium。 ) print(最终决策动作, result.action)运行方式python main.py预期输出类似[感知结果] {scene: entrance, objects: [person, person, person], count: 12, confidence: 0.87, raw_text: ...} [推理结果] {risk_level: high, reason: ..., action: notify_security, confidence: 0.82} 最终决策动作 notify_security6. 从接口调用走向模型蒸馏接口调用的方式适合快速验证效果但如果想把 DeepSeek-R1 的推理能力真正“沉淀”到渝州大模型中还需要做模型蒸馏。6.1 蒸馏的基本思路蒸馏的目标是让渝州大模型在“不调用 DeepSeek-R1”的情况下也能输出接近 R1 的推理结果。流程如下构造一批多模态输入样本。让渝州大模型生成感知结果。把感知结果和业务问题一起发送给 DeepSeek-R1生成高质量的推理答案。将“感知结果 问题 → R1 的推理答案”作为训练数据。用这些数据对渝州大模型进行微调。6.2 蒸馏数据构建示例# 文件路径scripts/distill_data.py import json import csv from core.perception import perceive from core.reasoning import reason def build_distill_dataset(image_paths: list, output_file: str): 批量生成蒸馏数据并保存为 JSONL 格式 with open(output_file, w, encodingutf-8) as f: for idx, image_path in enumerate(image_paths): print(f处理第 {idx 1} 张图片{image_path}) # 感知 perception perceive(image_path) # 推理 reasoning_result reason(perception) sample { instruction: 请根据结构化感知信息判断安全风险。, input: perception.model_dump_json(), output: reasoning_result.raw_output, } f.write(json.dumps(sample, ensure_asciiFalse) \n) print(f蒸馏数据已保存到 {output_file})生成的数据样例如下{ instruction: 请根据结构化感知信息判断安全风险。, input: {\scene\: \entrance\, \objects\: [\person\], \count\: 12, \confidence\: 0.87}, output: 先关注人数和时间因素... {risk_level: high, reason: ..., action: notify_security, confidence: 0.82} }6.3 蒸馏训练注意事项用蒸馏数据微调渝州大模型时有几个问题需要特别注意。第一数据质量比数据量更重要。与其生成 10 万条噪声数据不如人工筛选 5000 条高质量、覆盖典型场景的数据。第二要防止灾难性遗忘。微调时可以将少量原始数据混入训练集避免模型忘记原有的感知能力。第三蒸馏能力有上限。渝州大模型的参数规模和架构决定了它能承接多少推理能力。如果模型本身很小强行蒸馏复杂推理逻辑可能导致效果不升反降。6.4 蒸馏后的效果评测蒸馏完成后需要一套评测体系判断效果是否提升。# 文件路径scripts/evaluate.py import json from core.reasoning import reason from schemas.models import ReasoningResult def evaluate(test_cases: list): test_cases 格式 [ { image_path: xxx.jpg, expected_risk: high } ] total len(test_cases) correct 0 for case in test_cases: try: result multimodal_reasoning(case[image_path]) predicted_risk result.risk_level if predicted_risk case[expected_risk]: correct 1 else: print(f预测失败{case[image_path]}期望 {case[expected_risk]}实际 {predicted_risk}) except Exception as e: print(f执行异常{case[image_path]}错误{e}) accuracy correct / total * 100 print(f测试样本数{total}准确率{accuracy:.2f}%)评测指标建议分层指标维度说明目标风险等级准确率预测的 risk_level 是否与标注一致越高越好动作合理率生成的 action 是否可执行、符合业务规范需要人工抽检输出格式合法率JSON 是否能正常解析、字段是否完整应接近 100%推理延迟单次推理耗时根据场景要求设定7. 常见问题与排查思路把 DeepSeek-R1 接入多模态大模型时最常见的几类问题如下。问题现象常见原因解决思路接口返回超时思维链生成的 token 数过多设置max_tokens上限将长任务改为异步队列处理JSON 解析失败模型在 JSON 前后输出了解释性文字使用正则提取 JSON 片段或要求模型只输出 JSON推理结果不稳定temperature 设置过高将 temperature 降到 0.1 或 0多轮推理上下文超出限制感知结果太长或历史消息过多精简感知结果只保留关键字段引入摘要机制蒸馏后模型变“笨”微调数据过少或过于单一增加数据多样性混入原始感知数据数据安全不达标敏感图片直接发送到外部 API私有化部署推理模型对图片脱敏后再调用下面挑两个典型问题展开说明。7.1 输出 JSON 总是解析失败这是接入 R1 后最常遇到的情况。因为 DeepSeek-R1 习惯输出“思考过程”很多情况下它会在 JSON 前后写一段推理说明例如我先分析一下数据图片中人数较多且是非高峰时段所以风险偏高。 {risk_level: high, reason: 人数超过阈值, action: notify_security, confidence: 0.82}直接json.loads整个字符串必然报错。稳妥的做法是在 Prompt 中明确要求“只输出 JSON不要输出任何解释”。在代码层使用正则提取第一个{到最后一个}之间的内容。使用JSON schema校验字段缺失时给出明确错误信息。7.2 推理延迟过高R1 因为要生成思维链响应时间通常比普通对话模型长。在实时告警场景中这种延迟可能是不可接受的。缓解方案把复杂推理任务放到异步任务队列业务系统先做简单的规则判断。对 DeepSeek-R1 的输入做精简只保留关键字段。使用蒸馏后的本地小模型做日常高频推理R1 只处理低频率、高复杂度的任务。从实际项目经验看最有效的还是“冷热分离”简单场景走规则引擎中等场景走蒸馏模型复杂场景才调用 R1。7.3 业务规则如何融入单独调用大模型做推理很容易出现“看着合理但不符合业务规定”的情况。例如模型建议“封锁大门”但园区规定只有消防事件才能封锁。建议在推理链路中增加“规则预过滤”环节。把业务规则以 JSON 或自然语言形式拼进 Prompt同时在代码层增加规则校验发现模型输出与硬性规则冲突时以规则为准。8. 最佳实践与工程建议基于特斯联在多模态推理场景的落地经验整理几条对后续项目有直接帮助的建议。8.1 明确感知与推理的边界在架构设计阶段就要明确哪些任务由感知模型负责哪些任务由推理模型负责。我的建议是凡是“看图说话”类任务交给渝州大模型等感知模型。凡是“基于事实做判断”类任务交给 DeepSeek-R1 或蒸馏后的推理模型。不要试图让一个模型干所有事组合的灵活度远高于单体模型。8.2 把输出做成结构化协议感知模型和推理模型之间的数据传输格式本质上是一种内部协议。建议用 Pydantic、JSON Schema 或 Protobuf 做强约束。例如感知结果至少应该包含scene: 场景类别 objects: 目标列表 count: 数量 confidence: 置信度 timestamp: 时间戳推理结果至少应该包含risk_level: 风险等级 reason: 推理依据 action: 建议动作 confidence: 置信度结构化的好处是后续无论是做日志审计、数据回流还是切换模型成本都很低。8.3 建立数据回流闭环每次 DeepSeek-R1 的推理结果都应该记录到样本库中。经过人工确认后可以作为下一轮蒸馏的训练数据。这样整个系统会越用越准逐步降低对外部推理模型的依赖。具体做法所有推理请求记录原始输入、中间结果、最终输出。对高风险决策要求业务人员反馈结果是否正确。定期筛选高质量样本补充到蒸馏数据集。8.4 安全与合规不可忽视产业场景的数据往往涉及人员、位置、设备等敏感信息。在调用外部推理模型前必须做好脱敏处理。建议的安全措施图片中的人脸、车牌、门牌号先做打码处理。发送给外部 API 时不携带业务主键、用户真实 ID。API Key 使用环境变量或密钥管理服务保存严禁硬编码。如果数据敏感度很高优先选择私有化部署推理模型。8.5 监控与退化预案接入新模型后一定要建立监控大盘。至少关注以下指标接口调用成功率。平均响应时间。输出格式合法率。风险等级分布偏移。业务侧告警误报率。当指标异常时要能快速切回旧链路。建议一开始就预留开关配置例如通过配置中心动态切换“使用 DeepSeek-R1”还是“使用蒸馏模型”。9. 总结与下一步规划把 DeepSeek-R1 接入渝州大模型本质上是在多模态感知模型之外补上了一条推理链路。特斯联的方式不是简单“外挂一个模型”而是把 R1 的推理能力通过接口调用和模型蒸馏两个阶段逐步融入产业 AI 系统。从工程落地角度看这种“感知模型 推理模型”的组合式架构非常适合当前算力有限、场景复杂的现实条件。在实施过程中需要特别关注三点第一定义好感知与推理之间的结构化协议这是链路稳定运行的基础第二重视数据回流蒸馏出的推理能力才是自研模型的长期壁垒第三从冷热路径分离和规则兜底开始避免一开始就追求全场景强推理。如果接下来要继续深入可以重点研究以下几个方向。使用 DeepSeek-R1 的推理能力构建高质量思维链数据集时如何设计自动评估方案减少人工标注成本。在多模态模型中引入强化学习让模型在推理过程中学会调用工具或查询知识库。推理结果的置信度与业务风险联动比如低置信度时自动转人工复核。最终的目标是让模型在复杂场景中不仅“看得见”还能“想得清楚、说得有理、做得准确”。