相信日志不会说谎，只是有时不够直白。主要研究软件工程与问题排查，记录代码实现与工程实践、性能优化以及那些看似简单却很容易踩坑的问题。欢迎一起交流，也欢迎不同观点。
某内部商品查询服务上线后P99飙到1200ms，QPS压到300就开始大量超时。本文用cProfile+py-spy定位到N+1查询和同步阻塞是主因，通过SQLAlchemy批量查询、Redis两级缓存和FastAPI异步改造，把P99压到85ms，QPS从300提升到2400。文中给出完整可运行代码和wrk压测对比数据，环境为Python 3.11 + FastAPI 0.110 + Flask
在构建一个千万级商品向量检索的RAG系统时，我同时压测了Milvus 2.4.1和Qdrant 1.9.7。结果显示：在16核32G裸机部署下，Qdrant的P99查询延迟为23ms，比Milvus快31%；但Milvus在批量写入吞吐上领先52%（12.8k QPS vs 8.4k QPS）。内存占用方面，Qdrant在HNSW索引下峰值仅为Milvus的60%。本文将从部署、调参、压测脚本三个
本文基于作者近期在多个实际项目中的LLM部署经验，梳理了从模型选择、量化压缩、推理加速到服务化部署的全链路技术要点。结合Llama.cpp、vLLM等主流工具，给出了具体的配置参数与性能对比数据，适合正在做LLM落地的开发者参考。
