cowcomic

@zhutianjingtu ollama 默认的 8B 的模型好像是量化过的

@fcten 哪儿能租到 A100 啊？

@cctvbnm111X1 glm4 的 9B 咋样啊，支持 function call 或者 tool call 么？

@crackidz @ospider 习惯了，很多地方填真实的都可以，就掉以轻心了

@gulao https://huggingface.co/meta-llama/Meta-Llama-3.1-405B
进去直接就有填表的按钮

@GeekGao 是的，我后来用别人的号写的新加坡就过了

@Les1ie 我也以为是过场，没想到……

@zbinlin 断网环境很麻烦，发现魔搭能下

如果结构体就是发出来这个样子，可以改成下面的形式
```
{1002, "原因 2b", "errorCodes": [1002, 100202], "msg": "原因 2b"}
```
1002, "原因 2b" // 这部分就给原来的系统用

"errorCodes": [1002, 100202], "msg": "原因 2b" // 新系统用这部分，原来系统如果能迭代的话，逐渐改为这种
"errorCodes": [1002, 100202] // 这个结构留着以后细化 code 用

如果新结构想再增加扩展性，不同 codes 不同 msg ，外面再封一层数组

想再再再增加扩展性，参考 Java 的 Exception 对象

其实楼主说的这个不是严格意义上的瀑布，可以叫螺旋模型或者迭代模型都可以，就是多个小瀑布连起来
严格的瀑布是没有迭代这一说的，一个瀑布结束，就彻底交付，维保期顶多改 BUG 。瀑布最大的问题就来源于这个一把梭哈上

通常不会用 redis ，正常的时候没问题，万一出了问题，就是大问题，这个风险不敢赌
最好就是关系型数据库，通常就是 ID 分段，用个表管理 ID 段（这个表里可以根据预期预设好），每个实例已有段用完了就拿新的，段内自己做自增，万一故障恢复所需要校验的也不多
这样无法严格保证一定是小先大后（只要一个段不是特别宽，也很难察觉到），但基本能保证连续，没有跳号
这样缩容扩容也简单，无脑加减机器就行（严格连续的话，减机器是要做处理的）

不太清楚业务场景，不过看描述，我理解应该是 Base 放在主工程中，被引用使用，A 系列和 B 系列分别打自己的 jar 包，根据你的技术栈可以封装成 starter 或者 SPI 服务包，实际需要用的时候，需要用哪个就把哪个包加载进去

建议上安培架构的显卡，也就是 30 系和 40 系
印象一些推理加速技术还有一些量化的技术对显卡架构有要求需要安培架构以上的显卡