GLM-OCR与内网穿透结合在本地服务器提供公网OCR服务最近和几个做电商的朋友聊天他们都在为同一件事头疼每天要处理海量的商品图片、订单截图、物流单手动录入信息效率低不说还容易出错。他们试过一些在线的OCR服务要么担心数据隐私要么觉得调用成本太高要么就是识别效果不太理想。这让我想起了一个挺不错的方案把强大的GLM-OCR模型部署在自己公司的内网服务器上然后用内网穿透技术安全地把这个服务“搬”到公网上让外部的应用或者移动端也能方便地调用。这样一来数据不出内网安全可控又能享受本地GPU服务器的强大算力识别又快又准成本还比按次付费的云服务划算得多。今天我就来详细聊聊这个方案的落地过程从模型部署到服务暴露再到简单的安全加固希望能给有类似需求的朋友们一个清晰的参考。1. 为什么选择本地部署内网穿透在深入技术细节之前我们先聊聊为什么这个组合拳值得考虑。很多企业尤其是对数据敏感或者有大量处理需求的都会面临几个核心矛盾数据安全 vs. 服务便利核心业务数据比如合同、财务报表、客户信息肯定不希望上传到第三方云服务。但完全封闭在内网又无法支持移动办公、远程协作或与外部系统集成。成本控制 vs. 性能需求公有云的API调用量大了是一笔不小的开支。而自购的高性能GPU服务器如果只在内网使用利用率可能不高是一种资源浪费。识别效果 vs. 部署复杂度GLM-OCR这类大模型在复杂场景、多语言、手写体识别上表现往往更好但它的部署和运维对很多团队来说是个门槛。把GLM-OCR部署在内网服务器完美解决了数据安全和识别效果的问题。而内网穿透技术则像是一座精心设计的“桥梁”它只负责转发网络请求并不存储或处理你的数据从而在保障内网安全的前提下打开了服务对外提供能力的大门。这个方案特别适合那些已经拥有内部IT基础设施又需要灵活对外提供服务的中小团队或企业部门。2. 第一步在内网服务器部署GLM-OCR服务我们的旅程从内网开始。假设你已经有一台安装了NVIDIA显卡和合适驱动程序的Linux服务器Ubuntu 20.04/22.04是个常见的选择。2.1 环境准备与模型获取首先确保你的Python环境建议3.8以上和CUDA工具包已经就绪。然后我们可以通过pip安装GLM-OCR的Python包。这里假设我们使用一个兼容OpenAI API格式的封装版本这样后续调用会更标准化。# 创建一个干净的Python虚拟环境是个好习惯 python -m venv glm-ocr-env source glm-ocr-env/bin/activate # 安装GLM-OCR及其依赖 # 请注意具体的包名和安装方式请以GLM-OCR官方文档为准此处为示例 pip install glm-ocr-openai-api接下来你需要获取GLM-OCR的模型文件。通常可以从官方渠道下载并放置在一个合适的目录比如/path/to/your/models。记得在部署脚本或配置中指定这个模型路径。2.2 启动一个简单的API服务为了让外部能够调用我们需要将GLM-OCR的能力包装成一个HTTP API。这里我们用轻量级的FastAPI来快速实现。创建一个名为glm_ocr_server.py的文件from fastapi import FastAPI, File, UploadFile, HTTPException from pydantic import BaseModel import uvicorn from typing import Optional import os import tempfile # 假设GLM-OCR的调用方式如下请根据实际SDK调整 # from glm_ocr import GLMOCRProcessor # processor GLMOCRProcessor(model_path/path/to/your/model) app FastAPI(titleGLM-OCR 内网服务) # 初始化OCR处理器在实际应用中这里需要加载模型 # processor GLMOCRProcessor(model_pathMODEL_PATH) class OCRRequest(BaseModel): 接收文本提示如果需要 prompt: Optional[str] 请识别图片中的文字 class OCRResponse(BaseModel): 返回识别结果 text: str confidence: Optional[float] None app.post(/v1/ocr, response_modelOCRResponse) async def process_image(file: UploadFile File(...), request: OCRRequest None): 核心OCR处理接口。 接收一张图片文件返回识别出的文本。 if not file.content_type.startswith(image/): raise HTTPException(status_code400, detail请上传图片文件) try: # 1. 将上传的图片保存到临时文件 with tempfile.NamedTemporaryFile(deleteFalse, suffix.jpg) as tmp_file: content await file.read() tmp_file.write(content) tmp_file_path tmp_file.name # 2. 调用GLM-OCR模型进行识别 # 这里是伪代码你需要替换为实际的GLM-OCR调用 # result processor.process(image_pathtmp_file_path, promptrequest.prompt) # recognized_text result.text # confidence result.confidence # 为了演示我们模拟一个返回结果 recognized_text 这是一段从图片中识别出的模拟文本。 confidence 0.95 # 3. 清理临时文件 os.unlink(tmp_file_path) return OCRResponse(textrecognized_text, confidenceconfidence) except Exception as e: raise HTTPException(status_code500, detailf处理图片时发生错误: {str(e)}) app.get(/health) async def health_check(): 健康检查端点 return {status: healthy, service: GLM-OCR API} if __name__ __main__: # 启动服务监听内网的某个端口例如 7860 uvicorn.run(app, host0.0.0.0, port7860)这个服务启动后会在你服务器的7860端口提供一个OCR接口。你可以先在服务器本地用curl测试一下curl -X POST http://localhost:7860/v1/ocr \ -H accept: application/json \ -F file/path/to/your/test_image.jpg如果看到返回的JSON文本说明内网服务部署成功了。现在这个服务还只能在内网访问。3. 第二步使用内网穿透工具暴露服务到公网接下来我们要搭建那座“桥梁”。内网穿透工具有很多比如 frp、ngrok、花生壳等。这里我们以开源且灵活的frp为例因为它配置清晰对流量控制更精细。3.1 基本原理与架构简单来说你需要一台具有公网IP的服务器作为“中转站”frp服务端你的内网服务器作为“客户端”frp客户端。客户端主动连接到服务端建立一个安全隧道。当公网用户访问服务端的某个端口时流量会通过这个隧道转发到内网服务器的指定端口。公网用户 - [公网IP:端口] (frp服务端) -- 安全隧道 -- [内网IP:7860] (你的GLM-OCR服务)3.2 配置与部署 frp1. 在公网服务器服务端上从 frp 的 GitHub Release 页面下载对应系统版本的压缩包。解压后编辑frps.ini配置文件[common] bind_port 7000 # frp服务端监听端口客户端用来连接的端口 token your_secure_token_here # 认证令牌建议设置一个强密码 # 仪表板可选方便查看状态 dashboard_port 7500 dashboard_user admin dashboard_pwd another_secure_password启动服务端./frps -c ./frps.ini2. 在内网服务器客户端上同样下载并解压 frp。编辑frpc.ini配置文件[common] server_addr your_public_server_ip # 你的公网服务器IP地址 server_port 7000 # 与服务端 bind_port 一致 token your_secure_token_here # 必须与服务端设置的 token 一致 [glm-ocr-http] # 自定义一个服务名称 type tcp # 我们使用TCP转发 local_ip 127.0.0.1 local_port 7860 # 本地GLM-OCR服务监听的端口 remote_port 6000 # 在公网服务器上暴露的端口启动客户端./frpc -c ./frpc.ini配置完成后公网用户就可以通过访问http://你的公网服务器IP:6000/v1/ocr来调用你内网的GLM-OCR服务了。所有流量都经由你的公网服务器中转内网服务器的真实IP并未暴露。4. 第三步为公网访问添加一道安全锁服务暴露到公网后安全就成了头等大事。我们不能让任何人都能随意调用既浪费资源也不安全。这里介绍几种简单有效的加固方式。4.1 API密钥认证最简单有效在FastAPI服务中增加一个简单的API Key验证中间件。修改glm_ocr_server.pyfrom fastapi import FastAPI, File, UploadFile, HTTPException, Depends, Header # ... 其他导入 ... # 定义一个固定的API Key生产环境应从环境变量或配置中心读取 API_KEY YOUR_SECRET_API_KEY_HERE def verify_api_key(api_key: str Header(None, aliasX-API-Key)): if api_key ! API_KEY: raise HTTPException(status_code403, detail无效的API Key) return api_key app.post(/v1/ocr, response_modelOCRResponse) async def process_image( file: UploadFile File(...), request: OCRRequest None, api_key: str Depends(verify_api_key) # 添加依赖项 ): # ... 原有的处理逻辑不变 ...现在客户端在调用时必须在请求头中带上正确的API Keycurl -X POST http://公网IP:6000/v1/ocr \ -H X-API-Key: YOUR_SECRET_API_KEY_HERE \ -H accept: application/json \ -F filetest_image.jpg4.2 利用frp进行IP白名单限制如果你只希望特定的IP地址比如公司办公室出口IP能够访问可以在frp服务端配置中设置。修改服务端的frps.ini[common] bind_port 7000 token your_secure_token_here allow_ports 6000 # 只允许暴露6000端口 # 对特定代理设置白名单 [glm-ocr-http] type tcp local_ip 127.0.0.1 local_port 7860 remote_port 6000 allowed_ips 123.123.123.123, 124.124.124.0/24 # 允许的单个IP或IP段4.3 结合Nginx提供更高级防护可选在公网服务器上你可以在frp前面再部署一个Nginx实现更多功能HTTPS终止配置SSL证书提供加密的HTTPS访问。限流防止恶意高频调用。更复杂的访问控制基于路径、用户代理等的规则。一个简单的Nginx配置片段如下server { listen 443 ssl; server_name ocr.yourdomain.com; # 你的域名 ssl_certificate /path/to/your/cert.pem; ssl_certificate_key /path/to/your/key.pem; location / { # 将请求代理到frp服务端本地的6000端口frp将流量转发到内网 proxy_pass http://127.0.0.1:6000; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; # 可以在这里添加限速等配置 # limit_req zoneone burst10 nodelay; } }这样外部用户通过https://ocr.yourdomain.com/v1/ocr访问体验更好也更安全。5. 实际应用与效果这套方案在我们内部的一个文档处理流程中跑了小半年效果挺扎实。以前市场部的同事需要把活动海报上的嘉宾信息录入系统手动操作一张图得花两三分钟。现在他们直接用手机拍个照通过我们封装好的小程序上传几秒钟后结构化的文本就回来了直接导入后台准确率比之前用的通用OCR高不少。成本上一次性投入就是那台GPU服务器和一台低配的公网VPS用作frp服务端。对比之前按调用量付费的云服务在处理量上来之后几个月就回本了。更重要的是心里踏实所有的合同扫描件、内部资料图片都在自己机房不用担心数据泄露的风险。当然这个方案也不是没有缺点。你需要自己维护内网服务器的稳定性处理模型更新以及应对可能的网络波动。但对于那些对数据安全有要求、且有持续稳定OCR需求的企业来说这套组合拳的性价比和可控性是非常有吸引力的。6. 总结回过头看把GLM-OCR这类大模型通过内网穿透技术提供出去本质上是在“数据安全”、“成本控制”和“服务能力”之间找到了一个不错的平衡点。它不是什么颠覆性的新技术而是对现有工具的一种务实组合。整个搭建过程核心就三步在内网把模型服务跑起来、用frp这类工具开个安全的“通道”、最后别忘了给通道加把“锁”API认证或IP限制。技术门槛并不算高任何一个有基本运维能力的开发团队都能搞定。如果你也在为类似的问题寻找解决方案不妨先从一个小场景开始试试。比如先在内网部署好服务让内部系统用起来跑顺了再通过内网穿透开放给一两个 trusted 的外部应用。一步步来既能验证效果也能控制风险。毕竟适合自己的才是最好的方案。获取更多AI镜像想探索更多AI镜像和应用场景访问 CSDN星图镜像广场提供丰富的预置镜像覆盖大模型推理、图像生成、视频生成、模型微调等多个领域支持一键部署。
GLM-OCR与内网穿透结合：在本地服务器提供公网OCR服务
发布时间：2026/5/25 8:34:43
GLM-OCR与内网穿透结合在本地服务器提供公网OCR服务最近和几个做电商的朋友聊天他们都在为同一件事头疼每天要处理海量的商品图片、订单截图、物流单手动录入信息效率低不说还容易出错。他们试过一些在线的OCR服务要么担心数据隐私要么觉得调用成本太高要么就是识别效果不太理想。这让我想起了一个挺不错的方案把强大的GLM-OCR模型部署在自己公司的内网服务器上然后用内网穿透技术安全地把这个服务“搬”到公网上让外部的应用或者移动端也能方便地调用。这样一来数据不出内网安全可控又能享受本地GPU服务器的强大算力识别又快又准成本还比按次付费的云服务划算得多。今天我就来详细聊聊这个方案的落地过程从模型部署到服务暴露再到简单的安全加固希望能给有类似需求的朋友们一个清晰的参考。1. 为什么选择本地部署内网穿透在深入技术细节之前我们先聊聊为什么这个组合拳值得考虑。很多企业尤其是对数据敏感或者有大量处理需求的都会面临几个核心矛盾数据安全 vs. 服务便利核心业务数据比如合同、财务报表、客户信息肯定不希望上传到第三方云服务。但完全封闭在内网又无法支持移动办公、远程协作或与外部系统集成。成本控制 vs. 性能需求公有云的API调用量大了是一笔不小的开支。而自购的高性能GPU服务器如果只在内网使用利用率可能不高是一种资源浪费。识别效果 vs. 部署复杂度GLM-OCR这类大模型在复杂场景、多语言、手写体识别上表现往往更好但它的部署和运维对很多团队来说是个门槛。把GLM-OCR部署在内网服务器完美解决了数据安全和识别效果的问题。而内网穿透技术则像是一座精心设计的“桥梁”它只负责转发网络请求并不存储或处理你的数据从而在保障内网安全的前提下打开了服务对外提供能力的大门。这个方案特别适合那些已经拥有内部IT基础设施又需要灵活对外提供服务的中小团队或企业部门。2. 第一步在内网服务器部署GLM-OCR服务我们的旅程从内网开始。假设你已经有一台安装了NVIDIA显卡和合适驱动程序的Linux服务器Ubuntu 20.04/22.04是个常见的选择。2.1 环境准备与模型获取首先确保你的Python环境建议3.8以上和CUDA工具包已经就绪。然后我们可以通过pip安装GLM-OCR的Python包。这里假设我们使用一个兼容OpenAI API格式的封装版本这样后续调用会更标准化。# 创建一个干净的Python虚拟环境是个好习惯 python -m venv glm-ocr-env source glm-ocr-env/bin/activate # 安装GLM-OCR及其依赖 # 请注意具体的包名和安装方式请以GLM-OCR官方文档为准此处为示例 pip install glm-ocr-openai-api接下来你需要获取GLM-OCR的模型文件。通常可以从官方渠道下载并放置在一个合适的目录比如/path/to/your/models。记得在部署脚本或配置中指定这个模型路径。2.2 启动一个简单的API服务为了让外部能够调用我们需要将GLM-OCR的能力包装成一个HTTP API。这里我们用轻量级的FastAPI来快速实现。创建一个名为glm_ocr_server.py的文件from fastapi import FastAPI, File, UploadFile, HTTPException from pydantic import BaseModel import uvicorn from typing import Optional import os import tempfile # 假设GLM-OCR的调用方式如下请根据实际SDK调整 # from glm_ocr import GLMOCRProcessor # processor GLMOCRProcessor(model_path/path/to/your/model) app FastAPI(titleGLM-OCR 内网服务) # 初始化OCR处理器在实际应用中这里需要加载模型 # processor GLMOCRProcessor(model_pathMODEL_PATH) class OCRRequest(BaseModel): 接收文本提示如果需要 prompt: Optional[str] 请识别图片中的文字 class OCRResponse(BaseModel): 返回识别结果 text: str confidence: Optional[float] None app.post(/v1/ocr, response_modelOCRResponse) async def process_image(file: UploadFile File(...), request: OCRRequest None): 核心OCR处理接口。 接收一张图片文件返回识别出的文本。 if not file.content_type.startswith(image/): raise HTTPException(status_code400, detail请上传图片文件) try: # 1. 将上传的图片保存到临时文件 with tempfile.NamedTemporaryFile(deleteFalse, suffix.jpg) as tmp_file: content await file.read() tmp_file.write(content) tmp_file_path tmp_file.name # 2. 调用GLM-OCR模型进行识别 # 这里是伪代码你需要替换为实际的GLM-OCR调用 # result processor.process(image_pathtmp_file_path, promptrequest.prompt) # recognized_text result.text # confidence result.confidence # 为了演示我们模拟一个返回结果 recognized_text 这是一段从图片中识别出的模拟文本。 confidence 0.95 # 3. 清理临时文件 os.unlink(tmp_file_path) return OCRResponse(textrecognized_text, confidenceconfidence) except Exception as e: raise HTTPException(status_code500, detailf处理图片时发生错误: {str(e)}) app.get(/health) async def health_check(): 健康检查端点 return {status: healthy, service: GLM-OCR API} if __name__ __main__: # 启动服务监听内网的某个端口例如 7860 uvicorn.run(app, host0.0.0.0, port7860)这个服务启动后会在你服务器的7860端口提供一个OCR接口。你可以先在服务器本地用curl测试一下curl -X POST http://localhost:7860/v1/ocr \ -H accept: application/json \ -F file/path/to/your/test_image.jpg如果看到返回的JSON文本说明内网服务部署成功了。现在这个服务还只能在内网访问。3. 第二步使用内网穿透工具暴露服务到公网接下来我们要搭建那座“桥梁”。内网穿透工具有很多比如 frp、ngrok、花生壳等。这里我们以开源且灵活的frp为例因为它配置清晰对流量控制更精细。3.1 基本原理与架构简单来说你需要一台具有公网IP的服务器作为“中转站”frp服务端你的内网服务器作为“客户端”frp客户端。客户端主动连接到服务端建立一个安全隧道。当公网用户访问服务端的某个端口时流量会通过这个隧道转发到内网服务器的指定端口。公网用户 - [公网IP:端口] (frp服务端) -- 安全隧道 -- [内网IP:7860] (你的GLM-OCR服务)3.2 配置与部署 frp1. 在公网服务器服务端上从 frp 的 GitHub Release 页面下载对应系统版本的压缩包。解压后编辑frps.ini配置文件[common] bind_port 7000 # frp服务端监听端口客户端用来连接的端口 token your_secure_token_here # 认证令牌建议设置一个强密码 # 仪表板可选方便查看状态 dashboard_port 7500 dashboard_user admin dashboard_pwd another_secure_password启动服务端./frps -c ./frps.ini2. 在内网服务器客户端上同样下载并解压 frp。编辑frpc.ini配置文件[common] server_addr your_public_server_ip # 你的公网服务器IP地址 server_port 7000 # 与服务端 bind_port 一致 token your_secure_token_here # 必须与服务端设置的 token 一致 [glm-ocr-http] # 自定义一个服务名称 type tcp # 我们使用TCP转发 local_ip 127.0.0.1 local_port 7860 # 本地GLM-OCR服务监听的端口 remote_port 6000 # 在公网服务器上暴露的端口启动客户端./frpc -c ./frpc.ini配置完成后公网用户就可以通过访问http://你的公网服务器IP:6000/v1/ocr来调用你内网的GLM-OCR服务了。所有流量都经由你的公网服务器中转内网服务器的真实IP并未暴露。4. 第三步为公网访问添加一道安全锁服务暴露到公网后安全就成了头等大事。我们不能让任何人都能随意调用既浪费资源也不安全。这里介绍几种简单有效的加固方式。4.1 API密钥认证最简单有效在FastAPI服务中增加一个简单的API Key验证中间件。修改glm_ocr_server.pyfrom fastapi import FastAPI, File, UploadFile, HTTPException, Depends, Header # ... 其他导入 ... # 定义一个固定的API Key生产环境应从环境变量或配置中心读取 API_KEY YOUR_SECRET_API_KEY_HERE def verify_api_key(api_key: str Header(None, aliasX-API-Key)): if api_key ! API_KEY: raise HTTPException(status_code403, detail无效的API Key) return api_key app.post(/v1/ocr, response_modelOCRResponse) async def process_image( file: UploadFile File(...), request: OCRRequest None, api_key: str Depends(verify_api_key) # 添加依赖项 ): # ... 原有的处理逻辑不变 ...现在客户端在调用时必须在请求头中带上正确的API Keycurl -X POST http://公网IP:6000/v1/ocr \ -H X-API-Key: YOUR_SECRET_API_KEY_HERE \ -H accept: application/json \ -F filetest_image.jpg4.2 利用frp进行IP白名单限制如果你只希望特定的IP地址比如公司办公室出口IP能够访问可以在frp服务端配置中设置。修改服务端的frps.ini[common] bind_port 7000 token your_secure_token_here allow_ports 6000 # 只允许暴露6000端口 # 对特定代理设置白名单 [glm-ocr-http] type tcp local_ip 127.0.0.1 local_port 7860 remote_port 6000 allowed_ips 123.123.123.123, 124.124.124.0/24 # 允许的单个IP或IP段4.3 结合Nginx提供更高级防护可选在公网服务器上你可以在frp前面再部署一个Nginx实现更多功能HTTPS终止配置SSL证书提供加密的HTTPS访问。限流防止恶意高频调用。更复杂的访问控制基于路径、用户代理等的规则。一个简单的Nginx配置片段如下server { listen 443 ssl; server_name ocr.yourdomain.com; # 你的域名 ssl_certificate /path/to/your/cert.pem; ssl_certificate_key /path/to/your/key.pem; location / { # 将请求代理到frp服务端本地的6000端口frp将流量转发到内网 proxy_pass http://127.0.0.1:6000; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; # 可以在这里添加限速等配置 # limit_req zoneone burst10 nodelay; } }这样外部用户通过https://ocr.yourdomain.com/v1/ocr访问体验更好也更安全。5. 实际应用与效果这套方案在我们内部的一个文档处理流程中跑了小半年效果挺扎实。以前市场部的同事需要把活动海报上的嘉宾信息录入系统手动操作一张图得花两三分钟。现在他们直接用手机拍个照通过我们封装好的小程序上传几秒钟后结构化的文本就回来了直接导入后台准确率比之前用的通用OCR高不少。成本上一次性投入就是那台GPU服务器和一台低配的公网VPS用作frp服务端。对比之前按调用量付费的云服务在处理量上来之后几个月就回本了。更重要的是心里踏实所有的合同扫描件、内部资料图片都在自己机房不用担心数据泄露的风险。当然这个方案也不是没有缺点。你需要自己维护内网服务器的稳定性处理模型更新以及应对可能的网络波动。但对于那些对数据安全有要求、且有持续稳定OCR需求的企业来说这套组合拳的性价比和可控性是非常有吸引力的。6. 总结回过头看把GLM-OCR这类大模型通过内网穿透技术提供出去本质上是在“数据安全”、“成本控制”和“服务能力”之间找到了一个不错的平衡点。它不是什么颠覆性的新技术而是对现有工具的一种务实组合。整个搭建过程核心就三步在内网把模型服务跑起来、用frp这类工具开个安全的“通道”、最后别忘了给通道加把“锁”API认证或IP限制。技术门槛并不算高任何一个有基本运维能力的开发团队都能搞定。如果你也在为类似的问题寻找解决方案不妨先从一个小场景开始试试。比如先在内网部署好服务让内部系统用起来跑顺了再通过内网穿透开放给一两个 trusted 的外部应用。一步步来既能验证效果也能控制风险。毕竟适合自己的才是最好的方案。获取更多AI镜像想探索更多AI镜像和应用场景访问 CSDN星图镜像广场提供丰富的预置镜像覆盖大模型推理、图像生成、视频生成、模型微调等多个领域支持一键部署。
