燕家猫本地部署大模型的应用周期里，最容易被跳过却又最重要的一环就是API鉴权。我见过太多团队把基于Ollama、vLLM跑起来的本地大模型API直接开给前端或者内部工具，模型也确实能跑通，可等到有人在内网扫到接口、白嫖了一堆算力，或者月底根本分不清哪个业务线消耗了多少Token时才反应过来——本地大模型API调用鉴权这层如果不补，后面所有可视化、计量、权限控制、业务扩展都无从谈起。
这篇文章就围绕“鉴权”这个最容易偷懒的环节展开。我会先用实际场景说明为什么本地模型服务必须做鉴权，再把静态Key、签名、JWT这些主流方案的选型逻辑讲清楚，然后给出一套可以直接抄的Python网关实现，最后把鉴权后续的可视化监控和多业务扩展路径一并串起来。不管你现在是自己在开发机上玩大模型，还是已经在公司GPU服务器上部署了推理服务，这篇内容应该都能帮你少踩几个坑。
1. 本地模型API，为什么必须把鉴权这层补上
1.1 不鉴权可能遇到的三种真实情况
很多人的第一反应是“我的服务只在内网跑，不鉴权也没事”。这类想法我一开始也有过，直到真正吃过亏才改变。先说三个我见过或者亲身踩过的场景。
第一个场景是端口扫描。只要模型服务监听了0.0.0.0，不管它在办公网还是云上内网，都会被人用扫描工具探测到。Ollama默认监听127.0.0.1，但为了给局域网里的同事用，很多人会主动把OLLAMA_HOST改成0.0.0.0:11434。一旦改了这个配置，任何能访问到这台机器的人都可以直接调用/api/generate，甚至还能通过/api/pull往你的服务器上拉模型。算力会被白白消耗，更麻烦的是别人能看到你服务器上跑着哪些模型。
第二个场景是调用方混乱。团队内部两三个同学调试时确实不需要复杂鉴权，但业务一旦铺开，前端、后端、数据分析、算法都在连同一个接口，问题就来了。某个同学离职后，他电脑里存的API地址和密钥还在被旧脚本调用；某个业务线偷偷用另一个团队的模型额度；出了线上事故后，想定位是哪边调用方的问题，结果日志里只有IP和User-Agent，根本无法定位到具体的人和具体应用。
第三个场景是管理接口和控制面暴露。推理服务为了易用性，往往会暴露一些管理类接口。Ollama有拉取模型、删除模型的接口，vLLM依赖外部模型加载器，但如果代理层直接开放了模型管理能力，不说恶意攻击，光是有人误操作把线上模型删了、覆盖了，就够你喝一壶。鉴权要管的不仅是“谁能调用”，还要管“谁能改配置”。
1.2 鉴权在本地模型服务中到底承担什么职责
鉴权这个词在本地大模型场景里并不只是“校验一个Key”那么简单。拆开看，它至少承担四层职责。
第一层是身份识别，也就是确认“你是谁”。每次请求必须能对应到一个人、一个应用或者一个业务线。没有这层，后面做的所有限流、配额、审计都是无源之水。第二层是访问控制，也就是“你能做什么”。不同角色能访问的模型不一样，有的Key只能访问轻量模型，有的Key可以调用千亿参数大模型，有些路径比如模型管理接口则完全不对普通调用方开放。
第三层是行为审计。每次请求从哪个Key来、调了哪个模型、消耗了多少Token、耗时多久、成功还是失败，这些信息必须能被追溯。单纯做日志还不够，日志要围绕“API Key+模型+调用方”这几个维度结构化存储，否则事故复盘时很难回答“到底谁在什么时间干了什么”。第四层是计量和成本分摊。本地部署模型也有成本，电力、GPU折旧、运维人力都是钱。没有鉴权体系就没有计量口径，后续做业务扩展时连“哪个业务线消耗了多少资源”都说不清楚，更别提预算管控了。
所以，鉴权在本地大模型API场景里不是一个可选项，它是把模型能力从“技术demo”推向“业务服务”的那道基础门槛。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 方案选型：模型服务、网关层与鉴权模型怎么搭配
2.1 常见本地推理服务的鉴权支持情况
先看一个直接的问题：主流本地推理框架自身有没有鉴权能力？我基于自己的使用经验整理了一个对照表。
| 推理服务 | 是否默认开启鉴权 | 是否支持多用户 | 是否支持配额管理 | 适合的默认暴露范围 |
|---|---|---|---|---|
| Ollama | 否 | 否 | 否 | 本机或受信任局域网 |
| vLLM | 可配置静态Key | 否 | 否 | 内部受控网络 |
| LocalAI | 可配置Bearer Token | 弱 | 否 | 内部受控网络 |
| Xinference | 有简单Key | 弱 | 部分场景可配置 | 内部受控网络 |
| llama.cpp server | 可配置简单Key | 否 | 否 | 本机调试为主 |
从这张表能看出，不管是Ollama还是vLLM，它们更多聚焦在“怎么把推理性能做好、把OpenAI兼容接口做得可靠”，而不是“怎么帮你管好一群人和一批应用”。vLLM的--api-key参数只能提供一个全局静态Key，内部十个人用同一个Key，出问题照样分不清是谁。Ollama目前开源版本没有Token体系，改OLLAMA_HOST绑定外网后，只要端口可达就能调用。
这也是为什么本地模型服务一旦要共享，就必须在模型前面加一层网关，把鉴权、审计、限流这些事收敛在网关里做，而不是指望推理服务本身来解决。
2.2 网关应该放在哪一层：轻量反代还是成熟API网关
网关放在模型服务和调用方之间，所有请求都经过它做鉴权和转发。这个小而关键的架构决策，直接决定了后续扩展的舒适度。
如果只是给团队内部五六个人用，最务实的方案是写一个轻量反向代理服务，用FastAPI或者Flask都行。它的核心逻辑很简单：校验API Key，然后反向代理到上游的Ollama或vLLM。这个方案维护成本极低，但能覆盖大部分内部需求。
如果公司已经有微服务体系和API网关基础设施，比如Kong、Apache APISIX这类组件，那就没必要重复造轮子。APISIX的key-auth、limit-count、response-rewrite插件组合起来，已经能实现密钥校验、限流、响应头改写，团队对这类系统本身就有运维经验，直接接入模型服务即可。
我个人的选型经验是：不要一上来就上重型网关。本地大模型场景一开始往往只有一两个模型服务，调用方也少，此时用Nginx加auth_request模块或者一个200行的Python小服务反而最灵活。等到调用方超过几十个、需要带管理后台、需要给不同业务线分配不同配额时，再切换到成熟网关或者自研控制面也不迟。
2.3 静态Key、HMAC签名和JWT怎么选
同样叫鉴权，不同方案解决的是不同层面的问题。
静态API Key是最基础也最常见的做法。调用方在Header里带一个Authorization: Bearer sk-xxx，网关查表确认Key存在且未过期即可放行。它的优点是实现简单、调试方便，特别适合内部服务。
HMAC签名则是在API Key之上增加了防篡改和防重放能力。调用方把请求方法、路径、时间戳、请求体放在一起做摘要签名，网关用同一把密钥验证。好处是即使请求在途中被截获，攻击者也没法随意篡改请求体；坏处是签名逻辑对调用方不够友好，每次生成签名都要写额外代码，前端联调时会比较痛苦。这种方案一般用于对外开放的API，或者对安全性要求更高的B端场景。
JWT是另一种思路。网关不直接存储密钥，而是通过验证JWT的签名来确认用户身份。JWT里能带上用户ID、模型权限范围、过期时间等信息。如果公司已经有统一登录系统，用OAuth2授权后发放JWT会比较顺畅。但对本地模型服务这种相对封闭的场景来说，引入JWT通常意味着还要搭建或对接一套身份认证服务，初期会偏重。
我的建议是：范围控制在团队内部时，先用静态API Key起步；需要开放给合作方或者外部开发者时，再在静态Key基础上叠加HMAC签名组件；需要在公司统一账号体系内做用户自服务时再考虑JWT。起步阶段不要把鉴权模型设计得太重，否则会被流程本身拖住。
3. 落地实现：写一个带鉴权的本地模型API网关
3.1 运行架构与一次完整请求的鉴权链路
为了让后面代码部分容易理解，先描述一次完整请求是怎么走通鉴权的。假设团队在GPU服务器上部署了Ollama（监听127.0.0.1:11434）和一个OpenAI兼容的vLLM服务（监听127.0.0.1:8000），这两个服务都不直接暴露给外部。对外暴露的是一个新建的Python网关，监听0.0.0.0:8080。
调用方发起请求后，链路是这样的：
- 客户端把API Key放在请求头
Authorization: Bearer sk-xxx中，请求打到网关的`/v1/chat/completions