]]>
所以花了两周写了个中间层，想解决"企业多个数据库接 LLM 时字段乱、权限乱、口径乱"的问题。写了 7000 行 Python 、134 个测试、3 份架构 spec 。然后意识到：我没有用户，没有真实场景验证，可能从头到尾在解决一个我想象出来的问题。
发出来给大家看看，也许有人真遇到过这个痛点，也许大家帮我确认这就是个锤子找钉子。
企业内部通常有好几个数据库：销售用 MySQL 、财务用 PostgreSQL 、HR 用 SQL Server 。现在老板说要接 LLM 让业务人员自然语言查数据。
直接接会遇到这些问题：
| 问题 | 举例 |
|---|---|
| 字段名无意义 | aa字段是单价，hj是合计，LLM 猜不出来 |
| 同名不同义 | 销售库的"金额"是回款，财务库的"金额"是开票 |
| 权限失控 | 销售员能查到成本和利润率 |
| 没有 SQL 审查 | LLM 生成的 SQL 可能 DROP TABLE |
| 敏感数据裸奔 | 手机号身份证明文返回 |
我的想法是在数据库和 LLM 之间加一层，把这些脏活自动化：
企业数据库群（ MySQL/PG/SQLite/Oracle/达梦） ↓ ┌─────────────────────────────────┐ │ KaiwuBridge │ │ 自动理解字段含义（不用人工标注） │ │ 权限控制 + SQL 审查 + 数据脱敏 │ │ 跨库字段自动对齐 │ └─────────────────────────────────┘ ↓ 任意 LLM （本地 Ollama / DeepSeek / GPT ） 核心卖点是不用人工洗库——传统做法是 DBA 花几周给每个字段写注释、建数据字典，我想用 LLM+统计方法自动搞定。
不是简单让 LLM 看字段名猜含义，而是：
单价 × 数量 ≈ 合计 这种关系这样即使字段名是aa，系统也能通过"aa × 整数字段 ≈ hj"推断出 aa 是单价。
灵感来自 2026 年 3 月的 DBAutoDoc 论文，核心思想是 schema 理解本质上是图结构问题。
物理层（只读账号）→ SQL 白名单（只允许 SELECT ）→ 注释绕过防护 → 字段级权限（ LLM 看不到=查不到）→ 行级过滤 RLAC （华东员工只看华东数据）→ 数据脱敏（手机号自动打码）→ 动态脱敏（按角色返回不同精度） GET /v1/context — Agent 获取 schema+权限+映射+歧义信号 POST /v1/execute — Agent 提交 SQL ，中间层负责安全检查+执行+脱敏 POST /v1/chat/completions — OpenAI 兼容接口（兼容层） Agent 层和数据层彻底分离。Agent 只管生成 SQL ，中间层只管安全执行。
同一个错误短时间内反复出现且从未成功 → 自动压制，不打扰用户。管理员可以看到"僵尸规则"列表。
企业可能有几十张表、几百个字段，不可能全塞给 LLM 。需要根据用户问题精准定位到相关的 2-3 张表。
做法参考了 SchemaGraphSQL （ ACL ARR 2025 ）：
这样 LLM 生成 SQL 时只看到精选的、和问题相关的表，不会被无关表干扰，生成准确率显著提升。
零样本、不需要 embedding 模型、不需要训练。一次 LLM 调用搞定路由。
从最初只有"连数据库+调 LLM"，到现在塞了一堆功能。用一张表说清楚每个模块干什么：
| 功能模块 | 解决什么问题 | 什么场景用 | 原理/技术 |
|---|---|---|---|
| 数据画像 (profiler.py) | 字段名无意义时无法理解数据 | scan 时自动运行，给每个字段建统计档案 | 空值率/唯一值比例/数值分布/高频值采样 |
| 代数关系检测 (profiler.py) | aa×bb≈cc这种隐含业务关系人看不出来 | 同表内数值字段三元组枚举 | numpy 向量化计算，5%误差容忍度 |
| 图传播引擎 (graph_propagation.py) | 单看一个字段猜不出含义，需要上下文 | scan --semantic 时替代逐字段 LLM 生成 | 建依赖图→LLM 迭代 3-5 轮→邻居描述作为 context 精化 |
| Schema Linking 路由 (schema_graph.py) | 几十张表不能全塞给 LLM | 每次用户提问时自动触发 | 外键图+LLM 实体提取+BFS 2 跳扩展，精选≤5 张表 |
| 跨库语义匹配 (matching.py) | 不同库的"金额"可能是不同概念 | scan 后自动两两匹配，生成 pending 映射 | bge-m3 embedding + Wasserstein 分布距离 |
| 主动学习 (matching.py RuleExtractor) | 人工审核效率低，不知道先审哪个 | 管理界面展示待审核映射时排序 | 优先推送置信度 0.6-0.8 的案例（信息价值最高） |
| SQL 白名单审查 (security.py) | LLM 可能生成 DROP TABLE | 每次执行 SQL 前强制检查 | sqlparse 语法树分析，只放行 SELECT/WITH |
| 字段级权限 (permissions.py) | 销售员不该看到成本字段 | schema 发给 LLM 前过滤 | 配置 denied_columns ，物理移除字段 |
| 行级过滤 RLAC (executor.py) | 华东员工只能看华东数据 | SQL 执行时 CTE 子查询包装注入 WHERE | 不依赖 LLM"自觉"，执行层强制注入 |
| 数据脱敏 (security.py + executor.py) | 手机号身份证不能明文返回 | 结果返回前自动处理 | 正则打码 + 按角色动态精度（ full/partial/round ） |
| 告警过滤 (alert_filter.py) | 同一个错误反复弹出烦死人 | 兼容层执行失败时判断 | 滑动窗口频率统计，≥5 次且 0 成功→压制 |
| 歧义检测 (server.py) | "销售额"在两个库都有，用哪个？ | /v1/context 接口返回歧义信号 | 语义名片匹配+多库来源检测，含 confidence |
| 数据新鲜度 (executor.py) | 查到的数据可能是上周的 | 执行成功后附加提示 | 查 MAX(updated_at)，超 24 小时警告 |
| 映射导入导出 (admin.py) | DBA 想在 Excel 里批量维护映射关系 | 管理后台 CSV 上传下载 | CSV 解析 + LLM 验证层（检查明显错误） |
| 持续学习 (admin.py + matching.py) | 用户反馈应该让系统越来越准 | confirm/reject 映射时自动触发 | 贝叶斯更新阈值 + 规则提取（不只是调参） |
| 解耦接口 (server.py) | Agent 层和数据层耦合在一起不好扩展 | Agent 自己生成 SQL 时用 context+execute | REST 分离：context 只给数据，execute 只管执行 |
一共 22 个 Python 模块，7015 行代码。说实话写到后面自己都觉得功能堆太多了。
用 100 行模拟订单数据测试：
用 10 对手工标注的跨库字段对测试：
这个 0%是预期的——证明了图传播层的必要性。裸字段名sales_amount和revenue的 embedding 相似度只有 0.67 ，低于 0.85 阈值。需要图传播先生成中文描述（"每笔订单的含税销售金额"），再做匹配才有意义。
但我还没有在真实数据库上跑过完整流水线。
65 个安全测试覆盖：SQL 注入（含注释绕过）、JWT 伪造、越权访问、频率限制、数据脱敏。全部通过。
134 passed, 0 failed, 21 warnings 全部依赖 Apache 2.0 / MIT / BSD ，可商用。
写完之后冷静下来想了几个问题：
1. 谁是用户？
我假想的场景是"中型企业，有 3-5 个业务数据库，想让业务人员自然语言查数据"。但我没有找到一个具体的企业说"我需要这个"。
2. 真实场景下这个问题存在吗？
也许存在，但解决方案可能不是我想的这样：
3. "不用人工洗库"这个卖点成立吗？
图传播方案理论上能自动理解字段含义，但：
4. 过度工程了吗？
7000 行代码、图传播、主动学习、告警过滤、动态脱敏……如果第一个用户只需要"连 MySQL + 权限控制 + 调 DeepSeek"，那 90%的代码都是提前优化。
想听听大家的看法：
代码在本地，如果有人感兴趣可以开源。也欢迎直接告诉我这是个伪需求，省得我继续往里面投时间。
| 来源 | 用在哪 | 怎么用的 |
|---|---|---|
| SchemaGraphSQL (ACL ARR 2025) | Schema Linking 路由 | 核心思想：用外键关系图+LLM 实体提取+BFS 路径搜索做 schema linking ，零样本不需要训练。我直接实现了这个方案 |
| DBAutoDoc (2026.03) | 图传播引擎 | 核心思想：schema 理解是图结构问题，通过依赖图迭代传播语义修正直到收敛。我简化了实现，没用原文的 GNN ，直接 LLM 迭代 |
| LLM-FK (2025) | 外键发现思路 | 三 agent 协作（ Interpreter/Refiner/Verifier ）的思路启发了我的约束发现设计，但我没实现多 agent ，只用了统计方法 |
| Valentine | 跨库匹配 baseline | schema matching 的开源 benchmark ，参考了它的评估方法论（ precision/recall on labeled pairs ） |
| ALITE | 约束发现 | 用数据分析发现函数依赖和包含依赖的思路，我简化成了代数关系检测（ A×B≈C ） |
| sentence-transformers | embedding 计算 | 直接用的 bge-m3 模型做字段语义向量化 |
| FastAPI | Web 框架 | OpenAI 兼容接口 |
| SQLAlchemy | 数据库连接 | 多数据库统一适配层 |
| sqlparse | SQL 安全审查 | 语法树分析，白名单验证，表名提取 |
部分论文 ai 搜的，，，， 说实话，论文读了不少，但真正落地时大幅简化了。DBAutoDoc 原文用的是 GNN 做图传播，我直接用 LLM 迭代替代了（因为目标场景是企业内部几十张表，不是几千张表的学术 benchmark ，LLM 迭代 3-5 轮完全够用）。
技术细节：Python 3.12 / FastAPI / SQLAlchemy / bge-m3 / 图传播架构 / 134 测试全绿
附仓库（为了避免说推广仓库的，所以放最后）： https://github.com/val1813/kwb
]]>DFlash DDtree Qwen3.5 & Qwen3.6 27B GGUF on RTX 3090 First GGUF port of DFlash speculative decoding. Qwen3.5-27B on a single RTX 3090, Q4_K_M target + BF16 draft, DDTree budget=22.
Up to 207 tok/s in the demo (207.6 tok/s DFlash vs 38.0 tok/s AR, 5.46×) 129.5 tok/s mean on the HumanEval 10-prompt bench 3.43× faster than autoregressive (+15% over chain speculative decoding) 2.8× faster than SGLang AWQ on the same hardware Up to 256K context in 24 GB via TurboQuant TQ3_0 KV cache (128K Q4_0 bench: 134.78 tok/s at ctx=131072)
PFlash speculative prefill on RTX 3090 In-process speculative prefill, C++/CUDA only. A drafter (Qwen3-0.6B BF16) loaded directly into the dflash daemon scores per-token importance over a long prompt; the heavy target (Qwen3.6-27B Q4_K_M) only prefills the spans that matter. Both models share the same ggml allocator on a single RTX 3090. No Python, no Triton, no PyTorch at runtime — just the dflash binary and four custom CUDA kernels (mean_K → score → select → sparse_fwd) plus BSA (mit-han-lab/Block-Sparse-Attention, FA-2 derived, sm_80+) for the long-context drafter forward.
~10.4× TTFT on 128K context: 24.8 s dflash daemon vs ~257 s llama.cpp (FA on, Q4_0 KV). 10.0× TTFT on 64K context: 13.5 s dflash vs 134.95 s llama.cpp. NIAH single-needle retrieved at every measured context (32K → 128K), keep_ratio=0.05, DFLASH_FP_ALPHA=0.85.
]]>本贴发布的目的不是推产品，不是炫技，而是想扬眉吐气——和华人开发者一起，和开源模型本地部署开发者一起，做一件我们自己的事。
去年开始用本地模型做编程辅助。原因很简单：公司代码不能传到海外服务器，Claude Code 和 Cursor 走不通。
但更大的问题是：中国开发者根本没有一个好用的本地 coding agent 平台。
CC 需要翻墙，还要订阅。Cursor 同样。Codex 刚出来也是海外服务。Hermes 这类开源工具不支持 Windows 原生运行，要装 WSL2 ，劝退了大多数国内开发者。最后大家的选择是：要么翻墙凑合用，要么忍着不用。
这是一个真实存在的空缺，没有人填。
本地跑 qwen3:8b ，然后发现问题一个接一个：
🔴 无限循环，像卡带一样
这是本地小模型最让人抓狂的问题。遇到它不会处理的场景，它不会说"我不知道"，而是开始重复——同一句话说三遍，同一个错误的修改建议循环出现，同一段代码反复生成。整个任务卡死，只能手动强制退出。这不是偶发现象，是小模型在推理能力不足时的典型崩溃模式。
🔴 修 bug 反复踩同一个坑
让它修一个函数，第一次失败，第二次用完全一样的方式再试，第三次依然。三次机会全浪费在同一个错误上，什么都没推进。
🔴 模型能力本身就弱于 API 模型
这是无法回避的现实。8B 、14B 的参数量，推理能力和 Claude Opus 、GPT-4 差距明显。让一个 8B 模型扛下一个复杂任务的全部推理，成功率很低，这不是哪个工具的问题，是模型本身的边界。
🔴 找不到要改的文件
项目大了之后，模型根本不知道要改哪个文件。让它找 bug ，它要么猜错，要么说"我需要看更多代码"，然后把整个项目塞进 context ，然后 context 又爆了。
🔴 对话几轮就开始遗忘
8B 模型 context 窗口只有 8K ，对话多了就满了，模型开始给出驴唇不对马嘴的回答。
这些问题叠在一起，用本地模型做开发辅助的体验极差。
所以我想自己做一个产品来跑。有人就会说：为什么不直接用 ollama + cc ？还友情指导我命令。
哎。
大厂的产品只会为它的商业模式服务。ollama 放弃了参数微调来换取稳定，lm 让开发者纠结什么是最优，CC/Codex/Cursor 都是卖 token ，没有人会真的认真想本地部署缺什么，需要优化什么，记忆怎么优化，上下文怎么压缩，小参数怎么辅助。
但我人微言轻，所以我做了个 MVP 想抛砖引玉。我们可以一起把要优化的都优化了，打造我们自己的产品。
有人也说，我能力不够。
那我的思路是：不够就做整合，够了就做突破。
所以我做了 KWCode ，不是为了商业化，MIT 任何人都能拿走，只希望哪个感兴趣的大神，愿意和我或者和所有开发者一起把它实现并开源，给所有被本地部署膈应的宝子们。
这是 KWCode 最核心的设计决策，也是解决上面所有问题的根本思路。
传统 coding agent 的架构是：一个 LLM 扛全部——理解需求、定位代码、生成修改、验证结果，全让同一个模型做。强模型能扛，小模型扛不住，然后就开始循环、幻觉、乱说。
KWCode 用的是 MoE （ Mixture of Experts ）架构：把任务切碎，每个专家只做一件事，LLM 只负责 Gate 分类和内容生成，其他步骤能不调 LLM 就不调。
用户输入 └─► Gate （ LLM 做一次分类，判断任务类型） └─► Locator （ BM25 + 调用图，不调 LLM ，毫秒级定位文件和函数） └─► Generator （ LLM 只写需要修改的那几行代码） └─► Verifier （自动跑语法检查 + pytest ，不调 LLM ） └─► SearchAugmentor （两次失败后自动搜索） LLM 在这条流水线里的任务被压到了最小：Gate 做一次分类，Generator 生成几行代码。定位文件、验证结果这两件最耗推理能力的事，完全不让 LLM 做。
参考：Agentless 论文（ ICSE 2025 ）——确定性流水线在 SWE-bench 上同时达到最高通过率和最低成本，优于让 LLM 自主决策的复杂 agent 。原因很简单：每一步 scope 极小，小模型在小 scope 里表现稳定。
代码定位是小模型最容易失败的步骤，把它从 LLM 手里拿走，换成确定性算法。
CodeCompass （ arXiv:2602.20048 ，2026 年）做了 258 次实验，发现了一个关键结论：
真实项目里，很多 bug 的根因文件名和错误描述毫无关联，只能通过调用链追踪才能找到。对这类"隐藏依赖"任务，BM25 关键词搜索准确率只有 **76.2%**，而图遍历达到 **99.4%**，差了 23 个百分点。
KWCode 的两阶段检索：
整个过程不调 LLM ，SQLite 持久化调用图，重启不重建。
技术栈：tree-sitter + rank-bm25 + SQLite。不需要 Neo4j ，不需要 embedding 模型，不需要额外 Docker 。
针对"反复踩同一个坑"和"无限循环"这两个问题：
反无限循环：MAX_RETRIES 硬编码为 3 ，没有任何路径能绕过。同时检测连续两次生成完全相同的 patch ，直接跳过不重试，告诉用户"模型卡住了，建议缩小任务范围"。
反重复失败：三次重试强制用三种不同的问题表述：
| 第几次 | 策略 |
|---|---|
| 第一次 | 正常描述需求 |
| 第二次 | 从错误信息出发："直接修复这个报错，不要解释" |
| 第三次 | 最小化修改："只改这一个函数，其他代码一行不动" |
第一次失败后先做 Reflection：让 LLM 一句话分析上次失败的原因，然后把这个分析注入下次的 prompt 。不是让模型自由发挥，是强制它先诊断再修。
参考：EE-MCP （ NeurIPS 2025 ）——从任务执行轨迹自动提取经验，验证可显著提升后续同类任务成功率。
KWCode 预置了 15 个专家（ BugFix 、TestGen 、SpringBoot 、FastAPI 等），每个专家有独立的 system prompt 。
同类任务成功 5 次之后，飞轮自动分析轨迹，生成新专家，经过三道验证门后投产：
专家可以导出成 .kwx 文件，kwcode expert install URL 一行安装别人分享的专家。
CC 不需要考虑这个，因为它只用一个模型。KWCode 需要。
自动检测当前模型的参数量，然后应用不同策略：
| 模型规模 | 自动策略 |
|---|---|
| < 10B （ qwen3:8b ） | 强制计划确认 · 任务范围限 2 个文件 · 第 1 次失败触发搜索 |
| 10-30B （ qwen3:14b ） | 可选计划 · 4 个文件范围 · 第 2 次失败触发搜索 |
| > 30B （ qwen3:72b ） | 宽松策略 · 8 个文件 · 自动处理复杂任务 |
切换模型，策略自动切换。
核心功能跑通了。282/282 单元测试通过，E2E 验收通过率 87%（ 26/30 ，4 个失败是模型能力边界，不是框架问题）。
代码能力
工程能力
/plan 计划模式 + 风险评估（ High/Medium/Low ，基于历史失败记录）体验
说实话，有些地方还挺粗糙的：
我一个人做这个工具有明显的上限，不是技术上的上限，是视野上的上限。
我自己主要用 Python 和 FastAPI ，所以这方面想得细。但我不知道每天写 Spring Boot 的人最痛的点在哪，不知道搞 Rust 的人在本地模型上遇到什么问题，不知道做小程序的人需要什么。
更重要的是，这件事不应该只是一个人的工具，应该是中国开发者社区的工具。
CC 是 Anthropic 的，Cursor 是美国公司的，Hermes 是外国社区做的。我们用的工具，我们的使用习惯、技术栈偏好、本地化需求，从来都是别人顺手加进去的功能，不是第一优先级。
我想做的是反过来——把中国开发者的需求放在第一位，把本地开源模型的适配放在第一位，然后把这个工具做到能和大厂产品掰手腕。
这件事一个人做不到，但开源社区可以。
Linux 打败了 Unix ，不是因为某一个天才，而是全球开发者共同维护了几十年。VSCode 能超过那么多商业 IDE ，也是因为背后有庞大的插件和贡献生态。
KWCode 不需要你有多高的水平，只需要你在用本地模型做开发，然后把你遇到的问题、你的解法、你的改进贡献进来。多一个人，就多一个使用场景被照顾到，多一个坑被填掉。
Fork 这个项目，改进你最痛的那个点，提 PR ，我们互相借力，一起把它做好。
闭源大厂有钱有人有算力，我们有什么？我们有真实的使用场景，有对本地部署的真实需求，有不依赖海外服务的动力。这已经足够了。
项目地址：github.com/val1813/kwcode
# Fork 项目，克隆到本地 git clone https://github.com/your-fork/kwcode.git cd kwcode # 安装开发版 pip install -e ".[dev]" # 运行测试确认环境正常 python -m pytest kaiwu/tests/ -v # 找一个你最想改的地方，开始动手 git checkout -b fix/your-improvement 改什么都可以：
Issues 里列了已知问题和规划中的功能，可以从那里找方向。Discussions 里可以聊技术思路，聊某个方向值不值得做。
没有什么贡献太小。
我不知道 KWCode 能不能真的超越 CC 或者 Hermes 。
但我知道，如果中国开发者一直用别人做的工具，一直把自己的需求当作"次要功能"等别人来实现，这件事永远不会有答案。
有些东西，只有自己做才知道能不能做到。
项目是 MIT 开源的，你贡献的代码永远是你的。如果 KWCode 最后做成了，这件事是所有参与的人一起做成的。
项目地址：github.com/val1813/kwcode
天工开物 · KWCode · 中国开发者自己的本地 Coding Agent
]]> ]]>我写过 kaiwu（一个本地模型部署器），结果发现——用 Local LLM 做开发的朋友，多得超出想象。
大家不断提需求：上下文压缩、Think 模式开关、联网搜索、工具调用……
可这些根本不是 Ollama 或 LM Studio 的事！
它们只负责把模型跑起来，至于“怎么让模型变聪明”——那是 Cursor 、Codex 、Hermes 的事。
但大厂们在干嘛？
它们不会花精力优化本地小模型。
因为本地跑得爽，谁还买它们的 API ？
更别提那堵墙了——
国内网络时断时续，任务跑到一半断连，体验像吃苍蝇。
想用 Claude ？得找中转、买注水账号、被收割、还被鄙视。
但墙能拦住资本，拦不住人民。
国际共产主义精神，就体现在一行行开源代码里。
部署难、速度慢、硬件要求高这些，我之前的 kaiwu + LM + Turbo 能解决。
今天我们不聊这些，就聊怎么让 8B 模型跑出 Opus 的体验。
核心理念：
LLM 只负责当“接线员”，真正干活的是确定性专家——
不依赖模型“啥都懂”，而是让模型只做一件极小、极明确的事。
不让 LLM 瞎决策，用固定流程 → SWE-bench 上通过率最高，成本最低。
我设计的流程（ KWCode ）： 用户输入 └─► Gate （毫秒级分类） └─► Locator （精确定位文件/函数） └─► Generator （只改该改的地方） └─► Verifier （语法 + pytest ，失败重试）
小模型只需要在小窗口里做一件事——失误率暴跌，错误可被当场抓住。
论文 CodeCompass 发现一个反常识事实：
context 越大的模型，反而越容易漏掉架构上关键但语义上遥远的文件——这叫“导航悖论”。
实验数据（ FastAPI 真实项目）：
| 任务类型 | BM25 | 图遍历 |
|---|---|---|
| 有明确关键词 | 100% | — |
| 可通过 import 链找到 | ~85% | ~85% |
| 完全无关键词的隐藏依赖 | 76.2% | 99.4% 🚀 |
我们的实现：
技术栈：tree-sitter + rank-bm25 + SQLite
零依赖、零 embedding 、零 Docker。
支持：Python · JS · TS · Java · Go · Rust
来自 EE-MCP (NeurIPS 2025) + WLBS 行为图。
预置 12 个专家（通用 7 个 + 中国场景 5 个）。
然后开始飞轮：
3 个月后，你的专属专家池——
Cursor 和 Hermes 永远追不上，因为它们无状态，而你有永久记忆。
专家可以导出、分享形成我们的社区数据资源。
Verifier 连挂 2 次 → 自动触发搜索：
零 API key ，零配置，装完即用。
想更隐私？自己部署 SearXNG ，数据不出网。
| 模块 | 做了什么 |
|---|---|
| 代码定位 | BM25 + AST 调用图，99.4% 命中隐藏依赖 |
| 代码修改 | 只改 patch ，不重写全文，精确匹配 |
| 验证重试 | 语法 + pytest ，失败回滚，失败 2 次开搜索 |
| 项目记忆 | PROJECT.md / EXPERT.md / PATTERN.md 三层分离，按需 BM25 注入 |
| 专家系统 | 12 预置 + 飞轮自生成 + 可分享安装 |
| 中国本地化 | 自动切 ModelScope / 清华镜像 / Bing 搜索 / Windows 原生 |
| 场景 | 其他工具 | KWCode （我们） |
|---|---|---|
| Windows | 逼你装 WSL2 | cmd / PowerShell 原生跑 |
| 模型下载 | HuggingFace 被墙 | 自动切 ModelScope |
| pip 安装 | PyPI 慢死 | 自动切 清华/阿里镜像 |
| 搜索增强 | DDG 被墙 | 自动切 Bing 中文版 |
| 推荐模型 | GPT / Claude （要钱/要梯子） | DeepSeek · Qwen · GLM（国产免费） |
我只有一台 5060 8G 显存 16G 内存小破电脑，硬盘还时好时坏，花钱买 api 一个月三四千。 我想要人人为龙时代，而不是 api 独大时代。 所以我想打造 一个真正属于开源社区、不依赖大厂 API 、不被墙、让 8B 模型也能干翻 Opus 的 Coding Agent 。
我们有论文支撑，有原型代码，有满腔怒火和热血。
现在还缺你——
缺每一个受够了被收割、被歧视、被网络暴力的开发者。
GitHub 仓库近期开放，代码完全开源。
你可以：
国际共产主义精神，从一行开源代码开始。
让大厂去卖 token 吧，我们有自己的工具了。
👉 有没有更好的思路和路径，上述只是我个人研究
👉 后续在本链接发布 github ，欢迎 fork 继续深挖
不要让资本定义“可能”与“不可能”。
我们说了算。 或许很快，8B 模型真能跑赢 OPUS ，所有人都能拥有独属于自己的智能体
要不要先建个群，算了 我社恐 不会维护，有事咱们这个链接聊把
]]>买不起机子，所以做了这个。
在线地址：tps.bunai.cc
一个 vibe code 出来的 GPU 推理性能估算工具。
起因很简单——显卡太贵，买不起，想跑个模型又不知道自己的配置够不够， 于是把网上散落的参数和公式汇总了一下，做成了这个计算器。
输入显卡型号、模型、量化方式和运行参数，快速估算：
✅ 在买机子 / 租卡之前，先大概预估一下跑不跑得起来
✅ 学习推理性能建模，理解量化、KV Cache 、TP 、Roofline 这些概念
✅ 做方案初筛和参数对比
❌ 不适合直接替代真实 benchmark
❌ 不适合把估算值当作生产承诺
❌ Mac 电脑没有放出来，验证了一下差距有点大，先放一放
这套公式和参数是我自己整理汇总的，没有大量真机跑过验证。 如果你手上有真实的测试数据，发现哪里估算偏差大、公式有问题， 欢迎开 Issue 或 PR 指出来，大家一起学习，一起把这个东西做得更准。
希望有真实数据的大佬帮忙指正，谢谢！🙏
]]>
YOLO26做数据集训练和目标检测或追踪的，图片数据暂定 5000 张（其实数据有很多，但是暂定用于训练的数据上限是 5000 张）。 目前有一台 RX6600xt ，但是 directML 好像也不能使这张卡参与训练计算，上网查了一下好像是对 7000 系列以上的显卡支持的更好一些。
所以老板的意思是重新配一台 N 卡主机，但我之前没有使用 YOLO 训练的经验，不知道目前这个数量级的数据训练以及这个体量的模型该使用什么卡。咨询官网 AI 的话，就是无脑推荐 4090 、5090 这种大显存的卡。搞得我很头疼~
关于预算的话，老板只说了一句你看着办吧。但之前老板的意思是让我看看能不能把现在这台主机的显卡换成 RTX5070 ，后来我查了一下现在主机的电源，才 500W ，带不动 5070 ，才有了配新主机的这件事。所以我想着写个两三套配置单给老板看，低配高配都写一下，让老板决定选什么。
有没有有YOLO 训练+目标检测经验的 V 友给点建议？跪谢了~
于是做了个工具自动找最优配置，过程中踩了不少坑，记录一下。
Qwen3-30B-A3B 是 MoE 架构，在 8GB 显卡上：
快了 7 倍，显存反而省了 65%。关键是 llama.cpp 支持这个，但你得自己识别哪些 tensor 是 MoE expert （.ffn_.*_exps. 这类命名），然后手动配。
同一张 8GB 显卡跑 Llama 3.1 8B ，不同 KV cache 配置速度差异：
| 配置 | ctx | 速度 |
|---|---|---|
| iso3+iso3 ，4 slot | 8K | 19.4 tok/s |
| q8_0+q4_0 ，1 slot | 8K | 38.2 tok/s |
| f16+f16 ，1 slot | 8K | 51.7 tok/s |
| f16+f16 ，1 slot （自动） | 64K | 26.2 tok/s |
f16 比 iso3 快将近 3 倍。但 f16 显存占用更大，所以正确策略是：先算 f16 KV cache 占多少显存，装得下就用 f16 ，装不下再降级。
公式：KV_MB = 2 × layers × kv_heads × head_dim × ctx × bytes / 1024²
社区里流传的 oobabooga 显存估算公式，原本用来预测装载模型后剩余显存能支持多大 ctx 。但这个公式是基于 q8_0/f16 拟合的，用 iso3 的时候会严重高估显存需求，导致 ctx 只算出 4K 。
最后放弃公式预测，改成二分探测：从 min(nativeCtx, 65536) 开始，OOM 就减半，最多探 5 次，让 llama-server 自己告诉我能跑多少。Llama 3.1 8B 的 ctx 从 4K 直接到 64K 。
llama.cpp 默认开 4 个并行 slot （为了多用户并发），但单用户场景下这会把 VRAM 分成 4 份。
关掉多余 slot （--parallel 1）之后：18.5 → 38.2 tok/s ，直接翻倍。
ubatch 128 vs 512 的性能差异跟模型和显卡都有关系，没有通用最优值。实测结论：
直接 benchmark 两个值取快的，比查文档猜靠谱。
最初方案是上下文满了之后调本地模型生成摘要——结果单 slot 阻塞，直接超时。
改成纯算法提取：保留头部（ system prompt + 首轮对话）和尾部（最近 8K tokens ），中间部分提取代码路径、函数名、文件名、TODO 等关键信息。压缩率 73%，耗时 <1ms 。
直接调用 llama.cpp 的 llama-server ，所有参数（ ctx 、KV cache 类型、线程数、ubatch 、mlock 、tensor split ）都通过启动参数注入。Kaiwu 本质上是一个参数决策层，不改推理引擎本身。
集成了 johndpope 的 turboquant fork （feature/planarquant-kv-cache），支持 -ctk iso3 -ctv iso3 参数。iso3 的压缩系数实测 0.73 ，理论值 0.75 ，在 VRAM 紧张的设备（ 8GB ）上可以把 KV cache 占用压缩到 q8_0 的一半。但有约 600MB 固定解码 buffer 开销，VRAM 充裕时反而比 f16 慢 8%，所以策略是 VRAM > 16GB 才默认开 iso3 。
社区流传的公式用来预测剩余显存能支持多大 ctx ，基于 q8_0/f16 拟合。iso3 场景下高估显存需求，导致 ctx 只算出 4K 。最终改成二分探测代替公式，让 llama-server 自己决定能跑多少。
Qwen3 等新模型用 GQA （ Grouped Query Attention ），kv_heads 远小于 attention_heads 。KV cache 大小公式里用的是 kv_heads 而不是 heads ，不识别这一点会高估 3-4 倍。通过读 GGUF metadata 拿到准确的 kv_heads 值再做计算。
读取模型的 tensor 名称列表，匹配 .ffn_.*_exps. 模式识别出 MoE expert 层，自动决定把这部分路由到 CPU 。不需要用户手动指定，也不需要提前知道模型架构。
上下文到 75% 时触发，纯算法提取：保留 system prompt 、首轮对话、最近 8K tokens ，中间部分按关键词权重保留（代码路径、函数名、文件名、TODO 、命令行等）。不调用任何模型，压缩耗时 <1ms ，73% 压缩率。最初试过调本地模型生成摘要，单 slot 阻塞直接超时，这条路走不通。
turboquant fork 需要自己编译带 iso3 支持的 llama-server 。用 GitHub Actions 同时编译 Windows （ MSVC ）和 Linux （ GCC ）版本，CUDA 12.4 ，覆盖 sm_75/80/86/89 架构，RTX 50 系列通过 PTX JIT 运行时支持。踩了三个 MSVC 编译坑（ extern "C" 声明改定义、M_PI 未定义、全局符号缺失），记录在 PROGRESS.md 里。
把上面这些逻辑都自动化了，叫开物（ Kaiwu ）。一行命令启动，参数全部自动找，结果缓存起来，第二次 2 秒启动。
GitHub： https://github.com/val1813/kaiwu
OpenAI 兼容 API ，Continue / Cursor / Claude Code 直接接。
有遇到类似问题的欢迎交流，尤其是 MoE offload 和 KV cache 这块踩坑挺深的。
]]>问题:
考虑:
好奇问一下，想学习学习
]]>这台机子的带宽 273 GB/s
31B 参数 × 2 bytes (BF16) ÷ 273 GB/s = 每个 token 227 ms = 理论最大 4.4 token/s
实际能到 3token/s 已经是牛逼 plus ，顶多 2.5token/s
所以有个关系，不要问能不能运行咋的，自己大概算下基本就知道能不能用
简单得推理我觉得至少要到25token/s，看起来才正常
1. 模型必须能加载完，显存只是基本条件
2. 必须要看内存带宽（ Memory Bandwidth ），这个太低得话估计就是个跛子，我看几乎很少有人部署模型时注意这个配置，这个也是非常重要得参数
3. 上面得基本是按照英伟达机子算出来得，mac 机子比较特殊，基本只要能加载到 gpu 里面，剩余一点内存，就能用速度不会很慢（ 20token/s 将就能用），冷启动稍微慢点
还有个本地模型部署，除了花大钱，本地部署就是玩玩可以，起码现在不要妄想超过线上得模型，尤其写代码方面
我个人认为现在本地模型能做得事
希望大家来交流自己得心得，大家共同学习进步
]]>本地部署的 coding 能力和效果，能接近 gpt-5.3-codex 吗？
如果本地部署的 coding 能力可以，我感觉可以让牛逼的模型 API 来创建分解任务，然后让本地执行。
]]>另外在 m2 mac 上直接跑 cli https://github.com/google-ai-edge/LiteRT-LM
这种性能已经完全可以离线运行 酒馆 小手机 之类的私密场景.
]]>
]]>随着价格的刺激和产能的提升，以及对本地大模型的需求，2 年以后 256G 内存能否得到普及？
256G 内存，加上本地模型的发展，应该可以在本地运行一些非常不错的 coding 模型了
]]>我一开始使用的是 qwen3.5-9b 和 qwen3.5-4b 的模型，测试的时候，可以用，但是在实际跑起来的时候，发现 qwen 会无限思考，经常 10 分钟都没有任何响应；后来换成了 qwen3-4b 的模型，效果比较好，很少出现无限思考的问题
]]>
]]>
本地部署 deepseek 70B 的模型，问答几轮之后就乱码了，怎么回事？我同事说一般部署的本地模型多轮问答之后就可能会有这个问题？
]]>