Debug:mlx-omni-server服务器用qwen3模型出错

背景:AI回答出错,开始以为是代码问题使得之前的对话出现在上下文,没想到是mlx-omni-server的问题

debug过程:

最开始比较好运地在github论坛找到同样的问题,大概率确认服务器出错。

之后用copilot写了一个简单的go代码重现情况,并通过服务器log监视thinking process有没有包含旧提问信息。

调查发现哪怕用独立client也可能会吃到之前的错误内存。另外换成deepseek等模型也会有同样问题。

于是考虑更换server tool,从chatgpt推荐里选择了ollama。ollama同样支持openai的api,所以后端代码不用修改。

LLM server安装都很简单,不用过多设置,一条指令就能启动服务。测试后发现之前的bug被解决。

之后需要补上api-key的认证,但这时发现ollama不支持api-key。好在openai的api token认证和http的bearer token认证格式一致,所以加一层nginx检查token即可。

相关推荐
Token炼金师3 小时前
范式跃迁:从标注囚徒到自监督信徒 —— 大模型时代的机器学习重写
人工智能·深度学习·llm
chanalbert4 小时前
Agent 工程化指南(一):概念与认知架构 — 智能体到底是什么、怎么思考
llm·agent
johnny23315 小时前
代码仓库理解:Graphify、CodeGraph、FastContext
llm
倾颜17 小时前
AI 聊天长期记忆的向量化处理:从"关键词匹配"到"换种说法也能找到"
llm·agent·next.js
AI小码17 小时前
LLM 应用的缓存工程:当每次 API 调用都在燃烧成本
java·人工智能·spring·计算机·llm·编程·api
程序喵大人20 小时前
【AI专栏】图解Transformer - 第05章:LLM 推理工程
人工智能·深度学习·llm·transformer
DigitalOcean21 小时前
GPU 算力降本指南:拆解大模型推理账单的 4 个隐藏加价坑
llm·agent
Token炼金师1 天前
生产化的鸿沟:流式、缓存、可观测、红蓝对抗、限流降级与评测 —— 工程化六渡
人工智能·llm·可观测性·红蓝对抗·缓存策略·限流降级·评测体系
吃饱了得干活1 天前
LangChain 模型调用方案:invoke、stream、batch 的同步与异步
langchain·llm