本地大模型SQL能力实测：部署、评测与翻车全记录

上周三下午，我在一个数据团队的周会上被一句话问住了：“你天天说大模型能写SQL，那你倒是现场写一条统计连续登录天数的SQL出来看看。”我当时打开网页版AI工具，把表结构和需求粘贴进去，出来的第一版SQL居然用了个不存在的函数名。现场气氛很尴尬，但也正是那次之后，我下定决心不再依赖在线AI，而是把所有能拿到的开源大模型全部拉回本地，搭了一个专门用来测SQL能力的“大模型实验室”。

这个实验室的目标只有一个：亲手测出到底哪个模型最懂SQL。过去两个月，我部署了Qwen2.5系列、代码专用模型、通用对话模型，从几十道真实业务题里拆出评测集，跑了一轮又一轮。今天把整个过程整理出来，从环境搭建、模型选型，到评测方案设计、实测数据和翻车现场，全部摊开聊。适合正在做本地大模型部署、AI编程助手选型、被慢SQL折磨过的研发和DBA，也适合准备把大模型引入数据工作流的同学参考。

1. 这个“SQL大模型实验室”到底在解决什么问题

先说清楚背景。不是在线AI不能用，而是SQL这个任务有它的特殊性，在线方案存在三道绕不开的坎。把这些问题想明白了，你才会真正理解为什么要自己搭一套本地实验环境。

1.1 在线AI在SQL任务上的三道坎

第一道坎是数据隐私。生产环境的表结构、字段命名、业务口径，说白了就是一家公司的数据地图。你把这些结构信息粘到在线AI对话框里的那一刻，它们就已经离开了可控边界。我认识的数据团队里，很多人宁愿自己手写慢SQL，也不愿意把核心库表结构发给外部服务。这不是守旧，是合规底线。

第二道坎是上下文窗口的性价比。一个真实业务库动辄几十张表，字段注释一拼起来就是几千上万token。在线AI的窗口虽然越做越大，但你真把整套schema塞进去之后，它经常“记了后面忘了前面”，生成SQL时会凭空造出一些不存在的字段。你越想把背景讲全，它越容易跑偏。

第三道坎是SQL方言差异。SQL不是一种语言，SQL Server、MySQL、PostgreSQL、Oracle之间的语法差异能坑死人。在线AI为了讨好用户，经常把不同方言的写法混在一个答案里。比如我把SQL Server的场景喂给它，它可能生成一段LIMIT语法，这在SQL Server里根本执行不了。

1.2 本地跑模型，真正的手感差异在哪

把模型拉到本地之后，最直观的变化是“敢把真实内容塞给它了”。我可以在提示词里完整贴上自己业务库的建表语句，包括字段注释、索引、分区信息，模型给出的SQL贴合度明显提升。这个能力听起来平平无奇，但恰恰是SQL助手落地最关键的环节。

本地化还意味着你可以自由构建反馈闭环。模型生成SQL之后，我可以立刻在测试库执行，把执行计划或报错信息再喂回给模型，让它自我修正。这种“生成-执行-反馈-再生成”的循环，在线工具很难稳定实现。

最重要的是，本地部署可以反复压测、自由对比。同一道题，我可以换不同模型、不同温度、不同提示词模板各跑十遍，看它到底稳不稳。这种“亲手测”得出的结论，远比网上那些泛泛的排行榜对你自己的业务有参考价值。

2. 设备清单与模型选型：预算有限怎么配

这个实验室的搭建门槛没有想象中高。核心问题只有两个：你的显卡能跑多大的模型，你该选代码模型还是通用模型。

2.1 显存与参数量：一张消费级显卡的极限在哪里

先说明显存和参数量之间的换算关系。模型显存占用大致可以按“参数量 × 量化位数 / 8”来估算。比如一个7B（70亿参数）模型，用Q4量化（每个权重4比特），推理状态大约需要70亿 × 4 / 8 = 3.5GB，再算上KV Cache和中间激活，实际占用大概在5GB到6GB。

我手头有一张12GB显存的消费级显卡，跑7B模型毫无压力，跑14B模型用Q4量化也能勉强放下，但推理速度明显变慢。如果只有8GB显存，建议老老实实用7B及以下。32B模型起步就要20GB以上显存，这已经超出大部分人的消费级显卡范畴。

注意这里是“推理显存”的估算，还没算多轮对话增长的KV Cache。实际使用中如果遇到OOM，优先降低上下文长度，这比换小模型来得快。

2.2 代码模型优先：为什么通用模型在SQL上容易掉链子

测试了几轮之后，我的选型原则很简单：SQL任务优先选代码模型。原因不复杂——SQL本质上是给数据库执行的“代码”，而不是给人类阅读的自然语言。代码模型在训练阶段见过大量结构化、强逻辑的代码数据，对字段引用、语法边界、子查询嵌套的敏感度，明显高于通用对话模型。

我对比过同一厂家的通用7B和代码7B模型，在“自然语言转SQL”任务上，代码模型的正确率普遍高出15到20个百分点。典型翻车案例是：通用模型能写出看起来结构完整的SQL，但引用了不存在的字段名，或者把JOIN顺序写反；代码模型这类低级错误明显少。

但代码模型也不是万能。在“SQL解释”这类偏语言表达的任务上，通用模型往往说得更口语化、更容易懂。所以建议是：如果核心需求是生成SQL，优先代码模型；如果还要兼顾解释和技术沟通，就在评测集里单独加一个解释维度，别凭印象拍板。

2.3 部署工具对比：Ollama还是vLLM

部署工具我两个都用了。简单说：个人实验首选Ollama，服务化高并发选vLLM。

Ollama的优势是极低的上手门槛，一条命令安装，一条命令拉模型，自动处理量化格式转换和运行环境。它对GGUF格式支持很好，适合快速跑通评测。

vLLM则胜在吞吐量和并发控制。它用PagedAttention把KV Cache管理得更好，同样的显存能服务更多并发请求，且提供OpenAI兼容的API，生产环境接入方便。缺点是配置项多，常见坑也多，比如CUDA版本不匹配、模型模板不匹配等，对新手不算友好。

我的建议路线是：评测阶段用Ollama，跑通流程；上生产之前再换vLLM。不要一开始就在vLLM上折腾部署，那会消耗掉你评测的热情。

3. 从拉取镜像到首次跑通：部署过程的完整记录

这一章直接给操作记录，可以照着做。我以Linux环境为例，Windows的差异不会太大。

3.1 用Ollama把模型拉起来

安装Ollama本身不难，Linux和macOS用户直接执行：

curl -fsSL https://ollama.com/install.sh | sh

Windows用户也可以直接下载安装包，这地方没什么坑。装完之后先启动服务：

ollama serve

然后拉取模型。我强烈建议在拉取时显式指定量化版本，不要只写模型名默认拉取。如果不指定，很可能拉到一个占用显存过大的版本。我的用法是：

ollama pull qwen2.5-coder:7b-instruct-q4_K_M

拉取完成后，可以先在交互式命令行里试一下：

ollama run qwen2.5-coder:7b-instruct-q4_K_M

能正常对话之后，再启动HTTP接口。默认端口是11434，Ollama提供OpenAI兼容路径，用curl就能测试：

curl http://localhost:11434/v1/chat/completions \ -H "Content-Type: application/json" \ -d '{ "model": "qwen2.5-coder:7b-instruct-q4_K_M", "messages": [{"role": "user", "content": "用一条SQL统计2024年每个月的订单总额"}], "temperature": 0.2 }'

这里把temperature设为0.2，是为了评测时减少随机性。做SQL生成时，偏低温度更合适，因为SQL是确定性任务，不需要模型过度“发挥”。

一个容易忽略的配置是上下文长度。Ollama默认上下文可能只有4096，对SQL任务来说有点短，尤其是塞入建表语句后。可以通过环境变量调大：

export OLLAMA_CONTEXT_LENGTH=16384 ollama serve

注意上下文长度翻倍，KV Cache的显存占用也会翻倍，量力而行。

3.2 vLLM部署的关键参数与踩坑

等评测有结论之后，可以用vLLM把选中的模型包装成服务。基本启动命令是：

pip install vllm vllm serve Qwen/Qwen2.5-Coder-7B-Instruct \ --max-model-len 8192 \ --gpu-memory-utilization 0.9 \ --dtype auto

如果显卡支持量化，可以加--quantization awq指定量化方式，但要注意AWQ格式需要提前准备。没有量化条件时，直接用GB级显存跑FP16也是可以的，只是显存要求更高。

我踩过的坑有三个。第一个是Python版本和vLLM版本的兼容问题，有些旧版vLLM在Python 3.12上装不上，建议按官方文档匹配版本。第二个是模型路径尽量用完整模型名，别用简称，否则容易拉到对应不上tokenizer的版本。第三个是prompt模板问题——vLLM不会自动帮你套chat template，API请求里传入的messages格式，模型会按照自己的模板处理；模板没配好，生成结果会出现重复片段或者中文乱码。

3.3 启动服务后先做三个自检

不管用Ollama还是vLLM，服务起来之后别急着跑评测，先做三个自检。

第一个自检是确认模型输出没有“复读机”现象。随便问一句“用SQL统计用户表总行数”，如果模型反复输出同一句话，或者输出内容跟输入无关，说明加载或模板配置有问题。

第二个自检是上下文记忆能力。把一段较长的建表语句放进上下文，连续问两个相关问题，看模型是否记得住前面的内容。如果第二个问题的回答明显忽略了第一个问题中提到的表结构，说明上下文处理有问题。很多评测翻车，根源其实不是模型不强，而是部署时上下文管理不到位。

第三个自检是中文输入输出是否正常。有些模型的tokenizer对中文编码敏感，会出现半个字、乱码、空格横插等现象。出现这种情况，优先检查prompt模板，而不是怪模型能力差。

4. 评测方案设计：怎样才算“最懂SQL”

部署只是第一步，真正花时间的是评测方案。我的原则是：不靠感觉打分，把“懂SQL”拆成可量化的维度。

4.1 五个评测维度拆解

我把SQL任务的评测拆成五个维度。

第一个是文本转SQL（NL2SQL）。这是最高频的日常场景，用户用自然语言描述需求，模型给出可执行的SQL。测试时我会给出一段建表语句和几个业务问题，比如“统计连续三天有订单的客户”，判断它能不能把“连续”翻译成窗口函数或者关联子查询。

第二个是SQL解释。日常工作中，研发常要接手一堆没有注释的复杂SQL。模型如果能把一条带有窗口函数、多层CTE的SQL讲清楚，那它就是真的理解，而不是只会背模板。

第三个是慢SQL优化。我会故意放一段有性能问题的SQL和它的表结构，问模型“哪里慢、怎么改”。这个维度非常考验模型对索引、连接方式、谓词下推、执行计划的理解深度。

第四个是方言兼容与排错。我会故意写一段SQL Server特有写法的SQL，然后让模型判断这段SQL在另一个数据库里跑不跑得通，如果不通该怎么改。这个维度能检验模型对不同数据库方言的掌握程度，特别适合团队里同时用多个数据库的场景。

第五个是安全红线。把一段包含可疑用户输入拼接的SQL拿给模型，看它能不能识别出注入口风险并建议用参数化查询改写。这里特别说明：评测目的是识别与防御，不是教怎么构造攻击。

4.2 测试集与打分规则

测试集建议每个维度准备10到15道题，分成基础、进阶、挑战三档。基础题考察CRUD和简单join；进阶题考察聚合、子查询、窗口函数；挑战题则涉及“连续登录”“追平上期”“区间重叠”这类逻辑复杂的需求。表结构可以统一用一套模拟电商库，包含用户、订单、商品、支付流水四张表，字段类型尽量贴近真实。

打分规则我按四档加权：可执行性占2分，结果正确性占4分，执行效率占2分，格式与可读性占2分，满分10分。可执行性是硬门槛——SQL如果根本跑不起来，后三项直接不用看了。

4.3 必须提前堵住的三个评测误差

设计评测方案时，最容易被忽略的是误差控制。我第一轮评测就犯过三个错误，提前给各位避坑。

第一，温度参数不统一。前两天测的结果和今天测的结果对不上，后来发现是某次启动时忘了设置温度，默认值偏高，导致模型输出随机性过大。SQL任务评测，统一temperature=0.2、top_p=0.8是底线。

第二，上下文没有隔离。最初的评测脚本把题目全都放在同一个会话里连续提问，结果前一道题的答案会影响后一道题。后来改成每道题独立创建会话，模型只看到当前题的schema和问题，评测公平性立刻好了很多。

第三是“只看SQL，不执行验证”。很多模型生成的SQL肉眼看着没问题，一执行就报错，比如字段名拼错、缺少GROUP BY列、全角括号等。所以我在评测脚本里加了自动执行环节，直接用测试库跑一遍，跑不出来就是0分。这一步极其重要，能淘汰掉一大批“花架子”模型。

5. 实测结果与翻车现场：数据会说实话

这部分直接上结论和数据，再挑几个印象深刻的案例展开讲。我用的测试集来源是自身的业务场景，分数不代表模型在所有场景的表现，但足够说明问题。

5.1 各模型得分总览

我挑出来对比的模型有四类：Qwen2.5-7B-Instruct、Qwen2.5-Coder-7B-Instruct、DeepSeek-Coder-6.7B-Instruct，以及一个通用对话模型作为参照。所有模型都用7B级别，保证显存条件一致。五个维度满分均为10分，总分满分50分。

结论很清楚：在SQL的生成和排错上，代码模型明显占优；在解释维度，通用模型的口语化表达更好。但整体来看，7B级别模型做SQL解释和慢SQL优化都还有明显短板，尤其是挑战类题目。想用大模型辅助生产环境SQL优化，建议至少上14B或者考虑微调。

5.2 窗口函数翻车实录

最有代表性的是“统计每个用户连续登录的最长天数”这道题。这是评测集里的一道挑战题，中文表达很简单，但翻译成SQL需要用到LAG/LEAD或者ROW_NUMBER做分组判断，对模型的逻辑组合能力要求很高。

其中一个模型给出的SQL是这样的（简写）：

SELECT user_id, COUNT(DISTINCT login_date) AS cont_days FROM login_log GROUP BY user_id;

这SQL能执行，但逻辑完全错误。它只是统计了每个用户的登录天数，而且用DISTINCT把连续关系抹掉了，直接得出“这个用户登录了5天，所以连续登录5天”的错误结论。说明模型理解了“天”和“登录”，但没有真正理解“连续”这个词的时序含义。

另一个代码模型则给出了正确的解决思路：先用LAG比较当前日期与上一日期是否相差1天，小于等于1的归为同一连续组，再按组聚合求最大天数。这种差距不是“多背几条SQL”能弥补的，而是模型对窗口函数执行顺序有真正的理解。

5.3 慢SQL优化建议的差距

慢SQL优化维度，模型之间的差距更大。我给了一道典型的慢查询，涉及一个大订单表和一个用户表，需求是统计每个城市的高价值客户。通用模型给出的建议是“加索引、避免SELECT *、把子查询改成JOIN”，听起来都对，但解决不了实际问题。

代码模型的回答就具体得多。它会先指出这条SQL的瓶颈大概率在ORDER BY和GROUP BY同时出现导致临时文件排序，然后根据表数据量建议用覆盖索引，甚至能注意到SQL里有一个在索引列上做函数的写法导致索引失效。这种“结合具体执行特征给建议”的能力，才是慢SQL优化维度的核心。

所以如果你打算用大模型辅助优化慢SQL，不要只看它能不能给出“优化版SQL”，更要看它能不能解释“为什么这里慢”。后者才是对你工作最有价值的部分。

5.4 评测中途遇到的三件意外

评测过程不是一路顺风，这里记录三个意外，帮后来人省时间。

意外一是在测多轮对话时显存突然溢出。排查发现是会话历史被完整带入下一轮，KV Cache成倍增长。后来把评测脚本改成每轮对话结束后清理历史，只保留当前题目的上下文。

意外二是中文提示词和英文提示词的得分差异非常大。同一道题用中文问和用英文问，一些模型的NL2SQL正确率差了将近20%。这提醒我们，在自己团队落地时，提示词语言最好固定，否则模型效果评估无法对齐。

意外三是方言测试时，多个模型都“默认”输出MySQL语法。即便提示词里明确写了“这是SQL Server库，注意方言差异”，模型仍然习惯性给出LIMIT而不是TOP。这说明模型训练语料里MySQL占比过高，方言切换能力不能被高估。

这三个意外也提醒我：评测不只是给模型打分，更是在帮你理解模型的“脾气”。你要是不知道它在中文和英文下表现差异这么大，上线后一定会被业务方质疑“怎么有时候聪明有时候笨”。

6. 从“会测”到“能用”：把评测结果落地成工程方案

评测完成了，最后一步是怎么把它变成真正能用的工具。我把落地路径分成三种，按团队规模和需求复杂度选。

6.1 三种接入方式：API、RAG、LoRA微调怎么选

第一种是直接把本地模型封装成内部API服务，前端接一个Web聊天界面或者IDE插件。适合个人和小团队，改造量最小。Ollama或vLLM跑起来，把prompt模板固定好，就能投入使用。我自己的第一版SQL助手就是这么做的，一天时间就能上线。

第二种是引入RAG（检索增强生成）。把业务库的建表语句、字段注释、枚举值、历史优秀SQL都存到向量库里，用户提问时先检索相关表结构，再拼进提示词让模型生成。这种方式能明显缓解模型“瞎编字段名”的问题。数据表很多的大型团队，建议直接走这条路线。

第三种是LoRA微调。如果你手里有一批标注好的“业务问题-SQL”对，可以用LLaMA-Factory等工具对选定模型做低秩微调。以Qwen2.5-7B为例，用单张消费级显卡加载LoRA跑几个epoch，就能让模型适应用你团队的独特表结构和SQL习惯。微调不是很多人想象中那么遥不可及，但前提是数据质量足够高——如果标注SQL本身有一堆问题，微调只会放大错误。

6.2 给SQL助手加一道“执行前审核”的护栏

最后必须提醒一点：本地大模型生成的SQL不能直接放到生产库执行。无论评分多高，都要在“SQL助手”和“真实数据库”之间加一道护栏。

我的实践方式是让模型在生成SQL的同时，输出三样东西：涉及的表清单、预期影响行数、可能的风险点。然后在程序侧接入EXPLAIN校验，发现计划中有全表扫描或者影响行数异常就直接拦截，转人工确认。提示词里也要明确写清禁止生成不带条件的DELETE、UPDATE以及任何DDL操作。把模型当成年纪不大但很有热情的实习生——你可以让它干活，但不能给它生产库的DROP权限。

我在实际使用中还有一个习惯：把每次评测的SQL、执行的执行计划、模型打分全部留档。每次模型出新版本，或者换一个新的部署配置，都拿同一套测试集重新跑一遍。这样模型能力和配置参数的变化，都能用数据说话，而不是靠感觉。