从二维到三维:SAM 3D 模型技术解析

在计算机视觉领域,图像分割已经发展多年。而随着三维重建与空间理解需求的增长,研究开始从“识别图像中的对象”走向“理解对象的三维结构”。Segment Anything Model(SAM) 的出现,本质上解决了“通用分割”问题。而在此基础上发展的 SAM 3D,则进一步尝试解决: 如何从二维图像推断三维结构。 本文将从原理、结构、能力与应用几个层面,对 SAM 3D 进行系统梳理。 一、技术背景:从 2D 分割到 3D 重建 传统的 3D 重建通常依赖: 而 SAM 3D 的核心思想是: 利用大规模预训练视觉模型的先验知识,从单张图像中推断三维结构。 这并不是“真实测量”,而是基于深度学习的结构推断与形状补全。 二、SAM 3D 的核心能力 1️⃣ 单图 3D 推断 输入: 输出: 这是 SAM 3D 的核心突破之一。 2️⃣ 基于分割的三维重建 SAM 3D 并不是独立模型,而是建立在 SAM 分割能力之上: 这种“先分割、再升维”的流程,使得模型具有更强的可控性。 三、模型结构概览 虽然具体实现会因版本不同而变化,但总体结构可以概括为: 图像编码器 (Vision …

Raspberry Pi 系统从 8GB SD 卡迁移到 16GB SD 卡的完整流程(UUID 启动 + 无损扩容)

摘要 本文记录一次在线系统迁移过程:在系统正常运行的前提下,将 Raspberry Pi 上的 Ubuntu 24.04 LTS 系统从一张 8GB SD 卡迁移到一张 16GB SD 卡,并实现根分区自动扩容。 本流程不使用 dd,采用 rsync 进行文件系统级复制,并通过 UUID 启动方式避免盘符混乱问题。 该方法适用于: 迁移目标 当前环境示例 运行系统盘: 目标盘(通过 USB 读卡器接入): 一、重新分区目标 SD 卡 目标卡必须为: 执行: 输入: 二、创建文件系统 三、挂载新系统 四、复制整个系统(文件系统级迁移) 使用 rsync 而非 dd。 原因: 执行两次: 第二次执行用于补同步。 五、获取新卡 UUID 示例: 六、修改新系统 fstab 编辑: …

本地服务器测试 Qwen2.5-VL-3B:一次轻量多模态模型验证记录

一、测试背景 在自建服务器环境中部署并测试 Qwen2.5-VL-3B 多模态模型,用于验证其在标准终端截图场景下的识别与结构理解能力。 测试输入为一张历史保存的 Linux 终端截图。截图内容为某 ARM 设备执行系统信息命令后的输出。所有个性化字段(包括序列号等)已脱敏处理,仅用于能力验证。 本次测试目的: 二、输入场景说明 截图特征: 属于典型“高对比规则文本”场景。 三、模型输出表现 模型成功完成以下任务: 未出现明显字段错读或结构误判。 在该类场景下,3B 规模模型表现稳定。 四、能力边界分析 需要明确一点: 终端截图属于视觉模型最容易处理的类型之一。 原因包括: 因此该测试结果仅说明: 模型在规则终端文本场景下可用。 并不能代表其在以下场景中的能力: 3B 级模型在复杂视觉推理任务中天然存在能力上限。 五、部署角度思考 在本地服务器环境中测试的意义在于: 3B 规模模型的优势在于: 对于工程体系而言: 模型只需满足明确场景需求,无需追求极限性能。 六、结论 本次测试得出的结论非常简单: 在规则终端截图场景下,Qwen2.5-VL-3B 表现稳定且可用。 该模型适合: 不适合: 在自建服务器体系中,它更像一个“可控的视觉工具模块”,而不是核心计算引擎。

本地部署 70B 大模型的现实路径:关于显存、架构与理性升级

一、问题背景 在本地部署大语言模型时,常见的一个想法是: 如果本地能够流畅运行 70B 规模模型,是否就可以完全替代云端模型? 这个问题表面上是模型规模问题,本质上是算力结构、显存容量、推理效率与整体系统设计的综合判断。 二、模型规模与硬件资源的基本关系 在大语言模型推理中,决定可运行规模的核心资源是: 其中,显存容量是最硬性的门槛。 1. 小规模模型(7B–14B) 特点: 这一规模在日常对话、代码辅助、知识问答中表现已经非常成熟。 2. 中等规模模型(30B–32B) 特点: 这一规模通常是“性能与效率的平衡点”。 3. 大规模模型(70B) 关键事实: 结论: 若希望 70B 流畅运行,显存容量应接近或超过 48GB。 三、“能运行”与“流畅运行”的区别 在实际体验中必须区分: 状态 含义 能运行 模型可以加载并输出结果 流畅运行 首 token 快,输出稳定,长对话不卡顿 若显存不足: 因此: 显存不足时,70B 虽可运行,但不具备良好的交互体验。 四、服务器环境中的现实因素 在老架构服务器中,需要考虑: 其中: 五、可行的硬件升级路径(脱敏) 单卡大显存方案(优先推荐) 特征: 优点: 这是 70B 流畅运行的现实门槛方案。 多卡中等显存方案 …

使用 Docker 部署 n8n 的完整实践记录(含反向代理与 LLM 接入)

一、目标架构 部署一个具备以下能力的自动化系统: 整体逻辑结构如下: 并额外接入: 二、数据库初始化陷阱 问题表现 原因 PostgreSQL 在首次启动时会根据环境变量初始化数据库。 之后即使修改密码,容器也不会重新初始化。 解决方式 删除数据库数据卷后重新启动。 关键原则: 数据库初始化仅进行一次。 三、数据库角色冲突问题 错误示例: 产生原因: 正确结构: 两者必须分离。 四、反向代理导致的两个典型问题 1️⃣ 邀请链接错误指向 localhost 现象: 新用户邀请链接使用 localhost 原因: 未正确设置外部访问环境变量。 必须显式配置: 否则系统默认生成本地地址。 2️⃣ X-Forwarded-For 报错 日志示例: 原因: 反向代理转发了客户端 IP但应用未信任代理 解决方式: 设置 trusted proxies。 是否可以忽略? 五、浏览器安全提示差异 现象: 分析: 结论: 多半为浏览器本地安全数据库或版本问题。 更新浏览器即可解决。 六、容器间网络通信(LLM 接入) …

自动化方案全景对比:从 AI 平台到工作流引擎的系统分析

随着自动化需求的增长,个人与组织可选择的技术方案越来越多。从 AI 应用平台到通用工作流编排引擎,再到企业级调度系统和传统脚本方式,不同工具在能力边界、扩展性、运维复杂度和适用场景上存在显著差异。 本文对主流自动化方案进行统一维度对比,涵盖: 一、AI 导向平台 1. Dify 定位AI 应用与大语言模型工作流平台。 核心能力 优势 局限 适用场景 2. Hugging Face Workflows 定位模型工作流组合平台。 核心能力 局限 适用场景 二、通用自动化工作流平台 3. n8n 定位开源自动化编排引擎。 核心能力 优势 局限 适用场景 4. Node-RED 定位可视化事件驱动自动化工具。 优势 局限 适用场景 5. Huginn 定位开源事件代理系统。 优势 局限 适用场景 三、SaaS 自动化平台 6. Zapier 定位云端自动化平台。 优势 局限 适用场景 …

使用 Unsplash API 为 Nextcloud 配置稳定自然风格随机背景

一、背景说明 在自托管环境中,界面视觉元素不仅影响使用体验,也会对长期工作状态产生潜移默化的影响。为 Unsplash 提供的图片资源接入 Nextcloud 作为背景,可以在不增加系统复杂度的前提下,提升整体视觉质感。 本文记录以下内容: 二、Unsplash API Key 的使用规范 在创建 Unsplash 应用后,会获得两个凭证: 1. 在 Nextcloud 中应填写哪个? 只应填写: 原因: 在随机图片接口中,调用方式通常为: 其中 client_id 对应的即为 Access Key。 三、关键词设计原则 背景图片不应成为注意力干扰源。关键词设计需满足以下要求: 1. 避免高饱和和情绪化元素 不推荐: 原因: 2. 强调稳定自然结构 推荐围绕以下主题: 四、最终稳定关键词组合 经过优化后的自然环境关键词如下: 关键词结构解析 类别 关键词 作用 地形 mountains 稳定视觉锚点 水域 river, calm lake 平衡画面,降低张力 植被 …

Nextcloud 反向代理架构下局域网访问异常排查记录

一、问题现象 部署结构如下: 外网访问正常,局域网访问 http://内网IP/nextcloud/ 时出现异常: curl 复现: 二、问题根因分析 config.php 中存在如下配置: 该配置会: 在源站未启用 443 的情况下,任何 HTTP 请求都会被强制跳转至 HTTPS,从而导致局域网访问失败。 本质问题: 源站未提供 TLS,却强制协议为 HTTPS。 属于架构与配置不匹配。 三、解决方案 删除或注释: 保留: 更新重写规则并重载 Web 服务: 修复后验证: 应返回: 局域网访问恢复正常。 四、反向代理标准配置建议 1. trusted_domains 2. trusted_proxies 用于信任反代传递的 X-Forwarded-* 头部。 3. HSTS 策略 HSTS 应仅在 HTTPS 终端(反代机)启用,不应在纯 HTTP 源站配置。 五、架构原则 在反向代理结构中应遵循: …

多栈 Docker 环境:数据迁移后的卷盘点与安全清理流程

背景 在多 Compose 栈并存的环境里,迁移完成后常见现象是: 目标是:先盘点,再确认引用关系,最后最小化删除,避免误删关键数据。 核心原则 1) 先确认“新数据落点”是否稳定 迁移成功的强信号通常是:关键服务容器的持久化目录全部使用 bind mount,且映射到统一的宿主机工作目录结构。 2) named volume 的风险等级更高 在多栈环境里,named volume 很可能承载关键数据,例如: 结论:只有当卷确认“零引用”且业务已稳定使用 bind mount 时,才进入删除阶段。 盘点步骤 Step A:列出所有卷(建立资产清单) 只列出“无引用候选”(只做名单,不删除): Step B:列出所有容器(包含已停止) 目的: Step C:从容器侧确认挂载类型(关键确认) 对“目标业务容器”查看挂载: 关注点: 若目标业务容器已完全为 bind mount,说明迁移落点基本完成。 识别“迁移搬运容器” 迁移时常用方式是: 这类容器特征: 验证方式:列出某个卷当前被哪些容器引用(最重要的安全检查): 安全清理顺序 ① 先删“迁移搬运容器” 前提:确认这些容器不再需要、并且目标业务已稳定运行。 ② 再做“卷引用归零”验证 对每个旧卷执行: 判定规则: ③ 最后删除确认无引用的旧卷 …

OnlyOffice Docker 栈内统一与匿名卷迁移记录

背景 在使用 onlyoffice/documentserver 单容器部署 OnlyOffice 的过程中,虽然已经将常见目录(logs / data / cache / public / fonts)通过 bind mount 挂载到了用户目录,但在实际检查容器挂载点时,仍然发现 /var/lib/docker/volumes/ 下存在多组随机字符串命名的 volume。 这类 volume 并非人为创建,而是镜像在 Dockerfile 中通过 VOLUME 指令声明后,由 Docker 自动生成的匿名卷。如果不显式覆盖挂载,这些卷会默默承载真实数据,从而破坏“栈内统一、目录可迁移”的目标。 本文记录一次完整的排查与修正过程,将 OnlyOffice 的 全部持久化数据 统一收敛到单一项目目录下,并清理匿名卷依赖。 问题确认:匿名卷从何而来 通过以下命令检查容器挂载点: 可以观察到: 这些匿名卷对应的典型路径包括: 结论:OnlyOffice 内部依赖的 PostgreSQL / RabbitMQ / Redis 等组件,其数据仍然落在 Docker 管理区,而非项目目录。 目标 现有目录结构(示例) …