企业级大模型落地指南

你这问题我踩过一模一样的坑，最后发现根本不是timeout或者CORS的事。Ollama的请求是同步阻塞的，你在MCP的async回调里直接调它，整个事件循环就卡住了，SSE那条连接自然就断了。我当时是把Ollama的调用扔到线程池里跑的，用run_in_executor包一层，瞬间就好了。另外你回调地址填的，如果MCP server和Ollama在同一台机器上没问题，但要是走容器或者代理，得确认

试试把检索到的文档按相关性重排，只取前3段喂给模型，效果能提升不少。

这问题我也踩过，7B在40G上fp16理论够但KV cache和中间激活才是大头，尤其长上下文并发直接爆炸。建议把max-model-len砍到4096或2048，配合vLLM的enable-prefix-caching能省不少重复计算。另外开个--kv-transfer-config试试，或者改用pagedattention的块大小调低点，我这边4bit下用这些设置能扛住8并发不OOM。hist

这俩框架对动态图复用的设计思路确实不一样，TF的graph模式在Agent这种高频小图调用上天生吃亏，建议试试TF的tf.function配合input_signature固定形状。 我踩过类似的坑，后来干脆把LLM子图单独用PyTorch部署，中间走gRPC通信，虽然多了网络开销但整体延迟反而降了。

我之前也遇到过类似情况，最后发现是backbone的BN层在训练模式下会持续更新running_mean/var，如果用了多卡同步BN或者数据加载时每个step的batchnorm统计量没释放，显存会慢慢累积。你可以试试在验证阶段用torch.no_grad()包一下，或者检查下有没有把验证集的loss也加进计算图里。另外DeepLabV3+的ASPP模块如果有空洞卷积并行，某些实现会隐式保留中间

试试在检索时把时间上下文拼进query里，或者对结果按时间戳做一次重排，能压掉不少重复。

试试按语义完整性切分，用递归字符分割器配合标题层级，比固定token靠谱得多。

试试给每个工具加个强制输出校验，参数错就直接让模型重新生成，比调参管用多了。 建议换个支持结构化输出的模型，或者用langgraph做状态机，卡住能回退重试。

few-shot确实管用，把带完整注释（含import和def）的函数扔进去当范例，比光说“每行注释”稳多了。

这问题我踩过，核心不在embedding模型，而是你检索策略太粗暴了。可以试试把时间信息拼进向量里，比如“今天天气”和“明天天气”前面加个日期前缀，相似度自然就拉开了。另外用MMR（最大边际相关性）做重排，能在保证相关性的同时增加结果多样性，比单纯调阈值靠谱。

这问题我也踩过坑，后来是把检索的top_k压到5以内，同时让MCP工具返回时带个摘要字段而不是完整chunk，Claude那边再按需取详情。窗口滑动试过但效果一般，主要是长文档的中间部分容易丢逻辑。你们有没有试过让工具返回结构化元数据，让模型自己决定要不要继续查？

prompt长度确实是个关键点，1.5k tokens的输入会让prefill阶段占比很高，而vLLM对长上下文的prefill优化有限，GPU利用率低但显存满正好说明计算没吃满。可以试试把max_num_seqs调低到64或32，同时用--enable-chunked-prefill看看能否把prefill和decode重叠起来，另外确认下你的vLLM版本有没有用上PagedAttention

大概率是防火墙拦了，群晖默认只放行自家端口，去控制面板里把8899加进允许列表试试。

几百个PDF这个规模真不用太纠结，我当初用LangChain折腾半天Callback和Chain的嵌套，后来换LlamaIndex直接怼了个SimpleDirectoryReader进去，代码量少一半还更稳。生产环境的坑LangChain主要在版本更新太激进，API说变就变，你锁版本锁到怀疑人生；LlamaIndex反而对数据源变更更敏感，文档结构一改索引就得重建。你既然已经用ChromaDB了，

这个“分层输出”确实是痛点，之前用别的工具生成一张海报，想改个标题颜色都得重新抽卡，来回折腾半小时。RoboNeo能拆模块改，至少让设计师觉得AI是来干活的，不是来添乱的。 不过有个疑问，它识别国潮纹样精度高，是不是意味着训练数据里国内案例占比特别大？那遇到偏欧美风格的设计需求，会不会反而比Lovart弱？毕竟国内团队出海做品牌也挺多的。

角色设定这块我踩过一样的坑，尤其客服场景，加了“专家”人设模型就爱自由发挥，感觉它把“专业”理解成了“多写点”。后来我把角色描述砍到只剩一句“你只依据文档信息回复，不确定就说不确定”，效果反而稳。指令优先级这事，我觉得系统prompt里越靠后的约束越容易丢，关键限制要么放最前面，要么就像你说的在用户输入里再强调一遍，实测这招对长上下文的注意力分散挺管用的。结构化写法我试过用分隔符把“角色、任务、规

按章节标题切最稳，配合重叠窗口能留住上下文，我试过效果好不少。

这思路对，但光加“不知道”不够，得让模型先判断相关性再决定答不答，不然它还是会硬凑。 我试过把“不知道”格式化成固定输出再加个置信度阈值，效果比单纯提示词稳多了。

这题我熟，上周刚踩完同一个坑。protobuf这种底层库硬升确实容易引发连锁反应，我当时是用虚拟环境单独给MCP开了一套Python解释器，虽然不如docker彻底但胜在轻量，改改PATH就切过去了。另外你可以试试用pipdeptree查一下到底是哪个包锁的3.20，有些时候只是传递依赖写死了，手动加个overrides能绕过去。至于官方最小依赖集，文档里其实没写全，建议直接看源码里的setup.

fp16震荡大概率是loss scale没调好，试试bf16或者torchao的int8量化，能省不少显存。