本地大模型

前言：为什么要把工具调用放到本地 过去两年，很多团队在做 AI 应用时都会先接一个云端大模型 API：把用户问题发出去，拿回一段文本，再在业务系统里解析。这个方案上手快，但一旦进入现场环境，问题很快就会浮出来：工厂内网不能直接访问公网，设备日志里可能含有客户数据，弱网场景下延迟不稳定，云端调用成本也不容易预估。更麻烦的是，一些“看起来只是聊天”的需求，本质上并不是聊天，而是让模型根据自然语言选择工具、填好参数、调用接口、再把结果解释给用户。比如“帮我查一下 3 号产线最近 10 分钟的温度异常”，模型需要决定调用 query_metric，参数包含产线编号、时间窗口和指标名；再比如“把这台边缘网关切到低功耗模式”，模型需要识别这是一个有副作用的动作，必须做权限确认和参数校验。 这类场景如果完全依赖云端，系统链路会变长，失败点会变多。相反，如果把小到中等规模的语言模型以 GGUF 格式部署在本地，通过 llama.cpp 提供推理服务，再在旁边放一个严格的 Function Calling 网关，就能得到一个更可控的架构：模型负责“理解意图”和“生成结构化调用计划”，网关负责“验证、授权、执行、审计”。这种分工非常适合工控边缘盒子、门店私有服务器、实验室内网助手、个人知识库一体机等场景。 本文不是简单介绍如何运行 ./llama-cli -m model.gguf，而是围绕一个可落地的本地工具调用网关展开：如何选择模型和量化格式，如何设计提示模板让模型稳定输出 JSON，如何用 Python 写一个流式调用编排器，如何处理超时、重试、权限和审计，最后如何把它部署到一台资源有限的边缘设备上。文章中的代码尽量保持小而完整，方便你按自己的业务接口替换。 一、整体架构：模型不要直接碰业务系统 一个常见误区是：既然模型可以生成函数名和参数，那就让模型输出什么就执行什么。这个做法在演示里很顺，但在生产环境里非常危险。语言模型是概率系统，它可能拼错函数名，可能把用户随口说的一句话理解成执行命令，也可能在上下文受到污染时生成越权参数。正确的做法是把模型放在“建议者”的位置，业务网关才是“裁判”和“执行者”。 本文采用的架构由五层组成： 客户端层：Web UI、命令行、企业微信机器人、串口控制台都可以作为入口。它们只负责收集用户输入和展示结果。 会话编排层：维护上下文、拼接系统提示词、把可用工具列表注入给模型，并解析模型输出。 本地推理层：llama.cpp 或 llama-server 加载 GGUF 模型，提供 OpenAI 兼容接口或原生命令行接口。 工具安全层：根据白名单、参数 schema、用户权限、二次确认规则决定是否允许执行。 业务适配层：真正访问数据库、设备驱动、HTTP API、MQTT、Modbus、文件系统等外部资源。 这个拆分的关键点是：模型输出永远只是“候选动作”，不能直接等价于“已授权动作”。即使模型说要调用 set_relay_state(channel=1, state="on")，网关也要检查当前用户是否有控制继电器的权限，channel 是否在允许范围内，动作是否需要二次确认，执行结果是否要写审计日志。 下面是最小化的工具描述格式。它不依赖某个云厂商的 Function Calling 协议，但足够表达函数名、用途、参数类型和安全属性。 { "name": "query_metric", "description": "查询某条产线或设备在指定时间窗口内的指标数据", "side_effect": false, "parameters": { "type": "object", "required": ["device", "metric", "window_minutes"], "properties": { "device": {"type": "string", "description": "设备或产线编号，例如 line-3"}, "metric": {"type": "string", "enum": ["temperature", "humidity", "current"]}, "window_minutes": {"type": "integer", "minimum": 1, "maximum": 1440} } } } 这里的 side_effect 很重要。查询类工具通常可以直接执行，控制类、写入类、删除类工具则应默认要求确认。很多事故不是模型“不聪明”，而是系统把模型的建议当成了不可质疑的命令。...

前言：为什么本地推理服务会成为团队的基础设施 过去两年，很多团队已经把大模型从“能聊几句的玩具”推进到了真正的业务链路里：客服质检、代码助手、文档检索、知识库问答、BI 分析、研发自动化、设备运维助手，场景越来越具体，调用量也越来越稳定。这个阶段最容易遇到的矛盾是：单次体验看起来不错，但一旦多人同时使用，延迟、成本、限流、数据安全、模型版本控制都会变成工程问题。 如果只是给个人写一个脚本，直接调用云端 API 最省事；如果团队已经有私有数据、内网系统、稳定 QPS、固定模型和合规要求，本地推理服务就值得认真建设。它不是为了“完全替代云服务”，而是为了把一部分可控、可预测、可缓存、可审计的请求沉到自己的基础设施里：模型版本自己定，日志留在内网，显卡利用率自己优化，业务峰值也可以通过队列和降级策略来处理。 在这一类方案中，vLLM 是目前很常见的选择。它的优势并不是“启动一个模型”这么简单，而是围绕大模型在线推理做了系统级优化：OpenAI 兼容 API、连续批处理、PagedAttention、张量并行、流式输出、Prometheus 指标、较成熟的服务端参数。对于很多团队来说，vLLM 正好站在“研究代码”和“生产服务”之间：比手写 Transformers server 更接近生产，比完整平台又轻量许多。 本文不打算只列一组启动命令。我们会按工程落地的顺序讲清楚：怎样选择模型与硬件，如何启动 OpenAI 兼容服务，为什么 PagedAttention 对吞吐和显存很关键，压测时应该看哪些指标，常见参数如何调，最后再补上网关、监控、systemd、Docker Compose 和故障排查。读完以后，你应该能搭出一个可用的内网推理服务，并知道下一步该怎么把它调稳。 一、先把目标说清楚：不是“跑起来”，而是“稳定地跑” 很多本地大模型项目的第一步都很顺利：下载模型，装依赖，跑一个 demo，看见回复，大家都很兴奋。真正的问题通常在第二周出现：同事开始接入，输入长度不一样，输出长度不一样，有人跑 8K 上下文，有人开流式输出，还有人批量生成摘要。GPU 显存看起来还剩不少，但请求排队越来越长；某些请求首 token 等待十几秒；升级模型后，原来的参数突然不合适；日志里偶尔出现 CUDA OOM，却很难复现。 所以在搭 vLLM 前，建议先明确四个目标。 第一，服务对象是谁。是给内部研发少量调用，还是给业务系统持续调用？如果只是研发使用，优先保证灵活性；如果是业务链路，优先保证限流、监控、灰度和回滚。 第二，模型规模是多少。7B、14B、32B、70B 对显存和并行方式的要求完全不同。模型越大，单卡部署越困难，吞吐和延迟的权衡也越明显。不要只看参数量，还要看量化格式、上下文长度、是否需要多 LoRA、是否要跑 embedding 或 rerank。 第三，请求形态是什么。短问短答、长文摘要、代码生成、Agent 工具调用的 token 分布差别很大。Prefill 阶段主要处理输入 token，Decode 阶段逐 token 生成输出；输入特别长会拉高首 token 延迟，输出特别长会占用更久的 KV Cache。压测时如果只用“你好”这种请求，结果没有参考价值。 第四，接受什么样的服务等级。比如 P95 首 token 延迟小于 3 秒，平均输出速度大于每秒 40 token，排队超过 30 秒直接返回忙碌，单 GPU 显存利用率维持在 85% 左右。这些指标越早写下来，后面调参越不会靠感觉。...