企业官网建设流程全解析

1. 先想清楚:为什么非得把代码模型拉回本地

聊 StarCoder 2 之前,我想先说结论:它不是 GitHub Copilot 的"平替",更像一把可以自己磨、自己装的刀。你在编辑器里敲下半个函数名,它能在 100~300 毫秒内把后面几行补上,这件事 Copilot 早就做到了,而且做得相当顺手。真正让人动心思自己搭一套的原因,通常不是"补得更好",而是三笔账:延迟、隐私、成本。延迟这块,云端服务要走一次网络往返,遇到跨区或者弱网,首 token 能拖到一秒以上,补全的节奏一断,人就不想用了;隐私这块,不少团队的代码库不允许外传,哪怕是片段级上传,合规评审也过不去;成本这块,按人头包月的账在小团队里不显眼,但人数一多、又想给 CI、文档生成、批量重构脚本也接上模型,费用和调用限制就开始咬人。

StarCoder 2 正好卡在这个位置上。它是一套开源代码大模型,参数量分 3B、7B、15B 三档,训练语料覆盖几百种编程语言,支持 fill-in-the-middle(FIM)训练目标,也就是天生为"中间插代码"这种补全场景设计的。7B 的 4bit 量化版本在消费级显卡上就能跑,15B 量化后在单张 24GB 显存的卡上也能撑住。这意味着你可以把整套推理链路放在自己机器里,断网也能用,代码不出内网。

这篇分享面向三类人:一是在自己笔记本上想折腾一套离线补全的独立开发者;二是要给团队搭一套内网补全服务、需要评估硬件和吞吐的工程负责人;三是已经用过 Copilot,想知道开源方案到底差在哪、差多少、能不能补上的技术同学。下面我会把模型结构里真正影响体验的几个点拆开讲,给出可以直接抄的三条部署路径、编辑器接入配置、参数取值表,以及我踩过的那些坑。硬件型号、显存数字、延迟数据我都会给具体的账,你可以照着换算成自己手上的设备。

2. StarCoder 2 的技术拆解:哪些设计决定了补全体验

2.1 三个规格与显存账:先算清楚你再下单

选模型第一步不是看榜单,是算显存。推理时的显存占用大致是权重 + KV cache + 框架开销三部分。权重部分是最好算的:FP16 下每 10 亿参数约 2GB,BF16 一样;4bit 量化后约 0.55~0.7GB/十亿参数,具体看量化方式。KV cache 跟上下文长度、并发数、KV 头数量成正比,补全场景单次请求上下文通常在 1~2k token,所以它一般不构成主要压力,但并发一开就会迅速膨胀。

下面这张表是我按实际部署经验整理的,列出常见配置的落点,你可以对照自己机器的显存位置来判断能跑哪一档。

这张表里最容易被低估的是"建议显存"和"权重占用"之间的差值。差的那几 GB 一部分给 KV cache,一部分给推理框架的临时缓冲,还有一部分是给操作系统和编辑器留的余量。我在一台 8GB 显存的机器上跑 7B 的 Q4_K_M,如果把上下文开到 8192、并行数开到 4,显存会直接顶满然后开始向内存借,速度断崖式下跌;把上下文收到 2048、并行收到 1,就非常稳。所以量化档位和上下文长度要一起调,不能只盯着模型大小。

另外提醒一句,量化不是越大越好。Q4_K_M 和 Q5_K_M 在补全任务上的差距,大部分时候人眼分辨不出来,但显存和速度差 15%~25%。我现在的默认选择是 7B 用 Q4_K_M,15B 用 Q4_K_M 或 Q5_K_M,只有在写数学密集或者类型体操特别复杂的代码时,才会切到 8bit 跑一遍对比。

2.2 分组查询注意力与滑动窗口:延迟和长上下文的两个开关

StarCoder 2 用了分组查询注意力(GQA),简单说就是多个查询头共享一组键值头。生活化的类比:以前是每个收银台都配一个自己的仓库管理员,现在是几个收银台共用一个管理员,取货次数少了,搬运成本就下来了。落到推理上,GQA 直接压的是 KV cache 的体积,而 KV cache 又是并发时的显存大户,所以这个设计对"多人共享一个服务"的场景意义很大。单机自用感受不明显,一旦你要给十几个人提供补全,有没有 GQA 直接决定你是一张卡还是两张卡。

滑动窗口注意力则是另一个方向:让每个 token 只关注前面固定窗口内的内容,而不是全部历史。这带来两个后果。好的一面是长上下文外推能力变强,训练时上下文长度有限,但推理时可以把窗口叠起来处理更长的输入;不好的一面是超长距离的依赖会丢,比如文件开头定义的接口、中间隔了两千行才用到的类型,模型可能就"忘"了。这个特性对补全场景其实刚好合适,因为补全只需要看前后几百 token,真正的长上下文需求应该由"检索相关片段再塞进上下文"来解决,而不是硬堆窗口。

这里有一条我验证过很多次的经验:补全请求的上下文不要贪长。把整个文件塞进去,除了增加延迟,还会让模型注意力分散,输出质量反而下降。比较稳的做法是把上下文控制在 1~1.5k token,优先放当前函数的完整代码、上面几行的 import、以及同文件里被引用的符号定义。剩下的交给检索,而不是交给窗口。

2.3 FIM 目标与提示格式:补全能不能用,全看这三个标记

这是最容易被忽略、也最容易出错的地方。普通语言模型是"给你前文,续写后文";但编辑器里的补全经常是"光标前后都有代码,我要往中间插"。这两种任务差别巨大,前者模型只需要顺着写,后者必须同时利用前缀和后缀的约束。StarCoder 2 在训练阶段就用了 FIM 目标,把文档切成前缀、后缀、中间三段,然后用三个特殊标记组织输入:<fim_prefix>、<fim_suffix>、<fim_middle>。期望模型生成的,就是 middle 那段。

拼装方式是这样的:

<fim_prefix>光标之前的代码<fim_suffix>光标之后的代码<fim_middle>

模型从这里开始生成,直到遇到结束标记。如果你的提示模板里少了这几个标记,模型就会退化成普通续写,表现是:它会把光标后面的代码再抄一遍,或者写出与前缀重复的语句。我第一次接编辑器时就栽在这里,补全十次有八次在重复后缀,我一度以为是模型太弱,换了好几个规格都一样,最后发现是提示模板写错了。

除了 FIM 标记,还有几个特殊 token 要留意。文件分隔标记<file_sep>用于多文件拼接训练,推理时如果上下文里放了多个文件,理论上可以用它分隔,但补全场景基本用不到,反而容易让模型误判。结束标记<|endoftext|>必须加进 stop 列表,否则模型可能在生成完代码后继续自言自语。我在 stop 列表里通常放这几个:<|endoftext|>、<file_sep>、<fim_prefix>、<fim_suffix>、<fim_middle>,再加上一个"连续两个换行 + 紧接着是已有后缀的第一行"这种启发式停止条件,后者需要你在客户端自己做,服务端不好表达。

提示:不同推理框架对特殊 token 的处理方式不一样。量化工具在转换时如果没有保留 special tokens 的映射,你会看到模型把<fim_prefix>当成普通文本输出。第一次部署完,先做一次纯文本的 FIM 测试,确认输出里没有标记泄漏,再去接编辑器。这一步花五分钟,能省掉两小时的困惑。

2.4 多语言覆盖与数据来源带来的现实差异

StarCoder 2 的训练语料覆盖几百种编程语言,但这个"覆盖"的分布极不均匀。Python、JavaScript、TypeScript、Java、Go、C++、Rust 这些主流语言的数据量充足,补全质量可用;一些小众语言、领域特定语言、配置文件的 DSL,数据量就少得可怜,模型容易写出语法正确但语义胡来的东西。这不是模型缺陷,是数据分布决定的,任何开源模型都一样。

数据来源方面,它基于公开代码仓库构建,并且提供了可以追溯来源的机制,这对企业合规评估很重要:你可以据此判断训练数据里是否混入了许可证不兼容的代码,以及生成结果需不需要做相似度检查。我的实际做法是,在团队内部明确一条规则:模型生成的内容一律视为"参考草稿",合并前必须人工审阅,尤其是涉及加密、权限校验、数据处理逻辑的片段,不能直接采信。这条规则不是为了免责,而是因为补全模型确实会在边界条件上偷懒。

还有一个实际影响:代码风格。训练语料以英文注释和主流风格为主,所以模型在写英文注释、按常见命名习惯补全时表现最好;如果你团队有强烈的内部风格约定(比如特定的错误处理模式、特定的日志封装),模型默认不会遵守,需要靠上下文示例或者微调来引导。这一点在后面讲微调和提示拼装时还会提。

3. 影响范围与适用边界:谁能真正受益

3.1 三类受益最明显的场景

第一类是离线或者隔离环境。有些开发机压根不联外网,或者只允许白名单流量,这种情况下云端补全服务根本接不进来,本地模型是唯一选项。第二类是对代码外传有硬性限制的团队,不管限制来自客户合同还是内部制度,只要"代码片段不能出网"这条成立,本地部署就从"想试试"变成"必须做"。

第三类是高频、大批量的自动化场景。比如给几千个仓库批量补类型注解、批量生成单元测试骨架、批量把旧接口调用改造成新接口。这类任务用云端 API 按 token 计费,账单会非常难看,而且速率限制会让你排队排到怀疑人生;用本地服务,边际成本接近电费,跑一晚上也就那么回事。我见过一个团队用 7B 模型跑历史代码的注释补全,一晚上处理了几万个文件,机器是台闲置的工作站,成本几乎为零。

反过来说,有几类场景我不建议硬上。第一种是追求"最聪明的补全"的个人开发者,如果你的机器只有集显、代码又允许外传,云端方案的体验确实更好,没必要为了情怀折腾。第二种是需要跨文件深度理解的重构任务,补全模型的能力边界就在当前文件加少量上下文,指望它做架构级改动不现实。第三种是对生成结果有严格正确性要求的场景,比如自动生成数据库迁移脚本,这类活还是让人来。

3.2 和云端方案的差距到底在哪

很多人关心"能不能打平"。我的判断是:在单行、单函数的补全上,7B 到 15B 的开源模型已经能到"够用"的水平,尤其在你把上下文拼装做对之后;差距主要体现在三个地方。

一是上下文组织能力。云端产品背后通常有一套成熟的检索和排序逻辑:它会从你打开的其他文件、最近的编辑历史、项目里的符号索引里挑出最相关的片段塞进提示。这套东西开源模型本身不提供,得自己搭。你不搭,模型就只看得到当前文件;你搭了,体验能上一个台阶。这是我认为投入产出比最高的一块工程。

二是多语言与框架知识的新鲜度。模型有知识截止时间,新出的框架、新版本的 API,它不知道。这一点云端产品靠持续更新模型缓解,本地方案靠你自己换模型或者做检索增强。

三是延迟稳定性。本地服务的延迟取决于你的显卡和当时的负载,好处是可控,坏处是没有弹性。团队规模一上来,一张卡扛不住就得加卡,而云端服务的弹性是天然的。

3.3 团队落地时的边界条件

如果你打算在团队里推这套东西,有几个边界条件最好提前想清楚,不然后面会反复扯皮。

硬件边界:是每人本地跑,还是集中一台机器做服务。每人本地跑的好处是零网络延迟、互不影响,坏处是硬件参差、模型版本不统一、升级维护麻烦。集中服务的好处是统一版本、统一参数、显卡利用率高,坏处是引入网络延迟和排队。我的建议是:小于 5 人、机器都还行,就本地跑;超过 10 人,或者有人用轻薄本,就上集中服务,配一个简单的排队和限流。

合规边界:训练数据的许可证情况、生成结果的归属、代码相似度检查策略。这些不是技术问题,但会决定这套方案能不能真的用起来。建议在试点阶段就把规则写下来,别等推广了再补。

预期边界:明确告诉使用者"这是辅助工具,不是自动驾驶"。补全模型会写出看起来对但实际错的代码,尤其是边界条件和异常处理。我在团队里推的时候,会专门收集一批"模型写错的典型例子"做内部分享,让大家知道该在哪些地方多看一眼,效果比空喊"注意审查"好得多。

4. 实操搭建:三条部署路径与编辑器接入

4.1 路径一:llama.cpp + GGUF,单机自用首选

这条路适合在自己机器上跑,尤其是显存不大、想要精细控制卸载层数和量化档位的情况。先拿到 GGUF 格式的量化权重,放在本地目录,然后起服务:

./llama-server \ -m ./models/starcoder2-7b-q4_k_m.gguf \ --host 127.0.0.1 --port 8080 \ -c 2048 \ -n 128 \ --n-gpu-layers 99 \ --parallel 1 \ --flash-attn \ --temp 0.2 --top-p 0.9 --repeat-penalty 1.05

参数逐个说。-c 2048是上下文长度,补全场景不需要太长,设小一点省显存也省时间。-n 128是单次最大生成 token 数,补全超过 128 个 token 的情况很少,设大了反而容易让模型啰嗦。--n-gpu-layers 99表示所有层都卸载到显卡,如果显存不够,这个数字往下调,调到不爆显存为止;层数卸载得越少,速度越慢,但至少能跑起来。--parallel 1是并发数,自用设 1 就够,设大了每个槽位都要占 KV cache。--flash-attn能省显存也能提速,前提是你的显卡和编译版本支持,不支持就去掉,别硬开。

启动后先用 curl 打一发,确认服务通:

curl -s http://127.0.0.1:8080/completion \ -H "Content-Type: application/json" \ -d '{ "prompt": "<fim_prefix>def parse_config(path):\n with open(path) as f:\n <fim_suffix>\n return cfg<fim_middle>", "n_predict": 96, "temperature": 0.2, "stop": ["<|endoftext|>", "<file_sep>", "<fim_prefix>", "<fim_suffix>", "<fim_middle>"] }'

返回里应该是一段合法的 Python,而不是重复后缀。如果它把return cfg又抄了一遍,回去检查 FIM 标记有没有被转义、有没有被服务端当成普通字符串处理掉。

4.2 路径二:Ollama,最短路径但可调项少

Ollama 的好处是把权重管理、服务托管、模型切换都包了,一条命令搞定,适合快速验证和不爱折腾的人。缺点是底层参数暴露得少,精细调优空间不如直接跑推理框架。

先写一个 Modelfile,把补全需要的关键参数钉死:

FROM starcoder2:7b PARAMETER temperature 0.2 PARAMETER top_p 0.9 PARAMETER top_k 40 PARAMETER repeat_penalty 1.05 PARAMETER num_ctx 2048 PARAMETER num_predict 128 PARAMETER stop "<|endoftext|>" PARAMETER stop "<file_sep>" PARAMETER stop "<fim_prefix>" PARAMETER stop "<fim_suffix>" PARAMETER stop "<fim_middle>"

然后构建并启动:

ollama create sc2-7b-fim -f ./Modelfile ollama run sc2-7b-fim curl -s http://127.0.0.1:11434/api/generate -d '{ "model": "sc2-7b-fim", "prompt": "<fim_prefix>func sum(nums []int) int {\n total := 0\n <fim_suffix>\n return total\n}<fim_middle>", "stream": false, "options": {"num_predict": 96, "temperature": 0.2} }'

有个细节要留意:Ollama 的默认上下文长度可能比你想要的短,必须用num_ctx显式指定,否则长一点的上下文会被截断,表现是模型"看不见"文件开头的东西,补全忽好忽坏。这个坑我遇到过一次,排查了半天以为是提示拼装的问题,最后发现是上下文被悄悄裁了。

4.3 路径三:vLLM 服务化,多人共享的正确姿势

当你要给一个团队提供补全服务,单请求延迟已经不是主要矛盾了,吞吐才是。vLLM 的核心优势是连续批处理和分页注意力,能把多个并发请求高效地塞进同一批计算里,显卡利用率比朴素推理高好几倍。

python -m vllm.entrypoints.openai.api_server \ --model /models/starcoder2-7b \ --served-model-name sc2-7b \ --dtype bfloat16 \ --max-model-len 4096 \ --gpu-memory-utilization 0.90 \ --max-num-seqs 16 \ --port 8000

--gpu-memory-utilization 0.90是让框架占用 90% 显存,剩下的留给系统和临时缓冲。这个值不要设到 0.95 以上,容易在峰值时被系统杀掉。--max-num-seqs 16是同时在处理的序列数上限,设太大显存会先撑不住,设太小并发一高就排队。实际调的时候,从 8 开始往上试,观察延迟曲线,找到 p95 延迟还能接受的那个点。

vLLM 暴露的是 OpenAI 兼容接口,但因为补全走的是 completion 而不是 chat,接入时要用/v1/completions,并且把 FIM 提示整体放进prompt字段。我见过有人把它当 chat 接口用,把代码塞进 user message,结果模型完全找不到 FIM 标记,补全质量惨不忍睹。

4.4 编辑器接入:把服务接到光标上

服务跑起来只是第一步,把补全接到编辑器的光标位置才是真正的"能用"。现成的路子有两条:一类是补全插件,配置里填模型地址就行;一类是自托管补全网关,它对编辑器的支持是自己实现的,好处是模板拼装、上下文采集、停止条件都能自己控。

以常见的补全插件为例,配置大致长这样(不同版本字段名会有差异,以插件文档为准):

models: - name: sc2-7b-local provider: ollama model: sc2-7b-fim apiBase: http://127.0.0.1:11434 roles: - autocomplete defaultCompletionOptions: maxTokens: 128 temperature: 0.2 topP: 0.9 stop: - "<|endoftext|>" - "<file_sep>"

关键在roles: autocomplete这一项。补全和对话是两个完全不同的提示模板,插件如果把它当对话模型用,补全质量会差很多。配好之后,在编辑器里敲一个函数名加左括号,应该能看到灰色的行内建议,按 Tab 接受。

如果插件不支持自定义 FIM 模板,你就得自己写一个薄薄的中间层:接收编辑器发来的前缀、后缀、文件路径,拼成 FIM 提示,转发给后端,再把结果裁掉后缀部分返回。这个中间层用几十行代码就能写完,收益是你能完全控制提示内容,包括注入 import 块、注入同文件的符号定义、控制缩进对齐。我自己是用这个方式做的,因为现成插件几乎都不支持"把后缀也传给模型",而缺了后缀,FIM 的优势就废了一半。

4.5 上线前先压一轮:延迟和吞吐的实测方法

部署完别急着宣布完工,先做一轮压测。方法很朴素:准备 50 条真实的光标位置样本,写个小脚本循环打请求,记录首 token 延迟和总耗时,算 p50 和 p95。补全场景里 p95 比平均值重要得多,因为平均值好看、p95 是 1.5 秒的体验,照样让人抓狂。

我常用的目标是:单机自用,p95 首 token 延迟压到 300 毫秒以内;团队共享服务,p95 压到 800 毫秒以内。达不到就按顺序排查:先看是不是所有层都卸载到了显卡,再看上下文是不是开太长,然后看并发数是不是超了,最后考虑换更小的量化档位或更小的模型规格。这里有个反直觉的经验:7B 的 Q4 常常比 3B 的 FP16 体验更好,因为质量差距带来的返工成本,比那点延迟差距值钱得多。

5. 提示拼装与参数调优:把补全做到"能用"

5.1 上下文里到底该放什么

补全质量的分水岭,不在模型,在上下文。同样一个模型,上下文拼得好不好,体验能差出一个档位。我的默认拼装顺序是这样的,总预算控制在 1.5k token 以内:

第一块是光标前的内容,从当前函数开头截起,如果函数太长就保留尾部;这一块权重最高,因为语法结构、变量名、缩进都在里面。第二块是光标后的内容,通常取 200~400 token 就够,FIM 主要靠它来对齐括号、补全参数列表、避免重复定义。第三块是当前文件里的 import 和类型定义,放在最前面,让模型知道有哪些符号可用。第四块是同文件里被光标前代码引用到的函数或类定义,按符号名匹配捞出来,截取签名和头几行。

如果要做跨文件检索,我建议别上重度方案,先用最土的:按当前文件的 import 列表,把被引入模块的导出符号签名捞出来,拼成一段"可用接口清单"塞进去,总量控制在 300 token。这一步的成本很低,收益比我预期的大,尤其是用第三方库的时候,模型经常能正确调用那些它原本不熟的接口。

注意:注入的上下文一定要带清晰的分隔,不然模型会把不同来源的代码混在一起,生成出跨文件的缝合怪。我的做法是用注释行做分隔,比如# --- current file ---、# --- imports ---,简单但有效。

5.2 参数取值:补全场景和聊天场景完全不同

很多人从对话模型迁过来,直接套用聊天的参数,结果补全要么啰嗦要么跑偏。补全需要的是"短、稳、贴题",不需要发散。下面这张表是我实际在用的取值,可以直接当起点。

repeat_penalty这一项值得单独说。代码里有大量合法重复,比如连续的}、连续的pass、重复的参数名。惩罚设太高,模型会为了避开重复而写出奇怪的东西;设太低,又容易出现死循环式的重复输出。我的经验是 1.05 附近最稳,遇到死循环优先检查 stop 序列和最大 token 数,而不是一味加惩罚。

5.3 什么时候值得做微调

微调这件事,我的态度是:先别做。原因很简单,大部分"补全不好用"的问题,根源在上下文拼装和参数,不在模型权重。你花两天做一版 LoRA,很可能不如花两小时把上下文拼装改对。

但有三种情况,微调确实值得投入。第一种是内部 DSL 或者自研框架,语法和主流语言差别大,基座模型基本没见过,这时用几千条真实代码做 LoRA,效果提升非常明显。第二种是强风格约束,比如团队要求所有函数必须有特定的错误包装、特定的日志格式,靠提示注入只能做到七成,微调能做到九成。第三种是特定领域的术语和 API,比如某个行业的计算库,模型老是编造不存在的函数名,微调能显著降低幻觉率。

具体做法上,有两个点容易翻车。一是数据构造必须用 FIM 格式,不能只用"前文续写"的样本,否则微调完模型会丢掉中间填充能力。二是数据量别贪多,几千条高质量样本效果往往好过几万条脏数据,而且小样本更容易过拟合,训练轮数控制在 2~3 轮,观察到验证集 loss 开始抬头就停。学习率用 1e-4 到 2e-4 量级,LoRA rank 从 16 起试,别一上来就 128。

# 构造 FIM 训练样本的核心逻辑示意 def to_fim(prefix, middle, suffix): return { "text": f"<fim_prefix>{prefix}<fim_suffix>{suffix}<fim_middle>{middle}<|endoftext|>" } sample = to_fim( prefix="def retry(fn, times=3):\n for i in range(times):\n try:\n ", middle="return fn()\n except Exception:\n if i == times - 1:\n raise", suffix="\n\ndef test_retry():\n assert retry(lambda: 1) == 1" )

这段代码本身没什么技术含量,但它点出了一个常被忽略的事实:训练样本的三个片段必须来自同一份真实代码的自然切分,而不是人工拼凑。人工拼凑出来的前后缀在语义上不连贯,模型学到的就是"怎么把不相关的东西缝起来",越练越歪。

6. 常见问题与排查实录

6.1 现象对照表:先定位再动手

下面这张表是我和周围人踩过的坑里最高频的一批,按现象索引,遇到问题先对号入座,能省掉大量试错。

表里最值得展开的是"缩进错乱"这一条。Python 尤其敏感,如果你把前缀截断在行首,模型就不知道当前应该缩进几层,生成出来的代码缩进全错,粘贴进去直接报语法错误。我的处理方式是在拼装前缀时,至少保留光标所在行的完整缩进,并且在提示里显式带上这一行的前导空格。这个细节听起来很小,但它决定了补全结果能不能直接按 Tab 接受。

6.2 几条不上文档的经验

第一条:先做纯文本验证,再接编辑器。编辑器里出问题,你很难判断是模型的问题、提示的问题还是插件的问题。用 curl 或者一段 Python 脚本直接打服务,把 FIM 提示手工拼好,看输出对不对。这一步跑通了,再去接编辑器,排查范围立刻缩小一半。

第二条:给每个模型版本固定一份参数配置。我吃过这个亏:换了量化档位之后忘了改上下文长度,结果新模型在老配置下频繁截断,表现是"时好时坏",查了一整天才发现。现在我的做法是把模型文件、量化档位、上下文长度、stop 列表写在一个配置文件里,换模型就整体换配置,不允许单独改某一项。

第三条:建立一个"错误样本库"。每次发现模型写错的地方,把当时的上下文和建议输出存下来。积累到几十条之后,你会发现错误有明显的聚类,比如某类边界条件总是漏、某类异常处理总是简化。这些聚类就是下一步优化的方向,比盲目换模型有用得多。

第四条:别用补全模型做它不擅长的事。我见过有人拿它生成整个类、生成数据库 schema、生成复杂正则,然后抱怨效果差。它的能力边界是"根据上下文补几行",超出这个范围,质量下降是必然的。真要做这些,用更大的模型、更长的上下文、更结构化的提示,或者干脆换成对话式的用法,别硬逼着 7B 干 70B 的活。

第五条:定期回看量化档位。硬件在变、推理框架在变,半年前跑不动的 15B Q5,现在可能已经很流畅了。我大概每季度会重新测一遍几档量化的延迟和质量,顺手把配置往上调一档。这个习惯带来的体验提升,比任何提示技巧都直接。

6.3 一个具体的排查过程记录

有段时间我的补全变得很奇怪:简单的函数能补,稍微长一点的、跨了七八行的,补到一半就开始胡说,或者干脆缩进全乱。参数没动过,模型也没换,按理说不该这样。

第一步先排除服务端,用 curl 打同样的提示,输出正常,说明问题在客户端。第二步在客户端把最终发给服务的提示打印出来,发现长度只有 400 多 token,而光标前明明有两千多字符。继续追,发现插件的上下文采集是按"行数"限制的,默认只取光标前 10 行,我那个函数有 40 多行,被截掉了大半。截断的位置又刚好在一个if块中间,模型拿到的是个残缺的语法结构,自然补不出正确的缩进。

改法很简单,把行数限制改成按 token 预算来算,并且优先保留当前函数的起始位置,而不是机械地往前数行。改完之后,同类问题基本消失。这件事给我的教训是:补全出问题,先看实际发出去的提示长什么样,别急着怀疑模型。十次里有七八次,问题都在提示这一侧。

7. 最后分享一点实际体会

这套东西我在自己机器上跑了挺长时间,中间换过三次量化档位、两套部署方式、两个编辑器插件。最大的感受是,本地补全的瓶颈很少在模型本身,而在"喂给模型什么"这件事上。同样的 7B 权重,上下文拼装做得好,写日常业务代码的体验能到"顺手"的程度;拼装做得糙,就会觉得这玩意根本不能用。所以如果有人问我值不值得搭,我的回答是:愿意花两天调提示和上下文,值得;只想装个插件就指望它替代云端服务,那大概率会失望。

另外一个小技巧,关于怎么判断什么时候该信任补全:我现在只在"结构清晰、命名规范、有现成模式可循"的地方接受建议,比如写数据类的转换、写重复的错误处理、写测试的断言框架。反过来,涉及状态机、并发、权限判断、金额计算的片段,我一律自己写,模型给的建议只当参考。这个边界划清之后,补全的正面价值被放大了,负面干扰基本消失。

如果你打算继续往下做,我建议的扩展方向有三个:一是把上下文采集从"当前文件"扩到"相关工作区",用符号索引做轻量检索;二是做一套按语言区分的提示模板,不同语言的缩进规则、导入习惯差别很大,统一模板会拖后腿;三是把补全和代码审查串起来,让模型在补完之后顺手标注"这段逻辑我信心不足",把不确定性暴露给人。第三点听起来有点理想化,但实际做起来,只要在提示里让它输出一个简单的置信标记,就能过滤掉相当一部分不靠谱的建议。