1. 項目概述當OCR遇上視覺語言模型最近在做一個項目需要從一堆復雜的掃描文檔、產品說明書甚至是一些現(xiàn)場拍攝的圖片里不僅要把文字摳出來還得理解這些文字和圖片內容之間的關系。比如一張產品圖旁邊配了一段參數(shù)說明傳統(tǒng)的OCR光學字符識別工具能把字都識別出來但“這段文字描述的是圖片里的哪個部件”或者“這個表格里的數(shù)字對應的是哪個指標”它就無能為力了。這恰恰是很多實際業(yè)務場景的痛點信息是割裂的我們拿到的是“圖”和“文”兩張皮而不是一個有機的整體。這時候PaddleOCR-VL進入了我的視野。簡單來說它不是PaddleOCR和某個視覺語言模型的簡單拼接而是一個深度融合的解決方案。PaddleOCR本身在文字檢測和識別上的功力有目共睹而VLVisual Language模型比如像Qwen-VL、MiniCPM-V這類模型擅長理解圖像內容并用自然語言進行描述或問答。PaddleOCR-VL所做的就是讓OCR識別出的結構化文本包括位置、內容和VL模型對圖像的深度理解能力產生“化學反應”從而實現(xiàn)圖文關聯(lián)理解、信息結構化抽取、智能問答等更高級的功能。你可以把它想象成一個不僅“視力”好看得清文字而且“腦力”強懂得圖文關聯(lián)的智能助手。這個項目標題“關于PaddleOCR-VL部署與使用說明”核心就是解決“如何把它用起來”的問題。這不僅僅是跑通一個Demo而是涉及到從環(huán)境搭建、服務部署到實際調用的完整鏈路。無論是想在自己的服務器上搭建一個供內部系統(tǒng)調用的服務還是研究如何將其集成到現(xiàn)有的文檔處理流程中亦或是評估其在特定場景如金融票據(jù)理解、工業(yè)質檢報告解析下的效果一個清晰、靠譜的部署和使用指南都至關重要。接下來我就結合自己的踩坑經驗把這套東西從部署到上手的全過程掰開揉碎了講清楚。2. 核心架構與部署方案選型在真正動手敲命令之前花點時間想清楚部署方案能省去后面至少一半的折騰。PaddleOCR-VL的部署不是單一的它更像一個“組合套裝”你需要根據(jù)你的資源、場景和技術棧來選擇合適的“打開方式”。2.1 組件拆解與依賴關系首先得明白我們要部署的是什么。PaddleOCR-VL通常包含以下幾個核心部分PaddleOCR引擎負責基礎的文本檢測找到文字在哪和文本識別認出是什么字。這部分通常比較成熟可以選擇Python庫直接調用或者部署為獨立的HTTP服務如PaddleOCR的HubServing模式。VL視覺語言模型這是智能的核心。它接收圖像和可能的文本提示Prompt輸出對圖像內容的理解。模型本身可能是一個多模態(tài)大模型需要加載預訓練權重。常見的開源選擇包括Qwen-VL、MiniCPM-V等。這部分是計算和內存消耗的大戶。協(xié)同推理框架/腳本這是粘合劑。它需要調度上述兩個組件流程一般是先用PaddleOCR處理圖片得到文本塊及其坐標然后將原始圖片和OCR識別出的文本作為額外的上下文信息一起喂給VL模型最后解析VL模型的輸出得到結構化結果如“將圖片中紅色圓圈內的文字與下方表格第二行關聯(lián)”。理解這個流程后部署方案的選擇就清晰了你是把所有組件塞進一個“大單體”應用還是拆分成微服務2.2 部署模式對比單體、微服務與Serverless對于PaddleOCR-VL我主要評估過三種模式單體應用部署All in One做法在一個Python環(huán)境中安裝PaddlePaddle、PaddleOCR、VL模型相關的庫如transformers然后寫一個統(tǒng)一的Python腳本或Web框架如FastAPI來封裝所有邏輯。優(yōu)點簡單直接鏈路最短內部調用效率高調試方便。適合快速原型驗證、研究或個人開發(fā)環(huán)境。缺點環(huán)境依賴復雜容易沖突特別是CUDA、cuDNN版本。資源伸縮不靈活OCR和VL模型強耦合一損俱損。VL模型通常很大數(shù)GB到數(shù)十GB每次更新或擴展都需要重啟整個服務。適用場景本地開發(fā)測試對吞吐量要求不高的內部工具或資源有限的原型階段。微服務部署做法將PaddleOCR服務和VL模型服務分別獨立部署。例如使用PaddleOCR的HubServing或自行封裝為FastAPI服務來提供OCR能力同時使用類似Triton Inference Server、vLLM如果VL模型是類GPT結構或簡單的FastAPI來部署VL模型服務。最后再有一個“協(xié)調服務”O(jiān)rchestrator來調用前兩者。優(yōu)點解耦清晰每個服務可以獨立開發(fā)、部署、伸縮和升級?？梢葬槍CR可能CPU密集型和VL絕對GPU密集型分別優(yōu)化資源配置。容錯性更好一個服務掛掉不影響另一個盡管整體功能失效。非常適合生產環(huán)境。缺點架構復雜需要維護多個服務涉及服務發(fā)現(xiàn)、網絡通信、負載均衡等。部署和運維成本高。適用場景企業(yè)級生產系統(tǒng)需要高可用、可伸縮的服務團隊有DevOps能力?；谌萜鞯牟渴餌ocker/Kubernetes這其實不是一種獨立的模式而是實現(xiàn)上述兩種模式的理想載體。無論是單體還是微服務用Docker容器化都是最佳實踐。優(yōu)點環(huán)境隔離依賴打包一次構建到處運行。版本管理清晰回滾方便。結合Kubernetes可以輕松實現(xiàn)微服務架構的自動化部署、伸縮和管理。缺點需要學習Docker和Kubernetes的相關知識有一定門檻。我的選擇與建議對于大多數(shù)想嘗鮮或中小型應用我推薦采用“Docker化單體應用”作為起步。它平衡了復雜度和可維護性。先用一個Docker容器把整個PaddleOCR-VL流程跑通對外提供統(tǒng)一的API。當業(yè)務量增長或需要更精細化管理時再考慮拆分為微服務。下文也將以這種模式作為主線進行詳細說明。3. 詳細部署實操從零到一的完整過程假設我們的目標是在一臺擁有NVIDIA GPU的Linux服務器上通過Docker部署一個提供PaddleOCR-VL能力的API服務。這里我以集成PaddleOCR和Qwen-VL-Chat模型為例。3.1 基礎環(huán)境與Docker準備首先確保你的服務器滿足以下條件操作系統(tǒng)Ubuntu 20.04/22.04 LTS其他發(fā)行版也可但指令可能微調。NVIDIA GPU驅動已安裝可通過nvidia-smi驗證。Docker Engine 和 NVIDIA Container Toolkit 已安裝。這是讓Docker容器能用上GPU的關鍵。安裝NVIDIA Container Toolkit的步驟簡要如下# 添加倉庫并安裝 distribution$(. /etc/os-release;echo $ID$VERSION_ID) curl -s -L https://nvidia.github.io/nvidia-docker/gpgkey | sudo apt-key add - curl -s -L https://nvidia.github.io/nvidia-docker/$distribution/nvidia-docker.list | sudo tee /etc/apt/sources.list.d/nvidia-docker.list sudo apt-get update sudo apt-get install -y nvidia-container-toolkit sudo systemctl restart docker # 測試運行一個帶GPU的測試容器 sudo docker run --rm --gpus all nvidia/cuda:11.8.0-base-ubuntu22.04 nvidia-smi如果能看到GPU信息說明環(huán)境就緒。3.2 構建PaddleOCR-VL的Docker鏡像我們不直接從Docker Hub拉現(xiàn)成的因為需要定制化集成VL模型。自己構建鏡像更靈活。創(chuàng)建項目目錄結構paddleocr-vl-service/ ├── Dockerfile ├── requirements.txt ├── app.py ├── ocr_vl_pipeline.py └── models/ # 用于存放下載的模型文件可通過卷掛載避免鏡像過大編寫Dockerfile這是鏡像的藍圖。# 使用PaddlePaddle官方GPU鏡像作為基礎它包含了CUDA和cuDNN FROM paddlepaddle/paddle:latest-gpu-cuda11.8-cudnn8 # 設置工作目錄 WORKDIR /app # 安裝系統(tǒng)依賴中文字體解決OCR識別中文亂碼 RUN apt-get update apt-get install -y \ libgl1-mesa-glx \ libglib2.0-0 \ wget \ wget -O /tmp/simhei.ttf https://github.com/StellarCN/scp_zh/raw/master/fonts/SimHei.ttf \ mkdir -p /usr/share/fonts/truetype/custom/ \ mv /tmp/simhei.ttf /usr/share/fonts/truetype/custom/ \ fc-cache -f -v \ rm -rf /var/lib/apt/lists/* # 復制依賴文件并安裝Python包 COPY requirements.txt . RUN pip install --upgrade pip -i https://mirror.baidu.com/pypi/simple \ pip install -r requirements.txt -i https://mirror.baidu.com/pypi/simple # 復制應用代碼 COPY . . # 暴露端口假設我們的服務運行在8000端口 EXPOSE 8000 # 啟動命令 CMD [uvicorn, app:app, --host, 0.0.0.0, --port, 8000, --workers, 1]注意這里使用--workers 1是因為VL模型通常很大多進程加載會占用多倍顯存。生產環(huán)境可以考慮通過多個容器實例配合負載均衡來實現(xiàn)并發(fā)。編寫requirements.txt列出所有Python依賴。paddlepaddle-gpu2.6.0 paddleocr2.7.0.3 fastapi0.104.1 uvicorn[standard]0.24.0 python-multipart0.0.6 transformers4.36.0 torch2.1.0cu118 --extra-index-url https://download.pytorch.org/whl/cu118 accelerate0.25.0 sentencepiece0.1.99 # 某些VL模型tokenizer需要重要提示PaddlePaddle、PyTorch和CUDA版本的兼容性是最大的坑務必確認你的GPU驅動支持的CUDA版本然后選擇對應版本的PaddlePaddle和PyTorch。這里以CUDA 11.8為例。編寫核心處理管道ocr_vl_pipeline.pyimport os from paddleocr import PaddleOCR from transformers import Qwen2VLForConditionalGeneration, AutoTokenizer, AutoProcessor import torch from PIL import Image import numpy as np import json class PaddleOCR_VL_Pipeline: def __init__(self, ocr_langch, use_gpuTrue, vl_model_pathNone): 初始化管道 Args: ocr_lang: PaddleOCR識別語言如 ch, en, chinese_cht等 use_gpu: 是否使用GPU進行OCR vl_model_path: 本地Qwen-VL模型路徑如果為None則嘗試從HuggingFace下載 # 初始化PaddleOCR關閉詳細日志 self.ocr_engine PaddleOCR(use_angle_clsTrue, langocr_lang, use_gpuuse_gpu, show_logFalse) print(PaddleOCR引擎初始化完成。) # 初始化Qwen-VL模型 self.device cuda if torch.cuda.is_available() else cpu model_name Qwen/Qwen2-VL-7B-Instruct if vl_model_path is None else vl_model_path # 加載processor處理圖像和文本 self.processor AutoProcessor.from_pretrained(model_name, trust_remote_codeTrue) # 加載模型 self.vl_model Qwen2VLForConditionalGeneration.from_pretrained( model_name, torch_dtypetorch.float16, # 使用半精度減少顯存占用 device_mapauto, # 自動分配模型層到可用設備多卡支持 trust_remote_codeTrue ).eval() # 設置為評估模式 print(fVL模型加載完成運行在 {self.device} 上。) def run_ocr(self, image_path): 執(zhí)行OCR返回文本塊列表每個塊包含坐標和內容 result self.ocr_engine.ocr(image_path, clsTrue) if result is None or len(result) 0: return [] # 解析結果格式[[[x1,y1],[x2,y2],[x3,y3],[x4,y4]], (文本, 置信度)] ocr_blocks [] for line in result[0]: box line[0] # 四個頂點坐標 text line[1][0] # 文本內容 confidence line[1][1] # 置信度 # 計算中心點近似作為塊的代表點 center_x sum([pt[0] for pt in box]) / 4 center_y sum([pt[1] for pt in box]) / 4 ocr_blocks.append({ bbox: box, center: (center_x, center_y), text: text, confidence: confidence }) return ocr_blocks def generate_vl_prompt(self, ocr_blocks): 根據(jù)OCR結果構造給VL模型的提示詞 # 簡單示例將所有OCR文本按位置粗略排序后作為上下文提供給模型 # 更復雜的策略可以按區(qū)域、段落進行組織 sorted_blocks sorted(ocr_blocks, keylambda b: (b[center][1], b[center][0])) # 先y后x排序 ocr_context \n.join([f文本塊{i1}: {block[text]} for i, block in enumerate(sorted_blocks)]) prompt f你是一個文檔理解助手。以下是從圖像中識別出的文本塊按大致位置排序{ocr_context}請根據(jù)原圖像內容回答以下問題這張圖片主要是什么類型的文檔或內容文本塊之間有哪些邏輯關聯(lián)例如哪個是標題哪個是正文哪個是表格數(shù)據(jù)如果有表格請嘗試將其內容以Markdown表格形式整理出來。 請直接給出分析結果。 return promptdef run_vl_inference(self, image_path, prompt): 執(zhí)行VL模型推理 image Image.open(image_path).convert(RGB) # 使用processor準備模型輸入 messages [ { role: user, content: [ {type: image}, {type: text, text: prompt} ] } ] # 準備輸入 text self.processor.apply_chat_template(messages, add_generation_promptTrue) inputs self.processor(text[text], images[image], paddingTrue, return_tensorspt) inputs inputs.to(self.device) # 生成 with torch.no_grad(): generated_ids self.vl_model.generate(**inputs, max_new_tokens512) generated_ids_trimmed [ out_ids[len(in_ids):] for in_ids, out_ids in zip(inputs.input_ids, generated_ids) ] # 解碼輸出 output_text self.processor.batch_decode(generated_ids_trimmed, skip_special_tokensTrue)[0] return output_text def process(self, image_path): 端到端處理流程 # 1. OCR print(開始OCR識別...) ocr_blocks self.run_ocr(image_path) print(f識別到 {len(ocr_blocks)} 個文本塊。) # 2. 構建提示 prompt self.generate_vl_prompt(ocr_blocks) # 3. VL推理 print(開始VL模型推理...) vl_result self.run_vl_inference(image_path, prompt) # 4. 整合結果 final_result { ocr_results: ocr_blocks, vl_analysis: vl_result } return final_result全局實例避免重復加載模型在FastAPI中可使用lifespan管理pipeline None def get_pipeline(): global pipeline if pipeline is None: # 假設模型已下載到本地 /app/models/Qwen2-VL-7B-Instruct model_path /app/models/Qwen2-VL-7B-Instruct pipeline PaddleOCR_VL_Pipeline(ocr_langch, use_gpuTrue, vl_model_pathmodel_path) return pipeline編寫FastAPI應用app.pyfrom fastapi import FastAPI, File, UploadFile, HTTPException from fastapi.responses import JSONResponse import tempfile import os from ocr_vl_pipeline import get_pipeline import uuid app FastAPI(titlePaddleOCR-VL 圖文理解服務, version1.0) app.on_event(startup) async def startup_event(): # 服務啟動時預加載模型冷啟動較慢 print(服務啟動正在加載模型...) _ get_pipeline() print(模型加載完成服務就緒。) app.post(/analyze) async def analyze_document(file: UploadFile File(...)): 上傳圖片文件返回OCR和VL分析結果。 支持格式PNG, JPG, JPEG等。 # 檢查文件類型 if not file.content_type.startswith(image/): raise HTTPException(status_code400, detail請上傳圖片文件。) # 保存上傳的臨時文件 suffix os.path.splitext(file.filename)[1] or .jpg with tempfile.NamedTemporaryFile(deleteFalse, suffixsuffix) as tmp_file: content await file.read() tmp_file.write(content) tmp_file_path tmp_file.name try: pipeline get_pipeline() result pipeline.process(tmp_file_path) # 可以在這里對結果進行后處理或格式化 return JSONResponse(contentresult) except Exception as e: raise HTTPException(status_code500, detailf處理過程中發(fā)生錯誤{str(e)}) finally: # 清理臨時文件 os.unlink(tmp_file_path) app.get(/health) async def health_check(): 健康檢查端點 return {status: healthy, service: paddleocr-vl}3.3 構建鏡像與運行容器下載VL模型權重由于模型很大建議在構建鏡像前先下載到models/目錄然后在Dockerfile中復制或者使用數(shù)據(jù)卷掛載。這里使用掛載方式更靈活。cd paddleocr-vl-service mkdir -p models # 使用huggingface-cli下載需先登錄huggingface-cli login huggingface-cli download Qwen/Qwen2-VL-7B-Instruct --local-dir models/Qwen2-VL-7B-Instruct # 或者使用git lfs # git lfs install # git clone https://huggingface.co/Qwen/Qwen2-VL-7B-Instruct models/Qwen2-VL-7B-Instruct構建Docker鏡像docker build -t paddleocr-vl-service:1.0 .這個過程會花費一些時間因為它需要安裝所有依賴。運行Docker容器docker run -d --name ocr_vl \ --gpus all \ -p 8000:8000 \ -v $(pwd)/models:/app/models \ # 掛載模型目錄避免鏡像過大 -v /tmp:/tmp \ # 掛載臨時目錄方便處理上傳文件 paddleocr-vl-service:1.0--gpus all將主機所有GPU分配給容器。-v $(pwd)/models:/app/models將宿主機上的模型目錄掛載到容器內這樣更新模型無需重建鏡像。-p 8000:8000將容器的8000端口映射到主機的8000端口。驗證服務curl http://localhost:8000/health如果返回{status:healthy,service:paddleocr-vl}說明服務已啟動。4. 服務調用、優(yōu)化與問題排查服務跑起來只是第一步怎么用好、用穩(wěn)才是關鍵。4.1 API調用與結果解析你可以使用任何HTTP客戶端調用服務。這里用Pythonrequests庫示例import requests import json url http://你的服務器IP:8000/analyze image_path 你的測試圖片.jpg with open(image_path, rb) as f: files {file: (image_path, f, image/jpeg)} response requests.post(url, filesfiles) if response.status_code 200: result response.json() print(OCR結果原始文本塊:) for i, block in enumerate(result[ocr_results]): print(f 塊{i1}: {block[text]} (置信度: {block[confidence]:.2f})) print(\nVL模型分析結果:) print(result[vl_analysis]) else: print(f請求失敗: {response.status_code}) print(response.text)返回的vl_analysis字段就是模型對圖文結合理解后的自然語言描述。你需要根據(jù)你的下游應用比如自動填表、知識庫構建來解析這段文本。更高級的做法是在構造Prompt時就讓模型以指定的JSON格式輸出方便程序化處理。4.2 性能優(yōu)化與生產級考量顯存優(yōu)化Qwen2-VL-7B模型在FP16精度下需要約14GB顯存。如果你的顯卡顯存不足如24G的3090/4090在運行其他進程后可能不夠可以嘗試量化使用bitsandbytes庫進行4位或8位量化能大幅減少顯存占用但可能會輕微損失精度。# 在加載模型時使用4位量化 from transformers import BitsAndBytesConfig quantization_config BitsAndBytesConfig(load_in_4bitTrue) self.vl_model Qwen2VLForConditionalGeneration.from_pretrained( model_name, quantization_configquantization_config, # 加入量化配置 device_mapauto, trust_remote_codeTrue ).eval()使用更小模型考慮參數(shù)量更小的VL模型如2B或3B版本。卸載到CPU使用accelerate或device_map策略將部分模型層卸載到CPU內存但推理速度會顯著下降。推理速度優(yōu)化啟用Flash Attention如果模型和你的GPU如Ampere架構之后的A100, 3090, 4090等支持可以啟用Flash Attention加速注意力計算。在加載模型時傳入attn_implementationflash_attention_2參數(shù)需安裝flash-attn庫。批處理如果業(yè)務場景允許可以一次處理多張圖片構建批處理的Prompt能提升GPU利用率。但需要仔細設計提示詞避免不同圖片間信息干擾。服務健壯性超時與重試在客戶端或協(xié)調服務中設置合理的請求超時和重試機制。VL模型推理可能耗時10-30秒甚至更長。健康檢查與優(yōu)雅退出實現(xiàn)/health端點并在Kubernetes的livenessProbe和readinessProbe中使用。確保在收到終止信號時能完成正在處理的請求再退出。日志與監(jiān)控在關鍵步驟OCR開始/結束、VL推理開始/結束打上日志并記錄耗時。集成Prometheus等監(jiān)控工具暴露指標如請求數(shù)、平均響應時間、錯誤率。4.3 常見問題與排查實錄在實際部署中我遇到了不少問題這里列幾個典型的問題Docker容器啟動失敗提示CUDA錯誤或libcuda.so找不到。排查首先在宿主機運行nvidia-smi確認驅動和CUDA可用。然后運行docker run --rm --gpus all nvidia/cuda:11.8.0-base nvidia-smi測試容器內GPU是否正常。解決確保安裝了正確版本的nvidia-container-toolkit并重啟了Docker服務。檢查Dockerfile中使用的基礎鏡像CUDA版本是否與宿主機驅動兼容。問題服務能啟動但調用/analyze接口時VL模型推理報錯“顯存不足Out of Memory, OOM”。排查進入容器docker exec -it ocr_vl bash運行nvidia-smi查看顯存占用。很可能是在加載模型時顯存就占滿了。解決嘗試使用量化如上述4位量化。換用更小的VL模型。升級顯卡硬件。如果有多張卡確保device_mapauto能正確將模型分布到多卡上。問題OCR識別中文出現(xiàn)亂碼或“口口口”。排查這是缺少中文字體的典型表現(xiàn)。解決在Dockerfile中已經添加了安裝中文字體的步驟。如果仍有問題檢查字體文件是否成功復制并刷新了緩存?？梢赃M入容器運行fc-list | grep -i simhei確認字體已安裝。問題VL模型生成的回答質量不高或者沒有結合OCR文本。排查檢查構造的Prompt。將打印出的Prompt和原始圖片一起放到Web版的Qwen-VL對話中測試看結果是否理想。解決Prompt Engineering是關鍵。你需要精心設計提示詞明確告訴模型OCR文本是什么、你想讓它做什么。例如對于發(fā)票Prompt可以是“你看到一張發(fā)票圖片。我已識別出以下文本塊及其位置[列出文本]。請?zhí)崛〕鲩_票日期、銷售方名稱、購買方名稱、商品名稱、數(shù)量、單價、總金額并以JSON格式輸出?！?多迭代幾次Prompt效果會有顯著提升。問題服務響應非常慢超過1分鐘。排查分階段計時。在代碼中記錄OCR階段和VL推理階段的耗時。解決OCR階段慢確認PaddleOCR是否成功使用了GPU初始化日志會顯示Using GPU successfully?？梢試L試調整PaddleOCR參數(shù)如關閉方向分類use_angle_clsFalse如果圖片方向固定。VL推理階段慢這是主要瓶頸。除了前述的Flash Attention可以嘗試減少max_new_tokens生成文本的最大長度或使用更高效的解碼策略如do_sampleFalse使用貪婪解碼。對于生產環(huán)境考慮使用專門的推理服務器如vLLM或Triton來部署VL模型部分它們有更優(yōu)化的內核和批處理能力。5. 進階應用與擴展思路當基礎服務穩(wěn)定后可以考慮以下幾個方向進行深化定制化微調如果通用VL模型在你的專業(yè)領域如醫(yī)療報告、法律文書表現(xiàn)不佳可以考慮用領域特定的圖文數(shù)據(jù)對VL模型進行微調LoRA或全參數(shù)微調讓它更懂你的“行話”。流水線優(yōu)化將OCR和VL推理設計成異步流水線。用戶上傳圖片后立即返回一個任務IDOCR完成后將結果存入消息隊列如Redis后端的VL模型Worker從隊列消費任務進行處理用戶再通過另一個接口憑ID查詢結果。這能極大提高接口的響應速度和系統(tǒng)的吞吐量。結果結構化目前VL模型輸出是自然語言?？梢越Y合“思維鏈Chain-of-Thought”提示或訓練一個小的文本分類/序列標注模型將自然語言輸出解析成固定的、可編程的結構化數(shù)據(jù)如JSON方便與下游業(yè)務系統(tǒng)集成。多模態(tài)檢索增強將處理后的“圖片-OCR文本-VL理解”三元組向量化存入向量數(shù)據(jù)庫如Milvus、Chroma。后續(xù)可以實現(xiàn)基于文本或圖片的混合檢索構建一個智能的多模態(tài)知識庫。部署PaddleOCR-VL這類多模態(tài)系統(tǒng)就像搭積木關鍵在于理解每個組件的特性和它們之間的接口。從簡單的單體Docker服務開始逐步迭代到更復雜、更健壯的架構這個過程中積累的經驗和踩過的坑遠比一次性追求完美架構更有價值。最重要的是動手跑起來用真實的圖片和業(yè)務問題去測試它你才會對它的能力和邊界有最直觀的認識。