企业官网建设流程全解析

Ostrakon-VL-8B一键部署与MySQL数据持久化实战

最近在折腾多模态大模型，发现Ostrakon-VL-8B这个模型挺有意思的，既能看懂图片，又能跟你聊天，还能根据图片生成描述。不过，用着用着就发现一个问题：每次调用产生的数据，比如用户上传了哪些图片、生成了什么文本、什么时候调用的，这些信息都丢了，想回头分析一下使用情况都无从下手。

这就像开了一家店，每天顾客来来往往，买了什么、什么时候来的，你都不记账，那还怎么优化经营呢？所以，我就琢磨着给这个模型服务加个“记账本”——用MySQL数据库把每次调用的关键信息都存下来。

今天这篇文章，我就手把手带你走一遍完整的流程：从把Ostrakon-VL-8B模型跑起来，到设计数据库表，再到把数据库操作集成到模型服务里，最后实现一个简单的日志查看功能。整个过程我会尽量讲得明白，哪怕你之前没怎么接触过数据库或者Web服务开发，跟着做也能搞定。

1. 环境准备与模型一键部署

咱们先从最基础的开始，把模型服务搭起来。这里我推荐用Docker，它能帮你省去很多配置环境的麻烦。

1.1 准备工作

首先，确保你的机器上已经装好了Docker和Docker Compose。打开终端，运行下面的命令检查一下：

docker --version docker-compose --version

如果都能正常显示版本号，那就没问题。如果还没装，可以去Docker官网找对应系统的安装教程，步骤很清晰。

接下来，创建一个项目文件夹，所有相关的文件都会放在这里。

mkdir ostrakon-mysql-demo && cd ostrakon-mysql-demo

1.2 编写Docker部署文件

在项目根目录下，创建一个名为docker-compose.yml的文件。这个文件会定义两个服务：一个跑我们的Ostrakon模型，另一个跑MySQL数据库。

version: '3.8' services: # Ostrakon-VL-8B 模型服务 ostrakon-api: image: registry.cn-hangzhou.aliyuncs.com/model_serving/ostrakon-vl-8b:latest container_name: ostrakon-vl-service ports: - "7860:7860" # 将容器的7860端口映射到主机的7860端口 environment: - MODEL_NAME=ostrakon-vl-8b volumes: - ./model_data:/app/model_data # 可选：挂载卷，用于持久化模型数据 restart: unless-stopped depends_on: - mysql-db networks: - app-network # MySQL 数据库服务 mysql-db: image: mysql:8.0 container_name: mysql-for-ostrakon restart: always environment: MYSQL_ROOT_PASSWORD: your_strong_password_here # 务必修改成一个强密码！ MYSQL_DATABASE: ostrakon_logs ports: - "3306:3306" # 将MySQL的3306端口映射到主机，方便用工具连接 volumes: - mysql_data:/var/lib/mysql # 持久化数据库数据 - ./init.sql:/docker-entrypoint-initdb.d/init.sql # 初始化SQL脚本 networks: - app-network # 定义网络和卷 networks: app-network: driver: bridge volumes: mysql_data:

注意上面代码里的your_strong_password_here，你一定要把它换成自己设定的、足够复杂的密码。

1.3 初始化数据库表结构

我们还需要一个SQL文件，在MySQL容器第一次启动时，自动创建我们需要的数据库表。在项目根目录创建init.sql文件：

-- 创建用于存储调用日志的数据库（如果环境变量已创建，这里也会执行） USE ostrakon_logs; -- 创建调用日志表 CREATE TABLE IF NOT EXISTS inference_logs ( id INT AUTO_INCREMENT PRIMARY KEY, session_id VARCHAR(255) NOT NULL COMMENT '会话标识，可用于追踪同一用户多次交互', image_hash VARCHAR(64) COMMENT '上传图片的哈希值，用于去重和追踪', user_query TEXT NOT NULL COMMENT '用户输入的文本问题', model_response TEXT NOT NULL COMMENT '模型生成的回答文本', input_image_path VARCHAR(500) COMMENT '服务器上存储的输入图片路径（可选）', created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP COMMENT '记录创建时间' ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci COMMENT='Ostrakon模型调用日志表'; -- 创建索引以加速查询 CREATE INDEX idx_session_id ON inference_logs(session_id); CREATE INDEX idx_created_at ON inference_logs(created_at); CREATE INDEX idx_image_hash ON inference_logs(image_hash);

这个表结构比较简单，主要记录了每次调用的核心信息。session_id可以用来区分不同用户或会话；image_hash是图片的“指纹”，同样的图片哈希值相同，方便我们分析哪些图片被频繁使用。

1.4 启动所有服务

现在，回到终端，在项目根目录下运行一条命令，就能把模型和数据库都拉起来：

docker-compose up -d

-d参数是让服务在后台运行。第一次运行会下载镜像，可能需要几分钟，喝杯咖啡等等就好。

运行成功后，你可以用下面命令查看服务状态：

docker-compose ps

如果看到两个服务的状态都是Up，那就成功了。现在，打开你的浏览器，访问http://你的服务器IP:7860，应该就能看到Ostrakon-VL-8B的Web交互界面了。同时，一个名为ostrakon_logs的数据库和inference_logs表也已经准备就绪。

2. 改造模型服务：集成数据库操作

模型服务跑起来了，数据库也建好了，但它们是两个独立的容器，现在需要让它们“说上话”。我们需要修改模型服务的代码，让它每次处理完用户请求后，能自动把日志存到MySQL里。

通常，这类模型服务的API是基于FastAPI或类似框架构建的。我们需要找到处理图片和文本对话的那个接口（一般是/v1/chat/completions或类似路径），然后在接口逻辑里插入数据库操作的代码。

由于我们无法直接修改原始镜像里的代码，一个更实际的做法是创建一个“包装器”服务，或者如果模型服务提供了自定义插件的机制，就利用它。这里我假设我们能够通过环境变量或配置文件挂载自定义代码。

2.1 创建数据库操作模块

在项目根目录下，创建一个database文件夹，里面放我们的数据库连接和操作代码。

首先，创建database/connection.py：

# database/connection.py from sqlalchemy import create_engine from sqlalchemy.ext.declarative import declarative_base from sqlalchemy.orm import sessionmaker import os # 从环境变量读取数据库连接信息，安全且灵活 DB_HOST = os.getenv("DB_HOST", "mysql-db") # Docker Compose中的服务名 DB_PORT = os.getenv("DB_PORT", "3306") DB_USER = os.getenv("DB_USER", "root") DB_PASSWORD = os.getenv("DB_PASSWORD", "your_strong_password_here") # 务必修改！ DB_NAME = os.getenv("DB_NAME", "ostrakon_logs") # 构建数据库连接URL SQLALCHEMY_DATABASE_URL = f"mysql+pymysql://{DB_USER}:{DB_PASSWORD}@{DB_HOST}:{DB_PORT}/{DB_NAME}" # 创建数据库引擎 engine = create_engine( SQLALCHEMY_DATABASE_URL, pool_pre_ping=True, # 防止连接超时断开 echo=False # 设为True可以在控制台看到所有SQL语句，调试时有用 ) # 创建会话工厂 SessionLocal = sessionmaker(autocommit=False, autoflush=False, bind=engine) # 声明基类，用于定义数据模型（表结构） Base = declarative_base() # 依赖项，用于在FastAPI路由中获取数据库会话 def get_db(): db = SessionLocal() try: yield db finally: db.close()

接着，创建数据模型，对应我们之前设计的表。创建database/models.py：

# database/models.py from sqlalchemy import Column, Integer, String, Text, TIMESTAMP from sqlalchemy.sql import func from .connection import Base class InferenceLog(Base): __tablename__ = "inference_logs" id = Column(Integer, primary_key=True, index=True, autoincrement=True) session_id = Column(String(255), nullable=False, index=True) image_hash = Column(String(64), index=True, nullable=True) # 允许为空，因为可能只有文本对话 user_query = Column(Text, nullable=False) model_response = Column(Text, nullable=False) input_image_path = Column(String(500), nullable=True) created_at = Column(TIMESTAMP, server_default=func.now(), index=True) # 默认使用数据库服务器时间

然后，创建数据库操作的“仓库”类，封装增删改查逻辑。创建database/repository.py：

# database/repository.py from sqlalchemy.orm import Session from .models import InferenceLog import hashlib from typing import Optional class LogRepository: def __init__(self, db: Session): self.db = db def create_log( self, session_id: str, user_query: str, model_response: str, image_hash: Optional[str] = None, image_path: Optional[str] = None ) -> InferenceLog: """创建一条新的推理日志记录""" db_log = InferenceLog( session_id=session_id, image_hash=image_hash, user_query=user_query, model_response=model_response, input_image_path=image_path ) self.db.add(db_log) self.db.commit() self.db.refresh(db_log) # 刷新以获取数据库生成的id和created_at return db_log def get_logs_by_session(self, session_id: str, limit: int = 100): """根据会话ID查询最近的日志""" return self.db.query(InferenceLog)\ .filter(InferenceLog.session_id == session_id)\ .order_by(InferenceLog.created_at.desc())\ .limit(limit)\ .all() def get_recent_logs(self, limit: int = 50): """获取最近的调用日志，用于监控""" return self.db.query(InferenceLog)\ .order_by(InferenceLog.created_at.desc())\ .limit(limit)\ .all() # 一个简单的工具函数，用于计算图片的MD5哈希（用于image_hash字段） def compute_image_hash(image_bytes: bytes) -> str: """计算图片字节流的MD5哈希值""" return hashlib.md5(image_bytes).hexdigest()

2.2 修改模型服务API（概念示例）

现在，我们需要修改模型服务本身的API处理逻辑。由于我们无法直接提供修改Ostrakon官方镜像的代码，这里给出一个概念性的示例，说明如何在你的自定义API路由中集成上述模块。

假设你有一个FastAPI应用，提供了/chat接口来处理Ostrakon的调用。改造后的主要逻辑如下：

1. 接收用户上传的图片和文本问题。
2. 调用底层的Ostrakon模型获取回答。
3. 计算图片哈希，构造日志数据。
4. 通过LogRepository将日志存入数据库。
5. 将模型回答返回给用户。

关键点在于，数据库插入操作不应该阻塞主要的推理请求。我们可以使用后台任务，比如FastAPI的BackgroundTasks，让日志写入在响应返回后异步执行，这样就不会增加用户的等待时间。

# 假设这是你自定义的API服务文件 app/main.py 的一部分 from fastapi import FastAPI, File, UploadFile, Form, BackgroundTasks, Depends from sqlalchemy.orm import Session import your_ostrakon_client_module as model_client # 假设的模型调用客户端 from database.connection import get_db from database.repository import LogRepository, compute_image_hash import uuid app = FastAPI() def save_inference_log( db: Session, session_id: str, user_query: str, model_response: str, image_bytes: bytes = None, image_path: str = None ): """后台任务：保存日志到数据库""" image_hash = compute_image_hash(image_bytes) if image_bytes else None repo = LogRepository(db) repo.create_log(session_id, user_query, model_response, image_hash, image_path) print(f"Log saved for session: {session_id}") @app.post("/v1/chat-with-logging") async def chat_with_logging( background_tasks: BackgroundTasks, file: UploadFile = File(None), question: str = Form(...), session_id: str = Form(default_factory=lambda: str(uuid.uuid4())), # 生成或接收会话ID db: Session = Depends(get_db) ): """ 支持图片和文本输入的聊天接口，并自动记录日志。 """ image_bytes = None image_path_in_server = None # 1. 处理上传的图片（如果有） if file and file.filename: # 这里简化处理，实际可能需要保存到文件系统或对象存储 image_bytes = await file.read() # 可以在这里将图片保存到服务器特定路径，并记录路径 # image_path_in_server = save_image_to_disk(image_bytes, file.filename) # 2. 调用Ostrakon模型（这里需要你根据实际SDK调整） # 假设 model_client.chat 接受图片字节和文本，返回回答 model_response = await model_client.chat(image=image_bytes, question=question) # 3. 添加后台任务，异步保存日志（不阻塞响应） background_tasks.add_task( save_inference_log, db, session_id, question, model_response, image_bytes, image_path_in_server ) # 4. 返回模型响应给前端 return { "session_id": session_id, "answer": model_response, "message": "Log will be saved in background." }

这样，我们就完成了模型服务与数据库的集成。每次调用/v1/chat-with-logging接口，都会在后台静默地生成一条日志记录。

3. 实现简单的日志管理与数据分析

数据存进去了，总不能只在数据库里躺着。我们至少需要一个简单的方法来看看这些数据。我们可以再写一个简单的管理API，或者直接连上数据库用SQL查。这里，我们快速实现一个最基础的FastAPI路由，用来查看最近的调用日志。

3.1 创建日志查询API

在刚才的FastAPI应用里，我们再添加一个只读的管理员端点。注意：这个端点在生产环境一定要加权限验证！

# 继续在 app/main.py 中添加 from fastapi import HTTPException from pydantic import BaseModel from typing import List class LogItem(BaseModel): """返回给前端的日志数据模型""" id: int session_id: str image_hash: Optional[str] user_query: str model_response: str created_at: str class Config: from_attributes = True # 支持从ORM对象直接转换 @app.get("/admin/recent-logs", response_model=List[LogItem]) def get_recent_logs(limit: int = 20, db: Session = Depends(get_db)): """获取最近的调用日志（管理员功能）""" # 在实际项目中，这里必须添加身份验证（如JWT、API Key） # if not is_admin(request): raise HTTPException(status_code=403) repo = LogRepository(db) logs = repo.get_recent_logs(limit=limit) return logs @app.get("/admin/logs-by-session/{session_id}", response_model=List[LogItem]) def get_logs_by_session(session_id: str, limit: int = 100, db: Session = Depends(get_db)): """根据会话ID查询日志""" repo = LogRepository(db) logs = repo.get_logs_by_session(session_id, limit=limit) if not logs: raise HTTPException(status_code=404, detail="No logs found for this session") return logs

启动这个改造后的API服务（需要你将其与模型服务对接或独立部署），访问http://你的服务地址:端口/admin/recent-logs，就能以JSON格式看到最近的调用记录了。

3.2 直接使用SQL进行初步分析

有时候，直接写SQL查询更灵活。这里给你几个可能有用的查询例子，你可以在MySQL命令行客户端或者像DBeaver、Navicat这样的图形化工具里执行。

查询今天最活跃的会话（用户）：

SELECT session_id, COUNT(*) as call_count FROM inference_logs WHERE DATE(created_at) = CURDATE() GROUP BY session_id ORDER BY call_count DESC LIMIT 10;

查询最常被问及的问题（去重后）：

SELECT user_query, COUNT(*) as frequency FROM inference_logs GROUP BY user_query ORDER BY frequency DESC LIMIT 20;

查询携带图片的请求占比：

SELECT COUNT(*) as total_requests, COUNT(image_hash) as requests_with_image, ROUND((COUNT(image_hash) / COUNT(*)) * 100, 2) as image_ratio_percent FROM inference_logs;

通过这些简单的分析，你就能对模型的使用模式有个直观的了解，比如用户更喜欢问什么问题、图片功能的使用频率如何，这对于后续优化服务或设计功能都很有帮助。

4. 总结与后续建议

走完这一整套流程，我们不仅成功部署了Ostrakon-VL-8B模型，还给它装上了“记忆系统”。现在，每一次图片对话、每一次文本生成，都会被清晰地记录下来。这不仅仅是简单的数据存储，它为你打开了几扇门：

首先，问题追踪和调试变得容易了。当用户反馈“上次我问某个图片的问题，答案不太对”时，你可以通过session_id或image_hash快速定位到当时的完整交互记录，复现问题。

其次，你拥有了分析用户行为的基础数据。哪些功能最受欢迎？用户通常在什么时间段使用？他们倾向于上传什么类型的图片？这些数据都能从日志中挖掘出来，成为你迭代产品、优化模型服务方向的重要依据。

再者，这为更高级的功能铺平了道路。比如，基于历史对话实现多轮上下文记忆；对高频提问进行缓存以提升响应速度；甚至利用积累的（用户）数据对模型进行微调，让它更贴合你的特定场景。

当然，这套基础方案还有很大的优化空间。比如，日志量大了之后，可以考虑按时间分表；图片存储最好用对象存储服务而非本地磁盘；管理API必须加上严格的权限控制；对于超高并发场景，数据库写入可能成为瓶颈，那时可能需要引入消息队列进行异步削峰填谷。

如果你刚开始接触，按照本文的步骤做下来，已经能搭建一个可用的、带数据持久化的多模态AI服务原型了。建议你先在测试环境跑通，理解每个环节的作用，然后再根据你的实际业务需求，一步步去强化它。技术的乐趣就在于，用一个简单的起点，可以延伸出无数种可能。

获取更多AI镜像

想探索更多AI镜像和应用场景？访问 CSDN星图镜像广场，提供丰富的预置镜像，覆盖大模型推理、图像生成、视频生成、模型微调等多个领域，支持一键部署。