本地大模型推理服务

日常开发要用大模型，但云端 API 有两个硬伤：依赖外网（网络波动时开发流程直接中断），以及代码与业务数据必须出本机，合规上不可接受。更麻烦的是不同模型用途不同——编码要快、方案讨论要通用、深度推理要更强的模型，但一个一个手动起停、换端口、换配置非常繁琐，尤其 120B 这类重型模型加载一次要占65GB 内存，不可能常驻。

还有一个隐蔽的坑：gpt-oss 系列模型带思考过程，会把analysis 通道的内容混进答案正文，导致下游解析被污染——IDE 里表现为回答后面莫名多出一段推理文字，业务侧则直接解析失败。

本地推理 + 统一协议

用 mlx-lm 0.31.3 在 Apple Silicon 上做本地推理，统一暴露 OpenAI 兼容接口并强制离线，调用方不需要为本地模型改任何客户端代码。

多模型按需编排

按用途分端口并行编排——Qwen3-Coder-30B-A3B(4bit) 16GB 走8080 作编码主力（实测约 59 tok/s）；gpt-oss-20b(mxfp4) 13.8GB 走 8081 作通用推理（约 54 tok/s）；gpt-oss-120b(mxfp4) 65.2GB 走 8082 作重度推理（约 43 tok/s，需独占内存）。支持按需启动与一键全停，重型模型不必常驻。

上下文长度取舍

模型原生支持 262144，但 KV cache 吃内存。统一设为 32768——这是在 103GB 机器上速度与容量实测出的平衡点，需要塞更多代码时可试 65536，速度下降则回退。

harmony 通道清洗（关键）

mlx_lm.server 不解析 gpt-oss 的 harmony 通道，而 tokenizer_utils._infer_thinking 只认 <|channel>thought、对不上 gpt-oss 的 analysis 通道。自写 harmony_proxy.py 把思考过程剥离到 reasoning_content，只把 final 通道作为 content 返回（流式与非流式都支持）。为此额外开一组 9xxx 端口给 IDE，并写好 Continue 的配置文件让 IDE 一律连9xxx，避免思考内容污染补全。

启动即用

提供 continue-config-final.json（已含三模型配置与 Qwen3-Coder 补全），IDE 侧一条配置即可接入全部模型。

本地即可获得 43–59 tok/s 的编码与推理能力，代码与业务数据全程不出机器；接口统一后 IDE 与业务侧可无感切换模型，重型模型按需拉起不占常驻资源；harmony 代理彻底解决了思考内容污染下游解析的问题。