河岳日星的博客

12G 显存跑 27B：NInfer + KVMem 推理引擎本地部署实战（sm_120 避坑全记录）一、背景与目标手里的机器是 RTX 5070 Ti Laptop（12GB 显存）+ 31GB 内存。目标很明确：在本地把 Qwen3-27B 跑起来，并且不是「能聊天」就行，还要满足两个硬需求： OpenAI 兼容 API——这样 ZCode、Codex、各种客户端可以直接接入； 对话 / 工具双模式——聊天时要发散，给 Agent 当工具时要收敛。 最终选型是 NInfer 推理引擎 + KVMem 改造版。这篇文章把完整部署过程、五个「缺一不可」的环境变量、12GB 显存下的选型账，以及那些「照抄默认配置就会炸」的坑，一次讲清。 二、架构硬约束：选错就直接拒NInfer 按 GPU 架构分发引擎包，没有回退机制，选错架构不是性能差，是根本起不来： 架构 对应显卡 引擎包 sm_86 30 系 infer-engine-sm86 sm_89 40 系 infer-engine-sm89 sm_120 50 系（Blackwell） infer-engine- ...

经验驱动。下面这套攻防是本机真跑的：我起了一个会”拦默认 Scrapy UA + 限速”的本地测试站，再用 Scrapy 蜘蛛绕过去。真实状态码和重试过程都贴在下面——不是我编的。 反爬站怎么拦（我写的测试逻辑）测试站两条规则：① User-Agent 含 Scrapy 或为空 → 返回 403；② 1.5 秒内重复请求 → 返回 429。 真跑证据先验证反爬是否生效（用 requests 直接打）： 12默认 Scrapy UA 状态码: 403 (被拦)伪装浏览器 UA 状态码: 200 (通过)，首页含标题: True 再上 Scrapy 蜘蛛（自定义 UA + DOWNLOAD_DELAY=2）。日志里能看到完整攻防： 1234567GET / HTTP/1.1 403 # 默认 UA 被拦（验证阶段）GET / HTTP/1.1 200 # 浏览器 UA 通过（验证阶段）GET / HTTP/1.1 429 # 蜘蛛首请求太快，触发限速GET / HTTP/1.1 200 # Scrapy 自动重试（延迟 2s 后）成功GET /ap ...

⚠️ 本文为公开资料整理版（占位）：基于三者官方文档与社区对比梳理，用于建立选型框架；本人尚未在同一数据集上完成三方横向压测，真实性能数据待补实践后替换。面试时可以据此讲清「选型逻辑」，但写进简历前请亲手跑一遍。 一、先想清楚要什么选向量库前先问三个问题： 数据量多大？千级 / 百万级 / 亿级？ 部署形态？单机嵌入式还是要分布式集群？ 要不要和检索框架、重排、元数据过滤深度集成？ 不同答案直接决定选型。 二、三者定位 Chroma：开发者友好，嵌入式起步，几行代码能跑，适合原型和小项目。代价是大规模下的运维能力弱。 Qdrant：Rust 实现，性能和内存效率高，过滤（payload）能力强，云托管成熟，适合中大型生产。 Milvus：面向海量（亿级）的分布式向量库，架构最重，运维成本高，但扩展性是三者最强。 三、对比速查 维度 Chroma Qdrant Milvus 起步成本 极低（pip 即用） 低（Docker） 高（分布式） 单机性能 中 高 高（规模取胜） 分布式 弱 中 强 元数据过滤 一般 强 强 适合阶段 原型/小项目 生产主力 ...

经验驱动。实体识别是信息抽取的第一步，也是搜索、知识图谱、风控的底层能力。本文用本机真实跑通的 bert4ner-base-chinese 讲清楚：模型怎么抽、真实输出长什么样、有哪些坑，以及一条能从”标注”走到”上线”的完整链路。 什么是 NER命名实体识别（Named Entity Recognition）是从文本里找出实体并给它们分类，比如人名、机构名、地名、时间。它是序列标注任务：给每个 token 打标签。 最常用两套标注体系： BIO：B-实体（开头）、I-实体（中间/结尾）、O（非实体）。例如 李/B-PER 明/I-PER。 BIOES：在 BIO 基础上加 E（结尾）、S（单字实体），边界更精确，评估时更不容易歧义。 中文 NER 比英文难在：没有空格分词，实体边界要靠模型自己学；还有大量未登录词（新公司名、英文名实体）。 真跑：用 bert4ner 抽实体bert4ner-base-chinese 是基于 bert-base-chinese 的中文 NER 模型，标签体系是 B/I-PER、B/I-ORG、B/I-LOC、B/I-TIME、O。本机推理代码： ...

经验驱动。下面这条提速链路是本机真跑的：sklearn 训练 RandomForest → 转 ONNX → onnxruntime 推理。结果很硬：单条推理从 4.55s 降到 0.029s，加速 157 倍，预测一致率 0.999。 为什么要把模型转 ONNX模型训完要上线，常卡在三件事：① 部署环境没装 sklearn/torch 整套 Python 依赖；② Python 推理慢、GIL 锁并发；③ 要跨语言（C++/C#/边缘设备）。ONNX 是”模型的中间表示”——把训练框架的模型导出成一个标准文件，再用 onnxruntime（纯 C++ 引擎，各平台都有）推理，去 Python 依赖、还能大幅提速。 真跑链路1234567891011121314# 1) sklearn 训练（略）clf.fit(Xtr, ytr)# 2) 导出 ONNXfrom skl2onnx import convert_sklearnfrom skl2onnx.common.data_types import FloatTensorTypeonx = convert_sklearn(clf, ...