Docker 多阶段构建与镜像瘦身实战
经验驱动 + 诚实声明。下面的 Dockerfile 按官方最佳实践编写,并做过 docker build --help 层面的语法自检;本机 Docker Desktop 引擎未启动(docker ps 报 npipe:////./pipe/dockerDesktopLinuxEngine 找不到),所以没有真跑 docker build。实际构建请先启动 Docker Desktop。 为什么要多阶段构建一个 Python 服务,如果在一个镜像里又装编译工具又装运行时,镜像会很大(1G+),传输慢、攻击面大。多阶段构建的核心是:用第一个阶段(builder)装编译依赖、跑构建,第二个阶段(runtime)只拷贝产物到一个精简基础镜像,最终镜像只有运行要的东西。 一个真实的多阶段 Dockerfile(Python)12345678910111213141516# ---- 阶段 1:构建 ----FROM python:3.12-slim AS builderWORKDIR /buildCOPY requirements.txt .# 只装进虚拟环境,方便整体拷贝RUN pyt ...
LLaMA-Factory 实战(二):环境搭建、WebUI 训练与模型导出合并全流程
LLaMA-Factory 实战(二):环境搭建、WebUI 训练与模型导出合并全流程 系列导航:(一)数据格式、模板选择与版本调试 —— 解决「样本被静默过滤」的问题;(二)本篇 —— 从零装好环境,用 WebUI 跑通训练,导出可部署的合并模型;(三)单卡后训练实战(SFT → DPO → GRPO 全链路)—— 用 TRL 把后训练三条路线走一遍。 一、环境搭建:版本组合是第一个坎LLaMA-Factory 对依赖版本极其敏感,我实测可用的组合(12GB 显存 + Qwen2.5-1.5B-Instruct + LoRA): 库 版本 说明 transformers 5.8.0 满足 LLaMA-Factory 要求(>=4.55, <=5.8) datasets 3.0.0 与 transformers 5.8.0 兼容 pandas 2.3.3 解决 gradio 依赖冲突 1pip install "transformers==5.8.0" "datasets==3.0.0" "pand ...
ComfyUI API 模式:把工作流变成可调用服务
经验驱动 + 诚实声明。下面的最小 Python 客户端按 ComfyUI 官方 API 规范编写,并用 python -m py_compile 做过语法校验;本机 ComfyUI 监听 8799,但探测 /system_stats 返回 502(经代理/未就绪),所以没有真提交一次任务。真跑只需先导出一份 API 格式工作流 JSON。 为什么要 API 模式ComfyUI 默认是网页拖节点,但当你要批量出图、接入自己的业务、或者包成服务时,就得走 API 模式:把节点图导出成 JSON,用代码提交、轮询、取结果。本质是把”鼠标点的工作流”变成”可编程的服务”。 核心端点 端点 方法 作用 /prompt POST 提交 workflow(API 格式 JSON),返回 prompt_id /history/{prompt_id} GET 轮询任务状态与 outputs /view GET 按 filename/subfolder/type 下载生成的图片 /ws WS 实时收进度事件(可选) 最小可调用客户端(真实代码)12345 ...
🧩 LLaMA-Factory 实战(一):数据格式、模板选择与版本调试(Qwen2.5 + LoRA 实战)
🧩 微调经验总结:数据格式、模板选择与版本调试(Qwen2.5 + LoRA 实战)📝 前言本次模拟训练以 Qwen2.5-1.5B-Instruct + LoRA 在 LLaMA-Factory 框架下进行,成功完成了 Kubernetes 领域问答微调。训练中遇到了数据格式不匹配、环境版本冲突等问题,最终通过使用 ShareGPT 格式 + qwen 模板 以及正确的版本组合解决了所有障碍。 本文对微调过程中的核心经验进行系统总结,重点厘清 Alpaca 与 ShareGPT 两种主流数据格式与模板的对应关系,并给出经过验证的训练配置,帮助读者在类似任务中少走弯路。 🧭 全文核心结论速览 关键点 结论 数据格式与模板 ShareGPT + qwen 是最稳定组合;Alpaca + chatml/qwen 易导致样本过滤 版本环境 transformers==5.8.0、datasets==3.0.0、pandas==2.3.3 实测通过 训练参数 12G 显存 + 1.5B 模型,LoRA rank=8,cutoff_len=1024,epochs=3 ...
剪映自动化实战:用 Python API 批量剪辑视频
剪映自动化实战:用 Python API 批量剪辑视频一、为什么要自动化剪映剪映是当下最好用的国产剪辑工具,但它的 GUI 是为「手动剪一条」设计的。当你需要批量产出(短剧每集十几条素材、课程视频几十个切片、模板化客户交付),手动点鼠标就成了瓶颈。 JyWrapper 这套封装把剪映的核心操作暴露成 Python API:建工程、导素材、加字幕、TTS 配音、关键帧动画、特效、录屏、导出——全部脚本化。这篇文章讲它的实战用法和那些「文档不写但必踩」的坑。 二、架构:操作的是草稿文件,不是 GUI剪映 v5.9+ 的工程是一个 draft_info.json 文件夹。JyWrapper 的本质是直接读写这个 JSON——不模拟点击、不依赖界面,所以: 剪映不用开着也能操作(导出除外); 批量操作就是批量改 JSON,速度是 GUI 的几百倍; 可以版本控制、可以 diff、可以回滚。 代价是要摸清 JSON schema。好消息是封装层已经处理了。 三、核心能力清单 能力 API / 脚本 建工程(支持自修复) JyProject("名字", overw ...
GitHub Actions 自动部署 Hexo 到 Pages
经验驱动。这个博客就是用这套 Actions 自动部署的。下面是一份真实可用的 workflow,并经过 YAML 语法校验。每次 git push 到 main,GitHub 自动装 Node、生成静态页、发布到 Pages——本地再也不用手动 hexo d。 为什么上 Actions手动部署流程是:本地 hexo clean && hexo g && hexo d,要装环境、要配 token、容易忘。放到 GitHub Actions 后,push 即发布,环境一致、可追溯、还能白嫖 GitHub 的机器跑构建。 真实 workflow(.github/workflows/deploy.yml)1234567891011121314151617181920212223242526272829303132333435name: Deploy Hexo to Pageson: push: branches: [main] workflow_dispatch:permissions: contents: read pages: write ...
VS Code 系编辑器三件套:汉化、代理与第三方模型接入排障
VS Code 系编辑器三件套:汉化、代理与第三方模型接入排障一、先说共性:编辑器的坑全是「不报错但不对」Cursor、Trae、Windsurf、VSCodium 这些 VS Code 系编辑器,配置上的坑有一个共同点:静默失败。汉化装了没生效、模型接了不生效、代理设了没用——全程没有任何报错,全靠你自己悟。这篇把三件事的排障一次讲清。 二、汉化:版本不匹配会被静默跳过汉化的铁律:语言包引擎要求的 VS Code 版本,必须被编辑器的内置版本满足,否则语言包被静默跳过——界面不变中文,没有任何提示。 所以第一步不是下载语言包,是取编辑器内置的 VS Code 版本: 12(Get-Content '<安装目录>\resources\app\product.json' -Raw | ConvertFrom-Json).vscodeVersion# 例:Cursor 3.21.13 -> vscodeVersion = 1.128.0 然后挑语言包:版本号前缀要匹配。1.128.2026071013 的 engines.vscode 是 ^1.12 ...
我的技术学习方法论:从踩坑到体系
经验驱动。这不是一篇”如何 21 天学会 Python”的鸡汤,而是我自己从踩坑里长出来的学习框架:怎么把零散的知识点连成能讲出口的体系,以及它怎么反哺我的博客和面试。 三个阶段的跃迁我把自己学一项技术的路径分成三段: 抄(Copy):照着官方文档/别人的教程跑通。目标不是懂,是”能跑”。这个阶段允许不懂,但必须原样复现。 改(Modify):在跑通的基础上改参数、换输入、故意搞坏看报错。目标是从”它为什么这样”里抠出原理。这一步最容易被跳过,却最关键——大多数人停在”抄”就以为学会了。 创(Create):用这项技术解决一个自己真实遇到的问题,并写下来。目标是从”会用”到”能讲”。 这个博客本身就是”创”阶段的产物:每一篇都是我把某个踩坑点写成文章,强迫自己把逻辑理顺。写不出来的地方,就是我还不懂的地方。 怎么把知识变成体系零散的知识点像一盘散沙,体系化靠三件事: 写下来:费曼技巧的变体。能写成一篇别人看得懂的文章,才算真懂。我博客里的”排障向”长文,都是这个过程的副产品。 连成网:每个新知识都问一句”它和我已知的哪块有关”。比如学到 ONNX,我会把它挂到”模型部署提速” ...
RAGFlow 实战(四):REST API 自动化——知识库管理、检索测试与问答脚本
RAGFlow 实战(四):REST API 自动化——知识库管理、检索测试与问答脚本 系列导航:(一)部署、鉴权与排障;(二)文档解析实战;(三)检索调参实录;(四)本篇。 一、为什么要走 APIWeb 界面适合探索,但下面这些场景必须脚本化: 批量上传:几百篇文档逐个点页面不现实; 检索回归测试:改切片参数/换 embedding 后,用固定问题集跑一遍,量化对比; 接入业务系统:知识库问答能力嵌进自己的应用; 运维巡检:定时检查文档解析状态、索引完整性。 RAGFlow 从 0.27 开始提供了新版 REST API(/api/v1/),覆盖知识库、文档、切片、检索、会话全链路。这篇给一套可直接改的 Python 客户端。 二、鉴权:先解决登录新版 API 用 Bearer Token。两种拿法: 方式一:账号密码登录换 token 12345678910111213141516import requestsBASE = "http://127.0.0.1:9380" # 按你的部署改def login(email: str, password: st ...
公众号自动排版与多平台分发
经验驱动。公众号编辑器是个”挑食”的编辑器——它会剥离 <style> 块和 class 属性,只保留内联 style。所以自动排版的核心就是:把 Markdown 转成全部内联样式的 HTML。我写了个纯标准库的转换器,下面附真实输出。 为什么要自动排版手写公众号排版很痛苦:标题字号、正文行高、代码块底色、引用左边框,每篇都要点一遍。而且博客文章(Markdown)想同步到公众号,直接粘贴会丢样式。自动排版 = 一份 Markdown,自动产出”公众号能直接粘”的内联样式 HTML。 关键认知:公众号只认内联样式这是最大的坑。你辛辛苦苦写的 <style>... .h1{...}</style> 粘进公众号编辑器会被整段删掉,class 也失效。唯一能活下来的就是写在标签上的 style="..."。所以转换器必须从一开始就把样式内联到每个标签。 真跑:转换器输出(纯标准库,已执行)输入一段 Markdown,转换器输出如下内联样式 HTML(节选): 12345<section style=&qu ...
avatar
HYRX-TG
运维工程师 | AI算法学习者 | 热爱写作与技术分享
关注 河岳日星的 GitHub
公告
欢迎来到河岳日星的博客,记录技术与成长
最新文章
网站资讯
文章数目 :
122
已运行时间 :
本站总字数 :
171.6k
本站访客数 :
本站总访问量 :
最后更新时间 :
一言
:D 获取中...
:D 获取中...