让本地27B(或任意)模型数学从只有92.7% 准确到工程可靠！可用！
-
由于工程类工作的需要，要把本地模型纳入日常工作流。可是他们在搞数字的时候偶尔还是会出错，这是一个用大模型来说很严重的而且无法避免的问题，和模型参数关系不大，哪怕95%的准确率也不能用，所以做了一些研究。发现方法是有的，只不过是没有一个好的现成的解决方案。总的痛点就是不确定性，但是工程工作又需要确定性，所以我们要使用外部工具，比如说Python让他把这个不确定性完全消除，结果还是喜人的：
一、背景与结论
之前 8080 主力是花了好大精力调优的 Qwen3.8-Flash-Next（QFN-IQ3_XXS，Strata 跑的）。但是Strata这个玩意就没有并发，PP速度也是慢了点，处理工程文件的时候很痛苦。做了大量的俩模型输出质量测试，发现质量没有什么肉眼可见的变化，只是flash next的输出细腻度确实高一些，毕竟脑容量大，再三权衡之后最后还是决定换回 PaitonMvLLM跑27B（W3A4），证据很充分：
C1：200K 冷读 176.3s → 91.3s（1.9×）
C1：200K 二次命中 28.4s → 1.7s（16.7×）
C4：墙钟 36.8s → 4.3s，聚合 9.7 → 107.6 tok/s（11.1×）QFN 的 C4 是排队——四条 TTFT 0.7/8.4/17.6/25.4 秒；27B 是 0.1/0.6/0.6/0.7 秒，真并发。
3bit 够不够强？同 20 题逐组对照，两边完全相同：200K长文 3/3、识图 6/6、并发 4/4、工程计算 2/3、代码 0/2（判分严实际对）、结构化 1/2（同）。人工复核 19 vs 18。
结论：27B 又快又不弱，但数学不可信——日常 110 题 92.7%、高数 70 题 75.7%。
二、问题定位
把 26 道错题按类别拆开，发现一件反直觉的事：
单位换算（长度/面积/重量）15/15 全对
百分比/折扣/税费 25/25 全对
小费分摊 2/5（最差）
温度 4/5、配比 4/5、加权 4/5、复利 4/5、日期 4/5
高数 14 类 53/7026 道错题里，零道是算术错。全是：公式用错（加权平均算成简单平均）、语义偏（"每人付"）、边界（日期含不含首日、样本还是总体）、单位链（45m@1:1000 答 45cm）。
结论：算术可以外包，公式不行。
三、方案与实现
两层：模型只出「子命令 + 参数」，calc 出全部数值。
calc 是 systemd 常驻服务（sympy 只 import 一次，跨机 42ms）：
calc eval "4827+3916" → 8743 calc tip 240 20 3 → 96.00 calc diff "x**2*exp(x)" --at 1 → 8.155 calc det "[[1,2,3],[4,5,6],[7,8,10]]" → -3 calc stat "2,4,4,4,5,5,7,9" --ddof 0 → 方差 4.00子命令：eval conv pct tip temp ratio wavg compound dates diff integ limit solve det inv matmul binom comb stat vec cplx
真正的体力活是接口容错——模型不会按你的文档传参：
{"cmd":"add"}→ 加 add/mul 别名
eval "sqrt((3-6)^2+...)"→ 表达式支持 sqrt/log/exp/sin，^认作幂
det "[[1,2,3],[4,5,6]]"→ 矩阵认 JSON 数组/分号/换行
integ "x^2+1" 0 2→ 认位置参数
stat "3,5,7,9 std"→ 认 std/variance/总体/样本，容忍多余词
binom 10 4 0.3→ 自动识别 n/p/k 顺序
wavg 80 90 70 3 2 1→ 自动判断"值组+权重组"
solve "x**2-2*x-1=0"→ 自动去 =0
参数写错 → 打印正确用法，让模型自己改四、注入
工具做好，模型不一定用。第一次实测 27 题只有 9 题主动调。
解法是写进 chat template，不是写提示词：
{%- set CALC_RULE = "【计算纪律】凡涉及数值计算……必须调用 calc 工具，禁止心算。 拿到工具结果后立即给出最终答案，不要重复调用；收尾：自检：单位✓ 量级✓ 工具✓" %} {{- "<|im_start|>system\n" + CALC_RULE + "<|im_end|>\n" }}改模板不改客户端，任何 agent 接进来都一样。验证方法很土：问它"系统提示里关于计算的规则怎么写的"，能一字不差背出来。结果：27/27 全部调工具。
五、折腾经过
先走了两条弯路：加了代理层（模型前面套一个自动执行 tool_call 的 proxy），能用，但违背"越简单越好"；又把模型挪到 8090 让 proxy 占 8080，所有客户端配置都要跟着改。最后全拆了，回到不改端口、不加中间层，只改模板。
calc 一开始是每次新起 Python，sympy import 350ms，单次 540ms。改成 systemd 常驻后 42ms。
模型会写
{"cmd":"add"}这种名字，加了别名还得在工具描述里写"四则用 eval"。拿到工具结果还会再调一次，模板加"直接作答，不要重复调用"。
3×3 行列式两个都答 0——不是算错，是根本不会展开。
复数 (2+3i)(1−2i)，3i×(−2i) 算成 −6（应 +6），分配律符号。
测的时候判分取第一个数字，题面数字先出现，把 14.0 判成 −10；改成"任一数字命中即通过"。
全角减号 −1 和 -1 认不出。
六、结果
27 道必错题，修复 26（96%），工具调用 27/27。
小费 3/3、温度 2/2、配比 1/1、加权 1/1、复利 1/1、日期 1/1、比例尺 1/1、导数 3/3、定积分 1/1、行列式 2/2、矩阵 2/2、概率 2/2、统计 2/2、向量 2/2、复数 2/2、多项式 0/1（单跑两次都过，批量偶发空正文）。
代价：每题 +0.65 秒（多一轮请求 + 工具执行），绝对值 0.78s/题，无感。
说明：
能外包的：算术、单位换算、日期、矩阵/积分/统计。不能外包的：公式选择、题意识别、边界定义——后者只能靠模板固化，写死公式让模型填参数。
部署就三样：docker-compose.yml（端口不变）、chat_template_calc.jinja（纪律写死）、calc.service（systemd，sympy 常驻）。
个人的repo，欢迎指教
https://github.com/halonc/local-llm-27b-reliability-boost -
-
-
-
-
-
-
-
請問妳在驗證時模型 temperature top_k top_p 是設多少？ 謝謝
查了脚本、服务端参数和模型自带配置这三处：
实际使用的参数
位置 temperature top_p top_k 测试脚本（27 题 / 110 题 / 70 题） 0 未传 未传 服务端启动参数 0.7 0.95 20 模型自带 generation_config.json1.0 0.95 20 客户端显式传入
temperature: 0，这个值会覆盖服务端的 0.7；top_p和top_k没有传，因此沿用服务端 override 的 0.95 / 20；--seed 42一直固定使用。但实际效果上，只有
temperature=0在起作用在 vLLM 中，当
temperature=0时走的是 argmax（贪心）路径，top_k和top_p虽然设置过，但不参与采样——所以那 27 道题是确定性解码，不是“用固定随机种子跑出来的采样”。这样设置的理由是：要测的是模型“会不会算”，而不是“是否抽到正确的 token”。如果使用 0.7 采样，同一道题跑两次可能会得到不同答案，那么测出来的数就不是模型能力，而只是运气。
温度是零，所以这已经是能做的最确定的测试了。总归就是大模型乱说这个事情和它的根本原理有关，而不是它的性能。越好的模型只是胡说的概率会小，但是并不会消失，定性的来说是这样。
-
-
-
@fcme 之前和ai分析，他认同在moe而且只在几家模型上有闲置资源占满的优势，我追问，那么是划分系统资源部分把cpu算力和其他资源的一部分用来优化推理算力需求吗，他的回答是，不是部分，是全部可用资源，也没有预留的工程安全冗余设置，而且不算是优化是劣化，因为其他资源作为算力占满不能作为工程环境依赖，在实际工程中会占满甚至发生硬件资源分配的拥堵。他的实际意义在于可以用更低的显存拉起更大的几款moe型模型，用来展示可以，看我能跑，看我多快，而对于稠密型模型几乎没什么提升价值还带来了参数适应调试成本。你的实战进一步印证了这些推理不是幻觉，我不测了，改个推理引擎也挺累的，谢谢
-
@fcme 之前和ai分析，他认同在moe而且只在几家模型上有闲置资源占满的优势，我追问，那么是划分系统资源部分把cpu算力和其他资源的一部分用来优化推理算力需求吗，他的回答是，不是部分，是全部可用资源，也没有预留的工程安全冗余设置，而且不算是优化是劣化，因为其他资源作为算力占满不能作为工程环境依赖，在实际工程中会占满甚至发生硬件资源分配的拥堵。他的实际意义在于可以用更低的显存拉起更大的几款moe型模型，用来展示可以，看我能跑，看我多快，而对于稠密型模型几乎没什么提升价值还带来了参数适应调试成本。你的实战进一步印证了这些推理不是幻觉，我不测了，改个推理引擎也挺累的，谢谢
@范志刚
对这个AI说的很到位，Strata本质上是llamacpp的魔改版本。所以最最最核心的缺点还是继承了llamacpp的，只是在资源调度方面做了大量的文章。分家分层加载的可以抽象为在显存里开了个小一点的稠密模型的同时还能借用一点点，开在显存里的储存更多不常用知识的调用频率（对应专家未命中率）很低的大型的稠密模型。
所以我把我的Strata优化到冒烟以后发现GPU和CPU的占用都很高，如图：
所以从原理上他就不适合跑稠密模型，因为稠密模型无法切块，而MoE可以抽象成俩分块的稠密。
-
@范志刚
对这个AI说的很到位，Strata本质上是llamacpp的魔改版本。所以最最最核心的缺点还是继承了llamacpp的，只是在资源调度方面做了大量的文章。分家分层加载的可以抽象为在显存里开了个小一点的稠密模型的同时还能借用一点点，开在显存里的储存更多不常用知识的调用频率（对应专家未命中率）很低的大型的稠密模型。
所以我把我的Strata优化到冒烟以后发现GPU和CPU的占用都很高，如图：所以从原理上他就不适合跑稠密模型，因为稠密模型无法切块，而MoE可以抽象成俩分块的稠密。
-
@paul-hou
对，这个框架用多了，它的局限性就逐渐显现出来了，而且是无法克服的那种。
他爱开子代理，如果子代理给其他的大模型也还好，本地运行的话，基本上都只有一个模型在跑，所以就是很频繁的卡死。我之前针对strata的冒烟优化，就是着力挖掘了它的缓存方面的潜力，让单流处理的时候，时间尽量缩短来缓解这个问题，但是最后还是无解的。以后需要质量高一点的时候，直接调用云端API就好了，他和27比真的没有差那么多。至少是咱们运行的量化版本来说。 -
@paul-hou
对，这个框架用多了，它的局限性就逐渐显现出来了，而且是无法克服的那种。
他爱开子代理，如果子代理给其他的大模型也还好，本地运行的话，基本上都只有一个模型在跑，所以就是很频繁的卡死。我之前针对strata的冒烟优化，就是着力挖掘了它的缓存方面的潜力，让单流处理的时候，时间尽量缩短来缓解这个问题，但是最后还是无解的。以后需要质量高一点的时候，直接调用云端API就好了，他和27比真的没有差那么多。至少是咱们运行的量化版本来说。 -
-
@paul-hou
我让27b翻了一下我的调试记录，关键点在于你pcie的速度，而且并发的时候总速度反而会掉，你可以做个参考，如下：找到了。完整记录在会话
session-4ec38542（标题：R9700-Strata-调优全记录），2026-10-26 当天实测。以下是搬出来的原始数据：
Radiance Flash-Next 实测数据（2026-10-26，单卡 R9700，204800 窗口，4096 chunk，MTP=4，fp8 KV）
项 数值 prefill 8.9K / 33K / 134K 1,077 / 1,303 / 1,339 tok/s TTFT 同上 8.3 / 25.9 / 100.6 s decode（temp 0.7，400 tok） 55.9 / 63.0 tok/s decode（贪心） 57.9 tok/s decode（temp 0.7，多轮） 41.6 / 40.3 tok/s decode @125K 上下文 34.9 tok/s 并发 2 / 4 聚合 31 / 50 tok/s 同对话追问（命中 12,288 tok 前缀） TTFT 1.53 s 冷启首轮 25 tok/s（必须预热） 启动日志关键量：专家 17.31 GiB 显存 + 43 GiB pinned 主机池；KV 4.86 GiB；PLE(n-gram) 表 47.68 GiB 在磁盘（内存装不下）；模型总文件 113.6 GiB。
为什么放弃（三条硬理由）
1. 链路硬顶，prefill 被 PCIe 3.0 卡死
R9700 上游链路被降级到 Gen3 x16（宿主
LnkSta: 8GT/s (downgraded)），GPU 空载 2 GiB 大页拷贝实测 13.8 GB/s。Radiance 的架构是每步把 43 GiB 专家池从主机内存搬过 PCIe，算下来 PP ≈ 14 GB/s ÷ 11.3 MB/token ≈ 1,240 tok/s——与实测 1,300 完全吻合。官方 2,545 tok/s 是 Gen4/5 平台的成绩，你这台 Dell 7820（Xeon Gold 6252，PCIe 3.0）物理上到不了。2. 内存模型撑不住并发和缓存
43 GiB pinned 池把内存吃死，只剩 6–9 GB 给对话缓存——8 条对话缓存根本开不了，SSD session 也不支持。而 Strata 只用 ~40 GiB 匿名内存 + 页缓存，剩 16 GB，才装得下 6 GiB / 8 槽的对话缓存 + SSD session。
3. 同卡对比 Strata 全面胜出
项 Radiance Strata（同卡同窗口） prefill 1,300 2,250–2,336（1.8×） decode 57–63 116–122（adapt-every 1） 8 槽对话缓存 
0.54 s 热态SSD session 可用内存 6–9 GB ~16 GB 附带现实约束：当时
/data池只剩 36 GB，Radiance 的 113.6 GB 模型必须删掉才装得下 Strata 的 81 GB 权重——只能二选一，不是偏好。
一句话总结：Radiance 的架构（专家每步过 PCIe）在你这台 PCIe 3.0 宿主上被链路带宽锁死，prefill 天花板 ~1,300、decode ~60，而 Strata 把专家算在 CPU/常驻显存，同卡直接翻倍。模型已删，要复核需重新下载 113.6 GB。
-
-
完美对症
