SmallThinker-3B-Preview一键部署与GitHub源码管理联动实践最近在星图GPU平台上部署了SmallThinker-3B-Preview模型整个过程确实挺顺畅的一键部署的体验没得说。但用了一段时间后我发现了一个小麻烦每次想调整一下启动参数或者更新一下服务配置都得重新登录平台手动操作对于需要频繁迭代的团队项目来说效率有点跟不上。后来琢磨了一下能不能把模型服务的配置也像普通代码一样管起来比如用GitHub来托管配置脚本代码一更新服务就自动跟着重启部署。试了试还真行。今天就跟大家聊聊怎么在星图平台部署好SmallThinker-3B-Preview之后再给它接上GitHub这个“自动档”实现一套简单的持续集成与部署流程。1. 先完成模型的一键部署联动GitHub的前提是你得先把模型服务跑起来。这一步在星图平台上非常简单。1.1 找到并启动镜像登录星图GPU平台后在镜像广场直接搜索“SmallThinker-3B-Preview”。通常你会看到官方或社区维护的预置镜像选择那个标注了“一键部署”或者版本号最新的就行。点击部署后平台会让你配置一些基础资源比如选择GPU型号A10、V100这些、分配内存和硬盘空间。对于SmallThinker-3B-Preview这个体量的模型一般选择中等配置的GPU就足够流畅运行了。这些配置项都有清晰的说明按需选择即可。1.2 确认服务正常运行部署完成后平台会提供一个访问地址通常是一个URL。你点开这个链接应该能看到模型的Web交互界面或者一个简单的API测试页面。为了后续步骤顺利这里最好做个简单的连通性测试。你可以用curl命令或者直接在浏览器里访问一下健康检查接口如果镜像提供了的话。更直接的方法是按照镜像文档的示例发一个简单的推理请求试试。# 假设你的服务地址是 https://your-service.csdn.net # 用一个简单的测试请求看看服务是否正常响应 curl -X POST https://your-service.csdn.net/v1/completions \ -H Content-Type: application/json \ -d { prompt: 你好请介绍一下你自己。, max_tokens: 50 }如果返回了一段由模型生成的文本那就说明服务已经稳稳地跑起来了。记下这个服务的基础URL和端口号后面配置GitHub Actions时会用到。2. 准备托管到GitHub的配置与脚本现在服务是跑起来了但所有的配置都“活”在平台上。我们的目标是把这些控制服务的“开关”和“说明书”变成代码存到GitHub里。2.1 梳理需要托管的文件在你的本地电脑上新建一个项目文件夹比如叫smallthinker-deployment。在这个文件夹里我们主要准备以下几类文件服务启动脚本这是核心告诉平台如何启动你的模型服务。通常是一个Shell脚本比如start_server.sh或Python脚本。依赖文件列出服务运行需要的所有软件包比如requirements.txtPython或Dockerfile如果你需要自定义环境。配置文件模型加载的参数、服务监听的端口、超时设置等。可以是一个config.yaml或.env文件。GitHub Actions工作流文件这是实现自动化的“大脑”放在.github/workflows/目录下。2.2 编写核心启动脚本启动脚本的内容取决于你使用的镜像。你需要查看镜像的文档找到它启动服务的命令。下面是一个假设性的start_server.sh示例#!/bin/bash # start_server.sh # 激活Python环境如果你的镜像是Miniconda基础镜像 source /opt/conda/etc/profile.d/conda.sh conda activate your_env_name # 替换为你的环境名 # 设置模型路径和环境变量 export MODEL_PATH/app/models/smallthinker-3b-preview export PORT8080 # 启动模型服务 # 这里以使用FastAPI或类似框架为例具体命令请参考镜像文档 python -m uvicorn main:app --host 0.0.0.0 --port $PORT --workers 1关键点这个脚本里的命令必须和你在星图平台容器内手动启动服务的命令一致。你可以先通过平台的终端功能连接到容器看看服务是怎么启动的然后把命令抄下来。2.3 创建配置文件将可配置项抽离出来是个好习惯。创建一个config.yaml文件# config.yaml model: name: SmallThinker-3B-Preview path: /app/models/smallthinker-3b-preview precision: fp16 # 加载精度可以是fp16, int8等 server: host: 0.0.0.0 port: 8080 workers: 1 generation: max_tokens: 512 temperature: 0.7然后在你的启动脚本或主程序里读取这个配置文件。这样以后想改端口或者调整生成参数直接改这个YAML文件就行了不用动代码。3. 配置GitHub Actions实现自动部署文件都准备好后把它们推送到GitHub仓库。接下来就是重头戏配置GitHub Actions让代码更新能自动触发平台上的服务重启。3.1 理解工作原理星图GPU平台通常提供两种方式与外部联动API调用平台开放管理API允许你通过发送HTTP请求来重启、停止或更新服务。Webhook平台提供一个Webhook URL当GitHub有推送事件时GitHub会通知这个URL平台再执行预设动作。这里我们以更通用、更灵活的“GitHub Actions调用平台API”为例。3.2 创建GitHub Actions工作流文件在你的项目根目录下创建.github/workflows/redeploy.yml文件。# .github/workflows/redeploy.yml name: Redeploy SmallThinker Service on: push: branches: [ main ] # 当代码推送到main分支时触发 pull_request: branches: [ main ] # 当向main分支提交PR时触发可选用于测试 jobs: redeploy: runs-on: ubuntu-latest steps: - name: Checkout code uses: actions/checkoutv3 - name: Deploy to Star Atlas env: # 将这些敏感信息设置为GitHub仓库的Secrets STAR_ATLAS_API_KEY: ${{ secrets.STAR_ATLAS_API_KEY }} SERVICE_ID: ${{ secrets.STAR_ATLAS_SERVICE_ID }} ENDPOINT_URL: ${{ secrets.STAR_ATLAS_ENDPOINT }} run: | # 示例使用curl调用星图平台的重启API # 请根据星图平台API的实际文档修改URL和参数 curl -X POST \ $ENDPOINT_URL/api/v1/services/$SERVICE_ID/restart \ -H Authorization: Bearer $STAR_ATLAS_API_KEY \ -H Content-Type: application/json - name: Verify Deployment run: | # 等待几秒让服务重启 sleep 15 # 再次测试服务是否健康 curl -f ${{ secrets.SERVICE_HEALTH_URL }} || echo Service health check failed, but deployment triggered.3.3 配置GitHub Secrets上面脚本里的STAR_ATLAS_API_KEY、SERVICE_ID等都是敏感信息绝不能直接写在代码里。你需要去GitHub仓库设置里添加它们。进入你的GitHub仓库。点击Settings-Secrets and variables-Actions。点击New repository secret。分别添加STAR_ATLAS_API_KEY你在星图平台生成的API访问密钥。STAR_ATLAS_SERVICE_ID你部署的SmallThinker服务的唯一ID在平台的服务管理页面可以找到。STAR_ATLAS_ENDPOINT星图平台的API基础地址例如https://api.csdn.net。SERVICE_HEALTH_URL你的模型服务的健康检查地址例如https://your-service.csdn.net/health。配置好后GitHub Actions就能安全地使用这些信息去调用平台API了。4. 管理多版本部署配置当团队协作或者需要测试新功能时我们可能同时存在多个版本的服务配置比如开发版、测试版、生产版。用Git分支来管理这些配置非常方便。4.1 利用Git分支管理环境你可以建立不同的Git分支来对应不同的部署环境main分支对应生产环境。这里的配置是稳定版任何更新都会自动触发生产服务重启。develop分支对应开发/测试环境。开发者在这里提交新配置可以配置Actions在推送到develop时部署到另一个测试用的服务实例上。功能分支比如feat/new-config。可以为这类分支配置Actions在创建Pull Request时部署到一个临时的预览环境进行验证。4.2 为不同分支配置不同的Actions修改你的redeploy.yml使其能根据分支执行不同的部署逻辑。# 在原有基础上增加一个job或者修改触发条件和参数 name: Redeploy SmallThinker Service on: push: branches: [ main, develop ] # 监听多个分支 jobs: redeploy: runs-on: ubuntu-latest # 根据触发分支决定部署目标 strategy: matrix: branch-env: - { branch: main, service_id: ${{ secrets.PROD_SERVICE_ID }} } - { branch: develop, service_id: ${{ secrets.DEV_SERVICE_ID }} } include: - branch: main service_id: ${{ secrets.PROD_SERVICE_ID }} - branch: develop service_id: ${{ secrets.DEV_SERVICE_ID }} # 只运行与当前分支匹配的任务 if: github.ref refs/heads/${{ matrix.branch }} steps: - name: Checkout code uses: actions/checkoutv3 - name: Deploy to ${{ github.ref }} environment env: STAR_ATLAS_API_KEY: ${{ secrets.STAR_ATLAS_API_KEY }} SERVICE_ID: ${{ matrix.service_id }} # 使用动态的Service ID ENDPOINT_URL: ${{ secrets.STAR_ATLAS_ENDPOINT }} run: | echo Deploying to service: $SERVICE_ID # 调用重启API这里SERVICE_ID会根据分支变化 curl -X POST \ $ENDPOINT_URL/api/v1/services/$SERVICE_ID/restart \ -H Authorization: Bearer $STAR_ATLAS_API_KEY \ -H Content-Type: application/json这样推送到main分支会重启生产服务推送到develop分支则重启开发服务互不干扰。你需要在GitHub Secrets里分别配置PROD_SERVICE_ID和DEV_SERVICE_ID。5. 总结这么一套流程走下来你会发现管理AI模型服务变得清晰多了。所有的配置变更都有Git提交记录谁改了什么都一目了然。更重要的是实现了“配置即代码”和自动化部署省去了大量重复的手动操作。实际用的时候有几点小建议。首先星图平台的API具体用法一定要去查它的官方文档每个平台的接口设计可能略有不同。其次在Actions工作流里最好加入一些简单的测试步骤比如在重启服务前先跑一下配置文件的语法检查重启后加一个服务健康检查确保自动化流程真的成功了。刚开始可能会觉得配置这些有点繁琐但一旦跑通对于需要持续迭代的团队项目来说效率的提升是非常明显的。你可以先从最简单的“一键重启”开始慢慢再加入更复杂的流程比如自动构建自定义镜像、蓝绿部署等。希望这个思路能帮你把AI模型的部署和管理做得更顺手。获取更多AI镜像想探索更多AI镜像和应用场景访问 CSDN星图镜像广场提供丰富的预置镜像覆盖大模型推理、图像生成、视频生成、模型微调等多个领域支持一键部署。