刷题系统部署前先厘清模型调用边界

刷题系统部署前先厘清模型调用边界模型服务不稳定时应用层最容易出现的症状不是 GPU 满载而是请求堆积连接迟迟不返回、goroutine 增多、网关开始超时。遇到这种情况先不要凭 CPU 或显存利用率判断根因。需要把请求在网关、业务服务和模型端各耗时多久记录下来再看阻塞点在哪里。配置需要写成明确的约束部署前至少确认四件事内网模型地址是否被HTTP_PROXY、HTTPS_PROXY或NO_PROXY意外影响每次调用是否有context超时以及超时是否小于网关的等待时间单个请求的输入大小、输出 token 和在途请求数是否有限制模型失败后返回什么。可以返回规则校验结果或“稍后重试”不要把无限等待当成降级。这些限制应按服务能力配置而不是照搬固定数值。模型、网络和题目长度变化后超时与并发上限都要重新测量。func callModel(ctx context.Context, client *http.Client, endpoint string, body io.Reader) (*http.Response, error) { if endpoint { return nil, errors.New(模型地址不能为空) } req, err : http.NewRequestWithContext(ctx, http.MethodPost, endpoint, body) if err ! nil { return nil, fmt.Errorf(创建模型请求: %w, err) } req.Header.Set(Content-Type, application/json) return client.Do(req) }调用方用context.WithTimeout创建请求范围内的超时http.Client也应设置兜底超时。两者都不能代替连接、读取和空闲连接的参数调校但能确保取消请求时资源有机会释放。排查顺序先用最小请求验证直连模型地址再检查容器内的代理变量和 DNS 解析。随后查看服务的请求耗时分布、错误类别与 goroutine profile。pprof只应暴露在受限管理网络不能直接公开到业务入口。模型返回格式错误时记录请求 ID、模型版本和经过截断或脱敏的校验错误即可。不要把完整题目、用户代码或 Prompt 直接写入日志。真正上线前用目标模型、目标网络和代表性题目做压测记录测试条件和结果这些数据才能决定限流、超时和降级策略。