asyncio重构Flask接口，QPS从87到312的完整记录
一个内部报表API，单次请求需要聚合3个微服务数据，平均耗时420ms，QPS只有87。用asyncio把串行HTTP调用改为并发后，P95延迟从680ms降到215ms，QPS提升到312。本文记录完整改造过程，包括asyncio.run()的坑、Semaphore限流、aiohttp连接池复用，以及如何在不改Flask框架的前提下接入异步。附完整可运行代码和压测数据。
Git Flow与Trunk Based双轨策略：支撑百人团队的版本控制架构
本文记录了我们团队从SVN迁移至Git后，在100+研发人员、20+并行项目的规模下，如何通过双轨制（Git Flow + Trunk Based）解决发布混乱与代码冲突的实践。重点分享基于Git 2.39.1的`--rebase-merges`策略、基于Gerrit 3.7的Code Review工作流，以及Jenkins Pipeline 2.4.6与GitLab CI 15.11的集成配置。
7B模型LoRA/QLoRA微调实录：显存从24G降到6G的细节与踩坑
微调7B模型，全参微调需要4张A100，而LoRA只需1张24G消费卡，QLoRA更是把门槛拉到6G。本文用细粒度情感分类任务，完整走通数据准备、LoRA/QLoRA训练配置、loss曲线分析、推理效果对比全流程。你会看到QLoRA在显存占用降低70%的同时，F1只掉了0.8个点，而推理速度几乎无损。文中所有代码和配置均基于transformers 4.38.2、PEFT 0.10.0、bitsa
Git分支策略与流水线联动：基于GitFlow改造的Trunk-Based实践
本文记录了一次将团队Git仓库从纯GitFlow迁移至“简化Trunk-Based+特性分支”的完整过程。我们解决了主干长期不稳定、Code Review流于形式、CI构建时长超过25分钟等核心痛点。通过引入GitHub Actions的路径过滤与合并队列（Merge Queue），将平均发布周期从2天缩短至4小时，主干分支的每日通过率从68%提升至96%。文中会给出分支保护规则、PR模板、自动化
Git分支模型与Code Review流水线：从SVN迁移后的千次提交实践
从SVN迁移到Git已18个月，团队从7人扩张到25人，经历了从“Git当SVN用”到成熟分支模型的蜕变。本文将分享我们基于Git Flow与GitHub Flow折中后的分支策略、基于Gerrit的Code Review强制流程，以及与Jenkins+SonarQube的CI/CD集成细节。文中包含真实的分支命名规范、hook脚本、Jenkinsfile配置，以及迁移后部署频率从每周2次提升至每
LoRA微调7B模型全记录：从QLoRA配置到loss收敛与推理对比
本文记录了一次完整的7B模型（llama2-7b-chat）微调实验。通过QLoRA技术，在单张24GB显存的RTX 3090上完成了指令跟随能力的定向增强。文章详细对比了不同rank（8/16/32）对loss收敛曲线的影响，并给出了微调前后模型在特定领域问题上的推理效果对比。实验显示，仅训练3个epoch，模型在测试集上的BLEU分数提升12.7%，而显存峰值仅占用18.6GB。全文包含完整的
FastAPI与Flask性能瓶颈定位：Profiling、SQL优化与Redis缓存调优实录
在一次电商订单API的压测中，我发现接口P95延迟从120ms飙升到2.3s，吞吐量从800QPS跌至150QPS。通过py-spy与cProfile定位到N+1查询和JSON序列化瓶颈，结合SQLAlchemy的`selectinload`、Redis缓存热点数据及Gunicorn+Uvicorn多Worker配置，将P95延迟降至180ms，吞吐量恢复至750QPS。本文记录完整调优过程，含P
FastAPI接口耗时2170ms→89ms：Profile与查询优化全记录
生产环境一个订单列表API在QPS=15时P99延迟飙到2170ms，伴随CPU空转和数据库连接池枯竭。通过cProfile定位到90%时间浪费在N+1查询和ORM懒加载上，结合SQLAlchemy 2.0的selectinload、Redis缓存热数据以及Gunicorn + Uvicorn多进程部署，将P99降至89ms，吞吐量提升至320 QPS。本文记录了完整的profiling工具使用、
Git分支模型与Code Review流水线：支撑百人级团队的版本控制架构
当团队从15人扩张到80人，主干开发模式导致的代码冲突率飙升300%，紧急修复被迫等待12小时合并窗口。本文基于Git 2.39.1与GitLab 15.11，拆解一套融合GitFlow精简版与Trunk Based的分支策略，配合基于Merge Request的强制Code Review与Jenkins CI/CD流水线。通过真实配置展示如何将发布周期从周级压缩至日级，同时将生产环境缺陷率降低4
FastAPI压测从1200到9800 QPS：profiling与缓存三层优化实录
一个用户画像服务上线后单实例QPS仅1200，P99延迟高达860ms，数据库连接池被打满。本文记录完整调优过程：用py-spy定位GIL争抢、cProfile揪出N+1查询、SQLAlchemy 2.0的`selectinload`替代`lazy='joined'`、Redis缓存热点数据与Caffeine本地缓存两级降级。调优后单实例QPS稳定在9800，P99降至41ms，数据库负载下降87
LangChain 0.3手写Agent：AutoGPT循环控制与记忆管理实践
本文记录一次从零实现轻量级AI Agent的完整过程，基于LangChain 0.3.7与GPT-4o-mini，核心代码仅180行。重点解决三个问题：如何设计可插拔的工具注册机制、如何用有限内存窗口实现长期记忆压缩、如何在循环中捕获工具异常并自动降级。最终Agent在5个连续工具调用场景下，任务完成率从初版61%提升至89%，平均单轮响应耗时稳定在2.3秒左右（含LLM推理与工具执行）。文中附全
asyncio重构Flask接口：QPS从120到850的并发优化实录
某次压测发现订单查询接口在200并发下超时率高达23%，平均响应时间1.8秒。通过asyncio+httpx异步化改造外部依赖调用，将同步阻塞的5次HTTP请求改为并发协程，接口吞吐量提升7倍，P99延迟从3200ms降至480ms。本文记录完整改造过程，包含asyncio.Semaphore限流、超时控制、连接池复用的坑与解，以及uvloop对性能的额外增益。
Prompt Engineering调优实录：从38%到91%准确率的RAG问答系统优化
在一次金融研报RAG问答系统开发中，我通过系统化Prompt Engineering，将GPT-4o-mini的答案准确率从38%提升至91%。本文记录了5轮Prompt迭代的完整实验数据：包括Few-shot示例数量对输出质量的影响（3-shot比0-shot准确率提升47%）、结构化指令与JSON输出约束的token消耗对比（平均每请求节省312 tokens）、以及系统Prompt中角色设定
用asyncio重构Flask API，并发性能提升300%的完整记录
上周接到一个紧急任务，线上某Flask服务在高峰期出现大量请求超时，单实例QPS只有80，P99延迟飙到1.8s。排查发现，瓶颈竟然是我们最引以为傲的“同步调用第三方REST API”逻辑——每个请求平均阻塞600ms。本文记录了我用Python 3.10 + asyncio + aiohttp对该服务进行异步化改造的全过程，包含before/after代码对比、协程并发模型设计、以及压测工具wr
7B模型LoRA微调实录：从loss震荡到指令遵循的调参全记录
本文记录一次完整的7B模型（Qwen2.5-7B-Instruct）LoRA微调实践。基于单张24G显存的RTX 3090，使用QLoRA（4-bit NF4量化）将显存峰值控制在17.8G。针对中文法律问答场景，构建8K条指令数据，通过对比r=8/16/32的收敛曲线，最终选定r=16+alpha=32组合。经过3个epoch训练（耗时4.2h），在100条人工评测集上，指令遵循准确率从基座的4
FastAPI与Flask双框架API性能调优：从900ms到40ms的Profiling与缓存实战
在接手一个日活10万+的库存查询服务时，该API在高峰期的P99延迟高达900ms，导致上游服务频繁超时重试。本文记录了针对FastAPI与Flask两个版本接口的完整调优过程：通过cProfile与py-spy定位CPU瓶颈，利用EXPLAIN ANALYZE发现索引失效与N+1查询，引入Redis三级缓存策略，最终将P99延迟降至40ms，QPS从380提升至5200。文中包含可复用的Prof
RAG召回率从61%到89%：chunk重构与rerank双阶段调优实录
线上问答系统命中率连续三周卡在61%，用户反馈“答非所问”占比高达34%。本文记录一次完整的RAG系统优化：通过动态chunk大小替换固定512字符切片，将召回准确率提升至73%；切换bge-large-zh-v1.5 embedding模型后提升至81%；最终引入bge-reranker-base重排，使Top-5命中率达到89%，首答准确率提升42%。全程附可运行代码、版本号及显存占用实测数据
7B模型LoRA微调实录：显存8G跑通中文指令微调与效果评测
在单卡RTX 3090上，用QLoRA对Llama-2-7B进行中文指令微调，显存峰值仅6.2GB。通过3000条高质量指令数据，3个epoch训练后，模型在C-Eval验证集上从34.2分提升至41.8分，推理速度保持12 tokens/s。本文完整记录数据清洗、bitsandbytes 4bit量化配置、PEFT LoRA参数选择、loss收敛曲线分析及微调前后输出对比，并附上训练脚本和踩坑记
Milvus与Qdrant在千万级向量检索下的选型实测对比
在处理2500万条768维向量、QPS峰值要求800+的RAG生产环境中，我先后用Milvus 2.4.1和Qdrant 1.9.2搭建了检索服务。实测结果：Milvus在16C32G配置下P99延迟9.2ms，Qdrant同样配置P99延迟14.7ms；但Qdrant的磁盘占用仅为Milvus的41%。本文用真实部署步骤、参数调优和压测数据，讲清楚两者在资源瓶颈和查询模式上的本质差异，帮你避开选
LoRA微调7B模型全记录：从数据处理到loss曲线与推理对比
上周用一张24G的RTX 3090，对Llama-2-7B做了LoRA微调，目标任务是“代码注释生成”。从数据清洗到训练完成花了约9小时，其中训练仅占4.2小时（batch size=4，seq_len=512，lora_rank=8）。最终在100条测试集上，微调后模型生成注释的BLEU从2.3涨到11.8，ROUGE-L从18.6%提升到34.2%。本文记录了完整流程，包括数据格式设计、tra
