二月中旬是技术圈最热闹也最没头绪的时候。上一轮大模型的热度还没完全退潮，新的小模型、推理框架、端侧方案已经排队入场，很多人不是没得选，而是选择太多不知道从哪里下手。这期 Tech Digest 02.19 我换了个思路，不再罗列新闻，而是把我自己这一周真正动手验证过的三件事摆出来：本地推理的成本账、一个慢接口的完整调优链路、以及我把工具从二十几个砍到六个之后的真实效果。如果你也正在做技术选型、性能优化或者预算规划，这份笔记应该比单纯的资讯列表更管用。

1. 本地推理重新被摆上桌：成本账和性能账都要算清楚

1.1 为什么本地推理这半年又“回春”了

这周被问得最多的问题不是“该不该上AI”，而是“AI到底怎么用才不亏”。大家显然已经从观望期进入务实期了。我观察到的一个明显信号是：本地推理又回到了开发者的工作流里。前两年大家倾向把所有请求都打到云端API，图的是省事，但实际用下来有几个问题是绕不过去的：敏感数据不能外传、调用次数多了账单不好控制、网络抖动直接拖垮生产环境。

我自己测试了 O1 和 Claude 都有一段时间了（抱歉，我会避免对特定模型做出评价），结论其实很简单：API 适合一次性回答、生成代码草稿、复杂推理；本地模型适合高频调用、私密数据处理、批量离线任务。把两者混着用，才是大多数团队的实际形态。这周我把之前写过一个“关键词翻译与摘要生成”的小工具改成了本地推理方案，一次性请求成本从几毛钱降到了几乎为零，延迟也从平均800毫秒降到了200毫秒以内。

1.2 一台普通机器到底能跑多大的模型

很多人上来就问“我电脑配置一般，能不能跑模型”，我的回答是：能，但你要先接受量化这个前提。现在主流开源模型发布时会同时放出不同精度的 GGUF 文件，常见的 Q4_K_M、Q5_K_M、Q8_0 分别对应不同的内存占用和效果损伤。你可以把量化理解成压缩饼干——体积小了，但营养会损失一点。

以通用对话模型为例，我的经验数据是：

实际测试里，我用一台 16GB 内存的轻薄本跑 8B 模型，速度大概每秒 15~20 个 token，用来做离线文本处理完全够用；如果有 NVIDIA 显卡，哪怕只是 12GB 显存的入门卡，速度都能翻好几倍。

1.3 本地推理的典型落地姿势

我这一周重点试了 Ollama 和 llama.cpp 两条线。Ollama 胜在把“下载模型—启动服务—调用接口”整条链路压到了三步以内，非常适合快速验证：

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

启动之后，本地默认暴露一个 OpenAI 兼容的 HTTP 接口，也就是说你之前写好的 API 调用代码基本不用改，把 base_url 指到本地地址就行。这个兼容层价值很大——团队在某一天想切回云端 API，代码层面几乎零改动。

llama.cpp 则更适合需要自己控制推理参数和部署在无 GPU 服务器上的场景。我把一个批量文本处理任务放到一台 2 核 4GB 的云服务器上跑，用 7B Q4 模型，单条文本耗时比调用云端 API 慢一些，但胜在流量完全免费、数据不出内网，跑了几万条文本都没花一分钱。这个收益对中小团队来说，是很真实的。

2. 一个变慢的报表接口，我是怎么把它从 2.8s 救回 0.2s 的

2.1 问题的表象和第一个排查动作

这周遇到最典型的性能问题，是一个报表分页接口突然变慢。后台同事反馈说翻页超过 3 秒，用户已经开始骂了。我接手之后没有直接埋头改代码，而是先看调用链和数据库状态。

第一步是开慢查询日志。MySQL 配置上开启slow_query_log，阈值设成 1 秒，跑了一小时，果然捞到一条异常语句：

# 慢日志截取 SELECT id, order_no, amount, created_at FROM orders WHERE status = 1 AND created_at BETWEEN '2025-01-01' AND '2025-02-19' ORDER BY created_at DESC LIMIT 20 OFFSET 50000;

这条 SQL 看着没毛病，但为什么跑得慢？我用EXPLAIN一看，发现优化器选的是全表扫描，预估扫描行数三百多万。问题就出在OFFSET 50000——为了拿到第 2501 页的数据，数据库得先把前 5 万行都查出来再丢掉。

2.2 这个坑的本质：深分页偏移的代价被低估了

很多团队做分页都喜欢写LIMIT 20 OFFSET n*20，数据量小的时候完全没事，一旦表超过几十万行，深翻页会把你打趴下。偏移量越大，数据库要扫描并排序的废弃行就越多，时间呈线性甚至超线性增长。

我当时的修法有两个。第一个是把普通翻页改成游标分页，也就是依靠索引列的值来定位而不是记录偏移量：

-- 游标分页写法 SELECT id, order_no, amount, created_at FROM orders WHERE status = 1 AND id > :last_seen_id ORDER BY id LIMIT 20;

这条查询只要命中主键索引，无论翻到第几百页，速度都稳定在几十毫秒。代价是分页的页码感没那么强了，但对“按时间往下滚”的报表场景来说，体验反而更顺滑。

第二个修法是给(status, created_at)建了一个联合索引。原来的查询需要在status过滤之后再用created_at排序，没有合适索引时就得做 filesort；补上联合索引之后，条件过滤和排序都能走索引，效果立竿见影。

2.3 实测数据和调优后的对比

优化前后我在同一台数据库实例上跑了压测，数据对比很直观：

压测从 2.8 秒降到 70 毫秒，效果很明显，但更重要的不是这个数字，而是整个排查过程中养成的习惯：先确认瓶颈在哪一层，再去动代码。我见过太多人一上来就加缓存、加机器，结果最后发现是查询语句本身写得不好，花了大钱办了小事。

2.4 这次调优给我留下的几条教训

• 在慢日志面前，不要猜。EXPLAIN 能告诉你真实的扫描行数和索引命中情况。
• 深分页是容易被忽略的隐藏炸弹，尤其是后台报表的页码往往很深。
• 别急着上 Redis 缓存。缓存只解决了热点查询的重复消费，没有解决单次查询本身很慢的问题。
• 性能优化的目标是让所有查询都跑得快，而不是给慢查询套一层加速器。

3. 工具做减法之后，剩下这几个我天天在用

3.1 从二十几个工具删到六个，反而出了问题

我前几年的工具习惯是“见了好的就装”，结果这周统计了一下开发机上常驻的服务：监控、日志、APM、消息队列、容器编排，加起来二十多个进程。看着很专业，实际用起来经常互相打架——告警消息一天刷几百条，重要故障反而被淹没了。

这周做的决定很粗暴：把能合并的合并，能停掉的停掉，最终只保留六类工具。挺意外的是，项目推进速度反而更快了，因为我终于知道每一份数据从哪来、该去哪里看、什么时候需要看。

3.2 清理之后的工具清单

有人可能会说这算开倒车，但我的判断标准是：在团队规模不到几十人的情况下，维护一个重型基础设施本身就是巨大的成本黑洞。工具的价值在于帮人决策，而不是制造更多需要人为判断的噪音。

3.3 告警治理的一点真实感受

告警是最典型的“越多越无效”场景。我删掉大部分告警规则之后，只保留三类：

• 系统不可用，直接 ping 人
• 错误率在 5 分钟内超过阈值，进了核心链路才告警
• 队列堆积超过一定量，说明消费者挂了

规则收敛之后，这周真正触发告警的次数一只手数得过来，而且每次都是真实故障。这比之前每天几百条“可能有问题”的提醒要实用太多。给技术债做减法，本质上不是少干活，而是把力气用在对的地方。

4. 二月装机：为了跑 AI 又兼顾日常，我的预算和型号思路

4.1 显卡显存才是第一道门槛

这周不止一个朋友问我同样的装机问题：平时写代码、偶尔跑跑本地大模型，显卡到底怎么选？我的回答永远先从显存开始。显存是硬门槛，跑不动的模型再便宜也没有意义。

大模型推理时，模型权重、KV Cache 都放在显存里，一个 7B 的 Q4 量化模型就要 5~6GB 显存，13B 需要 9~10GB，30B 以上直接奔着 20GB 去。如果显存不够，系统会把部分数据交换到内存，速度会断崖式下降，体验基本不可用。所以选显卡，第一看的是显存容量，而不是显卡的纸面算力。

4.2 我最近比较推荐的三档配置

我自己的机器用的是 16GB 显存档位，实测跑 14B Q4 模型，生成速度每秒 40~60 token，日常出一段说明、代码解释、批量分类完全足够。如果只是玩玩 3B/7B 小模型，核显其实都能跑，但速度会很难受，建议至少花 3000 元淘个入门卡。

4.3 内存和电源这些容易翻车的地方

除了显卡，还有几个隐藏大坑。第一是内存，跑模型时除显存外，系统内存也要留余量，16GB 是底线，32GB 会比较从容。第二是电源，大功率显卡需要实打实的电源，建议额定 650W 起步，别在电源上省钱。第三是散热，如果机箱闷罐，显卡长时间满负荷跑推理会过热降频，花了几千块钱买了性能打折。

买二手卡时要留个心眼：贴吧和论坛上经常有人把锻炼卡当游戏卡卖。我的建议是，优先找支持个人送修的品牌，买回来立刻跑半小时压力测试，显存温度超过 90 度就有嫌疑。选卡的逻辑很简单，找显存最大的，因为 AI 推理对显存容量的敏感度远高于对显示核心算力的敏感度。

5. 接下来这一个月，我会死盯这三条线

5.1 推理框架正在朝统一接口收敛

这一周的实测让我感受最深的是，Ollama、vLLM、llama.cpp 这些推理框架不约而同都在做同一件事——提供一个 OpenAI 兼容的接口。这意味着你今天写好的代码，以后可以随时把底座从本地框架换成云端服务，业务代码一个字都不用动。

我以前在项目里吃过绑定某个私有 SDK 的亏，所以现在选路由和推理框架的第一原则就是“接口是否标准”。这跟数据库连接用标准 SQL 而不是独有方言是一个道理，能让你在未来的框架切换中少流很多血。

5.2 端侧小模型的性能正在追上需求

另一个我觉得值得重点关注的方向，是 3B~8B 的小模型在端侧设备上越跑越流畅。目前 8B 量化版已经能在中端手机上跑出每秒十几个 token 的速度，用来做本地摘要、消息分类、甚至简单的语音助手，体验都在及格线以上。

对很多非核心任务来说，我们不需要一个无所不知的大模型，只需要一个在本地、不联网、响应快、隐私安全的小模型。未来一个月如果有时间，我会重点测一批端侧模型的工具调用能力和长上下文效果，这是当前小模型最容易露怯的两个地方。

5.3 AI 应用的工程化观测会越来越重要

这周我还做了一件不起眼但挺重要的事：给 AI 推理链路加上了完整的链路追踪。以前 AI 应用因为黑盒程度高，出了问题很难定位——是你提示词写得不对，是模型返回截断了，还是网络超时了？没有日志和数据，只能靠猜。

现在我把每一轮请求的输入 token 数、输出 token 数、推理耗时、模型名称、版本号、返回码都记录到日志里，用 OpenTelemetry 统一上报。以后查问题就有数据支撑了。

5.4 文摘编辑手记

这周把收藏夹从头到尾翻了一遍，真正点开读完的文档不到五分之一。信息爆炸的时候，筛选比收藏更重要。我自己给自己立了个规矩：凡是没在三天之内用过的工具、没和现有系统做过兼容性验证的框架，一律先不进收藏夹。

AI 技术迭代确实快，但落到真实业务里，最终比拼的还是谁先把成本、性能、稳定性这三件事搞清楚。如果你也在做类似的选型或者调优，欢迎拿你自己跑出来的数据和结论来对，这种实测积累比任何新闻都更能说明问题。