召回层单独用双塔模型，本质是把「语义匹配」从 BM25 的词汇重叠里解耦出来，代价是要接受它召不回精确术语。所以生产上一般不是二选一，而是两路并行再融合。coROM base 768 维的实际用法：from sentence_transformers import SentenceTransformer m = SentenceTransformer("coROM-base") doc_vec = m.encode(docs, batch_size=64, normalize_embeddings=True) q_vec = m.encode([query], normalize_embeddings=True)三个容易踩的点。第一，normalize_embeddings=True 必须开，否则内积和余弦距离算出来排序不一致。第二，文档侧要离线批量编码并落盘，别在请求里现算，10 万条文档现算一次要几分钟。第三，索引选 HNSW 而不是暴力检索，hnswlib 的 M 设 32、ef_construction 设 200，召回率能到 0.95 以上。融合阶段给 BM25 和向量各一路分数，用 RRF 而不是直接加权求和，因为两边分数量纲不一样，加权很容易被一边吃掉。最后再接一个 cross-encoder 重排前 50 条，效果比单独调向量模型明显。

4bit NF4 把 4B 的 VL 模型压到 2.87GB，显存账其实要分三块算：权重 2.87GB、KV cache、以及图像预处理时的中间激活。4060 的 8GB 里，权重占掉三分之一，剩下能不能跑长上下文，全看 KV cache。实际部署建议先用 transformers 跑通，别一上来就 vLLM：pip install transformers accelerate bitsandbytes model = AutoModelForVision2Seq.from_pretrained( path, load_in_4bit=True, bnb_4bit_quant_type="nf4", bnb_4bit_use_double_quant=True, device_map="auto")注意 device_map="auto" 在单卡上会把部分层甩到 CPU，推理速度直接掉一个量级。单卡 8GB 建议手动全放 GPU，把 max_new_tokens 控制在 512 以内。图片侧是隐藏的显存杀手。一张 1024×1024 的图，ViT patch 16 之后是 4096 个 token，加上文本能轻松顶到 8K 上下文。预处理时先把长边缩到 768，能省一半以上。至于医疗微调的效果，没有评测报告就只能自己造 20 条测试样本试，别直接上生产。

生产环境我会先把「配置」拆成三层看：连接层、执行层、存储层，每层只调 1-2 个参数，不然改完出问题根本定位不到是谁的锅。连接层最常见的是连接池给太大。MySQL 的 max_connections 调到 2000 并不等于吞吐上去了，反而会把内存吃满、上下文切换变多。业务侧连接池 maximumPoolSize 一般按 (CPU 核数 × 2 + 磁盘数) 估，配合 wait_timeout 设 600 秒，比盲目加连接数有效。执行层先看慢日志再动手：SET GLOBAL slow_query_log=ON; SET GLOBAL long_query_time=0.5;跑一天再用 pt-query-digest 排序，前 5 条 SQL 该加索引加索引，该改写的改写。经验上前 5 条能吃掉 80% 的耗时。存储层主要是 buffer pool，InnoDB 建议给到物理内存的 60%-70%，剩下的留给连接和排序。改完 innodb_buffer_pool_size 要重启，先在从库验证再滚动到主库。顺序别反：先观测再调参，调完留至少一个业务周期的观察窗口。

Connection reset 多半是连接被 MySQL 的 wait_timeout 或中间设备掐断，池里拿到的是死连接。Hikari 的 maxLifetime 要比数据库 wait_timeout 小 30 秒以上，比如：spring.datasource.hikari.max-lifetime=600000spring.datasource.hikari.idle-timeout=300000spring.datasource.hikari.keepalive-time=120000spring.datasource.hikari.connection-test-query=SELECT 1再查云数据库侧的空闲连接回收策略，事务里连接会保持更久。改完让连接空闲 10 分钟再打请求，日志里不再出现 reset 就对了。

0.5G 内存跑 Docker，先上 zram 再用 swapfile 兜底，别把 swap 放进 zram。zram：apt install -y zram-toolsecho -e "ALGO=lz4\nPERCENT=50" > /etc/default/zramswapsystemctl restart zramswapswapfile：fallocate -l 1G /swapfile && chmod 600 /swapfile && mkswap /swapfile && swapon /swapfileecho '/swapfile none swap sw 0 0' >> /etc/fstabsysctl -w vm.swappiness=60容器加 --memory=256m --memory-swap=512m，构建时少装包，否则 0.5G 很容易 OOM。

大概率是灾难性回溯。嵌套量词或 (a+)+ 这种写法在长字符串上会指数级展开，CPU 直接跑满。先用最小复现定位：perl -e 'use re "debug"; "aaaaaaaaaaaaaaaaaaaaaaaaaaaaab" =~ /(a+)+$/'改法：拆开嵌套量词，用原子组 (?>...) 或占有量词 ++，给输入长度设上限；线上再加匹配超时，Java 用可中断线程，Go 的 regexp 是 RE2 没有回溯问题。