7B模型LoRA微调显存压至16G：Qwen2.5指令遵循提升42%
用一张RTX 4090对Qwen2.5-7B-Instruct做LoRA微调，处理一个客服意图识别+槽位填充的混合任务。经过96小时训练（batch size 128，学习率2e-4），在500条测试集上意图准确率从78.3%提升到91.2%，槽位F1从0.71提升到0.88。同时尝试了QLoRA（4bit NF4量化），训练显存从24G降到14.5G，推理速度仅下降12%。本文记录完整的数据准备
asyncio重构Flask API：请求耗时从380ms降至47ms
某个周末，我负责的订单查询接口在压测时P99延迟飙到1.2秒，数据库连接池被占满，CPU却只有30%利用率。排查后发现罪魁祸首是串行调用三个上游HTTP服务——每个耗时120ms，加起来360ms，加上业务逻辑正好380ms。我用asyncio+httpx重写了这个接口，配合信号量控制并发，P99降到47ms，QPS从80提升到620。本文记录完整的重构过程、代码对比、踩坑经历（包括协程泄漏和Ev
Milvus与Qdrant实测：亿级向量检索资源消耗与延迟对比
在电商图搜业务中，我们对Milvus 2.4.1与Qdrant 1.9.2进行了为期两周的对比测试。使用4096维图像特征向量，1000万条数据规模，在同等资源（8C32G）下，Qdrant的RPS达到3200，P99延迟12ms，而Milvus的RPS为2100，P99延迟19ms。但Milvus在冷数据导入和批量删除场景下表现更优。本文记录了完整的部署参数、性能调优过程和踩坑记录，供选型参考。
FastAPI/Flask压测对比与PySpy定位慢查询的缓存优化记录
某电商订单接口在QPS 200时P99延迟飙至1.8s，通过PySpy现场抓栈确认瓶颈为N+1查询与模板渲染。用SQLAlchemy 2.0的selectinload替代lazy load，配合Redis二级缓存与gzip中间件，最终在wrk压测下QPS从412提升至3200，P99降至87ms。本文记录Flask迁移FastAPI时的性能差异，并给出可直接复用的profiling脚本。
asyncio重构Flask接口，QPS提升3.2倍与CPU占用降40%
一个电商订单导出接口，单次请求耗时3.8秒，并发20时CPU直接飙到85%。用asyncio+httpx重写后，单次耗时降到1.1秒，QPS从32涨到103，CPU稳定在45%左右。本文记录了完整的优化过程：从同步阻塞的requests调用，到异步非阻塞的httpx client，再到信号量控制并发上限，最后用aiofiles做异步文件写入。中间踩了三个坑——协程泄漏、事件循环阻塞、以及async
FastAPI异步改造与Redis缓存：记一次API响应从2.1s到180ms的调优
生产环境某报表接口在300并发下P95延迟飙至2.1s，CPU空闲但数据库连接池被打满。本文记录一次完整的FastAPI性能调优过程：使用py-spy定位GIL锁竞争，通过SQLAlchemy 2.0的`selectinload`消除N+1查询，引入Redis二级缓存并设计缓存击穿保护，最终将P95延迟降至180ms，吞吐量提升4.7倍。文中包含完整的profiling命令、优化前后代码对比及wr
7B模型LoRA微调显存爆炸？QLoRA+4bit量化训练全记录
上周用单张RTX 4090微调Qwen2-7B-Instruct做法律文书抽取，直接全参微调显存爆到24G不够用。改用LoRA后显存降到14G，但训练速度慢得离谱。最后换上QLoRA+4bit NF4量化，显存峰值11.2G，训练速度提升2.3倍，F1从0.82涨到0.87。本文记录完整调参过程，包括torch 2.1.2 + transformers 4.38.1 + peft 0.9.0的版本
React 19与Vue 3.5项目从Props drilling到Zustand/Pinia的迁移实录
在三个中大型项目（React 18+TS、Vue 3.4+setup语法）中，我将跨层级状态从多层Props/Context/Provide-inject迁移至Zustand 4.5与Pinia 2.1。迁移后，组件重渲染次数平均减少63%（React）与58%（Vue），代码行数缩减40%以上。本文记录方案选型对比、分步迁移策略、以及我在React 19 RC环境下遇到的Concurrent渲染
Docker Compose编排三层应用：网络隔离与健康检查的落地实践
生产环境迁移容器化时，我在一个Spring Boot + Redis + MySQL + Nginx的四服务项目上踩遍Compose编排的坑——从卷挂载权限到服务启动竞态，再到健康检查失效导致流量打到未就绪节点。本文基于Docker Compose v2.24 + Docker Engine 24.0，分享一套包含自定义网络、命名卷、显式依赖和健康门控的编排方案。配置后，服务启动耗时从原先的35秒
asyncio重构Flask接口：QPS翻3倍与线程池的取舍实录
一次真实的Web API性能优化：某用户列表接口在QPS 200时P99延迟飙到1.2秒，CPU和内存双双告急。通过引入asyncio + httpx并发调用下游服务，将同步阻塞的requests改为异步IO，QPS从185提升至620，P99从980ms降至210ms，内存占用下降40%。本文记录完整的重构过程，包括asyncio.Semaphore限流、aiohttp连接池复用、以及async
Prompt工程化调优实录：基于GPT-4o的SQL生成任务token成本削减43%
用GPT-4o做自然语言转SQL，基线prompt的准确率仅67%，且单次查询平均消耗1820 tokens。经过五轮结构化迭代（角色注入、few-shot示例、格式约束、自校验链），最终将准确率提升至91%，token消耗降至1040 tokens，响应时间缩短38%。文中记录了完整的实验对比数据、踩坑过程与可复用的Prompt模板，并附上基于OpenAI SDK的自动化评测代码。
FastAPI接口耗时560ms降至40ms：profiling与缓存优化全记录
一个内部报表接口，单次请求平均耗时560ms，QPS峰值只有12，被业务方投诉“打开报表转圈10秒”。本文记录完整调优过程：通过cProfile与py-spy定位瓶颈，发现N+1查询与重复计算是主因；随后引入SQLAlchemy 2.0的`selectinload`消除N+1，并用Redis缓存热点数据，最终将P95耗时从560ms降至40ms，QPS提升至480。文章包含具体版本号、火焰图分析、
用asyncio重构Flask API：并发查询从2.1s降到0.3s的完整记录
在压测一个基于Flask+Requests的聚合查询接口时，发现当上游三个微服务响应分别为800ms、600ms、700ms时，接口总耗时高达2.1秒——因为代码是串行调用。本文记录用asyncio+httpx替代Requests的完整改造过程，包含before/after代码、asyncio.run与gather的正确用法、以及一个容易踩的loop闭包陷阱。改造后接口P95从2.1s降至0.31
RAG召回率从61%到89%：chunk重构、Embedding选型与Rerank排错全记录
线上问答系统在迁移到新知识库后，召回率骤降至61%，Top-20命中率不足七成。本文记录了完整的RAG调优链路：从固定256字chunk改为按Markdown标题与段落语义切分，将bge-large-zh替换为bge-m3（支持多向量与长文本）；随后引入bge-reranker-v2-m3做两阶段重排，并修复了混合检索权重错误。最终在自建500道评测集上，Hit@5从61.3%提升至89.2%，平
7B模型LoRA/QLoRA微调全记录：从数据准备到效果对比
上周我接手一个领域问答项目，需要把Llama-3-8B微调成法律咨询助手。单卡A100（80G）跑全量微调显存不够，用QLoRA 4bit量化后显存峰值压到21G，训练6小时loss从2.1降到0.87。本文记录完整流程：数据清洗、LoRA rank=16/alpha=32配置、loss曲线分析，以及微调前后对同一法律问题的回答对比。踩了三个坑：中文分词器截断导致loss不降、样本重复导致过拟合、
React 19与Vue 3.5跨框架状态管理迁移：从Context/Props到Zustand与Pinia的工程实践
本文记录了一次真实的中型后台项目（React 18 + Vue 3.4）从Props/Context模式向Zustand 4.5与Pinia 2.1迁移的完整过程。项目包含42个页面组件、186个状态字段，迁移后首屏渲染时间从2.3s降至1.1s，重渲染次数减少62%，代码量缩减34%。文章对比了两种方案在跨组件通信、异步状态处理、DevTools调试上的差异，并给出了可直接复用的迁移步骤与性能优
FastAPI接口耗时3287ms降至89ms：Profiler定位与三层缓存改造实录
一个内部报表API在QPS 50时P95延迟飙至3.2秒，数据库CPU被打满。本文记录使用py-spy、cProfile和慢查询日志定位瓶颈的全过程：发现N+1查询和重复计算是元凶，随后通过SQLAlchemy 2.0的selectinload优化关联加载、引入Redis 7.0二级缓存和LRU本地缓存，最终将P95延迟从3287ms降至89ms，DB CPU占用从97%降至12%。文中含完整代码
asyncio重构Flask接口：请求耗时从3.2秒降至0.4秒的完整记录
上周我们线上一个数据聚合接口单次请求平均耗时3.2秒，高峰期直接拖垮了四台4核8G的云主机。通过asyncio+httpx重写核心IO逻辑，配合信号量控制并发度，最终将P95延迟从5.8s压到0.6s，单机吞吐量提升6倍。本文记录了从问题定位、方案选型、代码改造到压测对比的全过程，包含两个可直接运行的代码版本，以及我在处理`asyncio.Semaphore`和`loop.run_in_execu
Git分支策略与Code Review流水线：支撑20人团队的协作架构
当团队从5人扩张到20人，频繁的分支冲突和代码回滚让发布效率下降了40%。本文基于我们团队在2024年Q2的一次Git工作流重构，详细拆解了基于Git Flow改良的“三线模型”分支策略、基于GitLab的强制Code Review流程，以及如何通过GitLab CI/CD将合并请求与自动化测试、部署无缝集成。文中包含完整的`.gitlab-ci.yml`配置、分支保护规则和`commit-msg
FastAPI接口300ms→38ms调优全记录：SQLAlchemy+N+1与Redis缓存实战
接手一个日活10万的内容API服务，生产环境P95延迟从280ms飙升至1.2s，数据库CPU飙升到85%。本文记录了完整的性能调优过程：通过cProfile和慢查询日志定位到SQLAlchemy ORM的N+1查询问题与Redis缓存命中率过低（仅32%）。通过重构查询逻辑（selectinload批量加载）、引入二级缓存（TTL 300s）和连接池参数调优（pool_size=20, max_
