Select Page
InternVL3 本地部署教學:用 lmdeploy 跑 OCR 與多模態理解

InternVL3 本地部署教學:用 lmdeploy 跑 OCR 與多模態理解

InternVL3 值得注意的地方,不只是又一個開源多模態模型,而是它把本地 VLM 的使用場景推得更實際,OCR、掃描文件、模糊表格、手寫字、截圖理解,這些都不是聊天模型的展示題,而是每天真的會卡住工作的資料入口。

如果之前已經在玩 本地多模態分析,InternVL3 可以看成下一個很適合放進實驗清單的模型。它不只是看圖說話,而是更接近能處理文件、表格與複雜畫面的視覺語言模型。

InternVL3 的重點是文件理解,而不是炫技

AIVI 的整理把 InternVL3 放在企業級 OCR 和多模態理解的脈絡裡看。這個定位很合理。現在很多人把 VLM 拿來做圖片描述,但真正有價值的地方,往往是把原本不適合丟給文字模型的資料變成可處理的結構。

例如模糊 PDF 掃描件、手寫備註、拍歪的表格、截圖裡的 UI 狀態,這些資料以前要靠人工整理,或用傳統 OCR 加一堆後處理。InternVL3 這類模型讓流程變成另一種樣子。先讓 VLM 看懂畫面,再把結果交給下游的 RAG、資料庫、工作流或 Agent。

這也能和 MarkItDown 這類文件轉換工具互補。文字型文件可以先轉 Markdown,掃描影像、複雜表格和視覺內容則交給 VLM 補上理解能力。

InternVL3 有哪些技術方向值得看

AIVI 筆記提到三個重點。第一個是原生多模態預訓練。它不是先訓練純文字模型,再把視覺模組接上去,而是在同一個訓練階段同時學文字和多模態資料。這個方向的好處,是減少後期對齊的落差,讓模型在文字能力與視覺理解之間更一致。

第二個是可變視覺位置編碼。這類設計的核心,是讓視覺 token 的位置表示更彈性,支援更長的多模態上下文。對文件理解很重要,因為真實文件常常不是單張乾淨圖片,而是多頁、表格、註記、圖文混排。

第三個是偏好優化與測試時擴展。簡單說,就是讓模型不只會回答,也能在推理過程中更穩定地挑出比較好的答案。這對 OCR 類任務尤其重要,因為一個字看錯、欄位對錯、單位錯置,都可能讓後面的分析整個歪掉。

為什麼要用 lmdeploy

InternVL3 本身是模型,真正要落到日常使用,還需要部署層,這就是 InternLM 的 lmdeploy 進場的地方。它的定位是壓縮、部署和服務化 LLM 與 VLM,官方 README 強調高效推理、量化、多機多卡服務和相容性。

用比較白話的方式說,lmdeploy 是把模型從「可以下載」變成「可以被應用呼叫」。當它用 OpenAI 相容 API 跑起來後,Open WebUI、自寫腳本、內部工具或 Agent 流程都可以用同一套 API 方式接進來。

這一點對本地部署很重要,單次 demo 可以直接跑 notebook,但長期使用要考慮服務常駐、併發、顯存、量化、監控和前端介面。這也是為什麼本地 AI 不該只停在安裝成功,而要慢慢走向像 OpenMontage 本地部署那樣,把模型、服務和工作流串起來。

建議部署流程

AIVI 的流程可以整理成四段。第一段是準備 Linux 或 WSL 環境,第二段是建立 conda 環境,第三段是安裝 lmdeploy 與必要套件,第四段是啟動 API server 並接到 Open WebUI。

conda create -n lmdeploy python=3.11 -y
conda activate lmdeploy
pip install lmdeploy partial_json_parser timm

模型服務可以先用 14B 版本做測試。AIVI 範例使用 TurboMind backend,port 設在 23333,並指定 InternVL 相關 chat template。

lmdeploy serve api_server OpenGVLab/InternVL3-14B-Instruct --backend turbomind --server-port 23333 --tp 2 --chat-template internvl2_5

啟動後,OpenAI 相容呼叫大致長這樣。重點不是 API key 本身,而是 base_url 指向本機服務。

from openai import OpenAI

client = OpenAI(
    api_key="local-key",
    base_url="http://127.0.0.1:23333/v1"
)

model_name = client.models.list().data[0].id

如果要給一般使用者操作,可以再裝 Open WebUI。

pip install open-webui
open-webui serve

Open WebUI 的價值不是漂亮而已,而是讓 VLM 從工程實驗變成日常工具。你可以把它當成公司內部的視覺文件入口,讓同事不用碰 Python,也能上傳圖片、掃描件或表格截圖測試效果,這個方向也和 AI Agent 進入可視化操作介面的趨勢一致。

部署前要先想清楚硬體與模型大小

InternVL3 有不同參數規模。不要一開始就衝最大模型,除非你已經有足夠顯存和多卡環境,比較務實的做法,是先用 14B 或更小版本建立流程,確認 API、Open WebUI、圖片上傳、OCR 品質和下游應用都通,再決定是否升級。

lmdeploy 官方支援量化與多種推理引擎,這表示部署時可以在速度、顯存、品質之間取平衡。若是個人工作站,應該先關心能不能穩定跑起來。若是團隊服務,才進一步考慮併發、多卡與監控。

如果已經在比較本地模型格式與顯卡路線,可以順手參考 Ollama 與 Qwen 量化選擇這類文章。雖然工具不同,但同樣是在處理顯存、速度和品質的取捨。

適合拿來做什麼

  • 把掃描 PDF 或圖片文件轉成可分析的文字與表格。
  • 判讀手寫註記、發票、表單、截圖與複雜版面。
  • 為內部知識庫補上圖片與文件理解能力。
  • 替 GUI Agent 提供畫面理解與狀態判斷。
  • 建立不依賴雲端 API 的企業內部 VLM 服務。

我會特別看好文件處理和內部工具場景。因為這些工作通常資料敏感,而且每家公司文件格式不同,雲端通用 OCR 未必能直接解決。能本地跑,代表可以把資料留在自己的機器或內網裡,再慢慢針對真實樣本調整流程。

我的結論

InternVL3 加 lmdeploy 的組合,真正值得看的不是安裝命令,而是它讓本地 VLM 服務變得更像一個可長期使用的基礎設施。模型負責看懂圖片與文件,lmdeploy 負責把模型服務化,Open WebUI 或其他前端負責降低使用門檻。

如果你的工作裡有大量掃描件、圖片表格、手寫內容、UI 截圖或需要保密的文件,這條路線很值得測。它不一定會取代所有 OCR 工具,但會讓 OCR 從單純辨識文字,升級成理解畫面裡的結構與意圖。

延伸資源

InternVL3.5 models HuggingFace

FAQ

InternVL3 適合做什麼?

InternVL3 適合處理 OCR、掃描件、手寫字、表格截圖、圖文混排文件和 GUI 畫面理解。它的價值不只是描述圖片,而是把視覺資料轉成可被後續流程使用的資訊。

lmdeploy 在這裡扮演什麼角色?

lmdeploy 是部署與服務化工具。它可以把 InternVL3 這類模型包成 API server,讓 Open WebUI、Python 腳本或內部工具用 OpenAI 相容方式呼叫。

一定要用最大版本的 InternVL3 嗎?

建議先用較小版本把流程跑通,確認 OCR 品質、顯存占用、API 和前端整合都穩定,再依需求升級到更大的模型。

Docling 是什麼?PDF 轉 Markdown、OCR 與 VLM 文件解析實戰

Docling 是什麼?PDF 轉 Markdown、OCR 與 VLM 文件解析實戰

企業知識庫和 AI Agent 最麻煩的地方,常常不是模型不夠聰明,而是資料進不來。PDF、掃描合約、研究報告、表格、圖片型文件,看起來都只是文件,但對 RAG 或 Agent 來說,它們必須先被轉成穩定、乾淨、可引用的結構化內容。

Docling 就是在解這個入口問題。它不是只把 PDF 拆成純文字,而是把文件版面、閱讀順序、表格、公式、圖片、OCR 結果整理成 AI 更容易消化的格式,例如 Markdown、HTML、JSON。對要做企業知識庫的人來說,這一層通常比後面換哪一個聊天模型更關鍵。

Docling 適合解決什麼問題

Docling 是 IBM Research Zurich 發起的開源專案,採用 MIT License。它支援 PDF、DOCX、PPTX、XLSX、HTML、EPUB、圖片與音訊等格式,官方也強調它能和 LangChain、LlamaIndex、CrewAI、Haystack 這類生成式 AI 工具鏈整合。

如果只是把少量文件轉成 Markdown,微軟的 MarkItDown 會很輕巧,之前我也整理過 MarkItDown 教學,但 Docling 的定位更偏向文件理解管線,尤其是 PDF 版面、表格、掃描文件、VLM 輔助解析這些較複雜的場景。

最基本的使用方式

Docling 的入門方式很直接,Python 環境建好後先安裝依賴:

pip install litellm google-generativeai docling

最小 Python 範例可以用 DocumentConverter 讀取 PDF,再輸出 Markdown:

from docling.document_converter import DocumentConverter

source = "https://arxiv.org/pdf/2408.09869"
converter = DocumentConverter()
result = converter.convert(source)

markdown_text = result.document.export_to_markdown()
print(markdown_text)

也可以用命令列直接轉檔:

docling https://arxiv.org/pdf/2408.09869

這種方式很適合處理數位原生 PDF,例如論文、報告、產品文件。它能保留標題層級、段落、表格與部分版面資訊,後續要切 chunk、做向量化、放進 RAG 都比較順。

掃描 PDF 要接 VLM 才會真正好用

企業場景裡最痛的通常是掃描件。掃描合約、舊報紙、模糊文件、影印後再掃描的 PDF,傳統 OCR 很容易漏字、錯行、表格亂掉,Docling 的強項之一,是可以把解析流程接到視覺語言模型,讓 VLM 協助理解頁面。

本地部署路線可以用 LM Studio 載入 InternVL3-9B,讓 Docling 透過 OpenAI 相容 API 呼叫本機模型,這個做法的優點是資料不必送到外部雲端,適合公司內部文件、客戶資料、合約與敏感文件。缺點是需要顯卡資源,也要接受本地模型在模糊文字上的上限。

如果追求辨識品質,Gemini 2.5 Pro 這類雲端 VLM 的效果通常會更穩,尤其是模糊掃描、複雜版面、引用格式、符號與表情符號。代價就是 API 成本、資料外送與權限控管,真正落地時,我會把它分成兩條管線:一般文件走本地模型,低信心或高價值文件再送雲端模型複核。

一個實用的企業知識庫流程

  1. 先把 PDF、Word、Excel、HTML、圖片掃描件集中到同一個資料夾或物件儲存。
  2. 用 Docling 轉成 Markdown 或 JSON,保留頁碼、標題、表格與圖片資訊。
  3. 針對掃描件啟用 OCR 或 VLM 管線,低品質文件可以標記信心分數。
  4. 清理內容,移除頁首頁尾、重複頁碼、錯誤斷行,再依標題與段落切 chunk。
  5. 把 chunk 放入向量資料庫,同時保存原始頁面來源,方便回答時回溯引用。
  6. 接到 RAG、Agent 或 Notebook 型工具,讓使用者可以查詢、摘要、比對文件。

之前整理過 GraphRAG 使用本地端的 Ollama,或是 Open Notebook 這類私有研究工作流,前面都需要穩定的文件解析層。Docling 可以放在最前端,負責把混亂文件變成 AI 能讀的乾淨材料。

LM Studio、InternVL3、Gemini 怎麼選

如果資料敏感,先選 LM Studio 加 InternVL3。這種配置比較像私有 OCR 與文件理解服務,可以在內網跑,也能和既有 Python 管線整合。若你已經在評估 Qwen 或其他本地模型,也可以參考 Ollama Qwen 3.6 怎麼選本地端多模態分析實戰 的思路。

如果文件很雜、品質很差、需要快速拿到高準確度結果,Gemini 2.5 Pro 會比較省心。尤其是頁面裡有表格、引用、符號、圖片文字混在一起時,雲端 VLM 的容錯能力會更好。我的建議不是二選一,而是分層使用:本地模型做第一輪,難件再升級到雲端模型。

導入前要注意的坑

第一,Python 版本要注意,Docling 近期版本已經不支援 Python 3.9,建議直接用 Python 3.10 以上,專案環境也要隔離,避免和舊套件衝突。

第二,不要只看 Markdown 有沒有產生,真正要檢查的是段落順序、表格欄位、頁碼引用、公式、圖片說明、錯字率。只要這些地方亂掉,後面的 RAG 回答就會變得不可信。

第三,VLM 不是魔法,模糊掃描、歪斜頁面、低解析度照片仍然會出錯。比較穩的做法是保存原始頁面圖、解析後文字、模型信心與人工校對狀態,讓知識庫能追蹤每一段內容從哪裡來。

結論

Docling 值得放進 AI 知識庫工具箱,原因不是它可以把 PDF 轉 Markdown 這麼簡單,而是它把文件解析變成一條可組合的管線。一般文件用基礎轉換,掃描件加 OCR,高難度文件再接 VLM,最後輸出成 RAG 可以使用的 Markdown 或 JSON。

如果你的資料來源大多是網頁和乾淨文字,Docling 不一定是第一個要上的工具。但只要公司文件裡有大量 PDF、掃描件、表格、舊報告,它就是很值得測的入口層。AI 系統的回答品質,很多時候從文件被讀進來的那一刻就決定了。

FAQ

Docling 和 MarkItDown 差在哪裡?

MarkItDown 很適合快速把常見文件轉成 Markdown。Docling 更偏向完整文件理解,強調 PDF 版面、表格結構、OCR、VLM 和 AI 工具鏈整合。

一定要用 Gemini 才能處理掃描 PDF 嗎?

不一定。本地可以用 LM Studio 搭配 InternVL3 這類視覺模型。Gemini 的優勢是複雜文件辨識品質通常更好,但需要考慮 API 成本和資料外送。

Docling 適合企業內部知識庫嗎?

很適合,特別是資料來源包含 PDF、掃描件、簡報、表格和舊文件時。它可以把文件轉成 AI 較容易處理的格式,再交給 RAG 或 Agent 使用。

OmniParser-微軟的開源螢幕解析工具

OmniParser-微軟的開源螢幕解析工具

繼之前提到的 Ahthropic Computer Use ,那時候超級驚豔的,馬上就看到MS也有推出自己的版本,雖然沒有自動執行功能,但可以配合 pyautogui 達成,雖然不支援中文,但可以透過中文OCR 或是 tesseract 處理

安裝到本地端

先建立一個虛擬環境起來

conda create -n omni python=3.12 -y
conda activate omni

選項:有GPU的,先把CUDA安裝起來

conda install pytorch torchvision torchaudio pytorch-cuda=12.1 -c pytorch -c nvidia

整個安裝也很簡單,就五個步驟

git clone https://github.com/microsoft/OmniParser.git && cd OmniParser
pip install -r requirements.txt
huggingface-cli download --repo-type model microsoft/OmniParser --local-dir weights --include "icon_detect/*" "icon_caption_blip2/*" "icon_caption_florence/*"
python /home/Ubuntu/OmniParser/weights/convert_safetensor_to_pt.py
python gradio_demo.py

OmniParser 2.0 更新

OmniParser V2 的主要改進與優勢

1. 更大、更乾淨的訓練資料集

OmniParser V2 採用了規模更大且模型已經清洗良好的「icon caption + grounding」資料集,涵蓋更豐富的 UI 標記與功能描述,進而提升模型對互動區域的識別能力。

2. 顯著降低推理延遲

V2 在推理速度上較 V1 快了 60%,平均延遲為每畫面 0.6 秒(A100 GPU)或 0.8 秒(RTX 4090),適合即時 GUI 解讀與互動場景。

3. Grounding 準確度大幅提升

在「ScreenSpot Pro」這項標註小型 UI 元素的基準上,搭配 GPT-4o,V2 的平均精準度達到 39.6%,遠高於 GPT-4o 原本只有 0.8% 的表現。

4. 整合 OmniTool,打造完整 AI GUI Agent 流程

V2 支援搭配 OmniTool,形成一個即插即用的環境,可控制 Windows 11 VM 並搭配各家大型語言模型,如 OpenAI (4o, o1, o3-mini)、DeepSeek R1、Qwen 2.5VL 甚至 Anthropic,使建構 GUI Agent 更簡單。

5. 擴大使用場景與穩定性

除了支援 PC 與手機螢幕截圖外,V2 的架構更穩定、更泛用,適合建構可解讀 GUI 的多種應用。


V1 vs V2 功能比較表

特性OmniParser V1OmniParser V2
訓練資料集標準 icon caption+grounding 少量更大、更乾淨的訓練資料集
推理速度較慢快了約 60%,平均延遲 0.6s–0.8s
Grounding 準確度基準低,難以處理小 UI 元素搭配 GPT-4o 平均達 39.6% 準確率
操作流程整合性需手動整合模型與 LLM支援 OmniTool,快速與多款 LLM 串接
適用場景廣度較狹窄更廣泛,包含各種 GUI 互動與截圖輸入

下載新的模型

for f in icon_detect/{train_args.yaml,model.pt,model.yaml} icon_caption/{config.json,generation_config.json,model.safetensors}; do huggingface-cli download microsoft/OmniParser-v2.0 "$f" --local-dir weights; done
   mv weights/icon_caption weights/icon_caption_florence

如果你是 Windows 可以去 Hugginface 下載模型後,並且在目錄下建立 weights\icon_caption_florence ,把下載來的模型放在目錄中即可

https://huggingface.co/microsoft/OmniParser-v2.0/tree/main

OmniParser 1.5 更新

先下載模型

python weights/convert_safetensor_to_pt.py

For v1.5: 
download 'model_v1_5.pt' from https://huggingface.co/microsoft/OmniParser/tree/main/icon_detect_v1_5, make a new dir: weights/icon_detect_v1_5, and put it inside the folder. No weight conversion is needed. 

執行指令要改成 1.5 版本

python gradio_demo.py --icon_detect_model weights/icon_detect_v1_5/model_v1_5.pt --icon_caption_model florence2

支援其他的語言

舉例來說,要改成中文,請找到專案下的 utils.py ,將 en 改成 ch

reader = easyocr.Reader(['en'])
paddle_ocr = PaddleOCR(
#    lang='en',  # other lang also available
    lang='ch',  # other lang also available
    use_angle_cls=False,
    use_gpu=False,  # using cuda will conflict with pytorch in the same process
    show_log=False,
    max_batch_size=1024,
    use_dilation=True,  # improves accuracy
    det_db_score_mode='slow',  # improves accuracy
    rec_batch_num=1024)

在介面中選取使用 PaddleOCR

相關資源

OmniParser 原始碼

OmniParser 官網

OmniParser 模型

https://blog.stoeng.site/20241030.html

Visa、MasterCard 都大推的「數位企業卡」,可以綁定手機嗎?

Visa、MasterCard 都大推的「數位企業卡」,可以綁定手機嗎?


由於企業在經營過程中,需要支付眾多費用如商務差旅、辦公用品採購、交通費和員工福利等,這些支出不僅種類繁多,而且報銷流程繁瑣且耗時,因此,及時監控金流變得尤為重要。

為了解決這個問題,Visa和萬事達卡分別在13日宣布推出「數位企業卡」(Virtual Corporate Card),意在獲得企業金流管理市場的先機。

數位企業卡

所謂的「數位企業卡」是透過企業名義申辦一張主卡號,再由員工申請數位子卡來進行交易,這使得員工可以使用隨機生成的卡號來支付各類費用,如企業採購、跨境付款、廣告費、交通和住宿費等。

萬事達卡聲稱,這種純數位卡的好處有三個主要方面:首先,它為跨境支付提供了更大的靈活性,並能產生一次性或多次性使用的卡號,從而提供了更安全的支付方式。其次,它可以解決傳統財務對帳和結算問題,用戶可以根據交易類型、週期和額度定制卡片,而且每筆交易都需要事先申請,系統會即時通知員工和簽核人員,自動產生報銷單,幫助企業有效管理支出。最後,如果交易出現異常,簽核方可以立即鎖卡,增加交易的安全性。

Visa台灣區總經理趙麗芳高興地宣布,經過一年準備,Visa數位企業卡現在已經準備就緒,並可以綁定LINE Pay使用。研究顯示,全球有73%的小型企業認為數位支付是其成長的關鍵,然而還有45%的中小企業在進行B2B支付時仍然依賴現金和支票。

同樣地,萬事達卡也與TapPay(喬睿科技)合作,預計在2024年上半年推廣「萬事達卡企業虛擬信用卡支付解決方案」,以幫助台灣企業加速數位轉型,更有效地控制商務支出。

這兩家金融服務巨頭的舉動,顯示出數位支付技術在企業運營管理中的重要性。數位企業卡提供的解決方案不僅能提升金流的效率和安全性,還能為企業節省貴重的人力成本,促進業務發展。在FinTech行業中,這種創新的支付方案可能成為企業日益增長需求的答案,而Visa和萬事達卡都在積極探索這片新興市場,提供更加智能、便捷的支付選項給大家。

綁定手機更便利

為了使支付過程更加便捷,Visa和萬事達卡還特別強調了其與手機APP的緊密整合。例如,Visa的數位企業卡可以綁定LINE Pay,而萬事達卡則計劃與TapPay合作,預計將在不久的將來擴大導入這項服務。這樣的結合不僅大大減少了現金支付的不便,還意味著在任何時候、任何地點,只要通過手機即可進行交易,無需隨身攜帶實體信用卡,這對於追求效率與安全的現代企業來說,無疑是一大福音。

COMMEET

科技新創公司COMMEET的結合更是將這一方案的便利性提升到了新的高度。透過其AI光學字元辨識技術(OCR)和智能費用管理系統,從拍照上傳發票到費用追蹤和報銷單生成,所有過程都能通過手機APP實現,大幅提升了報銷作業的效率。

申請請到 COMMEETTapPayOwlPay